IDプロバイダーは、Drataで最初につなぐ連携です。Drataは、IDプロバイダーから取り込んだユーザーをもとに要員の一覧を作り、社員のサインインやアクセスの管理のテストもIDプロバイダーの情報を使います。このページでは、Okta、Microsoft Entra ID、Google WorkspaceなどのIDプロバイダーとの連携として、要員の情報の取り込み、多要素認証の確認、アクセスレビューへの利用を説明します。
IDプロバイダーとの連携の役割
IDプロバイダーとの連携は必須です。つなぐと、次のことができるようになります。
| できること | 内容 |
|---|---|
| 要員の情報の取り込み | 名前、メールアドレス、アバター、アカウントの情報を取り込み、要員の記録を作る |
| サインイン | 社員がDrataにサインインできるようになる。シングルサインオン（SSO）の設定も、IDプロバイダーをつないだ後に行う |
| アクセスの管理のテスト | IDプロバイダーの多要素認証（MFA）や、社員ごとに固有のメールアドレスがあるかを確かめるテストに使う |
IDプロバイダーだけをつないだ場合、取り込んだユーザーは、既定で在籍中の従業員（Current employee）として扱われます。ただし、admin@やinfo@のように、人ではないことが明らかな別名のアドレスは除かれます。入社日、退職日、業務委託者かどうかを正確に扱うには、人事システムもつなぎます。詳しくは人事システムとの連携で説明します。
連携の作業は、Admin、Workspace Manager、DevOps Engineerのロールのユーザーが行えます。Access Reviewerのロールのユーザーは、Connectionsページを見るだけです。
主なIDプロバイダーのつなぎ方
ConnectionsのAvailableタブでIdentityのカテゴリーに絞り込み、つなぐIDプロバイダーを選びます。Okta、Microsoft 365、Google Workspaceのほか、JumpCloud、OneLogin、PingOneなどがあります。
Okta
Oktaとの連携では、Oktaの側で次の準備をします。
Directory→Profile Editorで、ユーザーのプロファイルのメールアドレスの項目が、少なくとも読み取り専用（Read Only）になっているかを確かめます。隠す設定になっていると、Drataはメールアドレスを読めず、要員の同期とサインインができません。- Oktaの組織のドメインをコピーします。
- 連携に使うサービスアカウントを作り、
Read-only Administratorのロールを割り当てます。 - サービスアカウントでサインインし、APIトークンを作ります。トークンは作ったときにしか表示されないため、安全な場所に保管します。
- アプリのカタログから
Drata – OIDCのアプリを入れ、クライアントIDとクライアントシークレットをコピーします。okta.users.read.selfのスコープを許可し、Drataにサインインする人やグループにアプリを割り当てます。
Drataの接続の画面では、組織のドメイン、APIトークン、クライアントIDとシークレットを入れ、同期する人を全員にするか、特定のグループ（グループのラベル）にするかを選びます。
人事システムをつながない場合、Drataは、Oktaのユーザーのプロファイルを作った日を入社日として扱います。Oktaにカスタムの属性drataStartDate（入社日）とdrataContractor（業務委託者かどうか）を加えると、Drataが自動で読み取ります。退職日は、この属性では扱えず、Oktaのユーザーを無効にした日になります。
Microsoft 365（Microsoft Entra ID）
Microsoft Entra IDのユーザーをDrataに取り込むには、Microsoft 365との連携を使います。Microsoft Azureとの連携は、クラウド基盤の連携で、別のものです。
| 準備すること | 内容 |
|---|---|
| 管理者のアカウント | Microsoft 365のGlobal Administratorのアカウント。メールアドレスのドメインが、Drataを使い始めたときのドメインと一致していること |
| 複数のドメイン | 複数のメールのドメインを使っている場合は、Drataのサポートに複数のドメインの同期を有効にしてもらう |
| 同期するグループ | 特定のグループだけを同期する場合は、Microsoft Entra IDのグループのオブジェクトID |
接続の画面では、ユーザーを照合する項目を、ユーザープリンシパル名（UPN）か、メールアドレス（Email Address）から選びます。多くの組織にはUPNが勧められ、複数のドメインの環境などでメールアドレスを基準にしたい場合はメールアドレスを選びます。この選択は、つないだ後にUser Identity Mappingで変えられます。続いて、同期する人を全員にするか特定のグループにするかを選び、Microsoft Graphの読み取り専用のスコープを許可します。
社員がサインインするときにApproval requiredのメッセージが出る場合は、Microsoft 365の管理者が、組織としての同意を与えます。同意の画面が出ないときは、管理者のアカウントでDrataからサインアウトしてサインインし直すか、ブラウザーのプライベートウィンドウで連携をやり直します。
Google Workspace
Google Workspaceとの連携には、2つの方法があります。
| 方法 | 内容 |
|---|---|
| OAuthでつなぐ（勧められる方法） | User Management Administrator、Group Admin、Directory Sync Adminのロール（または同じ権限のカスタムロール）を持つ管理者のアカウントで承認する。ユーザー、グループ、組織部門、ドメインの読み取り専用のデータにアクセスする |
| Super Adminでつなぐ | Super Adminのアカウントで、Google管理コンソールのSecurity → Access and data control → API controlsから、Drataのクライアントにドメイン全体の委任を与える。接続の画面ではSuper Adminのメールアドレスを入れる |
つないだ後に、Drataの管理者がGoogle Workspaceに見つからない場合はメールアドレスの食い違いを解消し、同期するドメインとグループを選んでConfirmを選びます。最初の同期には、組織の規模によって最長で1時間かかります。Drataへのサインインに使うメールアドレスのドメインがGoogle Workspaceのドメインと違う場合は、Drataのサポートに要員の同期を有効にしてもらいます。
連携に対応していないIDプロバイダー
連携に対応していないIDプロバイダーを使っている場合は、CSVファイルで要員を取り込みます（CSVの連携）。
- Drataのひな形を使い、列の順序を変えず、全ての列を含めます。
- メールアドレスのドメインは1つだけです。複数のドメインには対応していません。
- CSVの連携は、ほかのIDプロバイダーの連携と組み合わせられません。
- 入社や退職などの変更は、連携の編集のアイコンから新しいCSVファイルをアップロードして反映します。ファイルに誤りがあると、内容を知らせるメールが届きます。
- 社員がDrataにサインインするには、別にSSOの連携（
Enterprise SSO）をつなぎます。
同期する範囲をグループで絞る
Okta、Microsoft 365、Google Workspaceでは、同期する人を特定のグループに絞れます。グループで絞るときは、次の点に注意します。
【注意】 Microsoft 365との連携でグループの範囲を変えるときは、選んだグループにDrataの管理者を必ず含めてください。含めないと、管理者がDrataにアクセスできなくなるおそれがあります。また、Microsoft 365との連携では、選んだグループに入っていないユーザーは同期されず、既に同期したユーザーをグループから外すと、退職した従業員（
Former Employee）として扱われることがあります。
複数のIDプロバイダーを使う
地域や子会社ごとに別のIDプロバイダーを使っている場合は、複数のIDプロバイダーをつなげます。複数のIDプロバイダーの要員は、全てのワークスペースに表示されます。
Drataは、メールアドレスが完全に一致するユーザーを同じ人として扱います。同じ人が複数のIDプロバイダーにいる場合、名前とメールアドレスは、優先順位の最も高いIDプロバイダーの情報が使われます。優先順位は、つないだIDプロバイダーの詳細の画面でConfigure connection priorityを選び、並べ替えて決めます。
Configure Connection Priorityの画面。IDプロバイダーをドラッグして並べ替え、最上位のものが名前とメールアドレスの基準になる
| 押さえること | 内容 |
|---|---|
| つなぐ順序 | 最も信頼できるユーザーの情報を持つIDプロバイダーを最初につなぎ、残りを優先したい順につなぐ |
| メールアドレスをそろえる | 名前は照合に使われず、メールアドレスが少しでも違うと別の人として記録される。同じ人には同じメールアドレスを使う |
| 同期するユーザーを分ける | できれば、IDプロバイダーごとに地域や部署などの別のグループを同期し、同じユーザーを重ねて取り込まない |
| 重複した記録 | 同じ人の記録が2つできた場合は、使わない方の記録の状態をOut of scope (ignore)にする |
優先順位を変えると、反映に最長で24時間かかり、重複した記録ができることもあります。1つのIDプロバイダーから複数に増やすとき、または減らすときは、どのIDプロバイダーにも見つからないユーザーが退職者として扱われる点に注意し、監査の対象期間に入る前に余裕をもって済ませます。
多要素認証の確認
Drataは、つないだIDプロバイダーごとに、ユーザーの多要素認証を確かめます（MFA on Identity Providerのテスト）。Drataが多要素認証を有効にすることはなく、設定はIDプロバイダーの側で行います。
Compliance→MonitoringでMFA on Identity Providerのテストを開きます。Findingsタブで、多要素認証が有効になっていないユーザーと、そのIDプロバイダーを確かめます。- ユーザーを選び、
Fix findingを選ぶと、多要素認証を有効にする手順を案内するメールを送れます。 - IDプロバイダーで、該当するユーザーの多要素認証を必須にします。
- 同期が済んだ後に、テストを実行し直します。
MFA on Identity ProviderのテストのFindingsタブでユーザーを選んだ画面。Fix findingで案内のメールを送れる
Governance → Personnelで、ComplianceのフィルターをIdentity MFA non-compliantにして、対象のユーザーを探すこともできます。
【注意】 テストが成功するには、多要素認証が使える状態ではなく、必須になっていて、各ユーザーがIDプロバイダー自体に多要素認証の手段を登録している必要があります。複数のIDプロバイダーにいるユーザーは、全てのIDプロバイダーで多要素認証が必要です。Microsoft Entra IDでは、Drataはセキュリティーの既定値、条件付きアクセスのポリシー、ユーザーごとの多要素認証の順に評価します。Microsoft Graphから見えない仕組みだけで多要素認証をかけている場合は、検出されないことがあります。
多要素認証を使えないサービスアカウントや緊急用の管理者のアカウントは、理由を付けてテストから除外します。除外の考え方は除外と無効化の使い分けで説明します。
アクセスレビューへの利用
IDプロバイダーの連携で取り込んだ要員は、アクセスレビューの基準になります。Oktaをアクセスレビューの連携先として使う場合は、先にOktaのIDプロバイダーの連携が必要です。アクセスレビューの進め方は、アクセスレビューの設計で説明します。