はじめに
こんにちは、Money Forward CISO室の万萌遠（バン・ホウエン）です。私は主にAWSセキュリティ統制システム「A-SAF(AWS-Security Alert Forwarding system)」の企画、開発、運用を担当してきました。運用も安定してきたので、今回はA-SAFシステムの紹介と、AWSをはじめとしたクラウド環境のセキュリティ統制についての心得を共有したいと思います。
A-SAFを作るモチベーション
クラウド環境のセキュリティといえば、CSPM（Cloud Security Posture Management）、CWPP（Cloud Workload Protection Platform）、CNAPP（Cloud Native Application Protection Platform）などが思い浮かぶかもしれません。ですが、今回ご紹介するA-SAFはこれらのツールの代替品ではなく、セキュリティ担当者とプロダクト担当者の架け橋となるシステムです。
EDR（Endpoint Detection and Response）、WAF（Web Application Firewall）、SIEM（Security Information and Event Management）、IDS/IPS（Intrusion Detection System / Intrusion Prevention System）などのセキュリティ製品を運用する際には、社内外のSecurity Operation Center（SOC）を含めたセキュリティ担当者がアラートを一元的に監視し、トリアージ後にインフラ担当者やプロダクト担当者と連携して対応するという方法が一般的です。しかし、シフトレフトやプロダクトセキュリティの観点からは、コンテナセキュリティ、ソースコードセキュリティ、サプライチェーンセキュリティ、クラウドセキュリティ、クレデンシャル管理などの課題については、セキュリティ担当者による一元的な管理は現実的ではありません。
企業の規模が小さく、AWSアカウント数やプロダクト数が一桁であれば、セキュリティチームがまとめてCSPMの検出を監視する方法でも運用が回るかもしれません。しかし、企業規模が大きくなり、例えば弊社のように複数の事業を持ち、AWSアカウントが400個以上もある状況になると、セキュリティチームによる一元的なアラート管理は非常に困難になります。なぜなら、伝統的なSOCではセキュリティチームがアラート内容に詳しい一方で、プロダクト/クラウド設定で検出されたアラートはそもそも意図的かどうかはプロダクト担当者でないとわからないことが多いからです。
そこで、このような問題を解決するためにA-SAFが誕生しました。開発サイクルで大量に検出された脆弱性をプロダクト担当者に能動的にトリアージしてもらいつつ、セキュリティ担当が改善に向けた支援とレビューを担当します。
A-SAFの仕組み
下図はA-SAFのおおまかな仕組みです。その他、週次で検出結果のサマリーを通知する機能もありますが、ここでは割愛します。
[図] 全体アーキテクチャー
AWS Security Hub（以下、Security Hub）に集約されたAmazon GuardDuty（以下、GuardDuty）、AWS Config、AWS Identity and Access Management Access Analyzer （以下、IAM Access Analyzer）などのアラートをAWS Lambda（以下、Lambda）を使ってJiraに起票します。同時に、各アカウントの責任者が所属するSlackチャンネルに通知します。注目していただきたいのは、セキュリティ担当者とプロダクト担当者の協力関係です。プロダクト担当者が通知を受け取った後、Jiraのチケットの解決に取り組みます。
[図] アラートチケットをクローズするワークフロー
[図] アラートチケットを無視/抑制する時のワークフロー
各コンポーネントの選定理由
A-SAFはアラートソース、処理、通知、チケッティングという四つの大きなコンポーネントから構成されています。それぞれのコンポーネントを選んだ理由は下記となります。
アラートソース
Security HubはAWSのネイティブCSPMサービスとして、AWSの他のセキュリティサービスからのアラートを簡単に集約でき、かつ検出結果を標準化されたデータ形式（AWS Security Finding Format, ASFF）に整形してくれるメリットがあるため、Security Hubをアラートのソースとして選定しました。
処理
処理はMVC(Model/View/Controller)で言うとControllerの部分にあたります。CSPMから流れてきたアラートメッセージの処理は、AWSのSQSとLambdaを使っています。
通知
弊社はSlackを社内コミュニケーションツールとして使っているので、通知はSlackbotにより行います。
チケッティング
本来、Security Hubにはセキュリティスコアや概要のダッシュボード、簡易的なチケット管理機能が備わっています。ただ、チケット管理に特化したシステムではないため、痒いところに手が届かず、チケッティングシステムとしてJiraを選定しました。Jiraのメリットとしては以下のとおりです。 1. 共同作業をワークフローで制御できる 2. MVCモデルにおけるModel（DB）の役割を果たしてくれる 3. MVCモデルにおけるViewの機能も担ってくれる
代替コンポーネント
筆者はどの製品や技術を使うかにこだわりはありません。むしろベンダーロックを避けるため、いくつかの代替案も考えています。例えば：
- アラートソースとしてSecurity Hubの代わりに、オープンソースまたは有料のサードパーティCSPMツールを使用する。
- 処理ではSQSやLambdaの代わりに、Google CloudのCloud Pub/SubとCloud Functionsを使用する（実際、弊社のGoogle Cloud環境のSAFシステムではこちらを使っています）。
- 通知システムもSlackにこだわる必要がないため、Teamsなどの他サービスに対応する。
- チケッティングシステムはNotionやAsanaを利用する。
効果
弊社の400を超えるAWSアカウントでは、当初12,000件を超えるアラートがありましたが、半年をかけて40%以上のアラートを削減できました。その中でも、弊社のとある組織が管理するAWSアカウント群の進捗状況はとりわけスムーズでした。例として各種グラフを見てみましょう。
可視化
こちらの組織が管理するAWSアカウント数は30以上です。
[図] 解決状況の推移グラフ
アラート解決を始めた当初は、556件のアラートがあったとグラフ上に表示されていますが、AWSのリソースが削除された場合にJira上のチケットも自動的に消す仕様にしていたため、一部のチケットは統計グラフに反映できていません。実際のところ、当時の728件のアラートから132件に削減し、おおよそ半年間で81%以上のアラートが解決できました。お気づきの方もいるかもしれませんが、A-SAFによってアラートの削減ができただけではなく、不要なリソースの削除、コストの削減にも貢献できています。
[図] 残っているアラート数の多いアカウント
このグラフを確認することで、どのアカウントの進捗状況が良くないかがわかり、サポートが必要なアカウントが一目瞭然となります。
[図] AWS Configのルール別のアラート数
このグラフを見ればどのルールのアラート数が多いかがわかります。ルール間には解決の優先度の差があり、例えばIAM UserやAccess Keyに関するルールの検出数が上位にきた場合、それはIAM Userが乱立していることを示唆しており、注意が必要になります。
Slack通知
Slackに送る通知も見てみましょう。
[図] 週次サマリーを各プロダクトチームのチャンネルに送っている
[図] 各チャンネルに送るGuardDutyアラートの例
上図のように、週次サマリーとリアルタイム通知の両方を活用して、各プロダクトチームに情報を提供しています。
ワークフローによるレビュー
前述のように、アラートのハンドリングはセキュリティ担当者とプロダクト担当者の共同作業が望ましいです。緊急度が高くないアラートに関しては、基本プロダクト担当者に初動対応を任せ、能動的にアラートを解決してもらっています。ただし、プロダクト担当者の改善対応が十分とは言えない可能性もあるため、プロダクト担当者だけの判断でアラートをクローズできないよう、Jiraのワークフローで制限をかけています。プロダクト担当者ができるのはアラートチケットの解決までとなり、セキュリティ担当者がレビューをして問題がないことを確認した後、セキュリティ担当者によりチケットをクローズします。下記の実例を見てみましょう。
[図] S3バケットがpublicになっているというアラート
[図] プロダクト担当者の主張とセキュリティ担当者による是正
この検知に対して、プロダクト担当者は「CloudflareのIPレンジに制限を設けているため問題ない」と考え、アラートを解決済みとしました。しかしセキュリティ担当者のレビューでは、「CloudflareのIPレンジが広範囲に及び、かつ複数のクライアントで共有されておりリスクがある状態であるため、より安全な制限方法を検討してほしい」とコメントし、チケットは再度オープンな状態に戻されました。 こういったレビューによってセキュリティ担当者の負担を軽減し、スケーリングできるようなアラート対応体制ができました。
プルリクエストによるレビュー
意図した設定についてはGitHub上にプルリクエストを出してもらい、アラートをignoreすることが可能です。
[図] プロダクト担当者によるアカウントレベルのパブリックアクセスブロックをしていないアラートをignoreしたいプルリクエスト
[図] セキュリティ担当者によるレビュー結果
「もしパブリックS3バケットを使用していないのであれば、アカウントレベルでのパブリックアクセスをブロックすることを検討してみてほしい」とアドバイスし、プルリクエスト自体を撤回してもらいました。このように、セキュリティ担当者のレビューが不適切な設定のプルリクエストを適切に修正する役割を果たします。
最後に
従来のアラートハンドリング手順と違い、セキュリティチームが主導する調査でなく、プロダクトチームに主導してもらい、セキュリティチームがレビューと支援を行う仕組みでスケーリングしやすいアラート対応体制ができました。無論プロダクトチームの理解を得るための努力が必要ですが、幸いにも弊社の社員はセキュリティ意識が高く、運用の浸透にほとんど抵抗がありませんでした。導入までの障壁は決して低くはありませんが、導入効果は高いと思いますので、ぜひ皆様の会社でも検討してみてはいかがでしょうか？
We're hiring
マネーフォワードでは、セキュリティスペシャリストを募集しています！ hrmos.co
