クラウドの設定ミスを仕組みで防ぐ。CSPMによる継続監視とIaCスキャン、ポリシーアズコードで公開バケットや全開放のセキュリティグループを作らせない設計

クラウドの事故報告を読み比べると、侵入の入口が脆弱性の悪用ではなく設定だったという例が目立ちます。誰でも読めるようになっていたストレージ、管理用のポートを世界中へ開けたままのセキュリティグループ、必要以上の権限を持ったままのアクセスキー。どれもクラウド事業者の基盤の欠陥ではなく、利用者が決めた設定の結果です。

利用者と事業者の責任の境目は、次の記事で整理しています。本記事はその続きとして、利用者側の責任範囲で起きる設定ミスを、担当者の注意力ではなく仕組みで減らす設計を扱います。

あわせて読みたい

クラウドの責任共有モデルとガバナンス。IaaS/PaaS/SaaSで変わる責任範囲と設定ミスの所在

対象は、AWS、Azure、Google Cloudのいずれかでアカウントやサブスクリプションを運用している基盤の担当者と、情報セキュリティ担当です。設定ミスを「作らせない」「見つける」「直す」の3層に分け、それぞれに置く仕組みと、最小構成から始める導入の順序を示します。

設定ミスの5類型と3層の対策#

最初に、防ぎたい設定ミスと、それぞれに効く仕組みを並べます。本記事で扱うのは次の5類型です。

3層はどれか1つで足りるものではありません。予防の層を抜けた変更を検知の層が拾い、検知した結果を是正の層が期限つきで閉じる、という流れで初めて設定ミスの残存期間が短くなります。

設定ミスが生まれる3つの経路#

仕組みを置く場所を決めるには、設定ミスがどこから入り込むかを知っておく必要があります。現場で多いのは次の3つの経路です。

1つ目は、コンソール操作の属人化です。管理画面から手で作ったリソースは、誰が何の意図でその値にしたのかが記録に残りにくく、レビューも通りません。作った本人が異動すると、公開設定やポートの開放が意図したものかどうかを誰も判断できなくなります。

2つ目は、環境のコピーです。検証環境の設定を本番へ複製する、別のプロジェクトのテンプレートを流用するといった作業で、検証の都合で緩めた設定がそのまま運ばれます。IaCを使っていても、緩い設定を含むモジュールを再利用すれば同じ問題が複数の環境へ広がります。

3つ目は、緊急対応の戻し忘れです。障害の切り分けのために一時的にポートを開ける、調査のために広い権限を付ける。対応が終わった時点で戻す手順が決まっていないと、一時的な変更が恒久的な設定になります。

3つとも、個人の注意だけでは防ぎきれません。コンソール操作にはデプロイ後の監視、環境のコピーにはデプロイ前のスキャン、戻し忘れには期限つきの例外管理を当てる、という対応関係で考えると、仕組みの置き場所が決まります。

デプロイ前に止めるIaCスキャン#

IaC(Infrastructure as Code)でリソースを定義している場合、設定ミスはコードの段階で見つけられます。修正のコストが最も小さいのはこの段階です。

OWASPのInfrastructure as Code Security Cheat Sheetは、IaCの安全対策を開発と配布、デプロイ、実行時の段階に分けて整理しています。開発段階では、IDEのプラグインによる早期の検出、脅威モデリング、シークレットの管理、バージョン管理、最小権限、静的解析、依存関係の確認、コンテナイメージのスキャン、CI/CDへの組み込み、成果物への署名が挙がっています。デプロイ段階ではインベントリの管理と動的解析、実行時には変更ではなく作り直しで更新するイミュータブルな運用、ログ、監視、実行時の脅威検知が並びます。

OWASP Infrastructure as Code Security Cheat Sheetは、IDEプラグインの例としてTFLintやCheckov、シークレット検出の例としてtruffleHogやgit-secrets、GitGuardian、コンテナイメージのスキャンの例としてTrivyやClairなどを挙げています。デプロイ段階では、リソースへのタグ付けと記録によって、管理から外れたリソースが残るのを防ぐよう勧めています。

チェックシートの観点を、本記事の5類型に当てはめると、CIで見る項目は次のようになります。

導入初期は、検出を表示するだけでマージは止めない設定から始めます。既存のコードに大量の指摘が出ると、担当者がスキャン自体を無効化する方向へ流れるためです。新しく追加するコードだけをブロックの対象にし、既存の指摘は是正の計画に載せて件数を減らしていきます。

シークレットの扱いは設定ミスと同じくらい事故につながりやすい部分です。保管と配布の方法は次の記事で扱っています。

