その他の今月のセキュリティ ヒントも参照してください。
トピック
概要 はじめに 1. ユーザー入力を直接信頼しない 2. サービスには、システム アクセスも管理者アクセスも許可しない 3. SQL Server のベスト プラクティスに従う 4. 資産を保護する 5. 監査、ログ作成、レポート機能を含める 6. ソース コードを分析する 7. 多層防御を使用して、コンポーネントを展開する 8. エンド ユーザー向けの詳細エラー メッセージをオフにする 9. セキュリティ管理に関する 10 の鉄則を理解する 10. セキュリティ障害対策計画を立案する 詳細情報 免責
概要
このホワイト ペーパーでは、セキュリティで保護された方法で Web アプリケーションや Web サービスを設計、作成、および展開するための一連の基本的なガイドラインを提供します。このホワイト ペーパーは、Web アプリケーションや IT セキュリティを使い慣れていない読者を対象にしています。完全な一覧を提供しているわけではありませんが、Web アプリケーションや Web サービスを始める出発点にはなります。
はじめに
このホワイト ペーパーでは、他のさまざまなソースから集めたヒントをベスト プラクティスとして提供します。これらのヒントは、Microsoft Windows ファミリのオペレーティング システムに Web アプリケーションを展開する際に使用することを目的としていますが、他の一般的な展開にも使用できます。トピックは 10個 のガイドライン (ヒント) に分けられていて、明確になるように各ガイドラインがさらに細分化されています。
1. ユーザー入力を直接信頼しない
だれかが、どこかで Web アプリケーションを攻撃しようとしていることは間違いありません。すべてのユーザーの入力は注意深く検証する必要があります。少なくとも入力の長さ、種類、形式、範囲などをチェックする必要があります。
実稼動に組み込むセキュリティを設計する 設計プロセスの最初からセキュリティについて考慮してください。後から追加しようとはしないでください。攻撃する立場から考え、最初の設計リビジョンから脅威モデルを作成します。脅威のモデリングは、設計プロセスに不可欠な部分です。コードを記述する前に潜在的な脅威を分析しておくことで、後から脅威を軽減する必要性と修正コストの両方を削減できます。注意深く設計することで、悪意のあるユーザーからの攻撃の確率を軽減できます。
クライアントのみでユーザー入力を検証しない 作成している Web アプリケーションはクライアント側の JavaScript ですべての入力を検証していますか。攻撃者がクライアント側のチェックが行われない、直接的な形式で送信を行うと、ビジネス ロジック層はどのように応答しますか。攻撃者は、クライアント側のチェックで一度でも発見されたことがあれば、クライアント側のチェックを迂回することがあるので、Web アプリケーションでユーザー入力を検証する必要があります。正しい形式のデータだけを許可し、不正な要求を拒否する正規表現は、入力を検証する手軽で、効率のよい方法で、次のポイントですぐに使用できます。
各層のデータを再検証する データの形式や型がビジネス ロジックにとって有効であることを再確認すると、データ ストレージ層のパフォーマンスがやや低下しますが、優れた多層防御の方法になります。また、ある層の欠陥や不具合が他の層に影響を及ぼすのを最小限に抑えることができます。再検証によるパフォーマンスの低下が大きすぎる場合は、データのソースの認証を検討し、システム全体の中で他に信頼されているコンポーネントにさかのぼれるようにします。
内部からの攻撃は行われないと想定しない すべての従業員を完全に信頼できますか。内部関係者との勝負を切り捨てないでください。信頼していても、確認してください。大規模組織、または社会保障番号やクレジット カード番号などの個人情報 (PII) が表示される内部 Web アプリケーションではこのことが特に重要です。機密情報は関係者のみに知らせる原則を守ってください。
2. サービスには、システム アクセスも管理者アクセスも許可しない
開発者やテスト スタッフは、最も制約が少ないという理由でローカル管理者としてサービスを実行することがよくあります。ローカル システムでサービスを実行しないとうまく機能しないということで、この方法は Web 開発にも持ち込まれます。高い特権でサービスを実行できるようにすると、Web アプリケーションでは小さなエラーがシステムを完全に危機に陥れることになるので、致命的な欠陥になります。作成または展開する Web アプリケーションでは、そのアプリケーションを実行するサーバーの管理権限を必要としないことを確認してください。
最小特権のユーザーアカウントを使用する サービスおよび Web アプリケーション プールは、ローカル ユーザー、ドメイン ユーザー、または事前定義済みのアカウント (ネットワーク サービスやローカル サービス) のいずれかで実行してください。MSDN には、その違いを説明する優れた記事が掲載されています (このホワイト ペーパーの「詳細情報」を参照してください)。これにより、侵害されたサービスから実行できることを制限できます。サービス アカウントが必要最低限のアクセス許可しか持たないようにシステムを構成すると、侵害された場合に影響を最小限に抑えることができます。
コンピュータ間アクセスにドメインユーザーアカウントを使用する Web サーバーのドメイン内にユーザーを作成し、そのユーザーで Web アプリケーションを実行します。インターネット インフォメーション サービス (IIS) 6.0 のアプリケーション プールを構成して、選択されたアカウントで実行し、匿名の Web サーバー認証要求にはそのアカウントを使用します。そのユーザー アカウントを使用して、サービスが展開されている異なるサーバー間の認証と承認を容易に制御することもできます。たとえば、そのアカウントを使用して、フロントエンド Web サーバーは中間層のビジネス ロジック層と通信できます。複数のフロントエンド Web サーバーが共通の中間層と通信する場合、サーバーごとに一意のアカウントを使用するか、または可能であれば、ネットワーク サービスとして実行するようにサービスを構成することを検討します。ここでいくつかの注意点があります。侵入者に Web サーバー ドメインへのアクセス権があり、ユーザー名がわかっていると、ロック アウトされるまでサービス アカウントとしてログオンを繰り返し試行することにより、サービス拒否攻撃を実行できます。
ローカルにログオンを許可しない 通常の状況下では、サービス アカウントがコンソールにログオンしたり、リモート デスクトップ セッション経由でログオンすることを許可しないでください。アカウントには、サービスとしてログオンすることだけを許可する必要があります。
パスワードを定期的に変更する パスワードを推測しようとする攻撃者が実在します。攻撃者が現在のパスワードの推測に成功する可能性を減らすために、サービス アカウントのパスワードを最低でも年 4 回変更します。標的が移動すると攻撃が難しくなります。より手の込んだ、力ずくの推測に対抗するために、パスワードを長くし (15 文字以上)、何らかの複雑性 (数字、記号、英大文字、英小文字の混在) を持たせてください。
3. SQL Server のベスト プラクティスに従う
多くの複雑な Web アプリケーションでは、バックエンドで SQL Server データベースが使用されます。SQL Server のセキュリティ機能を使用するためのいくつかの便利なヒントがあります。
SA を使用しない Web アプリケーションを関連するデータベースに接続するとき、システム管理者 (SA) を使用しません。代わりに、必要な特権だけを備えた特定のユーザーやロールをデータベースで構成します。SA ログインを使用することは、管理者としてサービスを実行するのと同じ影響があります。SA は、テーブルの削除、テーブルに含まれるすべてのデータの削除など、SQL Server のデータベースに対してほぼすべての操作を実行できます。
SQL Server アクセスを制御するために、ロールとログインを使用する 制限された状態から始め、必要に応じてユーザーのアクセス許可を追加します。特定のユーザーで実行されているサービスでは、データベースとの特定の相互作用のみが許可されるようにします。これは、Web アプリケーションに対して事前定義したロールで操作する権限だけが許可された SQL Server ログインを使用することで、簡単に実現できます。
サービスアカウントユーザーではテーブルに直接アクセスしない 多層防御手段として、サービス アカウントにはデータ テーブルへの直接アクセスを許可しません。その結果、攻撃者はデータベースで実行できる操作のうち、限定された一部の操作しか実行できないので、侵入によって生じる影響が最小限に抑えられます。データベースに顧客の機密データが含まれている場合は、この制限をすべてのスタッフに拡張することを検討します。この場合、データに基づいて作成される標準のレポートは、ストアド プロシージャを使用して作成する必要があることに注意してください。
パラメータ化クエリとストアドプロシージャを併用する Web アプリケーションと SQL Server との間のすべてのデータベース操作には、ストアド プロシージャ内に含まれるパラメータ化クエリを使用します。この方法では、データベース テーブルに関するすべての対話が厳密に制御され、使用前に入力パラメータが注意深く型チェックされます。この方法での SQL Server との対話に、テーブルへの直接アクセスの制限を加えると、クエリの挿入はほぼ不可能になります。次に例を示します。
CREATE proc sp_GetUserEmailAddress
@UserID uniqueidentifier
as
begin
select EmailAddress from Users where uid_UserID=@UserID
GO
Microsoft SQL Server Best Practices Analyzer を使用する Web アプリケーションでの Microsoft SQL Server の使用をダブルチェックする簡単な方法は、Best Practices Analyzer ツールの無償コピーを入手することです。Web アプリケーション データベースに対してこのツールを実行し、レポート内の各項目の提案事項の実装を検討します。
4. 資産を保護する
すべての Web アプリケーションには、CPU リソースやネットワーク帯域幅から、プライベート ユーザー データまで、保護すべき資産があります。資産の価値に応じて、それぞれを適切かつ長期的に保護することを検討してください。デジタル情報が盗まれてからでは、それを取り返すことは事実上不可能です。
暗号化キー Web アプリケーションである種の暗号化操作を行いますか。暗号化キーはどのように保護されていますか。攻撃者や内部関係者からの盗難を防ぐために、秘密キーや対称キーを数種類のハードウェア セキュリティ モジュール (HSM) に格納するかどうか検討してください。侵入者と判断される者を HSM で完全に阻止できるわけではありませんが、HSM を使用すると新たな防御層が確実に追加されます。さらに、上述のキーの使用を監査することで、何者かによる不正アクセスを示す痕跡を残すことができます。また、Microsoft Windows Server 2003 の一部であるデータ保護 API (DPAPI) は、機密性が低く、寿命の短いマテリアルの妥当なキー保護に容易に利用できます。Web アプリケーションやサービスでは、最低でも Windows Crypto API を使用します。既知の暗号化のアルゴリズムを改良したり、新しく興味深いアルゴリズムを作成しようとしないでください。このような作業は誤りが生じやすいので、暗号化は専門家にまかせ、その他の第一線の防御に集中します。
サービスアカウントの資格情報 Web アプリケーションを実行しているドメイン ユーザーのユーザー名とパスワードを紙に書いてサーバーに貼り付けたりしていませんか。サービス アカウントの資格情報は、選択した少数のスタッフしか知らないようにします。上述の資格情報のコピーを記述したり、格納している場合は、その情報へのアクセスを制限します (たとえば、安全なファイルや暗号化されたファイルなどに保管します)。
ユーザーデータ ユーザー データは社内ユーザーのだれもがアクセスできるデータベース内にありますか。そのデータには PII が含まれていますか。それは、カード番号などの金融に関する機密情報ですか。ユーザー データへのアクセスは、関係者のみに知らせるという原則を守ってください。また、ある種のデータは管理が規制されるので、法律で必要な適切なレベルの保護について、法務部門に確認します。たとえば、特定の Web サービスにとっては、暗号化形式でデータを格納し、暗号化されていないデータに誰がアクセスしたかを注意深く監視するだけ十分です。
5. 監査、ログ作成、レポート機能を含める
レポートは統計ばかりを取っているわけではありません。堅牢なログやレポートの作成は、Web アプリケーションの測定結果を分析する必要がある人だけに役立つわけではなく、運用スタッフや障害対応チームにとっても役立ちます。これはすべての Web アプリケーションやサービスにとって重要な部分です。
ログ記録データを安全に保管する Web アプリケーションのトランザクションやその他さまざまな詳細に関して収集したデータは、アクセスが制限された、安全な場所に保管します。また、未加工のログ記録データを、オフラインでセキュリティで保護された場所に定期的 (毎日または毎週) に移動することを検討してください。ログ記録したレコードの再使用については注意深く検討します。ログ記録システムがいっぱいになったとき、古いエントリが自動的に削除されますか。削除する必要はありますか。適切で正当なログ記録エントリを含むログ記録システムをスパムし、悪用の証拠を示す古いエントリを強制的に削除するのが、追跡を覆い隠すための攻撃者の常套手段です。
履歴レコードを保管する 法的なガイドラインや要件を満たすためには、どの程度の期間ログ データの履歴を保管する必要があるかを弁護士に相談します。ただし、完全に保管しておく必要がなくなったデータは、毎月、毎四半期、毎年のデータのサマリを保管するようにします。その結果、後々のために過去の傾向データが保管され、障害対応時に侵害された日付を特定できる可能性があります。
データに署名する 保管されているログ データが改ざんされていないことを実証するために、デジタル署名の使用を検討してください。ログ データが訴訟で証拠として提出された場合、デジタル署名が役立つことがあります。
収集と一元管理 一部の詳細情報はサーバー単位にログオンして収集する必要があります。ただし、バックエンドでデータを収集し、一元管理することで、現在の稼動状態やシステムのセキュリティを適切に把握できます。
Microsoft Enterprise Library の使用を検討する Microsoft では再利用のために、一連の優れた拡張性の高いアプリケーション ロジックを Enterprise Library に作成しました。Web アプリケーションの多くの共通機能が既に作成され、使用する準備が整っています。詳細については、このホワイト ペーパーの「詳細情報」から「patterns & practices Enterprise Library」を参照してください。
6. ソース コードを分析する
セキュリティに注目してソース コードを注意深く確認すると、潜在的なセキュリティ ホールやリスクを発見できます。『Writing Secure Code 第2版 (上) プログラマのためのセキュリティ対策テクニック』には一読すべき優れた推奨事項がいくつか記載されています。
コードレビューを実施する 特定の機能に関する作業を行っている関係者を集め、1 行ごとにソース コードをレビューします。見つかったすべての問題点が合意済みの方法で変更されたことを確認します。特定した問題点を修正しなければ、コード レビューの意味はありません。したがって、分析するだけではなく、問題点の修正も計画します。
バッファオーバーフローに注意する システムのある部分で、意図したよりもより多くのデータが入力されるとバッファのオーバーフロー (BO) が発生します。これは、1 ガロンのジュースを 1 クオートの容器に詰め込もうとしているようなものです。あふれた部分は、サービス拒否攻撃 (DoS) の作成から、ランダムなコード群の実行まで、あらゆることに利用できます。BO を防ぐ最善の方法は、最初の段階で存在しないようにすることです。また、Windows Server 2003 Service Pack 1 や 64 ビット プロセッサに含まれているデータ実行防止 (DEP) により、いくつかの追加の防御策が提供されます。ネイティブ コードは、特にバッファのオーバーフロー状態の影響を受けやすくなります。すべての入出力バッファのコードを注意深く確認してください。次の例 (「Defend Your Code with Top Ten Security Tips Every Developer Must Know」 (英語) からの抜粋) では、ソース データの長さが適切に制限されていない場合に、バッファ オーバーフローが発生する典型的な関数を示しています。
void DoSomething(char *cBuffSrc, DWORD cbBuffSrc) {
char cBuffDest[32];
memcpy(cBuffDest,cBuffSrc,cbBuffSrc);
}
整数のオーバーフローに注意する 整数のオーバーフローは、収容可能な数値よりも大きな数値を格納しようとする点で BO に似ています。整数のオーバーフロー状態はマネージ コードでさえその影響を受けやすく、結果的には、BO のように DoS が行われたり、攻撃者が目論む少量のコードが実行されます。すべての入出力バッファのコードを注意深く確認してください。次の例では、i が -1 に等しい場合、DIVIDE BY 0 例外が発生します。
Int16 i = getFromNetwork();
if (i <= MAX) {
i++;
Int32 j = 8192 / i;
}
また、次の例では変数 req が 32767 を超えると、負の数値として解釈され、配列のバインドの例外が返されます。
Int16 req;
...
while (true) {
getRequest();
req++;
arr[req] = DateTime.Now;
}
バッファ オーバーフローと同様に、整数のオーバーフローに対する最善の防御は、整数がオーバーフローするようなコードをなくすことです。すべての動的メモリ要求を注意深くレビューして、整数オーバーフローの可能性を探し、適宜テストを行ってください。
クロスサイトスクリプティングに注意する ほとんどの複雑な Web アプリケーションは、特定のサブタスクを実行するために、他の Web アプリケーションを呼び出します。これは便利ですが、この操作にはリスクが伴います。他の Web アプリケーションを呼び出すために使用する URL をユーザーに入力させる場合は、さらにリスクが高くなり、あるユーザーから他のユーザーを攻撃するために使用されることがあります。クロスサイト スクリプティングによる攻撃が起こらないように、ユーザー操作を処理するコードをレビューします。次のスクリプトを考えてみましょう。
<script language=c#>
Response.Write("Hello, " + Request.QueryString("name"));
</script>
名前のソースが信頼できない場合、Web サイトのリダイレクト スクリプト、サイトの Cookie の盗用の試みなど、事実上あらゆる状況が含まれる可能性があります。
正規化の問題に注意する ファイル パスや URL は、多くの場合、いくつか異なる方法で表すことができます。すべての機能を注意深くレビューして、フォーマットに関して予期しない結果を引き起こす可能性のある想定をすべて検索してください。たとえば、URL は ASCII テキストのみで表現できるだけでなく、UTF-8 でエンコードすることもできます。
危険な関数を検索する 『Writing Secure Code 第2版 (上) プログラマのためのセキュリティ対策テクニック』には一連の優れた付録が付いており、よく誤用され、そのために潜在的なセキュリティ ホールが残るような標準関数が一覧されています。危険な関数へのすべての参照を、ここで推奨されている代替関数に置き換えることを検討してください。
自動スキャンを使用する 自動ソース コード分析ツールを使用すると、コード レビュー プロセスが高速化され、一貫性のあるフィードバックを提供できます。これらのツールを正規のビルド プロセスに組み込むには時間がかかりますが、この時間は後で取り戻すことができます。一部のツールは誤った結果を示すときもあるので、警告を注意深く確認するようにしてください。また、開発環境ではコンパイラの警告をエラーとして扱う機能をオンにします。この結果誤ったエラーが発生することもありますが、これは優れたファーストレベルのコード スキャンです。今後のバージョンの Microsoft Visual Studio には、一般的な問題点を検索し、簡潔なレポートを生成する FXCop や PREFast などのツールが含まれます。これらのツールを実行後に個別にサマリを確認して、各問題点の発生状況をチェックし、ソース コードを適切に修正できます。
7. 多層防御を使用して、コンポーネントを展開する
セキュリティ ホールの可能性があるからといって、すべてが終わったというわけではありません。特定のセキュリティ テクノロジが失敗した場合に備えて、直接的なリスクや二次的なリスクを軽減する方法を定義します。軽減方法を定義、設計、および作成したら、テストを行います。適切に設計されたソフトウェアは失敗しても対策が施され、セキュリティで保護されたモードになることを覚えておいてください。疑わしい場合は、アクセスを拒否します。セットアップや展開のプロセスで、Web アプリケーションが操作を行うために必要な最低限の特権以上のものが構成されないことを確認します。このようなレビューを支援する優れたツールに、VeriTest-Rational Installation Analyzer があります (このホワイト ペーパーの「詳細情報」から一覧を参照してください)。セットアップの前後に Installation Analyzer 使用をして、何が変更されたかを確認します。
すべての依存関係の展開ベストプラクティスに従う Web アプリケーションは Microsoft Exchange Server に依存していますか。Microsoft SQL Server 2000 に依存していますか。Web サイトは IIS 5.0 と連携していますか。依存関係にあるテクノロジの一覧の中でどれが必要かにかかわらず、それぞれのセキュリティのベスト プラクティスを使用して展開します。一般的な展開ガイドへのリンクについては、このホワイト ペーパーの「詳細情報」から一覧を参照してください。
2 層または 3 層アーキテクチャを使用する Web アプリケーションのデータ ストア (通常は SQL Server) は、顧客のトラフィックが着信するのと同じパブリック ネットワークから直接アクセスできないようにしてください。フロントエンド Web サーバーとは独立して Web アプリケーションを展開するために、パブリック ネットワークとプライベート ネットワークを保持します。また、ビジネス ロジックをプレゼンテーション層 (Web サーバー) から分離することを検討してください。その結果、柔軟性が向上し、必要に応じてより優れたセキュリティを展開できるようになります。
Web サーバーで SSL を使用する Web アプリケーションは、個人情報 (PII) などの顧客の機密データを送受信しますか。その場合は、Secure Sockets Layer (SSL) またはインターネット プロトコル セキュリティ (IPSec) のいずれかを使用して、クライアントとの Web サーバー セッションを暗号化することを検討してください。これにより、データ転送中に侵入者が偶然にデータを監視したり、または積極的にデータを改ざんする可能性を軽減できます。使いやすくするために、顧客のシステムが信頼しているルート証明機関から証明書を取得するようにします。ただし、SSL には制限があります。SSL は 2 つのエンド ポイント間のセッションの暗号化を提供するだけで、現在の両当事者が誰なのかを大まかに保証するだけです。しかし、すべての Web アプリケーションにとって優れた出発点ではあります。
すべての場所にファイアウォール、ネットワークセグメント、ACL を設置する ファイアウォール、セグメント化、およびルーターのアクセス制御リスト (ACL) を組み合わせて、Web アプリケーションのさまざまな部分を可能な限り分離します。このような組み合わせはバリケードとして機能して、危険性の拡散を低速化または中断し、アラートや警告を発して適切な障害対応を可能にします。たとえば、ビジネス ロジック層 (BLL) サーバーは、SQL Server を実行しているコンピュータと通信する唯一のサーバーになるようにします。そのため、ルーター ACL でこれが設定されるようにします。Microsoft Internet Security and Acceleration Server 2004 などのステートフル パケット インスペクション ファイアウォールでは、トラフィックを分析して、トラフィックが特定の宛先ポートの形式と種類に実際に一致することを確認することもできます。たとえば、ステートフル パケット インスペクション ファイアウォールは、SQL Server のインスタンスとビジネス ロジック層との間のトラフィックが、HTTP メッセージや DNS メッセージではなく、何らかの適切な SQL Server トラフィックのように見えることを保証するのに役立ちます。Web アプリケーションやサービスで使用されるすべてのファイルに、適切な最小特権の ACL を含めます。簡単に言うと、Web アプリケーション用に作成されたもの、または Web アプリケーションで使用されるものには、何らかの ACL が必要です。
バックエンドのネットワークトラフィックの暗号化を検討する 実運用展開は、他のさまざまな Web サイトとデータ センターを共有しますか。他のサーバーのいずれかが侵害され、プライベート ネットワークでリッスンしている場合、PII が見えてしまうことになりますか。その場合は、SSL または IPSec を使用して、バックエンドのネットワーク トラフィックを暗号化することを検討してください。これにより盗み見を防ぐことができ、コンピュータ間ネットワーク認証の形態として使用することもできます。
8. エンド ユーザー向けの詳細エラー メッセージをオフにする
攻撃者が目標を下見する方法の 1 つに、エラー メッセージに示される微妙な細部を探す方法があります。Web アプリケーションが実運用環境に展開された後、つまり、実際に使用する段階になったら、詳細なエラー応答やエンド ユーザーへのデバッグ メッセージはオフにします。
ローカルエラーのみ 実際の Web アプリケーションで問題が発生した場合、スタック トレースなどのデバッグ メッセージはアプリケーション イベント ログに送信します。この方法を使用すると、詳細を公開しなくても問題を詳しく診断できます。
エラーをバックエンドに報告する 完全なスタック トレース、変数、システム情報などのエラーの詳細は、Web アプリケーションの監査、ログ記録、およびレポート処理機能に送ります。このようなデータは、侵入が行われた場合に、どのように行われたかを分析する際に役に立ちます。
攻撃の兆候を監視する 1 つのクライアントで、短期間に繰り返し同じようなエラーが頻発していますか。それは実際に有効な顧客ではなく、セキュリティ ホールを探している攻撃者ですか。攻撃の兆候 (たとえば、認証の失敗の繰り返し) が見つかった場合は、セキュリティ障害対応が必要かどうか検討するよう、システムから運用スタッフに警告を発します。また、侵入の証拠となる兆候の監視を支援するために、サードパーティの侵入検知システムの展開を検討してください。
9. セキュリティ管理に関する 10 の鉄則を理解する
Web アプリケーションの作成や運用に関わるすべてのスタッフは、セキュリティ管理の 10 の鉄則に精通している必要があります。これらの優れたガイドラインを次に示します。
すべてのシステムをセキュリティで保護する セキュリティで保護されていないシステムへの Web アプリケーションの展開には価値がありません。必要に応じて修正プログラム、ウイルス対策ソフトウェア、およびファイアウォールを使用して、すべてのシステムを保護します。これは、インターネット経由で通信する Web アプリケーションにとっては特に重要です。
10. セキュリティ障害対策計画を立案する
侵入が行われた場合、チームはどのように対応するのでしょうか。前もって事態を考慮しておけば、対応時間や通常の運用に戻るまでの時間に大きな違いが出ます。CERT Coordination Center には、通常のセキュリティ障害対応計画 (SIRP) で何をすべきかに関する優れた資料があります。詳細については、このホワイト ペーパーの「詳細情報」から「Responding to Intrusions」(英語) を参照してください。
誰を呼び出すのかを把握する 必要なスタッフに警告を発するための連絡網を計画します。上層部の管理部門、開発部門、プログラム管理部門、テスト部門、運用部門、人事部門、法務部門などを、一覧に記載する必要があります。また警察署、インターネット サービス プロバイダ、金融機関など、サードパーティの連絡先の情報も含めます。
最善の結果を期待し、最悪の事態に備える 理想は SIRP を使用しないことですが、万一に備えて作成しておく必要があります。前もっていくつかのシナリオを考えておきます。たとえば、Web サーバーに何らかの方法で侵入された場合、何が起きるのでしょうか。シナリオごとに対応計画を作成し、フィードバックを集めます。すべてを文書化し、適切な障害対応担当者のみが入手できるような既知の場所に置きます。
計画に従う セキュリティ障害が検出された場合、一般的な計画とその状況の種類に応じた特定のガイドラインに従います。最悪の事態を招く可能性があるのは、障害を検知してから、あわてて対応策を練り直そうとすることです。
計画に従わない場合を把握する 同じセキュリティ障害が起こることはめったにありません。一般的な対応計画はあらゆる状況を想定しているので、場合によっては計画とはやや異なる対応が必要になることがあります。プロセスに厳格になり過ぎないでください。望ましい結果を実現するためには、必要に応じて柔軟に対応できるようにしてください。
事後分析を行う セキュリティ障害が解決したら、発生方法と原因を分析します。障害とその対応を時系列で調べ、その効果をチェックします。どのようにすればプロセスをより効果的にできるでしょうか。最初の段階で障害を防ぐにはどのようにすればよいでしょうか。率直に分析することは必要ですが、非難にならないように注意してください。
フィードバックや学んだ教訓を組み込む 対応計画の有効性を分析した後で、そのフィードバックを計画に組み込みます。優れた SIRP とは、時間の経過と共に適宜変更できるドキュメントです。時間の経過と共に変更を加えていくときは、計画の変更履歴をとるようにします。
詳細情報
このホワイト ペーパの詳細情報の完全な一覧 (英語) を参照してください。
免責
このドキュメントは暫定版であり、ここに記載されたソフトウェアの最終的な製品版の発売時に実質的に変更されることがあります。
このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関するマイクロソフトの確約とは見なされないものとします。また、発行以降に発表される情報の正確性に関して、マイクロソフトはいかなる保証もいたしません。
このホワイト ペーパーに記載された内容は情報提供のみを目的としており、明示、黙示または法律上の規定にかかわらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。
お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。ただしこれは、著作権法上のお客様の権利を制限するものではありません。
マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。
別途記載されていない場合、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、出来事などの名称は架空のものです。実在する商品名、団体名、個人名などとは一切関係ありません。
© 2005 Microsoft Corporation.All rights reserved.
Microsoft、MSDN、Visual Studio、Windows、および Windows Server は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。
記載されている会社名、製品名には、各社の商標のものもあります。