マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓やあれこれ

こんにちは。SREチームの吉澤です。年末はイベントが多かった関係でネタがあったので、ANDPAD Advent Calendar 20246日目に続き、19日目も私が担当します。

先日12/13(金)に、Findy社のオンラインイベント「クラウドセキュリティを再吟味するために〜実例から学ぶ、考慮すべき観点とその対策事例〜」にお呼びいただき、AWS Security Hubの運用について講演しました。

今回はこの講演の内容と、10分の講演時間内には話しきれなかったリアルなあれこれをご紹介します。

講演:マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓

アンドパッドでは、2023年9月からAWS Security Hubの運用を開始し、1年以上が経過しました。講演では「これからAWS Security Hubを導入する人に3つだけアドバイスするなら?」と考えた結果を、「3つの教訓」に整理してご紹介しました。

どういう教訓なのかは、ぜひスライドを読んでみてください!アーカイブも公開中です(注:視聴にはFindyのアカウント登録が必要です)。

3つの教訓

発表時間が限られていたので、Security Hubの基本的な概念やシステム構成、運用の詳細には触れませんでした。これらの詳細は、過去のブログ記事や講演資料をご参照ください。

以下、講演時間内には話しきれなかったあれこれです。

AWSによるコントロールの追加・削除はどれくらいあるのか?

今回の講演をきっかけに、アンドパッドでSecurity Hubの本番運用を開始した、2023年9月25日以降の追加・削除を調べてみました。

調査方法

コントロールの追加については、私が把握している分についてはSecurity Hubユーザーガイドの改訂履歴にすべて書かれていました。一方、AWS公式のお知らせ()にはその一部しか書かれていませんでした。コントロールの追加を知りたいなら、ユーザーガイドを見るのが確実ということですね。

コントロールの削除については、AWSからのメールでの連絡を受けて対応していました。今回改めて確認したところ、ユーザーガイドには削除については書かれていませんでした。そのため、以下にはメールで連絡を受けたものだけ記載しました*1

結果

コントロールの改訂履歴

月ごとのコントロール数の増減

正直言って、運用開始前の私は、コントロールがこんなに頻繁に増えていくものだとは思っていませんでした。

追加されたコントロールの一部のみが失敗したとしても、失敗する検出結果の総数は膨大になります。そのため、講演でもお話ししたとおり、Slack等に検出結果をプッシュする場合は、「有効になっている標準で新しいコントロールを自動的に有効にする」という設定はオフにすることをおすすめします。

過去に発生したSlackへのプッシュ通知の件数は?

アンドパッドでは、検出結果のコンプライアンスステータスがFailedになったとき、一度だけSlackにプッシュ通知するシステムを構築しています(詳細:AWS Security Hubコントロールの有効無効をコード管理するのは予想のN倍大変だった話)。開発環境のアカウントと、本番環境のアカウントでは、通知先のチャンネルを分けています。

Security Hubを運用したら、実際どれくらいの量の通知に悩まされるのか、というのは経験しないとわからないところだと思います。そこで、過去に発生した、このプッシュ通知の件数の推移を可視化してみました。

調査方法

Slack APIを用いて、本番運用を開始した2023年9月25日以降にAWS Chatbotから送られたメッセージを取得し、送信された月および環境(開発・本番)ごとに件数を集計しました。

結果

講演でも話したとおり、運用開始時は「有効になっている標準で新しいコントロールを自動的に有効にする」という設定をオンにしていました。そのため、AWSのコントロール追加によって発生する大量の通知に悩まされていました。

2024年1月9日にこの設定をオフにして、それ以降は大きな負担もなく、Security Hubを活用できるようになりました。

アンドパッドで発生したプッシュ通知の件数

このグラフを見ると、本番環境よりも、開発環境のプッシュ通知の件数が多いことがわかります。開発環境では、問題を未然に(本番環境に出てしまう前に)検知するため、プッシュ通知がある程度発生するのは正常なことです。

ただ、それと同様に、本番環境でもプッシュ通知が発生し続けていることもわかります。これは何故なんでしょうか?

過去に発生したSlackへの通知の理由で、特に多かったものは?

Security Hubをきちんと運用しても、本番環境の通知をゼロにできなかった理由を整理してみました。

調査方法

「有効になっている標準で新しいコントロールを自動的に有効にする」がオンだった時期は不必要な通知が多かったので、この時期を除いて、通知内容を詳しく調べました。

