クラウドの設定ミスはなぜ起きる？AWS・Azureで多いセキュリティリスク10選

クラウド設定ミスによる情報漏洩は「他人事」ではない

「うちはクラウドに移行したから、データセンター時代より安全になった」——そう考えているセキュリティ担当者は少なくありません。しかし現実は正反対かもしれません。

クラウドサービスの普及とともに、設定ミスに起因する情報漏洩事故が急増しています。米国のクラウドセキュリティ企業Wiz社の調査（2024年版クラウドセキュリティレポート）によれば、クラウド環境で発生したセキュリティインシデントの58%以上は、外部からの高度な攻撃ではなく、「誤った設定」が直接の原因でした。

日本でも同様の傾向があります。IPA「情報セキュリティ10大脅威2026（組織編）」において「クラウドサービスの設定ミスによる情報漏洩」は上位にランクされており、金融機関・官公庁・大手製造業など業種を問わず発生しています。

S3バケットが公開設定のまま放置されていた、IAMロールに過剰な権限が付与されていた、セキュリティグループで全ポートが開放されていた——これらはどれも「高度な攻撃」ではなく、運用者の設定ミスや知識不足から発生した事故です。

本記事では、AWS・Azureのそれぞれで頻発する設定ミスを5つずつ、合計10のリスクに絞り込み、影響度・発見方法・修正方法をセットで解説します。

なぜクラウドで設定ミスが起きるのか

1. クラウドの変化スピードが速すぎる

AWS・Azureとも、年間数百件以上の新機能・新サービスをリリースしています。エンジニアが特定のサービスの設定を学習し、ドキュメントを読み込んだとしても、半年後にはUIや設定項目が変わっていることが珍しくありません。セキュリティのベストプラクティスも頻繁に更新されるため、継続的なキャッチアップが欠かせません。

2. IAMポリシーの複雑さ

クラウドのアクセス管理は柔軟性が高い反面、設定が複雑です。AWSのIAMでは、ユーザー・グループ・ロール・ポリシーが複数階層で絡み合うため、「どのエンティティがどのリソースに何の操作ができるか」を正確に把握することは、経験豊富なエンジニアでも難しい作業です。結果として「とりあえず広めの権限を付けておく」という運用が生まれやすくなります。

3. デフォルト設定の危険性

クラウドプロバイダーの初期設定が必ずしもセキュリティファーストではない場合があります。「設定しなければデフォルトのまま安全」という思い込みは危険です。S3バケットのアクセス制御やAzureのストレージパブリックアクセスなど、デフォルト設定が後に変更され、古い設定のままになっているケースも多発しています。

4. マルチアカウント・マルチクラウド管理の限界

企業規模が拡大すると、AWSアカウントやAzureサブスクリプションが部門ごとに増殖します。「誰がどのアカウントを管理しているかわからない」「使われていないサブスクリプションが放置されている」という状況が、設定ミスの温床になります。

5. 開発チームとセキュリティチームの分断

DevOpsの普及でエンジニアがクラウド設定を直接操作するケースが増えましたが、セキュリティ部門が関与しないまま設定が進むことも多くなりました。「動けばOK」という開発優先の文化の中で、セキュリティ設定が後回しになりがちです。

AWS編：5つの設定ミスとその対策

ミス①：S3バケットのパブリック公開

概要

Amazon S3（Simple Storage Service）は、AWSで最もよく使われるオブジェクトストレージサービスです。S3バケットのアクセス設定を誤ると、本来非公開であるべきファイル（個人情報・設計書・APIキーを含む設定ファイルなど）がインターネット上から誰でも参照できる状態になります。

影響度：高

• 顧客の個人情報・クレジットカード情報・医療記録などの大規模漏洩
• 競合他社・攻撃者による機密ビジネスデータの取得
• GDPR・個人情報保護法違反による法的制裁・賠償リスク

発見方法

