Skip to content

MS_CodeAccessSecurity

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

コード・アクセス・セキュリティ

概要

コード・アクセス・セキュリティ（CAS）により、
セキュリティのため、.NET のプログラムのアクセス許可を設定できます。

  • .NET のプログラムをコードグループに分類し、
    セキュリティ ポリシー レベル毎にそれぞれのコードグループのアクセス許可を設定できます。

  • 信頼されているアプリケーション ドメイン ホストは、
    アクセス許可の設定を評価し、アクセス許可セットを与えます。

  • ノータッチデプロイメントや、ClickOnce などのテクノロジの内部でも利用されています。

移行メモ（誤字）: 移行元の「アクセス許可を設定を評価し」を
「アクセス許可の設定を評価し」に修正した。

補足（本ページを今読む際の前提）: CAS は
.NET Framework 4.0 で非推奨となり、.NET Core 以降には存在しない。
本ページは歴史的資料として読むことになる。

【CAS が目指したもの】★
   ・「どこから来たコードか」に応じて
     【同一プロセス内で権限を分ける】
     → インターネットから落ちてきたコードは
       ファイルに触れない
     → イントラのコードなら少し許す
     → ローカルなら全許可

   ・この発想が実現していた技術
       - ノータッチ デプロイメント（IE から .exe を起動）
       - 【XBAP】（ブラウザ内 WPF）
       - ClickOnce の部分信頼
       - Silverlight
     → いずれも【現在は全滅】している ★

【なぜ廃止されたのか】
   ・後述の ＠IT 記事の要約どおり
     「設定が難しく使いこなせない」
   ・加えて【セキュリティ境界として破られた】
     → 権限昇格の脆弱性が繰り返し発見された
     → Microsoft は
       「CAS をセキュリティ境界として使うな」と明言

【現在の考え方】★
   ・信頼度の違うコードは
     【プロセス／コンテナ／マシンで分ける】
   ・詳細は
     [.NET4におけるサンドボックス化API](MS_DotNet4Sandbox)

詳細

セキュリティ ポリシー モデル

https://learn.microsoft.com/ja-jp/previous-versions/dotnet/netframework-4.0/ck90k585(v=vs.100)

セキュリティ ポリシー レベル

アセンブリまたはアプリケーション ドメインに与えるアクセス許可を計算する。

補足（4 つのレベルはどう合成されたか）: 「計算する」の中身を
補っておくと、なぜ設定が難しかったかが分かる。

【アクセス許可の決定方法】★
   各ポリシー レベルが独立に
   「このアセンブリに与える許可セット」を算出し、
   最後に【全レベルの積集合（AND）】を取る

     エンタープライズ    : {A, B, C}
     コンピューター      : {A, B}
     ユーザー            : {A, B, C, D}
     アプリケーション ドメイン : {A, B, C}
     ─────────────────────
     最終的な許可        : 【{A, B}】★

   → 【最も厳しいレベルが勝つ】
   → 「なぜ動かないのか」を調べるには
     【4 階層すべてを確認する】必要があった
     → これが「使いこなせない」と言われた
       最大の理由である ★

【さらに難しかった点】
   ・レベルごとに【コード グループが木構造】になっている
   ・木の各ノードに条件（証拠）と許可セットが付く
   ・つまり
     【4 つの木を同時に読み解く】必要があった

コードグループと証拠

メンバーシップ（特定の条件を持つコードの論理的な集まり）と、メンバーシップの証拠。

補足（「ゾーン」は今も残っている概念）: この一覧で挙がる
ゾーンだけは、CAS 廃止後も Windows の仕組みとして生きている。

【セキュリティ ゾーン】★
   ・マイ コンピュータ / ローカル イントラネット /
     信頼済みサイト / インターネット / 制限付きサイト
   ・Internet Explorer 由来だが、
     【OS の仕組みとして今も機能する】

【現在も影響が出る例】★★
   ・ネットからダウンロードした ZIP を展開すると
     各ファイルに【Zone.Identifier】という
     代替データ ストリーム（ADS）が付く
     → 「Mark of the Web（MOTW）」
   ・これが付いていると
       - Office がプロテクト ビューで開く
       - PowerShell スクリプトの実行が制限される
       - 【Visual Studio がビルドを拒否する】★
         → [mark of the web](MS_MSBuildMarkOfTheWeb) を参照

   【解除方法】
     ・ファイルのプロパティで [許可する] にチェック
     ・PowerShell: Unblock-File
     → 【展開前に ZIP 側で解除する】のが確実

アクセス許可

コード グループに関連付けることができる一連のアクセス許可

ホスト

コード・アクセス・セキュリティをサポートするアプリケーションをホストする
アプリケーション ドメインのこと。

