「AWSのセキュリティ設定、たぶん大丈夫だと思うのですが」
AWSの運用について伺うと、こうしたお答えをいただくことがよくあります。「たぶん」がつくのは、確認したことがないか、確認したが継続できていないかのどちらかです。
本記事では、AWS環境でよく見られるセキュリティ設定漏れを10項目挙げます。前半5つは、マネジメントコンソールから数分で確認できるものです。後半5つは、設定値のチェックだけでは判定しにくく、スコアが良好に見えても残りやすいものを取り上げます。
▶うちのAWS、大丈夫？ 26項目でわかる自社環境のセキュリティ診断 スコア＆現状分析で「課題」と「優先順位」を可視化！かんたんチェックリストを無料配布中 |
AWSセキュリティ設定漏れ10選 一覧
まずは全体像です。前半5項目はマネジメントコンソールから数分で確認できます。後半5項目は、確認そのものに手間と前提知識が必要な領域です。
| # | 項目 | 自分で確認 | 自動検出 |
|---|---|---|---|
| 1 | ルートユーザーの認証情報 | ○ | ○ |
| 2 | セキュリティグループの全開放 | ○ | ○ |
| 3 | S3のパブリックアクセスブロック | ○ | ○ |
| 4 | CloudTrailの有効化と保全 | ○ | ○ |
| 5 | セキュリティ連絡先の設定 | ○ | ○ |
| 6 | IAMの実効権限と権限昇格パス | △ | △ |
| 7 | 「実質公開」状態のリソース | △ | △ |
| 8 | 長期未使用の認証情報 | △ | △ |
| 9 | バックアップの復元可能性 | × | × |
| 10 | 検出結果そのものの運用 | × | × |
△ と × は「確認が不可能」という意味ではありません。単発の設定チェックでは判定しにくい、という意味です。
自分で確認できる5項目
1. ルートユーザーの認証情報｜「MFAを設定しましょう」はもう古い
チェックリスト記事の定番だった「ルートユーザーのMFA未設定」は、2026年現在ほぼ成立しません。AWSは2024年に管理アカウントとスタンドアロンアカウントでルートユーザーのMFAを必須化し、2025年にはOrganizationsのメンバーアカウントにも対象を拡大しました。現在はすべてのアカウントタイプでルートユーザーにMFAの設定が必要です。
厳密には、最初のサインイン試行から35日以内に登録すればよい猶予があります。ただし期間が過ぎればMFAなしでコンソールに進めないため、未設定のまま使い続けることはできません。
代わりに確認すべきは次の3点です。
アクセスキーが残っていないか。
MFA必須化はコンソールへのサインインに対する制限であり、アクセスキーによるAPI呼び出しには効きません。AWSはルートユーザーのアクセスキーを作成しないことをベストプラクティスとして明示しています。過去に発行されたものが残っていれば、それは制限のかからない最強の認証情報がそのまま存在している状態です。
MFAデバイスを誰が持っているか。
特定個人のスマートフォンに紐付いたままだと、その人の退職や機種変更でサインインできなくなります。
メンバーアカウントのルート認証情報を放置していないか。
Organizationsを利用しているなら、中央ルートアクセス管理でメンバーアカウントのパスワード・アクセスキー・MFAを管理アカウント側から削除できます。Organizationsで新規作成したアカウントは、デフォルトでルート認証情報を持ちません。
確認手順：IAMコンソールのダッシュボードでルートユーザーのアクセスキーの有無を確認します。Organizations利用中の場合は、IAMコンソールの「ルートアクセス管理」から一元管理の有効／無効を確認してください。
Security Hubでは、ルートユーザーのアクセスキーの有無を [IAM.4]、MFAの設定状況を [IAM.9]（ハードウェアMFAに限定する場合は [IAM.6]）で検出できます。
（なお、かつて存在した「ルートユーザーの使用を避けます」というコントロール IAM.20 は2024年に廃止されています。古い記事にはまだ現役として載っているのでご注意ください。）
2. セキュリティグループの全開放｜検証で開けて、そのまま
インバウンドルールで 0.0.0.0/0 に対してSSH（22）、RDP（3389）、データベースのポート（3306、5432など）を許可している状態です。設定漏れの中で最も多く、そして最も直接的に侵害につながります。
厄介なのは、悪意ある設定ミスではなく「検証のため一時的に開けて、そのまま忘れた」という経緯で生まれる点です。当時の担当者がすでに異動していると、なぜ開いているのか誰も説明できず、閉じる判断もできません。
IPv6を見落としがちなことにも注意してください。0.0.0.0/0 は塞いだのに ::/0 が残っている、というケースは珍しくありません。
確認手順：EC2コンソールの「セキュリティグループ」で、インバウンドルールのソースを一覧確認します。VPCコンソールのフィルタ機能で 0.0.0.0/0 を含むルールを絞り込むと早いです。
CSPMでも検出されますが、検出されたうえで「業務上必要だから」と例外扱いのまま放置されているパターンが多く、後述の項目10と地続きの問題でもあります。
3. S3のパブリックアクセスブロック｜アカウント単位とバケット単位の両方を見る
S3のブロックパブリックアクセスには、アカウント単位の設定とバケット単位の設定があり、それぞれに4つのオプションがあります。よくあるのは、アカウント単位で有効にしてあるので安心していたが、実際には一部が無効化されていた、あるいはその逆というケースです。
静的サイトのホスティングやコンテンツ配信のために特定のバケットで意図的に解除することはあります。問題は、その解除がいつのまにか「アカウント全体の設定を緩める」形で実施されている場合です。
なお、両者の関係は「どちらか一方が勝つ」というより、複数のレベルで設定されている場合、最も制限の厳しい設定が適用されると理解するのが正確です。したがってアカウント単位でブロックしていれば、個別のバケット側で解除してもブロックが維持されます。逆に言えば、アカウント単位の設定が緩んでいれば、バケット単位でどれだけ丁寧に設定していても防御の最終ラインが1枚失われます。
確認手順：S3コンソールの左メニュー下部にある「アカウントと組織の設定」を開くと、「このアカウントのブロックパブリックアクセス設定」が表示されます。「パブリックアクセスをすべてブロック」と、その下の4項目がすべてオンかを確認してください。続いて個別のバケットの「アクセス許可」タブで同じ4項目を確認し、あわせてバケットポリシーの Principal に “*” が指定されていないかを見てください。
4. CloudTrailの有効化と保全｜インシデントのときに「調べられない」が確定する
CloudTrailの証跡を適切に構成していないと、侵害の調査に必要なログを長期間保存できず、調査が大きく制限されます。設定を怠って困るのは平時ではなく有事です。
確認すべきは有効かどうかだけではありません。証跡が全リージョンを対象にしているか、ログファイルの整合性検証が有効か、そしてログの保存先S3バケットが保護されているかの3点です。侵入者が最初にやることのひとつは証跡の消去なので、ログ自体が同じアカウントの無防備なバケットに置かれていれば、記録があっても信用できません。
なお、CloudTrailを設定していなくてもコンソールの「イベント履歴」で直近90日分は追えます。ただし対象は管理イベントのみで、データイベントは記録されません。S3への配信や長期保存、任意期間の検索もできません。証跡の代わりと考えるのは危険です。
確認手順：CloudTrailコンソールの「証跡」で、「すべてのリージョンに適用」と「ログファイルの検証」が有効かを確認します。続いて保存先バケットのパブリックアクセスブロック、バケットポリシー、暗号化設定を確認してください。
5. セキュリティ連絡先の設定｜AWSからの侵害通知が誰にも届かない
地味ですが、実害の大きさに対して知られていない項目です。
AWSは、公開されているコードリポジトリにアクセスキーが漏洩しているなど、アカウントに関するセキュリティ上の問題を検知した際に、登録された連絡先へ通知を行うことがあります。ここが未設定だと、AWSが気づいていても、その情報が担当者に届きません。
確認手順：アカウント設定ページの「代替の連絡先」で、セキュリティの連絡先が設定され、かつ現在も受信可能なアドレスかを確認します。Organizations利用中であれば、管理アカウントからメンバーアカウントの代替連絡先をまとめて設定・更新できます
Security Hubのコントロール Account.1 でも、この設定の有無をチェックできます。
前半5項目を確認したあとに
ここまでの5項目は、一度確認すれば済むものではありません。セキュリティグループは日々変更され、バケットは増え、アカウントも増えます。今日すべて問題なくても、来月には別の場所に穴が空きます。
つまり本当の課題は「確認できるか」ではなく「確認し続けられるか」です。ここが手作業の限界で、CSPMの出番でもあります。設定監査を有効化しておけば、これら5項目は変更のたびに自動で評価され、逸脱があれば検出結果として上がってきます。
まだ導入していない場合、最初のハードルは「何がどれだけ検出されるのか想像がつかない」という点でしょう。その場合は、まず現状を可視化するところから始めるのが現実的です。
後半をお楽しみに！
▶【クララのAWSセキュリティ】AWSベストプラクティスをベースに設計 その他、構築から監視・運用まで、ワンストップで支援しています。 コスト削減や運用負担軽減のヒントが詰まった資料をぜひご覧ください！ |
