クラウドベースのアプリのセキュリティを確保するための最初のアプローチは、可能な限り多くの脆弱性を見つけて修正することだ。アプリのセキュリティ上の脆弱性を探す方法は数多く存在する。例えば、手動または自動ソースコードレビュー、汚染解析、Webスキャン、ファズテスト（※1）、フォールトインジェクション（欠陥注入）テストやシンボリック実行など。しかしながら、Webアプリのソフトウェア脆弱性を見つける場合は、これらの手法の全てが同じように適用できるわけではない。クラウドベースのアプリでは、アプリ自体の脆弱性だけでなく、OSやハイパーバイザーのような下位レイヤーの脆弱性の両方を考慮しなければならない。そのため、侵入テストサービスを採用してアプリをチェックし、検出されたあらゆる脆弱性に関するセキュリティ報告書を作成することは、常に有効な良い方策だ。

※1　ファズテスト（fuzz testing/fuzzing）：ランダムな不良データ（ファズ）を用いて、プログラムを攻撃し、どこに障害が発生するかを調べるテスト。

　セキュリティ検査を実施した後でも、ゼロデイ攻撃に対する脆弱性が存在する可能性について考慮しておくことが重要だ。しかし、検査の過程で、大部分の危険度の高い脆弱性は排除されるものである。

セキュリティの脆弱性の悪用を防ぐ

　クラウドアプリのセキュリティを最強にするための第2の戦略は、アプリの新しい脆弱性を発見するのではなく、既存の脆弱性が悪用されるのを防ぐことだ。こうした悪用を防止するための技術やツールが幾つかある。

ファイアウォール

　ファイアウォールは、非武装地帯（DMZ）との境界の特定ポートへのアクセスをブロックするために使用する。これで、攻撃者がインターネットから、または別のDMZから脆弱なアプリにアクセスする攻撃を防ぐことができる。

不正侵入検知（IDS）／不正侵入保護（IPS）

　IDS／IPSを使用して既知の攻撃パターンを探し出し、攻撃が対象のアプリに到達する前にブロックすることができる。

Webアプリケーションファイアウォール（WAF）

　WAFは、アプリケーションレイヤーでの悪質なパターンを探すために使用でき、SQLインジェクション、クロスサイトスクリプティング、パストラバーサル（パスの乗り換え）のような脆弱性を検出することが可能だ。WAFには、ブラックリスト方式、ホワイトリスト方式の2種類のソフトウェアがある。ブラックリスト方式のWAFが既知の悪質なリクエストだけをブロックするのに対し、ホワイトリスト方式のWAFは、デフォルトで全ての疑わしいリクエストをブロックする。ブラックリスト方式では、ブラックリストに存在しないリクエストでも、WAFを完全にバイパスしないようにクエリを再構築するのは簡単だ。ホワイトリストの方が安全だが、全ての有効なリクエストを手作業でプログラムしなければならないため、設定に多くの時間を必要とする。企業がWAFの構築に時間を投資する用意がある場合、WAFは最終的により強固なものになるだろう。NginxのWebサーバを運用している企業は、オープンソースのNaxsi Webアプリケーションファイアウォールをホワイトリスト方式として使用し、アプリを保護することを検討すべきだ。

コンテンツ配信ネットワーク（CDN）

　CDNは、インターネット経由で複数のデータセンターを介してコンテンツを配信し、Webページをより速くロードするためにドメインネームシステム（DNS）を使用している。ユーザーがDNSリクエストを送信すると、CDNはユーザーの場所に最も近いIPアドレスを返す。これは、Webページをより速くロードできるだけではなく、トラフィックはCDNを通って流れるため、結果的にシステムをサービス妨害（DoS）攻撃から保護している。通常、CDNはWAF、電子メール保護、稼働時間とパフォーマンスの監視、Googleアナリティクスなど、他の保護メカニズムも持っており、これらを使用することもできる。

