工場や倉庫の入退室管理、監視カメラのアラート履歴を社内サーバーだけで保持しているなら、この記事が参考になるかもしれません。記録が内部にしかない監査ログは、権限を持つ担当者や侵入者によって書き換えられるリスクを常に抱えています。
海外のハッカソン投稿で公開された「SolSentry IoT」という実験プロジェクトは、この問題に対して興味深い解決策を示しています。Arduino（教育・試作でよく使われる小型マイコン基板）と超音波センサーで侵入検知を行い、検知イベントをSolana（高速処理を特徴とするパブリックブロックチェーン基盤）に記録するという構成です。本記事では、このアーキテクチャが示す「改ざん耐性のあるログ設計」という観点から、エンタープライズ開発の現場で何が落とし穴になりやすいかを整理します。
何が起きるか：中央集権ログの書き換えという事象
監視ログやアクセス履歴が単一のサーバー、単一のデータベースに集約されている場合、そのサーバーの管理者権限を持つ人物は理論上ログを自由に書き換えられます。
タイムスタンプの改ざん、映像データの削除、アラート発報の抑制が、痕跡を残さずに行われる可能性があるという点が核心です。これは悪意のある内部関係者だけでなく、認証情報が漏洩した場合の外部攻撃者にも当てはまります。
SolSentry IoTの説明では、侵入検知システムがこの「centralized telemetry manipulation（中央集権的なテレメトリ改ざん）」に対して脆弱だと指摘しています。監査証跡の信頼性そのものが、単一障害点に依存してしまっている状態です。
影響範囲は物理セキュリティに限りません。金融システムの取引ログ、医療システムの操作履歴、製造業の品質検査記録など、「後から誰かが見返して正しさを証明する必要があるログ」全般に共通する問題です。
なぜ起きるか：原因を段階的に分解する
原因は大きく3段階に分けて考えると整理しやすくなります。
1段階目は、ログの書き込み先が単一のシステムに閉じていることです。アプリケーションサーバーがログファイルやDBレコードを生成し、同じサーバーの管理者がそれを削除・変更できる権限を持っています。
2段階目は、ログに「改ざんされていないことを証明する仕組み」が付いていないことです。単純なテキストログやDBレコードは、書き換えられても外形上は正常なデータに見えてしまいます。
3段階目は、監査要件とシステム設計が切り離されて検討されていることです。監査・コンプライアンス部門が求める「誰がいつ何をしたかを後から覆せない形で証明する」という要件が、開発段階でログ基盤の設計に反映されていないケースがあります。
SolSentry IoTの実装は、この3段階すべてに対してブロックチェーンという1つの技術で応えようとしています。SHA-256（データのハッシュ値を計算する暗号学的アルゴリズム）でイベントをダイジェスト化し、Ed25519（Solanaが標準採用する署名方式）の秘密鍵で署名し、Solana Devnet（開発・検証用のテストネットワーク）に記録することで、仮にハードウェアが物理的に破壊されても証拠がバリデータノード群に残り続ける、という設計です。
自分のプロジェクトが該当するか確認する方法
まず、現行システムの監査ログがどこに保存されているかを確認します。
# ログの出力先設定を確認する例（アプリ側の設定ファイルを想定）
grep -i "audit" config/application.yml
grep -i "log_path\|log_destination" config/*.conf次に、そのログに対する書き込み・削除権限を誰が持っているかを確認します。DBであれば、監査テーブルに対する DELETE 権限や UPDATE 権限が誰に付与されているかをロール一覧で洗い出します。
-- PostgreSQLの例: audit_logテーブルへの権限を確認する
SELECT grantee, privilege_type
FROM information_schema.role_table_grants
WHERE table_name = 'audit_log';ここでアプリケーションの実行ユーザーや運用担当者のアカウントに DELETE や UPDATE が付与されていれば、改ざんの余地がある状態です。該当する場合は次の対策セクションに進んでください。
該当しない、つまり追記専用（append-only）の仕組みがすでにあり、権限分離もできているなら、ブロックチェーン連携のような大掛かりな対策は過剰である可能性が高いです。判断基準として、「監査ログの改ざんが実際に事業リスク・コンプライアンスリスクとして顕在化しているか」を先に整理することをおすすめします。
対策の手順：段階的に改ざん耐性を上げる
いきなりブロックチェーンを導入する前に、エンタープライズの現場で現実的な対策を段階的に積み上げる方法を示します。
ステップ1: 権限分離の見直し
監査ログの書き込み権限と削除・更新権限を別のロールに分けます。多くのRDBMSでは、INSERT のみ可能なロールと管理者ロールを分離することで、通常運用の担当者がログを消せない状態を作れます。
ステップ2: 追記専用ストレージへの移行
AWS S3のオブジェクトロック（Object Lock、一定期間オブジェクトの削除・上書きを禁止する機能）や、WORM（Write Once Read Many）対応のストレージを監査ログの保存先に使う方法があります。既存システムがログをローカルファイルやDBに直接書いているなら、ログ出力をストリーミングでこうした外部ストレージに転送する構成に変える価値があります。
ステップ3: ハッシュチェーンによる改ざん検知
ブロックチェーンに記録するまでいかなくても、各ログレコードに前のレコードのハッシュ値を含める「ハッシュチェーン」を実装すれば、どこか1件でも書き換えられた時点で後続すべてのハッシュが不整合を起こし検知できます。SolSentry IoTがSHA-256でイベントをダイジェスト化している部分は、この発想と同じ系統の技術です。
ステップ4: 外部notarization（第三者による記録の証明）の検討
それでも「社内の誰かが結託すれば改ざんできてしまう」懸念が消えない、規制業種・高リスク領域であれば、外部の第三者に証跡を預ける選択肢が出てきます。SolSentry IoTがSolanaのパブリックネットワークに記録しているのはこの発想です。Solanaを選んだ理由として、ブロック生成時間が約400ミリ秒と高速で、手数料が極めて低いためイベント単位の記録が経済的に成立する、という説明がなされています。時間あたり20件程度の侵入検知イベントでも、従来型のブロックチェーンでは手数料や確定待ち時間がネックになる場面です。
エンタープライズの現場でパブリックブロックチェーンを採用する場合は、法務・コンプライアンス部門との事前協議が前提になります。データの性質によっては、パブリックネットワークに記録を残すこと自体が情報漏洩や規制抵触のリスクになり得るため、ハッシュ値のみを記録しデータ本体は社内に留める設計が現実的な落としどころになりやすい点も確認しておく必要があります。
まとめ
監査ログの改ざんリスクは、単一システムへの集約・権限の未分離・証明可能性の欠如という3つの原因が重なって生じます。
自分のプロジェクトが該当するかは、ログの保存先設定と権限一覧（DELETE・UPDATE の付与状況）を確認することで判断できます。
対策は権限分離、追記専用ストレージ、ハッシュチェーン、外部notarizationという段階を踏んで検討すると、過剰投資を避けられます。
パブリックブロックチェーンの活用は選択肢の1つですが、まずは権限設定とストレージ構成の見直しから着手するのが現実的な一歩です。