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

SOC 2 の検証で使う Trust サービス規準には、「論理的及び物理的アクセス管理」の項目群(CC6)があります。そのうち CC6.1〜6.3 が、システムに入れる人とその権限を扱います。社内で使う SaaS に置き換えると、使える人の一覧、ID の発行と削除の手続、権限の種類と見直しの 3 つです。SOC 2 の仕組みそのものは SOC 2 とはにまとめています。規準と着眼点の文言は、日本公認会計士協会の翻訳(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 人で完結させない役割分担)を考えます。考え方は最小権限の原則とはにあります。着眼点は次の 3 つです。

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

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

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

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

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

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 とパスワードなどの「識別及び認証資格の不正使用」で起きる異常を見つける対策を挙げています。共有アカウントでは誰が入ったかが記録に残らないため、正しい利用と不正な利用を記録から区別しにくくなります。