クラウドセキュリティの事故事例と対策｜実際に起きた3つのケースから原因と備えを解説

社内の基幹業務までクラウドサービスで動かすようになり、設定の誤りや不正アクセスによる情報漏えいが、実際に起きた事故として報じられる機会が増えています。守る対象がパソコンや社内サーバーだけだった時代と違い、クラウド上の設定やアカウントの管理まで自社で担う場面が広がったためです。

こうした事故は、特定の業種や大企業だけに起きるものではありません。原因の多くは、アクセス権限の設定ミスや、アカウントの乗っ取り、委託先・従業員による持ち出しといった、どの企業でも起こりうる共通の型に当てはまります。まずは「実際にどんな事故が、なぜ起きたのか」を具体的に知ることが、自社の備えを考える出発点になります。

本記事では、実際に公表されている代表的な3つのクラウドセキュリティ事故を深掘りします。そこから共通する原因の型、自社で取るべき対策、万一のときの対応の流れまでを整理しました。取り上げるのは大企業の事例ですが、原因となる設定ミスやアカウント管理の甘さは企業規模を問わず起こるもので、自社の備えを見直す材料としてご活用ください。

実際に起きたクラウドセキュリティの事故・インシデント事例

まず、実際に起きたクラウドセキュリティの事故を3件見ていきます。原因が設定ミス・内部不正・不正アクセスと異なる代表的なケースを選びました。全体像を先に示すと、次のとおりです。

以下で、それぞれの事故について「何が・どれだけ・なぜ起きたのか」を順に詳しく見ていきます。

クラウド環境の設定の誤りによる情報流出（トヨタ自動車・2023年）

トヨタ自動車は2023年5月12日、クラウド環境の設定の誤りにより、同社のコネクティッドサービスを契約した顧客の情報が外部から閲覧できる状態にあったと公表しました。

対象は、2012年1月2日から2023年4月17日までの間にT-ConnectやG-Linkなどを契約した約215万人にのぼります。外部からアクセスできる状態は、2013年11月6日から2023年4月17日までの約10年間続いていました。

外部から閲覧できる可能性があったのは、車載端末ID・車台番号・車両の位置情報・時刻などの情報です。同社は原因について、データの取り扱いルールの説明や徹底が不十分だったことが主な原因だったとの見解を示しています。

クラウド側の設定という、運用のルールひとつで広範囲かつ長期間にわたって情報が露出しうることを示した、設定の誤りを原因とする国内の代表的な事例です。その後も追加の公表が行われ、対象範囲は公表ベースで広がっています。

出典・参考資料（1件）

• 出典：クラウド環境の誤設定によるお客様情報の一部が外部から閲覧できる状態にあったことについて｜トヨタ自動車株式会社（https://global.toyota/jp/newsroom/corporate/39174380.html）

管理者権限を悪用した内部不正による持ち出し（NTT西日本グループ・2023年）

NTTマーケティングアクトProCXとNTTビジネスソリューションズは、業務の運用保守にあたっていた元派遣社員が、システム管理者アカウントを悪用して顧客情報を不正に持ち出していた事案を公表しました。持ち出された情報は、複数の取引先に関わる顧客情報で、顧客数928万件・69のクライアント（取引先）にのぼり、不正は約10年にわたって続いていました。

公表資料では、元派遣社員が業務端末などからサーバーにアクセスし、情報を第三者に流出させていたと説明されています。外部からの攻撃ではなく、正規に与えられた管理者権限を持つ内部の担当者による持ち出しである点が特徴で、特権的なアカウントの管理と操作ログの監視がいかに重要かを示しています。

件数は調査の進展とともに当初の公表値から更新され、最終的に928万件・69のクライアントとされました。同社グループはこの事案を踏まえ、情報セキュリティ強化に向けた取組みを公表しています。

出典・参考資料（1件）

