除外

セキュリティおよびコンプライアンスプログラムは多くの場合、特定のビジネス状況において有効でありながら許容できる検出結果を生成します。たとえば、ロードバランサーは設計上パブリックにアクセス可能である場合や、開発環境で意図的に緩和されたアクセス許可が使用されている場合があります。除外と呼ばれるこれらの承認されたケースを管理することで、不必要なノイズ発生を防ぐことなく、リスクの全体像を正確に把握できます。

除外を使用すると、例外管理フレームワークが提供され Tenable One Cloud Exposure 、可視性と説明責任を維持しながら、これらの決定を承認、追跡、監査できます。

除外を使用することで、次のことが可能になります。

ノイズを減らす: 未解決の検出結果から誤検出や意図的な設定を削除します。
大規模に適用する: ビジネスニーズに合わせて 1 つの除外ルールを定義し、関連するすべての検出結果に適用します。
ガバナンスの維持: 各除外を作成したユーザー、いつ、なぜ作成したかを記録します。
フォーカスの向上: 未解決の検出結果に実用的なリスクのみが反映されるようにします。

除外ライフサイクル

除外は、4 段階のライフサイクルに従います。各段階で、例外が意図的に作成され、定期的に確認され、セキュリティモデルに適合するようになります。

検出結果と今後の検出結果の特定: 有効であるものの対処の対象とならない検出結果を見つけ、発生する可能性のある同様のケースを予測します。
除外を定義する: これらの検出結果を明確なビジネスケースにグループ化し、その範囲、 アクション、理由を決定します。
除外を作成する: 各ビジネスケースを除外に変更し、一致する検出結果の深刻度を無視するか調整します。
除外の管理: 除外を維持、更新、または廃止して、例外管理を最新の状態に保ち、監査可能に保ちます。

検出結果と今後の検出結果の特定

検出結果の深刻度を無視したり調整したりする前に、設定を見直して、有効であるものの対処の対象とならない現在または潜在的な検出結果を特定します。これらには、意図的にパブリック設定、許容設定、または一時的な設定が含まれ、それらを除外したり深刻度をダウングレードしたりする予定です。

一般的な例:

環境: テストのためのより広範なアクセスを許可する開発、QA、またはサンドボックス。
アーキテクチャ: パブリックロードバランサー、インターネットに接続する API、またはデモテナント。
運用上のニーズ: 緊急ロール、一時的なデバッグ設定、移行期間
データパイプライン: ステージングバケット、一時キュー、または有効期間の短いスナップショット。
名前付けとタグ: 意図を示す env:dev、 qa-*、 lab-* などの規則。

[検出結果] ページのフィルターを使用して、次のパターンを特定します。

フィルタータイプ	例	目的
ポリシー	パブリック EC2 インスタンス	意図的な設定または許容された設定を表す可能性のある特定のポリシーからの検出結果を特定します。
環境またはアカウント	Dev1 アカウントの中程度の検出結果	リスク許容度や可視性のニーズが環境によって異なる検出結果に焦点を当てます。
重大度の調整	ステージング環境の重大な検出結果を中に変更	有効だが非本番環境の設定でリスクの低い検出結果を再分類します。

これらのパターンを確認した後で、その処理方法を決定します。

意図的な検出結果や誤検出の検出結果は無視します。無視無視された検出結果からのパターンベースの除外の作成方法を学習します。
検出結果が有効であるが、文脈上のリスクが低い場合、深刻度を変更します。

除外を定義する

既存または将来の検出結果を特定したら、それぞれが 1 つの明確に定義されたビジネスケースを表す除外にグループ化します。

典型的な除外の使用例

テスト環境のパブリックエンドポイントなど、 意図的な設定を反映した検出結果。
検証後に検出結果が 誤検出 であることが確認されました。
修正作業の進行中に付与された一時的な例外。

除外を定義するには、以下のようにして検出結果と今後の検出結果をグループ化します。

範囲: 除外が適用される場所 (組織、アカウント、フォルダー)、および対象となるポリシー、リソース、深刻度を定義します。
アクション: 定義された範囲内で対象となる検出結果の処理を決定します。深刻度を無視または変更します。

1 つの検出結果は、アクションタイプごとに 1 つずつ、合計最大 2 つの除外による影響を受けます。同じアクションの複数の除外が同じ検出結果をターゲットとする場合、1 つの除外のみが適用されます。詳細については、「競合の解決」を参照してください。

