技術の発展により、クラウドサービスの利活用が一般的になってきた一方で、漠然と「クラウドサービスはよくわからないし、セキュリティ的に危険そう」というイメージがある人も多いのではないでしょうか。
では、いったいどんな危険があるのでしょうか。
今回は、技術に関するクラウド上のセキュリティリスクを13個紹介します。具体的なリスクを知ることで、実際に使ってみる際に「これだけ気を付ければ大丈夫」と思えるかもしれません。
クラウドサービスは便利なので、できれば使いたいものです。
ISO27017の取得を目指している企業のセキュリティ担当のリスク分析に役立つので、クラウドに関わるセキュリティ担当の方は、ぜひ最後までご覧ください。
また、企業がやるべきセキュリティ対策をまとめたセキュリティチェックシートを無料で配布しています。ぜひご活用ください。
クラウドのセキュリティリスクとその対策
クラウドのセキュリティリスクと、その対策を紹介します。
(1) リソースの枯渇
クラウドサービスは、複数の利用者により1台のサーバやネットワーク機器を共有していることが一般的です。
このような、複数の利用者が1つの機材を共有する形態を「マルチテナント」と呼びます。
物理的なサーバを利用しているわけですから、そのサーバの処理速度にも限界があります。
では、同じサーバを利用している共同利用者が、突然、高い負荷がかかる処理を開始するとどうなるでしょうか。
限られた物理サーバの処理能力を、マルチテナントによる利用者全員で分配して利用しているわけですから、当然、自社データの処理に影響が出る可能性があります。
分かりやすい例として、Twitterを見てみましょう。
Twitterを構成するシステムそのものは、多くのユーザーが利用(共有)しています。
また、日本国内のTwitterユーザーは、TV番組などでジブリ作品の「天空の城ラピュタ」が放送された場合、物語終盤で用いられるセリフとタイミングを合わせて、一斉に「バルス！」と投稿することがあります。
その瞬間、複数の共同利用者が一斉に「投稿」という処理を行った瞬間、Twitterのサービス全体の負荷が上がり、一部処理が遅延したり、投稿できなくなるという事態が発生しました。
これが例えば、一秒の遅れも許されないビジネスの世界だったとして、高負荷が原因で操作が数秒間遅延してしまうと、場合によっては大きな損害を被る可能性があります。
このように、共同利用者の高負荷がかかる操作により、計算に必要な能力が奪われて、自社のシステムにも影響を与えてしまうことを「リソースの枯渇」と呼んでいます。
リソースの枯渇を対策するには
リソースの枯渇を対策するには、要求されたシステム性能を確実に満たすために、リソースの利用を監視・調整し、また、リソースが足らない時期や足らないリソースを予測することが重要です。
たとえば、Twitterの呟きのケースであれば、番組が放映されている日時が事前に分かっているため、その間だけ、サーバーを強化して、リソースの枯渇を避けることができるでしょう。
(2) 隔離の失敗
上記「リソースの枯渇」において、マルチテナントを採用しているクラウドサービスの場合は、複数の利用者が1つの機器を共有しているという説明をしました。
ということは、自社のデータと他社のデータが、同じサーバ内に保管されている可能性があるということです。
すなわち、自社のデータを読み書きする際には、まずは複数の利用者のデータが保管されているサーバにアクセスして、その中から自社のデータを選択して、取り出す必要があり、その概念を「隔離」と呼んでいます。
隔離には、いくつかのレベルがあります。
例えば、IaaSを利用している場合は、1つのサーバの上に、複数の利用者のOSが動いているため、OS同士を適切に隔離する必要があります。
また、SaaSを利用している場合は、1つのデータベースのテーブルの上に、複数社のデータレコードが存在している場合が一般的です。
SaaSの開発者は、ある利用者のデータが、他の利用者に取り出されないようにするために、安全な設計やプログラミングをする必要があります。
有名な攻撃手法である「SQLインジェクション攻撃」は、このデータベースの隔離の失敗を突いて、本来見ることが出来ないデータを取り出すための攻撃です。
もし仮に、「必要なデータだけを取り出す」という隔離の仕組みに不備や脆弱性があった場合は、他社のデータも見ることができてしまうかもしれません。
このように、適切なデータの取り出しが担保されていない状況を、隔離が上手く機能していないとして、「隔離の失敗」と呼んでいます。
隔離の失敗を対策するには
隔離の失敗を対策するには、エスケープ処理という、処理系によって特別な意味を持つ文字を別の文字に置換して、特別な意味を持たない文字に変換して、SQLインジェクション攻撃を防ぐ対策が有効です。
また、データベースサーバーのログを監視・解析することで、脆弱性となりうる、普段は使われていないSQL 文の発見や、権限昇格によるシステムログへの攻撃を察知できます。
また、セキュリティソフトを利用してサイバー攻撃を防いだり、脆弱性診断を行い、脆弱性がないかをチェックする対策も実施すると良いでしょう。
(3) クラウドプロバイダ従事者の不正 – 特権の悪用
クラウドサービスを利用するということは、自社のデータを、クラウドサービスを提供している企業の管理下に置くことと同義です。
そして、クラウドサービス提供者(特に、システム管理者)は、その気になれば、サービスを利用している会社のデータを閲覧できる場合もあります。
もしそのような特権管理者が内部不正を働かせた場合、自社が預けているデータが流出したり、改ざんされたり、削除される可能性があります。
このように、クラウドサービス提供者自身による何らかの不正行為を、「クラウドプロバイダ従事者の不正 – 特権の悪用」と表現しています。
特権の悪用を対策するには
クラウドプロバイダ従事者の不正を対策するには、事前に信頼できる企業かどうかを判断することが重要です。
当然ですが、サービス提供者である企業は、特権の悪用が発生してしまうとサービスの信頼や評判を損なうため、様々な対策を実施しています。
具体的には「利用者のデータを閲覧できる権限を持つものはシステム管理者の中のごく一部の人間に限る」「上長に申請をしないとデータを閲覧できないようにする」「データ閲覧時のログを取る」といった内容です。
また、サービスの利用規約にも、利用者のデータを、自社(サービス提供者)が許可なく閲覧することは無い旨を明記している会社も多いです。
そのため、過去に特権の悪用があったクラウドサービスを調査して、避けるのが一番の対策といえるでしょう。
(4) 管理用インターフェイスの悪用
クラウドサービスは、社内外を問わず、インターネットに繋がりさえすればどこからでも利用できるという特徴があります。
また、利用するサービスの管理画面によっては、たった数回のクリックでサーバを全て停止させたり、データを全て削除したりすることが可能な場合もあります。
例えば、自社がクラウドサービスを利用しており、サービスの管理権限を持つ社員が、カフェなどで作業をしているところを考えてみて下さい。
PCからふと目を離した隙にPCが盗まれ、そのまま作業中だったクラウドサービスの管理画面にアクセスされ、クラウドサービス上に預けている全ての情報が削除されてしまえば、社内の業務に多大な影響を及ぼしかねません。
また、削除だけならまだしも、データを外部に流出させられたり、サーバを停止させられたりした場合は、業務への影響だけでなく会社の評判が大幅に下落してしまうことになります。
このように、管理画面等から容易に重大な影響を及ぼす処理を実行し得るため、その状態が内包する危険性を総称して「管理用インターフェイスの悪用」と呼んでいます。
管理用インターフェイスの悪用を対策するには
管理用インターフェイスの悪用を対策するには、管理画面へのアクセスを堅牢にし、悪用されないことが重要です。
具体的には、「多要素認証の導入」「IPアドレスによるアクセス制御」「席をたつときはPCの画面をロックする」といった多層的な対策が求められます。
また、喫茶店のような不特定多数の人物がいる場所で仕事用のパソコンを使用しないのも重要といえます。
(5) データ転送途上における攻撃
クラウドサービスは、単一のサーバだけで運用されているわけではありません。
例えばIaaSを利用して、Webアプリケーションを構築するためのサーバ構成を考えてみると、まずWebサーバやアプリケーションサーバと、DBサーバは分離するべきでしょう。
そして、データの完全性や可用性を保つために、DBサーバは冗長構成にして…などと考えるかもしれません。そうすると、提供されるクラウドサービス内の複数のサーバの間で、データのやり取りをする必要があります。
ここで問題になってくるのは、サーバ間でのデータのやり取りの途中に、その通信の内容が傍受される可能性があるということ、そして、その通信をどれだけセキュアなものに設計するかは、クラウドサービス提供者の手に完全に一任されており、利用者側は、打つ手が無いということです。
このように、クラウドサービス内でのデータのやり取りにおいて、セキュリティ上のリスクが存在する状態を「データ転送上における攻撃」と表現しています。
データ転送途上における攻撃を対策するには
データ転送途上における攻撃を対策するには、自社で直接的な対策が難しいです。
そのため、クラウドサービス提供者が本当に信頼できるのか、過去になにか問題は起こしていないか、問題を起こしていたとして、どのような対応をしてどんな対策をしたのかを調査しましょう。
頻繁に、サイバー攻撃を受けてしまっているクラウドサービス提供者の場合、適切な対策ができていない、もしくは、技術力が足りないともいえます。
信頼できるクラウドサービスを利用するのが、効果的な対策といえるでしょう。
(6) データ漏えい（アップロード時、ダウンロード時、クラウド間転送)
データの漏えいは、先程述べたクラウドサービス内のデータ転送以外でも生じ得ます。
クラウドサービス利用者が、自身のPCやスマートフォンからクラウドサービスにアクセスする時のデータのやり取り、すなわちクラウドサービスと利用者間における通信経路も、適切に保護する必要があります。
クラウドサービスとサービスの利用者間での通信や、クラウド間での通信途上における情報漏えいの危険性を「データ漏えい」と呼んでいます。
データ漏えいを対策するには
データ漏えいを対策するには、技術的な側面から見ると、通信経路の暗号化(SSL/TLS)を実施しているサービスを利用することが有効です。
「野良Wi-Fi」と呼ばれる、提供元が不明のWi-Fiやカフェやホテルなどで提供されている暗号化がされていないWi-Fiに接続してしまうと、通信が容易に傍受されてしまう可能性があります。
そのため、外出先のカフェなどで、気軽に無料Wi-Fiに接続しないようにするのが重要です。
セキュリティチェックシートでセキュリティ対策の改善をしましょう。
(7) セキュリティが確保されていない、または不完全なデータ削除
クラウドサービスを利用している自社の従業員が、間違えて重要なファイルをアップロードしてしまったことに気づき、急いで「削除」ボタンを押したところを想定してみてください。
ボタンを押してしばらくすると、確かに、画面上のファイル一覧からは、間違ってアップロードしたファイルは表示されなくなりました。
ですが、クラウドサービスの利用者は削除ボタンをおした時、そのファイルが本当に「サーバ自体から削除された」のか、または「サーバにはデータが残っているが、画面上で見えなくなった」だけなのか、判断することは困難です。
（※前者を「物理削除」、後者を「論理削除」と呼びます）
利用者が実行できる削除操作が論理削除だった場合、クラウドサービスから情報が漏えいした際に、削除したはずのデータが流出してしまう可能性があります。
このように、データの削除における取り扱いが有するリスクを「セキュリティが確保されていない、または不完全なデータ削除」と呼んでいます。
セキュリティが確保されていない、または不完全なデータ削除を対策するには
こちらも、自社側で直接的な対策はできません。
そのため、削除操作が物理削除なのか論理削除なのかを事前に確かめたり、自社がクラウドサービスの利用をやめるとき、自社のデータはサーバにずっと残ったままになるのか、利用をやめるタイミングで削除されるのか、あらかじめ確認しておくことが大切です。
また、AWS(Amazon Web Services)の場合、データの廃棄については以下のような声明を出しています。
このような、対策を明示しているクラウドサービスを使うのも一種の対策といえるでしょう。
(8) DDoS攻撃
DDoSとは「Distributed Denial of Service」の略で、日本語では「分散型サービス妨害攻撃」となります。
悪意のある第三者が、複数のサーバから、サービスに対して大量のアクセスを送り、処理をパンクさせ、サービスを利用不可にしてしまう攻撃です。
身近な例で言えば、Webブラウザでページを繰り返し再読み込み(更新)する、いわゆる「F5アタック」と呼ばれる操作を、複数のサーバから機械的に行う妨害攻撃と捉えても間違いではないかもしれません。
もし、クラウドサービスの提供元が、DDoS攻撃を始めとする様々な悪意のある第三者からの攻撃に対して十分な防御策を取っていないと、そういった攻撃を受けた際に急にサービスが使えなくなったり、情報が流出したりする可能性があります。
クラウドサービスの利用者は、サービス提供元が技術的な防御策をとっていることを確認する必要があるため、リスクとして「DDoS攻撃」が挙げられています。
DDoS攻撃を対策するには
DDoS攻撃を対策するには、脆弱性の発見と改善をすることが大前提です。
また、CDN(Contents Delivery Network)というコンテンツを配信する仕組みがあり、世界中にキャッシュサーバを持つことでアクセス負荷を分散させ、DDoS攻撃を防ぐ効果があります。
利用しているクラウドサービスの、コンテンツ配信方法を理解しておくことが重要です。
(9) EDoS攻撃
EDoSとは「Economic Denial of Service」の略で、日本語では「経済的なサービス妨害攻撃」となります。
あまり馴染みがないかもしれませんが、クラウドサービス利用者に経済的な負担を与えて、サービスの運用継続を妨げる攻撃手法です。
IaaS型のクラウドサービスの中には、利用する回数や通信量に対して利用料を請求する「従量課金制」を採用しているサービスが多く存在します。
身近なスマートフォンに例えれば、5GBまでのインターネット利用は定額の3000円で、それを超えると1GBあたり1,000円の追加料金が掛かるというような料金形態です。
EDoS攻撃は、そのような料金形態のスマートフォン利用に際し、100GBや1,000GBなどといった莫大な量の通信を強制的に送り込むことで利用者を経済的に破綻させ、サービスの利用を困難にさせる攻撃です。
EDoS攻撃を対策するには
EDoS攻撃を対策するには、大量のアクセスを遮断するようなネットワークの設定を行い、従量課金を防ぐ方法が効果的です。
また、クラウドサービスのEDoS攻撃を受けた際の経済的な保証や免責事項について確認しておきましょう。 また、直接的な対策ではありませんが、一定の利用料金を超えた場合にアラートやメールが届くよう設定するといった、被害検知の仕組みを構築しておくことも重要です。
(10) 暗号鍵の喪失
一般的なパスワードのような、本来秘密にしておくべき認証情報が漏れてしまう事態も考えられるため、クラウドサービスで利用するパスワードは、社内システムで利用するそれと比べ、厳重に守る必要があります。
それは、多くのクラウドサービスは、IDとパスワードさえ分かってしまえば、いつでも、誰でも、どこからでもアクセスすることが可能だからです。
そのため、クラウドサービスにおいてパスワードが流出してしまうことは、最も忌避すべきリスクの一つであるとも言えるでしょう。 クラウドサービスにおけるパスワードや秘密にすべき認証情報の重要性と、それが漏えいした場合のリスクを鑑みて「暗号鍵の喪失」がリスクに挙げられています。
暗号鍵の喪失を対策するには
暗号鍵の喪失を対策するには、「二段階認証」を採用することが、簡単かつ、リスクを回避する最も効果的な方法です。
クラウドサービスを利用する全ての従業員に二段階認証を求めるのは非現実的かもしれませんが、管理者権限を持つユーザーなどに限って二段階認証を利用するように設定するだけでも、セキュリティレベルは大きく向上します。
(11) 不正な探査又はスキャンの実施
社内システムとクラウドサービス、悪意のある第三者に攻撃対象にされやすいのはどちらかと訊かれた場合、多くの人は、クラウドサービスの方が攻撃を受けるリスクが高いと考えるのではないでしょうか。
実際、社内システムを攻撃しようとすると、社内ネットワークに進入するなどのハードルが存在します。一方、クラウドサービスの場合は、Web上のセキュリティホールを見つけたり、IDやパスワードを抜き取ったりと、攻撃可能な範囲を拡大しやすいケースが多い状況です。
それでは、クラウドサービスに対する攻撃として、どのような手法が考えられるでしょうか。
一般的で、かつイメージのしやすい攻撃手法の一つとして、パスワードの総当たり攻撃が挙げられます。
クラウドサービス利用者が、クラウドサービスを利用する際にアクセスする「ログイン画面」そのものは、誰でもアクセスすることが可能です。
ということはひょっとすると、今現在でも、悪意ある第三者があなたのアカウントに紐づくパスワードの総当たり攻撃を実施している最中かも知れません。
このように、クラウドサービスにおける総当たり攻撃のリスクなどを鑑みて、「不正な探査又はスキャンの実施」がリスクに挙げられています。
不正な探査又はスキャンの実施を対策するには
不正な探査又はスキャンの実施を対策するには、IPアドレスでログイン画面へのアクセスを制限し、自社のネットワークからのみ接続できるようにすることが重要です。
また、記号や大文字英語、小文字英語、数字といった複数の種類の織り交ぜた複雑なパスワードを設定したり、ログイン試行履歴やログイン成功履歴一覧を確認し、不正なログインが発生していないか定期的に確認することも対策として重要です。
(12) サービスエンジンの侵害
クラウドサービスでは、同一のサーバに自社と他社のデータが同居する「マルチテナント」が発生するケースが少なくないことは上述した通りです。
当該のサーバにおいては、自社のデータと他社のデータを適切に分離するためのソフトウェアが実装されており、ここではそれを「サービスエンジン」と呼びます。
そして、サービスエンジンがサーバ内に存在するソフトウェアである以上、自社が何らかの不適切な操作を行ったり、もしくは、マルウェアに感染したりすることで、このサービスエンジンの設定が変更されたり、乗っ取られたりするリスクが存在します。
幸いなことに、このようなリスクを突いた攻撃は、現時点ではそれほど多くは観測されていません。
しかし、仮にサービスエンジンが乗っ取られれば、自社データと他社データが適切に分離されていない隔離の失敗を引き起こすどころではなく、自社データの削除や窃取などが容易に実現可能になってしまいます。
このように、サービスエンジンへの攻撃に伴うリスクとして「サービスエンジンの侵害」が挙げられています。
サービスエンジンの侵害を対策するには
まず前提として、不適切な操作をしないように、マニュアルを用意して従業員の誤操作を防ぐことが重要です。
また、侵害テスト（ペネトレーションテスト）により、リスクのある設定不備を検出して脆弱性を発見することも、有効な対策といえるでしょう。
(13) 利用者の強化手順と、クラウド環境との間に生じる矛盾
クラウドサービスの安全は、クラウドサービスの提供者とクラウドサービスの利用者、双方の適切な取り扱いと心がけによって守られるものです。
例えば、クラウドサービス提供者は、利用者から預かった情報を適切に保存する必要がありますし、クラウドサービス利用者は、サービスを利用するためのパスワードを強固なものにしたり、必要に応じて2段階認証を導入したりする必要があります。
一見すると当たり前のように映る取り組みですが、セキュリティ対策の中には、提供者と利用者のいずれがが責任をもって実施すべきなのか、明確に定義されていないものがあります。
ある会社が、Amazon Web Servicesの仮想サーバ(EC2)を利用して自社のWebサービスを運用していたとします。
ある日、AWS側のデータセンターがトラブルに見舞われ、EC2が利用できなくなり、自社のWebサービスが停止してしまった場合、サービス停止の責任はAWSにあると思われがちですが、一概にそうとは言えません。
もしこの会社が、AWSのデータセンターにおけるトラブルを予測して、AWSが有するもう一つのデータセンターにも予備のサーバを設置していれば、サービスの停止は防げたかもしれません。
※AWSは、日本国内のみで言っても少なくとも2箇所にデータセンターを有しています。
そのような、異なる箇所にサーバを設置することを、AWSでは「multi-AZ」と呼んでいます。
「利用者がそこまで考える必要があるのか」と思われるかもしれませんが、EC2のSLAを読んでみると、「multi-AZ構成をしていたにも関わらず、サービスが停止してしまった時のみ、保証が適用される」との記載が見受けられます(2016年10月現在)。
つまり、利用者によるmulti-AZ構成が前提となっており、そしてその設定は、利用者自身が行う必要があります。
このように、クラウドサービスの利用者は、自社の情報を守るために、クラウドサービス側における各種の技術的対策の実施有無を見極め、必要に応じて自社での対応や対策を検討・実施しなければならないことを「利用者の強化手順と、クラウド環境との間に生じる矛盾」と表現しています。
利用者の強化手順と、クラウド環境との間に生じる矛盾を対策するには
対策としては、前述した通りクラウドサービス側における各種の技術的対策の実施有無を見極め、必要に応じて自社での対応や対策を検討・実施することが重要であり、例で出したAWSの場合、multi-AZ構成を設定することが対策といえるでしょう。
この現象は、いわば利用者とクラウドでの認識のギャップによって起きているともいえます。
「クラウドに任せておけば安心」「何か特別な操作は要らない」「なにかおきてもクラウドサービス側がなんとかしてくれる」
そんな認識は持たず、現在の状態で
- 機密性（confidentiality）
- 完全性（integrity）
- 可用性（availability）
は維持できているのかを常に考え、設定に不備はないか確認したり、脆弱性はないか確認することが重要な対策といえるでしょう。
まとめ
技術に関するクラウド上のセキュリティリスクを紹介しました。
クラウドにおけるセキュリティリスクの対策としては、クラウドサービスを提供する会社が、安全なクラウド環境を構築し、適切なセキュリティ対策が出来ているかが重要になります。
そのクラウドサービスを提供する会社の利用規約を読んだり、直接問い合わせて、どんな対策がとられているのか、どんな仕様になっているのか、守れているかどうかが大事になるでしょう。
