セキュリティの概要 (ADO.NET)
更新 : November 2007
アプリケーションのセキュリティ保護は継続的なプロセスとして行う必要があります。開発者は、アプリケーションがあらゆる攻撃に対して安全であることを常に保証できるわけではありません。これは、新しい技術がもたらす未知の攻撃を予測することが不可能なためです。反対に、システムに欠陥が発見 (または公開) されていない場合も、そのシステムに欠陥がないとは限りません。プロジェクトの設計フェーズでセキュリティを考慮することはもちろんのこと、アプリケーションの使用期間を通じてセキュリティをいかに確保してゆくかを計画しておく必要があります。
セキュリティのデザイン
セキュリティで保護されたアプリケーションを開発するうえで最大の問題は、プロジェクトのコードが完成した後にセキュリティが導入されるということです。つまり、セキュリティが補足的になりがちです。最初の段階でアプリケーションにセキュリティを導入しておかないと、十分な対策が講じられず、アプリケーションの安全性を損ねる結果となります。
最終段階でセキュリティが実装された場合、新しい制限によりソフトウェアが誤動作を起こしたり、予期していなかった機能を組み込むためにソフトウェアの書き換えが必要となって、バグの発生が増えます。また、書き換えたすべてのコードが新たなバグの原因となる可能性もあります。このような理由から、新しい機能の開発と平行して進めるよう、開発プロセスの早い段階でセキュリティを考慮する必要があります。
脅威モデリング
システムがどのような攻撃に曝されているかを理解せずに、攻撃からシステムを保護することはできません。ADO.NET アプリケーション上でセキュリティ違反の可能性およびその影響を調べるには、脅威のモデリングと呼ばれるセキュリティ上の脅威を評価するプロセスが必要です。
脅威のモデリングは、1) 攻撃者の視点を理解し、2) システムのセキュリティの特徴を把握し、3) 脅威を特定するという、大きく 3 つの手順で構成されます。
脅威のモデリングでは、反復的なアプローチによってアプリケーションの脆弱性を評価しながら、最重要データの漏洩につながる最も危険な部分を特定します。脆弱性を特定したら、それらを深刻度の順にランクを付けて脅威への一連の対策に優先順位を付けます。
詳細については、次のリソースを参照してください。
リソース |
説明 |
|---|---|
脅威のモデリング (MSDN セキュリティ デベロッパー センター) |
脅威のモデリング プロセスを理解し、開発したアプリケーションの脅威モデルを構築するうえで役に立ちます。 |
最小特権の原則
アプリケーションの設計、ビルド、および配置は、アプリケーションが攻撃されるという前提で行う必要があります。多くの場合、こうした攻撃は、コードを実行しているユーザーの権限で悪意のあるコードを実行することによって行われます。高い技術を持った攻撃者が脆弱性を悪用することによって作成したコードも存在します。セキュリティの計画を立てるときは、常に最悪のシナリオを想定するようにしてください。
コードを最小限の特権で実行することによって、できるだけ多層的にコードを防御することが対策の 1 つとして考えられます。最小限の特権では、常に必要最小限のコードに対し、その処理に必要な最小限の時間だけ権限を与えることが原則となります。
安全なアプリケーションを作成するためのベスト プラクティスは、まず、権限をまったく付与しない状態から始め、その後で、実行しようとする特定のタスクに必要な最小限の権限を追加してゆくことです。逆に、すべての権限を与えてから、不要なものを 1 つずつ拒否していく方法では、アプリケーションを危険にさらす結果となります。この場合、意図せずに必要以上の権限を付与することによってセキュリティ ホールを招く可能性があるため、安全性をテストすることも、管理していくことも困難です。
アプリケーションのセキュリティ保護の詳細については、次のリソースを参照してください。
リソース |
説明 |
|---|---|
一般的なセキュリティ トピックへのリンクが含まれています。分散アプリケーション、Web アプリケーション、モバイル アプリケーション、およびデスクトップ アプリケーションを保護するためのトピックへのリンクも含まれています。 |
CAS (コード アクセス セキュリティ)
コード アクセス セキュリティ (CAS) は、保護されたリソースや操作に対するコードのアクセスを制限するメカニズムです。.NET Framework では CAS によって次の機能が実行されます。
各種システム リソースにアクセスするための権限や権限セットを定義する。
管理者が一連の権限をコードのグループ (コード グループ) で関連付けることにより、セキュリティ ポリシーを構成できるようにする。
実行に不可欠な権限のほか、あった方がよいと思われる権限、決して与えてはならない権限をコードから要求できるようにする。
コードによって要求された権限およびセキュリティ ポリシーによって許可された操作に基づいて、読み込まれた各アセンブリに権限を付与する。
呼び出し元が特定の権限を所有していることをコードから要求できるようにする。
呼び出し元がデジタル署名を所有していることをコードから要求できるようにする。これにより、特定の組織またはサイトに属する呼び出し元以外は保護されたコードにアクセスできないようになります。
呼び出し履歴上で、各呼び出し元に付与された権限を、その呼び出し元に求められる権限と比較することにより、コードに対する制限を実行時に強制する。
攻撃を許した場合でも損害の規模を最小限に抑えるため、コードのセキュリティ コンテキストを選択し、コードの処理に必要なリソースへの権限だけを付与し、それ以外は実行できないようにする。
詳細については、次のリソースを参照してください。
リソース |
説明 |
|---|---|
ADO.NET アプリケーションの観点から、コード アクセス セキュリティ、ロール ベース セキュリティ、および部分信頼環境間の相互作用について説明します。 |
|
.NET Framework の CAS について説明する追加のトピックへのリンクが含まれています。 |
データベース セキュリティ
最小特権の原則はデータ ソースにも適用されます。データベース セキュリティの一般的なガイドラインは次のとおりです。
アカウントをできるだけ低い権限で作成する。
単にコードの正常動作を目的としてユーザーに管理者アカウントにアクセスさせることは避ける。
サーバー側のエラー メッセージをクライアント アプリケーションに返さない。
クライアントとサーバーの両方ですべての入力を検証する。
動的 SQL ステートメントは避け、パラメータ化コマンドを使用するようにする。
データベースのセキュリティ監査とログ記録を有効にし、セキュリティ侵害が発生した場合に警告を受けることができるようにする。
詳細については、次のリソースを参照してください。
リソース |
説明 |
|---|---|
SQL Server のセキュリティの概要を説明します。アプリケーションのシナリオを交えながら、SQL Server を対象とした安全な ADO.NET アプリケーションを作成するための指針を提供します。 |
|
データへのアクセスおよびデータベース操作の実行に関連した推奨事項について説明します。 |
セキュリティ ポリシーと管理
コード アクセス セキュリティ (CAS) ポリシーの管理が不適切だと、セキュリティの脆弱性を招く可能性があります。アプリケーションを展開した後は、セキュリティ監視技法を適用し、新しい脅威が現れた際はそのリスクを評価する必要があります。
詳細については、次のリソースを参照してください。
リソース |
説明 |
|---|---|
セキュリティ ポリシーの作成と管理について説明します。 |
|
セキュリティ ポリシーの管理方法について説明したトピックへのリンクを提供します。 |