カスタムテストを作る

Drataが用意するテストで確かめられない事項は、カスタムテストを作って自動で確かめられます。カスタムテストは、Test Builderで、どのリソースのどの属性がどうなっていればいいかを組み立てて作ります。このページでは、Test Builderでカスタムテストを作る方法として、テストのロジックの組み立て方、下書きと公開の流れ、カスタムテストの証跡を監査人に渡す方法、作りすぎを避ける考え方を説明します。

カスタムテストを使う場面

カスタムテストは、自社の実際の運用に合わせた条件で、環境を確かめるテストです。公開したカスタムテストは自動的に実行され、監査で確かめられる証跡を作ります。ヘルプセンターでは、主な使い方として次の3つを挙げています。

使い方	例
Drataのコントロールをカスタムテストでモニタリングする	AWS Backupのバックアップのジョブが毎日完了しているかを確かめるテストを作り、日々のバックアップの状態のモニタリングのコントロール（DCF-98）にマッピングする
手作業で確かめていたコントロールを自動化する	Amazon GuardDutyでS3のログのデータソースが有効かを確かめるテストを作り、脅威の検知のコントロール（DCF-87）にマッピングする
自社のカスタムコントロールを自動で確かめる	Application Auto Scalingのスケーリングポリシーがあるかを確かめるテストを作り、カスタムコントロールにマッピングする

カスタムテストを作るには、次の条件を満たす必要があります。

条件	内容
プラン	DrataのAdvanced以上のプラン。ご契約のプランで使えるかどうかは、正規販売代理店（デジタルアクセルズ）にご相談ください
連携	AWS、Google Cloud、Microsoft Azureなどのクラウド基盤の連携か、カスタム連携が1つ以上有効になっていること
ロール	Admin、Information Security Lead、Workspace Manager、Control Manager、DevOps Engineerのいずれか
数の上限	アカウントのカスタムテストの数が上限に達していないこと。同じテストの下書きと公開済みの版は、1つのテストとして数える

カスタム連携で送ったデータを確かめるテストも、同じ手順で作ります。その場合は、分類（Category）をCustomにし、提供元にカスタム連携の名前を選びます。カスタム連携については、カスタム連携で説明しています。

作る前に決めること

テストを作る前に、次の点を決めておくと、組み立てが楽になり、結果も予想しやすくなります。この順に作る必要はありません。

1. 目的：どのリスクや要求事項を確かめるか、どうなっていれば適合とするかを決めます。
2. 提供元とアカウント：確かめるシステムと、連携したアカウントを選びます。評価に使えるデータがこれで決まります。
3. 条件グループ：サービスとリソースの種類を選び、評価するリソースを決めます。1つの条件グループが、1つのデータのまとまりに当たります。
4. 範囲の絞り込み（任意）：条件を当てはめる前に、特定のリソースを含めたり除いたりします。本番環境のリソースだけにする、タグの付いたリソースを除く、などです。
5. 条件（ルール）：属性、演算子、値で、リソースごとに何が成り立つべきかを決めます。
6. 条件グループの追加（必要な場合）：別のサービスやリソースの種類、独立したロジックを評価するときは、条件グループを追加します。
7. 評価の基準：全ての条件グループの結果を、どうまとめて1つの成功か失敗にするかを決めます。

条件グループ、条件、絞り込みの条件

カスタムテストを作るうえで最も重要なのが、この3つの関係です。

条件グループ（Condition Group）。サービスとリソースを選び、属性、演算子、値で条件を決め、Filtering criteriaで評価するリソースを絞り込む

