発見的統制内容説明(AWS編)
2023/03/06 公開
本書はガバメントクラウド(AWS)における発見的統制の実装方式および活用方法を理解するための文書である。
発見的統制の全体像
発見的統制とはリソースが不正な状況になっていないかを継続的に監視し修正する機能である。
ガバメントクラウド(AWS)では、Security Hub、GuardDuty、Control Tower、Config Rulesおよび、ガバメントクラウドで作成した環境の自動棚卸し機能を使用し、発見的統制を実現している。
また、前述のサービスにより検出された結果に加え、EventBridge、CloudTrailで通知の必要があるイベント、文字列を発見した場合は、メール、Slack(任意)によって利用システム管理者に通知が行われる。
図001 発見的統制の全体像
統制内容
発見的統制に抵触する操作、設定が行われた場合、発見的統制を構成するサービスはそれを検知し、ダッシュボードへの表示と利用システム管理者への通知を行う。本項ではサービスごとの統制内容を記述する。
Security Hub 統制内容
ガバメントクラウド(AWS)では以下のセキュリティ基準が有効化されており、セキュリティ基準内のコントールは全て有効化されている。
- AWS 基礎セキュリティのベストプラクティス v1.0.0
- CIS AWS Foundations Benchmark v1.2.0
※管理組織側の判断でセキュリティ基準の最新化、一部ルールの無効化が行われる可能性がある。
[AWSドキュメント:AWS Security Hub のセキュリティ標準とコントロール] (https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-standards.htmlOpens in new tab)
GuardDuty 統制内容
ガバメントクラウド(AWS)では、GuardDuty を使用し、継続的なセキュリティモニタリングを行う。設定内容はGuardDutyを有効化したのみで、その他はデフォルトとなっている。GuardDutyの詳細は以下を参照。
[AWSドキュメント:Amazon GuardDuty とは] (https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/what-is-guardduty.htmlOpens in new tab)
※管理組織側で中央管理しており、以下の設定追加の依頼は他システムへ影響があるため個別対応できない。
また、記載されていない設定に関しても対応できないのものあるためGCASヘルプデスクから問い合わせること。
- Trusted Entity list
- Threat Entity list
Control Tower 統制内容
ガバメントクラウド(AWS)では、Control Tower の機能である発見コントロールを使用し、ポリシー違反など、アカウント内のリソースの非準拠を検出し、アラートを提供する。
- 発見コントロールはガイダンスが「必須」であるものが有効化されている。コントロールについては以下を参照。
[AWSドキュメント:AWS Control Tower のコントロールについて] (https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/controls.htmlOpens in new tab)
- 有効化されるコントロールは、ランディングゾーンのバージョンアップに伴い増減する可能性がある。バージョンアップは影響範囲を確認し、破壊的変更がなければ事前に利用システム側へ周知後、実施する。破壊的変更がある場合は、影響範囲と対策を周知後に実施する。
また、アップデートは検証環境アカウント/本番環境アカウントと段階的に実施する。
Config Rules 統制内容
ガバメントクラウド(AWS)では、Config Rulesを使用し、ポリシーに違反する設定を検知して通知、さらに追加で是正を行う。
- Security Hubのコントロール及びControl Towerのコントロールを有効にした際に作成されるルールについては、それらのサービスの項で記述する内容と同義であるため、本項では除外する。
| ルール名 | 内容 | 対応方法 |
|---|---|---|
| bb-default-security-group-closed | VPC のデフォルトセキュリティグループから、すべてのインバウンドルールおよびアウトバウンドルールを削除する。 | 自動で処理されるため、対処は不要。 |
環境の自動棚卸し 統制内容
ガバメントクラウド(AWS)では、ガバメントクラウドで作成した環境の自動棚卸し機能によって利用システムの環境を参照し、リソースに対するインターネット接続の有無を変更する設定を検出した場合、利用者へ通知する。利用システムの管理者による環境の適正性の評価を補助することが目的である。
| 対象 | 発見的統制の内容 | 目的 |
|---|---|---|
| ネットワーク構成情報 | 接続経路にインターネットへの接続が追加・削除された場合に通知する。 | 利用システムにおけるリソースのネットワーク構成情報を棚卸して、外部との通信先を明確化することで、通信が適切な接続先に限定されていることを評価し、情報漏洩の未然防止を図るため。 |
発見時のアクション
発見的統制によって検出された結果に対し、利用システム管理者は適切な対処を行う。本項では通知の受信、または日次/週次チェックによる事象の発見の際のワークフロー及びサービスごとの検出結果に対する対応について記述する。
- メールまたはSlackからの通知を受信した場合、Security Hubのダッシュボードを確認して同じ時間帯に発生している事象を把握する。事象の全体像を把握後、GuardDutyなどの各サービスのダッシュボードを確認する。各サービスの対応の詳細については個別のサービスの項を参照。
- 緊急性が低い事象の場合、通知は行われない。そのため、日次/週次でSecurity Hubのダッシュボードの確認を行い、新規発生した事象を発見した場合は対応の要否、検出結果の抑止などの対応を行う。対応が必要な場合は、通知による発見時と同様、詳細を確認して対応を行う。
- 各省庁ごとのワークフローを策定する際の参考として、以下に事象発生時からクローズまでのワークフロー例を示す。
図002 事象発生時のワークフロー例 - Security Hubダッシュボードでの確認時、検出結果の重要度によって対応を変える必要がある。以下に、ワークフロー例から重要度による変化がある部分を抜粋した対応パターンを示す。
尚、パターン中の対応優先度[高][中][低]の詳細は後述の事象発見時の重要度別対応詳細 を参照。
図003 重要度別対応パターン
事象発見時の重要度別対応詳細
| No | 対応優先度 | Security Hubの重要度 | 対応方針 |
|---|---|---|---|
| 1 | 低 | INFORMATIONAL、LOW | INFORMATIONALはセキュリティ基準に準拠状態であることを確認するための結果であり、 推奨される対応なし。LOWはフォレンジック情報の収集に失敗した場合などが該当。 侵害に直接つながらないため、対応の必要があるかどうか判断する。対応の必要があると判断された場合は、 対応優先度[中]と同様の対応を行う。対処不要であれば検出結果の抑止設定を行い、以後通知されないようにする。 |
| 2 | 中 | MEDIUM | 転送中のデータの暗号化が欠如している場合などが該当。 高度な中間者攻撃など、やや難しい攻撃手法となるが、脅威シナリオが成功すると、 一部のデータが侵害される可能性がある。チケットなどで管理し、週次定例などで定期的に対応を検討する。 緊急性が高いと判断されたものは臨時メンテナンスで対応し、それ以外は定期メンテナンス、 新バージョンのリリース時などのタイミングで対応する。 |
| 3 | 高 | HIGH、CRITICAL | HIGHはデフォルトの VPC セキュリティグループがインバウンドおよびアウトバウンドトラフィックに対して開かれている場合などが該当。 MIDIUMに比べ、簡単な攻撃手法で侵害が可能なため、重要度が高くなる。 CRITICALは公開された S3 バケットなどが該当。公開された S3 バケット内のデータは、 他者によって発見およびアクセスされる可能性があり、重要度が非常に高くなる。 HIGH、CRITICALの結果への対応は、緊急性が高く、脆弱性や攻撃の痕跡の発見、設定の不備などの種類にかかわらず、 可及的速やかに対処する必要がある。 臨時メンテナンスを実施し、CDKやプログラムのコード修正及びリリースなどの対処を行う。 対処が遅れた場合、対処範囲の拡大、より上位層へのエスカレーションの発生など、 発見時よりさらに深刻な事態に進行する恐れがある。 |
Security Hub 発見時のアクション
Security Hubのダッシュボードは複数のソースからアラートを集約するため、事象の全体像を把握に役立つ。ただし、製品がSecurity Hubではないアラートには全ての情報が含まれるわけではないため、詳細を確認するためには事象のソースとなる製品、リソースを確認する。
対処が不要な事象の場合、以後の通知を抑止するため、ワークフローのステータスを「抑制済み」に変更する。
[AWSドキュメント:結果のワークフローステータスを設定する] (https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/finding-workflow-status.htmlOpens in new tab)
GuardDuty 発見時のアクション
Security Hubで確認したアラートの事象の製品がGuardDutyだった場合、GuardDutyのダッシュボードに移動して詳細を確認する。
- 確認後の第一段階として、まず対処が必要な事象かどうかを判断する。対処が不要な場合、その理由を明記した管理簿などを作成し、以後対応しないよう管理する。
- 対応が必要である場合、または調査を行わなければ対応の要否が不明の場合は、事象の発生しているリソースを確認し、ログの調査や再現の検証などを行い、原因と対応方法を特定する。
Control Tower 発見時のアクション
Control Towerの発見コントロールの実態はConfig Rulesであるため、Config Rules 発見時のアクション を参照。
Config Rules 発見時のアクション
Security Hubで確認したアラートの事象の製品がConfigだった場合、Configのダッシュボードに移動して詳細を確認する。
- 確認後の第一段階として、まず対処が必要な事象かどうかを判断する。対処が不要な場合、その理由を明記した管理簿などを作成し、以後対応しないよう管理する。
- 対応が必要である場合、ルール内容と事象の発生しているリソースを確認し、ルールに準拠するようにリソースを修正する。
通知
発見的統制に抵触するアクション、設定が検出された場合、あるいは通知が必要なイベントや文字列が検出された場合、利用システム管理者に通知が行われる。本項では通知に関する方式や設定について記述する。
通知受け取り方式例
通知はメール、slackで行われる。ただし、slackは必須適用テンプレート適用時に任意で除外することができる。詳細は、GCASアカウントを取得の上、GCASガイド(メンバー専用ページ)で公開されている自動適用テンプレート(メンバー専用ページ→ガバメントクラウドテンプレート/ポリシー→ガバメントクラウドテンプレート/ポリシーのダウンロードページ)の内容を確認すること。
- 通知は以下の条件に該当する事象が発生した場合に行われる。
| No | サービス名 | 通知対象 |
|---|---|---|
| 1 | Health | 全てのイベント |
| 2 | EventBridge | セキュリティグループのルール追加/削除、CloudTrailの停止などの重要度の高いイベント |
| 3 | CloudTrail | アクセス拒否、許可されていない操作などの重要度の高い文字列 |
| 4 | Security Hub | 重要度がCRITICAL、HIGHの事象の検出 |
| 5 | GuardDuty | 重要度の値が4.0~8.9(中~高)の事象の検出 |
通知先設定
通知先となるメールアドレス、slackのチャンネルIDは必須適用テンプレート適用時に設定ファイルに記述する。詳細は、GCASアカウントを取得の上、GCASガイド(メンバー専用ページ)で公開されている自動適用テンプレート(メンバー専用ページ→ガバメントクラウドテンプレート/ポリシー→ガバメントクラウドテンプレート/ポリシーのダウンロードページ)の内容を確認すること。
改訂履歴
| 改訂年月日 | 改訂理由 |
|---|---|
| 2023年03月06日 | 新規作成 |
| 2023年12月04日 | 「ガードレール」から「コントロール」に名称変更に伴う修正 |
| 2024年07月19日 | 文言修正 |
| 2024年09月02日 | 文言修正 |
| 2025年02月14日 | コントロールの無効化に関する記載を削除 |
| 2025年03月28日 | 「Control Tower 統制内容」の内容修正 |
| 2025年11月14日 | 「GuardDuty 統制内容」の内容修正 |
| 2025年12月17日 | 「環境の自動棚卸し 統制内容」を追加 |