あわせて読みたい

シークレット管理の実務。APIキー・認証情報をハードコードせず、Vaultやマネージドサービスで守りローテーションする

CIへのセキュリティ検査の組み込み全般は、次の記事で整理しています。

あわせて読みたい

DevSecOps入門。CI/CDにセキュリティを組み込むSAST・DAST・SCA・シークレットスキャン

デプロイ後に見つけるCSPM#

CSPM(Cloud Security Posture Management)は、稼働中のクラウド環境の設定を継続的に評価し、基準から外れた状態を検出する仕組みです。IaCを使っていない環境や、手作業の変更が混じる環境でも効くため、3層の中で最初に整えると効果が見えやすい層です。

判定の基準には、自社で項目を一から書き起こすのではなく、CISベンチマークのような公開された基準を採用することを勧めます。理由は3つあります。1つ目は、多くの組織が同じ基準で評価しているため、監査や取引先への説明で共通の言葉が使えることです。2つ目は、版が管理され、各項目に評価手順と是正手順が付いていることです。3つ目は、主要なクラウドの標準機能が、CISベンチマークに沿った評価をすでに備えていることです。自社固有の要件は、この基準の上に追加する形にします。

AWSのドキュメントによると、Security Hub CSPMはCIS AWS Foundations Benchmark v5.0.0のLevel 1とLevel 2でCIS Security Software Certificationを受けており、複数の版の標準を同時に有効化できます。

Azureでは、Microsoft LearnがFoundational CSPMについて、2026年10月27日から新しいAzureサブスクリプションでは既定で有効にならず、利用者が有効化を選ぶ方式に変わると案内しています。無料での提供は続き、すでに有効なサブスクリプションはそのまま維持されます。これから作るサブスクリプションは、作成の手順に有効化を組み込んでおく必要があります。

Google Cloudでは、Security Health Analyticsが公開されたバケットを示すPUBLIC_BUCKET_ACLや、広く開いたファイアウォール規則を示すOPEN_FIREWALLといった検出項目を持ち、CISがその項目とCIS Google Cloud Foundations Benchmarkの対応づけを認証しています。一方で、Security Command CenterのStandard階層を新しく有効化した組織ではSecurity Health Analyticsは使えず、Compliance Managerで誤設定を評価するよう案内されています。自組織でどちらが動いているかを、管理画面で確かめてから運用を設計します。

検知の結果は、アカウントごとに個別に見るのではなく、組織の管理用アカウントやテナントへ集約します。アカウントが増えるたびに見る場所が増える構成では、新しいアカウントが監視の対象から漏れます。組織単位で新規のアカウントやサブスクリプションに自動で監視を適用する設定を、最初に確認しておきます。

ポリシーアズコードで例外を明文化する#

予防の層のもう1つの柱が、組織単位のガードレールです。個々のリソースのコードを検査するのではなく、組織全体で「この設定は作れない」と決めて、クラウドのAPIの段階で拒否します。

代表的な仕組みは、AWS OrganizationsのサービスコントロールポリシーとS3のアカウント単位のブロックパブリックアクセス、Azure Policyの拒否の効果、Google Cloudの組織ポリシーです。Google Cloudには、Cloud Storageの公開アクセスを防ぐstorage.publicAccessPreventionという制約があります。こうしたガードレールもコードとして管理し、変更はプルリクエストを通して行います。汎用のポリシーエンジンであるOpen Policy Agent(OPA)を使って、IaCの計画結果に独自の規則を当てる構成もあります。

ガードレールを置くと、正当な理由で例外が必要になる場面が必ず出ます。静的サイトの配信用に公開するバケット、取引先との接続のために特定の送信元へ開けるポートなどです。ここで例外を口頭やチャットで承認すると、理由と期限が記録に残らず、戻し忘れと同じ経路で穴が残ります。例外もコードとして書き、次の項目を必須にします。

• 対象のリソースの識別子と、除外する規則の名前
• 例外が必要な業務上の理由
• 責任者の名前または所属
• 有効期限。変更のない期間も定期実行の検査で期限切れを検出し、CIを失敗させて責任者へ通知する
• 承認者。プルリクエストのレビューで、例外のファイルだけはセキュリティ担当の承認を必須にする

期限つきの例外は、緊急対応の戻し忘れへの対策にもなります。障害対応で一時的にポートを開ける場合も、例外のファイルに期限を書いてから開ける運用にすると、期限の到来が戻す作業の起点になります。

過剰なIAMの問題は、ガードレールだけでは解決しません。権限の設計の考え方は、次の記事にまとめています。

