業務システムの時刻同期監視｜NTP・クロックずれ・証跡時刻を揃える方法
サーバーやクラウド、ネットワーク機器、SaaSの時刻が数秒ずれるだけでも、障害の発生順序を誤って読んだり、認証トークンや証明書を期限外と判定したり、同じ取引のログが前後したりします。NTPを設定済みでも、同期元が一つしかない、外部時刻源とクラウド内時刻源が混在する、同期断を通知していない状態では、必要なときに時刻を信頼できません。
時刻同期監視では、同期先の名前だけでなく、現在選択中の時刻源、階層、offset、jitter、周波数補正、到達性、最後の正常同期、切り替え履歴を継続して観測します。監査ログはUTCまたはUTCオフセット付きで記録し、サービスごとの許容差を超えたら、大きな時刻変更を急いで入れる前に認証・ログ・ジョブ・署名への影響を隔離します。
時刻同期監視が完了するのは、NTPサービスが起動した時ではなく、基準時刻との差、同期元、切り替え履歴、影響を受けた証跡まで同じ時刻同期台帳で説明できた時です。
本記事のポイント
- 時刻同期の成否はNTPサービスの起動ではなく、基準時刻との差、選択source、切り替え履歴、証跡への影響で確認します。
- 独立性と多様性のある複数の時刻源を使い、クラウド内部NTPと外部NTPの方式混在、単一上流への共通依存を避けます。
- offset、jitter、frequency drift、reach、最終同期、leap状態を監視し、時刻ずれ期間の認証・ログ・署名を再検証して復旧を閉じます。
業務システムの時刻同期でそろえる対象を決める
NTPは、ネットワーク越しに時刻情報を交換し、各機器の時計を基準へ近づけるための仕組みです。RFC 5905が定義するNTPv4では、一次サーバーをstratum 1とし、その下流へ進むごとにstratumが上がる階層を構成します。ただし、stratumの数字が小さいだけで、その時刻源が自社から見て最も正確・安定・安全とは限りません。ネットワーク遅延、経路の非対称、サーバー負荷、発振器の安定性、時刻源自体の異常も含めて選びます。
最初に、OSを持つサーバーだけでなく、時刻を生成・利用・転送する構成要素を一覧化します。対象は、物理サーバー、仮想マシン、コンテナホスト、ネットワーク機器、認証基盤、データベース、ジョブ基盤、監視、SIEM、バックアップ、電子署名・タイムスタンプ処理、外部SaaSとの連携です。SaaS側の内部時計を直接設定できなくても、API応答や監査ログがどのタイムゾーン・精度で返るかは確認できます。
NIST SP 800-53 Rev.5のAU-8は、監査記録のタイムスタンプを内部システム時計から生成し、UTC、UTCからの固定オフセット、またはローカルオフセットを含む形式で記録する考え方を示しています。SC-45はシステム内・システム間の時計同期を求め、SC-45(1)では組織が定めた頻度で権威ある時刻源と比較し、定めた差を超えたときに同期する設計を示します。つまり「NTPが動くか」だけでなく、「どの精度をどの業務で必要とするか」を組織側で決める必要があります。
| 対象 | そろえる情報 | ずれたときの主な影響 | 確認する証拠 |
|---|---|---|---|
| 認証・アクセス制御 | UTC、token・証明書の有効期間、許容skew | 正しい利用者の拒否、期限切れ資格情報の誤受理 | 認証ログ、発行時刻、失効時刻、端末offset |
| 監査ログ・SIEM | UTCまたはUTCオフセット、ミリ秒等の必要精度 | 攻撃・操作・障害の順序を誤認 | 原本ログ、受信時刻、取り込み遅延、同期状態 |
| データベース・分散処理 | アプリ時刻、DB時刻、キュー・ジョブ時刻 | 重複処理、順序逆転、期限判定の誤り | event ID、sequence、各ノードのoffset |
| 署名・Webhook | 署名生成時刻、検証窓、再送・リプレイ判定 | 正しい要求の拒否、古い要求の誤受理 | raw request、署名header、検証時刻、時刻源 |
| 障害調査・証拠保全 | 端末、サーバー、クラウド、SaaSの時刻関係 | 証拠の因果関係や受渡順序を説明できない | 採取時刻、ハッシュ、受渡記録、既知の時計差 |
監査ログの設計を時刻だけで完結させず、event IDや処理順序も併用します。複数サービスをまたぐ記録項目は監査証跡の設計方法で整理できます。時刻は重要な並び替え軸ですが、ネットワーク遅延や非同期処理があるため、同じタイムスタンプだけで因果関係を断定しません。
独立したNTP同期元とフェイルオーバーを設計する
時刻源が一つだけなら、その時刻が壊れても比較対象がありません。RFC 8633は、独立性と多様性のある少なくとも4つの時刻源を推奨し、4つを用意できない場合は少ない構成も許容しつつ、可用性と異常検知が弱くなる点を説明しています。数だけ増やしても、すべて同じ事業者・同じ上流・同じGPS受信・同じ実装に依存していれば、共通原因障害を避けられません。
クラウドでは、事業者が提供する内部時刻源とインターネット上の公開NTPを無秩序に混ぜないことが重要です。Google Compute Engineの公式資料は、Googleの時刻源がうるう秒を24時間にわたってsmearし、VM内でGoogleのNTPと外部NTPを混在させると、うるう秒の前後に異なる時刻が返る可能性があるため、混在を避けるよう案内しています。AzureのLinux VMでも、chronydやntpdなどの同期サービスに加え、ホスト時刻または外部時刻源のどちらを使うかを構成として選びます。
自社のNTP階層は、外部の権威ある時刻源へ接続する境界サーバーと、社内クライアントへ配布する内部サーバーを分けると管理しやすくなります。クライアントを多数の公開NTPへ直接接続させるのではなく、許可済みの内部NTPを複数用意し、ファイアウォール、DNS、監視、設定管理を統一します。外部時刻源を変えるときは、現在のoffset、到達性、leap処理、認証方式、上流依存を比較して段階的に切り替えます。
NTPパケット自体の送信元を信用する必要がある環境では、ネットワーク制限だけでなく認証も検討します。RFC 8915のNetwork Time Security（NTS）は、TLSを使う鍵確立とNTPv4用の認証拡張を組み合わせ、時刻サーバー由来であることと改ざん耐性を確認する仕組みです。利用するOS・NTP実装・時刻源がNTSへ対応しているかを確認し、未対応環境では送信元制限、監視、複数源比較、設定改変防止を重ねます。
| 設計項目 | 望ましい状態 | 避けたい状態 | 監視の入口 |
|---|---|---|---|
| 時刻源 | 独立性・多様性を確認した複数源 | 単一源、同じ上流だけの見かけ上の複数源 | source一覧、stratum、ref ID、到達性 |
| クラウド | 事業者推奨の内部時刻源とleap方式へ統一 | 内部NTPと外部NTPの無計画な混在 | 設定ファイル、選択source、leap状態 |
| 社内階層 | 境界NTPと内部配布NTPを冗長化 | 全端末が個別に公開NTPへ接続 | 上流到達性、内部client数、切替履歴 |
| 認証 | NTS等の対応可否を確認し、経路制限も併用 | 送信元IPだけで正当性を断定 | 認証状態、証明書、失敗理由 |
| フェイルオーバー | 異常sourceを除外し、正常sourceへ自動切替 | 到達不能なのに古い同期状態を正常表示 | selected source、falseticker、lastRx |
DNSやネットワーク経路の変更で時刻源へ到達できなくなることもあります。複数系統の監視と切り戻しの考え方はセカンダリDNSの同期監視と共通しますが、NTPでは「応答したか」だけでなく「どの時刻を採用したか」「他のsourceと整合したか」を確認します。
offset・drift・同期断を監視する7ステップ
監視値は製品や実装によって名称が異なります。offsetは基準とローカル時計の差、jitterは観測したoffsetのばらつき、frequency driftやfrequency errorは時計が進みすぎる・遅れすぎる傾向、reachは直近の問い合わせに時刻源が応答したかを示します。RFC 5905もclock offset、system clock jitter、frequency wanderなどを区別しています。単一の「同期済み」フラグへ集約せず、元の値と時系列を残します。
- 時刻同期台帳を作る。対象機器、OS・ファームウェア、時刻同期サービス、設定ファイル、許可source、現在source、stratum、タイムゾーン、leap方式、責任者、変更日を記録します。SaaSは設定できる項目と、監査ログで観測できる項目を分けます。
- 業務別の許容差を決める。認証、署名、ログ相関、決済、製造制御などで許容できる差は同じではありません。製品既定値をそのまま全社基準にせず、正常時の実測と業務影響から警告・重大・遮断の閾値を定めます。
- 複数sourceの健全性を集める。selected sourceだけでなく、候補sourceのoffset、delay、jitter、reach、stratum、ref ID、falseticker・unreachable判定を収集します。選ばれていないsourceも、障害時の切替先として正常かを見ます。
- ホスト自身のdriftを追う。同期中のoffsetに加え、再起動、VM移行、ホスト保守、休止復帰、負荷急増後のfrequency補正を観測します。Azureの公式資料も、VMは構成によってホスト時刻と外部時刻源を組み合わせ、保守後の時刻更新を扱う点を説明しています。
- 外形比較を加える。監視対象と同じNTP設定だけを参照する監視では、共通の誤時刻を正常と判定します。独立した監視地点から基準時刻との差を比較し、内部監視と外形監視の両方が一致するかを確認します。
- 変更とフェイルオーバーを試験する。検証環境で一つのsource停止、DNS解決失敗、経路遮断、異常offsetを再現し、除外・切替・復帰・通知が想定どおり動くかを確認します。本番では意図的に誤時刻を配布せず、安全なモックまたは隔離環境を使います。
- 証跡の整合まで閉じる。警告が解消した後、認証エラー、ジョブ失敗、ログ順序、署名検証、監視欠損を確認します。時刻だけ戻っても、ずれていた間に生成されたデータの補正・注記・再処理が終わるまで復旧完了にしません。
| 監視指標 | 分かること | 通知条件の考え方 | 次に確認すること |
|---|---|---|---|
| offset | 基準時刻との差 | 業務別の警告・重大閾値を継続超過 | source、delay、直前変更、ホスト状態 |
| jitter | offset観測のばらつき | 平常値から急増、複数sourceで不安定 | ネットワーク揺らぎ、負荷、source品質 |
| frequency drift | ローカル時計の進み・遅れの傾向 | 補正量の急変、再起動後に収束しない | VM移行、電源・温度、kernel、daemon |
| reach・last sync | source到達性と最終同期 | 連続失敗、許容時間を超える未同期 | UDP 123、DNS、ACL、source障害 |
| selected source | 実際に採用中の時刻源 | 想定外sourceへ切替、頻繁な切替 | 候補sourceの一致、優先度、共通依存 |
| leap状態 | うるう秒・smearの扱い | 同一系で方式が混在、未同期表示 | 事業者仕様、source設定、イベント期間 |
Webhook署名では、受信時刻と署名headerの差をリプレイ防止に使うことがあります。許容窓を広げて時刻ずれを隠すのではなく、Webhook署名検証とシークレット交換でraw body、署名世代、検証時刻、隔離・再処理を分けて扱います。SAMLでも時刻条件の失敗を証明書障害と混同しないよう、SAML署名証明書の更新手順と時刻監視を同じ変更記録から参照できるようにします。
時刻ずれが起きたときに証跡を壊さず復旧する
大きなずれを見つけたとき、最初の操作を「正しい時刻へ即座に合わせる」にすると、同じ時刻のログが重複したり、未来時刻から過去へ戻ったように見えたり、期限判定や定期ジョブが一斉に動いたりすることがあります。まず影響範囲を隔離し、現在値、基準との差、選択source、daemon状態、最後の正常同期、直前の変更を採取します。サービス停止や段階的補正の必要性は、OS・NTP実装・業務システムの仕様に従って判断します。
切り分けは、①監視側の表示誤り、②対象ホストだけのdrift、③内部NTPの異常、④外部source・経路の異常、⑤複数sourceの不一致、⑥タイムゾーン表示の誤解、⑦アプリ独自時刻の誤り、の順で進めます。UTCの実時刻は合っているのに、表示タイムゾーンだけが違うケースをNTP障害として扱わないよう、epoch値とUTCオフセットを同時に確認します。
| 症状 | 最初に保全する証拠 | 復旧前の確認 | 復旧完了の条件 |
|---|---|---|---|
| 一台だけ大きくずれる | offset、frequency、daemon・kernelログ | VM移行、休止、負荷、設定改変 | 再同期後もdriftが平常範囲で継続 |
| 全社で同じ誤時刻 | 内部NTPと各上流sourceの差 | 選択source、共通上流、認証、経路 | 独立sourceと一致し、全クライアントが追随 |
| 認証が一斉に失敗 | token・証明書・SAML条件と各時計差 | 期限判定、認証基盤、端末、SaaS側時刻 | 認証回復と、誤発行・誤受理がないこと |
| ログ順序が逆転 | 原本時刻、受信時刻、sequence・event ID | 取り込み遅延、バッファ、時刻補正区間 | 既知の時計差を注記し、因果関係を再構成 |
| 署名・Webhook検証失敗 | raw body、署名header、検証時刻、source | secret世代、許容窓、再送、リプレイ | 正規要求だけを再検証・再処理 |
時刻ずれの期間に取得した証拠は、後からタイムスタンプを書き換えません。採取時点で分かっている時計差、採取方法、原本ハッシュ、保管先、受渡者を追加記録し、補正後の推定時刻と原本時刻を区別します。ログや端末の証拠保全は情報セキュリティ事故の証拠保全の手順と結び付けると、復旧作業が原本性を損ねにくくなります。
最終的な復旧判定では、時刻同期サービスの正常表示だけでなく、対象機器のoffsetが許容範囲へ収束し、選択sourceが想定どおりで、フェイルオーバー先も利用可能で、ずれていた期間の認証・ログ・ジョブ・署名・証拠へ必要な再処理や注記が完了したことを確認します。原因、影響期間、最大offset、復旧操作、再発防止、次回試験日を同じ変更記録へ残します。
よくある質問
業務システムの時刻同期では何をそろえますか？
サーバーだけでなく、認証基盤、データベース、ネットワーク機器、監視、SIEM、ジョブ、バックアップ、連携先SaaSを対象にし、UTCまたはUTCオフセット、必要精度、許容差、同期元、leap方式、責任者をそろえます。
NTP同期元と冗長構成をどう決めますか？
独立性と多様性のある複数sourceを用意し、同じ事業者・上流・実装への共通依存を確認します。クラウドは事業者推奨の内部時刻源とleap方式を優先し、外部NTPとの無計画な混在を避けます。
クロックずれをどの指標と閾値で監視しますか？
offset、jitter、frequency drift、reach、最終同期、selected source、source切替、leap状態を監視します。閾値は認証・監査ログ・署名など業務ごとの許容差と正常時の実測から決め、単一の同期済みフラグだけで判断しません。
認証・ログ・電子署名へ時刻ずれが起きたらどう復旧しますか？
現在の時計差と同期状態を先に保全し、影響する認証、ジョブ、ログ、署名処理を隔離します。時刻を段階的または停止後に補正し、ずれた期間のtoken、ログ順序、再送、署名検証を再確認してから利用を開きます。
NTPサーバーは一つあれば十分ですか？
一つでは誤時刻を比較できず、停止時の切替先もありません。RFC 8633は少なくとも4つの独立・多様なsourceを推奨しています。用意できない場合も、少ない構成の限界を認識し、外形比較と障害時手順を補います。
時刻が合えばログの順序は正しいですか？
必ずしも正しくありません。非同期処理、ネットワーク遅延、バッファ、取り込み遅延で同時刻や順序逆転が起こり得ます。event ID、sequence、受信時刻、処理時刻を併用し、タイムスタンプだけで因果関係を断定しません。
