企業でクラウドサービスを導入する以上、セキュリティ対策は考えなければならない課題です。ベンダーから提供されるSaaSのセキュリティレベルは信頼に値するのでしょうか？

この記事では、クラウド・SaaSのセキュリティリスクや過去にクラウドサービスで起きたセキュリティ事故、確認すべきベンダーのセキュリティ対策についてお話しします。

目次

  1. クラウド・SaaSに懸念されるセキュリティリスク
  2. 過去に起きたクラウドのセキュリティ事故
    1. Google Docsのセキュリティ障害
    2. Dropboxのセキュリティ障害
    3. 2つのクラウドサービスの共通点は？
  3. パトリオット法によるクラウド・SaaSへの影響
    1. パトリオット法とは？
    2. パトリオット法のクラウドサービスへの影響は？
    3. 日本のデータセンターが影響を受けることも
  4. SaaSベンダーのセキュリティ対策をチェック
    1. ネットワーク上の対策
    2. 物理的な対策
  5. 第三者による認証
  6. 「オンプレミスのほうが安全」は過去の話かも
  7. 自社のセキュリティ対策も万全に
  8. まとめ

クラウド・SaaSに懸念されるセキュリティリスク

自社開発のシステムやオンプレミスのサーバーなど、自社内でデータのやり取りを完結させる場合は、セキュリティリスクについても自社でコントロールできます。
自社のポリシーに沿ったセキュリティレベルで運用可能です。コストやリソース次第で、いくらでもセキュリティレベルを強固にできます。

対して、クラウドサービスやSaaSではその性質上、セキュリティレベルをクライアント側で調整できません。*クラウドサービスを利用する以上、基本的にはベンダーにセキュリティ対策を任せることになります。*クライアント側がセキュリティ対策について意識する必要はないということです。

「セキュリティ対策をベンダーに依存する」という事実は、クラウド・SaaSのメリットとしてもデメリットとしても語られます。クラウドサービスが台頭したばかりの段階では、SaaSのセキュリティレベルについて多くの企業が懸念を示していました。現在は「セキュリティ更新を任せられる」という点がメリットとして認識されている一方で、セキュリティに関して懸念する声も根強く残っています。

実際にはクラウドサービスでセキュリティ事故が起きた例は少数です。サービス起因で起きた事故はほとんどありません。しかし、依然として「セキュリティを安全に保つためにはオンプレミス・自社システムを利用すべき」という声が一般的です。

過去に起きたクラウドのセキュリティ事故

多くのクラウドサービスは当初からセキュリティを考慮して設計されています。しかし、人が作り出すものである以上、欠陥を排除することはできません。過去には大型のクラウドサービスでセキュリティ事故が発生しています。

過去に「Google Docs」と「Dropbox」で起きたセキュリティ障害の事例を紹介します。

Google Docsのセキュリティ障害

「Google Docs」はGoogleが提供しているドキュメント編集サービスです。2009年7日に起きた障害により、非公開になっているドキュメントが他のユーザーに対して公開できる状態になっていたことが報告されました。同日中に障害は修正されましたが、およそ0.05%のユーザーが影響を受けたと考えられています。

*Google Docsのユーザー数は2007年時点で160万人に到達していたため、全体の0.05%といっても影響を受けたユーザーは決して少なくありません。*Googleをはじめとするインターネット関連企業がパッケージ型のソフトウェアからSaaSへの移行を積極的に呼びかけていたタイミングでの事故でした。

Dropboxのセキュリティ障害

「Dropbox」は日本でも普及しているオンラインストレージサービスです。2011年の6月19日にはどのパスワードを入力してもアカウントにログインできる障害が発生しました。事実上、パスワードによるセキュリティが機能しない状態と言えます。

障害は約4時間で復旧されましたが、TwitterをはじめとするSNS上で大きな話題になりました。Dropboxはこの事故以降、さらに強固なセーフガードの実装する意向を示しています。

