AWS Security Hubの導入からうまく運用を回すまでのTips / 開発者向けブログ・イベント

こんにちは、GMOインターネットグループ株式会社システム統括本部ホスティング・クラウド開発部アプリケーション共通チーム（技術推進チーム/AWS運用チーム）の井本です。

弊社では、AWS環境におけるセキュリティ強化の取り組みを随時実施しております。今回は、直近で実施したセキュリティ統制の取り組みである「AWS Security Hubの導入」について、ご紹介させていただきます。

はじめに

みなさんは、Security HubやGuardDuty, Trusted Advisorなどを導入したものの、「各チームにご対応いただけない」、「通知が来すぎてしまう」など、うまく運用を回すことができないという状況に直面したことはないでしょうか？

今回は、Security Hubの横断導入に際して、得られた知見をご共有させていただき、ぜひみなさんが導入・運用改善される際の参考にしていただければと思います。

AWS Security Hub導入の背景

弊社では、従来オンプレミスで運用を行っていた際はもちろん、Security HubやGuardDuty, Trusted Advisorなどの導入は行っておらず、「GMOサーバーセキュリティ by イエラエ株式会社」の「クラウドプラットフォーム診断」を実施させていただり、社内で策定したセキュリティガバナンスに基づいているかを定期的にチェックする、あるいは、問題が発生した（発生してそうと判明した）ときに、手動で検知して対応するしかありませんでした。

そこで、自動的にセキュリティ上の問題を検知・集約化してくれるSecurity Hub導入への機運が高まり、導入に行った次第でございます。

各開発・運用チームに対応いただくための取り組み

コントロールの精査

コントロールとは、Security Hubのセキュリティ基準における各セキュリティ項目を指し、何の優先度も付けず、すべてを片っ端から対応を進めていくのは生産的ではないため、弊社では下記のような分類に基づき、優先度付けや対応方針を策定しました。

なお、弊社で導入しているセキュリティ基準は２つであり、「AWS 基礎セキュリティのベストプラクティス v1.0.0」と「CIS AWS Foundations Benchmark v1.4.0」です。

「AWS 基礎セキュリティのベストプラクティス v1.0.0」では、下記４種類の対応方針を定めています。

◆是正まで追跡
　・期限を設定し、検知項目が是正されるまでAWS運用チームが追跡する
◆通知のみ
　・ユーザーに通知のみ、是正するかは任せる
　・通知したら抑制済みとし、セキュリティスコア対象外
◆対応しない
　・対応する必要なし、抑制済みにする
◆無効化
　・コントロールを無効化にする

「CIS AWS Foundations Benchmark v1.4.0」については、弊社の使っていなサービスに関する項目や対応が難しそうな項目は「無効化」し、それ以外のすべてのコントロールを「是正まで追跡」と定めています。

また、「AWS 基礎セキュリティのベストプラクティス v1.0.0」については、下記の分類により対応方針を定めています。

◆必須サービス
　・必須で有効化すべきサービスや必要な設定
　・サービスや設定毎の特徴があるため、実際はコントロール個別での判断が多い
　・対応方針：是正まで追跡
◆可用性確保
　・マルチAZやバックアップなど
　・セキュリティといえばセキュリティだが、今回のスコープでは特に幅の広い要素
　・厳密なセキュリティ要件ではないため管轄外
　・対応方針：対応しない
◆ロギング
　・サービスのログ保存など
　・本番環境の大体のログは必須とする
　・対応方針：是正まで追跡
◆通信中の暗号化
　・TLSを利用するもの
　・現代のインターネットでは必須
　・対応方針：是正まで追跡
◆保管時の暗号化
　・KMSなどを利用したストレージ上の暗号化
　・ポリシーと規制要件のためここでは管轄外
　・対応方針：対応しない
◆使用なし
　・現状、使用していないサービス
　・検知ステータス：データなし
　・対応方針：無効化
◆その他
　・セキュリティ要件から外れるログの適用等は対応しない
　　‐VPCフローログとか
　　‐ログだけ運用されないといった事象につながるので必須にはしない
　・WAF適用は本番で通知のみ
　　‐WAFが不要な対象もあるため、WAF入れてないけど大丈夫かの確認だけ通知する
　・OS以上のレイヤーの脆弱性管理は管轄外
　　‐SSMパッチコンプライアンスなど、別で管理する場合も多いため
　　‐AWS環境のセキュリティを維持する目的からは外れる

