安全なデータ アクセス (ADO.NET)
更新 : November 2007
セキュリティで保護された ADO.NET コードを作成するには、基になるデータ ストア、つまりデータベースで利用可能なセキュリティ機構を理解しておく必要があります。さらに、アプリケーションに含まれる他の機能またはコンポーネントのセキュリティへの影響も考慮する必要があります。
認証、承認、および権限
Microsoft SQL Server に接続する場合は、Windows 認証 (統合セキュリティ) を使用できます。Windows 認証では、ユーザー ID とパスワードを渡さずに、現在のアクティブな Windows ユーザーの ID を使用します。ユーザー資格情報が接続文字列内で公開されないため、Windows 認証を使用することを強くお勧めします。SQL Server への接続に Windows 認証を使用できない場合は、SqlConnectionStringBuilder を使用して、接続文字列を実行時に作成することを検討してください。
認証に使用する資格情報は、アプリケーションのタイプに基づいて、それぞれ個別に処理する必要があります。たとえば、Windows フォーム アプリケーションでは、ユーザーに認証情報の入力を求めたり、ユーザーの Windows 資格情報を使用できます。Web アプリケーションでは、ユーザーではなくアプリケーションより提供された資格情報を使用してデータにアクセスする場合がよくあります。
いったん認証されたユーザーは、与えられた権限に基づく範囲で操作を実行できます。常に最小特権の原則に従い、どうしても必要な権限以外は付与しないようにしてください。
詳細については、次のリソースを参照してください。
リソース |
説明 |
|---|---|
保護構成を使用して接続文字列を暗号化する方法など、セキュリティのベスト プラクティスと接続情報を保護する手法について説明します。 |
|
データへのアクセスおよびデータベース操作の実行に関連した推奨事項について説明します。 |
|
実行時にユーザー入力から接続文字列を構築する方法について説明します。 |
|
SQL Server のセキュリティ アーキテクチャについて説明します。 |
パラメータ化コマンドと SQL インジェクション
パラメータ化コマンドは SQL インジェクション攻撃への対策として利用できます。SQL インジェクション攻撃は、SQL ステートメントに、サーバーのセキュリティを侵害するコマンドを "注入" することによって行われます。パラメータ化コマンドを使用した場合、外部ソースから受け取る値が必ず値として渡され、Transact-SQL ステートメントの一部になることはないため、SQL インジェクション攻撃を防ぐことができます。Transact-SQL コマンドが値に挿入されたとしても、データ ソースに対して実行されることはありません。これらのコマンドは、単なるパラメータ値として処理されます。セキュリティ面の利点に加え、パラメータ化コマンドには、Transact-SQL ステートメントで渡される値やストアド プロシージャに渡される値を簡単に扱うことができるという利点もあります。
パラメータ化コマンドの使い方の詳細については、次のリソースを参照してください。
リソース |
説明 |
|---|---|
DataAdapter でパラメータを使用する方法について説明します。 |
|
パラメータの指定方法および戻り値の取得方法について説明します。 |
|
SQL Server のストアド プロシージャを使用してデータ アクセスをカプセル化する方法を説明します。 |
スクリプト攻略
Web ページに悪意のある文字を挿入することによって行われるスクリプト攻略もインジェクション型の攻撃に属します。挿入された文字はブラウザによって検証されることなく、ページの一部として処理されます。
詳細については、次のリソースを参照してください。
リソース |
説明 |
|---|---|
スクリプトによる攻略および SQL ステートメントによる攻略から保護する方法について説明します。 |
プローブ攻撃
攻撃者は、システムを攻撃するときに、サーバー、データベース、テーブルなどの名前を例外情報から取得して使用することがよくあります。例外には、アプリケーションやデータ ソースに関する具体的な情報が含まれている場合があるので、アプリケーションとデータ ソースの保護を強化するには、クライアント側に不可欠な情報だけを公開するようにします。
詳細については、次のリソースを参照してください。
リソース |
説明 |
|---|---|
try/catch/finally 構造化例外処理の基本的な形式について説明します。 |
|
例外処理のベスト プラクティスについて説明します。 |
Microsoft Access および Excel データ ソースの保護
セキュリティ要件が最小限の場合、またはセキュリティ要件がまったく存在しない場合は、Microsoft Access や Microsoft Excel を ADO.NET アプリケーションのデータ ストアとして利用できます。セキュリティ面では、"関係者以外には触らせないようにする" とった程度であれば十分な抑止効果がありますが、それ以上のセキュリティを求めることはできません。Access および Excel の物理データ ファイルはファイル システム上に存在するため、原則的にすべてのユーザーがアクセスできます。ファイルは容易にコピーしたり改変したりできるため、データの盗難や損失といった攻撃には決して強くありません。堅牢なセキュリティが必要な場合は、SQL Server など、物理データ ファイルをファイル システムから読み取ることのできないサーバー ベースのデータベースを使用してください。
Access データおよび Excel データの保護の詳細については、次のリソースを参照してください。
リソース |
説明 |
|---|---|
Access 2007 のセキュリティ手法 (ファイルの暗号化、パスワードの管理、新しい ACCDB 形式および ACCDE 形式へのデータベースの変換、他のセキュリティ オプションの使用など) について説明します。 |
|
Excel 2007 のデータにアクセスしたり変更したりできるユーザーを制御する方法について説明します。 |
|
Access 2003 を対象としたトピックです。Access 2003 でユーザー レベルのセキュリティ機能を実装し、データを保護する方法について説明します。 |
|
Access 2003 のセキュリティの作業グループ情報ファイルのロールおよびリレーションシップについて説明します。 |
|
Microsoft Access セキュリティの FAQ (Microsoft Access バージョン 2.0 ～ 2000) |
ダウンロード可能なバージョンの Microsoft Access セキュリティ FAQ です。 |
Excel 2003 のセキュリティに関する一般的な問題の解決方法が掲載されています。 |
Enterprise Services
COM+ は、Windows NT アカウントおよびプロセスやスレッドの偽装に基づく独自のセキュリティ モデルを備えています。System.EnterpriseServices 名前空間は、.NET アプリケーションが、ServicedComponent クラスを使用して、マネージ コードと COM+ セキュリティ サービスを統合できるようにするラッパーを提供します。
詳細については、次のリソースを参照してください。
リソース |
説明 |
|---|---|
マネージ コードを COM+ セキュリティ サービスに統合する方法について説明します。 |
|
EnterpriseServices 名前空間のクラスを使用して、サービス コンポーネントを作成する方法について説明します。 |
アンマネージ コードとの相互運用性
.NET Framework は、COM コンポーネント、COM+ サービス、外部のタイプ ライブラリ、各種のオペレーティング システム サービスなど、アンマネージ コードとの相互運用性をサポートします。アンマネージ コードを使用することは、マネージ コードのセキュリティ境界の外に出ることを意味します。作成するコード、およびそれを呼び出すコードのどちらにも、アンマネージ コード権限 (UnmanagedCode フラグが指定された SecurityPermission) が必要です。アンマネージ コードは、意図しないセキュリティ上の脆弱性をアプリケーションにもたらす可能性があります。どうしても必要な場合を除き、アンマネージ コードとの相互運用は避けてください。
詳細については、次のリソースを参照してください。
リソース |
説明 |
|---|---|
COM コンポーネントを .NET Framework に公開する方法、および .NET Framework コンポーネントを COM に公開する方法について説明します。 |
|
プライマリ相互運用機能アセンブリ、スレッド処理、カスタム マーシャリングなど高度なトピックが含まれています。 |