• 出典：お客さま情報の不正持ち出しを踏まえたNTT西日本グループの情報セキュリティ強化に向けた取組みについて｜西日本電信電話株式会社・株式会社NTTマーケティングアクトProCX・NTTビジネスソリューションズ株式会社（https://www.ntt-west.co.jp/news/2402/pdf/240229a_1.pdf）

設定の不備を突いた不正アクセスによる大規模流出（Capital One・2019年）

海外でも、クラウド上の設定の不備が不正アクセスの入口になった大規模な事例があります。米国の金融大手Capital Oneは2019年7月29日、不正アクセスにより米国の約1億人、カナダの約600万人の情報が影響を受けたと公表しました。同社は、攻撃者が自社のインフラにおける特定の設定の脆弱性を悪用したと説明しています。

米国司法省の事件資料によると、侵入は設定を誤ったWebアプリケーションファイアウォール（WAF）を経由してデータへのアクセスを可能にしたものでした。クラウド上に構築したシステムであっても、利用者側が行う設定の不備が、これだけの規模の流出につながりうることを示しています。

ただし、利用していたクラウド基盤の事業者名は一次資料では明示されておらず、報道ベースの情報です。米国司法省は、この不正アクセスを行った人物を訴追しています。

出典・参考資料（2件）

• 出典：Capital One Announces Data Security Incident｜Capital One（https://www.capitalone.com/about/newsroom/capital-one-announces-data-security-incident/）
• 出典：United States v. Paige Thompson｜U.S. Department of Justice（https://www.justice.gov/usao-wdwa/united-states-v-paige-thompson）

事例に共通する原因の型

前章の3つの事例に、一般に多い原因も加えて、クラウドで情報漏えいが起きる原因を型に分けて整理します。自社の環境がどの型のリスクを抱えているかを当てはめて考えられるよう、代表的な5つの型を順に見ていきます。

アクセス権限の設定ミス（クラウド設定の誤り）

社内限定で公開したつもりの領域が外部からアクセスできる状態になっていた、といった設定の誤りは、クラウドで情報漏えいが起きる代表的な原因のひとつです。総務省のガイドラインは、IPAの届出状況をもとに、設定不備が不正アクセスの原因別比率で約17.7%を占め第3位になっていると紹介しています。トヨタ自動車の事例もこの型に当たります。

設定ミスには、誤った値を設定してしまう「誤設定」、必要な設定を行わない「未設定」、環境の変化後に設定を見直していない「未変更」が含まれます。クラウドは設定項目が多く、担当者の確認漏れや引き継ぎ漏れで起こりやすい点に注意が必要です。

出典・参考資料（2件）

• 出典：クラウドサービス利用・提供における適切な設定のためのガイドライン｜総務省（https://www.soumu.go.jp/main_content/000944468.pdf）
• 出典：クラウドの設定ミス対策ガイドブック｜総務省（https://www.soumu.go.jp/main_content/000944467.pdf）

不正アクセス・アカウントの乗っ取り

IDとパスワードだけで守られたアカウントは、使い回したパスワードの流用やフィッシングによって乗っ取られ、不正アクセスの入口になります。クラウドサービスはインターネット経由でどこからでもアクセスできるため、認証を突破されると、社外からでも機密情報に到達されてしまいます。

前章のCapital Oneの事例も、設定の不備が外部からの不正アクセスの入口になったケースです。IDとパスワードだけに頼らず、多要素認証やアクセス制限で認証そのものを強くしておくことが備えになります。

脆弱性の放置・対策の遅れ

利用しているソフトウェアやミドルウェアに既知の脆弱性があるのに修正プログラムの適用が遅れていると、そこを突かれて侵入されます。IPAの「情報セキュリティ10大脅威 2025」でも、システムの脆弱性を突いた攻撃は組織向けの脅威の第3位に挙がっており、クラウド上で動かすアプリケーションやサーバーOSも例外ではありません。

クラウドでは利用者が構築・運用する部分の脆弱性対応は利用者側の責任になります。どのソフトウェアにどの脆弱性があるかを把握し、計画的に修正していく運用が欠かせません。