除外を定義するためのベストプラクティス

除外をできるだけ具体的にして、監視対象と監視対象外を明確にします。
同じ除外内で無関係のポリシーやリソースタイプを混在させないようにしてください。たとえば、「パブリック IAM ロール」や「パブリック EC2 インスタンス」などです。除外ごとに、1 つの問題またはビジネスケースに対処する必要があります。
適切な範囲の選択: 除外の範囲が広すぎると、実際の問題が隠されて監査が困難になる可能性がありますが、除外が狭すぎると、不要な複雑さとメンテナンスが行われる可能性があります。
意図せずに重複する可能性のある命名パターンは使用しないでください。たとえば、名前が prod- で始まるリソースを除外すると、新しく追加された、まだ監視が必要な本番リソースもキャプチャされる可能性があります。
重複するアラートを抑えるためのショートカットとして除外を使用しないでください。たとえば、プロジェクト内のすべての「重大」の検出結果を除外します。代わりに、根本的な原因を調査するか、明確な正当性を定めて深刻度の変更を適用してください。

範囲

範囲を定義することで、除外が意図した場合にのみ適用されるようになります。

複数のアカウントまたはポリシーをカバーするような 広範な除外は、同じ条件が多くのリソースに当てはまる場合に、管理を簡素化し、反復作業を減らすことができます。ただし、広範な除外により、重要な検出結果が意図せずに非表示になるリスクも高まり、意図しないリソースが含まれる場合、監査がより困難になる可能性があります。
除外を狭くすると、より多くの制御と精度が得られます。これは、除外の理由が限られたリソースのセットにのみ適用される場合に便利です。ただし、狭い除外が多すぎると、時間の経過とともに追跡して維持することが難しくなる可能性があります。

組織のレビューとガバナンスのプロセスに適したバランスを選択します。各除外は、影響を制限する定義された条件を通じて検出結果を対象としています。

要素	説明
アカウント	除外を適用するアカウントを選択します。これは、組織全体に適用することも、特定のフォルダーまたは個別のアカウントに制限することもできます。
ポリシー	[すべてのポリシー] (All policies) を幅広く選択するのではなく、ビジネス上の理由に合致する特定のポリシーを選択します。関連のないポリシータイプ (IAM や EC2 など) を混在させると、重複が発生し、メンテナンスが複雑になる可能性があります。
リソース	除外がカバーするリソースを定義します。たとえば、名前が LabUs- で始まるすべての EC2 インスタンスや、us-east-1で env:dev というタグが付けられたリソースなどです。
深刻度	(オプション)除外を特定の深刻度の検出結果に限定します (たとえば、[低] または [中] の検出結果のみを無視し、[高] と [重大] は表示されたままにするなど)。

アクション

各除外によって、その条件に一致する検出結果の処理が決まります。

無視: 一致する検出結果のステータスを「オープン」から「無視」に変更します。検出結果を無視する場合、理由も指定する必要があります。
- 設計上: 構成は意図的なものであり、機能のために必要です。
- 例外: 検出結果は、修正が完了するまで一時的に許容されます。
- 誤検出: 検出結果が不正確または無関係であることが確認されました。
選択した理由は、無視された各検出結果の検出結果の表に表示される サブステータス にもなります。
深刻度の変更: 一致する検出結果の深刻度レベルを、選択したレベルに置き換えます。たとえば、[Critical] (重大) の検出結果を [Medium] (中) に変更します。これにより、問題の優先順位付けと報告方法を調整しながら、問題の可視性を維持できます。これは [除外] ページでのみ設定できます。

除外を作成する

ビジネス上の理由、範囲、およびアクションを定義したら、次のステップは除外を作成することです。この段階では、計画が作業ルールに変わり、一致する検出結果の深刻度を無視するか調整します。

除外は次の 2 つの場所で作成できます。

[除外] ページ (推奨): [除外] ページから除外を作成すると、一元化された可視化と完全なコントロールが提供されます。これにより、正確なフィルター、範囲、有効期限を定義して、各除外が明確なビジネスケースを反映し、正確で監査可能かつ保守可能なガバナンスをサポートするようにします。
検出結果を無視する: 選択した検出結果を特に対象とする除外を作成することで、検出結果を素早く無視できます。[検出結果] ページから作成された除外の作成はすぐに有効になります。これは、次のスキャンサイクルの前に特定の項目を非表示にする必要がある場合に適していますが、設定オプションは限られています。[検出結果] ページを頻繁に使用して結果を無視する場合は、一部の除外をより広く定義または調整する必要があることを示している可能性があります。

