# SOC 2 の論理アクセスの規準(CC6.1〜6.3)を SaaS のアカウント管理に当てはめる

CC6.1 は情報資産へのアクセスを仕組みで制限すること、CC6.2 は承認してから ID を発行し不要になれば消すこと、CC6.3 は役割に応じた最小限の権限を求めます。SaaS では一覧・申請と削除の記録・定期の見直しに当たります。

更新日: 2026-10-13

SOC 2 の検証で使う Trust サービス規準には、「論理的及び物理的アクセス管理」の項目群(CC6)があります。そのうち CC6.1〜6.3 が、システムに入れる人とその権限を扱います。社内で使う SaaS に置き換えると、使える人の一覧、ID の発行と削除の手続、権限の種類と見直しの 3 つです。SOC 2 の仕組みそのものは [SOC 2 とは](/guides/compliance/what-is-soc2)にまとめています。規準と着眼点の文言は、日本公認会計士協会の翻訳(AICPA 2017 年版)によります。

## 着眼点の扱い

各規準には「着眼点」が付いています。規準を満たしているかを見るときの観点で、規準そのものではありません。翻訳の前書きは、着眼点が組織に合わなければ変えてよいとし、「各着眼点が対処されているかどうかの判定が必要となるわけではない」と書いています。満たすのは規準の文で、着眼点は自社の手続を組み立てるときの手がかりです。

AICPA は、着眼点を改訂した版を「2017 Trust Services Criteria (With Revised Points of Focus – 2022)」の題で公表しています。題のとおり、規準は 2017 年版のままで、改められたのは着眼点と読めます。一方、日本公認会計士協会の翻訳は、2018 年に公表した研究資料と同じ内容で、この改訂を含みません。以下で挙げる着眼点は、改訂前の翻訳によるものです。

## どの SaaS が対象になるか

翻訳の前書きは CC6.4 を例に、規準が当てはまるのは、SOC 2 の検証の範囲に入るシステムに関わる管理に限られると説明しています。CC6.1〜6.3 も同じように読めます。用語集では、システムは、サービスを提供するために一体で動く設備(サーバーやネットワーク)、ソフトウェア、人、手順、データを指します。そのため、自社のサービスそのものだけでなく、その運用に使う SaaS も範囲に入りえます。クラウドの管理画面、顧客からの問い合わせを扱うツール、提供中のサービスのデータに触れる管理ツールなどです。範囲は、経営者がまとめるシステムの記述書(検証の対象を説明する文書)で示されます。

## CC6.1 情報資産へのアクセスを仕組みで制限する

CC6.1 は、論理的なアクセス(ネットワークや画面を通じてシステムに入ること)の安全対策を導入し、セキュリティ上の出来事から情報資産を守ることを求めます。翻訳では着眼点が 10 あり、SaaS のアカウント管理に当てはめやすいのは次の 4 つです。

- 「情報資産の識別・台帳の作成・管理」: 守る対象を一覧にする
- 「論理的なアクセスの制限」: 管理者の権限を含むアクセスを、仕組みと決まりで制限する
- 「ユーザーの識別及び承認」: アクセスの前に、人を識別し承認する
- 「識別及び認証の管理」: 識別と本人確認の決まりを作り、文書にして管理する

SaaS に置き換えると、まず範囲に入る SaaS の一覧を作ります。次に、各 SaaS に誰の ID で入るかを決め、管理者の権限を使える人を限ります。ログインの方法(二段階認証を必ず使うか、Okta や Microsoft Entra ID のような ID 管理サービスを通すか)は、文書にした決まりとして示します。

## CC6.2 承認を得て ID を発行し、不要になれば消す

CC6.2 は、新しい利用者を登録・承認してから、ID やパスワードなどログインに使う情報(翻訳では「システム資格」)を発行することを求めます。アクセスが承認されなくなったら、それを削除します。社員だけでなく、外部の利用者も対象です。着眼点は次の 3 つです。

- 資産のオーナー(その SaaS の責任者)か、承認された管理者の許可を得て ID を作る
- もう要らなくなった ID を削除する手順を整える
- 付ける必要のない人に ID が付いていないかを、定期的に見直す

SaaS では、申請と承認の記録、削除の記録、見直しの記録がこれに当たります。見直しの頻度は規準に書かれていません。用語集は、システムに求められることの例として、次を挙げています。

> セキュリティポリシー・マニュアルに文書化された就業者の論理的アクセスの定期的なレビューとしての許容される最大の間隔

間隔は自社の規程で決め、その間隔どおりに見直したかが問われると読めます。

## CC6.3 役割に応じて権限を付け、変え、外す

CC6.3 は、役割や責任などに基づいて、組織がアクセスを承認し、変え、削除することを求めます。そのとき、最小権限の原則と職務分離(1 人で完結させない役割分担)を考えます。考え方は[最小権限の原則とは](/guides/access-basics/what-is-least-privilege)にあります。着眼点は次の 3 つです。

- 資産のオーナーの承認に基づいて、アクセスを作る・変える手順を整える
- もう要らなくなったアクセスを外す手順を整える
- 兼務できない職務を分けるために「役割ベースのアクセス管理」(役割ごとに権限の組み合わせを決めて付ける方法)を行う

