クラウドは安全なのか？主なリスクと利用者がとるべき対策・安全なサービスの選び方

Microsoft 365やGoogle Workspace、クラウドストレージへと業務データを預ける企業が当たり前になりました。一方で「社外のサーバーに大事なデータを置いて、本当に安全なのか」という不安は根強く残ります。

クラウドそのものは危険なのでしょうか。それとも、使い方さえ押さえれば安心して任せられるのでしょうか。判断するには、クラウドで実際に起こる事故の中身と、事業者と自社のどちらが何を守るのかという線引きを知る必要があります。

本記事では、クラウドが安全に使えるのかという結論からお伝えし、起こりうるリスク、事業者と利用者の責任の分かれ方、利用者側で今すぐ取るべき対策、安全なサービスの見分け方までを一通り整理します。専任のセキュリティ担当がいない企業でも、要点を押さえれば自社でクラウドを安全に使えると判断できるよう解説します。

クラウドは安全に使えるのか（結論）

結論から言えば、クラウドは要点を押さえれば安全に使えます。データセンターの物理的な保護やサーバーの保守といった基盤部分は、クラウド事業者が専門の体制で堅く守っています。中小企業が自前のサーバー室で同じ水準を維持するほうが、むしろ難しいのが実情です。

問題は、事故の多くが基盤側ではなく利用者側の設定・認証・運用で起きる点にあります。総務省が公表したガイドラインは、クラウドの設定不備を抑止するための基本的な考え方を次の3点に整理しています。

クラウドサービスにおける設定不備の抑止・防止に向けた基本的な考え方は、下記の３つである。

① クラウドサービス利用者・事業者双方において、クラウドサービスの特性や、クラウドサービスの利用・提供におけるリスクについて認識すること

② クラウドサービス利用者・事業者双方において、自身の責任範囲や役割を理解し、それを共通認識とすること

③ クラウドサービス利用者・事業者間でコミュニケーションを密なものとしつつ、双方における設定不備の抑止・防止の対策を適切に実施すること

出典：クラウドサービス利用・提供における適切な設定のためのガイドライン｜総務省

裏を返せば、リスクと自社の責任範囲を理解し、設定不備を防ぐ対策を実施できれば、クラウドは安全に使えるということです。実際、同ガイドラインは不正アクセスの原因の約17.7%（第3位）が設定不備だと指摘しており、利用者側の設定が事故の主要因の一つになっています。次の章から、起こりうるリスクの実像を具体的に見ていきます。

出典・参考資料（1件）

• 出典：クラウドサービス利用・提供における適切な設定のためのガイドライン（設定不備の原因比率・IPA「コンピュータウイルス・不正アクセスの届出状況2021年」を引用）｜総務省

クラウドで起こりうるリスク

ここからは、クラウド利用で実際に起こりうるリスクを整理します。事故が報じられると被害額や信用の失墜に目が向きがちですが、まず「どういう時に・誰の領域で起きるか」を押さえると、自社で防げる範囲が見えてきます。リスクは大きく、利用者側の設定・運用で起きるものと、事業者側・環境要因で起きるものに分けられます。

利用者側の設定・運用で起きるリスク

クラウドの事故でとくに多いのが、利用者側の設定ミスです。アクセス権限を「全員に公開」のまま運用してストレージの中身が外部から閲覧できた、といった事例が典型で、前述のとおり設定不備は不正アクセス原因の約17.7%を占めます。

認証の甘さに起因する不正アクセスと情報漏えいも見過ごせません。IPAの「情報セキュリティ10大脅威 2025」（組織編）でも、内部不正による情報漏えい（4位）や不注意による情報漏えい（10位）が上位に並びます。ランサム攻撃（1位）や脆弱性を突いた攻撃（3位）も、入口はパスワードの使い回しや多要素認証の未設定といった利用者側の認証の甘さにあることが少なくありません。

加えて、情報システム部門が把握しないまま従業員が無断でクラウドサービスを使う「シャドーIT」も、利用者側のリスクです。管理外のサービスにデータが蓄積されると、権限管理も退職時のアカウント停止も及ばず、漏えいの温床になります。

出典・参考資料（1件）

• 出典：情報セキュリティ10大脅威 2025［組織］（順位は危険度の高低を示すものではない）｜独立行政法人情報処理推進機構（IPA）

事業者側・環境要因で起きるリスク

利用者の運用とは別に、事業者側や外部環境に起因するリスクもあります。代表的なのがサービス障害です。大規模障害が起きると、その事業者のサービスに依存している業務が一斉に止まります。IPAの10大脅威でも、分散型サービス妨害攻撃（DDoS攻撃）が8位に挙がっています。