なお、重要度が「CRITICAL/HIGH」、かつ上記の分類が「是正まで追跡」となっているコントロールはそのまま「是正まで追跡」とし、重量度が「MEDIUM/LOW」、かつ上記の分類が「是正まで追跡」となっているコントロールは「通知のみ」と定めています。また、それ以外の対応方針（「通知のみ」/「対応しない」）は、重要度に関わらず、上記の分類に基づいた対応を実施します。

これらのコントロール別の対応方針は、DynamoDBの「対応方針テーブル」に保存しておき、セキュリティ上の問題検知後、それぞれの対応方針に応じて、対応が実施されます。

通知周りの実装・設定

通知周りの実装は、うまく運用を回す上で、最も重要な部分です。

まずは、Security Hubの検出結果をAmazon EventBridgeにより取得し、その取得結果をStep Functionsに流します。

私が設定しているEventBridgeのルールにおける、イベントパターンは下記の通りです。

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Compliance": {
        "Status": ["FAILED", "WARNING", "NOT_AVAILABLE"]
      },
      "RecordState": ["ACTIVE"],
      "Workflow": {
        "Status": ["NEW"]
      }
    }
  }
}

ここで特筆すべき事項としては、findingsのComplianceのStatusが「FAILED/WARNING/NOT_AVAILABLE」、WorkflowのStatusを「NEW」に限定している点です。

これにより、新たに検知された問題のあるセキュリティ項目のみを取得することができます。

取得されたセキュリティ項目は、下記のStep Functionsにより、対応方針に応じた処理が実行されることになります。

また、その対応方針が「是正まで追跡」である場合は、DyanamoDBに登録したアカウントテーブルからそのアカウントの担当者情報などを取得し、その結果をもとにSlack通知やチケット記票（後述）を行います。

通知の実装をする際には、EventBridgeから取得したデータを基にして、Amazon SNSとAWS Chatbotを使用することで、Slackチャンネルへの検出結果の送信が非常に簡単にできます。

しかし、デフォルトでは英語で通知、詳細な条件分岐によるメッセージの変更など、カスタマイズ性が悪く、今回の要件とはマッチしなかったため、弊社ではAWSに関する通知周りの実装を行う際はLambdaを利用するケースが多いです。

なお、今回対応方針を「通知のみ」に定めたコントロールに関しては、Security Hubの定期的なチェックのタイミングで通知するのではなく、月次サマリとしてすべての対応状況と併せて通知するようにしています。

当初は、対応方針が「通知のみ」のコントロールについても、Security Hubの定期的なチェックのタイミングで通知するように実装を行っていたのですが、「是正まで追跡」を実施するコントロールがSlack上で流れてしまい、管理がしにくくなってしまう懸念が生じたため、仕様変更を行いました。

（チャンネルを分けて、対応方針が「通知のみ」専用の通知用チャンネルを作るという選択肢もなくないですが、みなさんご存じの通り、そのようなチャンネルはまあ見ることはないですよね、、）

月次サマリを実装する際ですが、Security HubのセキュリティスコアをAPI経由で取得する手段はないため、boto3から各コントロールの「成功/失敗」を取得して算出するようにしています。

月次サマリのメッセージのサンプルは下記の通りであり、これだけでは詳細は分かりかねるものの、Security Hubのコンソールや対応状況管理チケットへの導線として機能するようにしています。

※数値は仮のものを使用しております

2024年4月1日現在のSecurity Hub検知状況をお知らせいたします。