出典・参考資料（1件）

• 出典：情報セキュリティ10大脅威 2025｜独立行政法人情報処理推進機構（IPA）（https://www.ipa.go.jp/security/10threats/10threats2025.html）

従業員の持ち出し・シャドーIT（内部不正）

外部からの攻撃だけでなく、正規の権限を持つ従業員や委託先による持ち出しも、重大な漏えい原因です。NTT西日本グループの事例では、システム管理者権限を持つ内部の担当者が約10年にわたり情報を持ち出していました。IPAの10大脅威でも、内部不正による情報漏えいは組織向けの第4位に挙がっています。

出典・参考資料（1件）

• 出典：情報セキュリティ10大脅威 2025｜独立行政法人情報処理推進機構（IPA）（https://www.ipa.go.jp/security/10threats/10threats2025.html）

加えて、会社が把握していないクラウドサービスを従業員が業務で使う「シャドーIT」も、管理の目が届かないまま情報が社外に置かれる原因になります。誰がどのファイルを操作・持ち出したかを記録し、特権的な権限ほど厳しく管理することが備えになります。

内部不正は本人の出来心だけでなく、過剰な権限や監視の緩さといった組織側の穴が重なって起こります。なぜ内部不正が起こるのかを人的・組織的な両面から掘り下げて知りたい方は、以下の記事をあわせてご覧ください。

サプライチェーン・第三者サービス経由

自社が直接利用するクラウドだけでなく、委託先や利用しているSaaS、その先の取引先を経由して情報が漏れることもあります。IPAの10大脅威では、サプライチェーンや委託先を狙った攻撃が組織向けの第2位に挙がっており、自社の対策が十分でも、つながっている相手の設定不備や管理の甘さが影響を及ぼすおそれがあります。

出典・参考資料（1件）

• 出典：情報セキュリティ10大脅威 2025｜独立行政法人情報処理推進機構（IPA）（https://www.ipa.go.jp/security/10threats/10threats2025.html）

委託先やSaaSを選ぶ段階でセキュリティの体制を確認し、契約後も定期的に見直すことが、この型への備えになります。

サプライチェーン経由の攻撃には、取引先や委託先、利用するソフトウェアを踏み台にする複数の手口があります。具体的な手口や被害事例、取引先まで含めた対策の立て方を詳しく知りたい方は、以下の記事をあわせてご覧ください。

自社で同じ事故を防ぐための対策

原因の型が分かれば、打つべき対策も見えてきます。前章の型ごとに、自社で真っ先に手を付けたい対策と点検の観点を整理します。前提として、クラウドのセキュリティは、サービスの提供者と利用者が責任を分担する「責任共有モデル」で成り立っており、設定やアクセス管理など利用者が担う範囲の対策は自社で講じる必要があります。

クラウドのセキュリティの確保については、まず、サービスの提供者と利用者とが、責任を分担するという考え方が重要です。このような考え方を『責任共有モデル』と呼びます。

出典：クラウドの設定ミス対策ガイドブック｜総務省

出典・参考資料（2件）

• 出典：クラウドの設定ミス対策ガイドブック｜総務省（https://www.soumu.go.jp/main_content/000944467.pdf）
• 出典：AWS 責任共有モデル｜アマゾン ウェブ サービス（https://docs.aws.amazon.com/ja_jp/whitepapers/latest/introduction-devops-aws/shared-responsibility.html）

アクセス権限の棚卸しと公開設定・最小権限の点検（設定ミスへの備え）

設定の誤りを防ぐには、まず「誰が・どのデータに・どこまでアクセスできるか」を棚卸しし、公開範囲が意図どおりかを確認することが出発点です。業務に必要な最小限の権限だけを与える「最小権限」の考え方を基本に、退職・異動のたびに権限を見直す運用を定着させることが重要です。クラウドは設定項目が多いため、定期的に設定を点検する仕組みをあわせて用意すると、未変更や確認漏れを拾いやすくなります。

