IT & Information security Journal
さくらインターネット株式会社は8月17日、同社が展開するレンタルサーバーサービス「さくらのレンタルサーバ」の一部顧客環境に対し、第三者による不正なアクセスとログインを確認したと発表しました 1。不正ログインの対象は583アカウントで、一部のサーバーにマルウェアが設置されていたこと、顧客領域内に保存された情報を第三者が閲覧または取得した可能性があることなどを伝えています。
その2日後の第二報では、同社が顧客の契約情報等を管理するために運用する「販売管理システム」への不正アクセスの可能性も発表 2。さくらのレンタルサーバに対する不正アクセスの調査過程で確認されたといい、対象となる可能性のある会員情報は最大約136万アカウントとしています。
本件のような事案が発生した場合、サービスの利用企業にはどのような法的責任が生じ、どう対応すべきか。事案のポイントや、クラウド例外と委託との区別、利用するクラウドサービスへの不正アクセスや情報漏えいが発覚した際の対応、平時からの備えなどを弁護士法人三宅法律事務所 渡邉 雅之弁護士に聞きました。
この記事のポイント
クラウドサービス事業者側で発生した情報漏えい等であっても、利用企業が自ら負う法令上の義務が当然に免除されるわけではない
「クラウド例外」は限定的な概念であり、契約やアクセス制御の実態が伴わなければ「委託」と判断され、委託先の監督義務が生じ得る
クラウド例外に該当する場合でも、利用企業の安全管理措置義務は残り、報告対象事態では利用企業が報告・本人通知の主体となる
ガバメントクラウドへの採択や第三者認証の取得状況などは、サービス選定における重要材料になり得ても、利用企業として行うべきリスク評価の代替にはならない
本件について、法的な観点からは利用企業はどのような点に注意すべきでしょうか。
本件は現在も調査が続いており、侵入経路や実際に取得された情報、影響範囲などは変わり得ますので、2026年9月2日時点で公表されている情報を前提とした一般論として説明します。まず、個人情報保護法上の観点では、本件で重要な点は2つです。
1点目は、クラウドサービス事業者で事故が起きても「クラウドサービス事業者の問題だから利用企業は関係ない」とはならないということです。クラウドへデータを預けることはできますが、クラウドサービス事業者に法令上の責任まで移転するわけではありません。
2点目は、「クラウドサービス事業者が個人データを取り扱わないこととなっている場合には、利用企業からクラウドサービス事業者への個人データの提供に該当せず、利用企業による委託先の監督も不要」とされる「クラウド例外3」という考え方があることと、そのうえで、実際にこの考え方が適用される場面がかなり限定的であるということです。
第一報のさくらのレンタルサーバ上の顧客環境に対する不正アクセスと、第二報の同社販売管理システムへの不正アクセスについては、性質が異なる事案と捉えるべきでしょうか。
法的には、第二報で明かされた販売管理システムへの不正アクセス事案と、第一報のさくらのレンタルサーバへの不正アクセス事案とは分けて考える必要があります。
第二報の販売管理システムの事案は、さくらインターネット自身が顧客管理のために保有している会員情報の漏えいであり、個人情報保護法上の個人データの問題に該当します。これに対して、第一報のさくらのレンタルサーバ事案は、利用企業が自らの顧客領域に保存しているデータとさくらインターネットとの関係について、クラウド例外が適用されるのか、あるいは「個人データの取扱いの委託」と捉えるかの問題が生じます。
第一報のさくらのレンタルサーバ事案でポイントとなる、クラウド例外にあたるか、委託にあたるかはどのように判断されますか。
クラウド例外は、「クラウドサービスの利用＝クラウド例外」という考え方ではありません。契約面だけでなく実態としても、クラウドサービス事業者が個人データを取り扱わないことが担保される必要があります。
クラウド例外に該当する場合の例としては、①クラウドサービス事業者が保存された個人データを取り扱わないと契約で定められていること、②適切なアクセス制御が行われていることという2点があげられています。つまり、こうした事情が認められれば、一般のレンタル倉庫のように、場所を貸しているだけだと捉えられるということです。
クラウド例外の考え方について、参考となる過去の事例はありますか。
クラウド例外の考え方は、2024年に個人情報保護委員会が行政指導を行った「エムケイシステム事案」が参考になります。これは、株式会社エムケイシステムが提供する社会保険労務士（社労士）向けのクラウドサービス「社労夢」が、ランサムウェアを用いた不正アクセスを受けたという事案です。
不正アクセス後の調査で、同社は「利用規約や保守運用および技術上、必要な場合にデータを監視・分析・調査できる」「保守用のIDを使い、顧客の個人データにアクセスできる」状態であったことが確認されました。また、実際に顧客からの調査支援要請に応じて個人データを取り扱った実績も確認されました。
個人情報保護委員会はこれらの実態を踏まえ、エムケイシステムと利用企業との関係について、クラウド例外の要件である「個人データを取り扱わない」状態にはあたらず、「利用企業からエムケイシステムへの個人データの取扱いの委託」に該当すると判断しています。さらに、クラウドサービスの利用が個人データの取扱いの委託に該当する場合、委託元が個人情報保護法で定められた委託先監督義務 4を負うことも注意喚起しています。
本件の場合、第一報のさくらのレンタルサーバ事案がクラウド例外に該当するかどうかは、現時点の公開・公表情報だけでは判断できません。個人情報保護委員会はエムケイシステム事案において、利用規約・契約内容に加えて実態まで把握したうえで、クラウド例外に該当しないと判断しました。本件でも、クラウド例外にあたるかを判断するためには、保守・障害対応時のアクセス権限の扱いや、個人データ取得を防止するアクセス制御の有無、実際の運用などの確認が必要でしょう。繰り返しになりますが、クラウド例外はクラウドサービス一般において適用される広い考え方ではありません。「普段はデータを見ていない」だけでは足りず、「保守・障害対応まで含め、クラウドサービス事業者が個人データを取り扱わない」状態である必要があります。なお、保守作業中に個人データが閲覧可能となるだけでただちに委託に該当するわけではなく、個人データの取得を防止する措置が講じられているかなど、具体的な運用も踏まえて判断されます。
一方で、攻撃者がさくらインターネットの管理環境を経由して顧客環境に到達したという本件の攻撃経路のみから、ただちにクラウド例外が否定されるわけでもありません。あくまで、平時において、クラウドサービス事業者自身が契約上、実態上、個人データを取り扱うこととなっているかが問われ、個人データを取り扱っていないこと、アクセスが適切に制御されていることなどが必要となります。
仮にクラウド例外に該当する場合、クラウドサービスの利用企業にはどのような義務が生じますか。
クラウド例外は、クラウドサービス事業者に責任を任せられるという考え方ではありません。むしろ、クラウドサービス事業者が個人データを取り扱わないからこそ、利用企業自身が報告主体となります。
もし、さくらのレンタルサーバ事案がクラウド例外に該当する場合、利用企業には委託先の監督義務はありません。しかし、利用企業自身には、法令に基づく安全管理措置義務があります 5。その個人データについて個人情報保護法26条の報告対象事態が生じた場合には、個人情報保護委員会への報告と、本人への通知が義務となります。
この際、クラウド上の個人データといえども、報告対象となる漏えい等が発生した場合の報告義務は利用企業にあり、さくらインターネットにはありません。また、この報告をクラウドサービス事業者に代行させることはできますが、義務の主体はあくまで利用企業です。
なお、クラウド例外には該当しない場合、つまり、本件の契約上の文言やさくらのレンタルサーバの実態から、さくらインターネットが個人データを取り扱うこととなっていると判断された場合を補足しましょう。その場合、利用企業がクラウドサービス事業者であるさくらインターネットへ「個人データの取扱いを委託した」と整理されます。
委託に該当する場合、利用企業には委託先の適切な選定や、適切な委託契約、委託先における個人データの取扱い状況の把握といった監督が求められ、委託先で報告対象となる漏えいなどが発生すると、原則として委託元・委託先の双方が報告主体となり得ます。ただし委託先は、委託元へ所定の通知を行うことで、自らの報告義務を免れる仕組みがあります。
クラウドサービス事業者側で発生した事故であることを理由に、利用企業の個人情報保護法上の義務が軽くなることはありますか。
クラウドサービス事業者側の事故であっても、それだけで利用企業自身の個人情報保護法上の義務が免除・軽減されるわけではありません。事故原因がクラウドサービス事業者側にあることと、利用企業が自らの法令上の義務を負うかどうかは別の問題です。
先述のエムケイシステム事案がまさにそうで、クラウドサービス事業者のセキュリティ事故であっても、委託であれば委託先の監督義務を、クラウド例外であれば自らの安全管理措置義務を、利用企業が負います。個人データの漏えい等の報告対象事態が発生したのであれば、利用企業自身が個人情報保護委員会への報告と本人通知をそれぞれ検討する必要があります。
利用企業の顧客等に実際の損害が生じた場合、利用企業とクラウドサービス事業者の損害賠償責任はどのように整理されますか。
ここは、個人情報保護法上の義務主体と、民事上の最終的な損害負担を分けて考える必要があります。クラウド例外は、個人情報保護法上、個人データの「提供」や「委託」にあたるかを整理する考え方であり、クラウドサービス事業者を民事上免責するものではありません。
たとえば、利用企業の顧客等に損害が生じた場合でも、漏えい等が発生したことだけで当然に損害賠償責任が成立するわけではありません。利用企業に安全管理措置義務違反等の過失があり、その過失と損害との間に因果関係が認められれば、利用企業が本人に対して損害賠償責任を負う可能性があります。一方、事故原因についてクラウドサービス事業者側に契約上の義務違反や過失が認められる場合には、利用企業からクラウドサービス事業者に対する債務不履行・不法行為に基づく損害賠償請求等が問題となり得ます。その際は、利用規約・約款・SLAにおける責任制限・免責条項の内容や有効性・適用範囲も重要です。
また、クラウドサービス事業者自身の過失と本人の損害との間に因果関係が認められるなど、不法行為の要件を満たす場合には、本人からクラウドサービス事業者への直接請求が問題となる可能性もあります。利用企業とクラウドサービス事業者の双方の行為が損害に寄与している場合には、共同不法行為等の成否も個別に検討されます。したがって、「本人に対する法令上の対応主体」と「利用企業とクラウドサービス事業者の間で最終的に誰がどの程度損害を負担するか」は別の問題として整理する必要があります。
本件のような不正アクセスが発覚した場合、利用企業として報告・通知の対応はどのように判断すべきでしょうか。
不正の目的をもって行われたおそれのある行為による個人データの漏えい等、またはそのおそれがあった場合は、個人データに係る本人の数が1000人を超えるかどうかという基準が適用されず、本人の数が1人でも対象になり得ます 6。その際、速報は、ガイドラインの目安でおおむね3～5日以内に、その時点で把握している内容の報告が求められます。また、確報は原則30日以内、不正の目的をもって行われたおそれがある行為による漏えい等の場合は60日以内に行わなければなりません 7。
この際、利用企業としては、クラウドサービス事業者の最終調査結果が出るまで何もしないこと、つまり、さくらインターネットからすべての情報が共有されるまで待つことは非常に危険です。自社の個人データについて報告対象事態が生じた、または生じたおそれがあると認識した場合、最終的なフォレンジック結果を待つのではなく、速やかに速報対応を進める必要があります。速報はその時点でわかっている範囲で行えばよく、まだ分からないことは「調査中」としておけばよいでしょう。
なお、報告期限の起算については、さくらインターネットが公表したリリースや、報道等を見ただけで、すべての利用企業について一律にただちに起算するものとは判断されません。起算点はあくまで利用企業が自社の報告対象事態を知った時点です。本件の場合は、8月17日や19日とは限りません。法人の場合、いずれかの部署の従業者が報告対象事態を知った時点で「部署が知った」と扱われ得ます。
クラウドサービス事業者から十分な情報が届かない場合、利用企業はどう動くべきでしょうか。
まず、自社で取得できる証跡を確保しましょう。たとえばFTP（File Transfer Protocol）やSSH（Secure Shell）、管理画面のログイン履歴、ファイルのタイムスタンプ、不審な管理者アカウント、メール送信履歴、ウェブサイトの変更などです。次に、認証情報を変更します。同じパスワードを他のサービスで使い回している場合には、そちらも変更しましょう。
その後、クラウドサービス事業者に対する具体的な照会に移ります。自社が対象かどうかや、アクセス可能だった期間、どの領域まで到達した可能性があるか、閲覧・取得・改ざんの痕跡、認証情報への影響などを確認します。この際、いつまでに、何を、どの粒度で知らせてもらえるかが重要ですので、クラウドサービス契約では事故時の対応を特に重視すべきといえます。重要なシステムでは平時から、インシデント時の通知期限や情報提供範囲、連絡ルートなどを確認しておくべきです。約款型のサービスでは個別交渉が難しい場合もありますが、その際は重要データを別のサービスに置くなど、サービス選定そのものがリスク管理といえるでしょう。
レンタルサーバーを利用している企業によっては、「自社は重要なデータを預けていない」と考える可能性もあると思われますが、この認識に危険な点はあるでしょうか。
まず、企業が考える重要データと攻撃者にとって価値のあるデータは、一致するとは限りません。そして、担当者が「置いていない」と思っているデータがサーバーに残っていることもあります。
レンタルサーバーで最初に見てほしいデータは、メールです。問い合わせや採用応募、請求書、他サービスのパスワードリセットメールなど、かなりの個人情報が蓄積されている可能性があります。
次にウェブフォームです。WordPressなどでは、問い合わせ内容がデータベースやプラグイン内に残っている場合があります。さらに、CMSのデータベース、古いバックアップなども確認しましょう。セキュリティ上さらに怖いのが.envや設定ファイルに入っているAPIキー、データベースの接続情報、他サービスの認証情報です。これらを足掛かりに別システムへ横展開される危険性があります。
また、メールアカウントを奪われると、なりすましやビジネスメール詐欺にもつながります。ウェブサイトやドメインを悪用されれば、自社は被害者であるだけでなく、フィッシング等の踏み台にもなり得ます。
本件のような事態の発生に備えて、利用企業が取っておくべき対応はありますか。
本件のさくらインターネットのように、1つの事業者がレンタルサーバー、VPS、クラウド、GPUインフラ、その他のサービスを幅広く提供している場合、利用企業は「当社はさくらインターネットを使っている」と把握しているだけでは、十分ではありません。どのサービスを何の目的で利用し、そこに何のデータを保存しているかを、サービス単位で把握する必要があります。
たとえば今回、さくらのレンタルサーバとさくらのクラウドでは、影響状況が異なります。ベンダー単位の台帳ではなく、サービス単位・データ単位でクラウド資産を把握する必要があるということも、大きな教訓といえるでしょう。
契約主体が自社以外の場合も注意が必要です。制作会社やウェブ制作会社がサーバー契約の主体となっている場合、インシデント通知が利用企業である自社には直接来ない、という構造になっていることもあります。自社の顧客情報を置いているサーバーなのに、事故通知の宛先が制作会社の担当者だけというケースもあります。平時から、契約者は誰か、事故通知は誰に届くのか、制作会社に届く場合は何時間以内に自社へ連絡が来るのかまで、確認しておく必要があります。
なお、第二報の販売管理システムへの不正アクセスは、さくらのレンタルサーバへの不正アクセスを検知した8月9日より前に発生した事象とされています。こうした侵害の時系列を明らかにするうえでは、何か月前まで遡って調査できるかなど、ログ保存の方針も重要です。侵害が数か月前から始まっていた場合、ログが30日しかなければ、後から調べられない可能性があります。
加えて、自社が調査して「当社は報告対象ではない」と判断した場合でも、何を確認し、どの事実に基づいて対象外と判断したかを判断記録として残しておくことをお勧めします。後日、個人情報保護委員会や顧客、取引先、それから経営陣などに、判断経緯を説明する際、極めて重要な情報になり得ます。
本件の発表内容には「通信の秘密」への言及もありました。このことは、クラウドサービス事業者と利用企業の実務にどのような影響を及ぼすでしょうか。
第一報に「攻撃者がお客様情報および通信の秘密に該当する情報へアクセス可能な状態であった」と明記されていますが、個人情報保護法とは別に、電気通信事業法上の問題を意識した記載と考えられます。さくらインターネットは電気通信事業者であるため、通信の秘密 8を保護する義務があります。通信の秘密には、通信内容だけでなく、通信当事者、通信日時、場所等の通信の構成要素・外形的事実も含まれ得ます。これらの漏えいが生じた場合、総務大臣への事故報告の対象となります 9。また、通信の秘密の漏えいを知った後は、速やかな報告に加え、知った日から30日以内の詳細報告が必要となります 10。
他方、電気通信事業法では通信の秘密侵害罪が規定されていますが、これは通信の秘密を侵した主体を処罰する規定であるため、漏えいした事実のみをもってさくらインターネットがただちに処罰されることはありません11。具体的な刑事責任については、誰がどのような態様で通信の秘密を知得・窃用・漏えいしたのか、故意の有無等を個別に検討する必要があります。
クラウドサービス事業者の実務としては、この漏えいが生じた場合の総務大臣への事故報告に加えて、調査結果次第では、法令の「通信の秘密の確保に支障があるとき」に該当するかが問題となり、業務改善命令の要否が問題となり得ます 12。サイバー攻撃を受けたという事実だけでただちに業務改善命令とはなりませんが、その後明らかになる管理体制、業務方法などを踏まえた評価となります。
さくらインターネットの利用企業という観点から見ると、サービスを利用しているだけで、利用企業が総務大臣への事故報告義務を負うことにはなりません。本件の場合、利用企業はまず、個人情報保護法上の対応、自社システムの確保・確認、顧客対応などを考えればよいでしょう。
ただし、利用企業自身が提供するウェブサービスやアプリなどを通じて電気通信事業を営んでいる場合は別です。また、登録・届出が適用除外となる第三号事業者 13にも同条3項により、電気通信事業法4条の通信の秘密に関する規定は適用されます。届出不要だから通信の秘密も関係ないという理解は誤りです。
最後に、本件から企業が得るべき教訓を教えてください。
今回の一連の事案は、さくらインターネットという1企業の事故として見るだけでは少しもったいないと考えます。本件では、さくらインターネットという会社の現在の位置づけも重要なポイントといえます。
さくらインターネットは、昔からあるレンタルサーバー事業者というイメージを持つ方も多いでしょう。実際のところ、現在も代表取締役社長を務める田中邦裕氏が1996年に、工業高等専門学校への在学中に始めたレンタルサーバー事業が出発点です。現在は東証プライム上場企業で、自社のデータセンターを基盤として、クラウド・レンタルサーバー・VPSに加えて、生成AI向けのGPUインフラにも大規模投資を行っています。
同社を語るうえで特に重要な点の1つとして、同社のパブリッククラウドサービス「さくらのクラウド」が、2026年3月にガバメントクラウドの対象サービスとして正式採択されたことがあげられます。「Amazon Web Services（AWS）」「Google Cloud」「Microsoft Azure」「Oracle Cloud Infrastructure（OCI）」といった海外の巨大クラウドサービス事業者が並ぶなか、国産事業者として唯一の選択肢として加わり、日本の政府の政策的にも非常に大きな意味があります。現在のさくらインターネットは単なるレンタルサーバー会社ではなく、日本の行政DX、データ主権、さらに生成AIの計算基盤まで含めた、国産デジタルインフラの一翼を担う会社と位置づけた方が実態に近く、国が求める高度な技術要件を同サービスが満たしたという意味でも重要です。さくらインターネット自体が、国や自治体の重要なインフラを担う国産クラウドサービス事業者で、インシデント発生時の調査能力、利用者への情報提供、再発防止・説明責任について、社会的に高い水準が期待される会社であることは間違いありません。
今回の事案は、ガバメントクラウドそのものへの侵害を公表しているわけではありません。第一報では「さくらのクラウド」への影響は確認されていないとされ、第二報では販売管理システムは「さくらのクラウド」をはじめとする各サービスの提供環境とは別のシステムと説明されています。したがって、本件はいわゆる「ガバメントクラウドへのサイバー攻撃」と表現するのは正確ではなく、本件をもってただちに「国産クラウドは危険だ」という話にするのも適切ではないでしょう。
一方、利用企業としては、政府が採択したサービスだからといって、自社では安全性を何も確認しなくてよいというわけではありません。ガバメントクラウドへの採択やISMAPへの登録、ISOなどによる第三者認証は、サービス選定の重要な材料にはなり得ます。しかし、本件から得られる一般的な教訓として、そうした各種材料は、利用企業自身の個人情報保護法上の安全管理措置や委託先監督の代替にはならないといえるでしょう。端的にいえば、政府による採択や第三者認証などは、利用企業自身のリスク評価を代替するものではないということです。
むしろ重要な点は、どれほど大手で社会的な意義のある事業者であっても、サイバーインシデントは起こりうるということです。そしてクラウドサービス事業者への信頼は、事故を1件も起こさないというだけでなく、事故をどれだけ早く把握し、影響範囲を調査し、利用企業が自らの法的義務を果たすために必要な情報を迅速に提供できるかによっても測られます。
利用企業側は、さくらインターネットが大手だからとか、政府が採択しているから、ということで導入時等の評価を終わらせることなく、どのサービスにどのデータを置いているのか、事業者はそのデータにアクセスできるのか、事故があった時に誰から何時間・何日以内にどの情報を受け取れるのか、誰が報告判断するのかなどを確認・把握しておくべきでしょう。クラウドにデータを預けることはできても、クラウドサービス事業者にガバナンスまで預けることはできないといえます。
この記事は会員限定です。
登録すると続きをお読みいただけます。
このサイトはreCAPTCHAによって保護されており、
Googleの
プライバシーポリシー
と
利用規約
が適用されます。
UNITISは、IT・セキュリティ担当者へ、実務家・専門家による解説や他社事例等を伝えるメディアです。セキュリティ・法律の専門家による実務解説や分析、第一線の実務家による事例・ノウハウをお届けします。
この記事をシェアする
最新情報をフォローする