状態の分割
状態の分割とは、次の場合により明確なセキュリティ境界を使用する、強化されたサービスとセキュリティ モデルです。
- 主要なシステム領域のセキュリティ強化を支援
- より高速でクリーンな更新とシステム リセットの有効化
このモデルは、すべてのファクトリ OS イメージで使用されます。 セキュリティ境界は、次の状態によって分類されます。
State | 説明 | 例 |
---|---|---|
固定 | この領域は、オペレーティング システム自体を除き、永続的に変更することはできません。 |
|
変更可能、高値 | 変更を加えて、再起動または更新後に保持されることも期待できますが、システムのリセット後には保持されません。 |
|
変更可能、低値 | 変更を加えることはできますが、再起動またはシステム リセット後に表示されなくなります。 | 一部のコンポーネントは、HKLM\SYSTEM や HKLM\SOFTWARE などのレジストリ ハイブへの書き込みが必要な場合があります。 これらのレジストリ領域は揮発性として読み込まれるので、コンポーネントは特定のランタイムに対して引き続き書き込み操作を実行できます。 次回再起動すると、変更は表示されなくなります。 |
ユーザー データ | 変更可能。 各ユーザー データ プロファイルは独自のパーティションで暗号化されます。そのため、変更はユーザーがログインしている場合にのみ影響します。 |
|
工場出荷時のテストでは、ログ ファイルや他のテスト ファイルをデータ パーティションまたは %PROGRAMDATA%
に保存しても問題ありません。
状態の分割の違反
状態の分割の違反は、次の場合に発生します。
- コンポーネントが MainOS ボリューム上のファイルシステムへの書き込みを試みる。
- コンポーネントが
HKLM\SYSTEM
またはHKLM\SOFTWARE
レジストリ ハイブに書き込みをする。
これらのルールを満たすコンポーネントの開発を支援するために、Windows ではこれらの場所のいずれかに書き込みを試みるたびにログを記録できます。
Windows が書き込み操作を追跡しているからといって、必ずしも問題があるとは限らないことに注意してください。コンポーネントは、変更が揮発性であることを期待して、意図的に HKLM\SYSTEM
または HKLM\SOFTWARE
レジストリ ハイブに書き込む場合があります。
インストルメンテーション
レジストリとファイル システムのアクティビティのログを収集する方法はいくつかあります。 使用する適切な方法を決定するには、ユース ケースと、ブート シーケンス内でドライバーがアクティブになる状況によって異なります。 以下は、各メソッドを使用して状態の分割とドライバーの分離の違反を見つけるタイミングをまとめた表です。
メソッド | 実行するタイミング | 検索する内容 |
---|---|---|
早期起動自動ロガー | ドライバーの検証ツールで検出できないファイル違反を検索するか、同じトレースでファイルとレジストリの違反を確認する | すべてのファイル違反と最も多いレジストリ違反 |
オンデマンド ロガー | ドライバーの検証ツールで検出できないファイル違反を検索するか、同じトレースでファイルとレジストリの違反を確認する | すべてのファイル違反と最も多いレジストリ違反 |
ブート トレース | 違反に至るまでの詳細なスタック情報が必要 | すべてのファイルとレジストリの操作 (違反であるかどうかに関係なく) |
ドライバーの検証ツールのドライバーの分離チェック | デバイスの起動、一般的なドライバー テスト、認定テスト中にすべてのレジストリ違反を見つけたい | ファイル違反なしおよびすべてのレジストリ違反 |
違反のリアルタイム ビュー
状態の分割の違反を追跡する最も簡単な方法は、Windows デバイス ポータルを介して Windows イベント トレーシング (ETW) をリアルタイムで確認することです。
Note
このテレメトリを提供するフィルター ドライバーは、コンポーネントの後に読み込まれる場合があります。 コンポーネントが起動処理の早い段階で実行されている場合は、次のセクションを参照する必要があります。
- テスト対象のデバイスで、Windows デバイス ポータルにログインする
- 左側の [ETW ログ記録] タブに移動します。
- [カスタム プロバイダー] でプロバイダー d6e1490c-c3a6-4533-8de2-18b16ce47517 を有効にします。
- シナリオを再現します。 違反がテーブルに表示されます。
- 十分なデータを収集したら、[ファイルに保存] をクリックして、キャプチャされた違反を含むテキスト ファイル (.csv) を取得します。 多くの場合、リアルタイム分析を行うよりも、ダウンロードしたデータを操作する方が簡単です。
早期起動自動ロガー
早期起動自動ロガー を使用して、ブート パスの早い段階で実行された操作の ETW トレースをキャプチャします。
Tracelog を実行して、プロバイダー GUID "d6e1490c-c3a6-4533-8de2-18b16ce47517" をリッスンするように自動ロガーを構成します。
バッファーを 128 キロバイトに設定し、最小 12 バッファー、最大 34 バッファーに設定します (値を小さくすると、イベントが削除される可能性があります)。
セッション GUID の場合、
uuidgen
を使用して GUID を生成し、その前に番号記号 (#) を追加するか、GUID を含むファイル名を指定することができます。ログファイルは任意の場所に保存できますが、ユーザーまたはアプリのデータ フォルダー内の場所 (
-f %ProgramData%\Fabrikam\log.etl
など) を使用することをお勧めします。Tracelog.exe -addautologger StateSeparationViolationsAutologger -sessionguid #aabbccdd-1234-5678-90ab-a00bb00ccdd -f %ProgramData%\Fabrikam\log.etl -guid #d6e1490c-c3a6-4533-8de2-18b16ce47517 -b 128 -min 12 -max 34
デバイスを再起動して自動ロガー トレース セッションを開始する
自動ロガーを停止します。
Tracelog.exe -stop StateSeparationViolationsAutologger
ETL ファイルを取得し、データを確認します。
a. デバイスの ProgramData ディレクトリの値 (
E:\ProgramData
など) をキャプチャします。cmd-device -InformationVariable echoInfo echo %ProgramData% $deviceProgramData = $echoInfo[0]
b. この値を使用して、ETL ファイルをデバイスからローカル PC に コピーします。 例:
PS C:\> getd E:\ProgramData\Fabrikam\log.etl C:\hostdir\log.etl
Windows パフォーマンス アナライザー (WPA) または他のツールを使用して、トレース ログ アクティビティ データを確認します。
オンデマンド ロガー
オンデマンド ロガーを使用して、オンデマンド ETW トレースをキャプチャします。
プロバイダー GUID "d6e1490c-c3a6-4533-8de2-18b16ce47517" をリッスンするログ セッションを構成します。
Tracelog.exe -start StateSeparationViolations -f <path to save ETL> -guid #d6e1490c-c3a6-4533-8de2-18b16ce47517
シナリオを再現するか、テストを実行します (デバイスが再起動しない限り)。
ログ セッションを停止します。
Tracelog.exe -stop StateSeparationViolations
デバイスから ETL ファイルをコピーします。
PS C:\> getd C:\ProgramData\Fabrikam\log.etl C:\hostdir\log.etl
ログ ファイルを開き、Windows パフォーマンス アナライザーを使用してトレース ログ アクティビティ データを確認します。
ブート トレース
早期ブート ETW トレースが正しく設定されている場合、すべてのレジストリ操作やファイル操作をトレースにキャプチャし、操作ごとのスタックをキャプチャして、そのレジストリ操作につながるコード パスを詳細に示すことができます。
ブート トレースを登録します (レジストリまたはファイル I/O のいずれか、または両方)
wpr -boottrace -addboot registry wpr -boottrace -addboot fileio
デバイスを再起動して、トレースのキャプチャを開始します。
TShell を使用してデバイスに再度接続します。
トレースを停止します。
wpr -boottrace -stopboot <path where to write ETL>
デバイスから ETL ファイルをコピーします。
PS C:\> getd C:\<path on device to the>\log.etl C:\hostdir\log.etl
ログ ファイルを開き、Windows パフォーマンス アナライザーを使用してトレース ログ アクティビティ データを開きます。
WPA では、調査中のバイナリをスタック トレースで解決し、レジストリの概要テーブルを開くことができるようにシンボルを読み込むように指示します。
テーブルをフィルター処理して、システム ハイブとソフトウェア ハイブの操作のみを表示することをお勧めします。 「ベース キー ツリー」列を表示している場合は、[レジストリ]、[マシン] の順に展開します。 [システム] と [ソフトウェア] の両方を複数選択し、右クリックして [選択対象にフィルター] を選択します。
スタックに調査中のバイナリが含まれる操作のみを行うために、テーブルをフィルター処理することをお勧めします。 このフィルター処理は、上記で推奨されているシステムおよびソフトウェア ハイブに対するフィルター処理に加えて行うことができます。 [スタック] 列をクリックして、検索ボックスを開きます。 調査中のバイナリの名前を入力し、[すべて検索] をクリックします。 バイナリ名を含むスタック内で強調表示された行のいずれかを右クリックし、[選択対象にフィルター] を選択します。
ドライバーの検証ツールによるドライバーの分離チェック
ドライバーの検証ツール (DV) は、システムを破損する可能性のある不適切な関数呼び出しまたはアクションのドライバーを監視するために使用される Windows に付属のツールです。 OS ビルド 19568 以降、ドライバーの検証ツールには、ドライバー パッケージの分離要件の違反を監視することにより、Windows ドライバーの開発者をサポートする新しい機能があります。 ドライバー パッケージの分離は、状態の分割要件に準拠するために、ドライバーがファクトリ OS システムで準拠しなければならない重要な要件です。
ドライバーの検証ツールは、ファクトリ OSシステムで許可されていない不適切なレジストリの読み取りと書き込みを監視します。 ドライバー開発の早い段階でこのツールを使用して、コンポーネントがドライバー分離要件に違反している場所を理解して修正します。
構文:
Note
ファクトリ OS システムで有効にして SSH 経由でファクトリ OS システムにリモート接続する場合は、「SSH を使用して接続する」を参照してください。
verifier /rc 33 36 /driver myDriver.sys
これにより、対象となるドライバー (myDriver.sys) でドライバーの分離チェックが有効になります。 一覧をスペースで区切ることにより、複数のドライバーを選択することもできます。
verifier /rc 33 36 /driver myDriver1.sys myDriver2.sys
検証設定を有効にするには再起動が必要です。 これを行うには、次を指定します。
shutdown /r /t 0
想定されている動作 - テレメトリ モード:
ドライバーを起動する初期段階でこれらのチェックに推奨される動作はテレメトリ モードです。これは既定の動作であり、バグチェックによって進行が妨げられることなく、開発者がすべての違反を表示する方法を提供します。
上記のセクションで指定した構文を使用し、カーネル デバッガーをアタッチして DV ドライバーの分離チェックを有効にすることをお勧めします。 再起動によって DV 設定が有効になると、カーネル デバッガーの出力に違反が表示されるようになります。
ドライバーの分離要件に違反するドライバーのシナリオ例と、一般的な出力の例を次に示します。
シナリオ: 完全な絶対パスを使用する ZwCreateKey:
"DRIVER_ISOLATION_VIOLATION: <ドライバー名>: レジストリ操作では絶対パスを使用しないでください。 分離されていないレジストリ キー '\Registry\Machine\SYSTEM' の作成が検出されました"
シナリオ: 承認された API からのものではないハンドルに相対的なパスを使用する ZwCreateKey:
"DRIVER_ISOLATION_VIOLATION: <ドライバー名>: レジストリ操作では、WDF または WDM API から返されたキー ハンドルのみを使用する必要があります。 分離されていないレジストリ キー '\ REGISTRY \ MACHINE \ SYSTEM \ SomeKeyThatShouldNotExist' の作成が検出されました"
テレメトリ モードを活用して、コンポーネントのすべての違反のベースラインを確立し、それらを 1 つずつ修正して、テストを開始します。
想定されている動作 - バグチェック モード:
ドライバー開発プロセスがさらに進んだ段階では、違反を明らかにするモードでドライバー分離チェックを有効にすることが役立つ可能性があります。 DV は、違反が発生した場合にバグチェックを行うように構成できます。
これにより、違反が発生した場所の正確な詳細を提供するメモリ ダンプが生成されます。 バグチェック モードで DV を有効にするには、次の構文を使用します。
verifier /onecheck /rc 33 36 /driver myDriver1.sys
このモードは、ドライバーが実稼働準備に近付き、検証とテストの最終段階にある場合に便利です。
コード パスの最大化:
DV ドライバー分離ルールは、IHV による既存のテスト フレームワークの実行中に有効にできます。 これは、テストするドライバーによって実行されるコード パスを最大化するのに役立ちます。
コマンド ラインを介した Device Fundamentals テストは、ドライバーの一般的なコード パスを実行するためのテストの優れたベースラインです。 開発者は、DV ドライバー分離チェックを使用してこれらのテストを有効にして、ドライバーの分離違反を可能な限り早くキャッチする可能性を最大化できます。
開発モード: 強制を無効にする
開発の目的で、状態の分割開発モードで を実行することで、状態の分割の適用を無効にできます。 これにより、要件に準拠していないアプリとドライバー (ファクトリ テスト アプリなど) を開発、テスト、および実行できます。
開発モードの場合:
- MainOS パーティションは書き込み可能です。
HKLM\SYSTEM
およびHKLM\SOFTWARE
の変更は再起動後も保持されます。- Windows は、状態の分割ルールに違反する可能性のあるアクティビティを引き続き監視します。
イメージ作成時に開発モードを構成するには、機能 : STATESEPARATION_ON
を STATESEPARATION_DEVMODE
に置き換えます。
次の表では、各モードの違いについて詳しく説明しています。
状態の分割モード | 不変ファイルシステム アクセス | 不変レジストリ アクセス |
---|---|---|
強制モード | 書き込みは不可 | レジストリの変更は再起動後も保持されない |
ETW およびデバッガー出力での違反警告 | ETW およびデバッガー出力での違反警告 | |
Dev モード | 読み取り/書き込みが可能 | レジストリの変更は再起動後も保持される |
ETW およびデバッガー出力での違反警告 | ETW およびデバッガー出力での違反警告 |