クラウド設定・鍵管理系の攻撃と対策

攻撃視点の分類 → セキュリティ脅威マップ ／ レイヤーC「クラウドとアプリ実装」

クラウド（AWS／Google／Microsoft などのインターネット上のサービス置き場）の 公開設定ミス や、鍵・パスワードの置き忘れ で、本来は社内だけのはずの中身が 誰でも見える状態 になってしまう——これがこのジャンルの中心です。ここで起きる事故は「攻撃された」というより、「鍵のかけ忘れ」「扉の開けっぱなし」 がほとんど。悪い人が高度な技術で押し入るのではなく、開いている扉をたまたま見つけて入ってくる イメージです。だからこそ、気づいて閉めれば防げる 事故でもあります。

このページの読み方 — 🟢 は全員が知っておく基礎、🔧 はエンジニア・運用担当者向けの実装/設定。まず🟢を全員で、🔧は技術担当が押さえる。

1. このジャンルの攻撃とは

クラウドでは、ファイルもデータベースも「設定ひとつ」で 公開／非公開 が切り替わります。その設定を間違えたり、サービスに入るための 鍵（APIキー＝サービスに入るためのパスワードのようなもの） をうっかり外に置いたりすると、

  • 置き場（ストレージ）の中身が全世界から読める
  • 拾われた鍵で、本物の利用者になりすまして入られる
  • 「誰が何をできるか」の権限（IAM）が広すぎて、入られたとき被害が一気に広がる

ことが起きます。攻撃の本体は派手な侵入ではなく、「公開のまま」「鍵を貼ったまま」「権限が強すぎるまま」放置 という、しまい方のミスです。しかもクラウドは世界中からアクセスでき、公開した瞬間に自動で探し回るプログラム（ボット）に見つかる ため、ミスが秒〜分単位で悪用されます。

2. 主な手口

手口 しくみ（何が起きているか）
ストレージの公開設定ミス S3／GCS バケット（クラウドのファイル置き場）を「全世界に公開」のままにしてしまい、中身が誰でも読める
過剰なIAM権限・不要な管理者 「誰が何をできるか」の権限を広く渡しすぎ。使っていない管理者アカウントも放置され、入られると全部触られる
認証情報／鍵の漏洩 GitHub などの公開リポジトリ（プログラムの共有置き場）に、.env ファイルやAPIキーをうっかりコミット（登録）してしまう
ソースにハードコードした鍵 プログラムの中に鍵を直接書き込む。コードが共有・流出すると鍵も一緒に漏れる
公開スナップショット／DB バックアップ（スナップショット）やデータベースを公開設定のまま放置し、丸ごと読まれる
ルート／管理者のMFA未設定 いちばん強い管理者アカウントに多要素認証（パスワード＋もう一つの確認）がなく、パスワードだけで乗っ取られる
設定ドリフト 運用しているうちに、いつの間にか設定が緩む。最初は安全でも、後から誰かが公開に変えて気づかれない

3. 実例・典型シナリオ

  • 公開バケットから個人情報流出: 社内資料を入れたファイル置き場が「全世界に公開」のまま放置され、顧客の名前・住所・問い合わせ内容が誰でもダウンロードできる状態になっていた。
  • GitHubにAWSキーをコミット→数分で高額請求: 開発者が鍵を含むファイルを公開リポジトリに上げてしまい、数分でボットに拾われ、勝手に高性能サーバーを大量起動されて、翌月に数百万円の請求が来た。
  • 退職者の鍵が有効なまま放置: 辞めた人の鍵やアカウントが止められておらず、退職後もクラウドに入れる状態が続いていた。「合鍵を返していない」のと同じ。
  • 設定ドリフトで“いつの間にか公開”: 当初は非公開だった置き場を、別の担当者が一時的に公開へ変更 → 戻し忘れ → 数か月間、気づかれず公開され続けた。

4. 対策

