5 段階でマスター ! AWS Security Hub CSPM を使い始めてから使いこなすまで
2025-10-02 | Author : 臼田 佳祐 (クラスメソッド株式会社 / AWS Security Hero)
はじめに
こんにちは、臼田です。みなさん、AWS のセキュリティ対策してますか ?
今回は AWS のセキュリティ対策で無くてはならない機能の 1 つ、AWS Security Hub CSPM をすべての AWS ユーザーが使いこなせるように説明していきます。
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
概要と対象者
みなさんはどのような立場で AWS と関わっていますか ?
AWS 上に自分たちのプロダクトを開発している?
運用者として日々AWSを触っている ?
直接は AWS をあまり触らないけど組織のメンバーが AWS を活用している ?
いろんな AWS との関わり方がありますが、どのような関係性であっても AWS のセキュリティ対策と無縁であることはできません。セキュリティ、この場合はもう少し厳密に表現して、情報セキュリティは関わる全ての人が責任を持つ必要があるからです。
実際にみなさんが利用している AWS 環境は「今」安全な状態にありますか ? 自信を持って「今」安全です ! と言えるようになるには、継続的に AWS の構成情報をチェックし、適切な状態に維持し続けることが必要です。その際利用できるのが AWS Security Hub CSPM です。
現在の AWS 利用において無くてはならない機能の 1 つである AWS Security Hub CSPM ですが、その利用者の多さと適用範囲の広さから、私も日々多くのお悩み相談を受けます。例えば下記のような。
「セキュリティの通知がたくさん来て対応に疲弊している」
「何からやればいいかわからず放置してしまっている」
これに限らず AWS Security Hub CSPM の活用段階に応じて様々な課題が出てきます。今回はこのような課題を解決しつつ、これから AWS Security Hub CSPM を利用し始め、完全に使いこなすまでのステップを 5 段階に分けて説明し、すべての AWS ユーザーが AWS 環境をセキュアに維持し続けられるように導きます。
というわけで対象の読者は以下のような方々です。
- AWSのセキュリティをこれから強化していきたい方
- AWS Security Hub CSPMを利用し始めたがうまく使いこなせていない方
- 組織全体にAWS Security Hub CSPMの活用を浸透させたい方
- AWSセキュリティに責任を持つ方
すべての AWS ユーザーが自分たちの使う AWS 環境のセキュリティに責任を持つ必要がありますから、実質 AWS ユーザー全員が対象者ですね。
ちなみに、さっきから "AWS Security Hub CSPM" と記載していますが、この表記に馴染みのない方がいらっしゃるかもしれません。2018 年末のに発表された AWS Security Hub は 2025 年 6 月に行われた AWS セキュリティの学習型カンファレンス「AWS re:Inforce 2025」にて AWS Security Hub CSPM という名前に変わりました。現在は別で AWS Security Hub と呼ばれるサービスがあるため、混同しないようにお気をつけください。
それでは、まだ AWS Security Hub CSPM を利用していない状態から、以下の段階でステップアップしていきましょう。
- AWS Security Hub CSPM を理解し有効化する
- 最初にクリティカルな問題に対処する
- 利用しながら AWS セキュリティに習熟する
- 設計からセキュアにする
- AWS セキュリティを全体に適用する
1. AWS Security Hub CSPMを理解し有効化する
まだ AWS Security Hub CSPM を利用していない状態から活用していくためには、まず適切に AWS Security Hub CSPM の役割を認識しましょう。
みなさんが利用している AWS というプラットフォームは、たくさんのサービスと機能があり、その利用状況を把握するのは簡単ではありません。先ほど書いた通り、刻々と変化する自分たちの AWS 環境が「今」安全であるかを把握できる、セキュリティチェックの機能を持つのが AWS Security Hub CSPM です。
このセキュリティチェックは各種 AWS リソースの変更管理を行う AWS Config と連携して行われます。クラウド上のリソースを 1 つ 1 つ人力でチェックすることは現実的ではありません。そのため AWS Config で自動的に設定を収集し、AWS Security Hub CSPM でセキュリティチェックを行う自動化された仕組みがクラウド利用には必須の機能です。
AWS Security Hub CSPM にはいくつかのセキュリティチェックのチェックリストである「セキュリティ基準」がありますが、私が一番推奨する「AWS 基本的なセキュリティのベストプラクティス (AFSBP)」は 2025/07 現在で 60 種類の AWS サービスをカバーし、チェック項目である「コントロール」が 318 種類あり、網羅性と実務性の高いセキュリティ基準となります。まずはこれを有効化すれば OK です。
有効化の手順
では実際に有効化をやってみます。今回は AWS アカウント単体の単一リージョンでの有効化手順です。
2025/07 時点では、AWS マネジメントコンソールで AWS Security Hub のページにアクセスすると、新しい AWS Security HubとAWS Security Hub CSPM を有効化するページが開きます。表記としては「Security Hub CSPM」となっている方を選択して有効化を始めます。
セキュリティ基準を選択
続いて有効化するセキュリティ基準を選択する画面となります。私の推奨である「AWS 基礎セキュリティのベストプラクティス」(AFSBP) のみを選択して有効化します。(必要な場合には後からでも他のセキュリティ基準を有効化できます)
有効化された AWS Security Hub CSPM はセキュリティスコアなどの結果をすべて表示できるようになるまで最大 24 時間かかりますので、有効化したらしばらく置いておきましょう。
なお、AWS Organizations と連携する場合や、前提条件となる AWS Config の有効化など詳細な情報はユーザーガイド「Security Hub CSPM AWS Config の有効化と設定 - AWS Security Hub」をご確認ください。
2. 最初にクリティカルな問題に対処する
AWS Security Hub CSPM を有効化する際にいろんな戦略を取れます。有効化の範囲としては AWS アカウント単体で有効化するか、AWS Organizations を利用してすべての AWS アカウントに展開するか、通知も EventBridge 経由でメールを送ったり加工したり Slack に流したりいろんなやり方があります。
そして通知まで設定すると、先程挙げたような以下のような状態になります。
「セキュリティの通知がたくさん来て対応に疲弊している」
「何からやればいいかわからず放置している」
AWS Security Hub CSPM を使い始めるときの最初の対応方針を以下のように示します。
- メールなどの通知は設定してもいいけど最初は見ない
- まずは AWS マネジメントコンソールで見る
- 重要度が Critical (重要) のものだけ対応していく
セキュリティ系サービスの通知は、環境がきれいになる前に導入するとめちゃくちゃたくさん通知されます。基本的に通知の目的は変化や問題に気づくことですから、導入当初の環境を改善する段階ではこれを 1 つずつ見ると疲弊します。これらは一旦おいておいて、AWS マネジメントコンソールで本当に見るべきものに絞って見ていきましょう。
実際の見方
実際の見方を説明します。AWSマネジメントコンソールでAWS Security Hub CSPMのコントロールあるいはセキュリティ基準のページから項目を絞っていきます。
コントロール一覧の上部にフィルターがありますので、ここで「コントロールステータス = FAILED」「重要度 = CRITICAL」を「および (AND)」で組み合わせることで最初に対応すべき項目に絞ることができます。
対象リソースを把握
詳細を開くと説明が英語で書かれていますが、まずは下部の「チェック」部分に対象のリソース一覧があるので、ここから対象リソースを把握しましょう。そして英語で分かりづらいですが、これがなんのチェックでどうすればいいのかは説明欄の「修復手順」のリンクからユーザーガイドを開いて確認していきます。
ユーザーガイドを確認
ユーザーガイドを開くと該当のコントロールを説明しリスクと修復手順まで説明したページが表示されます。
ユーザーガイドはほとんど日本語化されているため、右上の言語選択から日本語に切り替えましょう。そうすると例えば EC2.19 のコントロールであれば このリンク でアクセスした先のページが表示され、どうしたらいいか理解できます。
まずは Critical のものだけでいいので、1 つずつ理解し対応しましょう。
3. 利用しながら AWS セキュリティに習熟する
2 段階目の手順を少し実施いただくと気づくはずです。「これ AWS セキュリティの勉強になるやつや」と。
最初は「AWS セキュリティってどうすればいいかわからない」となっている方でも、1 つ 1 つ対応していくうちに「この設定は使ったほうがいい」「この設定は危ない」という判断がつくようになります。
AWS のセキュリティを強化していくためには、実際の AWS 環境で AWS Security Hub CSPM を使った是正を行いながら、ユーザーガイドを読み習熟していくのが効果的です。これが次の段階に活かされます。
ここでは代表的なコントロールをいくつか解説します。
代表的なコントロール
[EC2.8] EC2 インスタンスは、インスタンスメタデータサービスバージョン 2 (IMDSv2) を使用することをお勧めします
IMDSv2 は現在新しくAmazon EC2 インスタンスを作成した際にはデフォルトで使用され、この検出はされません。昔から利用している Amazon EC2 ではこちらの検出がよく発生しますが、現代において IMDSv1 が利用できる環境はドキュメントにある通りいくつかの問題と組み合わさることで攻撃される可能性が増加します。テスト環境等で IMDSv2 を強制した Amazon EC2 インスタンスを動作させて検証してから、本番環境も新しい設定の Amaazon EC2 インスタンスに置き換えましょう。ついでに古いインスタンスなら、新しいインスタンスタイプに見直すことでコスト効率も上げられますよ。
[S3.1] S3 汎用バケットではブロックパブリックアクセスの設定が有効になっている必要があります。
Amazon S3 には複数のアクセス制御機能がありますが、その一番大きな単位の設定がアカウントレベルのブロックパブリックアクセスです。これは Amazon S3 のバケットポリシーなどでよく分からず公開設定を入れたとしても、パブリックな公開を防止する機能です。Amazon S3 のデータは様々な用途で利用しますが、公開しないものも多いです。また、一般向けにデータを配信する場合も Amazon CloudFront と連携する場合は OAC という設定を入れつつ S3 バケットは非公開のまま維持でき、あまり公開する場面がありません。ほとんどの場合公開設定は不要のため基本的にブロックパブリックアクセスを有効化しておくと考えてください。
[RDS.3] RDS DB インスタンスでは、保管時の暗号化が有効になっている必要があります。
このコントロールに限らず、保管時の暗号化についてのコントロールは各リソースに存在します。特に重要なリソースが含まれる Amazon RDS などのデータベースやストレージにおける保管時の暗号化は必須と考えましょう。
ユーザーによる適切なデータ管理
よくある意見として「AWS が適切に管理してくれるから保管時の暗号化は行わなくてもいいのでは ?」というものがありますが、これは間違いです。
みなさん、AWS セキュリティの大前提である責任共有モデルの図を思い出してください。一番上には何がありますか ?
……そうです、一番上はデータです。データは一度たりとも AWS の責任になることはありません。我々 AWS ユーザーが AWS 上に保管しているデータの責任はすべて我々にあります。これは、AWS はそのデータの管理を放棄しているなどということではありません。AWS ユーザーが扱うデータの主権は、常に AWS ユーザー側にあるという責任の拠り所の話です。もちろん AWS はプラットフォーマーとして顧客のデータが侵害されないように、あるいは内部不正などからも守れるように様々な仕組みが用意されていますが、それは AWS の責任範囲の中の話です。我々 AWS ユーザーはその実施状況に関係なく、責任あるデータの取り扱いをしなければなりません。
さて、ではこう考えてみましょう。お客様から預かった重要なデータを Amazon RDS に保管します。お客様からこのように尋ねられます。
「データは適切に管理していますか ?」
もちろん、Amazon RDS の DB インスタンスで保管時の暗号化を設定しておく必要がありますね。もちろんこれ以外にも、通信の暗号化やバックアップ、データの破棄に至るまでのデータライフサイクル全体に渡って責任を果たす必要があります。
このように、1 つ 1 つのコントロールについてその背景を調べ対応していくうちに、AWS セキュリティへの理解が深まっていきます。
4. 設計からセキュアにする
AWS のセキュリティについての理解が深まってきましたか ?
しかしこのまま検出した問題を修正し続けるだけでは根本解決になりません。
セキュリティ対策をより良くしていくためには「セキュリティ・バイ・デザイン」、つまり設計からセキュリティを組み込んでおく必要があります。
例えば EC2.19 が検出され続ける環境では、AWS を設定する人がよく Amazon EC2 にアクセスするためにセキュリティグループの SSH ポートを 0.0.0.0/0 で開放している、というケースがあったりしますが、これが危険であり絶対に行ってはいけない設定であることが周知徹底されていないため発生するわけですね。
現在の AWS ではより適切な手法として、AWS Systems Manager の Session Manager を利用することで、インターネットに SSH ポートを開放せず管理アクセスを実現可能です。管理アクセスのためにセキュリティグループを開放しないように、設計に組み込んでいくことや関係者に周知徹底していくことが必要です。
これらのセキュリティ対策を推進するためには、3 段階目で習熟した知識と経験が必要です。1 つずつ設計を変えルールを適用していきましょう。うまく進めることで、ようやく通知をオンにして適切に運用できるくらいの流量になるはずです。
5. AWSセキュリティを全体に適用する
1 つずつ積み上げて AWS 環境をセキュアにできましたか ? しかしこれはまだ始まりに過ぎません。
改めてみなさんはどのような立場で AWS セキュリティの強化に関わってきましたか ? AWS 上に自分たちのプロダクトを開発している方は、そのプロダクトから検出が上がらないように設計を強化する対応ができましたか ? 運用者として日々 AWS を触っている方は、設計・開発側にセキュリティの問題を提示し解決に導けましたか ? 直接は AWS をあまり触らないけど組織のメンバーが AWS を活用している方は、責任を持つ範囲の AWS セキュリティ対策のレベルを把握しメンバーに対して適切に改善を促せましたか ?
「セキュリティ・バイ・デザイン」にしていくにはすべての関係者への啓発が必要です。セキュリティも含む AWS をセキュアに利用するためのガイドラインを整備しましょう。チームメンバーや組織内でのガバナンスと教育を効率化できます。
直接関与しない別の AWS を利用したプロダクトなど、組織の他の AWS 環境でも同じようにセキュリティを強化していく必要があります。AWS Organizations や AWS Control Tower などを利用して全体で同じようなセキュリティ対策を簡単に適用できるように整備しましょう。
みんなが AWS のセキュリティを「あたりまえ」に考えられる環境を作っていくことも大切です。AWS Security Hub CSPM にはこれをわかりやすく「セキュリティスコア」で表現できます。スコア 100% が維持される環境を目指し、問題を検出して是正し、ガイドラインに組み込み、すべての AWS 利用者がこれを守れるようにしていきましょう。
スコアが高いことを称賛する文化を醸成する
この時、スコアが低いことを問題にするのではなく、スコアが高いことを称賛できる文化にすると、モチベーション高く対応できますよ。
例えばこんな Slack 通知とか。
セキュリティスコアを 100% にするためのコツ
セキュリティスコアを 100% にするためのコツをいくつか紹介します。
不要なコントロールを無効化
まず前提として、AFSBP の 318 種類のコントロールのうち、すべてを対応していく必要性はありません。ステップ 3,4 を実施していくにつれ、「うちではこの項目は必要ないな」「これはサードパーティのこのソリューションでカバーしているからチェックしなくていいな」といった自分たちの状況に合わせた判断ができるようになってきます。
AWS Security Hub CSPM で利用するコントロールは無効化できるので、組織全体で必要ないと判断したら無効化しましょう。各コントロールの詳細画面にて「コントロールを無効にする」を選択すると、理由も添えて無効化が可能です。
例えば無効化できるコントロールとして下記が挙げられます。
- [IAM.1] IAM ポリシーでは、完全な「*」管理者権限を許可しないでください
こちらを含む IAM 系のコントロールは、メインリージョン以外でも検出されますが、全リージョンで同じ検出が動作し必要外のコストが発生するため、グローバルリソースを記録しているメインリージョン以外での無効化が推奨されています - [ ELB.6 ] Application、Gateway、および Network Load Balancer の削除保護を有効にしてください
このような削除保護の設定などは、本番環境では必要ですが開発環境などでは一般的に不要なため、環境特性に合わせて無効化できます
例外対応
また、コントロール無効化はしたくないけど、特定のリソースだけリスクを許容するなどの例外対応も可能ですのでこれも併用します。
例外対応をするにはコントロールの詳細画面で対象のリソースを選択し、「ワークフローのステータス」を「抑制済み」に変更します。
例えば抑制済みを活用できるコントロールとして下記が挙げられます。
- [ S3.2 ] S3 汎用バケットはパブリック読み取りアクセスを禁止する必要があります
本当に公開すべき S3 バケットである場合にリスクの判断後抑制済みにしても良いです。 - [ DynamoDB.1 ] DynamoDB のテーブルは、需要に応じて自動的に容量をスケールする必要があります
可用性のためのチェックですが、コストを制限する場合などで必ずしもスケールする必要はなく、対象システムの特性を加味して個別に抑制済みにしても良いです。
一方で、コントロールの無効化や抑制済みを乱用するとチェックが意味をなくすため、組織の中でどこまでなら抑制済みにしていいかなどの条件を整備し、これもガイドラインなどにまとめていきましょう。AWS を利用するメンバーで話し合いながら整備していくことで、組織全体の AWS セキュリティに対する理解度がより上がっていきます。みんなで 100% を目指す運用が可能です。
大事なのは、ただ 100% にすることではなくこの工程を経てすべての関係者がコンセンサスを取りつつ、組織としての AWS セキュリティの成熟度を上げながらセキュアに使い続けられる土壌を作ることです。難易度が高いと感じられるかもしれませんが、目指すべき場所と考え段階的に進めていきましょう。
まとめ
AWS Security Hub CSPM を使い始めてから使いこなすまでの 5 段階のステップを紹介しました。この道のりは決して簡単ではないですが、AWS を使っていくなら絶対に外せない道のりです。
絶対に 1 人では達成できないので、最初は 1 人でも少しずつ周りを巻き込んで、目指せ 100% !
筆者プロフィール
臼田 佳祐 (AWS Security Hero)
クラスメソッド株式会社 クラウド事業本部サービス開発室
シニアソリューションアーキテクト
クラスメソッド株式会社で AWS とセキュリティに関する様々な活動を行っていて、最近ではセキュリティサービスの開発に注力。社外では Security-JAWS の運営を実施。Amazon GuardDuty を始め、AWS Security Hub や Amazon Detective などの AWS のセキュリティサービスを愛するエンジニア。CISSP。AWS Security Hero (2023~)
