クラウド上のセキュリティリスク(技術編)
企業でもクラウドサービスの利活用が一般的になってきた一方で、漠然と「クラウドサービスはよくわからないし、セキュリティ的に危険そうだから」といった印象をお持ちになっている方も多いのが現状ですが、クラウドサービスが有している具体的なリスクを知ることができれば、より建設的な議論ができるのではないでしょうか。
その一歩として、ENISA(欧州ネットワーク情報セキュリティ機関)発行の “Cloud Computing: Benefits, risks and recommendations for information security” に記載されている、クラウド上の様々なリスクをご紹介します。
この文書では、組織に関するリスク(7個)、技術に関連するリスク(13個)、法律に関するリスク(4個)という3つのカテゴリに分けて、計24個のリスクが紹介されています。
また、この文書は、ISO27017において、リスク分析を実施するための参考文献として紹介されている信頼性のおける内容となっており、クラウドに関わるご担当者様にはご一読をおすすめします。
今回は、技術に関するクラウド上のセキュリティリスク(13個)をご紹介します。
index
(1) リソースの枯渇
クラウドサービスは、複数の利用者により1台のサーバやネットワーク機器を共有していることが一般的です。
このような、複数の利用者が1つの機材を共有する形態を「マルチテナント」と呼んでいます。
物理的なサーバを利用しているわけですから、そのサーバの処理速度にも限界があります。
では、同じサーバを利用している共同利用者が、突然、高い負荷がかかる処理を開始するとどうなるでしょうか。
もしくは、単独ではそこまで高負荷ではないものの、いつもよりも少しだけ負荷がかかる処理を、複数の共同利用者が同時に実施した場合、どうなるでしょうか。
限られた物理サーバの処理能力を、マルチテナントによる利用者全員で分配して利用しているわけですから、当然、自社データの処理に影響が出る可能性があります。
分かりやすい例として、Twitterを見てみましょう。
Twitterを構成するシステムそのものは、多くのユーザーが利用(共有)しています。
また、日本国内のTwitterユーザーは、TV番組などでジブリ作品の「天空の城ラピュタ」が放送された場合、物語終盤で用いられるセリフとタイミングを合わせて、一斉に「バルス！」と投稿することがあります。
その瞬間、つまり、複数の共同利用者が一斉に「投稿」という処理を行った瞬間、Twitterのサービス全体の負荷が上がり、一部処理が遅延したり、投稿できなくなったりする可能性があります。
これが例えば、一秒の遅れも許されないビジネスの世界だったとして、高負荷が原因で操作が数秒間遅延してしまうと、場合によっては大きな損害を被る可能性があります。
このように、共同利用者の高負荷がかかる操作により、計算に必要な能力が奪われて、自社のシステムにも影響を与えてしまうことを「リソースの枯渇」と呼んでいます。
(2) 隔離の失敗
上記「リソースの枯渇」において、マルチテナントを採用しているクラウドサービスの場合は、複数の利用者が1つの機器を共有しているという説明をしました。
ということは、自社のデータと他社のデータが、同じサーバ内に保管されている可能性があるということです。
すなわち、自社のデータを読み書きする際には、まずは複数の利用者のデータが保管されているサーバにアクセスして、その中から自社のデータを選択して、取り出す必要があり、その概念を「隔離」と呼んでいます。
隔離には、いくつかのレベルがあります。
例えば、IaaSを利用している場合は、1つのサーバの上に、複数の利用者のOSが動いているため、OS同士を適切に隔離する必要があります。
また、SaaSを利用している場合は、1つのデータベースのテーブルの上に、複数社のデータレコードが存在している場合が一般的です。
SaaSの開発者は、ある利用者のデータが、他の利用者に取り出されないようにするために、安全な設計やプログラミングをする必要があります。
有名な攻撃手法である「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) セキュリティが確保されていない、または不完全なデータ削除
クラウドサービスを利用している自社の従業員が、間違えて重要なファイルをアップロードしてしまったことに気づき、急いで「削除」ボタンを押したところを想定してみてください。
ボタンを押して、しばらくすると、確かに、画面上のファイル一覧からは、間違ってアップロードしたファイルは表示されなくなりました。
しかし、これで安心でしょうか？
クラウドサービスの利用者は、削除ボタンをおした時、そのファイルが本当に「サーバ自体から削除された」のか、または「サーバにはデータが残っているが、画面上で見えなくなった」だけなのか、判断することは困難です。
※前者を「物理削除」、後者を「論理削除」と呼ぶこともあります。
利用者が実行できる削除操作が論理削除だった場合、クラウドサービスから情報が漏えいした際に、削除したはずのデータが流出してしまう可能性があります。
また、退会時のデータ削除にも注意が必要です。
自社がクラウドサービスの利用をやめるとき、自社のデータは、サーバにずっと残ったままになるのか、利用をやめるタイミングで削除されるのか、あらかじめ確認しておくことが大切です。
このように、データの削除における取り扱いが有するリスクを「セキュリティが確保されていない、または不完全なデータ削除」と呼んでいます。
(8) DDoS攻撃
DDoSとは「Distributed Denial of Service」の略で、日本語では「分散型サービス妨害攻撃」となります。
悪意のある第三者が、複数のサーバから、サービスに対して大量のアクセスを送り、処理をパンクさせ、サービスを利用不可にしてしまう攻撃です。
身近な例で言えば、Webブラウザでページを繰り返し再読み込み(更新)する、いわゆる「F5アタック」と呼ばれる操作を、複数のサーバから機械的に行う妨害攻撃と捉えても間違いではないかもしれません。
もし、クラウドサービスの提供元が、DDoS攻撃を始めとする様々な悪意のある第三者からの攻撃に対して十分な防御策を取っていないと、そういった攻撃を受けた際に、急にサービスが使えなくなったり、情報が流出したりする可能性があります。
クラウドサービスの利用者は、サービス提供元が技術的な防御策をとっていることを確認する必要があるため、リスクとして「DDoS攻撃」が挙げられています。
(9) EDoS攻撃
EDoSとは「Economic Denial of Service」の略で、日本語では「経済的なサービス妨害攻撃」となります。
あまり馴染みがないかもしれませんが、クラウドサービス利用者に経済的な負担を与えて、サービスの運用継続を妨げる攻撃手法です。
IaaS型のクラウドサービスの中には、利用する回数や通信量に対して利用料を請求する「従量課金制」を採用しているサービスが多く存在します。
身近なスマートフォンに例えれば、例えば、5GBまでのインターネット利用は定額の3000円で、それを超えると、1GBあたり1,000円の追加料金が掛かるというような料金形態です。
EDoS攻撃は、そのような料金形態のスマートフォン利用に際し、100GBや1,000GBなどといった莫大な量の通信を強制的に送り込むことで、利用者を経済的に破綻させ、サービスの利用を困難にさせる攻撃です。
これを回避するための方策は、大別して2種類です。
1つ目は、大量のアクセスを遮断するようなネットワークの設定を行うような技術的な対策です。
2つ目は、EDoS攻撃を受けた際の経済的な保証や免責事項について確認しておくなどの組織的な対策です。
また、対策とまでは言えませんが、一定の利用料金を超えた場合に、アラートやメールが届くようにするといった検知の仕組みを構築しておくことも重要です。
このように、クラウドサービスの課金形態上、攻撃を受ける可能性が少なからず存在する点を踏まえて、「EDoS攻撃」がリスクに挙げられています。
(10) 暗号鍵の喪失
タイトルは「暗号鍵」と記載していますが、一般的なパスワードのような、本来秘密にしておくべき認証情報が漏れてしまう事態も含めたリスクに関しても説明してみます。
クラウドサービスで利用するパスワードは、社内システムで利用するそれと比べ、厳重に守る必要があります。
それは、多くのクラウドサービスは、IDとパスワードさえ分かってしまえば、いつでも、誰でも、どこからでもアクセスすることが可能だからです。
そのため、クラウドサービスにおいて、パスワードが流出してしまうことは、最も忌避すべきリスクの一つであるとも言えるでしょう。
現時点において、このリスクを回避する最も効果的な方法は、「二段階認証」を採用することです。
インターネットバンキングでは、近年、ワンタイムパスワードを用いた二段階認証が盛んに導入されています。
また、GoogleAppsやDropboxをはじめ、多くの企業向けサービスでも二段階認証が用いられています。
クラウドサービスを利用する全ての従業員に二段階認証を求めるのは非現実的かもしれません。
しかし、例えば、管理者権限を持つユーザーなどに限って二段階認証を利用するように設定するだけでも、セキュリティレベルは大きく向上します。
このように、クラウドサービスにおけるパスワードや秘密にすべき認証情報の重要性と、それが漏えいした場合のリスクを鑑みて、「暗号鍵の喪失」がリスクに挙げられています。
(11) 不正な探査又はスキャンの実施
社内システムとクラウドサービス、悪意のある第三者に攻撃対象にされやすいのはどちらかと訊かれた場合、多くの人は、クラウドサービスの方が攻撃を受けるリスクが高いと考えるのではないでしょうか。
実際、社内システムを攻撃しようとすると、社内ネットワークに進入するなどのハードルが存在します。
一方、クラウドサービスの場合は、Web上のセキュリティホールを見つけたり、IDやパスワードを抜き取ったりと、攻撃可能な範囲を拡大しやすいケースが多い状況です。
それでは、クラウドサービスに対する攻撃として、どのような手法が考えられるでしょうか。
一般的で、かつイメージのしやすい攻撃手法の一つとして、パスワードの総当たり攻撃が挙げられます。
クラウドサービス利用者が、クラウドサービスを利用する際にアクセスする「ログイン画面」そのものは、誰でもアクセスすることが可能です。
ということはひょっとすると、今現在でも、悪意ある第三者が、あなたのアカウントに紐づくパスワードの総当たり攻撃を実施している最中かも知れません。
そのような攻撃によるリスクを回避するための対策としては、下記のような手法が一般的です。
- IPアドレスでログイン画面へのアクセスを制限し、自社のネットワークからのみ接続できるようにする。
- 十分に複雑なパスワードを設定する。
- ログイン試行履歴やログイン成功履歴一覧を確認し、不正なログインが発生していないか定期的に確認する。
このように、クラウドサービスにおける総当たり攻撃のリスクなどを鑑みて、「不正な探査又はスキャンの実施」がリスクに挙げられています。
(12) サービスエンジンの侵害
クラウドサービスでは、同一のサーバに自社と他社のデータが同居する「マルチテナント」が発生するケースが少なくないことは上述した通りです。
当該のサーバにおいては、自社のデータと他社のデータを適切に分離するためのソフトウェアが実装されており、ここではそれを「サービスエンジン」と呼びます。
※少しだけ技術的な話になりますが、IaaSのサービスエンジンにおいては、ハイパーバイザーという仕組みがよく用いられています。
そして、サービスエンジンがサーバ内に存在するソフトウェアである以上、自社が何らかの不適切な操作を行ったり、もしくは、マルウェアに感染したりすることで、このサービスエンジンの設定が変更されたり、乗っ取られたりするリスクが存在します。
幸いなことに、このようなリスクを突いた攻撃は、現時点ではそれほど多くは観測されていません。
しかし、仮にサービスエンジンが乗っ取られれば、自社データと他社データが適切に分離されていない隔離の失敗を引き起こすどころではなく、自社データの削除や窃取などが容易に実現可能になってしまいます。
このように、サービスエンジンへの攻撃に伴うリスクとして「サービスエンジンの侵害」が挙げられています。
(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構成が前提となっており、そしてその設定は、利用者自身が行う必要があります。
このように、クラウドサービスの利用者は、自社の情報を守るために、クラウドサービス側における各種の技術的対策の実施有無を見極め、必要に応じて自社での対応や対策を検討・実施しなければならないことを「利用者の強化手順と、クラウド環境との間に生じる矛盾」と表現しています。
技術に関するクラウド上のセキュリティリスクは以上となります。
クラウド上における他分野のセキュリティリスクを知りたい方は、下記もご覧ください。
- クラウド上のリスク(法律編)
- クラウド上のリスク(技術編) ※本ページ
- クラウド上のリスク(組織編)
取得される企業様の状況によって変わりますので、まずはお気軽にご相談ください。