データ消失のリスクもゼロではありません。事業者側の大規模なシステム障害や、地震・火災といった災害でデータセンターが被災する可能性は残ります。大手事業者は複数拠点での多重化で備えますが、利用者側でも重要データのバックアップを自社で持っておくと、万一の際に復旧の選択肢が広がります。これらのリスクをふまえ、次章で事業者と利用者の責任の分かれ方を見ていきます。

事業者と利用者で守る範囲はどう分かれるか（責任共有モデル）

ここからは、クラウドのセキュリティを「誰が何を守るのか」という観点で整理します。この線引きは「責任共有モデル」と呼ばれ、総務省のガイドラインも、多くの事業者がこの考え方を採用していると説明しています。

クラウドサービスの情報セキュリティを高めるためには、クラウドサービス事業者とクラウドサービス利用者が協力して、クラウドサービスに対する責任を共有する必要がある。この責任を共有するという考え方（責任共有モデルと呼ぶ）を多くのクラウドサービス事業者が採用している。

出典：クラウドサービス利用・提供における適切な設定のためのガイドライン｜総務省

事業者公式の説明も同じ考え方に立ちます。たとえばAWSは、インフラを守る「クラウドのセキュリティ」は自社の責任、その上で利用者が選んだサービスの設定を守る「クラウド内のセキュリティ」は顧客の責任、と線を引いています。守る範囲は利用形態や契約で変わるため、総務省ガイドラインも責任範囲は一律に決まるものではなく、事業者の免責事項などで責任分界を確認する必要があると注意を促しています。

出典・参考資料（1件）

• 出典：AWS 責任共有モデル｜アマゾン ウェブ サービス（AWS）

提供形態（SaaS・PaaS・IaaS）別の利用者対策範囲

利用者が守るべき範囲は、クラウドの提供形態によって変わります。多くの企業が日常的に使うMicrosoft 365やGoogle Workspace、クラウドストレージはSaaS（Software as a Service）にあたり、利用者の責任範囲は最も狭くなります。総務省ガイドラインは、SaaSにおける利用者の責任を次のように記しています。

SaaS を利用する場合、図表Ⅱ．１．２－３に示すとおり、クラウドサービス利用者が責任を負う部分は、データとアプリケーションの管理の一部となる。アプリケーションの動作に係る設定（図の動作設定）は SaaS 事業者が責任を負う一方、利用者アカウントや業務データの設定（図のユーザ設定）については、クラウドサービス利用者の責任となる。

出典：クラウドサービス利用・提供における適切な設定のためのガイドライン｜総務省

一方、開発基盤を借りるPaaS（Platform as a Service）ではアプリケーションとデータまで、サーバーやネットワークを自社で構築するIaaS（Infrastructure as a Service）ではOS・ミドルウェアの設定まで、利用者の責任範囲は広がります。提供形態ごとの大まかな分担は次のとおりです。

提供形態	事業者が主に守る	利用者が主に守る
SaaS（Microsoft 365・Google Workspace など）	アプリの稼働・基盤・OS・ミドルウェア	アカウント・権限・共有/公開設定・業務データ
PaaS	基盤・OS・ミドルウェア	アプリケーション・データ・アカウント・権限
IaaS	物理基盤・仮想化基盤	OS・ミドルウェア・アプリ・データ・アカウント・権限

自分の責任はアカウント・権限・設定が中心

SaaS中心で使う企業にとって、守るべき中心はアカウントと権限、そして公開範囲などの設定です。具体的には、ファイルの共有リンクや外部共有を許すか、管理者ロールを誰に与えるか、退職者のアカウントをいつ止めるか、といった日々の運用がここに含まれます。いずれも事業者任せにはできず、利用者が手を打たなければ埋まりません。

前章で見た設定ミスや認証の甘さによる事故が利用者側で起きるのは、ここが利用者の責任範囲だからです。次章では、この領域を固める具体的な対策を優先順に並べます。

利用者が今すぐやるべき対策（優先順チェックリスト）

ここからは、利用者側で取るべき対策を、効果が高く着手しやすい順に並べます。すべてを一度に完璧にする必要はありません。上から順に手を付けるだけでも、事故の起きやすい入口を着実に塞げます。

