モニタリングテストの検出事項の中には、業務上の理由で意図的に許しているものや、監査の対象外のものが含まれることがあります。こうした項目への対処には、特定の項目だけをテストの対象から外す除外と、テストそのものを止める無効化の2つがあります。選び方を誤ると、本来見つけるべき問題を見逃したり、準備状況が実態と食い違ったりします。このページでは、テストの除外と無効化の違いとして、特定のリソースだけを対象から外す除外の使い方、クラウドのタグによる除外、無効化が準備状況に与える影響、監査人への説明を説明します。
除外と無効化の違い
| 項目 | 除外(Exclusions) | 無効化(Disable) |
|---|---|---|
| 対象 | テストの中の個々の項目(検出事項、リソース) | テスト全体 |
| テストの実行 | 続く。除外した項目だけが、以後の実行で評価されない | 止まる。Autopilotでも手動でも実行されない |
| 準備状況への影響 | 除外していない項目の結果で、引き続き準備状況に効く | 効かなくなる |
| 新しい問題の検出 | 新しく現れた項目は、引き続き検出される | 検出されない |
| 理由の記録 | 業務上の根拠(business rationale)の入力が必要 | 業務上の根拠の入力が必要 |
| 元に戻す | いつでも除外を外せる | いつでも有効に戻せる |
除外が向くのは、テスト自体は自社の環境に当てはまり、今後の問題も見つけ続けたいが、特定の項目だけは意図的に許している、または対象外という場合です。無効化が向くのは、テストが自社の環境に当てはまらない場合、コントロールをDrataの外で実施またはモニタリングしている場合、テストを実行させたくない、または準備状況に影響させたくない場合です。
| 場面 | 選ぶ方法 |
|---|---|
| 新しいデータベースや設定の誤りを見つけるテストで、1つのデータベースだけが、リスクにならない形で意図的に設定されている | 除外。そのデータベースを除外すれば、テストは毎日実行され、今後のデータベースも引き続き確かめられる |
| 文書化した業務上の理由で、あるセキュリティーグループが外部からのSSHを許している | 除外。理由を記録して、その検出事項だけを除外する |
| テストが確かめるセキュリティーの対策を、自社では別のツールや手順で実施している | 無効化。テストが自社の守り方を表していないため無効にし、監査では代わりの証跡を示す |
【注意】 テストが自社に当てはまり、一部の項目だけを無視したい場合に、テストを無効化しないでください。テスト全体が止まり、本来見つけるべき新しい問題も見逃します。まず除外で対処できないかを考えます。
検出事項を除外する
除外は、テストの詳細の画面のFindingsタブから作ります。失敗したテストの検出事項を確かめるときに作ることが多いですが、意図的に外すべき項目があれば、いつでも作れます。
Compliance→Monitoringで、テストを開きます。Findingsタブを開きます。- 除外する検出事項を1つ以上選びます。個々の検出事項を選ぶと、除外する前に詳しい内容を確かめられます。
Excludeを選びます。- 業務上の根拠を入れます。
Submitを選びます。
除外した項目は、以後のテストの実行で評価されません。除外は、テスト全体ではなく、個々の項目に対して効きます。
除外を確かめて管理する
除外した項目は、テストの詳細の画面のExclusionsタブに並びます。除外した人、除外した日、理由も確かめられます。関係するリソースが今のテストの結果に含まれなくなった除外には、N/Aと表示されます。
Exclusionsタブで除外を選んだ画面。選んだ除外について、理由を変えたり、除外を外したりできる
| 操作 | 手順 |
|---|---|
| 理由を変える | 除外を1つ以上選び、Update reasonを選ぶ |
| 除外を外す | 除外を1つ以上選び、Includeを選んで、Reincludeで確定する。外した項目は、次のテストの実行から再び評価される |
| 一覧を書き出す | Download ExclusionsでCSVファイルに書き出す。分類がIn DrataとPolicyのテストでは使えない |
除外のあるテストを探すには、MonitoringページでHas exclusionsの絞り込みを使います。
要員の検出事項は除外できない
テストの検出事項が要員(ユーザー)の場合、Monitoringページからは除外も、除外の取り消しもできません。要員は、Governance → Personnelのページで、特定の確認項目だけを除外するか、対象外にします。要員の除外では、例えば会社が管理しない私物の端末を使う業務委託の要員について、端末の確認項目だけを除外し、監査の対象には残せます。詳しくは、対象外の要員とサービスアカウントで説明します。
クラウドのタグで除外する
AWS、Microsoft Azure、Google Cloudのリソースは、クラウドの側でタグやラベルを付けて、Drataのテストの対象から外すこともできます。毎日作られては消える一時的なリソースや、本番環境以外のリソースなど、常にテストの対象にしないリソースに向きます。
| 方法 | 向く場面 |
|---|---|
| クラウドのタグによる除外(リソースの単位) | そのリソースを、どのテストでも一切モニタリングしない |
| Drataでの検出事項の除外(テストの単位) | リソースは対象に残すが、特定のテストの結果だけを許す |
Drataは、クラウドの側で付けたタグやラベルを読み取って除外を判断します。Drataがタグを付けたり管理したりすることはありません。除外は、証跡の収集と継続的なモニタリングの両方で評価され、除外したリソースは、関係するインフラストラクチャーのテストで評価されなくなります。
| クラウド | タグの付け方 | 対象のリソース |
|---|---|---|
| AWS | キーがDrataExcludeのタグ。値は任意で、空でもいい | RDSのインスタンスとクラスター、EKSのクラスター、EC2のインスタンス、S3のバケット、セキュリティーグループ、SQSのキュー、IAMのユーザー、ECS(Fargate)のクラスターとサービス、ElastiCacheのRedisのクラスター(保存データの暗号化のテストだけ)、DynamoDBのテーブル、OpenSearchのクラスター |
| Microsoft Azure | 名前がDrataExcludeのタグ | Container Instances、ストレージアカウント、Kubernetesのクラスター、仮想マシン |
| Google Cloud | キーがdrataexcludeのラベル。値には除外の理由を、スペースを入れずに書く | バケット、VMのインスタンス、Kubernetesのクラスター、Cloud SQLのデータベース、プロジェクト |
【注意】 タグのキーは大文字と小文字を区別します。AWSとMicrosoft Azureでは
DrataExcludeと書き、drataexcludeでは効きません。Google Cloudのラベルのキーはdrataexcludeです。また、Microsoft AzureのAzure SQLやPostgreSQLのフレキシブルサーバーなどのデータベースのサービスは、タグによる除外に対応していません。タグを付けても、モニタリングから外れません。
タグを付けるときは、次の点にも注意します。
- タグによる除外は、クラウド基盤との連携をつなぎ、Drataがリソースをモニタリングしている状態で評価されます。連携の設定は、クラウド基盤との連携で説明しています。
- AWSでは、タグを付けたリソースは、次のテストの実行で成功の結果の側に表示されます。
- AWSのEC2のAuto Scalingのグループにタグを付ける場合は、新しいインスタンスにもタグを付ける設定にします。タグを付ける前に作られたインスタンスには、タグが付きません。
- AWSのIAMのユーザーに、最初の同期の後でタグを付けると、次の同期でアクセスが取り消されたものとして扱われます。その場合も、インフラストラクチャーのアカウントの管理の画面で、要員に対応付けるか、対象外にする必要があります。最初の同期の前にタグを付けたユーザーは、取り込まれません。
- Google CloudのKubernetesのクラスターでは、ラベルがノードに行き渡るまで1時間ほどかかります。その前にCPUのモニタリングのテストが実行されると、失敗します。
- 除外は、リソースの種類によっては、すぐには反映されないことがあります。リソースを除外しても、アカウントや環境そのものはモニタリングの対象に残ります。
カスタムテストでは、テストの中の絞り込みの条件で、DrataExcludeのタグが付いたリソースを評価の前に外すこともできます。カスタムテストを作るを参照してください。
テストを無効化する
テストを無効にできるのは、Monitoringへの書き込みの権限があるユーザーで、通常はAdmin、Workspace Manager、Information Security Lead、Control Managerのロールです。
Compliance→Monitoringを開きます。- テストが実行中の場合は、行の「…」から実行を止めます。止まるのは今回の実行だけで、無効にするための操作です。
- 一覧で、テストの
StatusをEnabledからDisabledに切り替えます。 - テストを無効にする理由(業務上の根拠)を入れます。
- 変更を保存します。
無効にしたテストは、実行されなくなり、コントロールとフレームワークの準備状況に影響しなくなります。テストは一覧に残り、理由とともに参照や監査の確認に使えます。複数のテストは、一覧でまとめて選んでDisableで無効にできます。
有効に戻すには、テストのStatusをEnabledに切り替えて保存します。テストは再び実行され、次の実行から準備状況に反映されます。過去の結果は変わりません。
【注意】 マッピングされたテストを無効にすると、コントロールの準備状況はそのテストの結果を使わなくなります。テストで確かめていた内容を監査でどう示すか(代わりの証跡を用意するかなど)を、無効にする前に決めておきます。証跡の扱いは、証跡とコントロールのマッピングで説明します。
監査人への説明
除外も無効化も、業務上の根拠の入力が必須で、記録は監査で確かめられる形で残ります。監査人には、次の材料で説明します。
| 材料 | 内容 |
|---|---|
| 除外の理由 | Exclusionsタブで、除外した人、日付、理由を確かめられる。Download ExclusionsでCSVファイルに書き出して渡せる |
| 無効化の理由 | 無効化の理由は、Monitoringページに残り、監査で確かめられる |
| カスタムテストの証跡 | カスタムテストの監査用のPDFには、除外したリソースと、記録した除外の理由が含まれる。カスタムテストを作るを参照 |
| 代わりの証跡 | テストを無効にしたコントロールは、監査で代わりの証跡を示す |
【運用のポイント】 除外は、範囲の決定の代わりではなく、選んで使うものです。除外を増やしすぎると、自動化で確かめられる範囲が狭まり、見えるものも減ります。除外は控えめに、意図して使い、必ず意味のある理由を書きます。除外したリソースは定期的に見直し、監査の範囲の決定と食い違わないように調整します。