多要素認証とアカウント管理の強化（不正アクセス・乗っ取りへの備え）

認証を突破されないためには、IDとパスワードに加えて多要素認証を導入し、パスワードの使い回しに依存しない仕組みにすることが基本です。特に、フィッシングに強いパスキー（FIDO2）などの認証方式や、接続元のIPアドレス・端末・時間帯で制限をかける仕組みは、乗っ取りのリスクを下げます。

複数のクラウドサービスを使っている場合は、ログインとアカウント管理を一元化し、誰がどのサービスにアクセスできるかを統制できる状態にしておくと管理の抜け漏れを防げます。

脆弱性診断とパッチ・アップデート運用の定期化（脆弱性放置への備え）

脆弱性の放置を防ぐには、自社が運用するアプリケーションやサーバーOS、依存するソフトウェアにどの脆弱性があるかを定期的に診断し、修正プログラムを計画的に適用する運用が必要です。クラウドの設定に誤りがないかを継続的に検査する仕組みを組み合わせると、設定ミスと脆弱性の両面を早期に把握できます。手作業での確認が追いつかない場合は、診断を自動化して定期的に回せる形にしておくと見落としを減らせます。

操作ログの可視化・持ち出し制御と従業員教育（内部不正・シャドーITへの備え）

内部不正や持ち出しへの備えとしては、誰がいつどのファイルを操作・持ち出したかを記録し、後から追跡できる状態にしておくことが基本です。USBメモリなどの外部媒体への書き出しを制限し、特権的な管理者権限は付与対象を絞って利用状況を監視することが備えになります。

あわせて、会社が把握していないクラウドサービスの業務利用（シャドーIT）を可視化し、従業員への教育で持ち出しのリスクを周知することが、人に起因するリスクを下げます。

委託先・利用SaaSの選定とリスク評価（サプライチェーンへの備え）

サプライチェーン経由のリスクには、委託先や利用するSaaSを選ぶ段階でセキュリティの体制・認証取得状況を確認し、契約後も定期的に見直すことで備えます。責任共有モデルのもとでは、委託先が行った設定であっても最終的な責任は利用者が負うことになるため、「任せきり」にせず、自社として確認する観点を持つことが重要です。

事故が起きたときの対応の流れ

備えをしていても事故は起こりえます。ここでは、クラウドで情報漏えいなどが起きたときの対応の流れを、初動から報告までの順に整理します。特に個人データの漏えいでは、個人情報保護法で報告と本人への通知が義務づけられている点に注意が必要です。

被害拡大の抑制（初動・封じ込め）

事故を検知したら、まず被害の拡大を止めます。侵害されたアカウントの停止、問題のある公開設定の是正、影響範囲のネットワークからの切り離しなど、これ以上情報が流出しないための封じ込めを最優先で行うことが重要です。このとき、後の調査のために、原因につながるログやデータを消さないよう保全を意識することも重要です。

インシデントの特定（影響範囲・原因の切り分け）

封じ込めと並行して、何が・どれだけ・どの経路で漏れた可能性があるのかの切り分けが必要です。対象となったデータの種類と件数、原因が設定ミスなのか不正アクセスなのか内部不正なのかを把握することで、この後の報告・通知の要否や範囲が決まります。

通知・報告（個人情報保護法の報告義務・本人通知）

個人データの漏えい等が発生した場合、一定の要件に当てはまるときは、個人情報保護委員会への報告と本人への通知が義務づけられています。個人情報保護委員会のガイドラインは、報告が必要な事態として、要配慮個人情報が含まれる場合、財産的被害が生じるおそれがある場合、不正の目的によるおそれがある場合、本人の数が1,000人を超える場合の4類型を挙げています。

報告は、まず速報を速やかに行い、続けて確報を提出する2段階です。ガイドラインは期限の目安を次のように定めています。

