01｜「クラウドは危ないのでは」という不安
クラウド化の話をしていて、最後に必ずと言っていいほど出てくるのが「セキュリティは大丈夫なのか」という問いです。
大事なデータを社外のサーバーに預けることに、抵抗を感じる。社内にサーバーがあれば、少なくとも自分たちの目の届くところにある──そう感じるのは自然なことです。
このシリーズの第1回「なぜクラウド化が進まないのか」でも、クラウド化が進まない理由の一つとしてこの不安を挙げました。今回は、その中身をもう少し踏み込んで整理します。
先に結論をお伝えします。適切に設計し、正しく設定して使えば、クラウドは自社でサーバーを持つよりも安全にできます。 機器の更新、不正アクセスの監視、障害時の切り替え──こうしたことを自社だけで維持し続けるより、専門の事業者に任せられる範囲のほうがずっと広いからです。
ただし、これは「クラウドにすれば自動的に安全になる」という意味ではありません。クラウドにすると危険が増えるのではなく、守るべき範囲が変わります。 その変わり方を理解しないまま使い始めることが、実際の事故につながっています。
問うべきなのは「クラウドは安全か」ではなく、「どこまでを自社で守る必要があるのか」です。
この記事では、事業者と利用者で守る範囲がどう分かれるのかを整理したうえで、まず押さえておきたい5つのことをお伝えします。
02｜守る範囲が変わる──責任共有モデル
自社でサーバーを持つ場合、守るべきものはすべて自社の側にあります。建物の施錠、機器の管理、OSの更新、ネットワークの設定、アカウントの管理まで、すべてです。
クラウドでは、このうち土台の部分をクラウド事業者が引き受けます。一方で、誰にどの権限を与えるか、どのデータを外部に見せるかといった部分は、利用者の責任のまま残ります。
この線引きを責任共有モデルと呼びます。主要なクラウドサービスでは、この考え方が契約や公開資料の中で明示されています。
事業者は、引き受けた範囲を専門の体制で守っている
事業者が引き受ける範囲は、契約でそう決まっているというだけではありません。基盤の安全は、事業者にとって事業そのものの土台です。 ここで事故を起こせば多数の利用者に影響が及び、信頼を失います。だからこそ、一社で用意するのは難しい水準の体制が敷かれています。
- データセンターは所在地を公開せず、入退室を厳格に管理している
- 機器は故障を前提に多重化されており、一台が壊れても基盤全体は動き続ける
- 基盤の監視と障害対応を、専門の担当者が24時間体制で行っている
- 第三者機関の監査を受け、情報セキュリティの国際規格（ISO/IEC 27001、SOC 2など）の認証を取得している。日本政府が調達の基準とするISMAPに登録されているサービスもある
同じ水準を自社のサーバー室で用意しようとすると、費用も手間も現実的ではありません。土台の部分は、任せたほうが安全になるというのが実際のところです。
サービスの形態によって境界が動く
責任の境界は、使うサービスの形態によって上下します。
グループウェアや会計ソフトのようなSaaSでは、事業者が引き受ける範囲が広く、利用者の負担は小さくなります。一方、サーバーを借りて自社のシステムを動かすIaaSでは、OSの更新も脆弱性への対応も利用者の仕事です。「クラウドにしたから安心」とならないのは、この違いを見落としているときです。
そして、どの形態を選んでも利用者側に残るのが、アカウントとデータの扱いです。事故が起きるのは、たいていこの二つです。
03｜クラウドの事故は「設定」と「アカウント」で起きる
クラウドで情報が漏れたという話を聞くと、事業者のシステムが破られたように感じます。しかし実際に多いのは、利用者側の設定に原因があるケースです。
具体的には、次のようなものです。
| よくある原因 | 何が起きるか |
|---|---|
| 退職者・異動者のアカウントが残る | 担当を離れた後もデータにアクセスできる状態が続く |
| 多要素認証を設定していない | パスワードが漏れた時点で、そのまま侵入される |
| 全員に管理者権限を与えている | 一つのアカウントが乗っ取られたときに、被害が全体に及ぶ |
| 共有リンクや公開範囲の設定ミス | 社内向けのつもりのファイルが、URLを知っていれば誰でも見られる状態になる |
| ログを取得していない | 事故が起きても、いつ・誰が・何をしたのかが分からない |
いずれも、事業者の側では防げません。そしてどれも「使い方を決める」段階の話であり、高価な製品を買えば解決するものではないという点が共通しています。
裏を返せば、ここさえ押さえておけば、クラウドは自社でサーバーを抱えるより守りやすくなります。
04｜まず押さえておきたい5つのこと
前の章で挙げた5つの原因に、そのまま対応しています。上から順に取り組んでください。
1. アカウントの棚卸しを定期的に行う
誰がどのサービスを使えるのかを一覧にして、使われていないアカウントを止めるところから始めます。あわせて、退職や異動のときにアカウントを止める手順が決まっているかを確認してください。人の入れ替わりに合わせて止める仕組みがないと、放置されたアカウントは静かに増えていきます。
2. 多要素認証を必須にする
パスワードだけの状態は、鍵が一つしかない扉と同じです。多要素認証（パスワードに加えて、スマートフォンのアプリや認証コードで本人確認を行う仕組み）は多くのクラウドサービスに標準で用意されており、追加費用なしで使えることがほとんどです。特に、管理者権限を持つアカウントには例外なく設定してください。
3. 権限は、必要な人に必要な分だけ
全員を管理者にしておけば運用は楽ですが、事故が起きたときの被害はそのぶん大きくなります。「この人はどこまで触れる必要があるか」を役割ごとに整理し、管理者権限を持つ人を絞ります。少人数で運営している会社ほど「全員が全部見られる」状態になりがちですが、ここは分けておく価値があります。
4. 公開範囲の設定を見直す
外部に発行したままの共有リンク、社外の方を招いたままのフォルダ、検証用に作って放置している領域──こうしたものが残っていないかを確認します。一度確認して終わりにせず、半年に一度など周期を決めて見直すのが現実的です。
5. バックアップは別に持ち、ログを残す
クラウドを使っていれば、事業者側でデータは複製されています。しかしそれは機器の故障に備えたものであり、誤って消したデータや、ランサムウェア（データを暗号化して使えなくする攻撃）の被害を受けたデータを元に戻すためのものではありません。世代を分けて別に保管する仕組みを用意してください。
あわせて、誰がいつ何をしたかを記録するログを有効にしておきます。事故が起きたときに影響範囲を特定できるかどうかが、その後の対応を大きく左右します。
なお、ここに挙げたのはクラウドを使ううえで特に重要な点です。OSやソフトウェアの更新、従業員への教育といった全社共通の基本については、当ブログのセキュリティ対策の記事で整理しています。
05｜まとめ
「クラウドは危ないのではないか」という不安の多くは、守る範囲がどう変わるのかが見えていないことから来ています。
ポイントを整理します。
- 正しく設計し、正しく設定して使えば、クラウドは自社でサーバーを持つより安全にできる
- 危険が増えるのではなく、誰が何を守るかの分担が変わる。土台の部分は、事業者が専門の体制で引き受けている
- アカウント・データ・公開設定は、どの形態でも利用者に残る。SaaSでは事業者の担う範囲が広く、IaaSでは利用者の担う範囲が広い
- 実際の事故は、利用者側の設定とアカウント管理に原因があるものが多い
- まず取り組むのは、アカウントの棚卸し・多要素認証・権限の絞り込み・公開範囲の見直し・バックアップとログ
いずれも、大きな費用をかけずに着手できるものばかりです。まずは「どのサービスを、誰が使っているか」を書き出すところから始めてみてください。その一覧ができると、次に何をすべきかが見えてきます。
ワイズラボでは、YzNexus（月額定額ITコンサルティング）やワイズクラウド（AWS導入・運用支援）を通じて、クラウドの権限設計や設定の見直しをサポートしています。「今の使い方で問題がないか確認したい」という段階でも、お気軽にご相談ください。