[除外] ページから除外を作成すると、組織全体の一貫性とビジネス目的との整合性を確保できます。次のスキャンサイクル後にターゲット検出結果が更新されます。

例: 除外を作成する

組織で複数のAWSアカウントを管理しています。そのうちの 1 つである Dev1 は、意図的にインターネットに公開されているテスト環境をホストしています。これらの EC2 インスタンスのほとんどは、ラボリソースの識別に使用される LabUs- で始まる命名パターンに従います。ただし、 JohnD という名前の手動で作成されたインスタンスも1つあり、同じテスト目的を果たしますが、規則に従っていません。リスクレポートを正確に保つためには、どちらも無視する必要があります。

これらの既知の非本番リソースからの繰り返しのノイズを回避するために、これらのインスタンスのすべての検出結果を無視する除外を作成することにします

ビジネス上の必要性: Dev1 アカウントの EC2 インスタンスへのパブリックアクセスは、テストのために意図されています。
目標: このパターンに一致する Dev1 のパブリック EC2 インスタンスの検出結果をすべて無視する。

除外設定:

名前: 既知のパブリック EC2 インスタンス
説明: QA によって使用されるパブリックにアクセス可能なテストインスタンス
アクション: 無視
検出結果タイプ: クラウド
ポリシー: パブリック EC2 インスタンス>特定のポリシー
リソース: 名前が LabUs- OR リソース名が JohnD
で始まる特定のリソース>- 有効期限: なし

除外を作成する方法

[ポリシー] > [除外] に移動します。
[組織] ドロップダウンでアカウント階層とフォルダーを選択します。デフォルトでは、組織全体 (すべてのアカウント) が選択されています。
[除外の追加] をクリックします。除外の作成後は、アカウントの範囲を変更できません。
名前と説明を入力します。
- 明確でビジネスに焦点を当てた名前を使用します (例: QA の公知の EC2 インスタンス)。
- 除外の理由または正当性を説明してください。
[アクション] で、検出結果が除外と一致した場合の動作を選択します。
- 無視: 一致する検出結果を [オープンの検出結果] リストから除外します。
  - 検出結果を無視する理由を入力します。検出結果が無視されると、サブステータスは [例外]、[設計による]、[誤検出] のいずれかになります。
- 深刻度を変更する: 一致する検出結果の深刻度を下げたり上げたりします。
ターゲットとなる検出結果の範囲を定義します。
1. タイプとして、クラウドまたは IaC を選択します。
2. [ポリシー] で、[すべてのポリシー] または [ターゲットとする特定のポリシー] を選択します。定義されたビジネスケースに一致する特定のものを選択することをお勧めします。
3. 必要に応じて深刻度フィルターを追加して、特定の深刻度の検出結果のみを含めることもできます。
ターゲットリソースを定義します。
以下の除外を作成する場合:
- クラウド: 関連するリソースを選択します。
- コード: パターンには次のワイルドカード文字を使用します。
  - アスタリスク * - 0 文字以上と一致
  - クエスチョンマーク ? - 1 文字と一致
    たとえば、パターン付きの名前 aol-*
[有効期限] で、[なし] または [有効期限] のいずれかを選択します。有効期限を過ぎると、除外は検出結果に適用されなくなります。他の除外がこれらの検出結果に影響を与えない場合、検出結果は再オープンされるか、深刻度が元に戻されます。
除外を作成する前に、設定を慎重に確認してください。[検出結果] プレビューパネルには、対象となるすべての未解決の検出結果が一覧表示されます。これを使用して、保存する前にフィルター、保持、範囲が意図した結果を正確にターゲットにしていることを検証します。
[保存] をクリックします。保存後、除外は次のスキャンサイクルで有効になり、一致するすべての検出結果が更新されます。

除外の管理

[除外] ページを使用すると、環境やビジネスニーズの変化に合わせて除外を確認および管理できます。定期的なレビューにより、結果を正確に保つことができ、古いルールによって有効なリスクが隠されるのを防ぐことができます。

除外を管理する方法

