プライベート IM とコンプライアンス：保持、監査、暗号化の実務

自社で IM システムを運用すると、メッセージデータを管理できます。同時に、そのデータが適切に扱われていることを証明する負担も引き受けます。コンプライアンスチームが尋ねるのは「暗号化はありますか」ではなく、「誰が何を、いつまで読めるのか、それをどう示せるのか」です。

本記事は、監査や調査の場面でプライベート IM を説明可能にする設計判断を整理します。一般的なエンジニアリングの指針であり、法的助言ではありません。

機能ではなく義務から始める

組織によって義務は異なります。業界規制、データ保護法、内部ポリシー、顧客との契約条件です。保持期間や暗号化モデルを選ぶ前に、次の点を文書化します。

• 対象となるデータ分類（メッセージ内容、メタデータ、ファイル、通話記録、管理操作）。
• 分類ごとの最小および最大の保持期間。
• 誰が、どの承認のもとで内容にアクセスできるか。
• 調査時に何を、どのくらいの期間内に提出する必要があるか。
• どの法域が関係するか。

これらの答えがアーキテクチャを決めます。「すべてを永久に保持する」設計は、削除が簡単だからという理由で定期的に削除する設計と同じくらい問題があります。

保持ポリシーの設計

保持は技術的な実装を伴うポリシーであり、両者は一致していなければなりません。

• 分類ごとの期間。 チャットは1年を既定とし、契約関連の通信はより長く、運用ログはより短く。
• 削除の仕組み。 論理削除、物理削除、バックアップの期限切れをそれぞれ定義する必要があります。バックアップが保持ポリシーの許容期間より長くデータを保持するなら、そのポリシーは不正確です。
• リーガルホールド。 調査では、システム全体をアーカイブ化することなく、特定のアカウントや会話の削除を凍結する必要があります。
• ユーザー側の期待。 メッセージが消えるとユーザーが信じているなら、システムは実際に削除しなければなりません。

有用なテストとして、1つのメッセージを選び、そのすべてのコピー（プライマリストア、レプリカ、バックアップ、監視、エクスポート）を追跡し、各コピーの保持挙動を確認します。

監査ログ

監査ログは「誰が、いつ、どこから何をしたか」に答えます。IM では、次のイベントが有用です。

• 認証とセッションのライフサイクル（失敗を含む）。
• 管理操作：グループ作成、メンバー変更、権限更新。
• サポート担当者やコンプライアンス担当者によるメッセージ内容へのアクセス。
• 保持、暗号化、エクスポートに影響する設定変更。
• エクスポート操作とその範囲。

設計原則は次のとおりです。

1. ストレージの分離。 監査ログはメッセージと同じデータベースに置くべきではありません。侵害が証拠を消してはなりません。
2. 追記専用。 変更可能なテーブルよりも、完全性管理を備えた不変ストレージを優先します。
3. 内容の最小化。 義務が内容の記録を要求しない限り、メッセージ本文ではなく識別子と操作を記録します。
4. 時刻同期。 コンポーネント間で一貫した UTC タイムスタンプがあることで、調査が可能になります。
5. 監査ログへのアクセス自体を監査します。

ログは定期的にレビューします。誰も読まない監査証跡は、統制ではなくコンプライアンス上の成果物です。

暗号化と鍵管理

通常、3つの層が議論されます。

• 通信の暗号化。 必須です。API には TLS、メディア転送には暗号化されたトランスポートを用います。
• 保存時の暗号化。 データベースとオブジェクトストレージの暗号化です。問題は誰が鍵を持つかです。
• エンドツーエンド暗号化。 内容はサーバーから読めません。機密性は最も高くなりますが、コンプライアンスとサポートにできることが変わります。

鍵管理の判断は、アルゴリズムの一覧よりも重要です。

• 鍵はプラットフォームチーム、独立したセキュリティチーム、外部の KMS/HSM のどこが保持するのか。
• 鍵はどのようにローテーションされ、古いデータはどうなるのか。
• 誰がバックアップを復号でき、その操作は記録されるのか。
• エンドツーエンド暗号化を使う場合、ルーティングと不正利用対応のためにどのメタデータが可視のまま残るのか。

トレードオフは明示します。エンドツーエンド暗号化は、内容ベースの eDiscovery や自動の不正検知と衝突する場合があります。それはエンジニアリングの失敗ではなく、ポリシーの判断です。

アクセス制御と職務分離

• プラットフォーム運用者、サポート担当者、コンプライアンス調査担当者の間のロール分離。
• 内容アクセスに対する、承認と期限を伴うジャストインタイムアクセス。
• 監査イベントを生成するブレークグラス手順。
• 共有の管理者アカウントを禁止。

サポートエンジニアがメッセージデータベースを直接クエリできるなら、そのアクセスモデルは実質的に「データベースのパスワードを持つ全員」です。

調査と eDiscovery

最初の要求が来る前に、ワークフローを準備します。

• あるアカウントの会話を、デバイスやグループをまたいでどう特定するか。
• 会話を完全性の証跡（ハッシュ、タイムスタンプ、保管の連鎖）とともにエクスポートできるか。
• 現実的な量で、エクスポートにどれだけ時間がかかるか。
• 誰がエクスポートを承認し、その記録はどこに保管されるか。

コンプライアンス向けに作られたエクスポートツールは、場当たり的な SQL クエリとは異なり、監査人はその違いに気づきます。

バックアップ、リストア、削除の検証

• バックアップだけでなく、リストアをテストします。
• 目標復旧時間とデータ損失の許容範囲を文書化します。
• レプリカとバックアップをまたぐ削除を定期的に検証します。
• コピーが存在する場所の一覧を維持します。メッセージに隣接するデータを取り込む分析や監視のパイプラインも含めます。

ベンダーとコンポーネントのデューデリジェンス

プライベートデプロイであっても、データベース、オブジェクトストレージ、IM SDK 自体といったコンポーネントに依存します。次の点を確認します。

• どのコンポーネントがメッセージ内容を処理し、どこで動作するか。
• ネットワーク外に出るテレメトリがあるか、あるとすれば何か。
• セキュリティアドバイザリはどのように届けられ、現実的に達成できるパッチ適用の SLA は何か。
• サポートのアクセスモデルは何か、無効化できるか。

実現可能な最低限のコンプライアンス基準

プライベートデプロイの IM システムについて、説明可能な最低限の基準は次のとおりです。

1. 文書化されたデータインベントリと保持スケジュール。
2. アクセスを制限した追記専用の監査ログ。
3. 通信時と保存時の暗号化、および文書化された鍵の管理責任。
4. ロールベースのアクセス、ジャストインタイムの内容アクセス、ブレークグラスの記録。
5. テスト済みのエクスポートとリーガルホールドのワークフロー。
6. 検証済みのバックアップ、リストア、削除の挙動。
7. レビュー済みのベンダーおよびコンポーネントの依存関係。

これらはいずれも特定の製品に固有のものではありません。プライベートデプロイの IM システムであれば、当社の製品を含め、どの製品にも投げかけるべき問いです。Feiyan IM SDK はメッセージデータを自社環境に保持するよう設計されていますが、上記の統制を定義し、運用し、証跡を示す責任は利用者にあります。