この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本ブログは 2023 年 2 月 28 日に開催された Classmethod Showcase Security におけるセッション「失敗例から学ぶ AWS セキュリティサービスの導入」の資料公開、およびブログ版です。
AWS Security Hub と Amazon GuardDuty に関して、失敗事例や悩ましい内容を交えながら導入時の考慮事項を話したセッションとなります。登壇時から一部内容を修正・削除しています。
登壇資料の目次
- AWS セキュリティサービスの機能概要
本ブログの対象外- AWS Security Hub
- Amazon GuardDuty
- Security Hub と GuardDuty の検知の違い
- 失敗例から学ぶ Security Hub / GuardDuty 導入時の考慮事項
本ブログでも紹介
本ブログでは登壇資料の後半部分である、導入時の考慮事項に絞って記載しています。前半のサービスの基本的な内容については登壇資料を参照ください。
失敗例・悩みから学ぶ導入時の考慮事項
次の失敗例・悩みに対する改善例を五月雨に紹介していきます。
1 点注意として、どのような状況でも有用な手段はないことです。同じことをしてうまくいくかどうかは組織のプロセスや文化に大きく影響されます。しかしながら、失敗例や悩みを先に知っておくことで検討をスムーズにできることもありますので、ご参考にしていただけると幸いです。
なお、AWS Secuirty Hub のセキュリティ基準は「AWS 基礎セキュリティのベストプラクティス」を対象に記載しています。
【Security Hub】すべてのチェック項目を満たそうとして疲弊する
全ての項目に必ず対応しなければいけないという思い込みにより疲弊してしまうパターンです。ベストプラスティスはあくまで理論上の最善のため、対応が必須というわけではりません。社内のポリシーや対応コストなどを踏まえ対応しない選択肢もあります。
「AWS 基礎セキュリティのベストプラクティス v1.0.0」には 2023 年 2 月 20 日時点で 205 のチェック項目があります。
リリース初期は約 30〜50 項目だったため、一度にすべての項目に対応することもあったと思いますが、205 項目ある現在は、優先度をつけて確認していくことが多くなります。Security Hub のブログや記事ですべてのコントロールに対応すべきとある場合は、執筆時期によって意味が変わってきますので注意が必要です。
改善例 ①
コントロールは「無効化」できます。コントロールの対象となるリソースの中から特定のリソースのみ「抑制」することもできます。
社内のセキュリティポリシーに応じてコントロールを選定することが望ましいですが、難しい場合もあります（例えば、ポリシーの抽象度が高い、オンプレミス前提になっているなど）。その場合は、コントロール別に定められている重要度を参考に選定することもできます。
| 重要度 | コントロール数 |
|---|---|
| CRITICAL | 18 |
| HIGI | 29件 |
| MEDIUM | 119 |
| LOW | 23 |
また、重要度以外では既に導入している企業のアウトプットや公開ブログなども参考にできます。
DevelopersIO でも次のブログなどで紹介されています。
- 【アップデート】AWS Security Hub の『基礎セキュリティのベストプラクティス』に新たに 9 個のチェック項目が追加されました | DevelopersIO
- AWS Security Hub の『基礎セキュリティのベストプラクティス』に 30 個のチェック項目が追加されました(2022 年 2〜4 月分) | DevelopersIO
例えば、次のようなコメントが掲載されています。
[EC2.22] 使用していないセキュリティグループは削除する必要があります
重要度 : Medium (コメント) 使用していないセキュリティグループを定期的に棚卸しすることで、意図しないセキュリティグループをリソースにアタッチする可能性を下げることができる。運用上の理由で定期的にアタッチとデタッチを繰り返すようなセキュリティグループが発生する可能性もあり、対応必須ではない。
なお、クラスメソッドメンバーズのお客様は Classmethod Cloud Guidebook で一覧化されたものを見ることができます。
【Security Hub】リリース後 / リリース直前に有効化した結果、対処できない
コントロールには構成変更が必要な項目や稼働中の対応が難しい項目があり、リリース直前にチェックした結果、構成変更するインパクトやリスクを許容できないパターンです。
例えば、[EC2.3] 添付済みの EBS ボリュームは、保管中に暗号化する必要がありますの対処例は次の手順となります。EC2 インスタンスの停止ができない環境では対応が難しくなります。
対処手順例
- EC2 インスタンスを停止（もしくは静止点を作成）
- スナップショットを作成
- スナップショットをコピーし、その際に暗号化を有効化
- コピーしたスナップショットから EBS ボリュームを作成
- 暗号化された EBS ボリュームを EC2 インスタンスにアタッチ
（参考）【Security Hub 修復手順】[EC2.3] 添付済みの EBS ボリュームは、保管中に暗号化する必要があります | DevelopersIO
改善例 ①
開発初期から AWS Security Hub を利用することです。組織的な対応としてアカウント作成時の初期設定に含めることも多いです。
例えば、クラスメソッドメンバーズのセキュアアカウントでは次のブログで解説されている内容がアカウント払い出し時に設定済みとなります。
クラスメソッドメンバーズのセキュアアカウントの初期設定サービスの概略図
（引用元）[安全な AWS セキュリティ運用ナレッジ 2022]セキュアアカウントの使い方 | DevelopersIO
【Security Hub】最初だけ頑張ってあとは放置
導入時は稼働・体制を確保してしっかり対応したが、その後は放置して新しいコントロールに対応できていないパターンです。
例えば、登壇日（2023 年 2 月）の 1 年前（2022 年 2 月）に導入した場合は、導入時より 69 項目が増えています。継続的に新規コントロールに対応していくで Security Hub を最大限活用できます。
改善例 ①
コントロール追加への対応や失敗しているコントロールの対応が継続的に必要なことを考慮し、1週間 〜 1ヶ月に一度など、事前に取り組みの時間を確保しておく方法があります。判断を早くするために関係者（インフラ、アプリ、セキュリティ担当など）が揃っていると進みやすいです。
次のブログやユーザーグループの勉強会でも取り組み内容が共有されているため参考になります。
- Security-JAWS | Doorkeeper （YouTube で過去の勉強会を視聴できる）
- AWS Security Hub をちゃんと運用した話
改善例 ②
Security Hub の対応をチームや組織の目標の 1 つとして定める方法があります。
そのためには、マネジメント層の理解が必要となります。マネジメント層にセキュリティの AWS トレーニングを受講してもらい、意識付けする場合もあります。
例えば、クラスメソッドの AWS トレーニングにはマネジメント層も対象としたセキュリティコースがあります。
AWS Security Essentials 〜セキュリティ基礎 1 日コース〜
（引用元）AWS 認定トレーニングの選び方ガイド[セキュリティ編] | DevelopersIO
【GuardDuty】有効化するだけで満足してしまう
GuardDuty を有効化しただけで終わるパターンです。通知設定をしていないので、有効化していることも忘れてそのうち見なくなります。忘れた頃に GuardDuty を確認したときには重要度の高い検出結果が放置されている場合があります。
改善例 ①
検出結果をメールやチャットツールに通知したり、API を利用してチケット管理システムに登録したりできます。チャットツールに通知した場合は、通知メッセージのスレッドとして対処方針や対処状況を関係者と共有できる点が個人的には気に入っています。
- 【小ネタ】GuardDuty 通知は Security Hub 経由で行うとリージョン集約ができて便利 | DevelopersIO
- EventBridge API Destinations を使って GuardDuty 検知を Backlog に自動起票してみた | DevelopersIO
【GuardDuty】通知が多すぎて見なくなる
上記で通知しましょうと言いましたが、通知が多くなり過ぎて見なくなるパターンもあります。特に複数アカウントで運用している場合や公開システムが多い環境では通知が多くなる場合があります。
改善例 ①
GuardDuty では、条件に一致した検出内容を抑制する機能があります。過検知が何度も発生する場合は抑制ルールを設定することでノイズとなる通知を減らせます。
抑制ルールの活用方法は次のブログが参考になります。
改善例 ②
通知の視認性を良くする方法として、GuardDuty の検出結果の重要度別に通知先を変更する方法があります。
重要度別の通知方法は次のブログが参考になります。
- GuardDuty の通知が重要度でフィルター可能になりました | DevelopersIO
- 重要度別に GuardDuty を Slack に通知してみた | DevelopersIO
- 一部の検出結果タイプの通知先を変更する説明もある
改善例 ③
個人的に最も効果があると思うのが GuardDuty 単独で導入するではなく Security Hub とセットで導入・対応する方法です。
Security Hub の重要度CRITICAL HIGHのコントロールに対応するだけでも GuardDuty の通知は 数件/月/アカウント 程度になることが多い印象です。
例えば、[EC2.19] に対応するとブルートフォースアタック関連の検出の低減が期待できます。
【Security Hub】通知が多すぎて見なくなる
Security Hub の単純な通知設定はコントロール 1 個に対してメールが一通送信されることから、こうなりがちです（数ヶ月前の私です）。
改善例 ①/②
重要度でフィルタして現実的な対応数（通知数）に絞り、落ち着いたら徐々に拡大していく方法です。この方法でも通知が多くなることはあります。
GuardDuty の場合と同様に重要度別に通知先を変更して視認性をよくする方法や重要度の低いコントロールは通知しない方法もあります。
Security Hub の通知を重要度別にフィルタリングする方法は次のブログが参考になります。
改善例 ③
作り込みが必要となりますが、失敗のコントロール数をサマリにして通知する方法もあります。
重要度別に通知する方法は下記ブログで紹介されています。
2023.4.10 追記
重要度別の失敗コントロール数を通知するブログを追記しました
改善例 ④
定期的に確認する前提で Security Hub は通知しない判断もあります。通知する仕組みの維持管理負担も少なからず発生するためです。
【GuardDuty】インシデントと判断したが何をすればよいか分からない
GuardDuty の検知からインシデントと判断したが、どう対処すればよいか分からない、社内のエスカレーション先が分からない場合があります。対応が遅れている間に、情報漏えいやマイニングによる料金の被害が大きなる可能性があります。
改善例 ①
事前にインシデント対応フローを整理しておくことです。多くの場合は、組織内に既にインシデント対応フローがあるはずですので、クラウドの場合も検討して既存の対応フローと整合性を確保します。
インシデント対応やフロー検討の参考になる資料を 2 つ紹介します。
1 つ目は、AWS が公開している AWS Security Incident Response Guide です。インシデント対応の基本事項の概要が記載されており、オンプレミスと異なる点の説明や Appendix として 対応 Playbook のサンプル もあります。日本語で要約したブログ も公開されています。
2 つ目は、JPCERT/CC が公開している インシデントハンドリングマニュアル です。CSIRT 運用やインシデントハンドリングに関するフロー（下図）、知見、ノウハウが掲載されています。既に組織内に対応フローがある場合は一から検討することは少ないかもしれませんが、全体の考え方を知っておくことスムーズに検討できます。
架空のインシデント対応フローで対応例を記載します。
初動の整理
インシデントが発生したときの初動とエスカレーション先を整理しておくことで対応で悩むことを減らすことができます。
AWS 全体管理者への共有
エスカレーション時の注意点として、CCoE などのクラウド全体を管理している部門への共有も必要です。大規模なクラウド活用の場合は、共通的なリソースを AWS 全体管理者に管理し、役割分担して運用していることがあるためです。その場合、対応は協力して実施する必要があるため、共有漏れがないように留意します。
調査方法の事前習熟
一次対応の後、場合によってはセキュリティ部門からセキュリティパートナーにフォレンジック調査を依頼することもあると思います。依頼した調査や契約に日数がかかる場合があるため、自分たちでもログを確認できるように事前に習熟しておくことが望ましいです。
例えば、AWS CloudTrail イベントログの調査方法です。Amazon GuardDuty の調査には Amazon Detective も利用できます（事前に有効化が必要です）。
AWS CloudTrail のイベントログ検索について、マネジメントコンソールでも検索できますが、マネジメントコンソールで検索できるイベントは過去 90 日間である点や検索条件が限定的な点に注意が必要です。そのため、イベントログを S3 に転送し、Amazon Athena を用いた検索も習熟しておきたい内容です。
IAM に関する調査例は次の AWS ナレッジセンターの記事が参考になります。
セキュリティパートナーとの連携
フォレンジック調査をアウトソーシングする場合は、迅速に依頼できるように事前にセキュリティパートナーと連携方法を整備しておくこともあります。
セキュリティパートナーをこれから探す場合は、IPA が公開している 情報セキュリティサービス基準適合サービスリスト が参考になります。
【Security Hub】【GuardDuty】コストが思ったより高くなった
Security Hub と GuardDuty のコストを事前に試算することは難しく、想定コストと乖離することがあります。特に、リソース作成・削除が多い環境は Security Hub のチェック回数が多くなるため定期的に確認が必要です。
利用料金は次のページで公開されています。
改善例 ①
Security Hub と GuardDuty には 30 日の無料期間があるため、この期間でコストを把握します。Security Hub / GuardDuty を全リージョンで有効化する場合、よく使うリージョン、グローバルサービスがあるバージニア北部リージョン、あまり使わないリージョンでそれぞれのコストを把握しておくとよいです。
改善例 ②（Security Hub のみ）
Security Hub のコストを削減する方法として次の方法があります。
- チェック回数を減らすためにコントロールを無効化
- Security Hub の利用前提で有効化するサービスである AWS Config のコスト削減のために、AWS Config の記録リソースを制限
- Security Hub のチェック項目（コントロール）対象となるリソースに関連する AWS Config の記録を停止した場合はチェックができなくなるため注意が必要です
Security Hub が必要とする AWS Config の記録リソースは次のドキュメントで確認できます。
- AWS Foundational Security Best Practices コントロールに必要な AWS Config リソース - AWS Security Hub
- CIS コントロールに必要な AWS Config リソース - AWS Security Hub
- PCI DSS コントロールに必要な AWS Config リソース - AWS Security Hub
【主に Security Hub】組織内に導入したが対応してもらえない
組織内の施策として全ての AWS アカウントに導入したが、対応してもらえないパターンです。
改善例 ①/②
「【Security Hub】最初だけ頑張ってあとは放置」と同様の方法です。
改善例 ③
Security Hub の重要なチェック項目への対応が放置されている場合は、時間経過でプロジェクト管理者（責任者）への通知や経営層が出席する会議に付議する方法です。経営層が認識するため、対応の優先度を上げる等の対応が取られやすくなります。
改善例 ③ は AWS 全体管理者とプロジェクト担当者の間に軋轢が発生する可能性もあります。そこで、なるべくプロジェクト担当者が対応しやすいようにする案が以降の案となります。
改善例 ④
通知を見やすく加工します。何も加工しなければ JSON 形式のため中身を見ようと思われないです。
通知の加工方法は次のブログが参考になります。
- GuardDuty からのイベント通知をちょっと見やすくして通知する | DevelopersIO
- Security Hub イベントを見やすく加工して E メール通知してみる | DevelopersIO
改善例 ⑤
ポジティブな通知や達成のお祝いによりモチベーションを上げる方法もあります。この方法を始めて聞いたときに「すごく良い！」と思った記憶があります。ただし、自動化するためには作り込みが必要となってしまうため、まずは手動で効果を見てから導入がよいかもしれません。
次のブログ・動画で紹介されている方法です。
改善例 ⑥
システムの重要度に応じて満たすべきコントロールを変更する方法です。セキュリティとビジネススピードのバランスを取るために採用される方法の 1 つです。
最も厳しい要件のシステム（人命に関わるシステム、重要情報を扱うシステムなど）を中心に一律で社内ルールが定められている場合、ビジネススピードが遅くなる懸念があり、担当者の不満が貯まる可能性もあります。
注目の機能
個人的に注目している機能の 1 つを紹介します。
AWS Control Tower 環境限定ですが最近 GA された「Service-Managed Standard: Control Tower」を利用することで、Security Hub を自由に設定・運用したいプロジェクト担当者と最低限満たしてほしいコントロールがある全体管理者の要望を両立できるのではないかと考えています。まだ、リリースされたばかりなのですが、今後の実装候補の一つとなりそうな予感です。
これまで、Security Hub でコントロールを無効化するときは、管理者アカウントメンバーアカウントの全てで個別に無効化する必要がありましたが、「Service-Managed Standard: Control Tower」では Control Tower の管理アカウントから OU 単位で展開ができます。また、有効化するコントロールを選択して展開する点に違いがあります。
「Service-Managed Standard: Control Tower」に関するブログです。
その他いろいろ
発表に収まりきらなかったものを掲載します。
- AWS 基礎セキュリティベストプラクティス (AFSBP) で十分だったため、後からデフォルトで有効化されている CIS Benchmark v1.2 基準を無効化したくなったが、組織内でセキュリティを弱める判断を下すのが難しい
- AFSBP はチェック項目数が多く、CIS Benchmark と被っている内容もあるため、まずは AFSBP で運用してみて他基準を検討する進め方もある
- Security Hub のコントロールに対応する AWS Config のリソースが記録されておらず、チェックできていなかった
- AWS Config の記録リソースは全てのリソースが推奨である。ただし、コストが許容できない場合は記録リソースの精査も要検討となる
- Security Hub / GuardDuty の機能が組織内の運用方針と合わずに利用しなくなった
- 運用をサービスに合わせる
- サードパーティ製品の利用を検討する
- ぜひ機能改善要望を出してください！
さいごに
AWS セキュリティサービスの導入に関する失敗例・悩みを紹介しました。
世の中のキラキラした成功事例ばかりが気になってしまいがちですが、成功事例になるまでには多くの失敗もあったのではないかと思います。
本ブログが少しでも前進するためのヒントになれば幸いです。
さいごに、失敗例を提供してくださった皆さま、本当にありがとうございました。この場を借りてお礼申し上げます。
2
