Drataは、連携したシステムの設定や状態を、モニタリングテストで毎日自動的に確かめます。テストの結果は、コントロールとフレームワークの準備状況のもとになるため、テストがどう動き、どの条件で準備状況に効くかを押さえておくと、結果を正しく読めるようになります。このページでは、モニタリングテストの仕組みとして、Autopilotによる毎日の実行、テストがコントロールの準備状況に効く条件、ProductionとCodebaseのタブの違い、テストの状態の意味を説明します。
モニタリングテストとAutopilot
モニタリングテストは、連携したシステムから集めたデータをもとに、決められた条件を満たしているかを判定します。例えば、多要素認証が全てのユーザーで有効になっているか、データベースが暗号化されているかなどを確かめます。
テストは、Autopilotの仕組みで毎日自動的に実行されます。ヘルプセンターでは、全てのテストが毎晩、米国太平洋標準時の午後7時に実行されると説明されています。設定を直した後などに結果をすぐに確かめたいときは、Test nowでいつでも実行できます。結果は、通常は数分で表示されます。
【注意】 連携先での変更は、連携先のAPIの事情で、Drataに反映されるまで最長で24時間かかることがあります。毎日のデータの同期に左右されるテストは、
Test nowで実行し直しても、同期が済むまで結果が変わらないことがあります。詳しくは連携の全体像を参照してください。
テストが自社の環境に入る経路は、次の3つです。
| 経路 | 内容 | 説明しているページ |
|---|---|---|
| フレームワークの有効化 | フレームワークを有効にすると、そのコントロールにマッピングされたDrataのテストが自動的に入る。モニタリングの画面に並ぶテストの多くはこの経路で入ったもの | 対応フレームワークと有効化 |
| Test Libraryからの追加 | Drataが用意するテストのカタログから、必要なテストを選んで追加する。AIで生成されたテストは、この経路でしか入らない | Test Libraryからテストを追加する |
| カスタムテスト | 自社で決めた条件で、テストを自分で作る | カスタムテストを作る |
フレームワークの有効化で入ったテストでも、テストに必要な連携(AWS、Microsoft Azure、Google Cloudなど)がまだなければ、テストは動かないままです。必要な連携をつなぐと、テストは自動的に動き始めます。そのため、新しい連携をつないだ後に、有効になるテストが増えるのは想定された動きです。
Monitoringページを開く
モニタリングテストは、左側のナビゲーションのCompliance → Monitoringで確かめます。Monitoringページを使えるのは、Admin、Information Security Lead、Workspace Manager、Control Manager、DevOps Engineerのロールのユーザーです。読み取り専用のロールのユーザーは、内容を見られますが、変更はできません。
ワークスペースの機能を使っている場合、テストとその結果はワークスペースごとに分かれます。あるワークスペースのテストの結果が、別のワークスペースの状態を変えることはありません。
ProductionとCodebaseのタブ
Monitoringページには、ProductionとCodebaseの2つのタブがあります。
| タブ | 表示されるテスト |
|---|---|
Production | 連携した業務のシステムに対して実行される本番環境のテスト。IDプロバイダー(OktaやMicrosoft 365(Microsoft Entra ID)など)、クラウド基盤(AWS、Google Cloud、Microsoft Azure)、セキュリティー製品、人事システムなどが対象 |
Codebase | 連携したコードのリポジトリーを、Infrastructure as Codeの解析で確かめるコードベースのテスト。設定の誤りや、必要な安全策の不足、ポリシーへの違反を、開発の早い段階で見つける |
Productionタブの上部には、連携したシステム全体のテストの結果の要約が表示されます。成功したテストの割合(% of tests passed)、成功(Passed)、失敗(Failed)、エラー(Error)のテストの数です。下書きのカスタムテストは、この数に含まれません。
MonitoringページのProductionタブの上部に表示される、テストの結果の要約
Codebaseタブの上部には、スキャンしているリポジトリーの数(Repositories monitored)と、失敗したテストと成功したテストの数が表示されます。テストの一覧と操作は、2つのタブで共通です。
テストの一覧
一覧には、次の列が並びます。
| 列 | 内容 |
|---|---|
Name | テストの名前。下書きのカスタムテストにはDraft、新しく公開されたDrataのテスト(45日間)にはNewのラベルが付く |
Result | 最後に実行したときの結果(Passed、Failed、Error) |
Findings | テストが見つけた検出事項の数 |
Status | テストの状態(Enabled、Disabledなど)。実行中はTesting...と表示される |
Category | テストの分類(Productionタブだけ) |
Active connections | テストが使っている連携(Productionタブだけ) |
テストの一覧。名前、結果、検出事項の数、状態、分類、使っている連携が並ぶ
テストの分類(Category)は、次の通りです。
| 分類 | 確かめる対象 |
|---|---|
Device | 社員の端末の状態 |
Identity Provider | 多要素認証の利用など、認証と認可 |
Infrastructure | クラウド基盤の設定 |
Observability | インフラストラクチャーのツールの設定 |
Policy | 必要なポリシーがあるか、見直されているか、同意されているか |
Version Control | コードの管理に関する要求事項 |
Ticketing | Jiraなどの課題管理の連携を使う事項 |
In Drata | Drataの中の情報 |
一覧の上の検索欄では、テストの名前、システム、キーワード(「MFA」「Okta」「IAM」など)でテストを探せます。絞り込みの条件には、結果、状態、分類、テストの種類(Drataのテスト、公開済みのカスタムテスト、下書きのカスタムテスト)、除外の有無、連携、コントロール、フレームワーク、チケットの状態があります。絞り込みの使い方は、テストの結果を読み解くと失敗したテストの是正で説明します。
テストの状態と結果
テストには、動いているかどうかを示す状態(Status)と、最後に実行したときの結果(Result)があります。
| 状態 | 内容 |
|---|---|
Enabled(有効) | Autopilotで毎日実行され、手動でも実行できる |
Disabled(無効) | Autopilotでも手動でも実行されない |
Unused(未使用) | テストに必要な連携がない、またはポリシーの下書きが1つも作られていないため、テストを使えない |
Testing(実行中) | テストを実行している |
| 結果 | 内容 |
|---|---|
Passed(成功) | 必要なデータを全て集め、求められる条件を満たしていると判定した |
Failed(失敗) | 必要なデータを全て集め、求められる条件を満たしていないと判定した |
Error(エラー) | データを集められない問題が起き、条件を満たしているかを判定できなかった |
それぞれの結果の詳しい読み方は、テストの結果を読み解くで説明します。
テストが準備状況に効く条件
テストの結果がコントロールの準備状況に効くかどうかは、テストの状態と、コントロールにマッピングされているかで決まります。
| 状態 | コントロールへのマッピング | 実行されるか | 準備状況に効くか |
|---|---|---|---|
Enabled | あり | される(毎日のAutopilotか手動) | 効く。コントロールとフレームワークの準備状況のもとになる |
Enabled | なし | される(毎日のAutopilotか手動) | 効かない。結果を見られるだけ |
Disabled | あり、なしとも | されない | 効かない。有効に戻すまで何も反映されない |
Unused | あり、なしとも | されない | 効かない。連携やポリシーの準備が済んでいない |
例えば、多要素認証のテストがSOC 2のCC6.1に関係するコントロールにマッピングされている場合、テストが失敗すると、そのコントロールは準備未完了になり、SOC 2の準備状況にもその不足が表れます。マッピングされていないテストは、準備状況には効きませんが、後でマッピングを検討するリスクの領域を把握するのに役立ちます。
このほか、次のテストも準備状況に効きません。
- 下書きのカスタムテスト。公開すると、準備状況に効くようになる。
- 結果が
Errorのテスト。判定できていないため、準備状況の計算に入らない。 - Test Libraryで新しく公開されたテスト。自社の環境に追加して公開するまでは、準備状況に影響しない。
マッピングされたテストの結果が、コントロールの準備状況にどう効くかは、コントロールの準備状況で説明しています。テストとコントロールのマッピングの手順は、Test Libraryからテストを追加するで説明します。
【注意】 エラーのテストは準備状況の計算に入らないため、テストが実行できていないのに、コントロールが準備完了のまま表示されることがあります。準備状況の数字だけでなく、
Errorのテストが残っていないかも定期的に確かめてください。
テストをまとめて操作する
一覧でテストのチェックボックスを選ぶと、選んだテストにまとめて操作できます。検索や絞り込みでテストを絞ってから選ぶと効率的です。
| 操作 | 内容 |
|---|---|
Test now | 選んだテストをすぐに実行する |
Enable | 選んだテストを有効にし、毎日のAutopilotで実行されるようにする。有効にしても過去の結果は変わらず、次の実行から反映される |
Disable | 選んだテストを無効にする。無効にする理由(業務上の根拠)の入力が必要で、理由は監査のためにMonitoringページに残る |
Publish | 下書きのカスタムテストを公開する。次のAutopilotの実行から、公開した版が使われる |
More → Download CSV | 選んだテストの名前、説明、状態、結果、分類、マッピングされたコントロールのIDなどをCSVファイルに書き出す。選択と絞り込みの条件が反映される |
1つのテストだけを操作する場合は、行の「…」からTest nowで実行するか、行のEnabledとDisabledの切り替えで状態を変えます。テストの名前を選ぶと、テストの詳細の画面が開きます。無効化の手順と、除外との使い分けは、除外と無効化の使い分けで説明します。