アクセスレビューは、各システムにアクセスできる人とその権限が、今の役割に見合っているかを定期的に確かめる作業で、日本の実務の「アクセス権の棚卸し」に当たります。Drataでは、連携したアプリのアクセスの情報をAccess Reviewsページに集め、アプリごとにレビュー担当者が確かめ、完了した記録を証跡として残します。このページでは、アクセスレビューを始める前に決めておくこととして、使うための条件、対象とするアプリの選び方、レビュー担当者の決め方、頻度、連携で自動的に権限を取り込めるアプリの確認方法を説明します。
使うための条件
| 条件 | 内容 |
|---|---|
| 契約 | ユーザーアクセスレビュー（UAR）は、FoundationとAdvancedのプランでは追加の機能で、Enterpriseのプランには含まれる |
| 連携 | OktaやMicrosoftなどのIDプロバイダーとの連携が正しく設定され、同期に成功している |
ユーザーアクセスレビューを有効にするには、正規販売代理店（デジタルアクセルズ）にご相談ください。Access Reviewerのロールも、ユーザーアクセスレビューが有効になっている場合に使えます。IDプロバイダーとの連携は、IDプロバイダーとの連携で説明しています。
Access Reviewsページの構成
アクセスレビューは、Governance → Access Reviewsで行います。ページには次の3つのタブがあります。
| タブ | 内容 |
|---|---|
Applications | 連携したアプリから同期した最新のアクセスの情報。データは毎晩更新される。必要に応じてアプリを手動で追加できる |
Active Review | 実施中のレビュー期間。アプリごとのレビューの進み具合を追う。実施中にできるレビュー期間は1つだけ |
Completed Reviews | 完了したレビュー期間。ダウンロードできる証跡のパッケージと、レビュー担当者や完了の情報が表示される |
対象とするアプリを選ぶ
アクセスレビューの対象は、レビュー期間を作るときにアプリごとに選びます。候補になるのは、Applicationsタブに表示される、連携から取り込んだアプリと、手動で追加したアプリです。ヘルプの手順の例では、監査の対象範囲のシステムとサービスをレビューの対象にしています。
自動で検出されないアプリは、手動で追加すればレビュー期間に含められます。手動での追加と利用者の一覧の取り込みは、連携していないアプリのレビューで説明します。
連携で権限を取り込めるアプリを確かめる
Connectionsページの連携には、ユーザーアクセスレビューの区分があります。この区分の連携で取り込んだアカウントは、ConnectionsのManage accountsのAccess Reviewsのページで管理します。IDプロバイダーを通じてほかのアプリの権限を取り込めるかどうかは、連携先によって異なります。
| 連携 | 取り込む情報 | 確かめること |
|---|---|---|
| Oktaとの連携（ユーザーアクセスレビュー） | Oktaのユーザー、グループ、ロールの割り当て | 先にOktaのIDプロバイダーとの連携が必要。Oktaとつないでいても利用者のデータを渡さないアプリがあるため、OktaがプロビジョニングできるアプリかをOktaのOkta Integration Networkで確かめる。SSOのプロビジョニングの設定によっては、表示されないアプリがある |
| Microsoft 365との連携 | AzureのMicrosoft Entraのアプリケーション（通常はEnterprise Applicationsにある）から、アクセスレビューの対象のアプリを取り込む | 自動で取り込めるアプリを、AzureのAzure Application Galleryで確かめる。ユーザーの属性は、AzureでのSSOのアプリの設定によって決まり、全てのアプリで得られるとは限らない。Microsoft 365 GCC Highにも対応している |
| Google Workspaceとの連携（ユーザーアクセスレビュー） | Google Workspaceのユーザー、管理者の権限、グループのメンバー | Google APIが、つないだアプリのSCIMに対応していないため、ほかのアプリのアクセスは取り込めない。Google管理コンソールの権限を持つユーザーだけが、管理者として表示される |
Oktaの外で、アプリに直接アクセスを付けている場合は、Oktaから見える範囲が限られます。そうしたアプリは、利用者の一覧を手動でアップロードするか、Drataとの直接の連携があればそれを使います。Microsoft 365の外でアクセスを付けている場合も、利用者のデータを手動でアップロードできます。ヘルプセンターには、AWS、Salesforce、Slackなど、アプリごとのユーザーアクセスレビューの連携の手順の記事があります。
連携から取り込まれたアカウントは、Oktaの場合、ConnectionsページのOktaのタイルでManage Accountsを選んで、同期されているかを確かめます。連携先での変更をすぐに反映したいときは、Manage accountsのAccess ReviewsのページのSyncで同期し直します。アカウントと要員の対応付けは、アカウントと要員の対応付けで説明しています。
【注意】 Google Workspaceとの連携（ユーザーアクセスレビュー）を削除すると、その連携に関係するデータも全て削除されます。アクセスレビューの記録も含まれます。
レビュー担当者を決める
レビュー担当者は、レビュー期間を作るときに、アプリごとに割り当てます。レビュー担当者には、Access ReviewerかAdminのロールが必要です。手動で追加したアプリは、追加するときにレビュー担当者を入力します。
| ロール | できること |
|---|---|
Access Reviewer | ユーザーのアクセスが適切か、最小権限になっているかを確かめる。Access Reviewsページと、Connectionsページ（閲覧だけ）を使える |
Read-only Access Reviewer | アクセスレビューとアプリを閲覧する |
ロールの割り当ては、ロールと権限の設計で説明しています。
【運用のポイント】 ヘルプの手順の例では、レビュー担当者は、その人がシステムやサービスにアクセスできることが役割に照らして適切か、システムやサービスの中での権限が役割に照らして適切か、という2つの観点でアクセスを確かめます。
頻度とレビュー期間
Drataのアクセスレビューは、年に1度のアクセス管理のレビューの証跡を作ることを想定しています。レビュー期間が完了すると、証跡がコントロール「DCF-11: Annual Access Control Review」に自動で付き、証跡の更新期限は既定で完了日の1年後に設定されます。
レビュー期間には、開始日と終了日を設定します。実施中にできるレビュー期間は1つだけです。
【注意】 Drataは、レビュー期間の中のアクセスの情報をスナップショットとして残しません。表示されるのは、レビューを行う日の時点のアクセスです。例えば、レビュー期間を4月1日から6月30日にして、7月5日にレビューを完了すると、7月5日の時点のアクセスを見ることになります。
ワークスペースを使っている場合、証跡が作られるのは主ワークスペースだけです。ほかのワークスペースでも必要な場合は、証跡を手作業でコピーします。ワークスペースは、ワークスペースの設計で説明しています。
アクセスレビューの手順の例
ヘルプセンターでは、監査の対象範囲のシステムを対象にしたアクセスレビューの進め方として、次の手順を例に挙げています。
- 担当の部署やチームが、社内の課題管理のシステムにチケットを作って、アクセスレビューを始めます。
- 担当の部署やチームが、対象のシステムとサービスにアクセスできるユーザーを、上の2つの観点でレビューします。
- 最小権限の原則に沿わないアクセスが見つかったら、アクセスを変えるためのチケットを作り、変更をユーザーに知らせます。同じ問題が繰り返し起きる場合や重大な問題の場合は、原因を調べて再発を防ぎます。
- システムやサービスごとに、レビューしたユーザーの一覧かスクリーンショットをチケットに添付します。
- 対象の全てのシステムとサービスのレビューが済んだら、チケットを閉じます。
Drataでレビューを進める手順は、アクセスレビューの実施で説明します。