不変の監査ログをホームサーバー上で非公開に保てるか？

はい、ホームサーバー上の監査ログを改ざんの証拠が残る状態にしながら非公開に保つことはできます。ただし、1人の管理者だけで完全な不変性を実現することはできません。

家庭では、AIエージェントの操作、ドアのイベント、設定変更、バックアップの削除などを、詳細を公開せずに恒久的に記録したい場合があります。ローカルストレージは機密性を確保し、ハッシュチェーン、署名付きチェックポイント、追記専用権限によって、後からの書き換えを検出しやすくします。残る信頼上の問題は、同じサーバー所有者がアプリケーション、ファイルシステム、データベース、バックアップをすべて制御できる場合に、署名鍵と以前のチェックポイントを誰が保護するかという点です。

プライバシーと不変性は別の性質

プライバシーは、イベントを誰が読めるかを制御します。不変性は、履歴を検出や承認なしに変更できるかどうかを制御します。暗号化によってログの内容を隠すことはできますが、管理者による暗号化ファイルの削除までは防げません。読み取り専用権限はアプリケーションアカウントを制限できますが、root権限には通用しない場合があります。そのため、実用的な設計では、機密性、追記アクセスの制限、暗号学的な連続性を組み合わせます。

immudbは履歴を検証します。以前のレコードバージョンを保持し、クライアントが暗号学的証明を確認できるようにする、不変データベースです。イベントをプライベートネットワーク内に保持することは可能で、検証のために平文を一般公開する必要は本来ありません。重要なのは、後の状態が以前の状態を参照して確定され、検証者が書き換えられた履歴を検出するために十分な信頼情報を保持していることです。

つまり、「非公開の不変ログ」は通常、非公開であり、追記専用であり、独立して検証可能なログを意味します。一般的なデータベースの監査テーブルよりは強力ですが、決して変更できない物理媒体ほど強固ではありません。ホームサーバーでは、管理者による復旧、スナップショット、ディスク全体の復元といった便利な機能によって、ロールバックを検出できないまま古いログ状態まで復元される可能性があるため、この違いは重要です。

Merkle証明はすべてのイベントを公開せずに書き換えを検出する

ハッシュチェーンでは、各エントリが直前のエントリに依存します。Merkleツリーでは、多数のエントリのハッシュを1つのコンパクトなルートにまとめます。古いイベントを変更すると、そこから導出されるコミットメントも変わります。検証者は包含証明を使って、あるイベントがコミット済みのツリーに含まれていることを確認できます。また、一貫性証明を使って、新しいツリーが古いツリーを拡張したものであることを確認できます。

RFC 9162では、Merkleツリーと一貫性証明を使った追記専用の透明性ログについて説明しています。証明書の透明性は公開向けの仕組みですが、この暗号学的な方式は非公開イベントにも適用できます。ホームシステムでは、署名付きツリールートや暗号化された証明バンドルだけをエクスポートし、イベントのペイロードや識別メタデータは信頼できるネットワーク内に保持できます。

ハッシュ化だけでは、推測しやすいデータを隠せません。イベントの値が少数の候補に限られる場合、観察者は値を推測してハッシュと照合できる可能性があります。機密性の高いペイロードには認証付き暗号化を使い、平文のメタデータは最小限にし、必要に応じてノンスを含めてください。公開チェックポイントを増やすとロールバック検出能力は高まりますが、プライバシーを検討せずに生のイベントハッシュを公開すると、タイミングや所属情報が漏れる可能性があります。

単一サーバーの信頼境界はいずれ破られる

攻撃者がログデータベース、署名鍵、アプリケーションの認証情報、保存されているすべてのチェックポイントを入手した場合、その攻撃者は履歴を書き換え、内部的に整合した代替履歴を作成できる可能性があります。ローカルの追記専用ソフトウェアは攻撃のコストを高めますが、すべての信頼アンカーが同時に置き換えられた場合、新たに捏造されたタイムラインを見分けることはできません。すべての証明を1台のマシンに置くことの根本的な限界はここにあります。

SigstoreのRekor透明性ログは、追記専用レコード、署名済みデータ、外部検証を使い、異なる当事者が一貫性を監視できるようにします。非公開のホーム環境では、内容を公開せずにこの独立性を取り入れられます。たとえば、署名付きルートを2台目のデバイスにコピーする、定期的なチェックポイントを印刷またはエクスポートする、サーバーを変更できないアカウントにコミットメントだけを送る、といった方法があります。

信頼できるチェックポイントが他の場所に残っていなければ、完全な侵害を受けた時点で不変性の主張は成立しません。また、操作前にログを無効化できる場合、証拠を残さずに時刻を書き換えられる場合、アプリケーションが曖昧な成功メッセージしか記録しない場合も同様です。取り込み経路を保護し、AIエージェントが最後に生成した説明だけでなく、リクエストの識別情報、実行者、対象、結果、単調増加するシーケンス番号を記録してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

ロールバック検証でログを確認する

テストイベントを作成し、署名付きチェックポイントを別のデバイスに保存してから、使い捨てコピーに対して3つの攻撃を試します。古いイベントの編集、イベントの削除、以前のスナップショットへの復元です。それぞれの試行後に、外部チェックポイントから検証を実行してください。正常な設計であれば、復元されたデータベースが内部的に整合して見える場合でも、履歴の変更をすべて検出できるはずです。

永続的なアプリケーションデータでは、現在の状態、履歴、バックアップに異なる役割を持たせる必要があります。ZimaSpaceによる永続データの役割の解説は、有用なストレージの例を示しています。運用状態と履歴の証拠は互換性のあるものではありません。監査台帳、検証チェックポイント、暗号化キー、通常のバックアップカタログは、それぞれ別の保護された場所に保管してください。

独立した検証者が編集、削除、ロールバックを検出でき、同時に権限のない閲覧者がイベントの内容を復元できない場合にのみ、ドリルに合格したと判断します。同じサーバー上でしか検証が成功しない場合は、少なくとも署名付きルートを別の場所に移してください。プライバシーが損なわれる場合は、公開するメタデータを減らすか、証明バンドルを暗号化してください。実際の目標は、どのビットも決して変わらないという無条件の約束ではなく、明確に定義した脅威モデルの下で改ざんを検出できることです。

よくある質問

WORMディスクは必要ですか？

いいえ。ハードウェアやオブジェクトロックによる保持機能は削除への耐性を高められますが、暗号学的証明と独立したチェックポイントによって、ソフトウェアで管理される履歴にも改ざんの証拠を残せます。それぞれが異なる脅威から保護します。

不変ログから個人データを削除できますか？

書き込み前に、データの最小化と保持期間を計画してください。1つの方法として、機密ペイロードを暗号化し、後からレコードごとの鍵を破棄しながら、機密性のないコミットメントを保持する方法があります。ただし、法的要件は管轄区域と利用目的によって異なります。

非公開ログにブロックチェーンは必要ですか？

いいえ。署名付きハッシュチェーンや、独立したチェックポイントを備えたMerkleツリーによって、コンセンサス、公開トークン、家庭内イベントの公開なしに、検証可能な追記専用履歴を提供できます。