はじめに
こんにちは!スタイル・エッジのpeipeiです。
前回の記事では、プロダクト横断型SREチームの発足についてお話ししました。 SREチームとして、組織全体の信頼性向上を目指し、複数のプロダクト開発チームを支援しながらSRE文化の構築に挑戦しています。
今回はその連載の続編として、AWS Security Hubを活用したセキュリティ対策の標準化 についてお話しします!
AWS Security Hubとは
AWS Security Hub(以下、Security Hub)は、AWS環境のセキュリティ監視・評価を一元化し、さまざまな基準に基づいたコンプライアンスチェックを実施するサービスです。 また、Amazon GuardDuty、Amazon Inspector、Amazon MacieなどのAWSセキュリティサービスや、サポートされているサードパーティ製品の検出結果(Findings)を統合できます。
実際に使ってみると、Security Hubを有効にするだけでAWSのベストプラクティスに沿ったチェックが自動で実行されるため、とても便利です。しかし、初めて使うと検出されるFindingsの量が多すぎて、「どこから手をつければいいの?」と戸惑ってしまいました。本記事では実践を通して得られた効率的な活用方法についても紹介します。
セキュリティ対策の標準化に動いたきっかけ
特に深刻なセキュリティインシデントは発生していませんが、会社の規模拡大に伴いシステムの社会的責任が一層重くなっていることを実感しており、セキュリティレベルのさらなる向上が不可欠となっています。
各プロダクト開発チームでセキュリティ対策は進められていましたが、システム全体の標準化を進めることで、より高いセキュリティレベルを実現できると考えました。以前からSecurity Hubを導入していましたが、セキュリティの抜け漏れを防ぐため、SREチームが全体の統率を担うことにしました。
対応方針〜「可視化 ⇒ 改修 ⇒ 予防」のアプローチ〜
セキュリティ対策を効果的に進めるため、私たちは「可視化 ⇒ 改修 ⇒ 予防」の3ステップでアプローチを行っています。
- 可視化:現状の課題を明確にし、全体の状況を把握する
- 改修:SREチームがプロダクト開発チームと連携しながら修正を進める
- 予防:同じ課題が再発しないよう仕組み化する
今回は可視化について詳しく見ていき、改修と予防については次回の記事で紹介します。
1. 可視化 - 現状のセキュリティ課題を明確にする
まず、課題を明確にしなければ、適切な対策を講じることはできません。Security Hubを中心に、全AWSアカウントのセキュリティ状況を一元管理できる仕組みを構築しました。
セキュリティ統括アカウントの作成と集約
複数のAWSアカウントを運用しているため、各アカウントごとにSecurity Hubの管理を行うのは手間がかかります。そこで、すべてのAWSアカウントのセキュリティ状況を一元管理するために、「セキュリティ統括アカウント」を作成しました。
さらに、アカウントの集約だけでなくリージョンごとの集約も行い、より効率的に管理を行えるようにしています。これにより、セキュリティ統括アカウントから全てのAWSアカウントのセキュリティ状況を一元的に把握できるようになりました。
※ 弊社では現在、AWS Organizations(以下、Organizations)を一部の環境を除いて使用していません。そのためアカウントの紐付けは、セキュリティ統括アカウントからメンバーアカウントを招待し、受諾するプロセスで行っています。
Security Hub でのメンバーアカウントの追加と招待 - AWS Security Hub
ダッシュボードの作成
Security HubのFindingsを可視化するために、事前に条件を設定したダッシュボード(カスタムインサイト)を作成しました。このダッシュボードを使用することで、AWSアカウントごとのセキュリティリスクを一覧表示し、全体の状況を一目で把握できるようになりました。
特に、重要度の高いFindingsをフィルタリングすることで、優先度の高いリスクから効率的に改修を進めやすくなっています。
カスタムインサイトの作成 - AWS Security Hub
通知機能の実装(Chatwork連携)
Security HubのFindingsをリアルタイムで関係者に通知するため、Chatworkへの自動通知機能を構築しました。これにより、セキュリティリスクの高いリソースが作成された際にChatworkへ即時通知され、迅速な検知が可能になりました。
当初、私はOrganizationsを使用せずに統合管理している場合、各アカウントごとにAWS EventBridge(以下、EventBridge)とAWS Lambda(以下、Lambda)をデプロイする必要があると思い込んでいました。しかし、Organizationsを使用していなくても、EventBridgeとLambdaはセキュリティ統括アカウントにのみ作成すれば問題ありませんでした。
セキュリティ統括アカウントでは、他アカウントのFindingsも同一のEventBridgeで検知できます。 また、統括アカウントで発行されるFindingsには対象アカウントのIDが含まれているため、どのアカウントで検出されたFindingsかを識別できます。
また、EventBridgeのイベントパターンを制御することで、通知対象を重要度の高いものに限定し、それ以外のFindingsは定期的に AWSコンソールで確認する運用としています。 本来であれば全ての通知に対応するのが理想ですが、検知されるFindingsの量が膨大で「狼少年アラート」になってしまうリスクがあるため、特に重要なもののみを通知し、それ以外は定期的にAWSコンソール上で確認する方針としました。
EventBridgeのイベントパターンのイメージ
{ "detail-type": ["Security Hub Findings - Imported"], "source": ["aws.securityhub"], "detail": { "findings.Compliance.Status": ["FAILED"], "findings.Severity.Label": ["CRITICAL, HIGH"] <= 通知するレベルを限定する } }
おわりに
ここまで、「可視化」のために実施した取り組みを紹介しました。 Security Hubを活用してセキュリティリスクを一元管理し、カスタムダッシュボードや通知の仕組みを整えることで、全体のセキュリティ状況を明確に把握できるようになりました。 今後は、Security Hubが検知したセキュリティの問題に対して、自動的にチケットを作成して担当者をアサインする仕組みを導入したいと考えています。
可視化はあくまでスタートラインで、それだけではリスクは減りません。重要なのは、その結果をどのように活用し、具体的な改修や予防策へと繋げるかだと考えます。
次回は、
2.「改修」:SREチームがプロダクト開発チームと連携しながら修正を進める
3.「予防」:同じ課題が再発しないよう仕組み化する
について詳しく解説していきます!
次回の記事も、ぜひチェックしてみてください!
連載予定
投稿日 | タイトル |
---|---|
4月 | AWS Security Hubを導入して社内セキュリティ対策の標準化を推進 〜改修・予防編〜 |
5月 | SREが“消火活動”に本気で向き合って見えた、信頼性向上へのリアルな一歩 |
6月 | SREとしてはお休み |
※内容や更新予定日は、追加・変更の可能性があります。
連載を通して、SREチームのチャレンジや、日々の気づきをお伝えしていきます。我々と同じように「SREって何から始めればいいの?」と悩む方や、自社の運用課題を抱える方の参考になっていければ幸いです。
一緒に働く仲間を募集しています!
スタイル・エッジでは、SREチームの立ち上げを共に進めてくださる仲間を募集しています!
もし興味をお持ちいただけましたら、ぜひ採用サイトをご覧ください!
recruit.styleedge.co.jp