Zenn
Septeni Japan Tech BlogPublicationへの投稿
🔒

ControlTower導入の話(SecurityHub編②)

市原 地円
2024/04/11に公開
AWS
infra
Control Tower
tech

はじめに

Septeni Japan株式会社でプロダクト開発&インフラセキュリティ対策を行っている市原と申します。
この記事は、社内のプロダクトに対してセキュリティのガバナンスを効かせる為にAWS Control Towerを導入した話となります。
Control Tower導入の話は下記のパートに分かれて記事を執筆しています。

今回はSecurityHub編②となります。

運用の前置き

SecurityHubには全289個のコントロールが存在します。
このコントロールのうち、インフラチームにて適用すべきものを選別した状態で運用を開始します。
運用が開始されると、AWSアカウントごとにSecurityHubが自動でリスクを検出します。
検出されたリスクはslackによって各AWSアカウントのチャンネルに通知されます。

通知のアーキテクチャ図


  • 通知先のslackチャンネルをプロダクトごとに設定

リスクが通知された際の対応手順

  1. 対象の AWS アカウントにログイン

  2. slackの通知文面のコントロール画面URLから管理画面に遷移
    SecurityHub

    GuardDuty

  3. タイトルをクリックして、詳細を確認
    SecurityHubの場合、詳細画面下の改善リンク、または、slack通知文面の対策レコメンドURLから、対応方法についてAWSからレコメンドがあります。

  4. リスクへの対応
    通常対応
    原則、検出されたリスクにはシステム変更などを行い、対応した後にワークフローステータスを解決済みに変更して完了となります。
    解決済みの場合、変更後にAWSリソースの状態が変わると、再度ワークフローステータスがNEWで検出されます。
    例外対応
    対応すると場合によっては追加開発などが発生する可能性がありますが、開発スケジュールや対応工数など鑑みて敢えて対応しないという判断をした場合は、抑制済みに変更して完了とします。
    なお、抑制済みの場合、変更後は検出結果に上がらなくなる為、セキュリティリスクを抱えることになります。
    当社では抑制済みにする場合、背景などをインフラチームと対話した後に行うようにしています。
    例
    静的ファイルをS3でホスティングし、WEBページを公開している場合
    S3 buckets should prohibit public read accessによって検出されてしまいます。この場合の対応としては下記のどちらからで行います。

    • S3でホスティングしているコンテンツを直接公開するのではなく、CloudFrontなど別のAWSサービスを使い、セキュアな状態で公開できるようにシステムを構築し直した後に解決済みにする
    • 対応工数やプロダクトのライフスパンなどを鑑みて、敢えて対応しないと判断する場合は抑制済みにする

    注意点
    リスクの検出は設定が一瞬でも外れると検出される為、例えば、一時的に設定を変更し、すぐに戻した場合でも検出されてしまいます。
    なお、一時的に変更をした瞬間に通知が行われますが、設定を戻した際にリスクのある状態ではなくなる為、管理画面にてコントロールの状態を確認するとARCHIVEDとなっているという状態になります。
    その場合は、リスクが回避されている状態のため、ワークフローステータスの変更などの対応は不要となります。

    当社の場合、Terraformを使ってインフラの設定を行っているチームがあるのですが、Terraformが上記のように、一時的に変更し、すぐに戻すといった挙動を行っていて、上記のような現象が確認されました。
    補足
    GuardDutyはSecurityHubを経由してSlack通知しています。GuardDutyは重要度でフィルタリングはできない仕様のため、重要度の異なるものが通知される可能性があります(2024/02/04時点)

セキュリティスコアとステータス


設定したコントロールは失敗･不明･成功･無効･データなしの4つのステータスに分類されます。詳しくは次のステータス条件の項で説明します。

ステータス条件

レコードの状態がARCHIVEDとワークフローのステータスがSUPPRESSEDである検出結果は無視されます。特にレコードの状態については、検出時と現在が異なる状態にある場合に、ARCHIVEDへ変化します。当社のようにslack通知など、別のシステムへ連携している場合、状態が変化しているかどうか確認が必要になります。
また、ワークフローのステータスがRESOLVEDの場合は、他のステータスによらず成功になります。

成功になるパターン

すべての検出結果のコンプライアンスステータスがPASSEDである時

失敗になるパターン

少なくとも1つの検出結果のコンプライアンスステータスがFAILEDである時

不明になるパターン

少なくとも1つの検出結果のコンプライアンスステータスがWARNINGまたはNOT_AVAILABLEである時(コンプライアンスステータスがFAILEDのものは含まれない)

データなしになるパターン

コントロールの結果がない時

無効になるパターン

現在のアカウントとリージョンでコントロールが無効になっている時

注意点

検出されたコントロールを通知済みのまま放置したり、闇雲に抑制済みしてしまうと、ステータスが不明で上がってしまい、セキュリティスコアが正しく機能しなくなる。

We are hiring

Septeni Japanでは、一緒にプロダクト開発組織を盛り上げてくれる仲間を募集しています！
ご興味のある方は以下リンクから応募していただき、カジュアル面談を通じて働く環境や仲間を知っていただければと思います！

その際、応募フォームの「知ったきっかけ」に「テックブログ」と記載いただければと思います。
https://septeni-recruitment.snar.jp/jobboard/detail.aspx?id=D3Sa2fnGT-Q5Qe8T-ivLbg

Septeni Japan Tech Blog
Septeni Japan Tech BlogPublication

Discussion