「クラウドだから安全」は半分だけ正しい——自社に残る責任の境界線

「クラウドに移したので、バックアップはもう心配ないですよね」——情報システムを社外に預けた経営者から、こういう言葉をよく聞きます。移行プロジェクトが終わって自社のサーバー室が空になった日の、あの安堵はよくわかります。長く悩まされてきた機器の故障も、休日に呼び出される電源工事も、もう自分たちの担当ではなくなるのですから。

この安堵は、半分だけ正しい。クラウドに移したことで、確かに守られるようになった部分があります。建物の耐震性、電源や回線の二重化、大規模な攻撃を受け止める基盤の強さ。自社で同じ水準を用意するのは、技術の面でも人手の面でも現実的ではありませんでした。そこがまとめて事業者側へ移ったのは、率直に言って大きな前進です。

一方で、その建物の中に何を置き、誰に鍵を渡し、どの部屋の扉を開けたままにするかは、移行の前も後も自社の仕事のままです。

誤解が生まれる背景には、「クラウド」という言葉が指す範囲の広さがあります。業務用のアプリケーションをそのまま使う場合と、システムを組み上げるための基盤だけを借りる場合とでは、事業者が守ってくれる範囲がまるで違う。それなのに、どちらも同じ一語で呼ばれます。自社がどちらの形で使っているのかを意識しないまま、「クラウドだから大丈夫」という一括りの安心に流れてしまうのは、そのためです。以下では、契約書の細かい条項ではなく、実務で判断できる形に落として整理します。

責任は「建物」と「中身」で分かれている

境界線は、建物と中身のあいだに引かれています。事業者が担っているのは建物と土台の部分です。データセンターの物理的な守り、電源や回線の冗長化、サーバーやネットワーク機器そのものの保守、大規模な攻撃を受け止める基盤の強さ。クラウドに移す最大の利点は、ここをまとめて任せられることにあります。

その建物の中身は、借りている側の判断です。クラウド事業者は、利用者が設定した公開範囲や権限を、利用者の意図として尊重します。ある資料を「社外からも見える設定」にしたのが利用者自身であれば、それがどれほど不本意な結果であっても、事業者から見れば指示どおりに動いただけということになります。守りが破られたのではなく、利用者が扉を開けたまま気づかなかった。事故のあとに残る説明としては、こちらのほうが圧倒的に多いのです。

自社でサーバーを持っていた時代は、建物の守りも中身の守りも、すべてが自社の担当範囲でした。範囲は広い代わりに、どこまでが自分たちの責任かで迷うことはありません。クラウドに移すと建物の部分が事業者へ移り、担当範囲は狭くなります。ところが多くの現場では、範囲が狭くなったことを「責任そのものが軽くなった」と読み違えてしまう。狭くなった分、そこに残った一つひとつの判断——誰に管理者権限を渡すか、どのフォルダを共有可にするか——の重みは、むしろ増しています。

利用形態を3段階で見ると、線引きが動く

境界線の位置は、クラウドをどう使うかによって変わります。業務用のアプリケーションをそのまま利用する形、基盤だけを借りて自社でシステムを組み上げる形、その中間にあたる形。事業者が担う範囲は、右へいくほど狭くなります。

どの形を選んでも、「自社に残る範囲」が空欄になることはありません。基盤だけを借りる形に近づくほど自社の作業は増えますが、手軽に使えるサービスの側にも、確実に残っているものがある。「簡単に使えるサービスなのだから、設定も任せておけばよい」——次の章で挙げる事故の多くは、この思い込みから生まれています。

実務では、多くの中小企業が表の一番上と、その隣の中間の形を組み合わせて使っています。メールやグループウェアはそのまま使い、顧客管理や独自の業務システムだけを自社で組み上げる、という構成です。すると一つの会社の中に、複数の境界線が同時に存在することになります。「うちはクラウドを使っている」の一言でまとめてしまうと、この違いが見えなくなり、どの部分を誰が見ているのかが曖昧なまま運用が進みます。社内で話をするときは、サービスの名前ごとに「これはどちらの形か」を先に確かめるだけでも、議論の噛み合い方が変わります。