2つのクラウドサービスの共通点は？

上述した事故が起きた2つのクラウドサービスには、共通点があります。「ひとつのシステムを複数人のユーザーでシェアしている」という点です。

「マンションタイプの集合システム」と呼べるこうしたクラウドサービスでは、ひとつのセキュリティ事故での影響が広範囲になる傾向があります。

パトリオット法によるクラウド・SaaSへの影響

クラウドサービス・SaaSのように世界的に活用されている技術のセキュリティにおいて、無視できないのがパトリオット法による影響です。

この法律の概要や、具体的なクラウド・SaaSへの影響についてお話しします。

パトリオット法とは？

パトリオット法は、テロリズムに立ち向かうことを目的として立案されたアメリカの法律です。2001年に起きた同時多発テロ以降、FBIをはじめとする捜査機関の権限を強化するために成立しました。捜査は情報分野も対象になります。

*例として、電話回線の傍受や通信傍受がパトリオット法のもとでは許可されます。*捜査令状があれば、メールやボイスメールの内容を入手することも可能です。さらに、テロの防止目的であれば、クラウドサービスの事業者に対して情報提供を求められます。

政権によってはさらに権限が拡大することも考えられます。現に、アメリカのオバマ元大統領はクラウドサービスに盗聴機能の搭載を義務付けるように準備中と報道されたことがありました。

パトリオット法のクラウドサービスへの影響は？

パトリオット法では、クラウドサービスの事業者に対して情報開示を求められます。アメリカのクラウドサービス事業者であればパトリオット法のもとに情報開示を要求される可能性がありますが、対応は企業によって異なるようです。

例として、Microsoftはパトリオット法に対して毅然とした姿勢を示しています。「正当な理由や手続きを通過していない限り、パトリオット法の対象であっても情報開示には応じない」と発表し、情報提供を行う際も顧客への通知を事前に行うことを公言しています。

また、もうひとつ懸念されている影響が「データセンターの停止」です。アメリカ・テキサス州では、あるデータセンターがFBIによって押収された事件が起きました。その間サービスを利用できなかった顧客大損害を受けています。

この件とパトリオット法の関係については明確に報道されていませんが、パトリオット法による押収でも同じ状況になることは十分に考えられます。

日本のデータセンターが影響を受けることも

上述したとおり、パトリオット法はアメリカの法律であり、適応されるのはアメリカの事業者です。そのため、一般的には事業者が日本に所在していればパトリオット法を意識する必要はないと考えられています。

そのような中、Amazonが自社のクラウドサービス「アマゾン ウェブ サービス（AWS）」に関して発表した声明が話題になりました。「Amazonはアメリカの会社なので、東京のデータセンターもパトリオット法の対象となる」といった内容が、過去のサミットでAmazon側から発言されています。

この件に関して、日本にデータセンターを持つクラウドサービス事業者の対応は明確に示されていないのが現状です。しかし、パトリオット法による影響を避けるためには、クラウドサービス事業者の所在やデータセンターの所在についても意識する必要があるかもしれません。

SaaSベンダーのセキュリティ対策をチェック

クラウドサービスのセキュリティでは、「ベンダーと利用者が責任を共有する」という考え方が一般的です。そして、責任共有の割合はクラウドサービスの提供形態によって異なります。

例としてIaaS（Infrastructure as a Service）の代表格であるAWSは、「クラウドシステムのセキュリティについての責任はAWSが負うが、データやOS、プラットフォームなどクラウド“内”のセキュリティの責任は顧客が負う」という責任共有モデルを提示しています。

SaaSはクラウドサービスの中でも、利用者側でコントロールできる領域が狭い提供形態です。セキュリティについても大部分をベンダーに依存しています。

SaaSを契約する際は、ベンダーがどのようなセキュリティ対策を実施しているか事前に確認しましょう。

確認すべきセキュリティ対策をネットワーク上の対策と物理的な対策に分けて紹介します。

