セキュリティ ポリシーを変更するタイミングの判断
.gif "重要 :") 重要 |
|---|
.NET Framework Version 4 では、共通言語ランタイム (CLR: Common Language Runtime) がコンピューターにセキュリティ ポリシーを提供しなくなります。Microsoft では、CLR のセキュリティ ポリシーの代替として、Windows のソフトウェアの制限のポリシーを使用することをお勧めしています。このトピックの情報は、.NET Framework Version 3.5 以前に適用され、.NET Framework 4 以降のバージョンには適用されません。この変更およびその他の変更の詳細については、「.NET Framework 4 におけるセキュリティの変更点」を参照してください。 |
既定のセキュリティ設定は、必ず変更する必要があるわけではありません。 多くの場合は、既定のセキュリティ設定のままでも十分なレベルでセキュリティを確保できます。 既定のセキュリティ ポリシーでは、発生元がローカル コンピューターではない (したがって、信頼性が低いと考えられる) コードは、保護されているリソースへのアクセスを制限されます。 インターネットまたはローカル イントラネットが発生元であるコードは、次のようにアクセスを制限されます。
インターネットまたはローカル イントラネットが発生元のコードには、ローカル ドライブに対する読み書き権がありません。
インターネットまたはローカル イントラネットが発生元のコードには、システム レジストリに対する読み書き権がありません。
インターネットまたはローカル イントラネットが発生元のコードは、発生元である Web サイトと通信できます。
ローカル イントラネットが発生元のコードは UI 要素に無制限にアクセスできますが、インターネットが発生元のコードはサブウィンドウとクリップボードにしかアクセスできません。
多くの場合、既定のセキュリティ ポリシーをそのまま適用できますが、適用できない場合もあります。 次のような場合は、セキュリティ ポリシーの変更を検討する必要があります。
発生元のゾーンに既定で付与されるアクセス許可よりも多くのアクセス許可を要求するアプリケーションを信頼する場合。
完全に信頼されている特定の発行元のアプリケーションを使用し、それらのアプリケーションが実行される場所に関係なく特定のリソースにアクセスできるようにする場合。
ローカル コンピューター上のアプリケーションであっても完全には信頼しない場合。 たとえば、エンタープライズ管理者が、信頼されていないアプリケーションをユーザーがインストールしたり実行したりするのを防ぐ場合が該当します。
ポリシーを変更することを決めた場合は、アクセス許可を減らし過ぎてアプリケーションが正常に機能しなくなることがないように注意する必要があります。
参照
処理手順
方法 : セキュリティ ポリシーにカスタム アクセス許可を追加する