2026年08月07日

クラウドのセキュリティを再設計する実践ガイド｜設定ミスと責任共有モデルの基本

クラウドへの移行は進めたものの、クラウドのセキュリティを何から見直せばよいか整理しきれない——情報システム部門の責任者やセキュリティ担当の中には、そう感じている方も多いのではないでしょうか。クラウドの事故は、高度な攻撃だけでなく、設定ミスや権限の管理不足といった日常の運用に潜む要因からも起こります。鍵になるのは、「事業者任せ」「境界を守る」という発想から、「自社の責任範囲を見極め、データそのものを守る」発想への転換です。クラウドのセキュリティを見直すときは、まず「自社の責任範囲」「設定・認証の状態」「端末に残るデータ」の3点を確認することが出発点になります。この記事では、責任共有モデルを踏まえながら、設定ミス・不正アクセス・端末紛失に備える優先順位を、再設計の視点で整理します。

クラウドのセキュリティは「事業者任せ」では守れない

まず押さえたいのは、クラウドにしてもセキュリティを事業者へ丸ごとは委ねられないことです。情報漏洩が起きれば、本人への通知や説明責任、信用の低下といった経営課題に直結します。ここでは近年のリスク動向と、利用者と事業者で責任がどう分かれるかを整理します。

IPA10大脅威が示す利用者側で備えるべきリスク

クラウド環境のリスクには、事業者ではなく利用者側の管理に関わるものが目立ちます。IPA（情報処理推進機構）は「情報セキュリティ10大脅威 2026」組織編で、「内部不正による情報漏えい等」を11年連続、「リモートワーク等の環境や仕組みを狙った攻撃」を6年連続で選出しています（出典：IPA「情報セキュリティ10大脅威 2026」）。いずれも権限を持つ人や働く環境に関わる脅威で、事業者が肩代わりできるものではありません。クラウドを使う側が、自ら備える前提で捉える必要があります。

責任共有モデルでSaaS／IaaSごとに変わる利用者の責任範囲

クラウドのセキュリティの土台になるのが、責任共有モデルです。セキュリティの責任を利用者と事業者で分担する考え方で、AWSやMicrosoftをはじめ多くの事業者が採用しています。ポイントは、サービス形態によって利用者の責任範囲が変わることです。IaaSではOS・ミドルウェア・アプリ・データまで利用者が担い、PaaSではアプリとデータ、SaaSでは主にデータとアカウント・利用設定が対象になります。形態を問わず「データ・設定・アカウント管理」は利用者に残ります。「クラウドにすれば事業者がすべて守る」という理解は、この点で実態とずれています。なお、細かな責任分担は、事業者やサービスによって異なります。

クラウドのセキュリティ事故は機密性と可用性の両面で起きる

クラウドの事故は、特別な高度技術よりも日常運用のすきまから起こりがちです。代表的な発生パターンを、情報が漏れる「機密性」と、データが使えなくなる「可用性」の両面から整理します。

設定ミスによる意図しない公開と権限過多

代表的なのが、クラウドの設定ミスです。アクセス権の付与しすぎや公開範囲の見落としで、本来は限られた人しか見られないデータが、意図せず外部から参照できる状態になりかねません。総務省は、設定ミスによる情報流出のおそれが繰り返し起きている状況を受けて「クラウドの設定ミス対策ガイドブック」を公開しています（出典：総務省「クラウドの設定ミス対策ガイドブック」）。設定は一度決めて終わりにせず、公開範囲とアクセス権の定期的な点検が欠かせません。

ID認証の甘さと多要素認証の未設定が招く不正アクセス

もう一つの典型が、ID認証の甘さです。パスワードの使い回しや多要素認証（MFA）の未導入があると、正規のIDを使った不正ログインを許しかねません。クラウドはどこからでもアクセスできるため、認証を突破されると被害が広がりやすくなります。多要素認証の導入と権限の最小化が、まず取り組むべき備えです。

端末紛失で残るローカルデータの情報漏洩リスク

