IaaS・PaaS・SaaS で利用者が負う範囲がどう変わるのかを整理。設定の誤りによる公開事故がなぜ繰り返されるのか、鍵と権限の管理、ログの取得、情報処理安全確保支援士試験での問われ方まで解説します。
クラウドを使うと、守る範囲は減りますが、無くなりはしません。どこまでが事業者の責任で、どこからが利用者の責任か——この線引きを責任共有モデルといいます。事故の多くは、この線を勘違いしたところで起きています。「クラウドだから事業者が守ってくれる」という誤解を正す設問が、繰り返し出題されます。
| 層 | IaaS | PaaS | SaaS |
|---|---|---|---|
| データ・利用者の権限 | 利用者 | 利用者 | 利用者 |
| アプリケーション | 利用者 | 利用者 | 事業者 |
| ミドルウェア・OS | 利用者 | 事業者 | 事業者 |
| 仮想化基盤・物理 | 事業者 | 事業者 | 事業者 |
どの形態でも動かないのが、データと、誰にどの権限を与えるかです。SaaS であっても、共有設定を誤って外部に公開してしまえば、それは利用者側の問題です。逆に IaaS では OS の更新まで利用者の仕事になります。「この構成でパッチ適用は誰の責任か」という形で問われます。
クラウドでの情報漏えいは、破られたのではなく、公開設定のまま置かれていた、という形が目立ちます。オンプレミスなら物理的な境界が最後の砦になりましたが、クラウドでは設定値ひとつで全世界に公開されます。境界が「設定」に変わったことが、事故の質を変えました。
人手で確かめ続けるのは現実的ではないため、設定を自動で点検する仕組み（設定監査）を入れます。基準から外れた状態を検知して知らせる、あるいは自動で戻す。作った後に見張るのではなく、作るときの雛形の側を正しくしておく（構成をコードで管理する）方向も併せて採られます。
クラウドでは、アクセスキーが実質的な合鍵になります。これがソースコードと一緒に公開の場所へ置かれてしまう事故が後を絶ちません。鍵は資源側に持たせる仕組み（インスタンスやサービスに役割を割り当てる）を使い、コードに書かない。書かざるを得ないなら秘密情報の保管サービスに預ける。そして定期的に入れ替える——この三点が基本です。
権限は最小限から始めます。管理者権限を日常的に使わない、操作の記録が残る仕組みで運用する、重要な操作には多要素認証を求める。クラウドは操作が API 一本で完結するため、権限を持った鍵が漏れたときの影響がオンプレミスより大きくなります。
クラウドでは、事業者側の層のログは自分では取れません。何が取得できて、どれだけ保存され、どう取り出せるのかを、契約や約款で確かめておく必要があります。インシデントのときに調べようとして「そのログは無い」と分かる、という事態を避けるためです。監査を受ける立場なら、第三者による評価（各種の認証取得状況）を確認材料にします。
データの保存される国、事業者を切り替えるときにデータを持ち出せるか（依存の度合い）、事業者が事業を終了したときにどうするか——こうした点も、選定時に見る項目として問われます。技術的な安全性だけでなく、運用と契約の話が答えに含まれるのがこの分野の特徴です。
クラウドは、部署の判断で簡単に契約できてしまいます。その結果、情報システム部門が把握していないサービスに業務の情報が置かれる、という状態が生じます。悪意があって始まるわけではなく、手軽さと業務の必要から生まれるのが厄介なところです。把握できていない以上、退職者の権限を消すことも、事故のときに影響を調べることもできません。
対策は禁止だけでは進みません。使いたくなる理由がある以上、禁じても隠れて使われます。安全に使える選択肢を先に用意し、申請すれば速やかに使える経路を作ったうえで、通信の記録から未把握の利用を見つけて拾い上げる。使わせない方向ではなく、把握して管理下に入れる方向で設計するのが現実的です。
午前Ⅱでは、責任共有モデルの範囲、各サービス形態の定義が問われます。午後では、クラウドへ移行した構成を示して「設定のどこが問題か」「誰の責任で何を直すか」を書かせる形が出ます。答えるときは、「事業者に依頼する」のか「自分たちで設定する」のかを明示すると、責任分界を理解していることが伝わります。
IPA 公式 PDF：令和6年度 秋期 午前Ⅱ問題 ↗本文はこの公式 PDF でご覧ください（アプリ内には転載していません）。