1. 多要素認証（MFA）を有効にする：パスワードが漏れても、本人確認の2段階目がかかれば不正ログインの大半を防げます。とくに管理者アカウントは最優先で設定しましょう。総務省ガイドラインも、管理者・特権アカウントには多要素認証を求めています。
2. アクセス権限を最小限にする（最小権限）：担当業務に必要な範囲だけに権限を絞り、管理者権限は限られた人だけに与えるようにします。権限が広いアカウントほど、乗っ取られた時の被害が大きくなるためです。
3. 共有・公開設定を点検する：ファイルやフォルダの共有範囲が「リンクを知る全員」や「全体公開」になっていないかを定期的に確認しましょう。設定ミスによる情報漏えいは、この点検で多くが防げます。
4. 重要データを暗号化し、アクセス元を制限する：機密性の高いデータは暗号化し、社内ネットワークなど許可したIPアドレスからのみアクセスできるよう制限するとよいでしょう。暗号化キーは統合的に管理すると運用が安定します。
5. バックアップを自社でも確保する：事業者側の障害やデータ消失に備え、重要データは別の場所にもバックアップを持ちます。多くのSaaSは一括エクスポート機能を備えており、定期的な書き出しや専用のバックアップサービスの利用で、自社で復旧できる状態を用意できます。
6. 従業員教育とシャドーIT対策を行う：許可するサービスと使い方を周知し、無断利用を減らします。人の運用が最後の砦になるため、ルールの共有と定期的な注意喚起を続けます。

チェックリストの多要素認証・最小権限・暗号化は、総務省ガイドラインが利用者側のベストプラクティスとして明記している対策です。

・ ユーザアカウントの管理においては、パスワード設定の厳格化や多要素認証の設定を行う。
・ 管理者や特権アカウントの管理においては、①多要素認証、②複数人でのチェック体制をとる
・ 特権アカウント利用者や特権昇格可能なアカウントは、最小限とすることが望ましい。

出典：クラウドサービス利用・提供における適切な設定のためのガイドライン｜総務省

最優先の多要素認証は、SMSの確認コード・認証アプリ・生体認証・パスキーなど、方式によって安全性も使い勝手も変わります。仕組みや二段階認証との違い、方式ごとの選び方は次の記事で詳しく解説しています。

どのリスクを、どの対策で、誰の責任領域で塞ぐのかを一覧にすると、自社で手を打つべき範囲がはっきりします。

主なリスク	主な対策	主な責任領域
設定ミスによる公開・漏えい	共有・公開設定の点検、最小権限	利用者
認証の甘さによる不正アクセス	多要素認証、アクセス元の制限	利用者
内部不正・不注意による情報漏えい	最小権限、暗号化、従業員教育	利用者
シャドーIT	利用ルールの周知、従業員教育	利用者
データ消失	自社側バックアップの確保	利用者・事業者
サービス障害	事業者の冗長化・SLAの確認	事業者

専任がいなくても回せる範囲（中小・ひとり情シス向け）

専任のセキュリティ担当がいない企業でも、上のチェックリストの最初の3つ（多要素認証・最小権限・共有設定の点検）は、各サービスの管理画面から対応できます（Microsoft 365は管理センター、Google Workspaceは管理コンソールが入り口です）。追加の製品を入れなくても、SaaSの標準機能の範囲で設定できることがほとんどです。

まずは各サービスの管理者ヘルプで「多要素認証」を調べ、管理者アカウントから有効にするのが最初の一歩になります。

難しくなるのは、複数のSaaSを使うほど、サービスごとに権限や認証を個別に設定・点検する手間が増える点です。1つずつ手作業で管理すると、設定漏れや退職者のアカウント停止忘れが起きやすくなります。ここを1つの基盤でまとめて管理する方法は、記事後半の「利用者側の対策をまとめて固める」で紹介します。

安全なクラウドサービスの選び方

利用者側の対策と合わせて、そもそも安全な事業者・サービスを選ぶことも大切です。ここからは、外部から安全性を見分ける判断軸を紹介します。公開情報だけでも確認できる軸を押さえておくと、導入前の比較がぶれません。

第三者認証で見分ける

第三者認証は、その事業者がセキュリティ管理の体制を外部機関に評価されている目印です。代表的なものを、発行主体と意味とあわせて整理します。

ISMS認証（ISO/IEC 27001）は、情報セキュリティマネジメントシステムの国際的な第三者適合性評価制度です。情報マネジメントシステム認定センター（ISMS-AC）が認定した認証機関が、JIS Q 27001（ISO/IEC 27001）を基準に組織の適合性を審査します。事業者が情報セキュリティの管理体制を第三者に認められているかの基本の目印になります。

ISMSクラウドセキュリティ認証（ISO/IEC 27017）は、ISMS（ISO/IEC 27001）の取得を前提に、クラウドサービスに固有の管理策への適合を評価する制度です（ISMS-ACが認定する制度）。一般のISMSより一段クラウドに踏み込んで評価されているかを見る軸になります。

