セキュリティ対策の失敗図鑑｜クラウド設定ミス（公開バケット・過剰権限）を棚卸ししない失敗

結論：クラウドは攻撃されなくても「自社の設定ミスだけ」で情報が公開状態になる

クラウドの情報漏えいと聞くと、高度な攻撃者による侵入を想像しがちである。だが実際には、誰にも攻撃されていないのに、公開設定になったストレージ、過剰に与えられた権限、検証のために作って忘れたテスト環境が、機密情報をインターネットから誰でも見える状態に置き続けるという失敗が起きる。侵入の痕跡がないため検知の仕組みにも引っかからず、発見が遅れやすい。失敗の本質は個々の操作ミスではなく、増え続けるクラウドの設定を定期的に棚卸しする仕組みが存在しないことである。

• クラウドの設定ミスは「攻撃の成功」ではなく「自社の操作」だけで情報を公開状態にする。侵入がないため警報が鳴らず、発見も遅れやすい。
• 公開設定のストレージ・過剰なIAM権限・放置されたテスト環境が三大典型で、いずれも作った時点では妥当だった設定が、時間の経過でリスクに変わる。
• クラウドは現場が自由にリソースを作れるため資産が増殖し、作った人が異動・退職すると全体像を知る人がいなくなる。
• 対策は一度の総点検ではなく、公開範囲・権限・不要リソースの三軸を定期的に棚卸しする仕組み化であり、CSPM等の設定監査で「ずれの検知」を継続する。
• テスト環境・検証環境にも本番同等の統制をかける。「テストだから」が最も漏れやすい入り口になる。

この連載は「セキュリティ対策の失敗図鑑」として、中堅・中小企業がつまずきやすいセキュリティの失敗を一つずつ分解している。第10回となる本稿が扱うのは、クラウドの設定と権限である。外部に公開された機器の脆弱性を放置する失敗は第3回のVPN機器のパッチ先送りで扱ったが、あちらは攻撃者が脆弱性を突いて侵入してくる「入り口」の話であり、本稿は攻撃がなくても自社の設定だけで情報が公開される失敗を扱う点で層が異なる。また、使われないIDが残り続ける構造は第7回の退職者アカウント・共有IDの放置と地続きだが、第7回が「誰がログインできるか」を問うのに対し、本稿は「ログインした人に何ができるか（権限の広さ）」と「そもそも認証なしで見える状態になっていないか（公開範囲）」を問う。

なぜ攻撃されていないのに情報が漏れるのか

「一時的なつもり」の公開設定が恒久化する

クラウドストレージの公開設定は、多くの場合、悪意でも無知でもなく「一時的な必要」から生まれる。取引先にファイルを渡すために一時的に公開した、検証のためにアクセス制限を外した、急ぎの障害対応で制限を緩めた——その場では合理的な判断である。問題は、戻す作業が誰のタスクにもなっていないことだ。公開設定は戻さない限り有効であり続け、担当者の記憶から消えた後も、そのストレージは世界中から到達できる状態で動き続ける。オンプレミスのサーバなら社内ネットワークという物理的な壁が最後の防波堤になったが、クラウドでは設定ひとつがそのまま公開・非公開の境界線になる。

「クラウド事業者が守ってくれる」という責任共有モデルの誤解

クラウドを使えばセキュリティも事業者任せにできる、という誤解も根強い。実際には、クラウドのセキュリティは事業者と利用者で責任を分担する「責任共有モデル」が前提であり、データセンターや基盤の防御は事業者の責任でも、その上で利用者が行う設定——誰に公開するか、誰にどの権限を与えるか、どのデータを置くか——は利用者の責任である。AWS、Microsoft Azure、Google Cloudはいずれも責任共有モデルを公式文書で説明しており、IAM、データ分類、暗号化、ネットワーク公開範囲、ログ監視は利用者側の設計・運用に残る。公開バケットも過剰権限も、この利用者責任の領域で起きる。事業者の基盤がどれだけ堅牢でも、利用者が「全員に公開」と設定すれば、その通りに全員へ公開される。それはクラウドの欠陥ではなく仕様である。

発注・監査の場では、責任共有モデルを抽象論で終わらせず、少なくとも次の5項目に落とす必要がある。

この5項目を要件定義や運用設計に入れないまま「クラウドだから安全」とだけ判断すると、事故が起きたときに「誰の責任で、どの設定を、いつ確認するはずだったのか」を説明できない。