• AWSマネジメントコンソールの「S3 → バケット → アクセス」列で「パブリック」と表示されているバケットを確認
• AWS Trusted Advisorの「バケットのアクセス許可」チェック
• AWS Security Hubのチェック：S3.2（S3バケットはパブリック読み取りアクセスを禁止する必要がある）

修正方法

• バケットのパブリックアクセスブロックを有効化：アカウントレベルおよびバケットレベルで「すべてのパブリックアクセスをブロック」を設定
• バケットポリシーを確認し、"Principal": "*" を許可している記述を削除
• データの公開が必要な場合は、CloudFrontのOAI（Origin Access Identity）を経由する構成に変更

2023年以降に作成されたS3バケットはデフォルトでパブリックアクセスがブロックされますが、それ以前に作成されたバケットは設定が引き継がれるため、必ず既存バケット全体を確認してください。

ミス②：IAMロール・ユーザーへの過剰な権限付与

概要

「とりあえずAdministratorAccess（管理者権限）を付けておけば動く」という運用が横行しています。EC2インスタンスにAdministratorAccessポリシーを付与したIAMロールを設定しておくと、そのEC2が侵害された際に攻撃者はAWSアカウント全体を掌握できます。

影響度：高

• EC2・Lambda・ECSなど一つのサービスが侵害されただけでアカウント全体が乗っ取られるリスク
• 大量のリソース作成（暗号資産マイニングなど）による高額請求
• 他の顧客環境・本番データへの不正アクセス

発見方法

• AWS IAM Access Analyzerを使用して、過剰な権限を持つロール・ユーザーを検出
• aws iam generate-credential-report でクレデンシャルレポートを出力し、長期間使用されていないアクセスキーを確認
• AWS Security Hubのチェック：IAM.1（IAMポリシーでは完全な管理者権限を許可しないこと）

修正方法

• 最小権限の原則（Principle of Least Privilege）を徹底：必要最小限のアクションのみを許可するカスタムポリシーを作成
• AdministratorAccessの使用を禁止し、役割別にポリシーを細分化
• AWS Organizationsのサービスコントロールポリシー（SCP）で組織全体に権限の上限を設定
• 90日以上使用されていないアクセスキーを自動で無効化するルールをAWS Configで設定

ミス③：セキュリティグループの無制限インバウンドルール

概要

EC2インスタンスに付与するセキュリティグループで、ソースIPアドレスに0.0.0.0/0（全インターネット）を指定したままSSH（22番ポート）やRDP（3389番ポート）を開放しているケースは非常に多く見られます。これは攻撃者にとって格好のブルートフォース攻撃・脆弱性スキャンの対象になります。

影響度：高

• SSH/RDPへのブルートフォース攻撃によるサーバー侵害
• 管理ポートへの脆弱性スキャン・ゼロデイ攻撃
• Webサーバー以外のポートが不必要に露出しているケースでは横展開のリスク

発見方法

• AWSマネジメントコンソール「EC2 → セキュリティグループ → インバウンドルール」で0.0.0.0/0を含むルールを確認
• AWS Trusted Advisorの「セキュリティグループ – 制限なしのアクセス」チェック
• AWS Security Hubのチェック：EC2.19（セキュリティグループで22番・3389番ポートへの無制限アクセスを許可しないこと）

修正方法

• SSH・RDPアクセスは特定のIPアドレスレンジのみに限定（社内IP・VPN出口IPなど）
• SSH・RDPが必要な場合はAWS Systems Manager Session Manager経由でアクセスし、セキュリティグループでポートを完全に閉じる
• 踏み台（Bastion）サーバー経由のアクセスに統一し、Bastionのセキュリティグループのみを管理IPに制限

ミス④：CloudTrailの無効化・ログの未保全

概要

CloudTrailはAWSアカウント上のすべてのAPIコールを記録するサービスです。デフォルトでは管理イベントは有効ですが、データイベント（S3オブジェクトへのアクセスなど）は無効です。また、CloudTrailが有効でもログが適切に保全されていないと、インシデント発生後の調査が不可能になります。

