前置き
イベントソーシングを取り入れることにより、セキュリティ面の変化はどうなるでしょうか？
攻撃者によって、データが破損したりすることはないのでしょうか？
今回は、イベントソーシングによるセキュリティ要件の変化を追っていきます。
イベントストアが持つ「壊れにくい」性質
結論から言うと、イベントストアも他のシステムと同様に攻撃対象になり得ますが、
その設計思想がデータの破損や改ざんに対して非常に高い耐性を持っています。
イベントソーシングの根幹をなす2つの原則が、強力な防御策として機能するからです。
1. 不変性 (Immutability)
イベントストアの最大の原則は「追記のみ」であることです。
一度書き込まれたイベントは、決して変更・削除されません。
従来のDB
UPDATE文で攻撃者がレコードを不正に書き換えると、元のデータは失われ、検知が困難な場合があります。
イベントストア
データを「上書き」できないため、攻撃者は過去の事実を改ざんできません。
もし不正な操作をしようとしても、それは「不正なイベント」として新たに追加
されるだけです。
2. 完全な監査証跡
全ての「状態変化」がイベントとして記録されているため、システムの振る舞いの全てがログとして残ります。これは、不正な操作が行われた場合に非常に強力です。
もし攻撃者が「残高を不正に増やす」というイベントを追加したとしても、その不正なイベント自体が消えない証拠として記録に残り続けます。
そのため、後から追跡・検知することが非常に容易です。
具体的な脅威と対策
もちろん、これらの原則だけに頼るわけではなく、以下のように多層的な防御を行います。
万が一、破損した場合
それでも物理的な障害や高度な攻撃でデータが破損する可能性はゼロではありません。
その場合の復旧プロセスは以下のようになります。
①. 検知
上記のハッシュチェーンなどにより、どこでデータがおかしくなったかを特定します。
②. バックアップから復元
定期的に取得しているバックアップから、破損する直前の状態まで復元します。
③. イベントの再適用
バックアップ以降に発生した「正当な」イベントのみを再度適用（リプレイ）して、最新の状態に戻します。
イベントソーシングは、このように
「イベントを再適用して状態を復元する」ことが得意なため、復旧プロセスと非常に相性が良い
です。
結論として、イベントストアは攻撃に対して無敵ってわけではありませんが、
その「不変性と監査性」という基本設計が、従来の書き換え可能なデータベースよりも改ざんの検知や復旧を容易にし、結果として非常に堅牢なシステムを構築できるのです。
セキュリティコンポーネントとイベントストアの関係
では、セキュリティコンポーネントの未実装などにより、仮にセキュリティコンポーネントの実装がデータの改ざんなどに対し、脆かったとしても、イベントストア自体が改ざんに強いため、幾分か安心なのでしょうか？
※ 実はこの考え方は非常に危険です。
両者は役割が全く異なるため、どちらか一方だけでは不十分です。
比喩
例えるとしたなら、
セキュリティコンポーネントは「金庫の扉」 で、イベントストアは「金庫の中の会計帳簿」 です。
もし「金庫の扉」が脆弱なら、誰でも簡単に中に入って、帳簿に「1億円を送金した」とデタラメな取引を書き込めてしまいます。
会計帳簿（イベントストア）自体は、その「不正な取引が記録された」という事実を完璧に記録し、後から消したり改ざんしたりはできません。
いかがでしょうか？？
不正な取引が記録されてしまった時点で、システムの状態は既におかしくなっています。
たしかに、不正事実の記録はできたものの、被害は実際に起きてしまっています。
役割の明確化
セキュリティコンポーネントとイベントストアはそもそも責務が違います。
・セキュリティコンポーネントの役割：侵入を「防ぐ」こと 🛡️
そもそも不正でデタラメなイベントを書き込ませないようにするのが役目です。認証や認可をしっかり行い、正当なユーザーによる正当な操作だけをイベントとして受け付けます。これが第一の防衛線です。
・イベントストアの役割：記録を「守り、検知する」こと 🧐
一度書き込まれたイベントが、後からこっそり改ざん・削除されていないかを保証するのが役目です。（脅威モデリングのSTRIDEのログ改ざんが相当）
これにより、万が一不正なイベントが書き込まれたとしても、それが「いつ、誰によって、どのように」行われたかを正確に追跡できます。
イベントストアの堅牢性は、あくまで「記録の完全性」を守るためのものです。
システム全体の安全性を確保するには、各サービスやコンポーネントの入り口である
セキュリティコンポーネントを強固にすることが絶対に必要です。
両者は互いを補完し合う関係であり、車の「ブレーキ」と「エアバッグ」の関係のように、
どちらも不可欠な安全装置だと考えてください。
ゼロトラストアーキテクチャ
実は上記の組み合わせは、ゼロトラストアーキテクチャの実現と非常に相性が良いです。
両者を組み合わせることで、ゼロトラストの基本原則である
「決して信頼せず、常に検証する (Never Trust, Always Verify)」
「侵害を前提とする (Assume Breach)」
を、アーキテクチャレベルで体現しやすくなります。
ゼロトラストとの親和性
・常に検証 (Always Verify)
セキュリティコンポーネントの役割として、全ての書き込みリクエスト（コマンド）を個別のトランザクションとして扱い、その都度
「誰が」「何を」しようとしているのかを厳格に認証・認可します。
システムの入り口で、リクエストを一切信頼せずに都度検証します。
・侵害を前提とする (Assume Breach)
イベントストアの役割として、万が一、防御を突破されて不正なイベントが書き込まれたとしても、その記録は不変の証拠として残り続けます。
これにより、
侵害の検知、影響範囲の特定、そして事後対応が非常に容易になります。
まさに「侵害は起こりうるもの」として設計されています。
組み合わせによる相乗効果
このアーキテクチャは、強力な多層防御を形成してくれます。
①. 予防 (Prevention)
セキュリティコンポーネントが、不正なアクセスの大半を入り口で防ぎます。
②. 検知と対応 (Detection & Response)
イベントストアが、万が一侵入された場合の攻撃者の活動をすべて記録し、迅速な検知と対応を可能にします。
このように、
「入口での厳格な検証」と「内部での完全な可観測性・監査性」を両立できる
ため、ゼロトラストの考え方を実現する上で非常に強力な設計パターンとなります。