さまざまな部門の規制により、システムが UTC に対して追跡可能であることが要求されます。 これは、システムのオフセットを UTC に関して証明できることを意味します。 規制遵守シナリオを有効にするために、Windows 10 (バージョン 1703 以降) および Windows Server 2016 (バージョン 1709 以降) には、オペレーティング システム側から見た場合の画像を提供して、システム クロック上で実行された操作を理解するための新しいイベント ログが用意されています。 これらのイベント ログは、Windows タイム サービス用に継続的に生成され、調査したり、後で分析するためにアーカイブしたりできます。
これらの新しいイベントによって、次の質問に回答できます。
- システム クロックが変更されたか
- クロック周波数が変更されたか
- Windows タイム サービスの構成が変更されたか
可用性
これらの改善点は、Windows 10 バージョン 1703 以降、および Windows Server 2016 バージョン 1709 以降に含まれています。
構成
この機能を実現するために必要な構成はありません。 これらのイベント ログは既定で有効になっており、イベント ビューアーの Applications and Services Log\Microsoft\Windows\Time-Service\Operational チャネルで確認できます。
イベント ログの一覧
次のセクションでは、追跡可能性のシナリオで使用するためにログに記録されるイベントの概要を示します。
このイベントは、Windows タイム サービス (W32Time) が開始したときにログに記録され、現在の時刻、現在のティック数、ランタイム構成、タイム プロバイダー、現在のクロック レートに関する情報をログに記録します。
イベントの説明 |
サービスの開始 |
詳細情報 |
W32time の起動時に発生 |
ログに記録されるデータ |
- 現在の時刻 (UTC)
- 現在のティック数
- W32Time 構成
- タイム プロバイダーの構成
- クロック レート
|
調整のメカニズム |
なし。 このイベントは、サービスが開始されるたびに発生します。 |
例:
W32time service has started at 2018-02-27T04:25:17.156Z (UTC), System Tick Count 3132937.
[コマンド:]
この情報は、次のコマンドを使用して照会することもできます。
W32Time とタイム プロバイダーの構成
w32tm.exe /query /configuration
クロック レート
w32tm.exe /query /status /verbose
このイベントは、Windows タイム サービス (W32Time) が停止しているときにログに記録され、現在の時刻とティック数に関する情報をログに記録します。
イベントの説明 |
サービスの停止 |
詳細情報 |
W32time のシャットダウン時に発生 |
ログに記録されるデータ |
|
調整のメカニズム |
なし。 このイベントは、サービスが停止されるたびに発生します。 |
テキストの例:W32time service is stopping at 2018-03-01T05:42:13.944Z (UTC), System Tick Count 6370250.
このイベントは、現在のタイム ソースと選択されたタイム ソースの一覧を定期的にログに記録します。 現在のティック数もログに記録します。 このイベントは、タイム ソースが変更されるたびには発生しません。 このドキュメントで後で紹介する他のイベントがこの機能を提供します。
イベントの説明 |
NTP クライアント プロバイダーの定期的な状態 |
詳細情報 |
NTP クライアントによって使用されるタイム ソースの一覧 |
ログに記録されるデータ |
- 使用可能なタイム ソース
- 選択されたログ記録時の参照タイム サーバー
- 現在のティック数
|
調整のメカニズム |
8 時間ごとに 1 回記録されます。 |
テキストの例: NTP クライアント プロバイダーの定期的な状態:
NTP クライアントは、次の NTP サーバーから時刻データを受信しています。
server1.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123)server2.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123); 選択した参照タイム サーバーは、Server1.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123) (RefID:0x08d6648e63) です。 システムティックカウント13187937
コマンド この情報は、次のコマンドを使用して照会することもできます。
ピアの特定w32tm.exe /query /peers
イベントの説明 |
タイム サービスの構成と状態 |
詳細情報 |
W32time は、その構成と状態を定期的にログに記録します。 これは、次を呼び出すことと同じです。
w32tm /query /configuration /verbose または
w32tm /query /status /verbose |
調整のメカニズム |
8 時間ごとに 1 回記録されます。 |
このイベントにより、SetSystemTime API を使用してシステム時刻が変更されると、各インスタンスがログに記録されます。
イベントの説明 |
システム時刻が設定された |
調整のメカニズム |
なし。 このイベントは、時刻の同期が適正なシステムではめったに発生しませんが、発生するたびにログに記録する必要があります。 このイベントのログを記録している間は、TimeJumpAuditOffset 設定は無視されます。この設定は、Windows システム イベント ログのイベントを調整することを意図したものであるためです。 |
イベントの説明 |
システム クロックの周波数が調整された |
詳細情報 |
システム クロックの周波数は、クロックが密接に同期されているときに W32time によって絶えず変更されます。 イベント ログを過剰に実行することなく、クロック周波数に対する "適度に有意な" 調整を行う必要があります。 |
調整のメカニズム |
TimeAdjustmentAuditThreshold を下回るすべてのクロック調整 (最小値 = 128 ppm、既定値 = 800 ppm) はログに記録されません。 現在の粒度でのクロック周波数の 2 ppm の変更は、クロック精度の 120 マイクロ秒/秒の変化を引き起こします。 同期されたシステムでは、調整の大部分がこのレベルを下回っています。 より詳細な追跡を行う場合は、この設定を調整する、PerfCounters を使用する、またはその両方を実行することができます。 |
イベントの説明 |
タイム サービスの設定または読み込まれたタイム プロバイダーの一覧の変更。 |
詳細情報 |
W32time 設定を再度読み取ると、メモリ内で重要な設定の一部が変更され、時刻同期の全体的な精度に影響を及ぼす可能性があります。
W32time は、時刻同期に影響を与える可能性がある設定を再度読み取るときに、それぞれの発生をログに記録します。 |
調整のメカニズム |
なし。
このイベントは、管理者または GP の更新によってタイム プロバイダーが変更され、その後 W32time がトリガーされた場合にのみ発生します。 設定の変更の各インスタンスを記録する必要があります。 |
イベントの説明 |
NTP クライアントによって使用されるタイム ソースの変更 |
詳細情報 |
NTP クライアントは、タイム サーバー/ピアの状態が変更になるとき (保留中 >同期、 同期 -> 到達不能、またはその他の移行) の、その時点でのタイム サーバー/ピアの状態のイベントを記録します |
調整のメカニズム |
最大頻度 - ログを一時的な問題やプロバイダーの正しくない実装から保護するため、5 分間に 1 回のみ。 |
イベントの説明 |
タイム サービス ソースまたは階層番号の変更 |
詳細情報 |
W32time タイム ソースと階層番号は、時間の追跡可能性に関わる重要な要素であり、これらに対する変更はすべてログに記録する必要があります。 W32time に時間のソースがなく、信頼性の高いタイムソースとして構成されていない場合は、タイム サーバーとして告知することを停止し、意図的に無効なパラメーターを持つ要求に応答します。 このイベントは、NTP トポロジの状態の変更を追跡するために重要です。 |
調整のメカニズム |
なし。 |
イベントの説明 |
再同期が要求された時刻 |
詳細情報 |
この操作は、次の状況でトリガーされます。- ネットワークに変更が発生したとき
- システムがコネクト スタンバイ/休止状態から戻る
- 長時間同期していなかったとき
- 管理者が再同期コマンドを発行する
この操作を実行すると、NTP クライアントによってフィルターがクリアされるため、細かい時刻同期の精度が即座に失われます。 |
調整のメカニズム |
最大頻度 - 5 分ごとに 1 回。
ネットワーク カードの不良 (または不適切なスクリプト) によりこの操作が繰り返しトリガーされ、ログがいっぱいになる可能性があります。 そのため、このイベントを調整する必要があります。
正確な時刻の同期にかかる時間は 5 分を超えるので、調整によって時刻の精度が失われる原因となった元のイベントに関する情報は失われません。 |