補足（4 つのホストのその後）: この一覧は、
CAS が前提としていた世界が消えたことを端的に示している。

【ブラウザー ホスト】★
   ・Internet Explorer 内で .NET コードを動かす
     → ノータッチ デプロイメント、XBAP
   ・【Internet Explorer は 2022年6月に廃止】
   ・XBAP も Edge では動かない
     → [XBAP](MS_XBAP) 参照
   → 【完全に消滅】

【サーバー ホスト（ASP.NET）】
   ・共有ホスティングで
     「他人のサイトのコードから守る」ために使われた
     → <trust level="Medium" /> 等
   ・【ASP.NET Core には存在しない】★
     → 現在は【プロセス／コンテナで分離】する

【シェル ホスト】
   ・エクスプローラから .exe を直接起動する場合
   ・現在は【MOTW とスマート スクリーン】が
     その役割を担う ★

【カスタム デザイン ホスト】
   ・自作アプリがプラグインをサンドボックスで動かす
   ・現在は
     AssemblyLoadContext（分離のみ。セキュリティ境界ではない）
     or 別プロセス / WebAssembly ★

Caspol

Caspol というツールを使用してコード・アクセス・セキュリティを構成できます。

補足（caspol.exe の現況）: ツール自体は
.NET Framework に今も同梱されているが、機能しない。

【現況】★
   ・%WINDIR%\Microsoft.NET\Framework\v4.0.30319\caspol.exe
     は【存在する】
   ・しかし .NET Framework 4 以降は
     既定で【レガシー CAS ポリシーが無効】
     → 実行すると
       「この機能は .NET Framework 4 では
         既定で無効になっています」という警告が出る

【無理に有効化する方法（非推奨）】
   ・app.config に
       <runtime>
         <NetFx40_LegacySecurityPolicy enabled="true"/>
       </runtime>
   ・または caspol -pp off
   → 【後方互換のためだけの機能】であり、
     新規に使ってはいけない ★

【関連する用語：Security Transparency】
   ・CAS の代わりに .NET 4 で導入されたモデル
   ・コードを 3 分類する
       - Transparent   … 特権操作ができない
       - SafeCritical  … 検証してから特権を使う
       - Critical      … 特権操作ができる
   ・これも .NET Core 以降は【意味を持たない】

参考

Microsoft Learn（旧 msdn.microsoft.com）

移行メモ（リンク）: 本ページの msdn.microsoft.com のリンクは、
Microsoft Learn の旧バージョン アーカイブ
（learn.microsoft.com/ja-jp/previous-versions/dotnet/netframework-4.0/...）に
対応するページがあるため、そちらに置き換えた。
ただし CAS は非推奨技術であり、一部は機械翻訳のまままたは
英語のみの可能性がある。

CAS廃止

CASが廃止。.NET 4のセキュリティはどうなるのか？ － ＠IT
http://www.atmarkit.co.jp/fdotnet/special/dotnet4security_01/dotnet4security_01_01.html

  • 要約すると
    • CAS は設定が難しく使いこなせないため廃止された。
    • セキュリティ ポリシー レベル、コードグループ、証拠などは廃止されるが
      アクセス許可の仕組みは生き残る。
    • このアクセス許可を使用したサンドボックス化の仕組は .NET4 以降に残っており、
      新しく「.NET4におけるサンドボックス化API」が用意された。

移行メモ（誤字）: 移行元の「.NET4 移行に残っており」を
文意（.NET 4 より後のバージョン）から「.NET4 以降に残っており」に修正した。

補足（この記事の予測のその後）: 「アクセス許可の仕組みは生き残る」
という要約は当時として正しかったが、その後さらに削られた。

【段階的な消滅】★
   .NET Framework 4.0
     → CAS ポリシー廃止。アクセス許可（Permission）は残る
   .NET Framework 4.x
     → 部分信頼は「サポートするが推奨しない」扱い
   【.NET Core / .NET 5 以降】★★
     → アクセス許可の仕組みごと【存在しない】
     → SecurityPermission 等の型は
       互換のため残るが【何もしない】
     → AppDomain の複数生成も不可能

【現在のセキュリティ設計の考え方】★
   「同一プロセス内で信頼度を分ける」を諦め、
   【プロセス境界／OS 境界／ネットワーク境界】で分ける

     ・プロセス分離（別 exe + IPC）
     ・【コンテナ】（Docker / Windows コンテナ）
     ・【WebAssembly】（言語ランタイムのサンドボックス）★
     ・OS の機構（AppContainer、Job Object、
       Windows Sandbox）
     ・最小権限のサービス アカウント

   → CAS の失敗が示したのは
     【「境界は薄いほど破られやすい」】という教訓である

Tags: 移行, .NET開発, セキュリティ

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally