総合評価② セキュリティ — 責任共有モデルと「設定ミス」
📖 このページのゴール：「クラウドに任せれば安全」は半分だけ正解だと腹落ちさせること。任せるほどクラウドが守ってくれる範囲は広がります。でも最後まで自分の責任として残る部分（データ・設定・アクセス権）がある——そして実際の事故のほとんどは、その“自分の担当”の設定ミスで起きます。5つの選択肢を横断して「どこを誰が守るか」を整理します。 ← 目次・はじめにへもどる
🏢 まず、たとえ話：マンションの「共用部」と「部屋の鍵」
セキュリティの責任分担は、賃貸マンションで考えるとスッキリします。
- 🏗 建物・エントランス・防犯カメラ・配管 … これはオーナー（管理会社）の担当。住人が直す必要はありません。
- 🔑 自分の部屋の鍵・窓の戸締まり・誰を部屋に入れるか … これは住人の担当。どんなに立派なオートロックのマンションでも、自分の部屋の鍵を玄関マットの下に隠したら意味がありません。
クラウドもまったく同じです。「任せる」を選ぶほど、建物まわり（物理・ネットワーク・OS）はクラウドがしっかり守ってくれます。でも“部屋の鍵”＝あなたのデータと設定とアクセス権は、いつまでも住人（あなた）の責任。この線引きを 責任共有モデル（せきにんきょうゆうモデル＝守る範囲を分け合う考え方） と呼びます。
🤝 責任共有モデル（任せるほど、クラウドの“守り”が広がる）🟢
§4の共通レイヤー表を、セキュリティの目線で読み直します。下に行く選択肢ほど、クラウド（オーナー）が守る範囲が広がり、あなたが守る範囲は狭まります。
物理ハード / ネットワーク / 仮想化 / OS / ミドルウェア / ランタイム / アプリのコード / データ・設定・アクセス権
| レイヤー | オンプレ | IaaS | コンテナ(マネージド) | PaaS | サーバーレス/BaaS |
|---|---|---|---|---|---|
| 物理〜仮想化 | 🔧自分 | クラウド | クラウド | クラウド | クラウド |
| OS | 🔧自分 | 🔧自分 | だいたいクラウド | クラウド | クラウド |
| ミドルウェア/ランタイム | 🔧自分 | 🔧自分 | 🔧自分(箱の中) | クラウド | クラウド |
| アプリのコード | 🔧自分 | 🔧自分 | 🔧自分 | 🔧自分 | 🔧自分(関数/設定) |
| データ・設定・アクセス権 | 自分 | 自分 | 自分 | 自分 | 自分 |
ポイントは2つだけ。
- ⬇️ 下に行くほど「クラウド」の文字が増える … 物理の盗難、ネットワーク機器、OSのセキュリティ更新（パッチ）まで、面倒で専門的な守りをプロが肩代わりしてくれます。これは任せることの最大のメリット。
- 🟥 でも一番下の行（データ・設定・アクセス権）は、どの列も「自分」のまま … ここが消えない責任です。
🔑 全ページ共通の鉄則：どんなに任せても「データ・設定・アクセス権」は最後まであなたの責任。クラウドの“設定ミス”（公開設定・権限・鍵）が最大の事故。
🟥 消えない自分の責任 ＝「設定ミス」事故の四天王 🟢
クラウドが破られて情報が漏れた、というニュースの多くは、クラウド自体が壊れたのではなく、利用者の“部屋の鍵”の置き忘れです。とくに多い4パターンを覚えてください。
| ありがちな事故 | どういうこと？（たとえ） | やってはいけないこと |
|---|---|---|
| 🗂 ストレージの全公開 | 社内用のファイル置き場（S3 / GCS バケット）を、うっかり「全世界に公開」設定のまま放置。倉庫のシャッターを開けっぱなしにするのと同じ | 「とりあえず公開にしたら動いた」で本番運用しない |
| 🔓 権限の付けすぎ（過剰なアクセス権） | 「面倒だから全部入りの管理者権限（過剰な IAM）」を配る。全部屋のマスターキーを全員に配るようなもの。1人乗っ取られたら全部やられる | 「とりあえず全権限」で済ませない（最小権限が原則） |
| 🔑 鍵・APIキーの漏洩 | パスワードやAPIキー（サービスを使うための合鍵）をコードに直書きして、公開リポジトリ（GitHub等）にコミット。鍵を玄関ドアにテープで貼って外出するのと同じ | 鍵・トークンをソースコードやチャット・公開メモに貼らない |
| 🚪 初期パスワード放置 | 管理画面の初期パスワード（admin / password 等）を変えずに公開。新築の鍵を「とりあえずの仮鍵」のままにしておくようなもの |
初期パスワードは最初に必ず変更する |
💡 この四天王はどの選択肢でも起きえます。オンプレでもサーバーレスでも、「鍵の置き忘れ」は人間がやらかすミスだから。だからこそ“任せたから安全”は誤解で、ここは自分で締めるしかありません。
🩹 パッチ当て（セキュリティ更新）は誰がやる？ 🟢
ソフトには次々と弱点（脆弱性＝ぜいじゃくせい）が見つかり、それを塞ぐ修正（パッチ）が配られます。「誰がパッチを当てるか」は選択肢でハッキリ分かれます。
| 選択肢 | OS・土台のパッチ | アプリ／部品のパッチ |
|---|---|---|
| オンプレ / IaaS | 🔧 自分でやる（OSの更新当番が必要） | 🔧 自分 |
| コンテナ | だいたいクラウド（土台）＋ 🔧 箱の中身は自分（古い部品を入れたままにしない） | 🔧 自分 |
| PaaS / サーバーレス・BaaS | 🟢 クラウドにお任せ（土台は勝手に最新化） | 🔧 でもアプリの脆弱性は自分（自分のコードや使っているライブラリの穴は自分で塞ぐ） |
覚え方はシンプルです。
- ⬇️ 下に行くほど「土台のパッチ」は楽になる（PaaS以上はOS更新を意識しなくていい）。
- 🟥 でも「自分が書いたコード」と「自分が選んだ部品」の穴は、どこまで任せても自分の責任。サーバーレスでも、関数の中に弱いライブラリを入れていれば、そこは突かれます。
🍕 ピザのたとえ：宅配ピザ（PaaS）にすればキッチンの衛生管理（OSの守り）はお店任せ。でも自分でテーブルに出した飲み物（自分のコードとデータ）に毒が入っていないかは、最後まで自分でチェックする必要があります。
🌍 コンプライアンス・データ所在地（どの国のサーバー？）🔧
もう1つ、初心者でも知っておくとよい観点が データ所在地（しょざいち＝データが物理的にどの国に置かれるか） です。
- 🗺 クラウドは世界中にデータセンター（リージョン＝地域）を持っています。あなたのデータが日本にあるのか、海外にあるのかは、選んだリージョン次第。
- 📜 個人情報などは、「国外に持ち出してよいか」が法律・規制（コンプライアンス）で決まっている場合があります（例：個人情報保護、医療・金融などの業界ルール）。
- ⚖️ 一般に、オンプレ／IaaS は「どこに置くか」を細かく自分で決めやすい（規制の厳しい大企業が好む理由）。PaaS／BaaS は手軽な反面、保管場所の選択肢が限られることがあります。
- 🟢 個人・小さなチームのうちは深入り不要。ただし「他人の個人情報を預かる」「仕事で使う」段階になったら、「このサービスのデータはどの国に置かれる？」を一度確認するクセを。
📋 選択肢ごとのセキュリティ早見表
5つの選択肢を横断して「クラウドが守ってくれる範囲」「自分が守る範囲」「特に注意」を一覧にしました。自分が守る範囲の一番下に、いつも“データ・設定・アクセス権”が居ることに注目してください。
| 選択肢 | 🛡 クラウドが守る範囲 | 🔑 自分が守る範囲 | ⚠️ 特に注意 |
|---|---|---|---|
| オンプレ | （ほぼ無し。建物の入退室も自前） | 物理〜OS〜アプリ〜データ・設定・権限まで全部 | 守る範囲が広い＝専門知識と当番が要る。盗難・物理・OS更新まで自前 |
| IaaS | 物理・ネットワーク・仮想化 | OS以上ぜんぶ（OSパッチ・ミドル・アプリ・データ・設定・権限） | OSの更新を忘れがち。鍵の置き忘れ／セキュリティグループ（通信許可）の開けすぎ |
| コンテナ | 物理〜（多くは）OSの土台 | 箱の中身（古い部品・ミドル）＋アプリ＋データ・設定・権限 | 古いイメージ（箱）を使い回さない。箱の中に鍵を焼き込まない |
| PaaS | 物理〜OS〜ミドル/ランタイム | アプリのコード＋データ・設定・権限（特に環境変数の鍵） | 土台は安心。でも自分のコードの穴と環境変数に入れた鍵の管理は自分 |
| サーバーレス・BaaS | 物理〜ランタイムまで広く | 関数のコード＋データ・設定・権限（公開ルール／DBのアクセス制御が要） | 一番楽だが、DBの公開設定・アクセス権限を間違えると丸見え（後述のRLSへ） |
🟢 読み取り方：右に行く（任せる）ほど、左の「自分が守る範囲」は短くなる。でも一番下の“データ・設定・アクセス権”だけは全列で残る。ここがこのページの背骨です。
🔗 姉妹教材と地続き：「鍵を守る」と「データは誰のもの（RLS）」
この“消えない責任”の話は、姉妹教材の セキュリティ脅威マップ と完全に地続きです。とくに次の2つは、ここで言う「データ・設定・アクセス権」そのもの。
- 🔑 鍵を守る → クラウド設定・鍵管理系の攻撃と対策 「APIキーをコミットしない」「バケットを全公開しない」は、まさに本ページの“設定ミス四天王”の話。どの選択肢を選んでも避けて通れません。
- 🛡 データは誰のもの＝アクセス制御（RLS） → バックエンド実装系の攻撃と対策 とくに BaaS（Firebase / Supabase） では、ブラウザから直接データベースを触れる代わりに、「誰がどの行を読み書きできるか」のルール（RLS＝Row Level Security／行レベルの権限）を自分で正しく設定することが命綱になります。ここを開けっぱなしにすると、便利さがそのまま“丸見え”に直結します。
🧭 つまり「どの選択肢を選ぶか」と「セキュリティをどう守るか」は別々の話ではなく、選択肢が変わると“自分が締めるべきネジ”の位置が変わるだけ。ネジ自体（鍵・公開設定・権限）はいつも自分の手元にあります。
🟢 ひとことで言うと
「任せる」を選ぶほど、物理・ネットワーク・OSの守りはクラウドが肩代わりしてくれます。でも“設定責任”＝データ・設定・アクセス権だけは、どの選択肢でも最後まであなたの担当。 事故の大半はクラウドが壊れたのではなく、バケット全公開・過剰な権限・鍵の漏洩・初期パスワード放置という“部屋の鍵の置き忘れ”です。マンションのオーナーが立派でも、自分の部屋の鍵は自分で締める——それがクラウド時代のセキュリティの第一歩です。