CC6.2 が ID の有無を扱うのに対し、CC6.3 は ID に付ける権限の中身を扱います。SaaS には、閲覧・編集・管理者のような権限の種類を用意しているものがあります。職務ごとにどの種類を付けるかを表にしておけば、異動のときに外す権限と付ける権限がその表から決まります。管理者の権限を持つ人を絞り、権限を付ける人と付けてもらう人を分けることが、職務分離の一つの形です。

## 共有アカウントは 3 つの規準のどこで説明しにくくなるか

翻訳に「共有アカウント」の語はありません。ただ、1 つの ID を複数の人で使う状態([共有アカウント](/guides/shared-accounts/what-is-shared-account))では、3 つの規準のそれぞれで説明が難しくなります。CC6.1 の着眼点は、入る前に人を識別することを挙げています。共有の ID では、ログインの記録から分かるのは ID だけで、使った人は分かりません。CC6.2 では、1 人を外すにはパスワードを変えて、残る人に配り直すことになります。CC6.3 では、権限が ID に付くので、使う人全員に同じ権限が渡ります。

対応は 2 段になります。SaaS が人ごとの ID と権限の種類を用意しているなら、まず個人の ID に分けます。分けられない管理画面などは、3 つを決めます。使える人の一覧、使うたびに誰が使ったかを残す手段、人が抜けたときにパスワードを変える手順です。そのうえで、規準の文をどう満たすかを説明できるようにします。権限の絞り方は[最小権限の原則を SaaS の共有アカウントに当てはめる](/guides/access-basics/least-privilege-for-shared-saas-accounts)で扱っています。

## Type 2 の期間中に残しておく記録

Type 2 の報告書(期間を通じて運用を確かめる報告書)には、その期間を対象に監査人が行ったテストとその結果が載ります。手続を文書にするだけでなく、期間中に手続を実際に行ったことを示す記録を残しておくことになります。CC6.1〜6.3 について用意するものを、決め方の一例として挙げます。

1. 範囲に入る SaaS の一覧と、SaaS ごとの ID と権限の一覧。SaaS の一覧は CC6.1 の着眼点にある台帳に当たり、ID と権限の一覧は見直しの元になります。
2. ID の発行と権限の変更について、申請と承認の記録。CC6.2 と CC6.3 は、どちらも着眼点にオーナーの承認を挙げています。
3. 退職・異動の日と、ID や権限を外した日を並べた記録。承認されなくなったときに削除したことを示せます。
4. 規程で決めた間隔での見直しの記録。CC6.2 の定期的な見直しに対応します。

CC6.1〜6.3 の外にも、アカウントに関わる規準があります。CC6.6 の着眼点は、システムの境界の外から入るときに追加の認証を求めることを挙げています。CC7.2 の着眼点は、ID とパスワードなどの「識別及び認証資格の不正使用」で起きる異常を見つける対策を挙げています。共有アカウントでは誰が入ったかが記録に残らないため、正しい利用と不正な利用を記録から区別しにくくなります。


## よくある質問

**CC6 の着眼点はすべて満たす必要がありますか**

必要ありません。翻訳の前書きは、各着眼点に対処したかの判定は求められないとし、組織に合わせて変えてよいとしています。満たすのは規準の文で、着眼点は手続を組み立てる手がかりです。

**アクセスの見直しは何か月ごとに必要ですか**

規準にも着眼点にも頻度は書かれていません。用語集は、見直しの最大の間隔を自社の規程に書く例を挙げています。決めた間隔どおりに見直し、その記録を残します。

**共有アカウントがあると SOC 2 は受けられませんか**

規準に共有を禁じる文はありません。ただ、使った人の識別と、1 人だけ外す手順の説明が難しくなります。人ごとの ID に分けられる SaaS は分け、残るものは一覧と記録で補います。

**社内で使う SaaS はすべて対象ですか**

対象は検証の範囲に入るシステムに限られます。サービスの運用に使い、顧客のデータや、提供中のサービスの設定に触れる SaaS は範囲に入りえます。範囲はシステムの記述書で示します。

## 参考資料

- [日本公認会計士協会「セキュリティ、可用性、処理のインテグリティ、機密保持及びプライバシーに関する Trust サービス規準」(AICPA 2017 年版の翻訳、2022 年 12 月 28 日)](https://jicpa.or.jp/specialized_field/ITI/files/0-51-0-2a-20221228.pdf)
- [日本公認会計士協会「AICPA『セキュリティ、可用性、処理のインテグリティ、機密保持及びプライバシーに関する Trust サービス規準』の翻訳の公表について」](https://jicpa.or.jp/specialized_field/ITI/2022/20221228tzq.html)
- [AICPA & CIMA「2017 Trust Services Criteria (With Revised Points of Focus – 2022)」](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022)

## Junify の場合

**人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。

**Junify なら** 分けられない管理画面を共有のまま Type 2 の対象期間に入ると、誰かが抜けるたびにパスワードを変えて配り直し、誰が使ったかを表に手で書き足す作業が続きます。Junify では導入時にパスワードを変えて Junify だけが持ち、担当者はスマホで本人確認をして入ります。使える人の一覧と、誰が・いつ使ったかの記録は管理者の画面で確かめられ、抜けた人は割り当てを外すだけで入れなくなります。

Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。

- [登録不要の体験デモを見る](https://www.junify.jp/bpo/try)
- [30 分デモを予約する](https://www.junify.jp/bpo/demo)

## 同じテーマの記事

- [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。
- [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。
- [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。