クラウド利用でも、手元の端末は無視できません。たとえば、営業担当者がクラウド上の提案資料を一時的にPCへダウンロードし、出張先で編集したまま持ち歩くケースでは、クラウド側のアクセス制御だけでは、ローカルに残ったファイルまで管理しきれません。こうしてローカルに残った可読データは、端末の紛失や盗難で情報漏洩につながります。端末に残るデータの扱いは、次章の「可読データを残さない」発想につながる論点です。

障害・ランサム・誤削除によるデータ消失と可用性のリスク

ここまでは情報が漏れる機密性のリスクでした。最後に、データが使えなくなる可用性のリスクを見ます。事業者側の障害、ランサムウェアによる暗号化、操作ミスによる誤削除などで、データ消失やサービス停止が起こり得ます。バックアップの取得先と復旧手順を決めておくことが、可用性を守る基本です。

暗号化だけでは守りきれない場面と「可読データを残さない」発想

ここでは、暗号化やアクセス制御だけでは守りきれない場面を整理し、「可読データを残さない」という発想を、補完的な選択肢として紹介します。

暗号化済みでも説明責任が残る場面の整理

暗号化は重要な対策ですが、「暗号化していれば必ず安心」とは限りません。漏えい時の報告の要否は、データの内容や漏えいの態様、復元の可能性、管理状況などを踏まえて個別に判断されます。個人情報保護法には、報告を要しない例外として「高度な暗号化その他の必要な措置」を講じた場合の定めもありますが、これと認められるには復号鍵を分離して漏えいを防ぐなどの条件が必要です（出典：個人情報保護委員会）。鍵が一緒に漏れたり、復号後のデータが扱われたりする場面では、暗号化していても保護が崩れ、説明責任が残りかねません。

アクセス制御から「データ自体を無意味化する」発想への拡張

そこで一つの方向性となるのが、守る対象をアクセス制御からデータそのものへと広げる発想です。「万一データが外部に出ても意味を持たない状態にしておく」という考え方で、その一つが、秘密分散と呼ばれる技術にあたります。データを意味のない断片に分けて扱い、断片の一部だけでは元の情報を復元しにくくします。暗号化と置き換えるものではなく、組み合わせて使える補完的なアプローチといえます。

端末紛失シナリオで無意味化・分散保存が補完策になるケース

この発想が活きるのが、端末の紛失・盗難という場面です。データを意味のない断片に変換し、PC内と外部（クラウドやスマートフォンなど）に分散して保存しておけば、PC単体に残るのは断片の一部にとどまります。こうして可読データを残さない状態にしておけば、端末を紛失しても、断片がそろわなければ元のデータに戻しにくいため、漏えいリスクを抑えやすくなります。ただしこれはすべてのクラウドリスクを解決するものではなく、設定ミスやID認証の対策と併せて、端末側を補う一手段として位置づけるのが現実的です。

クラウドのセキュリティ対策は基本から段階的に進める

クラウドのセキュリティ対策は、すべてを同時に進めるより、影響の大きい順に確認するほうが現実的です。まずは設定・権限、次に認証、続いてバックアップと端末内のデータを点検しましょう。以下では、その順序で再設計の道筋を整理します。

総務省ガイドの基本3観点（組織・ルール／人／作業手順）から着手

最初に取り組みたいのが、体制とルールづくりです。総務省「クラウドの設定ミス対策ガイドブック」は、対策を「組織・ルール」「人」「作業手順」の基本3観点と、それらを補完・強化する「道具（ツール）」に整理しています（出典：総務省「クラウドの設定ミス対策ガイドブック」）。まずは責任者の明確化、利用ルールの整備、設定作業の手順化という基本3観点から始め、必要に応じて道具で強化するのが堅実です。

IPA15項目で認証・バックアップ・契約・データ所在地を棚卸し

