Drataは、クラウド基盤やバージョン管理などの連携先から取り込んだアカウントを要員に対応付け、誰がどのシステムにアクセスできるかを判断します。対応付けがずれていると、アクセスの管理のテストが失敗したり、監査人からの質問が増えたりします。このページでは、連携先のアカウントを要員に対応付ける方法として、メールアドレスで自動的に対応付く条件、共有アカウントや別名のアドレスの扱い、対応付けがずれたときの直し方を説明します。
自動で対応付く条件
Drataは、連携の種類ごとに、次の情報で記録を要員に対応付けます。
| 対応付けるもの | 照合に使う情報 | 対応付かない場合 |
|---|---|---|
| 複数のIDプロバイダーのユーザー | メールアドレスの完全な一致。名前は照合に使われない | 別の人として記録される |
| 人事システムとIDプロバイダーの記録 | メールアドレス。一致しないときは姓名 | 雇用状態がUnknownになる |
| バージョン管理のアカウント | 名前やメールアドレスなどの情報 | 対応付かないまま残る。連携先が十分な情報を渡さない場合は、手作業で対応付ける |
| クラウド基盤のアカウント | 同期した直後は対応付かないことがある | 手作業で対応付ける |
| バックグラウンドチェックの記録 | 個人のメールアドレス、仕事のメールアドレス、姓名の順 | 手作業で対応付ける |
メールアドレスの照合では、つづり、スペース、大文字と小文字、記号の違いも区別されます。IDプロバイダーと人事システムで、同じ人には同じ表記のメールアドレスを使うことが、対応付けのずれを防ぐ基本です。
アカウントを要員に対応付ける
連携先のアカウントは、ConnectionsのManage accountsの各ページで確かめます。Access Reviews、Background Checks、Infrastructure、Observability、Version Controlのページがあり、どのページでも同じ操作で対応付けます。対応付けには、IDプロバイダーから要員が取り込まれている必要があります。IDプロバイダーをつないでいないと、要員の選択肢が表示されないことがあります。
ConnectionsのManage accountsの区分。Infrastructureのページに、クラウド基盤から見つかったアカウントが並ぶ
Connectionsで、対象のManage accountsのページを開きます。- 対応付けるアカウントを探します。
Personnelの列で、そのアカウントを使う要員を選びます。
対応付けると、そのアカウントは要員に結び付きます。担当者が変わったときは、…のメニューから対応付けを外し、別の要員に対応付け直します。
対応付けが必要なテスト
次のテストは、アカウントが社内の個人に対応付いているかを確かめます。対応付いていないアカウントがあると失敗し、対象のアカウントの一覧が示されます。
| テスト | 直し方 |
|---|---|
Employees have Unique Version Control Accounts | Version Controlのページで、全てのアカウントを要員に対応付けるか、サービスアカウントを対象外にする |
Employees have Unique Infrastructure Accounts | Infrastructureのページで、同じように対応付けるか対象外にする |
Employees have Unique Email Accounts | ボットや別名のアドレスと判断されてUnknownになった要員の雇用状態を、Personnelページで直す |
テストを実行し直す前に、連携先の最新のユーザーの情報が同期されている必要があります。すぐに反映したいときは、Manage accountsのページのSyncで同期し直します（Access Reviews、Infrastructure、Observabilityのページで使えます）。All providersか、絞り込みで選んだ連携先だけを同期するSelected providerを選べます。テストの是正の進め方は、失敗したテストの是正で説明しています。
共有アカウントとサービスアカウントの扱い
サービスアカウント、自動化のためのユーザー、システムが作るIDなど、特定の個人のものではないアカウントは、要員に対応付けません。理由を書いて、対象外にします。
- 対象の
Manage accountsのページを開きます。 - アカウントの
…のメニューでMark out of scopeを選びます。 - そのアカウントが個人のアクセスではない理由を、簡潔に書きます。
Manage accountsのページで、アカウントの…のメニューからMark out of scopeを選ぶ画面
対象外にしたアカウントは、要員に対応付けられなくなり、理由は監査のために残ります。理由の確認と、対象に戻す操作は、同じ…のメニューから行います。
【運用のポイント】 対応付けを確かめる3つのテストは、社内ネットワーク、本番環境、ネットワーク機器、サポートのツールへのアクセスに個人ごとに固有のIDを求めるコントロール（
Unique Accounts Used）の一部です。対象外にするのは、個人のアクセスではないアカウントに限ります。
別名のアドレス
IDプロバイダーだけをつないでいる場合、admin@、marketing@、info@のように人ではないことが明らかな別名のアドレスは、在籍中の従業員として取り込まれません。人事システムをつないでいても、ボットや別名のアドレスのアカウントが要員の一覧に入り、Unknownになることがあります。そうした記録は、Personnelページで雇用状態をOut of scope (service account)などに直します。要員の記録の対象外の扱いは、対象外の要員とサービスアカウントで説明します。
対応付けがずれたときの直し方
| 状況 | 直し方 |
|---|---|
| アカウントが別の要員に対応付いている | …のメニューから対応付けを外し、正しい要員に対応付け直す |
| 同じ人の記録が2つできた | 複数のIDプロバイダーで、メールアドレスが少しでも違うと別の人として記録される。メールアドレスをそろえ、使わない方の記録の雇用状態をOut of scope (ignore)にする |
人事システムの記録がUnknownになる | 人事システムとIDプロバイダーで、メールアドレスと名前の表記をそろえ、再同期する |
| バックグラウンドチェックの記録が対応付かない | Manage accountsのBackground Checksのページで、要員を選んで対応付ける（バックグラウンドチェック） |
メールアドレスを使い回すとき
Drataは、仕事のメールアドレスを、要員の記録を照合する主な識別子として使います。退職した人のメールアドレスを新しい社員に使い回すと、新しい社員が退職者の記録に対応付けられ、入社日、退職日、雇用状態や、研修、アクセスレビュー、退職時の作業の証跡が、別の人のものとして表示されるおそれがあります。社員ごとに、退職後も使い回さないメールアドレスを割り当てることが勧められています。
どうしても使い回す場合は、次の順で進めます。
- 退職者のIDプロバイダーか人事システムの記録を、使い回さない仮のアドレス（例：
former-jdoe+archive@yourdomain.com）に変えます。 - 変更が済んだ後に、使い回すアドレスで新しい社員の記録を作ります。
- 新しい社員にSSOでDrataにサインインしてもらい、新しい記録を同期させます。
アクセスがなくなった記録
連携先でアカウントを削除しても、Drataからは消えません。アクセスがなくなった日時がAccess revokedの列に記録され、退職者のアクセスを期限内に外したことを監査で示せます。データベースや管理者のアクセス、多要素認証の状態などの表示は、連携先から読み取ったもので、Drataからは変えられません。バージョン管理のWrite accessとMerge to default branchのチェックは、開発と課題管理のツールとの連携で説明しています。