次の方法で共有

安全なコーディングのガイドライン

  • [アーティクル]

ほとんどのアプリケーション コードは、.NET によって実装されるインフラストラクチャを単純に使用することができます。 場合によっては、アプリケーション特有の追加のセキュリティが必要になります。これは、セキュリティ システムを拡張するか、または新しい特有の方法を使用して構築されます。

.NET によって適用されるアクセス許可やコード内での他の適用を使用して、防御機構を設けて、悪意のあるコードが知られたくない情報にアクセスしたり、他の望ましくないアクションを実行したりすることを防ぐ必要があります。 また、信頼されるコードを使用するすべての想定されるシナリオで、セキュリティと使いやすさのバランスを取る必要があります。

この概要では、セキュリティ システムと連携するようコードを設計するさまざまな方法を説明します。

リソース アクセスの保護

コードを設計して作成する場合、作成元が不明なコードを使用したり呼び出したりする際は特に、コードがリソースに対して持つアクセス権の保護と制限を行う必要があります。 そのため、コードの安全性を確保するために次の点に注意します。

  • コード アクセス セキュリティ (CAS) を使用しないでください。

  • 部分的に信頼されたコードを使用しないでください。

  • AllowPartiallyTrustedCaller 属性 (APTCA) は使用しないでください。

  • .NET リモート処理を使用しないでください。

  • 分散コンポーネント オブジェクト モデル (DCOM) を使用しないでください。

  • バイナリ フォーマッタを使用しないでください。

部分的に信頼されたコードでは、コード アクセス セキュリティとセキュリティが透過的なコードはセキュリティ境界としてサポートされません。 発生元の不明なコードの読み込みと実行に関しては、他のセキュリティ対策を適切に導入することなく行わないようにしてください。 代わりのセキュリティ対策は次のとおりです。

  • 仮想化

  • AppContainers

  • オペレーティング システム (OS) のユーザーおよびアクセス許可

  • Hyper-V コンテナー

セキュリティ中立なコード

セキュリティ中立なコードは、セキュリティ システムに対して明示的な操作を何も行いません。 これは何であれ自分が受け取ったアクセス許可を使用して動作します。 保護された操作 (ファイルの使用やネットワーキングなど) に関連したセキュリティ例外をアプリケーションがキャッチしなかった場合はハンドルされない例外になるとはいえ、セキュリティ中立なコードは .NET でのセキュリティ テクノロジを活用します。

セキュリティ中立なライブラリは、理解しておくべき特別な特性を持っています。 ファイルを使用したり、アンマネージド コードを呼び出したりする API 要素をライブラリで提供していると仮定します。 対応するアクセス許可を持っていないコードは、記述どおりに動作しません。 しかし、コードがアクセス許可を持っているとしても、そのコードを呼び出すアプリケーション コードが同じアクセス許可を持っていなければ、正しく機能しません。 呼び出し元のコードが正しいアクセス許可を持っていない場合、コード アクセス セキュリティのスタック ウォークの結果として SecurityException が発生します。

再利用可能なコンポーネントではないアプリケーション コード

作成するコードがアプリケーションの一部であって、他のコードから呼び出されることがなければ、セキュリティは単純であり、特殊なコーディングは不要な場合があります。 ただし、悪意のあるコードがそのコードを呼び出す可能性があることを忘れないでください。 悪意のあるコードによるリソースへのアクセスをコード アクセス セキュリティが阻止する可能性もありますが、機密情報を含んだフィールドやプロパティの値をそのようなコードが読み取ることも考えられます。

また、コードがインターネットやその他の信頼できないソースからのユーザー入力を受け付ける場合には、悪意のある入力にも注意する必要があります。

ネイティブ コードの実装のマネージド ラッパー

一般にこのシナリオは、何らかの有用な機能がネイティブ コードで実装されており、これをマネージド コードで利用したいというケースに該当します。 マネージド ラッパーは、プラットフォーム呼び出しか COM 相互運用を使用して簡単に作成できます。 ただしこの場合には、操作を成功させるために、ラッパーの呼び出し元がアンマネージ コードの権利を持っている必要があります。 つまり既定のポリシーでは、イントラネットやインターネットからダウンロードされたコードはラッパーでは機能しません。

これらのラッパーを使用するすべてのアプリケーションへの権利をアンマネージド コードに与えるより、これらの権利をラッパー コードのみに与える方が望ましいと言えます。 基になる機能が何もリソースを公開しておらず、かつ実装も同様に安全である場合、ラッパーは、自分の権利をアサートしさえすれば、あらゆるコードが自分を通して呼び出しを行えるようにできます。 リソースが関係する場合のセキュリティ コーディングは、次のセクションで説明するライブラリ コードのケースと同じです。 ラッパーはこれらのリソースに対して呼び出し元を公開する可能性があるため、ネイティブ コードの安全性を慎重に確認する必要があり、その責任はラッパーにあります。

保護されたリソースを公開するライブラリ コード

以下のアプローチは、セキュリティ コーディングとして最も強力なものであるため、方法を間違えるなら最も危険性の高いものともなります。ライブラリは他のコードに対し、(.NET のクラスが使用するリソースのアクセス許可を課すのと同じように) 他の手段では使用できない特定のリソースにアクセスするためのインターフェイスとして機能します。 どこでリソースを公開しようと、コードはまずそのリソースに適したアクセス許可を要求し (つまりセキュリティ チェックを実行しなければなりません)、それから通常は実際の操作を実行するための権利をアサートする必要があります。

関連項目