クラウドセキュリティ~過去事例と現在~

はじめに

本記事に興味を持って頂きありがとうございます。
クラウドは数クリックで始められるので、手軽でとても便利です。
ただ、だからと言って何の知識も持たずに始めるのは危険でしょう。
本記事では過去に起きたクラウドのセキュリティに関する事故事例と、クラウドのセキュリティが実際どうなっているのかということを紹介していきたいと思います。
過去の事例や現状を正しく理解することで、これから起こりえるだろう事故を想定でき、未然に防いでいくことができるはずです。
本記事で少しでもクラウドのセキュリティに関することの理解を深めて頂ければ幸いです。

クラウドセキュリティ事故事例

では、さっそくクラウドのセキュリティ事故事例を見ていきたいと思います。

クラウドベンダー起因による事故事例

まずはGoogleで起こった事故事例を紹介します。
2009年3月10日にオンラインでドキュメントを作成、利用できるサービスである「Google Docs」で、非公開のドキュメントが共有されてしまうという不具合発生が発生しました。2011年にはドキュメントリストに関するリアルタイムコラボレーション機能を強化するために実施した設計変更が原因で、メモリー管理の問題が起こりました。2014年にはGoogleDriveを介して共有された一部ファイルが関係のない第三者が閲覧できるという事例が発生しています。
次にDropBoxで起こった事故事例について紹介します。クラウドのストレージサービスを提供する同社で、2011年6月21日に任意のパスワードであらゆるユーザーアカウントにアクセスできる障害が発生しました。これはプログラマーのミスで、コードアップデートの際にDropBoxの認証メカニズムに影響を及ぼすバグが発生したことが原因でした。
最も重要な事件は、2012年に起きた「ファーストサーバ事件」でしょう。
なんと契約している約5000社の顧客データがすべて消えてしまったのです。
この事件の経緯は、メールシステムの障害対策の際、サーバーへメンテナンスで使用する更新プログラムに不具合があり、サーバーのデータをバックアップも含めて削除してしまったのです。不具合が起きた原因は担当者が更新プログラムを改変した際に、対象サーバの「ファイル削除コマンド」を消し忘れてしまったことのようです。
これらはいずれもクラウドベンダー側のミス、中でもヒューマンエラーによるものと言えます。これに関しては、過去に事故事例の少ないサービスを選択し利用するのが良いでしょう。

サイバー攻撃を起因とする事故事例

次にサイバー攻撃によって発生した事故事例について紹介していきます。
国立大学法人「鹿屋体育大学」ではクラウドサービスアカウントが何者かの不正アクセスを受け、学生の端末に登録されていた学内外の関係者らのメールアドレス合計約2,500件が閲覧され、そのアカウントを利用して「なりすましメール」を319件送信されました。また近年ではクラウド上に構築した検証環境のセキュリティの脆弱性を攻撃されるケースもありました。検証環境は本番環境とは違い、セキュリティに関して軽視されることが多いです。例えばパスワードは開発者全員で一つのアカウントを使ったり、検証環境のアクセス制御が弱い場合があります。(VPNなどを使わずインターネットで直接接続ができる設定になっている。)こうした脆弱性を狙われるケースもあります。クラウドはその性質上、社外のサーバに接続することになりますので、アカウント認証は必ず入ってきます。ユーザー側のうっかりミスが大惨事につながることもありますので、アカウントはしっかり管理する必要があります。

クラウドベンダーのセキュリティ対策

ここではクラウドベンダーが実施しているセキュリティ対策について紹介します。
Googleはサイバー攻撃対策として、GoogleDrive上のデータは安全なデータセンターに保管しているとした上で、我々ユーザにも定期的なセキュリティ診断の実施やソフトウェアの更新、セキュリティ上安全なパスワードの使用を推奨しています。DropBoxのセキュリティ対策では、AESによるデータの暗号化(2020年現在のアメリカで標準化されている高度な暗号化)や2段階認証(IDとパスワード以外にセキュリティコードを入力する)を実施しており、Googleと同様にユーザ側にも定期的なパスワードの変更やセキュリティソフトの利用を呼び掛けています。また、クラウドデータセンターのセキュリティは大変堅牢なものとなっています。GoogleではGoogle独自のサーバが製造されています。Linux OSであり、余分な実装を取り除いているので、脆弱性をなくし、パッチの適用を減らすことができるようになっています。データセンターへの立ち入りは、一般のみならず、Googleの社員さえ立ち入ることができません。またセキュリティスタッフが24時間365日体制で常駐する検問所からのみ確認を受けて入ることができます。Azureなどのクラウドサービスを提供しているMicroSoftも同様の取り組みを実施しています。データセンターには可能な限り人が出入りしないよう抑制されており、リモートで集中管理、自動化、マシンラーニングによる自立化が進められています。データセンターの管理においても、キャパシティー(リソースの操作)を管理するチームと物理的にサーバをチェックするチームをわけており、構造的にセキュリティが堅牢になるようになっています。もちろん、ストレージに使っているHDDは暗号化されているだけでなく、穴を開けて物理的に破壊してから出ないとデータセンターの外に出せないルールになっているのです。GoogleやMicroSoftなど有名なクラウドベンダーは世界各国のセキュリティ基準をクリアしておりますので、一般企業のオンプレミス環境よりもよほどセキュリティが高いことが証明されています。

さいごに

いかがでしたでしょうか?
過去に起こった事例を見てみると、更新時のミスのようにクラウドベンダー側のヒューマンエラーが多数見受けられました。しかしGoogleでは再発防止のために、プログラムの脆弱性をなくすよう更新をかけたり、ファーストサーバでも開発部門と運用部門を分けて責任範囲を明確にし、二次バックアップを取得するなどの対策が行われました。不正ログインなどのサイバー攻撃に対しても、データの暗号化や2段階認証を実施しており、物理的なサイバー攻撃に対してもデータセンターの徹底管理などを実施しています。上で紹介したクラウドベンダー起因による事故事例は10年程前のものになりますので、現在においては、クラウドサービス全般的に、格段に品質が向上しているでしょう。むしろ近年ではクラウドベンダー起因の事故よりも我々ユーザ側のアカウント漏洩や設定ミスを起因とする事故が多く取り沙汰されています。多くの名立たる企業が基幹システムをAWSへ移行していますし、今やクラウドのセキュリティはかなり信頼できるものと言えるでしょう。ただし、だからと言ってクラウドベンダー側にセキュリティをすべて任せてしまうことはできません。ユーザー側でもアカウントの管理などを徹底するのはもちろんのこと、事例から学び、クラウドに対する理解を深めていかなければなりません。
以上となります。ありがとうございました。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です