個人情報取扱事業者は、報告対象事態を知ったときは、速やかに、個人情報保護委員会に報告しなければならない。

「速やか」の日数の目安については、個別の事案によるものの、個人情報取扱事業者が当該事態を知った時点から概ね3～5日以内である。

前項の場合において、個人情報取扱事業者は、当該事態を知った日から30日以内（当該事態が前条第3号に定めるものである場合にあっては、60日以内）に、当該事態に関する前項各号に定める事項を報告しなければならない。

出典：個人情報の保護に関する法律についてのガイドライン（通則編）｜個人情報保護委員会

引用中の「前条第3号に定めるもの」とは、不正の目的によるおそれがある事態を指します。確報の期限は通常30日以内ですが、この事態に当たる場合は60日以内に延長されます。

本人への通知も、事態の状況に応じて速やかに行う必要があり、通知が難しい場合は、ホームページでの公表や問い合わせ窓口の設置といった代替措置が認められています。自社の事故がどの類型に当たるか、どの期限が適用されるかは、必ず最新のガイドラインの原文で確認してください。

出典・参考資料（1件）

• 出典：個人情報の保護に関する法律についてのガイドライン（通則編）｜個人情報保護委員会（https://www.ppc.go.jp/files/pdf/temp260614_guidelines01.pdf）

フォレンジック調査（ログ取得・保全）

原因と影響範囲を正確に突き止めるには、操作ログやアクセスログ、仮想マシンの状態などの証跡をもとにした調査（フォレンジック調査）が必要になります。クラウドでは、調査に使えるログを平時から取得・保存する設定にしておかないと、事故後に必要な記録が残っていないことがあります。自社で対応が難しい場合は、専門の調査会社に委託することも選択肢になります。

ここでは対応の流れの全体像を整理しましたが、初動で避けるべきことや報告の期限まで、手順を一つずつ追って確認したい場合は、以下の記事で詳しく解説しています。

事例の原因に対応する対策ソリューション

前章の対策は、権限の棚卸しや運用ルールの徹底など、まず自社で取り組めることが土台です。そのうえで、手作業では追いきれない部分を支えるのが対策ソリューションです。ここでは、ログインとアクセスを統制するID基盤、クラウドの設定の誤りや脆弱性を検査するツール、PCの操作ログを記録するサービスを、それぞれが対応する原因の型とあわせて紹介します。

各サービスの概要は次の比較表のとおりです。「対応する原因の型」の列から、自社が抱えるリスクの型に近いものを選ぶ目安になります。

※料金は2026年11月時点の各社公式情報によります。

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

CloudGate UNOは、株式会社インターナショナルシステムリサーチが自社開発する国産のID基盤（IDaaS）です。一度の認証で複数のクラウドサービスへアクセスできるシングルサインオンに、多要素認証やパスキー（FIDO2）によるパスワードレス認証、アクセス制限を組み合わせて提供します。不正アクセスやアカウントの乗っ取りを防ぐ認証の強化とアクセスの統制を担うサービスです。

フィッシングに強いパスキーのパスワードレス認証を全プランで利用でき、IPアドレス・端末・場所・時間帯といった軸で細かくアクセスを制限できる点が特徴です。入社・異動・退職に合わせてアカウントを作成・変更・削除するプロビジョニングも標準で備わっており、複数のクラウドを使う環境でログインとアカウント管理を一元化できます。

月額料金はStandard Plusが1ユーザーあたり400円（税抜）からで、30日間の無料体験が用意されています（2026年11月時点の公式情報による）。

多要素認証といっても、認証方式によって突破されにくさは異なります。この点について、提供元の株式会社インターナショナルシステムリサーチの平澤氏は、独自インタビューで次のように述べています。

2. Aikido Security（株式会社AndGo）

Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリを1つの管理画面で検査するオールインワンの脆弱性診断SaaSです。日本では株式会社AndGoが販売と日本語サポートの窓口を担っています。クラウド設定の誤りを検査するCSPM（AWS・Azure・GCPなどに対応）を含み、設定ミスと脆弱性の放置の両方をカバーできる点が強みです。