影響度：中〜高

• インシデント発生時に「誰が・何を・いつ」操作したかの追跡が不可能
• コンプライアンス監査（SOC2・PCIDSS・FISC安全対策基準）で証跡提出ができない
• 攻撃者による証拠隠滅（CloudTrailの無効化自体が攻撃の一手）

発見方法

• CloudTrailコンソールでトレイルの有効化状況を確認
• AWS Config ルール：cloudtrail-enabled で有効化状態をチェック
• CloudTrailのログが別リージョンまたは別アカウントのS3バケットに保存されているかを確認

修正方法

• すべてのリージョンにまたがるCloudTrailトレイルを一つ作成し、有効化
• ログを保存するS3バケットにはMFADelete・バケットポリシーによるアクセス制限を設定
• CloudWatch Logsと統合して、CloudTrailの無効化アクション自体をアラートで検知

ミス⑤：Secrets Managerを使わずにハードコードされた認証情報

概要

EC2のユーザーデータ、Lambda環境変数、GitリポジトリにAPIキー・DBパスワード・AWSアクセスキーをそのまま記述してしまうケースは後を絶ちません。AWSではAWS Secrets Manager（またはParameter Store）を使って認証情報を安全に管理することが推奨されています。

影響度：高

• Gitリポジトリが公開状態だった場合、認証情報が即時漏洩
• GitHubなどのコードホスティングサービスには認証情報を自動スキャンするBotが常時活動しており、数分以内に悪用されることがある
• 一つの認証情報から連鎖的なアクセス拡大（ラテラルムーブメント）が発生

発見方法

• git log でコミット履歴を検索し、認証情報の混入を確認（git-secrets・truffleHogなどのツールが有効）
• AWS Security Hubのチェック：SecretsManager.1
• Amazon Inspector の「コード内のシークレット検出」機能

修正方法

• すべての認証情報をAWS Secrets ManagerまたはAWS Systems Manager Parameter Store（SecureString）に移行
• アプリケーションコードからは環境変数経由でSecrets Managerを呼び出す構成に変更
• GitHubのpushプロテクションやgit-secretsを使い、コミット時に認証情報の混入を自動検知

AWS Organizationsを使って複数アカウントを管理している場合、AWS Security Hubを組織レベルで有効化すると、上記のすべてのチェックを全アカウント横断で集中管理できます。

Azure編：5つの設定ミスとその対策

ミス⑥：Entra IDのゲストアクセスの過剰な権限

概要

Microsoft Entra ID（旧Azure Active Directory）では、外部ユーザーをゲストとして招待できます。デフォルト設定では、ゲストユーザーはディレクトリ内の他のユーザー・グループ・アプリ情報を広範に閲覧できる権限が付与されています。外部ベンダーや取引先をゲスト招待した際に、この設定を見直さないと内部情報が意図せず漏洩するリスクがあります。

影響度：中〜高

• 外部ユーザーによる社内ユーザー一覧・グループ構成・アプリ登録情報の閲覧
• ゲストアカウントへのフィッシング攻撃を経由した内部情報の窃取
• コンプライアンス上の問題（社外に共有すべきでない組織情報の漏洩）

発見方法

• Entra ID管理センター「外部 ID → 外部コラボレーション設定」でゲストアクセスレベルを確認
• Microsoft Secure Score（Microsoft Defender ポータル）でゲスト関連の推奨事項を確認

修正方法

• ゲストアクセスレベルを「ゲストユーザーのアクセスは自分のディレクトリオブジェクトのプロパティとメンバーシップに制限される」に変更
• 定期的なアクセスレビュー（Entra ID Premium P2のアクセスレビュー機能）を有効化し、不要なゲストアカウントを削除
• 条件付きアクセスポリシーでゲストユーザーのアクセスを特定アプリのみに制限

