よくあるAWSセキュリティ設定漏れ10選の後半戦です。
前半のチェックまだの方はこちらから👇
AWSセキュリティ設定漏れ10選 一覧
今回は、後半5項目をご紹介していきます。
| # | 項目 | 自分で確認 | 自動検出 |
|---|---|---|---|
| 1 | ルートユーザーの認証情報 | ○ | ○ |
| 2 | セキュリティグループの全開放 | ○ | ○ |
| 3 | S3のパブリックアクセスブロック | ○ | ○ |
| 4 | CloudTrailの有効化と保全 | ○ | ○ |
| 5 | セキュリティ連絡先の設定 | ○ | ○ |
| 6 | IAMの実効権限と権限昇格パス | △ | △ |
| 7 | 「実質公開」状態のリソース | △ | △ |
| 8 | 長期未使用の認証情報 | △ | △ |
| 9 | バックアップの復元可能性 | × | × |
| 10 | 検出結果そのものの運用 | × | × |
△ と × は「確認が不可能」という意味ではありません。単発の設定チェックでは判定しにくい、という意味です。
ツールのスコアが高くても残る5項目
ここから先の5項目は、前半とは性質が異なります。
設定監査ツールが評価しているのは、基本的に「個々の設定値が、定められた基準に適合しているか」です。ルートユーザーにアクセスキーがあるか、S3バケットが公開されていないか。これらは設定値を読み取れば機械的に判定できます。一方、次の3つはそれだけでは判定しにくい問題です。
組み合わせで生じる問題。
個々の設定はすべて基準に適合しているのに、それらが組み合わさった結果として意図しない権限や経路が生まれるケースです。設定を一つずつ見るのではなく、環境全体を関係性として解析する必要があります。
「正しく設定されているが、不要」な状態。
使われていないIAMユーザーや、廃止済みシステムのアクセスキーは、設定として何も間違っていません。しかし攻撃者から見れば、これらは現役の認証情報と同じ価値を持ちます。
運用が回っているかどうか。
検出結果が出ていても、誰も見ていない、抑制ルールで消しているだけ、といった状態はスコアに現れません。むしろ抑制した分だけスコアは改善します。
つまり、設定の正しさとリスクの低さは、必ずしも一致しません。
ただし、この領域が手つかずというわけでもありません。2025年に登場した新しいSecurity Hubのexposure findingsを起点に、2026年へ入ってからは権限昇格パスの解析、インターネットからの到達性の実測、未使用アクセスの検出といった機能が相次いで追加されています。利用には対応する機能の有効化が必要で、料金や条件も機能によって異なりますが、検出できる範囲は着実に広がっています。
それでもこの5項目を挙げるのは、検出できることと、対処できることが別だからです。検出結果を前にして、それが意図した設定なのか事故なのか、消してよいのか残すべきなのかを決めるところに、依然として人の判断が要ります。
6. IAMの実効権限と権限昇格パス｜個々のポリシーが正しくても安全とは限らない
CSPMは個々のIAMポリシーが基準に沿っているかを評価します。ワイルドカードの多用、管理者権限の直接付与といった分かりやすい問題は検出されます。
しかし実際の権限昇格は、単体では問題のない権限の組み合わせで起こります。たとえば、ロールを渡す権限と、そのロールを使ってリソースを作成する権限。それぞれは業務上必要で、どちらも減点対象ではありません。ところが両方を持つプリンシパルは、自分より強い権限のロールを引き受けられます。
さらに、ロールの引き受けが連鎖する場合、リソースベースのポリシーと組み合わさる場合、アカウントをまたぐ場合と、経路は容易に複雑化します。ポリシーを1枚ずつ見ている限り、この構造は見えません。
IAM Access Analyzerやポリシーシミュレーターで部分的な検証はできますが、「このプリンシパルは最終的にどこまで到達できるのか」を組織全体で洗い出すのは、手作業では現実的ではありません。
2026年7月、AWS Security HubのExposure findingsに Impact Analysis が追加され、公開状態のリソースに紐づくIAMプリンシパルの実効権限を解析して、権限昇格パスを可視化できるようになりました。この領域は自動化が進みつつあります。ただし対象はExposure findingsとして検出されたリソース起点であり、組織のIAM構造全体を保証するものではありません。CSPMでも検出されますが、検出されたうえで「業務上必要だから」と例外扱いのまま放置されているパターンが多く、後述の項目10と地続きの問題でもあります。
7. 「実質公開」状態のリソース｜設定は閉じているのに、外から届く
セキュリティグループを適切に絞っていても、そのリソースがインターネットから到達できないとは限りません。
ロードバランサーやCDN、API Gateway経由でリクエストが転送されていれば、バックエンドのセキュリティグループが特定のソースしか許可していなくても、実質的には外部に公開されています。検証用に付けたパブリックIPが残っているENI、VPCピアリングやTransit Gateway経由で別環境から到達できる経路も同様です。
ここで効いてくるのが、「到達しうる」と「実際に到達できる」は別物という点です。従来の到達性チェックは、セキュリティグループやルートテーブルの設定から経路を計算します。設定上は到達可能でも実際には応答がない、逆に設定を追い切れずに見落とす、といったずれが生じます。
2026年7月に追加された Security Hub の Network Scanning は、実際にインターネット側からリソースをプローブして到達性を判定します。到達可能なポートと、その背後で動いているサービスまで特定します。設定の読み取りではなく実測に踏み込んだ点で、この項目の状況は変わりつつあります。
とはいえ、検出された「公開されている」という事実に対して、それが意図した公開なのか事故なのかを判断できるのは、そのシステムを理解している人間だけです。
8. 長期未使用の認証情報｜設定としては正しいので、誰にも咎められない
退職した社員のIAMユーザー、契約が終了した委託先向けのロール、検証で作ったまま消していないアクセスキー、すでに廃止されたCIパイプラインの認証情報。
これらは設定として何も間違っていません。適切な権限が付与され、命名規則にも従っている。それでいて、漏洩したときの被害は現役の認証情報と変わりません。
自動検出がまったく効かないわけではありません。IAMユーザーの未使用の認証情報については、IAM.8 や IAM.22 といったコントロールが以前から存在し、スコアにも反映されます。ただしこれらが見ているのはIAMユーザーの認証情報であって、未使用のロールや、付与されているが一度も使われていない権限までは対象外でした。実際の運用では、人ではなくロールとポリシーの方に不要な残骸が溜まります。
棚卸しが進まない理由ははっきりしています。消していいかどうかの判断がつかないからです。最終使用日から半年以上経っているキーを見つけても、「バッチ処理で年1回だけ使われているのでは」という懸念が消えなければ、誰も削除ボタンを押せません。結果として「調べたが残した」が積み上がります。
2026年5月、Security Hubは未使用のIAM権限・ロール・認証情報を組織横断で検出する機能を追加しました。一定期間使われていないという事実だけでなく、実際の利用状況に基づいてリスクを評価し、権限を絞る方向の提案まで得られます。
それでも、その権限やロールを本当に削除・縮小してよいのかという業務上の判断は残ります。ここには対象システムへの理解が要り、自動化できる部分ではありません。
9. バックアップの復元可能性｜取得できていることと、戻せることは違う
ここまでは「入られないための設定」でしたが、入られた後に効くものも設定漏れの対象です。ランサムウェアを想定するなら、なおさら外せません。
バックアップは、取得設定の有無ならチェックできます。しかし本当に問われるのは、必要なときに実際に復元できるかです。
見落とされやすいのは次のような点です。復元手順が文書化されておらず、担当者の記憶に依存している。暗号化に使ったKMSキーの権限が変更され、復号できない。バックアップが本番と同じアカウント・同じリージョンにしかなく、アカウントごと侵害されたら一緒に失われる。そもそも復元にかかる時間を測ったことがなく、事業側と合意したRTOを満たせるか誰も知らない。
ランサムウェアを想定するなら、変更・削除ができない形での保管や、別アカウントへの複製も検討が必要です。
これらは設定値のスキャンでは判定できません。判定する唯一の方法は、実際に復元してみることです。年に一度でも復元訓練を実施している組織は、経験上かなり少数です。
10. 検出結果そのものの運用｜スコアは上がったが、リスクは減っていない
最後は、これまでの9項目すべてを無効化しうる項目です。
セキュリティサービスを導入した組織で、次のような状態は珍しくありません。
- 対応が難しい検出結果に抑制ルールを設定し、そのまま恒久化している
- 利用していないつもりのリージョンでサービスが有効化されておらず、そこにリソースが存在する
- 新しく作成したアカウントが組織の管理下に入っておらず、集約対象から漏れている
- 通知先のチャンネルは生きているが、誰も見ていない
- 検出結果の件数だけを月次で報告し、内容は追っていない
いずれの場合も、ダッシュボード上のスコアは良好に見えます。抑制した項目は減点されず、有効化していないリージョンのリソースはそもそも評価されないからです。つまりスコアの改善と、リスクの低減が乖離します。
しかもこの乖離は、機能が充実するほど広がりやすくなります。検出できる範囲が広がれば検出結果は増え、増えれば処理しきれず、処理しきれなければ抑制するか無視するしかない。ツールを導入したのに安心できない、という感覚の正体はここにあります。
必要なのは、検出結果に優先度をつけ、対応するか受容するかを判断し、受容したなら理由と期限を記録して定期的に見直す。この一連のサイクルです。これはツールの機能ではなく、運用の設計です。
まとめ｜検出できることと、対処できることの間にある距離
10項目を振り返ると、前半5つと後半5つの違いがはっきりします。
前半は、確認すれば分かり、直せば終わる問題です。まだ手をつけていない項目があれば、この記事を閉じたあとにコンソールを開いてみてください。おそらく30分もかかりません。
後半5つはそうはいきません。共通しているのは、検出することよりも、検出結果をどう扱うかの方が難しいという点です。
2026年に入ってからのAWS Security Hubのアップデートを見ても、この構図は変わっていません。未使用のアイデンティティリスクの検出、Exposure findingsのImpact Analysis、実測ベースのNetwork Scanning、Azureリソースへの対応と、検出できる範囲は着実に広がっています。それ自体は歓迎すべき進化です。
しかし検出範囲が広がるほど、手元に届く検出結果は増えます。増えた検出結果に優先度をつけ、対応するか受容するかを判断し、判断の記録を残して見直す。この作業量は自動的には減りません。むしろ増えます。ツールを入れることと、それが回り続けることの間には距離があるのです。
クララでは、この2つの段階に対応したサービスを提供しています。
| 👉まだCSPMを導入していない場合は、「AWS セキュリティレポート」をご利用ください。お試しでCSPMを導入し、現在のAWSアカウントでどのようなアラートが上がっているかをレポートとして可視化します。まず自社の現在地を知りたい、という段階に適しています。 |
| 👉すでに導入しているが運用が回っていない場合は、「AWS マネージドセキュリティ Secure」をご検討ください。Security Hub CSPMの初期設定・構築から日々の運用までを担い、検出結果に優先度をつけて対応方針をお伝えします。本記事の項目10に心当たりがあれば、まさにこの領域です。 |