要素	内容	使う場面
条件グループ（Condition Group）	1つのサービス、1つのリソースの種類、そのリソースに当てはめるルール、任意の絞り込みの条件をまとめたもの	別のリソースの種類を評価する、リソースごとに違うロジックを当てはめる、結果を個別に評価して評価の基準でまとめる。例：1つ目の条件グループでS3のバケットを、2つ目でEBSのボリュームを評価する
条件（Attribute、Operator、Value）	確かめるデータの項目（属性）、値の比べ方（演算子）、比べる値	同じリソースで、複数の要件を全て満たす必要がある。例：暗号化がtrueで、かつ公開のアクセスがfalse
絞り込みの条件（Filtering criteria）	条件を評価する前に、条件グループの範囲を絞る。ExcludeかIncludeを選び、属性、演算子、値で指定する	特定のリソースだけを評価する、タグ、ラベル、名前、属性で一部のリソースを外す。例：DrataExcludeのタグが付いたもの以外の全てのS3のバケットを評価する

選べるリソースは、選んだ提供元とサービス、自社の環境にあるデータによって決まります。1つのサービスでリソースを使うと、そのサービスは、次の条件グループを追加するときの選択肢に表示されなくなります。

【注意】 条件を設定した後に、選んだサービスやリソースを変えると、テストの設定がリセットされ、作り直しが必要になることがあります。サービスとリソースは最初に確定させてから、条件を組み立てます。

評価の基準（evaluation threshold）は、次の3つから選びます。

評価の基準	内容
All results must pass	全ての条件グループが成功したときに、テストを成功にする。ほとんどのコンプライアンスの用途で勧められる
At least one result must pass	どれか1つの条件グループが成功すれば、テストを成功にする
Only one result may fail	一定の失敗までは、テスト全体を失敗にしない

テストを作る

1. Compliance → Monitoringで、Create testを選びます。
2. テストの名前と説明を入れます。名前は重複できません。名前と説明は、どちらも監査の証跡に表示されます。
3. 作成に進み、Logic detailsで、評価の基準、分類、提供元とアカウントを指定します。
4. 条件グループごとに、サービスとリソースを選び、条件（属性、演算子、値）を加えます。必要に応じて、絞り込みの条件を加えます。
5. 設定を保存します。

保存したテストは、下書きとして作られます。

Resource Guideで属性を調べる

テストを作っている間は、情報のアイコンを選ぶとResource Guideが開き、使えるサービス、リソース、属性を調べられます。

1. 提供元（AWS、Google Cloud、Microsoft Azureなど）を選びます。
2. サービスを選び、リソースを絞ります。
3. リソースを選ぶと、Drataが評価できるデータの構造と属性が表示されます。

View attribute dictionaryを選ぶと、属性ごとの名前、データの型、説明、ほかの属性との関係を確かめられ、名前や説明で検索もできます。入れ子になった属性は、縦の線で階層が示され、Test Builderではドットでつないで指定します（例：diagnostics.logAnalytics.workspaceId）。配列の中のオブジェクトの属性は、灰色と白の交互のまとまりで示され、評価するにはAdvanced editorが必要です。

Advanced editorで複雑な条件を書く

条件グループの中でAdvanced editorを有効にすると、属性、演算子、値を選ぶ代わりに、JSONの形のルールで条件を書けます。次のような場合に使います。

• 入れ子のオブジェクトや配列を評価する
• ANDとORを組み合わせた複雑なロジックを書く
• タグのキーだけでなく、キーと値の組み合わせで判定する

画面で選んだ条件は、Advanced editorに切り替えると、JSONのルールに自動で変換されます。最上位のallは全ての条件が成り立つこと（AND）、anyはどれか1つが成り立つこと（OR）を表し、入れ子にもできます。各条件は、fact（属性）、operator（演算子）、value（期待する値）で書きます。

{
  "all": [
    {
      "fact": "encryption.enabled",
      "operator": "equal",
      "value": true
    }
  ]
}

エディターは書いている間に文法とロジックを確かめ、誤りのある行と内容を示します。誤りが全て解消するまで、保存できません。Ctrl＋Spaceで、入れられる値の候補を表示できます。1つのコードのブロックに書けるのは70行までです。