Entra IDの詳細なセキュリティ設定については、Microsoft Entra IDセキュリティ設定チェックリスト：見落としがちな15の設定も参照してください。

ミス⑦：Azureストレージアカウントのパブリックアクセス許可

概要

Azureストレージ（Blob Storage）にもAWSのS3と同様の問題が発生します。コンテナーのアクセスレベルを「コンテナー（匿名読み取りアクセス）」や「BLOB（匿名読み取りアクセス）」に設定すると、認証なしでインターネットからアクセスできる状態になります。

影響度：高

• 機密ドキュメント・バックアップデータ・ログファイルのインターネット公開
• Azureサービス間通信用の接続文字列・SASトークンの漏洩

発見方法

• Azureポータル「ストレージアカウント → Blobサービス → コンテナー」でアクセスレベルを確認
• Microsoft Defender for Cloudの推奨事項：「ストレージアカウントのパブリックアクセスを禁止する」
• Azure Policyを使い、パブリックアクセスが許可されているストレージアカウントを組織全体でスキャン

修正方法

• ストレージアカウントレベルで「BLOBの匿名アクセスを許可する」をオフに設定（Azure Portal または Azure CLI az storage account update --allow-blob-public-access false）
• 公開が必要なコンテンツはAzure CDNまたはAzure Front Doorを経由し、ストレージ自体は非公開のままにする
• Azure Private Endpointを使用してVNet内のリソースのみからアクセスできる構成に変更

ミス⑧：NSG（ネットワークセキュリティグループ）の広範なインバウンドルール

概要

AWSのセキュリティグループに相当するAzureのNSG（Network Security Group）でも同様の問題が発生します。0.0.0.0/0を送信元とするSSH（22番）・RDP（3389番）・データベースポート（1433・3306など）の開放は、攻撃者の格好の標的になります。

影響度：高

• ブルートフォース攻撃・辞書攻撃によるリモートアクセス侵害
• データベースポートが直接インターネットに露出しているケースでのSQLインジェクション・不正アクセス

発見方法

• Azureポータル「ネットワークセキュリティグループ → インバウンドセキュリティ規則」で送信元*またはAnyのルールを確認
• Microsoft Defender for Cloudの推奨事項：「管理ポートを仮想マシンで閉じる必要がある」
• Azure Security Center（Defender for Cloud）のアダプティブネットワーク強化機能

修正方法

• 管理ポートへのアクセスは特定のIPアドレスのみに制限
• Azure Bastionを使用し、パブリックIPアドレスなしでRDP/SSHアクセスを実現
• Azure Virtual Network Gateway（VPN）またはExpressRoute経由のアクセスに統一

ミス⑨：Microsoft Defender for Cloudの未有効化

概要

Microsoft Defender for Cloud（旧Azure Security Center）は、Azureリソースのセキュリティ状態を評価し、脅威を検知するセキュリティ管理サービスです。無料プランは基本的なポスチャ評価のみですが、有料の「Microsoft Defender for ○○」シリーズを有効化すると高度な脅威検知が可能になります。この有料プランが有効化されていないケースが多く見られます。

影響度：中

• 仮想マシン・コンテナー・ストレージなどに対する脅威の検知漏れ
• 重要な設定ミスがあってもアラートが上がらず、見逃しが発生
• インシデント発生後の調査に必要なログ・タイムラインが取得できない

発見方法

• Defender for Cloud「環境設定」でサブスクリプションごとのDefenderプランの有効化状況を確認
• Microsoft Secure Scoreで有効化関連の推奨事項を確認

修正方法

• 少なくとも「Defender for Servers」「Defender for Storage」「Defender for SQL」は有効化を検討
• Defender for Cloud Appsと統合してShadow IT（非承認SaaSの検出）を有効化
• Log Analytics Workspaceにログを集約し、Microsoft Sentinelと統合して高度な分析を実現

Microsoftセキュリティツールの活用については、Microsoft 365のセキュリティ設定ガイドも参考になります。

