DRMのかかった文書がサーバで開かない理由
一言でいうと
DRMがかかった文書は、拡張子だけが普通で、実際には暗号文なので、エージェントのないサーバーでは決して開かれません。これはバグではなく、設計です。
現場の最初の場面
運用中の決裁システムに、問い合わせが入ります。
「添付ファイルが開きません。『ファイル形式またはファイル拡張子が正しくありません』と表示されます。」
開発者がサーバーに入ってファイルを確認します。サイズも正常で、拡張子も.xlsxです。ローカルにダウンロードして開いてみると、開きます。ところがユーザーは、開かないと言います。逆の状況もあります。サーバーでバッチがそのExcelをパースしようとして、失敗し続けます。
この時点で知っておくべきこと。そのファイルは暗号化されています。DRMのためです。
DRMは何をするのか
韓国の企業の文書セキュリティ(DRM、Digital Rights Management)の動作は、おおむね次のとおりです。
- PCにDRMエージェントがインストールされています。
- ユーザーが文書を保存すると、エージェントが自動的に暗号化します。拡張子はそのままです。見た目は普通の
.xlsxです。 - ユーザーが文書を開くと、エージェントがポリシーサーバーに権限を問い合わせ、許可されればメモリ上で復号してOfficeプログラムに渡します。
- 権限は、人・部署・期間・操作(閲覧/編集/印刷/画面キャプチャ)の単位でかけられます。
つまり、ファイル自体が暗号化された状態で出回り、復号はエージェントが行います。この構造が事故を生む箇所が、複数あります。
なぜサーバーでは開かないのか
サーバーにはDRMエージェントがありません。そのため、サーバーから見ると、そのファイルは拡張子だけがxlsxの、正体不明のバイナリです。
- Javaライブラリ(POIなど)でパースすると、
Invalid header signatureのようなエラー fileコマンドではdataと出ます(正常なxlsxならMicrosoft ExcelまたはZip archive)- プレビュー/サムネイルの生成に失敗
- 全文検索のインデックス化に失敗(内容を読めないため)
診断の一行があります。
file 첨부파일.xlsx
head -c 4 첨부파일.xlsx | xxd
(コードブロックの韓国語は、添付ファイルの名前を表すプレースホルダーです。)
正常な.xlsxはZIPなので、50 4B 03 04(PK..)で始まります。DRMで暗号化されたファイルは、ベンダー固有のヘッダーで始まるか、ランダムなバイト列です。この2行で、「ファイルが壊れている」と「DRMがかかっている」を区別でき、それだけで問題の半分が解決します。残りの半分は、こちらでは解けません。ベンダーの領域です。
ではSIプロジェクトで何をすべきか
DRMは、こちらで作ることも、直すこともできません。こちらにできるのは、設計と協議です。
1. サーバーが文書の内容を読む必要がある要件はあるか
- 添付ファイルの全文検索
- サーバーサイドのプレビュー(PDF変換)
- Excelアップロード → データの一括登録
- 文書の内容に基づく決裁の自動分類
このような要件があれば、分析段階で必ずDRM担当部署と協議する必要があります。設計が終わったあとに発見すると、要件そのものを取り下げるか、別途予算が必要になります。
2. 協議の結果は、たいてい次の3つのうちのどれかです
| 方式 | 説明 | 注意点 |
|---|---|---|
| サーバー用の復号モジュール(SDK) | ベンダーが提供するサーバーライブラリで復号します | 別途ライセンス・費用が必要です。サーバーの登録が必要です |
| 例外ポリシー | 特定のアップロード経路/アカウントは、平文での保存を許可します | セキュリティチームの承認が必須です。範囲を最小化します |
| アップロード時にユーザーのPCで復号 | エージェントがあるPCから、平文でアップロードします | Webアップロードは、たいてい自動では復号されません |
3つ目が、特に落とし穴です。「ユーザーPCにエージェントがあるから、自動で復号されてアップロードされるだろう」は、ほとんどの場合、間違っています。Officeプログラムが開くときには復号されますが、ブラウザーがファイルを読んでアップロードするときは、ポリシーによって暗号文のままアップロードされます。そのため、検証環境で、必ず実際にDRMが適用されたPCでアップロードテストを行う必要があります。開発者のPCはたいてい例外に入っているので、テストが通ります。そして、サービスイン後に問題が起きます。
3. 持ち出し(復号)の手続きを要件に含めます
DRMがかかった文書を外部(協力会社、顧客)に送る業務があるなら、持ち出しの決裁手続きが必要です。大企業では、月に数千件も起きることです。こちらのシステムがその流れの一部なら(例: 協力会社ポータルへのファイル掲載)、決裁連携や持ち出しAPI連携が要件に入る必要があります。
関連する概念の整理
DRMとよく混ざって使われる用語を区別しておけば、会議で迷いません。
| 用語 | 何をするか | 統制のポイント |
|---|---|---|
| DRM | 文書自体を暗号化し、閲覧権限を統制します | ファイル |
| DLP | 情報流出の経路(メール・USB・Web)を監視・遮断します | 経路 |
| 文書集中化 | 文書をPCではなく、中央サーバーにだけ保存します | 保存場所 |
| VDI / ネットワーク分離 | 作業環境そのものを分離します | 環境 |
| ウォーターマーク | 出力・画面に識別情報を表示します(流出時に追跡) | 事後追跡 |
この5つが同時にかかっている現場がよくあります。そのため、「ファイルがアップロードできない」という症状1つに、原因の候補が5つあります。問題を絞り込む順序は、次のとおりです。
- 同じファイルがローカルでは開けるか → 開けるなら、ファイルは正常で、環境の問題
- ファイルのシグネチャは正常か → そうでなければ、DRMによる暗号化
- 別の経路(メール/USB)でもブロックされるか → ブロックされるなら、DLP
- 特定のユーザーだけがそうなるか → そうなら、権限/ポリシー
- 特定のネットワークだけがそうなるか → そうなら、ネットワーク分離/ファイアウォール
最後に: ログに残すもの
DRM関連の障害は再現が難しいです。ユーザーPCの環境に左右されるからです。そのため、アップロードの処理ポイントで次のことをログに残せば、分析時間が大幅に減ります。
- ファイル名、サイズ、先頭8バイトの16進数
- アップローダーのアカウント、部署、接続IP、ブラウザー
- パースを試した結果と、例外メッセージの全文
先頭バイトのログが1つあるだけで、「DRMかどうか」を事後に判定できます。これを残さないと、毎回ユーザーにファイルを再提出してもらうことになります。