人が診断して報告書を納める受託型ではなく、自動スキャンを継続的に回せる契約形態のため、設定の誤りや脆弱性を定期的に検査する運用に向いています。

バラバラに出るアラートを統一して対応すべきものを絞り込めるほか、修正案のドラフトを作成してプルリクエストまで出せる機能も備えます。料金は月額のサブスクリプション型で、日本窓口では月額5万円台からが目安です（年間契約・利用者10人までの場合）。無料で試せるプランもあります（2026年11月時点の公式情報による。為替などにより変動するため、正式な料金は提供元への確認が必要です）。

開発や運用の現場でセキュリティをどう扱うかは、近年変化しています。この変化について、日本窓口を務める株式会社AndGoの原氏は、独自インタビューで次のように述べています。

3. Eye”247″ Work Smart Cloud（株式会社フーバーブレイン）

Eye”247″ Work Smart Cloudは、株式会社フーバーブレインが提供する、PCの操作ログを記録・可視化するクラウド型サービスです。「誰が・いつ・どこで・何を操作したか」を記録し、ファイル操作やUSBなど外部媒体への書き出し、Webアクセスの履歴まで把握できます。従業員の持ち出しや内部不正といった、人に起因するリスクの可視化・抑止に役立つサービスです。

指定した拡張子のファイル操作や、個人情報を含むファイルの扱いも記録でき、USBの使用制限や印刷制限といったデバイス制御も行えます。初期費用は無料で、月額は契約台数に応じた1台あたりの従量制（100台以上で1台あたり月額400円から、税別）です。14日間の無料トライアルが用意されています（2026年11月時点の公式情報による）。

ここで取り上げたのは、原因の型に対応する代表的な3つのソリューションです。認証やアクセスの統制から設定・脆弱性の検査、操作ログの管理まで、守る対象ごとにどんなタイプのサービスがあり、どう選べばよいかまで含めて比較検討したい方は、以下の記事もあわせてご覧ください。

まとめ

クラウドセキュリティの事故は、アクセス権限の設定ミス、不正アクセスやアカウントの乗っ取り、脆弱性の放置、従業員の持ち出し、サプライチェーン経由といった、どの企業にも起こりうる共通の原因の型に当てはまります。トヨタ自動車やNTT西日本グループ、Capital Oneの事例が示すように、設定ひとつ、権限ひとつの管理が、広範囲かつ長期間の漏えいにつながります。

まずは自社のアクセス権限と公開設定を棚卸しし、認証の強化・設定と脆弱性の定期検査・操作ログの可視化・委託先の確認という観点で備えを見直すことが出発点になります。あわせて、万一のときの通知・報告の義務も平時から押さえておくと、いざというときに慌てずに対応できます。対策を具体的に進める際は、原因の型に対応するソリューションの資料を取り寄せて比較検討してみてください。

よくある質問（FAQ）

Q. クラウドセキュリティの事故とは何ですか？

A. クラウドセキュリティの事故とは、クラウドサービス上の設定の誤りや不正アクセス、内部不正などによって、保管している情報が外部に漏えいしたり不正に持ち出されたりする出来事です。

本記事で紹介したトヨタ自動車（設定の誤り）、NTT西日本グループ（管理者権限を悪用した内部不正）、Capital One（設定の不備を突いた不正アクセス）のように直接の原因はさまざまですが、いずれもクラウド上の設定やアカウントの管理に起因している点が共通しています。

Q. クラウドセキュリティの事故は大企業だけで起きるのですか？

A. クラウドセキュリティの事故は、特定の業種や大企業だけでなく、クラウドを業務に使うどの企業でも起こりうるものです。原因の多くは、アクセス権限の設定ミス、アカウントの乗っ取り、委託先・従業員による持ち出しといった、企業規模を問わず起こりうる共通の型に当てはまります。まずは実際にどんな事故がなぜ起きたのかを知ることが、自社の備えを考える出発点になります。