ミス⑩：診断設定（Diagnostic Settings）の未構成

概要

AzureリソースのアクティビティログやリソースログをLog Analytics Workspaceやストレージアカウントに転送する「診断設定」が構成されていないと、誰がいつ何を操作したかの記録が残りません。特にEntra IDのサインインログ・監査ログの未収集は、不審なアクセスの検知を著しく困難にします。

影響度：中〜高

• 不正アクセス・特権操作の痕跡を追跡できない
• セキュリティ監査・コンプライアンス監査（ISO27001・ISMS等）で証跡を提出できない
• インシデントレスポンスにおけるタイムライン復元の不可

発見方法

• Azureポータル各リソースの「診断設定」タブで設定有無を確認
• Entra ID管理センター「モニタリング → 診断設定」でサインインログ・監査ログの転送設定を確認
• Azure Policy（組み込みポリシー：Deploy Diagnostic Settings）を使い、全リソースの診断設定状況を一括確認

修正方法

• 重要リソース（Entra ID・Key Vault・仮想マシン・ネットワークセキュリティグループ）の診断設定を優先的に構成
• Log Analytics WorkspaceへのRetention（保持期間）を最低90日以上に設定（規制業界では1年以上推奨）
• Azure Policyを使い、新規リソース作成時に自動的に診断設定が構成されるよう強制

CSPMツールで設定ミスを継続的に検出する

上記で紹介した設定ミスを手作業で一つひとつチェックすることは、中規模以上のクラウド環境では現実的ではありません。CSPM（Cloud Security Posture Management）ツールを活用することで、クラウド環境全体の設定ミスを自動的に継続的にスキャンすることが可能です。

主なCSPMツール

CSPMツールは設定ミスを自動検出できますが、検出された課題を適切に優先度付けして修正するのは人間の判断が必要です。「Critical」の指摘が数百件表示されて何から手をつければよいかわからない、というケースでは専門家によるアセスメントが有効です。

AWS・Azureのクラウドセキュリティ設定についてプロフェッショナルによる診断を受けたい方はこちらからご相談ください。

プラットフォーム診断サービスの詳細を見る

プラットフォーム診断でクラウド設定ミスを網羅的に洗い出す

AEVUSのプラットフォーム診断では、AWS・Azure・GCPのクラウド環境に対して、上記のような設定ミスを体系的に評価します。CIS（Center for Internet Security）ベンチマークやNIST CSFをベースに、数百項目の設定チェックを実施し、優先度付きのレポートを提供します。

特にAzure環境のEntra IDセキュリティ設定は、Microsoft 365との統合があるため評価範囲が広くなります。Microsoft 365環境全体のセキュリティを評価したい場合は、M365セキュリティアセスメントもあわせてご検討ください。

Yahoo! JAPAN、Nikon、三井住友カード、森トラスト、双日など多くの企業でクラウドセキュリティ評価の実績があるAEVUSが、御社のクラウド環境の現状把握から改善提案まで一貫してサポートします。

よくある質問（FAQ）

Q1. AWS・Azureはどちらが「安全」ですか？

どちらが安全かという比較は意味がありません。どちらのプラットフォームも適切に設定すれば高いセキュリティを実現できますが、設定ミスが発生すればどちらでも重大なリスクになります。本記事で解説した設定ミスはどちらのプラットフォームにも構造的に発生しやすい問題です。

Q2. 設定ミスはどのくらいの頻度でチェックすべきですか？

最低でも四半期に一度の定期チェックが推奨されますが、新機能の追加・組織変更・アカウント追加などのイベントに合わせて都度チェックすることが理想です。CSPMツールを導入すると継続的かつリアルタイムなチェックが可能になります。

Q3. 小規模なスタートアップでも設定ミスは問題になりますか？