あわせて読みたい

最小権限の原則（Least Privilege）。なぜ権限を絞ることが最強の防御の一つなのか

NIST SP 800-210は、クラウドシステムのアクセス制御の考え方をIaaS、PaaS、SaaSのサービスモデルごとに整理した文書です。ガードレールで何を拒否するかを決める際に、自組織の方針を外部の枠組みと照らし合わせる材料になります。

最小構成から始める導入順序#

3層をまとめて整えようとすると、検出の量と調整の手間で止まります。リスクの大きい順に、次の順序で進めます。

ログの集約と保管の設計は、次の記事で扱っています。

あわせて読みたい

ログ管理の基本。何を・どこまで・どれだけ残すか

検知から是正までの運用#

CSPMは、検出結果を誰かが閉じるまでが仕事です。検出が溜まり続ける状態は、監視していないのと変わりません。運用を始める前に次を決めておきます。

自動是正は便利ですが、意図した公開を止めて業務に影響を出すことがあります。例外の記録が整ってから、対象を絞って有効にします。

公開ストレージが見つかった場合は、閉じて終わりにせず、公開されていた期間と、その間の外部からの読み取りの痕跡を調べます。読み取りを記録するログが取れていなければ調べようがないため、ログの有効化を導入の早い段階に置いています。ただし、S3のサーバーアクセスログのようにベストエフォートで配信されるログもあり、記録が見つからないことを閲覧がなかった証拠として扱うことはできません。個人データが含まれていた場合は、漏えいのおそれとして社内の報告の手順に乗せ、法務や個人情報保護の担当者とともに、個人情報保護委員会への報告と本人への通知が必要な事態に当たるかを速やかに確認します。

要求の出どころを確認する#

3層の設計は、社内の判断だけで決めるより、外部の要求に紐づけて説明したほうが予算と人手を確保しやすくなります。参照先を整理しておきます。

AWS Well-Architected FrameworkのSecurity Pillarは、設計原則としてセキュリティのベストプラクティスの自動化や追跡可能性の維持を挙げています。Azure Well-Architected Frameworkのセキュリティの柱と、Google Cloudのセキュリティのベストプラクティスのページも、それぞれのクラウドでの推奨事項をまとめています。IaCとCSPMの導入を、クラウド事業者自身の推奨に沿った取り組みとして説明できます。

国内では、ISMAP(政府情報システムのためのセキュリティ評価制度)が、政府機関が調達するクラウドサービスのセキュリティを評価し、登録する制度として運用されています。ISMAPはクラウドサービスの提供者側を評価する制度ですが、政府機関や自治体を顧客に持つ事業者では、利用者としての設定管理も取引先から確認される場面があります。

米国では、CISAのSCuBA(Secure Cloud Business Applications)プロジェクトが、Microsoft 365とGoogle Workspaceの安全な構成の基準(Secure Configuration Baselines)と、それに沿っているかを確認する無償のツールとしてScubaGearとScubaGogglesを公開しています。SCuBAのページは、連邦機関向けの拘束的運用指令であるBOD 25-01とも関連づけられています。IaaSではなくSaaSの設定が対象ですが、基準を決めてツールで継続的に確認するという考え方は、本記事の3層と同じです。

コンテナとKubernetesへの広げ方#

クラウドの設定を3層で管理できるようになったら、同じ考え方をコンテナとKubernetesのマニフェストへ広げます。OWASPのチェックシートもコンテナイメージのスキャンをIaCの安全対策の一部に含めています。特権コンテナの禁止やネットワークポリシーの既定の拒否など、Kubernetes固有の項目は次の記事で整理しています。

あわせて読みたい

Kubernetesクラスタのセキュリティ設定の基礎

あわせて読みたい

コンテナ(Docker)セキュリティの基礎と実務で効く守り方

まとめ#

クラウドの設定ミスは、担当者の注意力に頼るほど再発します。作らせない層にIaCスキャンと組織単位のガードレール、見つける層にCISベンチマークを基準にしたCSPM、直す層に期限と責任者を持つ是正と例外の管理を置くと、設定ミスが残る期間を短くできます。

最初の一歩は、全アカウントの公開ストレージと全開放のセキュリティグループの棚卸しです。ここで見つかった意図しない公開を閉じ、意図した公開を例外として記録するだけでも、次に置くガードレールとCSPMの土台になります。記事の内容は執筆時点(2026年9月23日)に確認した各クラウドの公式ドキュメントとガイドラインに基づきます。機能名や提供の条件は更新されるため、設計の際は各クラウドの最新のドキュメントを確認してください。