🟢 基礎（全員がやること）

  1. パスワード・APIキー・鍵を「貼らない」 — メール・チャット・付箋・公開メモ・公開リポジトリに、鍵やパスワードを貼り付けない。鍵は「家の合鍵」と同じで、貼った時点で誰でもコピーできる。
  2. クラウドの管理者アカウントにMFA — 管理画面に入るアカウントには、必ず多要素認証（パスワード＋スマホ確認など）をかける。いちばん強いアカウントほど守りを厚く。
  3. ファイル共有リンクの公開範囲を必ず確認 — 「リンクを知っている全員」「全世界に公開」になっていないか、共有する前に毎回チェックする。社内向けは社内だけに。
  4. 退職・異動時に共有を見直す — 人が入れ替わったら、その人の鍵・アカウント・共有設定を止める／引き継ぐ。「辞めた人がまだ入れる」状態を残さない。

🔧 応用（エンジニア・運用）

  1. 最小権限IAM・ロールベース — 「誰が何をできるか」は、必要な人に必要な分だけ。個人に直接強い権限を付けず、役割（ロール）単位で管理し、未使用の管理者は削除。
  2. Secrets管理と鍵ローテーション — 鍵は専用の金庫（Vault／Secrets Manager）に保管し、コードや設定ファイルに直書きしない。定期的に鍵を作り替える（ローテーション）。
  3. 公開設定の自動検知（CSPM） — クラウドの設定を自動でスキャンし、「公開になっている置き場」「MFA未設定」などを継続的に検出・通知する（CSPM＝クラウド設定の健康診断）。
  4. シークレットスキャン（pre-commit/CI） — コミット前やCI（自動チェックの仕組み）で、鍵やパスワードが混入していないか自動検査し、流出を未然に止める。
  5. ルートアカウント保護とMFA必須 — 最上位（ルート）アカウントは日常使いせず、強力なMFAで保護。管理者全員にMFAを必須化する。
  6. 監査ログと異常検知 — 「誰が・いつ・何をしたか」の記録（CloudTrail 等）を残し、ふだんと違うアクセスや大量ダウンロードを検知できるようにする。
  7. IaCのポリシーチェック — 設定をコード化（IaC＝Infrastructure as Code）し、デプロイ前に「公開バケットを禁止」などのルール（ポリシー）で自動チェックして、設定ドリフトを防ぐ。

5. 解説動画（実在確認済み）

クラウド専用のIPA公式動画は確証のあるものに絞れないため、ここでは 特定の動画は埋め込みません。代わりに、実在する公式ページから関連動画を探せます。クラウドの土台になる「不正ログイン対策」「パスワード／認証」の動画が参考になります。

6. チェックリスト

🟢 全員

  • パスワード・APIキー・鍵をメール／チャット／付箋／公開リポジトリに貼っていない
  • クラウドの管理者アカウントにMFAを有効にした
  • ファイルを共有する前に、公開範囲（社内だけ／リンク共有／全世界）を確認している
  • 退職・異動が出たら、その人の鍵・アカウント・共有を止める手順を知っている

🔧 エンジニア・運用

  • IAMを最小権限・ロールベースで管理し、未使用の管理者を棚卸し・削除している
  • 鍵はSecrets管理（Vault／Secrets Manager）に集約し、定期ローテーションしている
  • CSPMで公開設定・MFA未設定を継続スキャンし、通知が届くようにしている
  • pre-commit/CI でシークレットスキャンをかけ、鍵の混入を止めている
  • ルートアカウント保護・全管理者MFA必須・監査ログ（CloudTrail等）と異常検知を整備している
  • 設定をIaC化し、デプロイ前にポリシーチェックして設定ドリフトを防いでいる

7. 関連ジャンル・出典

関連ジャンル

出典（一次情報）

  • IPA「映像で知る情報セキュリティ」 — https://www.ipa.go.jp/security/videos/index.html ／「情報セキュリティ10大脅威」 — https://www.ipa.go.jp/security/10threats/
  • 各クラウドのベストプラクティス — AWS（Well-Architected／IAMベストプラクティス）、Google Cloud（セキュリティのベストプラクティス）、Microsoft（Azure セキュリティ ベンチマーク）
  • CIS（Center for Internet Security）Benchmarks — クラウド設定の基準
  • NIST — Cybersecurity Framework（CSF）／クラウドセキュリティのガイドライン

合わせて読む