製造業者と、誰も尋ねない「監査証跡」の問い

製造業者は、顧客や監査人から求められた際にアクセスログを提示できる場合がほとんどです。しかし、より難しい問いがあります。それは「管理者権限を持つ者が、そのログを提出前に密かに編集できた可能性はないか」というものです。もし理論上でも「はい」と答えられるなら、そのログは証拠とは言えません。適切な資格を持つ者が、設計ファイルに誰がアクセスしたかについて、好きな内容を書けてしまう文書にすぎないからです。

本記事では、製造業者にとって監査ログが証拠として信頼できるものとなる条件と、多くの製造業者のロギングがこの基準を密かに満たしていない理由について解説します。

エグゼクティブサマリー

監査ログが顧客監査人や社内調査担当者にとって有用かどうかは、その完全性への信頼に完全に依存します。そして、その信頼はポリシーだけに依拠することはできません。基盤となるログストレージに管理者権限で技術的に編集できる場合、ポリシーで禁止されていても、それが実際に不可能であることとは異なります。エンジニアリングやITリーダーにとって、実践的な基準はアーキテクチャにあります。すなわち、システム管理者を含むいかなる個人も、実際に記録を改ざんできるかどうかが問われます。

主なポイント

1. 管理者が編集や削除できるログは、どれだけ詳細でも証拠にはなりません。
2. 基盤となるログストレージへのアクセスは、ポリシーだけでなくアーキテクチャ上も制限されていなければなりません。
3. 職務分掌はアクセス制限と同じくらい重要です。 設計ファイルにアクセスする人と、そのアクセス記録を確認する人は、同じ役割であってはなりません。
4. 完全性と即時性は信頼性の一部であり、切り離せるものではありません。
5. 顧客や監査人は、ログの内容だけでなく、その保護方法についてもますます質問するようになっています。

「詳細なログがある」では始まりとして不十分な理由

監査ログについての議論は、多くの場合カバレッジ（網羅性）に集中します。カバレッジは重要ですが、最初に問うべきことへの答えにはなっていません。

完全性のない詳細は、単なるよくできた物語にすぎない

誰が設計ファイルにアクセスしたかを詳細に記録したログも、その後に誰にも改ざんされていないという保証があって初めて信頼できます。

本当に重要な問い：「誰がこれを変更できたか」

最初に問うべきは、ログに何が記録されているかではなく、記録された後に誰が技術的にそれを変更できるかという点です。

ログの完全性を「手続き」ではなく「アーキテクチャ」で担保するとは

管理者はログを編集してはならないというポリシーは、管理者がそれを守ることを前提としています。アーキテクチャ上の制御は、そもそも技術的にそれができないようにします。

基盤となるログストレージへの恒常的なアクセス権を持たせない

この制御の最も強力な形は、製造業者自身のIT管理者もプラットフォームベンダーも、ログが保存されているOSやデータベースへの通常のアクセス権を持たない状態です。

例外は「抜け道」ではなく、本当に例外であるべき

防御可能な例外と抜け道を分けるのは、そのアクセスが一時的であり、二重承認が必要で、かつその操作自体も完全に記録されるかどうかです。

職務分掌による独立した二重の安全策

設計ファイルにアクセスできる役割が、そのアクセス記録を確認できる役割も兼ねている場合、その役割には本質的な利益相反が生じます。

実行者と監査者は分けるべき

真の職務分掌は、コンプライアンス、監査、ポリシー機能を運用管理とは別の役割に割り当てることです。

監査人に求められる前に基準を構築する

実践的なテストは、「製造業者の監査ログを技術的に改ざんできるのは誰か」、そして「実行する役割と監査する役割が本当に分かれているか」を率直に問い直すことです。

データコントロールプレーンがアーキテクチャに証拠性を組み込む方法

Kiteworksのデータコントロールプレーンは、強化されたアーキテクチャ上で稼働しており、Kiteworksも製造業者自身のIT管理者も、基盤となるOSやデータベース（監査ログストレージを含む）への通常のアクセス権を持ちません。サポートアクセスが必要な場合も一時的かつ二重承認制で、その操作自体も完全に記録されます。専用のコンプライアンスおよび監査者ロールにより、運用管理と監査機能が分離され、すべてのチャネルでのすべての操作が、改ざん不可能かつスロットリングのない監査ログとして完全かつ即時に記録され、SIEMツールに直接連携されます。

現在の監査ログが「管理者が編集できたかもしれない」という問いに耐えられるかどうかを試したい製造業者は、カスタムデモを予約できます。