ネットワーク上の対策

ネットワーク上の対策としては以下のようなものが挙げられます。
セキュリティポリシーに明記されているか確認しましょう。

通信傍受

クラウドのネットワークでは、通信傍受への対策が求められます。
現在は、暗号化による対策が代表的です。

なりすまし・中間者攻撃

第三者によってクラウドネットワークの通信を盗聴されてしまうことが考えられます。デジタル証明書による堅牢な本人確認体制や暗号化など対策が求められます。

キャパシティ

安定したパフォーマンスを期待するためには、ネットワークのキャパシティも重要です。

ベンダーがさまざまな利用状況に対応できるか、キャパシティの管理方法などについてあらかじめ確認しておきましょう。

物理的な対策

物理的な対策状況もベンダーを判断する重要なポイントです。
外的要因への対策、内部要因への対策に分けてご紹介します。

外的要因への対策

データセンターには関係者以外に侵入を防ぐための物理的なセキュリティが求められます。

第三者の侵入を防ぐため、以前はデータセンターの所在を公開しないのが一般的でした。しかし、現在は災害による影響を考慮しデータセンターの場所をしっておきたいというユーザーの声も増えてきています。そのため、データセンターの大まかな所在を公開しているベンダーも増えてきました。

バックアップを実施しているベンダーや複数拠点があるベンダーは、災害リスクに強いと言えるでしょう。

内部要因への対策

データセンターの従業員起因でデータが漏れる可能性も否定できません。

データセンターへの入退室管理はもちろんのこと、機器へのアクセス許可、特定の部屋に入室許可など権限の管理状況も重要なポイントです。

第三者による認証

ベンダーは基本的に自社にセキュリティに関して自信を持っています。しかし、利用者側にとっては、ベンダーのセキュリティポリシーだけでは信頼に欠けるかもしれません。

いくつかのベンダーはセキュリティに関する第三者認証を取得し、自社のセキュリティレベルの裏付けとして公開しています。

ユーザーにとっては、ベンダーを選択する基準のひとつになるでしょう。

代表的な第三者認証として以下のようなものが挙げられます。

・ISMS 認証（JIS Q 27001）
・プライバシーマーク（JIS Q15001）
・ASP・SaaSの安全・信頼性に係る情報開示認定制度

「オンプレミスのほうが安全」は過去の話かも

セキュリティレベルを自社で任意に調整できるオンプレミスがクラウドよりも評価されているのは自然なことです。しかし、実際には「オンプレミスが安全」という評価は過去の話かもしれません。現在は、多くのSaaSベンダーがセキュリティに万全の対策を実施しています。

オンプレミスの安全性は、あくまで自社がコストやリソースを投入できることが前提です。多くの企業にとって、SaaSベンダーと同じレベルのセキュリティをオンプレミスで実現するのは、コストやリソースの問題から現実的ではないでしょう。

仮に実現できたとしても、本業へと投資したほうが有益と言えます。

自社のセキュリティ対策も万全に

セキュリティが堅牢なSaaSを利用していたとしても、自社起因で事故が起きてしまう可能性は考えられます。SaaSを利用している企業にも、万全のセキュリティ対策が必要です。

一部の従業員を管理者に設定し、ほかの従業員のアクセスを制限することはセキュリティ対策の基本です。企業によっては、外出先からのアクセス制限、利用者ごとのパスワード管理など独自の対策が求められることもあります。

自社のセキュリティポリシーとのマッチングもSaaSを選定する基準のひとつです。

まとめ

SaaS導入前にセキュリティに関して考えておくことは大切です。機密情報の取り扱いが多い企業にとっては、最優先事項と言えます。

SaaSを選定する際は、各サービスのセキュリティポリシーや実施されている対策をくまなく確認してください。

また、SaaSのセキュリティレベルは十分でも自社起因で事故が起きてしまう可能性は否定できません。SaaSの導入を機に、自社のセキュリティ対策についても見直してみましょう。