クラウド基盤との連携

AWS、Microsoft Azure、Google Cloudなどのクラウド基盤をつなぐと、Drataがクラウドの構成を読み取り、インフラストラクチャーのセキュリティーのテストと証跡の収集を自動で続けます。このページでは、AWS、Microsoft Azure、Google Cloudとの連携として、読み取り専用の権限の付け方、複数のアカウントやサブスクリプションの扱い、不足した権限によるテストのエラーの直し方を説明します。

クラウド基盤との連携でできること

クラウド基盤との連携では、次のことができます。

• クラウド基盤の構成を継続的にモニタリングする
• 自動化されたコントロールの証跡を集める
• ロールやアクティビティーのデータで、アクセスレビューを支える

どのクラウドでも、Drataは読み取り専用のアクセスでデータを集め、リソースを変更しません。連携に使う仕組みと、Drataが勧める既定の権限は次の通りです。

クラウド	連携に使う仕組み	既定の権限
AWS	Drataが引き受けるIAMロール（DrataAutopilotRole）。信頼ポリシーと外部ID（External ID）で、Drataだけが引き受けられるようにする	AWS管理ポリシーのSecurityAudit
Microsoft Azure	Microsoft Entra IDに登録したアプリ（Drata Entra App）と、そのサービスプリンシパル	Microsoft Graphのアプリケーションの権限（User.Read.All、Reports.Read.All、Directory.Read.All、Policy.Read.All、AuditLog.Read.All）と、サブスクリプションのReaderロール
Google Cloud	Drataを表すサービスアカウント	監視、コンピューティング、資産などの閲覧のロール（Monitoring Viewer、Compute Viewer、Cloud Asset Viewer、Browserなど）

Microsoft Azureとの連携はクラウド基盤の連携で、Azureのリソースへのアクセスのレビューに使います。Microsoftの環境の要員の同期は、IDプロバイダーの連携（Microsoft 365との連携）で行います。詳しくはIDプロバイダーとの連携で説明します。

読み取り専用の権限の付け方

AWS

AWSとの連携は、ConnectionsのAvailableタブでAWSを選んで始めます。設定は、設定の選択、連携、範囲の設定の3段階で進みます。連携できるのは、Admin、Information Security Lead、DevOps Engineer、Workspace Managerのロールのユーザーです。

1. 最初の段階で、関連付けるワークスペースと、使う機能を選びます。クラウド基盤の機能は既定で有効です。アクセスレビューに使う場合や、AWS IAM Identity Centerを使っている場合は、それぞれを有効にします。
2. AWSのマネージメントコンソールで、IAMのロールを作ります。信頼するエンティティーにAWS accountのAnother AWS accountを選び、Drataの接続の画面に表示されるDrataのアカウントIDを入れます。
3. Require external IDを選び、Drataの接続の画面に表示される自社の外部IDを入れます。
4. 権限のポリシーにSecurityAuditを付けます。
5. ロールの名前をDrataAutopilotRoleにして作ります。
6. 作ったロールのARNをコピーし、Drataの接続の画面のRole ARNの欄に貼り付けます。
7. 範囲の設定で、対象のリージョンとリソースを選びます。

範囲の設定では、次のことを決めます。

設定	内容
リージョン	制限がなければAll regionsを選ぶ。サービスコントロールポリシー（SCP）でリージョンを制限している場合は、Specific regionsで許可されたリージョンを選ぶ。選ばないとテストがエラーになることがある
リソース	Specific resourcesを選ぶと、タグ（一致）か名前（一致、含む、含まない、前方一致、後方一致）の条件で、取り込むリソースを絞れる。条件に合うものを含める（In scope）か、外す（Out of scope）かを選ぶ

リソースの範囲の設定は、保存した後の次の同期から、AWSを使うテストの評価と、Assetsページに取り込まれる資産に効きます。

AWS IAM Identity Centerを使っている場合、Drataは外部のIDプロバイダーからSCIMで同期されたデータを読み取ります。Identity Centerのディレクトリーだけを使う構成には対応していません。

【注意】 AWS Backupのバックアップの状態を確かめるテストなど、一部のテストにはSecurityAuditに含まれない権限が必要です。権限が足りないまま実行すると、テストがエラーになります。必要な権限は、DrataAutopilotRoleにインラインポリシーとして加えます。