どの形でも自社に残る、4つのもの

一つ目はアカウントと権限です。誰にログインできる権利を与え、その人にどこまでの操作を許すかを決めるのは、事業者ではなく利用者です。二つ目は設定そのもので、公開範囲、共有の可否、外部からの接続を許す条件などは、初期値のまま使うか、自社の実情に合わせて変更するかを利用者が選ぶことになっています。

三つ目はデータそのものの中身です。何を保存し、どれを消し、どれを残しておく必要があるかという判断は、業種や契約、法律によって決まるものであり、事業者側で代わりに判断することはできません。四つ目は「誰に共有したか」という記録です。社内の担当者、取引先、外部の協力会社。データへの入り口を増やすたびに、その入り口を自社が把握しているかどうかが問われます。

冒頭の「バックアップはもう心配ない」に話を戻します。標準でバックアップの仕組みを備えたサービスは多いのですが、それが何日分を保持し、誤って消したファイルが何日後に完全に消えるのかは、サービスごとに違います。そして、その日数が契約書のどこに書いてあるのかを言える人は、社内にあまりいません。多くの場合、そもそも書かれていないか、読まれないまま署名されています。復元できる期間を過ぎてから問い合わせても、事業者にできることは残っていない。バックアップがあるかどうかではなく、「いつまで遡れるのか」を導入時に確かめておく話です。

この4つを事業者の仕事だと思い込んでしまう原因の一つに、導入時の説明の受け取り方があります。「セキュリティも整った基盤です」という言葉は、ほとんどの場合、建物と土台についての説明であって、アカウントや設定の運用にまで踏み込んだ話ではありません。ところが聞く側は、それを「全部やってもらえる」という意味で受け取る。説明を聞くときは、いま話されているのが建物の話なのか中身の話なのかを、その場で切り分けて聞くと誤解が減ります。

設定ミスから起きる、よくある事故の型

クラウド移行後に実際に起きる事故は、事業者側の障害よりも、利用者側の設定や運用に起因するものが多くを占めます。業種を問わずよく見かける型を並べます。どれも高度な攻撃ではありません。

これらの型に共通する厄介さは、事故が起きた瞬間には誰も気づかない点にあります。公開範囲の設定ミスも、残ったままのアカウントも、それ自体はエラーを出しません。システムは正常に動き続けます。発覚するのは外部からの指摘か、たまたま誰かが気づいたときで、それまでの間、状態は静かに続きます。

もう一つ。どの型も「一度設定したら終わり」ではなく、時間の経過とともに崩れていきます。導入したときは適切だった権限も、担当者の異動や、業務の広がりや、新しい連携アプリの追加によって、少しずつ実態からずれていく。事故の多くは、悪意ある誰かが一気に作り出すものではなく、日々の小さな変更が積み重なった結果として、ある日たまたま踏み抜かれる形で表に出ます。点検を一度で終わらせず、見直す日を先に決めておくのはそのためです。

契約・導入時に事業者へ確認しておきたい10の質問

サービスを選ぶ場面では、機能と使いやすさに目が向きます。ただ、契約書や利用規約を読む段階、あるいは営業担当者との打ち合わせの席で、次のような点を尋ねておくと、後から困ることが減ります。

• 保存されるデータの物理的な保管場所はどこか、国外に置かれる可能性はあるか。
• 障害が起きた際、事業者はどの範囲まで復旧を担い、どこから先は利用者側の備えに委ねられるのか。
• アクセスの記録（ログ）はどこまで取得され、標準でどれくらいの期間保存されるのか。延長は可能か。
• 監査や第三者機関の認証をどの程度受けており、その結果を利用者側が確認できる仕組みがあるか。
• 契約を終了した際、データはどのように返却され、その後どのタイミングで完全に削除されるのか。
• 運用の一部を別の会社に再委託しているか、していればその範囲はどこまでか。
• 不正アクセスなどのインシデントが起きた場合、利用者への連絡はどのくらいの時間内に、どの窓口から行われるのか。
• 利用者側の設定ミスによって生じた被害について、事業者はどこまでを責任の対象外としているか。
• バックアップは標準機能に含まれているのか、含まれているとして復元できる期間はどこまで遡れるのか。
• アカウントの権限を細かく分けて設定できる仕組みが用意されているか、それとも一律の権限しか選べないのか。