下書きと公開

作ったカスタムテストは、まず下書きになります。下書きで動きを確かめてから公開すると、準備状況や監査の証跡に影響させずに、ロジックを検証できます。

項目	下書き	公開済み
実行	実行でき、結果も返る	Autopilotで自動的に実行される
準備状況への影響	影響しない	コントロールにマッピングすると影響する
監査人への提示	監査人向けではない	監査の証跡が自動的に作られる
一覧の表示	Draftのラベルが付く	ラベルは外れる
コントロールへのマッピング、チケット	できない	できる

下書きのテストの実行は、Autopilot Draft Testのイベントとして記録されます。Monitoringページの絞り込みで、テストの種類をCustom (Draft)にすると、下書きのテストを探せます。

公開するには、下書きのテストを開いてPublishを選びます。Monitoringページの一覧で下書きのテストを複数選び、まとめて公開することもできます。公開すると、テストのロジックと除外は引き継がれますが、下書きの間の履歴とメモは引き継がれません。公開したテストは、コントロールにマッピングします。マッピングの手順は、Test Libraryからテストを追加するで説明しています。

公開したテストを変える

公開したカスタムテストのロジックを変えるには、テストの詳細の画面のTest logicの欄でEditを選びます。

• 公開した版から、下書きの版が作られます。
• 1つの公開済みのテストに作れる下書きは1つだけです。
• 下書きを編集している間も、公開した版はそのまま実行されるため、準備状況と監査の証跡は影響を受けません。

下書きで結果を確かめたら、公開します。次のAutopilotの実行から、新しい版が使われます。

カスタムテストの証跡を監査人に渡す

カスタムテストの証跡は、毎日システムが作る監査用のPDFで、監査人に渡せます。

1. 左側のナビゲーションのEventsを開きます。
2. 絞り込みで、対象のカスタムテストのイベントを探します。
3. イベントを選びます。
4. Downloadを選びます。
5. ファイルの準備ができると、画面の右下に通知が表示されます。通知のDownloadを選びます。

PDFには、次の内容が入っています。カスタムテストがどう動き、結果がどう作られるかを監査人に示すのによく使われます。

• テストの設定とロジック（JSONの形）
• テストの実行で評価したリソース
• 除外したリソースと、記録した除外の理由
• Autopilotが作った生のJSONの応答

監査人や技術の担当者が生の応答のデータを求める場合は、Monitoringページでカスタムテストを開き、Historyタブでテストのイベントを選んで、Raw JSONの欄のDownloadで、テキストファイルとしてダウンロードします。イベントの見方は、イベントの確認で説明します。

【運用のポイント】 テストの名前と説明は、監査の証跡にそのまま表示されます。何を、どの条件で確かめるテストかが監査人に伝わる名前と説明にしておくと、証跡の説明の手間が減ります。カスタムテストの名前と説明は、公開した後も、テストの詳細の画面のDetailsの欄で直せます。

作りすぎを避ける

カスタムテストは、アカウントごとに作れる数に上限があります。また、作ったテストは、ロジックの保守、結果の確認、監査人への説明の対象になり続けます。必要なものに絞って作ります。

作る前に確かめること	内容
Test Libraryに同じ目的のテストがないか	Test Libraryには、Drataのテストに加え、AIで生成された1,000件以上のインフラストラクチャーのテストがある。目的に合うテストがあれば、追加して使う。Test Libraryからテストを追加するを参照
既存のテストの除外で済まないか	既存のテストの一部の項目だけが自社に当てはまらない場合は、新しいテストを作らず、除外で対処する。除外と無効化の使い分けを参照
1つのテストにまとめられないか	同じリソースへの複数の要件は、1つの条件グループに条件を重ねる。別のリソースの種類も、条件グループを追加して1つのテストで評価できる

失敗したカスタムテストの原因は、AIの要約で確かめることもできます。失敗したテストの是正を参照してください。