次に、自社の状況を棚卸しします。IPA「中小企業のためのクラウドサービス安全利用の手引き」は、15項目のチェックシートを用意しています。項目は「選択」「運用」「セキュリティ管理」の3つに分かれ、利用者の認証、バックアップ、適用法令や契約条件、データ保存先の所在地などが含まれます（出典：IPA「中小企業のためのクラウドサービス安全利用の手引き」）。サービスごとに点検すると、どこに穴があるかが見えやすくなります。抜けの大きい項目から順に埋めていくとよいでしょう。

多要素認証とログ監視を備えゼロトラストでID・端末・データを守る

基本が固まったら、より進んだ選択肢としてゼロトラストが挙げられます。NISTの「ゼロトラスト・アーキテクチャ」は、ネットワークの内外を前提にせず、アクセスのたびに検証する原則を示しています（出典：NIST）。具体的には、多要素認証でログインを固め、アクセスログを監視し、利用者や端末の状態に応じて権限を都度確認します。なお、ゼロトラストは境界防御を置き換えるものではなく、境界防御と併用しながら、ネットワークの場所に依存しない検証を加えていく考え方です。さらに端末側では、無意味化・分散保存を補完策として組み合わせると、紛失時の保護を補えます。優先度の高いところから段階的に取り入れていきましょう。

なお、着手の順番は自社の状況で変わります。多要素認証やバックアップが未整備なら、無意味化・分散保存より先に、認証と権限管理を優先します。基本対策が整っている場合は、端末に可読データが残っていないかを次の確認ポイントにするとよいでしょう。

クラウドのセキュリティに関するよくある質問

ここでは、クラウドのセキュリティでよく寄せられる疑問に答えます。

クラウド事業者に任せれば情報漏洩対策は十分か

事業者に任せるだけでは、情報漏洩対策として十分とはいえません。責任共有モデルのもとで、データ・設定・アカウントの管理は利用者側に残るためです。一方、事業者の信頼性は確認できます。ISMAP（政府のクラウドサービス評価制度）への登録やISMSなどの認証、SLA（サービス品質保証）が示す責任範囲を確認すると、任せられる部分を見極めやすくなります。事業者の見極めと自社の運用、その両方で情報漏洩を防ぐ姿勢が欠かせません。

暗号化していれば端末紛失時の漏洩対策になるか

暗号化は有効ですが、それだけで万全とはいえません。復号鍵が端末と一緒に持ち出されたり、ログインしたままの状態で紛失したりすれば、データを読まれるおそれが残ります。実務では、暗号化に加えて、画面の自動ロック、遠隔からのロックやデータ消去、データを可読のまま残さない仕組みを組み合わせると、紛失時の備えを高められます。なお個人情報保護法では、報告を要しない例外は高度な暗号化など一定の条件を満たした場合に限られ、要否は状況に応じて個別に判断する必要があります（出典：個人情報保護委員会）。暗号化を入口に、複数の備えを重ねることが効果的です。

中小企業はクラウドのセキュリティを何から始めるべきか

まずは基本的な体制づくりから着手するのが堅実です。総務省ガイドブックの基本3観点に沿って、責任者を決め、利用ルールを整え、設定作業を手順化することが出発点になります。あわせて、IPAのチェックシートで認証やバックアップ、データの所在地などを点検すると、弱点が見えやすくなります（出典：総務省、IPA）。ただ、中小企業では専任担当者を置きにくいのも実情です。その場合は、IPAのSECURITY ACTION（自己宣言制度）や外部のセキュリティ診断サービスを活用して不足を補う方法もあります。使える制度や外部の力を借りながら段階的に進めるとよいでしょう。

まとめ

クラウドのセキュリティは、事業者任せでは守りきれません。責任共有モデルのもとで、データ・設定・アカウントは利用者が担う領域です。設定ミスや認証の甘さ、端末紛失、可用性のリスクといった多角的なリスクに対応するため、まずは総務省やIPAの基本に沿って体制を整え、チェックシートで現状を棚卸しすることが出発点になります。そのうえで暗号化やゼロトラスト、可読データを残さない仕組みを、自社に合わせて段階的に重ねる——これが、事業者任せ・境界中心の発想から、データ中心へとクラウドのセキュリティを再設計する道筋です。