「作った人しか全体を知らない」増殖構造

最も構造的な問題は、クラウド資産の増え方にある。オンプレミスの時代は、サーバを増やすには調達稟議と設置作業という関所があり、情報システム部門が全体を把握しやすかった。クラウドではアカウントさえあれば、現場の担当者が数分でストレージや仮想サーバを作れる。事業のスピードには貢献するが、台帳に載らないリソースが各部門・各プロジェクトで増殖していく。そして作った本人が異動・退職した瞬間、その環境の目的も設定も誰にも分からなくなる。「消してよいか判断できないから残す」が積み重なり、誰も全体を知らないクラウドが出来上がる。設定ミスの点検以前に、点検すべき対象の一覧が存在しないのである。

設定ミスの典型パターンと点検観点

クラウドの設定ミスには定番のパターンがある。自社の環境を見る際は、次の表の観点で確認したい。

この表に共通するのは、どれも「作った時点では誰かにとって合理的だった」という点である。だからこそ、個人の注意力に頼る対策は機能しない。設定は必ずずれていくという前提に立ち、ずれを定期的に見つけて戻す仕組みの側で受け止める必要がある。

棚卸しを「仕組み」にする——一度の総点検では元に戻る

公開範囲・権限・不要リソースの三軸で定期的に回す

棚卸しと聞くと一度の大掃除を想像しがちだが、クラウドの設定は日々の運用で変わり続けるため、一度きれいにしても数か月で元に戻る。必要なのは、(1)公開範囲（外部から見える設定になっていないか）、(2)権限（誰に何ができる権限が与えられているか）、(3)不要リソース（使われていない環境・キー・アカウントが残っていないか）の三軸を、決まった頻度で確認する定例業務にすることである。手動で行うなら四半期に一度を目安に、責任者と手順を決めて回したい。外部公開と管理者権限は月1回、テスト環境は作成から30日または60日、アクセスキーは90日を基準に見るなど、項目ごとに周期を分けると実務に落ちやすい。退職・異動・プロジェクト終了といったイベントの際に権限とリソースを見直すルールを併せて置くと、第7回で扱ったアカウント放置と同じ仕組みで権限の放置も防げる。

CSPMで「ずれの検知」を自動化する

リソースの数が増え、変更が日常的に起きる環境では、手動の棚卸しだけでは追いつかない。そこで使われるのがCSPM（Cloud Security Posture Management）である。CSPMはクラウドの設定を継続的に収集し、「ストレージが公開設定になった」「管理者権限が新たに付与された」「全開放のルールが作られた」といった、あるべき状態からのずれを検知して通知する仕組みだ。人の注意力で公開設定の戻し忘れを防ぐのではなく、戻し忘れが起きた瞬間に機械が見つける構造へ変える。CIS Controls v8でも、企業資産の棚卸し、アクセス制御、監査ログ管理は基本対策として位置づけられており、クラウドでも同じ発想を設定監査に落とす必要がある。何をあるべき状態とするかの基準づくりから運用までは、クラウド設定診断（CSPM）で支援している。

外から自社がどう見えているかを突き合わせる

CSPMがクラウドの内側から設定を点検する仕組みだとすれば、外側からの視点も必要である。自社のドメインやIPアドレスに紐づく資産が、インターネットからどう見えているか——把握していないテスト環境や旧サイトが公開されたまま残っていないか——を外部視点で発見する取り組みがASM（Attack Surface Management）であり、考え方と進め方はASM導入ガイドで整理している。内側の設定監査と外側の資産把握を突き合わせると、台帳に載っていないリソースが浮かび上がる。両方を含むクラウド全体の防御設計はクラウドセキュリティ支援の領域である。

テスト環境にも本番同等の統制をかける

最後に、最も軽視されやすいのがテスト環境・検証環境である。「テストだから」とアクセス制限を緩め、検証のためにと本番データをコピーする——この組み合わせが、統制の弱い環境に本物の情報が置かれる最悪の形をつくる。原則は単純で、本番データを置くなら本番と同等の統制をかける、それができないならテストデータを使う、のどちらかである。加えて、環境の作成時に台帳へ登録し、利用期限を決め、期限が来たら延長か削除かを判断するというライフサイクル管理を入れることで、「誰のものか分からない環境」の発生自体を抑えられる。万一、公開状態のストレージが見つかった場合は、攻撃の有無にかかわらず影響範囲の特定と報告要否の判断が必要になる。その判断の進め方は個人情報漏えい時の72時間判断フローを参照してほしい。