規模に関わらず問題になります。むしろスタートアップはセキュリティ専任担当者がいない場合が多く、「動けばOK」の設定が本番環境にそのまま残りやすい傾向があります。また、スタートアップへの攻撃は「大企業の取引先として侵入する踏み台」として使われるケースもあり（サプライチェーン攻撃）、規模にかかわらず注意が必要です。

Q4. IaCツール（Terraform・CloudFormation）を使っていれば安全ですか？

IaCはコードレビュープロセスでセキュリティチェックを組み込めるため、手動設定よりセキュリティを高めやすい面があります。しかしIaCのコード自体に設定ミスが含まれていれば、デプロイのたびにミスが再現されます。checkov・tfsec・cfn-nagなどのIaCセキュリティスキャンツールをCI/CDに組み込むことが重要です。

Q5. クラウドプロバイダー（AWS・Microsoft）との責任分担はどうなっていますか？

AWSもMicrosoftも「責任共有モデル（Shared Responsibility Model）」を採用しています。クラウドプロバイダーはインフラ・物理設備・ハイパーバイザーのセキュリティに責任を持ちますが、クラウド上のデータ・アクセス設定・ネットワーク設定・アプリケーションのセキュリティは利用者の責任です。本記事で解説した設定ミスはすべて「利用者の責任範囲」に含まれます。

Q6. 設定ミスが原因で実際に情報漏洩が起きた場合、どうすればよいですか？

まず影響範囲の特定（どのデータに誰がアクセスできたか）、次に設定の修正（即時の被害拡大防止）、その後に関係当局・個人情報保護委員会への報告義務の確認が必要です。AWSではCloudTrailのログ、AzureではActivity Log・サインインログを使って証跡を調査します。インシデント対応の準備として、事前にSOCサービスの検討もお勧めします。

Q7. AWSとAzureを両方使っている場合、管理はどうすればよいですか？

マルチクラウド環境では、どちらか一方のネイティブツールだけでは全体を把握できません。Microsoft Defender for Cloud（AWS対応あり）や、Wiz・Prisma Cloudのようなサードパーティ製マルチクラウドCSPMツールの導入が効果的です。統一したポリシー基準でマルチクラウド環境全体を管理することが重要です。

まとめ

本記事では、AWS・Azureで頻発するクラウド設定ミスを10項目に絞り込み、影響度・発見方法・修正方法を解説しました。

AWS編（5つのミス）

1. S3バケットのパブリック公開 → パブリックアクセスブロックを有効化
2. IAMロール・ユーザーへの過剰な権限付与 → 最小権限の原則を徹底
3. セキュリティグループの無制限インバウンドルール → 管理ポートを特定IPに制限
4. CloudTrailの無効化・ログの未保全 → 全リージョン対象のトレイルを有効化・ログ保全
5. ハードコードされた認証情報 → Secrets Managerに移行

Azure編（5つのミス）

6. Entra IDのゲストアクセスの過剰な権限 → ゲストアクセスレベルを制限・定期レビュー
7. Azureストレージのパブリックアクセス許可 → アカウントレベルで匿名アクセスを禁止
8. NSGの広範なインバウンドルール → Azure Bastionで管理アクセスを集約
9. Microsoft Defender for Cloudの未有効化 → 重要サービスのDefenderプランを有効化
10. 診断設定の未構成 → Entra IDを含む重要リソースのログをLog Analytics Workspaceに転送

クラウド環境のセキュリティは「移行したから安全」ではなく、継続的な設定管理と定期的な評価が欠かせません。CSPMツールの活用と、専門家によるプラットフォーム診断を組み合わせることで、設定ミスのリスクを大幅に低減できます。

AEVUSのプラットフォーム診断では、クラウド環境の設定を網羅的に評価し、リスクの高い設定ミスを優先度付きで報告します。「自社のクラウド環境が安全かどうか確認したい」という段階のご相談も無料でお受けしています。

クラウドセキュリティの現状診断について、まずは無料で相談してみませんか？

無料相談・お問い合わせ