すべての監査人が納得するユーザーアクセスレビュー

アクセスレビューほど普遍的で、かつ失敗の多い統制は多くありません。すべてのフレームワークは、各ユーザーが現在もそのアクセス権を必要としているかを、定期的に確認することを求めています。大半の組織はレビューを実施しています。しかし、そのレビューが網羅的で、独立しており、結果に基づいて対応されたことを監査人に示せる組織は、はるかに少ないのが実情です。

フレームワークの要件

フレームワーク	アクセス制御	リンク
NIST CSF 2.0	PR.AA-01PR.AA-05	トピックの定義
ISO 27001	A.5.15A.5.16A.5.18A.8.3	対応表
CIS v8.1	CIS 5.1CIS 6.1CIS 6.2CIS 6.7CIS 6.8CIS 3.3CIS 5.2CIS 5.3CIS 5.5CIS 5.6CIS 6.6CIS 12.5	対応表
SOC 2	CC6.1CC6.2CC6.3	編集
PCI DSS	7.2.17.2.27.2.48.2.1	対応表
CMMC	AC.L2-3.1.1AC.L2-3.1.2	対応表
800-53	AC-2AC-3	対応表
HIPAA	§164.308(a)(4)§164.312(a)§164.312(a)(2)(i)§164.312(d)	対応表
GDPR	Art.25(2)Art.32(1)(b)	編集
NIS2	11.111.211.5	対応表
Essential Eight	—	当サイトのデータにはマッピングがありません

各リンクの詳細と根拠： アクセス制御 のフレームワーク横断 →

PCI DSSは、頻度が固定されている唯一のフレームワークです。すべてのユーザーアカウントと権限を少なくとも6か月ごとにレビューし（7.2.4）、アプリケーションおよびシステムアカウントも同様にレビューします（7.2.5.1）。SOC 2の監査人は、アクセス権が適切に承認、変更、削除されているかを検証し（CC6.2、CC6.3）、証拠として定期的なレビューの有無を確認します。ISO 27001は、アクセス権を一定の間隔でレビューすることを求めています（A.5.18）。HIPAAは、情報アクセス管理とアクティビティのレビューを求めています（§164.308(a)(4)）。CMMCは、アクセスを認可されたユーザーと機能に限定すること、および最小権限の原則を求めています（AC.L2-3.1.1、3.1.2）。

合格するレビューの進め方

1. 対象の網羅性。 ユーザー一覧はシステムから直接取得してください（担当者が保守するスプレッドシートではなく、エクスポートしたデータを使用）。サービスアカウントと共有アカウントも含めます。
2. 適切なレビュー担当者。 システムまたはデータの所有者、もしくは各ユーザーの上長とし、アクセス権を付与した管理者は避けてください。
3. 十分な文脈情報。 各ユーザーの役割とアクセスレベルをレビュー担当者に提示し、「承認」が十分な情報に基づく判断になるようにします。
4. アカウントごとの判断。 維持、変更、削除のいずれかを、レビュー担当者の氏名と日付とともに記録します。
5. 変更の実施。 削除についてはチケットを起票し、完了の証跡を保管します。
6. 証跡の保管。 エクスポートデータ、判断結果、チケット、承認記録を一括して保管します。

頻度

対象となるすべてのシステムについて、PCI DSSの6か月を基準としてください。また、特権アクセスは四半期ごとにレビューしてください。SOC 2 Type IIを取得している場合は、各観察期間に少なくとも1回（できれば2回）のレビューが含まれるようにしてください。

監査人が指摘しがちな問題

• 形式的な承認：数分ですべてのアカウントを、判断の根拠を持たない人が承認している状態です。
• 対象の不備：アプリケーションはレビューされたがデータベースは対象外、または人間のアカウントはレビューされたがサービスアカウントは対象外。
• 自己承認：管理者が自身のアクセス権を承認している。
• 削除の未完了：レビューで削除と判断されたのに、数か月後もアカウントが残っている。
• レビューで発覚する離職者：オフボーディングのプロセスが機能していない兆候であり、監査人は別途その統制を検証します。

重要なポイント

• アクセスレビューが監査で不合格となるのは、努力不足ではなく証跡の不備によるものです。対象の不備、自己承認、未完了の削除などが典型例です。
• システムからのエクスポート、適切なレビュー担当者、アカウントごとの判断、変更の証跡を用いてください。
• 6か月ごとのレビュー（PCI DSSの規定）と、特権アクセスの四半期レビューを行えば、すべてのフレームワークの要件を満たせます。
• 対象範囲は重要なシステムに絞り、作業の仕組みは自動化してください。

持続可能な運用に向けて

エクスポートとリマインダーを自動化し、ユーザー単位ではなくシステム単位でレビューを行い、対象範囲は重要なシステムに絞ってください。対象は、本番環境、顧客データ、特権ツール、そしてフレームワークの適用範囲に含まれるものです。対象が小さくても証跡がしっかり残るレビューの方が、範囲が広く常に期限に遅れるレビューよりも優れています。

詳細な要件とその出典については、アクセス制御および特権アクセスのトピックページをご覧ください。また、SOC 2、ISO 27001、PCI DSSにまたがる証跡の再利用に関するブログ記事もあわせてご覧ください。

よくある質問

ユーザーアクセスはどのくらいの頻度でレビューする必要がありますか？

PCI DSSでは、ユーザーアカウントとアクセス権限を少なくとも6か月ごとにレビューすることが求められています（7.2.4）。その他の多くのフレームワークでは、定期的なレビューを求めていますが、頻度は組織が定めることになっています。特権アクセスは四半期ごと、その他は6か月ごとというのが一般的な基準です。

アクセスレビューは誰が実施すべきですか？

システムまたはデータの所有者、もしくはユーザーの上長です。アクセス権を付与した管理者は除きます。監査人は、独立性があり、十分な情報をもつレビュー担当者であるかを確認します。

サービスアカウントにもアクセスレビューは必要ですか？

はい。監査人はサービスアカウント、共有アカウント、APIアカウントをレビュー対象に含める傾向が強まっています。PCI DSSでも、アプリケーションアカウントおよびシステムアカウントの定期的なレビューが明示的に求められています（7.2.5.1）。