点検前に確認すべきこと（チェックリスト）

• 自社で利用しているクラウドサービス（IaaS・SaaS）とアカウントを一覧化できているか。
• ストレージの公開設定を全件確認し、公開中のものは業務上の根拠を説明できるか。
• 管理者相当の権限を持つ人とアクセスキーを把握し、最小権限へ絞る運用があるか。
• 退職・異動・プロジェクト終了時に、クラウドの権限とアクセスキーを見直す手順があるか。
• テスト・検証環境の作成・削除のルールと台帳があり、本番データの持ち込みを統制しているか。
• 設定の変更を検知・通知する仕組み（CSPM等）があるか。
• 外部から自社のクラウド資産がどう見えるかを確認したことがあるか。
• 公開状態が見つかったときの、影響範囲の特定と報告判断の手順を決めているか。

このチェックリストで複数の項目が「いいえ」になるなら、個別の設定を直す前に、まず全体像の把握から始めるべき段階である。誰も全体を知らない状態のまま部分的に直しても、把握していない場所から漏れる構造は変わらない。

関連記事

• 特集トップ：セキュリティ対策の失敗図鑑
• 第3回：VPN機器のパッチ先送り——「あとで」が侵入口になる失敗
• 第7回：退職者アカウント・共有IDの放置——辞めた人が今もログインできる失敗
• ASM（Attack Surface Management）導入ガイド
• クラウド設定診断（CSPM）
• クラウドセキュリティ支援

参考一次ソース

• AWS Shared Responsibility Model
• Microsoft Azure shared responsibility in the cloud
• Google Cloud shared fate model
• CIS Controls v8
• NIST SP 800-53 Rev.5: Security and Privacy Controls for Information Systems and Organizations

よくある質問

Q1. 攻撃を受けていなければ、設定ミスがあっても実害はないと考えてよいか。

よくない。公開設定になっていた期間は、誰でもそのデータに到達できた期間である。攻撃と違って侵入の痕跡が残りにくいため、「誰にも見られていない」ことを後から証明するのは難しい。公開状態が見つかった時点で、攻撃の有無にかかわらず、何がどの期間見える状態だったかという影響範囲の特定と、関係者への報告要否の判断が必要になる。

Q2. クラウド事業者がセキュリティを担保してくれるのではないか。

基盤の防御は事業者の責任だが、その上の設定は利用者の責任である。これが責任共有モデルの考え方で、誰に公開するか、誰にどの権限を与えるか、どのデータを置くかは利用者が決め、利用者が守る領域になる。公開バケットや過剰権限による漏えいは、ほぼすべてこの利用者責任の領域で起きる。クラウドを使うこと自体は安全性を高め得るが、設定の管理責任までは移転できない。

Q3. CSPMとASMはどう違うのか。

CSPMはクラウドの内側から、設定情報を継続的に収集してあるべき状態とのずれを検知する仕組みである。ASMは外側から、自社に紐づくIT資産がインターネット上でどう見えているかを把握する取り組みである。CSPMは把握しているクラウド環境の設定を深く点検でき、ASMは把握していなかった資産の発見に強い。内と外の両面で突き合わせることで、台帳にない環境の見落としを減らせる。

Q4. 棚卸しはどれくらいの頻度で行えばよいか。

環境の変更頻度による。リソースの追加・変更が頻繁な環境では、手動の定期点検だけでは点検の合間に公開設定が生まれて残るため、CSPM等による常時検知と、四半期程度の定期レビューを組み合わせるのが現実的である。変更が少ない環境でも、退職・異動・プロジェクト終了のタイミングでは必ず権限とリソースを見直したい。重要なのは頻度の数字より、棚卸しが誰かの定例業務として割り当てられていることである。

クラウドの設定ミスは、攻撃を待たずに自社だけで完結してしまう失敗であり、裏を返せば自社の取り組みだけで確実に減らせる失敗でもある。公開範囲・権限・不要リソースの棚卸しをどこから始めるか、CSPMによる設定監査をどう仕組みにするかでお困りの場合は、無料相談から自社のクラウド利用状況の整理を一緒に始めていただきたい。