Drataの自動化を支えているのは、社内で使っているシステムとの連携です。連携をつなぐと、Drataが各システムから情報を集め、証跡の収集とテストを自動で続けられるようになります。このページでは、Drataの連携の全体像として、連携で自動的に集まる情報、連携の種類と優先順位、Connectionsページの見方、連携に使うアカウントの権限を最小限にする考え方を説明します。
連携で自動的に集まる情報
コンプライアンスの要求事項の多くは、Drataの外にある情報に左右されます。誰がどのシステムにアクセスできるか、どの社員が対象になるか、クラウド基盤がどう設定されているか、規程や手順が守られているか、といった情報です。
連携をつなぐと、Drataは次のことができるようになります。
- 各システムから情報を直接取り込む
- 要求事項を、ある時点だけでなく継続的に確かめる
- 不備やリスクを、起きた時点で示す
連携と、フレームワーク、コントロール、テスト、証跡の関係は次の通りです。
| 要素 | 役割 |
|---|---|
| フレームワーク | 何の基準を満たすかを決める |
| コントロール | 要求事項をどう満たすかを決める |
| テストと証跡 | コントロールが意図通りに運用されているかを確かめる |
| 連携 | テストと証跡が使うシステムのデータを提供する |
連携がなくてもDrataは使えますが、その場合は証跡を手作業でアップロードしたり、継続的なモニタリングの代わりに定期的な確認に頼ったりする部分が増えます。連携をつなぐと自動化の度合いは上がりますが、コンプライアンスの結果は、連携の有無ではなく、そのシステムをどう使っているかで決まります。また、考えられる全てのシステムをつなぐ必要はありません。
連携の種類
Drataの連携は、つなぐシステムの種類ごとにカテゴリーに分かれています。主なカテゴリーは次の通りです。
| カテゴリー | 主な連携先 | 集まる情報 |
|---|---|---|
Identity | Okta、Microsoft 365、Google Workspaceなど | 要員、グループ、多要素認証の設定 |
HRIS | 人事システム | 入社日、退職日、雇用状態 |
Infrastructure | AWS、Microsoft Azure、Google Cloudなど | クラウド基盤の構成とアカウント |
Version control | GitHub、GitLab、Bitbucketなど | リポジトリーの設定とアカウント |
Ticketing | Jiraなど | セキュリティーの課題のチケット |
MDM | Jamf、Microsoft Intune、Kandjiなど | 端末の設定 |
Vulnerability | 脆弱性スキャンの製品 | 脆弱性の検出事項 |
このほかに、Background check、Codebase、Communication、CRM、CSPM、Custom、Cyber insurance、Digital signature、EDR、Enterprise SSO、External policy、Observability、Security reviews、Security training、User access review、Automation toolsなどのカテゴリーがあります。表示されるカテゴリーは、プランとフレームワークによって増減します。
連携は、提供のされ方でも次の3つに分かれます。
| 提供のされ方 | 内容 |
|---|---|
| 標準の連携 | Drataが用意する連携。APIトークン、クライアントシークレット、OAuthの認証情報などでつなぎ、データを自動で同期する |
| パートナーの連携 | パートナーが作り、Drataの外で管理する連携。カスタムのスコープを付けたDrataのAPIキーでつなぎ、パートナーのツールから証跡をDrataに送る。Drataの自動のテストは使えない |
| カスタム連携 | 標準の連携がないシステムのデータを、JSONの形でDrataに送る連携。カスタム連携で説明する |
ワークスペースを使っている場合、クラウド基盤、オブザーバビリティー、課題管理、バージョン管理、コードベース、CSPM、脆弱性、カスタムの連携は、設定するときに関連付けるワークスペースを選べます。そのほかの種類の連携は、全てのワークスペースに共通です。詳しくはワークスペースの設計で説明しています。
連携の優先順位
ヘルプセンターでは、多くの組織が次の順序で連携をつなぐとしています。アクセスの管理、資産の範囲、日々の運用の流れを早い段階で固めるためです。
- IDプロバイダー
- クラウド基盤
- バージョン管理
- 課題管理
【運用のポイント】 IDプロバイダーは最初につなぎます。Drataは、IDプロバイダーをもとに要員の一覧を作り、社員のサインインもIDプロバイダーの連携が前提になります。人事システムとの連携も、IDプロバイダーの連携の後に設定します。
Quick Startでの進め方はQuick Startで初期設定を進める、部署を巻き込んだ連携の進め方は導入の流れと体制で説明しています。
Connectionsページの見方
連携の追加と管理は、左側のナビゲーションのConnectionsで行います。
Connectionsページ。左側にManage accountsの区分、右側にAvailableタブの連携の一覧が並ぶ
| 項目 | 内容 |
|---|---|
Activeタブ | 有効にした連携の一覧。連携ごとに、編集、更新、切断ができる |
Availableタブ | 組織で追加できる全ての連携の一覧。カテゴリーごとに分かれている |
Manage accounts | 連携で取り込んだアカウントを確かめる区分。Access Reviews、Background Checks、Infrastructure、Observability、Version Controlのページがある |
連携をつなぐ手順は連携ごとに異なり、ヘルプセンターの連携ごとの記事に、必要な権限と手順が書かれています。
連携の状態を確かめる
Activeタブでは、連携ごとに同期の状態が表示されます（Connection Insights）。
| 状態 | 意味 |
|---|---|
Healthy | 同期の全ての段階が成功している |
Unhealthy | 同期のいずれかの段階でエラーが起きている |
Operational statusのフィルターでUnhealthyに絞り込むと、対応が必要な連携を探せます。
Activeタブ。左側のOperational statusでHealthyとUnhealthyを絞り込め、連携ごとに状態が表示される
連携を選ぶと詳細の画面が開き、Overviewタブの上部のSync statusで、同期の段階ごとの結果を確かめられます。連携がUnhealthyのときは、AIの要約（AI Summary）が表示され、失敗した段階の説明と、直し方の提案が示されます。要約を作った後に新しい同期のデータが記録されると、要約は自動で無効になり、Generate summaryで作り直せます。Refreshを選んで、最新の同期のデータで作り直すこともできます。
Unhealthyの連携の詳細の画面。Sync statusにAIの要約が表示され、右側に関係するコントロールとテストの数が並ぶ
【注意】 同期の状態は、リアルタイムには更新されません。最新の状態はページを再読み込みして確かめます。また、この機能が有効になる前に設定を誤っていた連携は、設定し直して新しい同期が済むまで、同期の段階のデータが表示されないことがあります。
手動で同期し直す
Drataは、連携先のデータを定期的に自動で同期します。連携先でユーザーの追加や削除、入社や退職の手続きをした直後に、すぐDrataに反映させたいときは、手動で同期し直せます。手動の同期はAdminロールのユーザーが行えます。
| 同期し直す場所 | 操作 | 対象 |
|---|---|---|
Governance → Personnel | 一覧の右上の「…」のメニューでResync Personnelを選ぶ | IDプロバイダー、クラウド基盤、バージョン管理、セキュリティー研修など、該当する連携全て |
Manage accountsの各ページ | Syncを選び、All providersかSelected providerを選ぶ | その種類の連携のアカウント。Access Reviews、Infrastructure、Observabilityのページだけで使える |
同期の開始と完了は画面に表示され、完了したときにはメールでも知らされます。
【注意】 連携先での変更は、連携先のAPIの事情で、Drataに反映されるまで最長で24時間かかることがあります。また、多要素認証や退職者のアカウントの削除を確かめるテストなど、毎日のデータの同期に左右されるテストは、
Test nowで実行し直しても、同期が済むまで結果が変わらないことがあります。
連携に使うアカウントの権限を最小限にする
多くの連携は、連携先のシステムへの読み取り専用のアクセスで足ります。Drataは証跡を集めるだけで、連携先のシステムを変更しません。アクセスは多くの場合、連携先で作るサービスアカウントや、連携専用のユーザーを通じて与えます。
サービスアカウントには、次の利点があります。
- 特定の社員ではなく、Drataが使うアカウントになる
- 担当者が異動や退職をしても、有効なまま残る
- 証跡を集めるのに必要な権限だけに絞れる
連携の作業では、連携先でサービスアカウントを作る管理者の権限、DrataのAdminロール、ITやセキュリティーの部署の承認、APIのアクセスや認証のトークンが必要になることがあります。Drataが連携先の完全な管理者の権限を求めることはありませんが、必要な権限は連携ごとに異なります。
【運用のポイント】 権限は最小権限の原則で与えます。Drataが勧める既定の権限から始め、特定のテストやサービスに必要な権限だけを加えます。全ての操作を許すような広い権限や、完全な管理者のロールは与えません。クラウド基盤での具体的な権限の付け方は、クラウド基盤との連携で説明します。
社内でWAFやファイアウォールを使っている場合、一部の連携では、DrataのIPアドレスを許可する必要があります。詳しくはネットワークとメールの許可設定で説明しています。