監査および不変ログ

1）なぜそれを必要とします

監査の目的は、セキュリティ、調査、財務報告およびコンプライアンスを維持するために「、誰、何、何、どこ、いつ、なぜ」を証明可能な完全性で捕捉することです。
Immutable log-イベントが追加のみで記録され、その後の変更/削除は暗号的手段とストレージポリシーによって不可能または検出可能な形式とストレージです。

2）脅威モデルと制御目標

リスク：

インサイダーによるイベントの意図的な編集/削除。
時間/ソースの置換（リプレイ/バックデート）。
ノードの「Quiet」ロギングシャットダウン。
事故/移行中のログの一部の損失。
プライバシーとの過度のPII収集と不和。

目的：

1.整合性：変更/削除に対する保護によって証明されています。

2.完全性：キーフロー（制御平面、データプレーン、アクセス、お金）の閉鎖。

3.時間精度：再現性、同期時間。

4.アクセシビリティ：SLO内の読み取りと検索。

5.プライバシー：PII最小、トークン化/暗号化、使用の合法性。

3）分類とイベントの優先順位

イベントを保存と不変性の優先順位付けでレイヤーに分割する：

Control Plane：認証/承認、構成変更、キー操作（KMS）、秘密管理、ポリシー変更。
データプレーン：オブジェクト/レコード/チェック/支払いへのアクセス；読み取り/作成/削除。
管理者とDevOps： SSH/コンソール、 CI/CD、インフラストラクチャ/IaCの変更、権利のエスカレーション。
製品：取引、請求、顧客操作。
システム/ネットワーク：カーネル/エージェント/プロキシ/バランサー、ブローカー、データベース。
セキュリティ：IDS/IPS/EDR、 WAF、アンチDDoS、アンチフラウド、DLP。

クラスごとに、criticality、スキーム、必須フィールド、保存期間、不変性の要件などを修正します。

4）必須フィールドとフォーマット

相関IDは'trace_id'、 'span_id'、 'request_id'、 'actor_id'（ユーザー/サービス）、'tenant_id'、 'resource_id'です。
A&Aコンテキスト：認証メソッド、アクション時のロール/ポリシー。
時間：RFC3339/UTC、ミリ秒/ナノ秒；同期ソース。
アクションと結果：操作の種類、目的、ステータス、影響を受けるオブジェクトの数。
Integrity：ローカルHMACレコード、シーケンス番号、hash-prev。
スキーマ：安定したモデルを持つJSON（たとえば、共通のイベント辞書と互換性があります）。

禁止：秘密、キー、トークン、完全なPAN、パスワード、秘密鍵。PII-必要に応じてのみ、マスキング/トークン化を行います。

5）時間および同期

タイムソース：少なくとも2つの独立したソース（NTP/PTP）+バイアス監視。
クリティカルタイムシグネチャ：イベントのバッチには、信頼できるタイムスタンプ（TSA）サービスまたは内部タイムシールサービスを使用します。
ルール：ローカルタイムゾーンなし、UTCのみ；ログとオフセット/時間の品質。

6）ログストリームアーキテクチャ

エージェント→バッファ→トランスポート→ランディング→ハッシュチェーン/シグネチャ→コールド/アーカイブ→検索するインデックス。

ノード上のコレクション：ディスク上のバッファ（背圧）を持つライトエージェント（デーモンセット/サイドカー）。
輸送：保護されたチャネル（TLS/mTLS）、保証された配達（少なくとも1回）、idempotent-ingest。
ランディングゾーン：「raw」形式のオブジェクトストレージ（日付/テナント/タイプによるバッチ）。
インデックス：オンラインクエリ（ホットレイヤー）の検索/分析エンジン。
アーカイブ（WORM）：保持ポリシーと法的保持を持つ不変のバケット/テープ。
アンカー/シール：ハッシュチェーンのパックの定期的な「シール」（下記参照）。

7）暗号の不変性

7.1ハッシュのチェーン（追加のみ）

各エントリには、'hash_curr=H （record）'、 'hash_prev'、 'seq'が含まれます。編集するとチェーンが壊れます。

チェーン擬似コード：


prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7.2パックとタイムスタンプの署名

N 秒/MBごとにブロックを形成します：すべての'hash_curr'のMerkleルート。
監査キー（KMS/HSMに安定して格納）でブロックに署名します。
TSAタイムスタンプを追加し「、透明度ログ」を公開します。
オプション：ルートハッシュを定期的に外部の証明可能なスペース（たとえば、独立したジャーナルや公共の不変のストレージ）にアンカーします。

7.3監査キー管理

署名キー-KMS/HSM、予定通りの回転、マルチファクタアクセス、エクスポート用のデュアルコントロール。
主要な取り消し→新しい信託ブランチ；古い署名は検証可能なままです。

8）保持およびWORMポリシー

WORM/immutability： P0/P1クラスの保持ポリシーと法的保持ポリシーで不変コンテナ/バケットを含める。
バージョン管理：有効；削除-遅延のある手順のみ（即時パージの禁止）。
保持：ホット（7-30日）、ウォーム（3-6ヶ月）、コールド/アーカイブ（1-7年以上-レギュレータ/契約に応じて）。
マルチテナント：テナントごとに名前空間/アカウント/暗号化キーを分離します。ログアクセスレポート。

