【比較表あり】AWS・Azure・GCPで起きがちな設定ミスTOP5と対策を徹底解説

最近は「AWS・Azure・GCPのどれかを使っている」ではなく、「全部使っている」というマルチクラウド環境が当たり前になってきました。環境が増えるほど設定ミスが起きやすく、かつ見落としやすくなります。

今回は3つのクラウドそれぞれで「やってしまいがちな設定ミス」と「その対策」を比較しながら解説します。

なぜクラウドの設定ミスが増えているのか

まず背景として、クラウドの設定ミスが事故の原因として増え続けている理由を整理します。

スピードを優先した結果のセキュリティ後回し
開発チームが素早くリソースを立ち上げ、セキュリティレビューが追いつかないまま本番化するケースが多いです。

クラウドごとの仕様の違いを理解していない
同じ「ストレージの公開設定」でも、AWS・Azure・GCPで設定方法・デフォルト値が異なります。AWSの感覚でGCPを触ると「あれ、こんな設定あったっけ？」という見落としが起きます。

マルチクラウドで管理が分散している
それぞれのクラウドポータルを別々に確認する運用では、どこかで設定の抜け漏れが生まれます。

AWS・Azure・GCP 設定ミスTOP5 比較

① ストレージの意図しない公開

AWS（S3）
バケットのパブリックアクセスブロック設定が無効になっているケース。デフォルト設定はブロック有効ですが、古い環境や設定変更時に誤って無効にされることがあります。CloudTrailで変更履歴が確認できます。

Azure（Blob Storage）
匿名アクセスをコンテナレベルで許可してしまうミス。「パブリックアクセスレベル」を「コンテナ（完全パブリック）」にするとURLを知っている誰でもファイルを閲覧できます。

GCP（Cloud Storage）
バケットへの allUsers への読み取り権限付与が典型的なミス。IAMポリシーのバインディングを見落としやすい。

対策共通ポイント：
CSPM（Cloud Security Posture Management）ツールで定期的にストレージの公開状態をスキャンする仕組みを整備することが必須です。

② IAM権限の過剰付与

AWS
AdministratorAccess ポリシーを開発者や自動化スクリプトに直接付与してしまうケース。「とりあえず全部の権限を渡しておく」発想でやってしまいがちです。

Azure
サービスプリンシパルや管理IDに「Owner」ロールを割り当てるケース。サブスクリプション全体に影響が出ます。また、アクセスレビューをしないまま権限が積み上がっていく「権限の肥大化」も深刻な問題です。

GCP
サービスアカウントへの roles/editor や roles/owner の直接付与。さらに、サービスアカウントキーを発行してファイルとして管理しているケースは、キーが漏洩した際のリスクが非常に高いです。

対策共通ポイント：
最小権限の原則（Principle of Least Privilege）の徹底と、定期的なアクセスレビュー。AWSはIAM Access Analyzer、AzureはEntra IDのアクセスレビュー機能、GCPはIAM推奨機能を活用します。

③ 監査ログの無効化・未保全

AWS
CloudTrailを有効化していない、または特定リージョンのみ有効でマルチリージョン設定になっていないケース。ログをS3に保存しているものの、そのS3バケット自体がパブリックになっているというケースも実際にありました。

Azure
Azure Monitor・Activity Logを有効化しているが、Log Analytics Workspaceへの転送設定をしておらず、90日で消えてしまうケース。診断設定が各リソースごとに必要なことを知らないまま放置することも多いです。

GCP
Cloud Audit Logsで「管理アクティビティ監査ログ」はデフォルト有効ですが、「データアクセス監査ログ」は明示的に有効化しないと取得されません。この差を認識していないケースがあります。

対策共通ポイント：
各クラウドのログを一元管理するSIEMへの転送設定と、保持期間のポリシー化。インシデント調査に最低90日分は必要です。

④ ネットワークの過剰公開

AWS
セキュリティグループで 0.0.0.0/0（全IPアドレス）からのSSH（22番）・RDP（3389番）アクセスを許可しているケース。「テスト用に開けたまま本番移行した」というパターンが非常に多いです。

Azure
NSG（ネットワークセキュリティグループ）でインバウンドの *（全ポート全IP許可）ルールを作成しているケース。また、Azure Bastion未使用で管理用ポートを直接インターネットに公開しているケースも。

GCP
ファイアウォールルールで 0.0.0.0/0 からの全ポート許可。GCPはVPCファイアウォールが「allow」優先のため、意図せず広い範囲を許可している設定が残りやすいです。

対策共通ポイント：
管理用ポートへのアクセスはVPN・Bastion経由に限定し、インターネット直接公開は原則禁止とします。定期的なネットワーク構成レビューが重要です。

⑤ シークレット・認証情報の平文管理

AWS
Lambda関数やEC2のユーザーデータにアクセスキーをハードコードするケース。GitHubに誤ってPushされた事例も後を絶ちません。

Azure
App Serviceの環境変数に接続文字列（パスワード含む）をそのまま入力するケース。Azure Key Vaultの参照設定で代替できるにもかかわらず、コスト・手間を避けて省略されがちです。

GCP
サービスアカウントキー（JSONファイル）をアプリケーションコードと同じリポジトリに置くケース。このJSONファイルが流出すると、対応するサービスアカウントの権限を持って何でもできる状態になります。

対策共通ポイント：
シークレット管理は必ずシークレットマネージャー（AWS Secrets Manager・Azure Key Vault・GCP Secret Manager）を使います。GitHub Advanced SecurityやTruffleHogでのシークレットスキャンも導入することをお勧めします。

3社まとめ比較表

マルチクラウド環境の設定ミスをどう継続的に防ぐか

3社を並べてみると、「やってしまうミスのパターン」は実は共通していることがわかります。大事なのは、設定ミスを個人の注意力に頼らない仕組みを作ることです。

推奨するアプローチは以下の3点です。

1. CSPMツールの導入（Orca SecurityやMicrosoft Defender for Cloudなど）で設定不備を継続的にスキャン
2. Infrastructure as Code（Terraform等）でコードレビューを必須化し、設定変更を人の目で確認できる体制に
3. 変更検知アラートをSIEMに連携し、意図しない設定変更が発生したら即時検知できるようにする

弊社Colorkrew SecurityではAWS・Azure・GCP全てのクラウド環境に対応したセキュリティ監視・SOCサービスを提供しています。「マルチクラウドになって設定の把握が追いつかなくなってきた」という方は、ぜひ一度ご相談ください。