一方、SOC 2は認証ではなく「報告書」です。米国公認会計士協会（AICPA）の基準にもとづき、公認会計士がサービス提供組織のセキュリティ統制を、セキュリティ・可用性・処理の完全性・機密性・プライバシーの観点で検証します。日本語で「認証」と呼ばれることがありますが、取得する証明書ではなく検証報告書である点に注意してください。

プライバシーマーク（Pマーク）は、JIS Q 15001にもとづき個人情報を適切に扱う体制を整えた事業者を、日本情報経済社会推進協会（JIPDEC）が認定する制度です。クラウドのセキュリティ統制そのものではなく、個人情報の取り扱い体制を見るための目印で、ISMSやSOC 2とは評価対象が異なります。

中小企業が見るべきは、認証名の有無だけではありません。これらの認証があるサービスは、設定や運用を任せる前提として「体制が第三者に評価されている」ことの裏づけになります。自社のデータの性質（個人情報が多いならPマーク、クラウド固有の統制を重視するなら27017など）に合わせて、どの認証が効くかを見極めると選びやすくなります。

出典・参考資料（4件）

• 出典：ISMS適合性評価制度について（JIS Q 27001／ISO/IEC 27001）｜一般社団法人情報マネジメントシステム認定センター（ISMS-AC）
• 出典：ISMSクラウドセキュリティ認証（ISO/IEC 27017）｜一般社団法人情報マネジメントシステム認定センター（ISMS-AC）
• 出典：SOC 2® — Reporting on Controls at a Service Organization｜AICPA & CIMA
• 出典：プライバシーマーク制度（JIS Q 15001）｜一般財団法人日本情報経済社会推進協会（JIPDEC）

保管場所・SLAで見分ける

認証に加えて、データの保管場所と可用性の約束も確認します。データがどの国のデータセンターに保管されるかは、適用される法律や有事の際の対応に関わります。国内にデータを置けるか、保管場所を選べるかは、公式サイトのセキュリティページやサービス仕様、利用規約で確認できます。

サービス稼働率の指標であるSLA（Service Level Agreement）も比較の軸です。公式サイトのSLA条項や利用規約で、「99.9%」「99.99%」といった稼働率の保証や、下回った場合の返金・補償条件が明示されているかを確認しましょう。業務が止まると困る用途ほど、ここを重視して選ぶとよいでしょう。

利用者側の対策をまとめて固める（サービス活用）

ここまで見てきた利用者側の対策のうち、アクセス制限・多要素認証・ID管理は、個別に設定するよりも1つの基盤でまとめて実現するほうが、設定漏れや管理の手間を減らせます。複数のSaaSを使う企業ほど、この「まとめて固める」発想が効いてきます。

こうした役割を担うのがID基盤（IDaaS）です。シングルサインオン（SSO）で複数サービスのログインを一本化し、多要素認証とアクセス制限、アカウントの発行・停止までを一元管理できます。IDaaSは必須の対策そのものではなく、利用者側の対策をまとめて楽に実現する一手段という位置づけです。まず主なID基盤を比較表で見比べ、そのうえで代表例を詳しく紹介します。

ID基盤に限らず、端末・ネットワーク・データまで含めた社内セキュリティ全体の選択肢を見比べたい場合は、以下の記事が役立ちます。守るべき対象ごとにソリューションのタイプと代表的なサービスを整理しています。

選ぶ際は、重視する点で絞り込むと迷いません。料金を抑えたいならIIJ IDサービス、人事情報と連携してアカウントの発行・停止を自動化したいならGluegent GateやExticが候補です。パスキーによるパスワードレス認証ときめ細かいアクセス制限を重視するなら、CloudGate UNOが向いています。

CloudGate UNO（株式会社インターナショナルシステムリサーチ）

CloudGate UNOは、運営元の株式会社インターナショナルシステムリサーチ（以下ISR）が自社開発する、ゼロトラスト型（社内外を問わず、アクセスのたびに本人と端末を確かめる考え方）のID基盤（IDaaS）です。一度の認証で複数のクラウドサービスへアクセスできるSSOを土台に、多要素認証・アクセス制限・ID管理を1つのプラットフォームにまとめています。

クラウドの安全性で課題になりがちな「アカウントと権限、認証」を、サービスごとに個別管理せず集約できる点が特徴です。

認証面では、フィッシングに強いパスキー（FIDO2）によるパスワードレス認証を全プランで無制限に使えます。アクセス制限は「端末・場所・時間」の3つの軸で設定でき、私用端末からのアクセス禁止や、時間帯による制御まで細かく指定できます。利用者側で取るべき対策である多要素認証・最小権限・アクセス制限を、この基盤の設定でまとめて満たせます。