Microsoft Azure

Microsoft Azureとの連携には、Microsoft Entra IDのGlobal Administratorのロールと、Readerロールを割り当てられるサブスクリプションへのアクセスが必要です。

1. Microsoft Entraの管理センターで、新しいアプリを登録します。名前はDrata Entra App、サポートするアカウントの種類はこの組織のディレクトリーだけにし、リダイレクトURLは空欄にします。
2. アプリケーション（クライアント）IDとディレクトリー（テナント）IDをコピーします。
3. Certificates & secretsでクライアントシークレットを作ります。有効期限は24カ月にします。コピーするのはシークレットのIDではなく値です。作った後にページを再読み込みしてから使います。
4. API permissionsで、Microsoft Graphのアプリケーションの権限を5つ加え、Grant admin consentで管理者の同意を与えます。
5. サブスクリプションのAccess control (IAM)で、Drata Entra AppにReaderロールを割り当てます。
6. Drataの接続の画面に、テナントID、アプリケーションID、クライアントシークレットの値、サブスクリプションIDを入れます。

Drataに同期する人は、全員（Everyone）か、特定のグループ（グループのオブジェクトID）で選びます。グループの直下のメンバーは1人ずつ同期されますが、入れ子のグループは1つとして同期され、その中のメンバーは同期されません。複雑な条件で絞る場合は、Microsoftの動的グループを使います。

【注意】 クライアントシークレットの有効期限が切れると、連携が切れます。期限の前に作り直せるように、リマインダーを設定しておきます。

Google Cloud

Google Cloudとの連携は、Drataが用意するスクリプト（シェルかTerraform）でつなぐ方法が勧められています。手作業でつなぐこともできます。

決めること	内容
つなぐ範囲	組織の単位でつなぐと、1回の設定で全てのプロジェクトが対象になる（勧められる方法）。プロジェクトの単位でつなぐ場合は、プロジェクトごとに設定を繰り返す
スクリプトを実行するユーザー	Organization Administrator、Organization Policy Administrator、Organization Role Administrator、Service Account Admin、Service Account Key Admin、Service Usage Adminのロールが必要
有効にするAPI	Compute Engine、Cloud Resource Manager、Admin SDK、Cloud SQL Admin、Cloud Monitoring、Cloud StorageなどのAPI。有効にしないと、関係するテストがデータを取れずに失敗する

スクリプトで作ったサービスアカウントのJSONの鍵をDrataにアップロードします。また、Google WorkspaceのSuper Adminのアカウントで、サービスアカウントにドメイン全体の委任（domain-wide delegation）を与えます。委任には、サービスアカウントの数字のクライアントIDと、読み取り専用のスコープを使います。

【注意】 ドメイン全体の委任を与えないと、DrataはGoogle CloudのIAMのユーザーの多要素認証の状態を読み取れず、インフラストラクチャーのコンソールの多要素認証を確かめるテストが失敗します。Google Workspaceとの連携を既に使っている場合は、委任の一覧にある既存の項目を消さないでください。IDプロバイダーの連携が切れます。

複数のアカウントやサブスクリプションの扱い

AWSの組織単位

複数のAWSアカウントを使っている場合は、連携の設定でUsing AWS Organizational Unitsを有効にします。組織の中のアカウントをDrataが自動で見つけ、モニタリングの対象にします。1つの連携で扱えるのは350アカウントまでです。

この方法では、管理アカウントと、モニタリングする全てのメンバーアカウントに、同じDrataAutopilotRoleを作ります。Drataの接続の画面に入れるのは、管理アカウントのロールのARNと、AWS OrganizationsのルートのID（r-で始まる）です。

ロールの作り方	向く場面
コンソールで1つずつ作る	アカウントが少ない組織
Terraformのモジュールでアカウントごとに作る	Terraformを使っていて、細かく管理したい組織
TerraformとCloudFormationのStackSetsで作る	アカウントが多く、Terraformを使っている組織
コンソールでCloudFormationのStackSetsを作る	アカウントが多く、Terraformを使っていない組織

【注意】 CloudFormationのStackSetsは、管理アカウントにはロールを作りません。管理アカウントのロールは、コンソールかTerraformで別に作ります。管理アカウントにロールがないと、連携は失敗します。

