AWS Security Hubをちゃんと運用した話
はじめに
少し前の話ですが、チーム内でAWS Security Hubを導入して半年以上かけてAWS環境のセキュリティレベルの底上げを実施したときの記録です。様々な細かい修正を積み重ね、最終的に100項目以上のセキュリティ要件をクリアしました。
AWS環境のセキュリティ設定の見直しや、リソースの棚卸しを検討されているエンジニアの方に参考にして頂けると幸いです。
書いていないこと
セキュリティに関することは赤裸々に書きにくいという側面があり、実際にSecurity Hubを実施した内容に関する記事は少なそうです。本記事も何の項目を検討して何を修正し、あるいは何のリスクを許容したかと言った具体的なことは書いていません。
しかしどういった体制や進め方で行ったか、あるいはどのような事を念頭に作業すると良さそうかについては、詳細に書きたいと思いました。
Security Hubとは
改めてSecurity Hubについての説明です。
（既にご存じの方は、読み飛ばして下さい）
Security HubはAWS環境のセキュリティ運用のためのツールで、他のAWSサービスとのインテグレーションも可能です。中心となる機能はアカウント内のセキュリティ設定を横断的に検出し、重要度ごとに一元的に可視化して、どう修正すれば良いのか（公式ドキュメントのリンク）まで示してくれる機能です。
検出項目（コントロールと呼ばれます）としては、すでに用意された項目のセットがあり、以下から複数選択できます。
この中でAWS 基礎セキュリティのベストプラクティスを掘り下げて、具体的にどのような項目があるか見てみます。例えば、EC2については
-
EC2.4停止した EC2 インスタンスは、指定した期間後に削除する必要があります -
EC2.9EC2 インスタンスにはパブリック IPv4 アドレスを使用できません
といったコントロールがあり、それぞれ上記の項目に該当したリソースが検知されると、ステータスが「失敗」と記録されます。どのようなコントロールが含まれているかについて、AWSの各サービス別で見てみるとコントロールの数の内訳は以下となっていました。
RDSが23個と最も多く、ついでEC2が17個、IAM、ELB、Elasticache、S3と続きます。一般的なWebサービスなど、利用ユーザー数の多いサービスの項目のウェイトが大きく、他にもセキュリティを考える上で重要なサービスが幅広く含まれている印象です。
しかし、だからといってRDSに関する作業時間が多くなるかというと、必ずしもそうはなりません。1つのAWSアカウント内で多数のRDSが稼働しているケースはおそらく少なく、けれどもS3バケットは50個以上ある、なんて環境はよくありそうです。結果としてどのサービスに作業工数をかけることになるかはその環境にもよりますが、S3やIAM、EC2などは見直すべきポイントが多くなるはずです。検出リソースの多い環境は、悪く言うと「細かい所まで検討されてこなかった環境」、でもそれは良く言うと「伸び代が大きく導入効果の高い環境」ですね。（ポジティブに）
運用方法
ここからは、具体的に実施した進め方について、5W1Hでまとめてみました。
When
隔週で開催されている定例会の中で「Security Hubの検討枠」を設けて定期的に実施し、曜日と時間（だいたい20〜30分前後）を固定して行いました。概ね次のような流れです。
- 担当者が実施した対応状況と、3~5個程の事前にピックアップした項目を前日までに共有
- 共有していた項目について対応すべきか検討し、対応すべきものについては対応方針を決定
- （定例会終了後から）２週間かけてTerraformやCFｎのPR作成など一つひとつ対応
ここで、検討項目を事前にピックアップしておく事が比較的重要だと考えています。一般的に決定事項の多い会議ほど、いきなり課題だけぶつけられると誰しも警戒したくなります。逆に、時間的な余裕があれば過去の経緯を確認して意見を整理し、または公式ドキュメントを参照して主張の裏付けをとっておくこともできそうです。
AWSインフラの修正を検討するわけですから、時としてシステムにdrasticな変更が生じることもあります。（そういった場合は見送ることも少なくないですが） そのため、検討すべき項目に関しては重要度を参考に慎重にセレクトし、Slackのプロジェクトチャンネルで前日までに関係者と共有するようにしました。
Where
検討（定例会）は、Google Meetを使い全てリモートで実施しました。担当者が画面を共有してマネージメントコンソールをみんなで見ながら、どう対応するかの議論や抑制済みの設定作業などを行いました。
Google MeetではJamboardと言うWorkspaceのホワイトボード機能も統合されており、ラフなイメージやシステム構成図を共有する際に便利です。
Who
一緒に検討したメンバーについてですが、実は非常に恵まれていました。
元セキュリティ企業のエンジニアの方、AWSコンサルをされていた方、Webだけではなくハードにも詳しい方、モダンなフロントエンドをバリバリ開発中の方など、様々なバックグラウンドを持った方にご参加いただき、適切なアドバイスをいただけました。
AWSのセキュリティと一口に言っても様々な切り口・考え方があることを考慮すると、参加人数は多い方が良いかもしれません。
（セキュリティ技術は座学や資格だけではなかなか身につかず、実践的な機会は無いものかと考えていた自分にとっても、本当に有り難い機会でした）
What
対象となるAWSアカウントで運用されているサービスは、会員制Webポータルです。BtoBであり少なくとも当時はクレジットカードなどは扱っていませんでした。そのため、Security Hubには「AWS 基礎セキュリティのベストプラクティス」以外に「PCI DSS」のコントロールセットもありましたが、一旦このベストプラクティスのみを検討することにしました。
他に「CISベンチマーク」についても検討はしたものの、似通ったコントロールも含まれるため採用の優先度は一段下げ次のステップとしました。ただこの判断は議論の余地がある所です。CISベンチマークを採用することで、第三者的な視点によるベンダーに依存しないセキュリティレベルの評価が可能です。他のパブリッククラウド、例えばGoogle CloudにおいてもSecurity Command CenterのSecurity Health AnalyticsというSecurity Hubに相当する機能があり、CISベンチマークがサポートされています。
Why
なぜやるのか？はもちろん「セキュリティを運用を一元管理し、インフラ環境を改善するためです。
そしてさらに付け加えるなら 「クラウドインフラのセキュリティに安心感を与え、アピールポイントに変えるため」 という側面もあると思います。副次的な効果ではありますが、定量的に高スコアを標榜できれば、システムに関する社内外でのイベント登壇や内部監査などでも胸を張って話せるのではないでしょうか。
How
作業の記録について書きます。開始当初、項目それぞれに対する対応作業の記録を、チケット管理SaaSなどを利用してつけていました。監査要件もあるため、それぞれのリソースの変更記録もそれとは別に残していました。
しかし、よくよく考えると対応した順序にはあまり意味が無いことに気づき、途中でSecurity Hub自体の作業記録はやめました。（後述しますが、記録より見直す機会を設定する方が大切だろうという判断もありました）
余談ですが、AWSのWell-Architected Toolだとメモを残す仕組みがあり、これが非常に素晴らしいなと感じています。（Security Hubにも欲しい[1]）
やってみて感じたこと
この一連の作業を半年以上かけて実施した結果、いくつか感じたポイントを振り返ります。
重要なこと
継続的な作業時間を確保する
当たり前な話ですが、どんなツールも結局は使い方次第だと改めて思いました。
有効化するだけで状況は何も変わらず、コントロールを起点に実際にシステムを是正していくことが大事だと分かってはいたのですが、とは言え90%程度に到達するだけでもかなりの時間がかかりました。
当時は、SREのようなロールでセキュリティと向き合う時間を十分に確保できたことが幸運でした。そしてこの作業に対する工数を確保すべきという判断を下したマネージメントこそが、組織内で正しく評価されるべきはないかと個人的には思います。（願わくばそういう組織で働いていきたいですね）
定期的に見直しを
これは内部監査などを担当されたことがある方は、身を持ってよくご存知かもしれません。
一般的にシステムのセキュリティは定期的な見直しがスケジュールされますが、その時にこのツールは非常に便利ではないかと思います。特に、Security Hubで検出されたものの対応を見送った「無効化」あるいは「警告を抑制(Suppressed)した」項目について、半年から一年などの期間で定期的に棚卸しすることはおそらく大事です。
欲を言えば通知設定なども欲しいですが、AWSではGuardDutyなど他にも重要な監視サービスの通知設定はありそうなので、順番に要検討でしょうか。
まぁまぁ大事なこと
コントロールの Disabled と Suppressed は違う
無効化項目の見直しの説明と関連しますが、対応を見送る判断をした際にSecurity Hubでは次の選択（ラベル付け）が可能です。
- コントロール自体を無効化（Disabled）する（新規リソースの検知を行わない）
-
FAILEDとなった該当リソースを個別に抑制（Suppressed）する
アカウントレベルの設定など、明らかに今後も対応の予定のないものは無効化も選択肢になり得ますが、多くの場合ではリソースの個別の抑制が好ましいと思われます。これは (1)新しいリソースが追加された時 や、(2)意図せず設定が変更された時 に検知できるように、といった理由です。
ただこの方法ですと、抑制済みリソースの管理も必要になり、少し厄介です。以前はAWS CLIを使ってSuppressedしたリソースの一覧を取得するスクリプトを使用していたのですが、正直あまりお薦めしません。この「抑制済み項目のリスト」は、見方を変えると「システムの脆弱性一覧リスト」のような側面もあるため、ローカルに保存したり気軽に共有したりと言った使い方は推奨されないだろうと考えたからです。ちょっと懸念し過ぎではないかとも思いますが、Suppressedしたからにはそれ相応の理由があり、改修自体が困難なケースもあるはずです。
Security HubでカバーされていないAWSのセキュリティを考える
AWS Configルールを利用したSecurity Hubの検出の仕組み上、Security Hubで検知できない or 相性の悪い脆弱性や懸念すべき項目があることも忘れずにいたいです。
また一般論として、どんなに優れたツールもそれ単体で使うと一面的な見方になってしまうことがあり、Security Hubにおいてもそれだけでインフラレイヤーのセキュリティが十分だとは思わないようにしています。
例えば、機密情報が公開S3バケットに保管されていないかや、VPCピアリングの設定が適切にされているかなど、考えるべきことは他にも多く、複数のサービスやツールを組み合わせてAWS環境全体の改善に取り組んでいけると理想だと思います。
おわりに
Security Hubをこれから導入される場合、スタート地点としては「なんとなく有効化」でも良いかもしれません。しかし、適切に運用することでチームの意思決定を強力にサポートする、素晴らしいツールだと感じています。
長々と書きましたが、最後まで読んでいただきありがとうございました。
-
無効化する際にコメントを付けることは現在でも可能ですね ↩︎
Discussion