クラウド環境の設定不備による
大規模漏えい〈午後II相当〉
各チームが独自にクラウドサービスを契約する「シャドーIT」状態の中で、検証作業後の公開設定の戻し忘れと、初期設定のまま公開されたデータベースが重なり、約120万人分の健康関連データが漏えいしたケースです。
この問題で問われている力
①各部署が独自にクラウドを契約・運用する「シャドーIT」が生むガバナンスの空白②検証作業後の「設定を元に戻す」という、見落とされがちな後始末の重要性③心拍数等の「要配慮個人情報」が含まれる場合の対応の重さ④海外ユーザーが含まれる場合の法令対応の広がり、という4点が軸になります。
📋 設問構成
次の記述を読んで、設問1〜5に答えよ。
〔システム概要〕
V社は、健康・フィットネス管理アプリを提供する従業員数150名の企業である。アプリは、利用者の活動量・心拍数等のセンサーデータや、メールアドレス・生年月日等の登録情報をクラウド上に保存している。V社では、開発チームごとに必要なクラウドサービスを個別に契約・運用しており、情報システム部門がすべてのクラウド利用状況を一元的に把握・管理する体制は整っていなかった。
分析チームは、機能改善のための分析作業用に、利用者データをオブジェクトストレージ（ST1）にコピーして利用していた。一方、別の開発チームが運用するデータベース（DOC1）は、利用者の行動履歴データを保存する目的で構築されたが、初期設定のまま運用が開始されていた。
セキュリティ部門は存在するが、各クラウド環境の設定状況を継続的に監視する専用のツール（CSPM：Cloud Security Posture Management）は導入されておらず、四半期に1度の手動チェックに依存していた。
〔インシデントの発生〕
X年、インターネット上に公開されているデータベースを定期的にスキャンしている海外の脅威インテリジェンス企業から、「DOC1と思われるデータベースが、認証なしでインターネットから直接アクセス可能な状態になっている」との連絡が、レポート公開に先立ってV社に届いた。情報システム部門の担当者Hが確認したところ、表1に示す経緯が判明した。
| 時期 | 出来事 |
|---|---|
| 5か月前 | 分析チームが、機能改善のための検証作業のため、利用者データをST1にコピーし、検証用に一時的に「公開（Public）」設定に変更した。 |
| 同時期 | 検証作業の完了後、公開設定を元に戻す作業が行われず、ST1は公開された状態のまま放置された。 |
| 8か月前 | 別の開発チームが、行動履歴データを保存するDOC1を構築したが、認証設定を行わず、初期設定のまま運用を開始した。 |
| 直近の四半期チェック | セキュリティ部門による手動チェックが実施されたが、確認対象は情報システム部門が把握しているクラウド環境に限られ、各チームが個別に契約していたST1・DOC1を含む環境は確認対象に含まれていなかった。 |
| X年 | 海外の脅威インテリジェンス企業から、DOC1への認証なしアクセスが可能である旨の連絡を受けた。 |
| 調査後 | ST1・DOC1の両方から、約120万人分の利用者データ（メールアドレス、生年月日、活動量・心拍数等のセンサーデータを含む）が、外部から閲覧可能な状態になっていたことが判明した。 |
(a) 自社の公開クラウド環境の設定不備を、自社で検知する仕組みがなかった。
(b) 情報システム部門が把握していない環境が生まれ、セキュリティ管理の対象から漏れてしまった。
(c) 確認対象が限定的かつ確認頻度が低く、設定不備が長期間放置される構造だった。
(b)は「シャドーIT」という言葉を使わなくても、「情報システム部門が把握していない環境が存在した」という趣旨が書けていれば加点。(c)は「手動・低頻度」という運用の限界に言及できているかが核心で、「担当者の確認ミス」という個人の責任に矮小化した答えは評価されにくい。
各部署が情報システム部門の管理外でクラウドサービスを契約・利用する状態は「シャドーIT」と呼ばれ、組織全体のセキュリティ管理の死角になる。クラウド利用状況を一元的に可視化・管理する体制（クラウドガバナンス）が、設定不備対策の前提条件となる。
(a) 検証作業のために変更した公開設定を、作業完了後に元へ戻す手順が行われなかった。
(b) クラウドサービスの初期設定をそのまま使用し、認証の設定を行わなかった。
(a)は「公開設定にしたこと自体」ではなく「戻し忘れたこと」が直接の原因であるという因果関係を明確にすること。(b)は「初期設定（デフォルト設定）のまま」という具体的な原因に言及できているかが核心。
クラウドサービスの設定不備の多くは「一時的に変更した設定を戻し忘れる」「初期設定（多くの場合、利便性を優先した緩い設定）をそのまま使う」という、地味だが頻発するパターンに起因する。検証作業の前後で設定を確認するチェックリストや、初期設定を安全側に強制するガードレールの仕組みが有効。
(a) 心拍数等の健康関連データは要配慮個人情報に該当する可能性があり、より厳格な対応が求められる。
(b) データが複数のクラウド環境・複数チームに分散して保存されており、全体像の把握に時間を要した。
(a)は「要配慮個人情報」という用語、または「健康に関する情報は特に慎重な取り扱いが必要」という趣旨のいずれかに言及できていれば加点。単に「個人情報が漏えいした」とだけ書くと、情報の性質による対応の重さの違いを説明できていない。
個人情報保護法上、病歴や健康診断結果等の「要配慮個人情報」は、通常の個人情報よりも厳格な取得・取扱いのルールが適用される。心拍数等のセンサーデータも、健康状態の推測につながる情報として、慎重な扱いが求められる場合がある。
(a) 要配慮個人情報の漏えいは報告・通知の対象となる可能性が高く、速やかな対応が必要になる。
(b) 利用者が居住する国・地域の個人データ保護法令（GDPR等）に基づく対応も検討する。
(c) 社外からの脆弱性・問題の指摘を受け付け、速やかに評価・対応する窓口を整備する。
(b)は「GDPR」という単語を書けなくても、「海外の法令にも対応が必要になりうる」という趣旨が書けていれば加点。日本国内の法令のみを前提とした解答は、グローバルにサービスを提供する企業のケースとしては不十分。
海外の利用者を含むサービスでデータ漏えいが発生した場合、日本の個人情報保護法だけでなく、利用者が居住する国・地域の法令（EUのGDPR等）に基づく報告義務が生じる可能性がある。自社のサービス対象地域に応じて、適用される法令を把握しておく必要がある。
(a) 各チームのクラウド利用を情報システム部門が一元的に把握・管理する体制を整備する。
(b) CSPMを導入し、公開設定や認証不備を継続的かつ自動的に検知する。
(c) 検証作業後に設定を元に戻したことを確認するチェックリストを運用する。
(d) データの機密度を分類し、要配慮個人情報を含むデータの保管・移動ルールを明確化する。
(a)〜(d)は、設問1〜3で指摘した個別の問題点（シャドーIT、手動・低頻度チェック、設定の戻し忘れ、要配慮個人情報の管理不足）に、それぞれ一対一で対応する解答になっているかを確認すること。
クラウド時代のセキュリティ対策は「個々の設定ミスを直す」だけでは不十分で、「誰がどのクラウドを使っているかを把握する（ガバナンス）」「設定の誤りを自動的に検知する（CSPM）」という、組織全体を見渡す仕組みが土台になる。この土台がなければ、同種の設定不備は形を変えて再発し続ける。
コメント