◆CIS AWS Foundations Benchmark v1.4.0
　・CRITICAL：0
　・HIGH：0
　・MEDIUM：3
　・LOW：5

◆ AWS 基礎セキュリティのベストプラクティス v1.0.0
　・CRITICAL：0
　・HIGH：0
　・MEDIUM：8
　・LOW：10

なお、上記の検知結果は失敗件数でございます。

CIS AWS Foundations Benchmark v1.4.0およびAWS 基礎セキュリティのベストプラクティス v1.0.0の「CRITICAL/HIGH」については、対応必須ですので、期日までのご対応をお願いいたします。

是正までの管理方法

弊社では、対応方針が「是正まで追跡」のコントロールに関しては、Slack通知とともに、自動的に社内のチケット記票を行い、そのチケットを利用して対応状況を管理できる仕組みを構築しています。

なお、上記チケットは弊社では、GMOチケットと呼んでおり、普段のプロジェクト管理にも利用しているため、様々なツールや機能がもともと用意されておりますが、ない場合はどのように対応状況を管理していくかを検討する必要があります。

なお、検出結果に基づく通知するメッセージのサンプルは下記の通りであり、各開発・運用チームは検出されたメッセージを確認して、参考URLから検出された原因やネクストアクションを確認することができます。

最終行に記載がある通り、商材やセキュリティ診断などの事情により許容すべき場合もあるので、その際はスレッドにその旨を記載いただき、ご相談させていただくような形式にしています。

タイトル：重要度: LOW (S3.13) S3 バケットでは、ライフサイクルポリシーを設定する必要があります
対応期限：２週間以内に対応してください
対象
◆AWSアカウント：<Account Name>（<Account ID>）
◆リージョン：ap-northeast-1
◆リソース：<Resource>
◆参考URL： https://docs.aws.amazon.com/console/securityhub/S3.13/remediation
◆許容すべき設定の場合はこのスレッドでメンションをつけて理由を説明してください

委任アカウントでの運用

Security Hubでは、権限を委任することで委任アカウントに、検出結果や通知の実装などを集約することが可能です。

しかし、標準機能では、委任アカウント側からコントロールの有効/無効を変更しても、その変更はメンバーアカウント側に伝搬することができません。

そこで、aws-samplesにて公開されているcontrol-disablerというソリューションを導入することで、この問題を解決することができました。

ただし、Security Hubの機能の１つである検出項目の自動修復については、Terraformによりリソースを管理しており、そのstateファイルと不整合が生じる可能性が高く、弊社では利用しておりません。

目下のセキュリティ施策

私たちが実施している目下のセキュリティ施策の一部について、ご紹介させていただきます。

現在、弊社では「継続的な運用」をテーマに、本記事のようなSecurity Hubの通知周りの整備を行ったように、AWS Trusted AdvisorやAmazon GuardDutyについても同様に集約アカウントで管理し、何か悪意のあるアクティビティや異常な動作をモニタリングして、自動で重要度に応じた通知する仕組みを実現しようとしています。

また、オブザーバビリティ向上のために、ログ最適化やX-Rayの導入、障害予測・検知ためにAmazon DevOps GuruのPoCを実施しております。

まとめ

セキュリティ施策を実施する上で、重要なのは目的から逆算して、必要な施策を行うことです。
ここでの目的とは、セキュリティ上の問題に対して、完璧に０にすることはできなくとも、限りなく０にするために、コスト見合いを行いながら、対応を継続的に行っていくことです。

AWS環境を利用していれば、往々にして「Security Hubを導入しましょう」「GuardDutyを導入して悪意のある動作を検知しましょう」といったサービスの導入部分にフォーカスされた会話になりがちですが、重要なのは導入することが目的なのではなく、継続的にそのサービスを利用して対応を進めていくことです。

しかし、それでもなお、「発見的統制」「予防的統制」「障害予測・検知」において、対策できていない箇所があれば、新たにAWSのサービスや他のツールの導入を検討しましょう。