Q. クラウドで情報漏えいが起きる主な原因にはどのようなものがありますか？

A. クラウドの情報漏えいは、アクセス権限の設定ミス、不正アクセス・アカウントの乗っ取り、脆弱性の放置、従業員の持ち出しなどの内部不正、サプライチェーン経由の5つの型に大きく分けられます。なかでもアクセス権限の設定ミスは、公的なガイドラインでも代表的な原因として挙げられています。それぞれの型の中身と型ごとの対策は、本文で詳しく解説しています。

Q. クラウドセキュリティの事故は、クラウド事業者と利用者のどちらの責任で起きるのですか？

A. クラウドのセキュリティは、サービスの提供者と利用者が責任を分担する「責任共有モデル」で成り立っており、設定やアクセス管理など利用者が担う範囲の対策は自社で講じる必要があります。委託先が行った設定であっても最終的な責任は利用者が負うことになるため、委託先やSaaSに「任せきり」にせず、自社として確認する観点を持つことが重要です。

Q. クラウドセキュリティの事故を防ぐために、自社でまず何から始めればよいですか？

A. まず「誰が・どのデータに・どこまでアクセスできるか」というアクセス権限と公開設定の棚卸しから始め、業務に必要な最小限の権限だけを与える「最小権限」を基本にすることが出発点です。そのうえで、多要素認証による認証の強化、クラウド設定と脆弱性の定期検査、操作ログの可視化・持ち出し制御、委託先・利用SaaSの確認という観点で、原因の型ごとに備えを見直していきます。

Q. クラウドで個人データが漏えいした場合、個人情報保護委員会への報告は必要ですか？

A. 個人データの漏えい等が発生し一定の要件に当てはまる場合は、個人情報保護委員会への報告と本人への通知が義務づけられています。

個人情報保護委員会のガイドラインは、報告が必要な事態として、要配慮個人情報が含まれる場合、財産的被害が生じるおそれがある場合、不正の目的によるおそれがある場合、本人の数が1,000人を超える場合の4類型を挙げています。自社の事故がどの類型に当たるかは、最新のガイドラインの原文で確認してください。

出典・参考資料（1件）

• 出典：個人情報の保護に関する法律についてのガイドライン（通則編）｜個人情報保護委員会（https://www.ppc.go.jp/files/pdf/temp260614_guidelines01.pdf）

Q. クラウド事故の漏えい報告は、いつまでに行う必要がありますか？

A. 報告は速報と確報の2段階で行い、速報は事態を知った時点から概ね3〜5日以内、確報は知った日から30日以内（不正の目的によるおそれがある事態の場合は60日以内）が目安とされています。

本人への通知も事態の状況に応じて速やかに行う必要があり、通知が難しい場合は、ホームページでの公表や問い合わせ窓口の設置といった代替措置が認められています。適用される期限は必ず最新のガイドラインの原文で確認してください。

Q. クラウドセキュリティの対策はどんなツールで実現できますか？

A. 事例の原因の型ごとに対応するソリューションがあり、不正アクセス・乗っ取りにはログインとアクセスを統制するID基盤（IDaaS）、設定ミスや脆弱性にはクラウド設定や脆弱性を検査するツール（CSPMを含む脆弱性診断）、内部不正にはPCの操作ログを記録するサービスが代表的です。

本記事では、これらに対応するソリューションとしてCloudGate UNO・Aikido Security・Eye”247″ Work Smart Cloudを紹介しています。自社が抱えるリスクの型に合わせて、複数のサービスの資料を取り寄せて比較検討してください。

社内セキュリティソリューションの料金・資料を一括チェック

MCB FinTechカタログでは、クラウドの認証強化・設定や脆弱性の検査・操作ログ管理など、社内セキュリティソリューションの最新資料を無料で一括請求できます。原因の型に合わせて複数のサービスをまとめて比べられます。

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

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