対象のアカウントは、接続の画面の範囲の設定で選ぶほか、AWSのアカウントにDrataExclude（値はtrue）のタグを付けて外したり、DrataIncludeのタグを付けて明示的に含めたりできます。

Azureの管理グループ

複数のAzureのサブスクリプションを使っている場合は、連携の設定でUsing Azure Management Groupsを有効にします。サブスクリプションを管理グループにまとめ、管理グループに対してDrata Entra AppのReaderロールを割り当てると、配下のサブスクリプションに読み取りの権限が及びます。モニタリングするサブスクリプションは、接続の画面の範囲の設定で選びます。

サブスクリプションにDrataIncludeかDrataExcludeのタグを付けて、対象を動的に増減させることもできます。なお、管理グループの連携には、カスタムテストを作れません。

Google Cloudのプロジェクト

組織の単位でつなぐと、組織の全てのプロジェクトが対象になります。プロジェクトの単位でつなぐ場合は、各プロジェクトが組織に属している必要があります。

ワークスペースを使っている場合、クラウド基盤の連携は、ワークスペースごとに関連付けられます。詳しくはワークスペースの設計で説明しています。

不足した権限によるテストのエラーの直し方

クラウド基盤を使うテストがエラーになった場合、多くは、Drataに与えた権限が足りないことが原因です。例えばAWSでは、AccessDeniedのエラーになります。新しいサービスを使い始めたときや、テストを追加したときにも起こります。

1. Compliance → Monitoringで、ErrorかFailedに絞り込み、該当するテストを開きます。
2. OverviewタブのLatest resultか、Findingsタブの生のJSONの出力で、足りない権限を確かめます。OverviewタブのDetailsのView instructionsを選ぶと、テストに必要な権限の案内が表示されます。
3. クラウドの側で、Drataが使っているIDを探し、権限を加えます（次の表）。
4. 権限を制限するほかの仕組みが、加えた権限を止めていないかを確かめます。
5. Drataに戻り、テストを実行し直します。

クラウド	Drataが使うID	権限の加え方	止めていないか確かめる仕組み
AWS	連携の詳細の画面に表示されるIAMロールのARN	ロールに付けたポリシーに、必要な操作を加える。SecurityAuditが付いていなければ、まず付ける	SCP、アクセス許可の境界
Microsoft Azure	Drata Entra Appのアプリとサービスプリンシパル	ディレクトリーのデータはMicrosoft Graphのアプリケーションの権限、サブスクリプションのリソースはAzureのロールの割り当て（RBAC）で加える。間違った場所に加えても直らない	管理グループのポリシー、Azure Policy、カスタムロールの定義
Google Cloud	Drataのサービスアカウント	サービスアカウントに割り当てたカスタムロールに、必要な権限を加える。必要なAPIが有効かも確かめる	組織のポリシー

クラウドを直接操作する権限がない場合や、Infrastructure as Codeで管理している場合は、インフラの担当者に依頼します。依頼には、DrataのロールやアプリやサービスアカウントのID、加える権限、依頼のもとになったテスト、加える場所を書きます。

【運用のポイント】 権限は、Drataの既定の権限から始め、エラーになったテストやサービスに必要なものだけを加えます。エラーを早く消そうとして、全ての操作を許すような広い権限や管理者のロールを与えないでください。ほかにもエラーのテストがないかをあわせて確かめると、権限の追加を一度で済ませられます。

対象のアカウントを確かめる

ConnectionsのManage accountsのInfrastructureでは、クラウド基盤から見つかったアカウントを確かめられます。

Manage Infrastructure Accountsの画面。Syncのメニューで、全ての連携先か、絞り込んだ連携先を同期し直せる

項目	内容
要員への対応付け	同期した直後のアカウントは、要員に対応付けられていないことがある。対応付けると、誰がクラウド基盤にアクセスできるかを正しく追える
Access revoked	クラウドの側でアカウントを削除しても、Drataからは消えず、アクセスがなくなった日時が記録される。アクセスの削除が期限内だったことを、監査で示せる
データベースや管理者のアクセス、多要素認証	連携先から読み取った状態が表示される。Drataでは変えられず、変えるときはクラウドの側で設定する

クラウドの側で変更してから、Drataに反映されるまで、最長で24時間かかることがあります。アカウントと要員の対応付けは、アカウントと要員の対応付けで説明します。