Windows Azureのセキュリティを簡単に向上させる3つの対策

Windows Azureのセキュリティ機能は比較的手早く実装でき、わずかなコードの変更で済む。セキュリティ専門家がこれについて知っておくことは役に立つはずだ。

公開 2012年08月16日 08時02分

更新 2012年09月04日 12時21分

著者

Ed Moyle

[TechTarget]

印刷する

　PaaS（Platform as a Service）にはアプリケーションセキュリティの知識が不可欠だ。PaaS環境を使っている企業にとって、開発者教育とソフトウェア開発ライフサイクルプロセスへの投資は欠かせない。しかし全般として、企業はアプリケーションセキュリティへの投資をあまり積極的に行ってこなかった。

Windows Azureのセキュリティに関する記事

　PaaSを重点的に使用している環境では、アプリケーションセキュリティに投資している間、短期的にPaaSセキュリティの溝を埋めるためにどんな対策が有効かという点がセキュリティ専門職にとっての課題となる。例えばWindows Azure（以下、Azure）の場合、開発に主眼を置いた米Microsoftのセキュリティリソースが豊富にあるのは素晴らしい。だがアプリケーションが既に開発済みの場合はどうか。そのアプリケーションにSDL（セキュリティ開発ライフサイクル）やThreat Modelingを組み込む時間はないかもしれない。

　こうした立場に置かれた場合、知っておくべきことは2つある。まずAzure環境自体が、そこにあるアプリケーションを守るための極めて手堅いセキュリティ機能を提供している。これにはネットワークレベルのコントロール、物理的セキュリティなどの対策が含まれる。だがこうした防御はまだ道半ばにすぎない。いかなる環境も、どれほど優れた防御策を講じていても、未解決のアプリケーションレベルの問題を通じて攻撃される可能性は残る。幸いなことに、アプリケーションが完成した段階で層を重ね、ある程度の防御をアプリケーションレイヤーで追加できる機能が幾つかある。

　アプリケーションセキュリティ対策として利用できるのは、こうした当面の対策だけにはとどまらない。いずれにしても講じるべき対策（例えばSSL）がここには含まれていないし、あらゆる使用事例に一律に当てはめることもできない。それでもAzureのセキュリティ機能は比較的手早く実装でき、ほとんどがわずかなコードの変更で済み、ビジネスロジックの集中的なテストをやり直さなくても既存のアプリケーションに何度でも組み込める。従ってセキュリティ専門職の人がこれについて知っておくことは役に立つはずだ。

PaaSのセキュリティに関する記事

1．部分信頼

　管理者権限を持たないユーザーがネイティブOS上でコードを実行しアプリケーションを破壊する攻撃に出ても、Azureはそのままの状態である程度の防止策を講じている（これは呼び出し側にはほとんど見えない）。しかしさらに進んで信頼レベルを「完全信頼」ではなく「部分信頼」に設定すれば、1つのロールに割り当てるアクセス許可を制限できる。

　このコンセプトは従来の.NET Frameworkのセキュリティモデルに詳しい向きなら理解できるはずだが、要はアプリケーション自体ができることを制限して、アプリケーション自体のセキュリティ問題による影響を抑え込むということだ。部分信頼のコンセプトは、一部のWebサーバやアプリケーションがファイルシステムの「Jailed」や制限された権限モデルを採用しているのとよく似ている。Microsoftは部分信頼の設定で利用できる機能の一覧と、Visual Studioでこれを有効にする方法について解説した文書を公開している。

　ただし注意しなければならない点もある。部分信頼は比較的小規模なアプリケーション／サーバには有効な手段かもしれないが、規模が大きかったり複雑だったりした場合（例えばレガシー.NETアプリケーションからの直接的な移植など）、機能させるためには完全信頼のパーミッションが必要になる公算が大きい。

2．AntiXSSライブラリ

　アプリケーションコンテキスト（さらに具体的にはWebアプリケーションコンテキスト）内部で発生する問題の多くは、不正な入力に起因する。言い換えれば、アプリケーション処理の一環として入力が制限または検証されない限り、ユーザーが行う入力は一般的な攻撃経路になる。制限や検証は容易ではない。フィルタリングすべきものとその理由、そのフィルタリングが包括的かどうかを検証する方法についてビジネスロジックの開発者に理解してもらうのは、一般的に相当の労力（そしてトレーニング）を要する。

　この理由から、MicrosoftはWeb Protection Library（WPL）を無償で公開し、開発者向けに入力値検証の定型ライブラリを提供することで、こうした問題をある程度相殺する一助として利用できるようにしている。WPLの中にあるこの「AntiXSS」ライブラリにはユーザーの入力をコード化する機能があり、これによって攻撃者が入力フィールドを破壊してアプリケーションの動作に悪影響を与えられる可能性は低くなる。

3．診断の活用

　攻撃を防ぐための次善策は、攻撃が起きたことを知る何らかの手段を持つことだ。従来型のオンプレミスアプリケーションを運用しているケースなら、アプリケーションレベルのセキュリティリスクを相殺するためにログ記録と検出コントロールの強化を施すだろう。同じ戦略はAzureにも応用できる。具体的には、Azureの診断機能の設定によって、アプリケーション自体に既に存在しているもの以外にもセキュリティ関連情報を追加できる。IISログ、インフラログなどのログ記録はアプリケーションを監視する手段になり得るし、いったん導入すれば集中的な計画やコーディングや再検証の必要もない。

　もちろん、以上のような対策はPaaSセキュリティに包括的な答えを出すものではない。組織としてライフサイクルに重点を置いた長期的かつ高度な方法を目指すことが理想だ。それにはソフトウェア開発ライフサイクルとプロセス変更を通してアプリケーションにセキュリティを焼き付けることも含まれる。だが、コード変更に集中するのが難しく、急ぎで対策を打ち出す必要に迫られている場合、以上のような手っ取り早い措置が役に立つかもしれない。

印刷する