どれも、契約書の分量が多い会社ほど、条項のどこかに答えが書かれています。読み切るのが大変だからと後回しにせず、担当者に直接尋ねて記録に残しておくほうが早い。検討中であれば、この一覧をそのまま使っていただいて構いません。

中でも後回しにされやすいのが、解約したあとの扱いです。データを返してもらえるのか、返してもらえるとしてどんな形式で、そして本当に消えるのはいつなのか。この問いを考え始めるのは、たいてい解約を決めた日です。その日にはもう、交渉できることはほとんど残っていません。入るときに聞いておく話です。

質問をぶつけたときの答え方にも、判断材料があります。具体的な仕組みや期間で答えられる事業者は、自社の運用を把握している証拠です。「基本的にはご安心いただけます」といった言葉で終わる場合は、質問の意図が伝わっていないか、答えを持ち合わせていないかのどちらかでしょう。契約は一度結ぶと切り替えに手間がかかるので、この段階のやり取りには時間をかける価値があります。

自社側でやる最低限は、まず4つ

一つ目は多要素認証です。パスワードだけに頼らない仕組みを、特に強い権限を持つアカウントから優先して有効にします。この論点は別記事で詳しく扱っているので、ここでは「まだなら最優先で着手する」とだけ書いておきます。

二つ目は権限の棚卸しです。誰がどのアカウントを持ち、どこまでの権限を与えられているかを、少なくとも半年に一度は一覧にして見直します。導入時に一時的に強い権限を渡したまま、そのままになっているアカウントは、たいていどこの会社でも見つかります。三つ目は共有設定の点検で、社外からも見える状態になっているフォルダや資料がないかを、定期的に確かめる習慣をつくること。四つ目は退職や契約終了の際の手順です。アカウントを止める作業が誰か一人の記憶に頼った運用になっていないかを確かめ、手順として文書に残しておきます。退職者のアカウント管理についても、掘り下げた内容は別記事に譲ります。

この4つに厳密な順番はありません。一つずつ着手する会社もありますが、並行して進めて構わない。効いてくるのは、誰か一人の担当者の努力に頼らず、いつ・誰が・何を確認するかを決めて、社内の年間の予定に組み込むことです。担当者が異動しても退職しても、予定として載っている確認は残ります。属人化した点検は、その人がいなくなった日に止まります。

「設定を間違えていないか」を外から確かめる

ここまで挙げてきた事故の型に共通するのは、社内から見ていても気づきにくいという性質でした。設定した本人には「そのつもりで設定した」という自覚があるので、見直しの候補にすら挙がりません。点検表を配って自己申告を集めても、同じ思い込みがそのまま書き写されてくるだけ、ということが起こります。

外部から自社の公開範囲やアクセス経路を確かめてみると、社内の想定と実際の設定がずれている箇所は、たいてい出てきます。担当者の能力の問題ではなく、日々の運用の中で設定が少しずつ積み重なり、誰も全体を見返していないという構造の問題です。第三者による確認は、その積み重なりを一度ほどく機会になります。自社の設定を外部の視点で点検するペネトレーションテストは、こうした確認に使われる手法の一つです。

参考になる公的資料

クラウド利用時の責任分担について社内で議論を始める際には、以下の公開資料が共通の土台として役立ちます。いずれも特定の事業者に偏らない、中立的な立場でまとめられたものです。

• 総務省「クラウドサービス提供における情報セキュリティ対策ガイドライン」——クラウド事業者と利用者、双方が担うべき対策の考え方が整理されています。
• 経済産業省・IPA「クラウドサービス利用のための情報セキュリティマネジメントガイドライン」——利用者側が契約前に確認すべき事項が具体的にまとめられています。
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」——データの保管場所や委託先の管理について、法律上の考え方が示されています。
• デジタル庁・総務省・経済産業省「政府情報システムのためのセキュリティ評価制度（ISMAP）」関連資料——クラウドサービスの安全性を評価する際の公的な基準の一つとして参照できます。