毎 月確認 し、各除外が現在の設定とリスク許容度を反映していることを確認します。
除外を編集し、必要に応じてフィルター、範囲、有効期限を更新します。
除外がカバーする検出結果が多すぎる場合は 、フィルターを厳格 にするか、焦点を絞った小規模な除外に分割します。
除外を一時的に無効にして、その影響を評価します。
有効期限が切れた、または有効なビジネスケースでなくなった除外を更新または削除します。
定期的に監査を行い、監査ログを使用して所有権、作成時間、正当性を検証します。

また、検出結果を無視するすることで、[検出結果] ページから直接除外を管理することもできます。除外の管理の詳細については、競合の解決と除外ステータスを参照してください。

[除外] ページに表示される内容

[除外] ページには、すべての除外とその設定、現在のステータスが一元的に表示されます。これは、組織全体で除外がどのように動作するかを検証し、除外が長期にわたって正確であることを確認するために使用します。

このページから、除外を作成、編集、複製、無効化、削除したり、除外を作成したユーザーと影響を受ける検出結果を確認したりできます。

テーブルの各行は、監査および管理に必要な重要な情報を含む 1 つの除外を表します。

縦棒	説明
名前	除外の名前。クリックすると、フルプロファイルが開きます。
説明	除外のビジネス上の理由または目的。
範囲	除外が適用される場所: 組織、アカウント、フォルダー
アクション	一致する検出結果に適用されたアクション: 深刻度を無視または変更します。
検出結果タイプ	検出結果のソース: クラウドまたは IaC。
ポリシー	すべて、または対象ポリシーのリストのいずれか。
有効期限日	除外の有効期限が切れる日付、有効期限がない場合はダッシュ (–)。
作成者	除外を作成したユーザー。
作成時間	除外が作成された日時。
ステータス	除外ステータス。
検出結果	現在除外の影響を受けている検出結果の数。クリックするとリストが表示されます。

除外ステータス

各除外には、システムでの現在の状態を反映するステータスがあります。[除外] ページの [ステータス] 列でこれらを表示し、各除外がどのように適用されているかを追跡します。

ステータス	説明
有効	除外が有効で、期限切れでない場合は、次回のスキャンに適用されます。除外の有効期限が切れると、他の除外が適用されない限り、検出対象の検出結果は再オープンされるか元に戻されます。
無効	除外は無効な状態ですが、再度有効にすることができます。
更新を保留中	変更があったため、次回のスキャンで更新されます。
無効化を保留中	このあと無効になりますが、スキャンが完了するまでは有効な状態です。
削除の保留中	削除のキューに登録されています。スキャンが完了するまでは有効な状態です。

既存の除外に追加するためのルール

[検出結果を無視] ダイアログを開いて [既存の除外に追加] を選択すると、ドロップダウンに選択した検出結果と互換性のある除外のみが表示されます。

これにより、検出結果は、タイプ、ポリシー、範囲に一致する除外にのみ追加でき、競合や意図しない動作を防ぐことができます。

次のすべての条件が満たされた場合にのみ、除外がドロップダウンに表示されます。

ルール	説明
書き込みアクセス許可	除外の範囲に対する書き込みのアクセス許可がある
アクションを無視に設定*	除外のアクションは [無視] (Ignore) に設定されています。
検出結果タイプ	除外の検出結果タイプ (クラウドまたは IaC) が、選択した検出結果と一致します。
ポリシーの一致	除外は、選択した検出結果とまったく同じポリシーを対象とします。
単一ポリシーの範囲	除外は 1 つのポリシーに適用され、複数のポリシーには適用されません。
深刻度フィルター	除外には定義された深刻度フィルターがありません。
一括選択ルール	複数の検出結果が選択されている場合、すべてが同じポリシーからのものである必要があります。

競合の解決

場合によっては、複数の除外が同じ検出結果を対象にできます。この場合、優先度は範囲と 作成時間によって決定されます。

除外は、アクションごとに個別に評価されます (深刻度は無視または変更)。検出結果には、アクションタイプごとに 1 つずつ、合計 2 つのアクティブな除外を含めることができます。

同じアクションの複数の除外が同じ検出結果をターゲットとする場合、優先順位は次の順番になります。

範囲の特異性: より明確な除外が優先されます。たとえば、アカウントレベルで定義された除外は、組織レベルで定義された除外よりも優先されます。
作成時刻: 2 つの除外が同じ範囲とアクションを共有する場合は、最初に作成された除外が優先されます。