認証

　2要素認証のメカニズムを可能な限り採用すべきだ。クラウドアプリへのログインに、ユーザー名とパスワードの組み合わせだけでは巨大な脆弱性となる。攻撃者はソーシャルエンジニアリング攻撃を通じて、この情報を収集できる可能性があるからだ。また、攻撃者はパスワードを推測したり、ブルートフォース攻撃（※2）で強引に解析したりすることも考えられる。なお、シングルサインオン（SSO）も、生産性を向上させると同時に、セキュリティを保持しつつ、全てのユーザーに適切なアクセス権を持たせることを保証する。

※2　ブルートフォース攻撃（Brute Force Attack）：力ずくで暗号を解読して、パスワードを取得する攻撃手段のこと。Brute Forceとは「力ずくで、強引に」という意味。

悪用による被害を局所的なものにする

　クラウドアプリに対するセキュリティ攻撃の被害を最小限にとどめるために、クラウドサービス事業者（CSP）がとり得る手段は幾つかある。

仮想化

　危険にさらされたアプリが与えるダメージを仮想環境のインフラだけに限定することでセキュリティを強化できる。だが、アプリを独自の仮想環境で実行するということは、企業や組織が稼働中の全てのアプリ用にOSを用意する必要があることを意味する。これは全くのリソースの無駄遣いであり、コンテナの人気がとても高くなっているのはこのためである。コンテナは、本格的な仮想化レイヤーを必要とせずに、システムの残りの部分からアプリを隔離することができるソフトウェアコンポーネントである。代表的なコンテナとして、Linuxコンテナ（LXC）やDockerが挙げられる。

サンドボックス

　ハッカーがバックエンドシステムへアクセスできても、アプリに対する攻撃の影響はサンドボックス環境内に限定される。そのため、OSへアクセスする攻撃を仕掛けるにはサンドボックスを突破する必要がある。LXCやDockerなどさまざまなサンドボックス環境が利用できる。

暗号化

　社会保障番号やクレジットカード番号などの重要な情報をデータベースに格納する際には、適切に暗号化しなければならない。アプリが暗号化をサポートしていれば、企業は既に暗号化された形態でデータをクラウドに送信することになる。

ログの監視／セキュリティ情報イベント管理（SIEM）

　攻撃が発覚した場合、攻撃がどこから来たのか、背後にいる攻撃者は誰か、いかにして問題を軽減するか、これらのことを迅速に判断するためのロギングシステムやSIEMを用意しておくとよい。

バックアップ

　適切なバックアップシステムは、何かがうまくいかなかった場合に非常に重要となる。正常に稼働するバックアップシステムを構築することは簡単ではなく、間違いなく運用するにはかなりの時間が必要だ。このため多くの企業は、バックアップのプロセスを外部委託することを選択する。

結論

　データをオンプレミスではなくクラウドに保持する場合、解決しなければならない新たなセキュリティ上の課題が多く存在する。だが幸いなことにこれらの課題を解決しやすくする方法もたくさんある。アプリの脆弱性を見つけて修正することは、脆弱性の悪用を防ぐことと同様に重要であり、また、悪意のある攻撃をブロックする適切な防御メカニズムを持つことと同じく、欠かすことのできないものでもある。

　これまでに述べたように、クラウドベースのアプリを保護するには多くの方法があるが、適切にセットアップするには時間と労力が必要になる。こうした制約があるため、企業は多くの場合、投資に対するリターンをすぐには見いだせず、セキュリティの重要性を軽視しがちだ。実際問題として、セキュリティはアプリのインフラが危険にさらされて初めて重要視されることが多い。しかしながら、そもそもアプリのセキュリティを強化し、脆弱性を防止するための適切な手順を取り、万が一、脆弱性が悪用された場合の対策を用意しておくことは、クラウドアプリ環境の成功とセキュリティのみならず、組織全体の活力にとっても、極めて重要である。