Slack APIを用いて、2024年1月9日以降にAWS Chatbotから送られたメッセージを取得し、環境(開発・本番)、セキュリティコントロールIDおよびリソースごとに件数を集計しました。そして、件数が多かったセキュリティコントロールIDの発生原因を調べました。

結果

件数が多いものは、おおむね以下のいずれかに分類できました。

  • 一時的に作成するリソースで、不要な設定を省略したために発生したもの
    • 本番環境で、データ分析などの用途で一時的にAuroraクラスタを作成することがある。このような用途で、RDS.6(監視設定)、RDS.7(削除保護)、RDS.15(Multi-AZ)などの検出結果が出ていた
    • 長期的に使用するAuroraクラスタでは必要なため、これらのコントロールを無効化するという解決手段は取れない
    • 定型業務で、毎回決まった名前で作成するクラスタについては、すでに自動化ルールで検出結果を抑止している。ただ、臨時の作業で作成するものについては抑止しきれなかった
  • タイミングによって、AWSリソースの作成直後に発生してしまうもの
    • IAM.5(IAMユーザーにMFAが設定されているか)は、IAMユーザーの作成から、MFAの設定までに時間が開くと検出結果が通知されてしまう。MFAは利用者が設定するため、この通知の発生は避けにくい
    • TerraformでS3バケットを作成すると、S3バケットの作成のあとに、ごく僅かな間隔を開けて、その他の設定が行われる。この僅かな時間内にコントロールのチェックが行われると失敗する。そのため、最終的な設定には問題がなくても、S3関係のコントロールの失敗が通知されることがある
  • 通常利用でも発生することがあるもの
    • KMS.3(KMSキーの削除時に発生)は、意図したKMSキーの削除時にも発生する。そのため、通知を見て、意図した削除かを確認する必要がある
    • SecretsManager.3(シークレットが90日利用されていないときに発生)は、利用頻度が低い秘密情報をシークレットに保存している場合に発生する。何日利用されていなかったら通知するかをunusedForDaysパラメータで変更できるため、このパラメータを設定することで発生頻度を下げられるかもしれない
  • 開発環境での、削除保護に関するもの
    • 特定のリソースに限らず、開発の初期段階では頻繁にリソースの追加・削除が行われるため、削除保護を無効にするケースが多い
    • 開発環境では、削除保護に関するコントロールはほとんど無効にしている。しかし、まだ抜け漏れがあった

こうやって振り返ってみると、ほとんどの問題は対策が難しく、悩ましいところです……。

ただ、一部の問題については「コンプライアンスステータスがFailedだったら即座に通知する」というシステムによる問題とも言えそうです。

「コンプライアンスステータスがFailedになってから一定時間後もFailedだったらSlackに通知する」というシステムを構築できれば、「タイミングによって、AWSリソースの作成直後に発生してしまうもの」や「開発環境での、削除保護に関するもの」は減らせるかもしれません。

Security Hubに関するタスク管理の悩み

最後に、Security Hubに関する、個人的には一番の悩みをご紹介させてください。

講演では、コントロールを無効化した理由や、チェック対象外にしたリソースとその理由を、スプレッドシートで管理しているという話をしました。

組織内の合意結果およびその理由の記録

また、対処すべきコントロールについて、タスク管理システムで管理しているという話をしました。

「運用開始前に」コントロールを分類する

これらの情報は、本来ならAWSマネジメントコンソールのSecurity Hub上で一元管理したいのに、複数のツールを使い分けなければいけないというのが悩みです。Security Hubに機能が不足しているために、各企業でこのような情報を管理する仕組みを独自に作り込む必要が生じてしまっています。

まとめ

今回は、Security Hubを実際に運用するまでなかなか気付けなそうな情報を、いろいろご紹介しました。

Security Hubに対する不満を色々書きましたが、このようなサービスは人の目が行き届かない部分をカバーしてくれるため、導入して本当によかったと思っています。Security Hubに限らず、なんらかのクラウドセキュリティ態勢管理サービスは導入すべき、と強くおすすめできます。この記事が導入の参考になれば幸いです。

We are hiring!

アンドパッドでは、「幸せを築く人を、幸せに。」というミッションの実現のため、一緒に働く仲間を大募集しています。アンドパッドのマルチプロダクト戦略を支えるSREチームにご興味がありましたら、以下のページからご応募ください。カジュアル面談も実施しています。

hrmos.co

*1:アンドパッドで有効化していないセキュリティ基準についてはメール連絡がなかった、といった理由で漏れているかもしれません。