Nebula のブロックリスト: 配布するのはあなたで、灯台ではない

ブロックリストの適用は検査するホスト側の性質であり、検査される証明書の性質ではありません。項目を一度も読み込んでいないマシンはその識別子を受け入れ続け、ハンドシェイクのどこにも二つのピアが食い違っていることを知らせるものはありません。同じ露出した資格情報に対して、安価な対処と高価な対処では到達範囲も可逆性も異なるため、意図して選んでください。以下の節では、項目が何をするのか、どこに届ける必要があるのか、ローテーションがより良い答えになるのはいつか、そしてどちらかが機能したことをどう証明するかを扱います。

ブロックリストの項目が実際にすること

PKI 構成は、証明書が正しく署名され有効期限内であってもホストが拒否しなければならないフィンガープリントを列挙します。適用はローカルで行われ、そのホストがサービス起動時に読み込んだリストに対して行われます。項目の内容が証明書の中を移動することはないため、ピアは提示された資格情報から判断を学ぶことはできません。ここで灯台が何の役割も果たさないのは、灯台がピア同士の探索を助け、直接経路が失敗した場所でトラフィックを中継するからです。灯台は発見と中継の層であり、構成の配布チャネルではありません。

あるマシンを更新すると、そのマシンの判断だけが変わり、他のすべてのピアは元のままです。署名機関を信頼し、項目を一度も見ていないピアには何も拒否する理由がありません。したがって、あなたが見ているコンポーネントはリストの適用を一度も求められていないため、灯台を眺めて失効を試しても何も証明できません。

証明書を特定し、デバイスを特定しない

ホスト名、デバイスのラベル、現在のアドレスは今日のあるマシンを識別しても来月には別の何かを指すため、拒否しようとしている資格情報のフィンガープリントを使ってください。そうした文字列はどれもブロックリストには現れず、どれも再インストールを生き延びません。証明書を印刷し、フィンガープリントを読み、それが廃止される資格情報のものであって、その後継のものではないことを確認してください。後継がすでに発行されている場合、新旧の証明書は名前を共有しつつ他のあらゆるフィールドで異なりうるため、両方のファイルを読むことが重要です。

どのフィンガープリントをいつブロックしたかを記録し、後日の監査で完了した変更と意図した変更を区別できるようにしてください。項目が署名機関を無効化するわけでも、その機関の将来の証明書が受け入れられるのを止めるわけでもないことも書き留めてください。ホスト証明書のブロックと侵害された機関の交換は、異なる結果を伴う別の操作です。

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

他の構成と同じように配布する

リストは、誰かが思い出したときに編集するファイルではなく、配布の仕組みを備えた構成として扱ってください。差分ではなくリスト全体を送ることで、以前の更新を逃したホストが隙間を溜め込むのではなく収束します。Nebula PKI のドキュメントもまさにそう勧めており、その助言は手作業の手順に言い換えるのではなく、文字どおり従う価値があります。

実行中のサービスが内容を再読み込みしたことを確認してください、ディスク上のファイルが変わっただけでは足りません。どのマシンが変更を適用したかを追跡し、未完了のリストを空になるまで見える状態に保ってください。一週間閉じられたノートパソコンは、その判断を一度も学んでいないピアであり、誰も予想しなかったネットワークから再接続するかもしれません。次の失効でそれを再利用し、最初のときに手順がデバッグされるため、フィンガープリントの隣に配布方法を記録してください。

ブロックリストか機関のローテーションか

ブロックリストの項目は狭く、一つの識別子が機能しなくなり、それ以外はすべて続きます。署名機関のローテーションは広く、その機関が発行したすべての証明書が信頼されなくなり、すべてのホストに新しい資格情報と新しい信頼の基点が必要です。前者は的を絞った失効、後者は移行であり、必要な承認もメンテナンスの時間帯も異なります。表は両者を到達範囲、手間、可逆性で並べています。

失ったノートパソコンには、影響範囲が一つの識別子であり、間違ったフィンガープリントをブロックしてしまっても変更を戻せるため、ブロックリストが適しています。漏えいした機関の鍵には、まだ発行されていない証明書にはブロックリストが役に立たないため、ローテーションが必要です。その両極の間では、機関は一つのホストより大きいため、露出した資格情報が他に何かを署名できたかどうかを問うてください。

圧力の下での選択は既定で広い選択肢を生みやすいため、インシデントの前に判断を書き留めてください。どちらの道を取るにしても、残る作業は同じで、重要なホストで適用が起きたことを証明することです。その時点でフィンガープリントと日付を記録することが、後で証明を可能にします。

拒否と残りを検証する

ブロックされた識別子から接続して失敗を確認し、次に許可されたピアから接続して必要なものにまだ到達できることを確認してください。全員を壊す変更は成功した失効ではありません。キャッシュされた状態が結果を隠すことがあるため、どちらも新しいセッションから行ってください。

変更後に確立済みのセッションが終了するかどうかを確認し、ファイルを編集すれば何かが終了すると決めつけるのではなく、自分のバージョンと構成での挙動を記録してください。disconnect_invalid オプションは証明書が期限切れまたは無効なクライアントを対象とするため、それに頼る前に自分のケースにどう当てはまるかを確認してください。即時の終了が必要条件なら、それを個別に試し、観察したことを記録してください。リストを次の再起動までしか適用しないホストには最初のテストが隠していた配布の問題があるため、そのうえで再起動後にテストを繰り返してください。健全な灯台は発見が機能することを教えてくれますが、どのピアかポリシーを適用したかまでは教えてくれません。