9）プライバシーと最小化

必要性の原則に従って収集：私たちは不要なログを記録しません。
機密フィールドのトークン化/仮名化、識別子のソルトハッシュ。
共有オブジェクトストレージに保存されている場合、プロデューサー側フィールド暗号化（AEAD）。
削除する権利（該当する場合）：（設計中に計画された）コンテナの不変性に違反することなく、フィールド/パーツキーの暗号消去によって実装されます。

10）監査そのもののアクセス、役割、監査

スプリット：生産者≠読者≠管理者。
WORMからの読み取り専用。保持ポリシーの変更-承認を得た別の役割と手順を通じて。
すべての読み取り/エクスポート操作は、セカンダリログ（メタ監査）に記録されます。
調査/コンプライアンスのためのエクスポート-ハッシュブロックディレクトリとトラストチェーンで暗号化された形式で。

11）観察可能性およびSLO

メトリクス：注入レート、インデックスへの遅れ、％lost/repeated、同期されていない時間の割合、署名/アンカーエラー、バッファ充填。
SLO： ≥ 99。9％のイベントがX秒≤ホットインデックスに配信されました。0シーケンス内の説明されていない「穴」；100％のブロックが署名され、タイムスタンプされています。
アラート：注入一時停止>N分、無効なハッシュ成長、チェーン発散、シグネチャ/タイムスタンプ障害、しきい値を超えたタイムオフセット。

12）テストおよび検証

Red/Blueテスト：異なる段階でレコードを編集/削除する試み。検出の点検。
カオス：ノード上のエージェントの無効化、ネットワークの破壊、バッファオーバーフロー、「タイムスプーフィング」。
暗号チェック：チェーンの定期的な検証、Merkleルーツとスタンプの和解。
フォレンジック：エンドツーエンドのログから調査用スクリプトを再生します。

13）操作およびプロシージャ

Runbook 「integrity check」（オンデマンドおよびスケジュール）。
当事者の法的保持と一時的な「凍結」のための手順。
信頼の連鎖を維持しながら発見と輸出手続き。
監査キーの回転と妥協への対応（新しい信託ブランチ、ブロックの再署名、通知）の計画。

14）ミニレシピ

ブロック署名（Merclization+TSA、回路図）：


records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

チェーン整合性チェック（フラグメント）：


for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

保持ポリシー（アイデア）：

制御/データ平面P0：ホット30日→暖かい6ヶ月→アーカイブ7年（WORM）。
DevOps：ホット14日→暖かい3ヶ月→アーカイブ1年。
Securiti信号：ホット90日（調査のために）、その後1-3年。

15）頻繁なエラー

"ログはスキーマなしのテキストです。"スキーマがなければ、決定論的な完全性と検索はありません。正規のJSONと固定フィールドが必要です。
相関関係はありません。'trace_id'が存在しないと、調査が中断されます。
現地時間。UTCのみとオフセット制御。
変更可能なボリュームへの書き込み。WORMなしでは、不変性はフィクションです。
読み込みを記録しないでください。機密データを読むことは、書くことよりも簡単に修正することが重要です。
ログの中の秘密。パターンの「レッドリスト」を送信する前に消毒剤をオンにします。
すべてのための1つのキー。署名と暗号化キー-ロールと回転で、別々に。

16）コンプライアンスと規制

貯蔵寿命/不変性の要件は、ドメイン（金融、支払い、通信など）に依存します。
証明：WORM/保持プロトコル、回路検証レポート、ログアクセスログ、法的保持およびエクスポート手順の可用性。

17）チェックリスト

販売する前に

イベントタクソノミとスキーマ承認済み（必須フィールド）。
エージェント、バッファ、保護されたトランスポート、背圧設定。
含まれている：ハッシュチェーン、ブロック署名、タイムスタンプ、透明度ログ。
WORM/プレゼンテーションストレージが有効になっています。上書き/削除できないことをテストします。
機密フィールドのマスキング/トークン化。
時間同期とオフセット監視。
KMS/HSMでの監査キーの回転計画と保存。

Operation（オペレーション）

チェーンとブロックの毎週の検証（+レポート）。
Circuit Break/Signature Error/Time Offsetアラート。
定期的なRed-team置換/削除テスト。
リテンションとコストの定期的なレビュー。

18） FAQ

Q：データベースレベルで「単に追加」だけで十分ですか？
ああ、いやいや。暗号保証（ハッシュ、ブロック署名、タイムスタンプのチェーン）とWORMポリシーが必要です。

Q：データを削除する権利はどうですか？
A：フィールド/パーティー用の暗号消去（キー除去）を設計し、メディアを変更できないようにし、ログを証明可能にします。

Q：ブロックに署名するには別のキーが必要ですか？
ああ、そうだ。ストレージ暗号化キーからブロック署名キーを分離します。回転および監査のKMS/HSMの店。

Q：公共空間に「アンカー」することは可能ですか？
A：任意。これにより検証性が向上し、回路内での「書き換え履歴」がカットされます。

監査および不変ログ

販売する前に

Operation（オペレーション）

お問い合わせ

迅速な連絡

動画はまもなく更新されます

現在、私たちはプロジェクトで非常に多忙です