時計が狂っていれば記録は証拠にならない
一言でいうと
エアギャップ環境には、外部の時刻源がありません。ネットワークの中に立てた時刻源は、ホスト同士の相対的な順序を合わせてくれるだけで、絶対時刻は保証しません。その違いを知らないまま「記録は正確です」と書いた陳述書は、監査で崩れます。
なぜ必要なのか
障害調査も監査対応も、結局は「何が先に起きたのか」を問います。ところが、記録の時刻は、その記録を残した機械の時計が示した値で、機械ごとに時計は違います。秒単位で違えば人が気づきますが、2秒ほどの差は、誰にも気づかれないまま、原因と結果をひっくり返します。実際に、調査で最もよくずれるのが、この点です。デプロイが障害よりあとに起きたように見えれば、調査は見当違いの方向に進みます。
インターネットが届く場所では、この問題はおおむね静かに解決されます。公開NTPサーバーを複数見ていれば、時計は自然に収束します。エアギャップ環境では、その前提が消えます。ネットワークの中に時刻源を1つ立てて、全員がそれに合わせますが、その時刻源自身は、外に合わせる対象がありません。RFC 5905が定義したストラタム(stratum)で、こうした時刻源は、自分自身を基準にする位置に立ちます。その結果、ネットワークの中のすべての記録は互いに一貫していますが、その全体が外の世界よりどれだけ進んでいたり遅れていたりするかは、誰にも言えません。この事実を陳述書に書かなければ、あとで問題になります。
どう動くのか
判定は、4つの層に積まれます。
1つ目に、表記を1つにまとめます。同じシステムの中でも、ログの時刻表記はばらばらです。オフセットが付いたISO 8601、オフセットのない現地時刻、epoch秒、末尾にZが付いたUTC。ここで最も危険なのは、オフセットのない時刻です。それをUTCとして読むと、韓国のタイムゾーンでは、9時間がまるごとずれます。ログファイルだけを見ても、どちらなのかはわからないので、その事実は、システム文書から持ってこなければならず、陳述書にもその根拠を書かなければなりません。RFC 3339がオフセットを必須と定めた理由が、これです。
2つ目に、系統をたどります。各ホストがどこから時刻を受け取っているかを、1歩ずつたどれば、大半は宣言された時刻源に届きます。届かないホストが問題です。設定が消されて、自分の時計をそのまま使っているホストは、見た目にはまともな時刻を出し続けるので、ログだけを見ても区別できません。系統を最後までたどるのが、唯一の方法です。
3つ目に、記録同士がぶつかる場所を探します。2つのホストがやり取りしたリクエストとレスポンスで、レスポンスがリクエストより先の案件があれば、2つの時計が、少なくともその差の分だけ開いているという意味です。これは推測ではなく、下限です。送った側と受けた側が、同じ出来事を、別々の時計で記録したために生じる値で、同期レポートのオフセットと比べれば、レポートが事実かどうかも確認できます。
4つ目に、補正して残るものを見ます。オフセットで補正すれば、大半の矛盾が消えます。消えないものが残るなら、それは時計の問題ではなく、記録自体の欠陥です。この2つを分けることが、この作業の核心です。補正で説明できる区間は、条件付きで使え、説明できない区間は、証拠として使えません。
もう1つあります。時計の同期は、その時刻にその記録が存在したことを証明しません。それは別の層の仕事で、RFC 3161のタイムスタンプのように、第三者が署名してくれる構造が必要です。同期とタイムスタンプを同じものとして語る陳述書は、信頼を失います。ログ管理全般については、NIST SP 800-92が、時刻同期をログの信頼性の前提として扱っています。
現場での姿
あるエアギャップ環境への納品で、調査が2日間空回りしました。バッチ作業が、キューに入れた時刻より先に処理されたように見えたからです。原因は、処理ノードの時計が2.4秒進んでいたことで、同期レポートには、その値がそのまま書かれていました。誰もそのレポートを、ログと一緒に並べて見なかっただけです。補正したあとに残った矛盾は、わずか1件で、その1件が、本物のバグでした。
もう1つよく見るのは、自分自身を時刻源として書いてあるホストです。インストール中に設定を1回消して、元に戻さなかったもので、そのホストのログは、もっともらしい時刻を出し続けます。系統を図に描いてみるまでは、現れません。
3つ目は、陳述書の表現です。調査結果を渡すときに、「時刻は正確です」と書きたい誘惑は大きいのですが、その文を、データは裏付けていません。データが裏付けるのは、「この区間の記録は互いに矛盾せず、報告されたオフセットで説明される」までです。この違いは、言葉遊びではありません。あとで1件でもずれれば、前の文を書いた陳述書は、まるごと信頼を失い、あとの文を書いた陳述書は、その1件だけを見直せばよいのです。監査が好む文書は、断定する文書ではなく、何を確認して何を確認できなかったかが分かれている文書です。
次のラボですること
表記が4つに分かれた5つのホストのログを1つの軸にまとめ、オフセットのないログをUTCとして誤って読むと、何件がどれだけずれるかを数えてみます。そのあと、時刻の系統をたどって、宣言された時刻源に届かないホストを探し、リクエストとレスポンスの矛盾で、時計誤差の下限を求めて、補正します。最後に、ホストごとに記録をどれだけ信頼できるかの等級を付け、何を信頼でき、何を信頼できないかを一緒に書いた陳述書を書きます。