料金はStandard Plusが月額400円／ユーザー（税別。税込440円）からで、30日間の無料体験も用意されています。国産の自社開発で、導入前から導入後まで日本語でのサポートを受けられます。運営元のISRはISMS（ISO/IEC 27001）とプライバシーマークを取得しています（料金・仕様は2026年11月時点）。

複数のSaaSを個別に管理する負担について、開発元のISRはインタビューで現場の実情を次のように述べています。

まとめ

クラウドは、基盤部分を事業者が堅く守る一方で、事故の多くは利用者側のアカウント・権限・設定で起きます。責任共有モデルで自社の守る範囲を理解し、多要素認証・最小権限・共有設定の点検から順に手を打てば、専任担当がいない企業でも安全に使えます。

サービスを選ぶ際は、第三者認証や保管場所・SLAで安全性を見分け、アクセス制限や多要素認証はID基盤でまとめて固めると運用が安定します。自社に合うサービスの資料を集めて、具体的な比較から始めてみてください。

よくある質問（FAQ）

Q. 責任共有モデルとは何ですか？

A. 責任共有モデルとは、クラウドのセキュリティを事業者と利用者が分担して守るという考え方です。事業者はデータセンターやサーバーなどの基盤を守り、利用者はアカウント・権限・公開設定など自分が使う部分を守ります。どこまでが利用者の責任かは提供形態（SaaS・PaaS・IaaS）や契約で変わるため、自社が守る範囲の把握がクラウドを安全に使う出発点になります。

出典・参考資料（1件）

• 出典：クラウドサービス利用・提供における適切な設定のためのガイドライン（責任共有モデル）｜総務省

Q. クラウドとオンプレミス（自社サーバー）はどちらが安全ですか？

A. クラウドとオンプレミスは、どちらが一方的に安全とは言えず、守る主体と範囲が違うだけです。クラウドは基盤の保守・物理防御・災害対策を専門体制の事業者に任せられる一方、設定や認証は利用者が担います。オンプレミスは自社で管理しきれますが、同水準の保守・監視を自前で維持する負担が大きく、専任担当のいない中小企業には重くなりがちです。

Q. 多要素認証を設定すればクラウドは安全になりますか？

A. 多要素認証はクラウドの安全性を大きく高めますが、それだけで万全になるわけではありません。パスワードが漏れても不正ログインの大半を防げる効果が高く、最優先で設定すべき対策です。ただし共有設定の誤りによる漏えいや過剰な権限付与、シャドーITは多要素認証では防げません。最小権限・共有設定の点検・従業員教育と組み合わせて初めて安全な状態になります。

Q. 無料のクラウドサービスは安全性が低いのですか？

A. 無料のクラウドサービスでも、料金の有無だけで安全性の高低は決まりません。無料プランでも多要素認証や通信の暗号化など基本的な保護機能を備えるものは多くあります。見るべきは価格ではなく、第三者認証（ISMS認証やSOC 2など）の有無・管理機能・データの保管場所です。無料プランは詳細なアクセス制御やログ機能が制限される場合があるため、業務利用では事前に確認してください。

Q. クラウドに保存してはいけないデータはありますか？

A. クラウドに保存してはいけないデータは原則としてなく、重要なデータほど保護設定を強めて預けるのが現実的です。個人情報や機密情報でも、暗号化・アクセス権限の最小化・多要素認証を設定すれば安全に扱えます。ただしマイナンバーや特に機微な個人情報、法令・契約で保管場所や扱いが定められたデータはより慎重な管理が必要なため、該当データの有無を先に確認し、保管場所を選べるサービスを選んでください。

Q. クラウドで情報漏えいが起きた場合、責任は事業者と利用者のどちらにありますか？

A. クラウドで情報漏えいが起きた場合の責任は、事故が起きた領域が事業者と利用者のどちらの責任範囲かによって決まります。設定ミスや認証の甘さなど利用者の責任範囲で起きた漏えいは利用者側の責任となり、基盤側の障害など事業者の責任範囲で起きたものは事業者側の責任になります。ただし責任の分かれ方は一律ではなく、契約内容や事業者の免責事項で定められているため、導入前に責任分界を確認しておくことが大切です。

クラウドの安全性を高めるサービスの料金・資料を一括チェック

MCB FinTechカタログでは、ID基盤・多要素認証・アクセス制限など、クラウドを安全に使うためのサービスの最新資料を無料で一括請求できます。認証方式・アクセス制限・料金を比べて、自社に合う1社を選べます。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。