Doconut Viewer は、契約書、請求書、設計図、顧客記録などを表示した瞬間に、アプリケーションのセキュリティ境界の一部となります。Doconut が閲覧レイヤーを提供しますが、周辺のアプリケーションは、誰がファイルを開くことができるか、ソースがどこに保存されているか、派生データがどのくらいの期間利用可能か、そして調査のために何が記録されるかを決定し続けなければなりません。

Doconut の安全なドキュメント閲覧のベストプラクティス記事では、サーバー側レンダリングをディフェンス・イン・デプス設計の一層として説明しています。本稿では Doconut に関するアプリケーション側の責務に焦点を当て、実装の詳細は製品の公式ドキュメントに委ねます。

脅威モデルから始める

「プライベート」や「セキュア」は設定項目ではありません。コントロールを選択する前に、防止または検知すべきイベントを定義しましょう。

リスク	例	アプリケーション側の対策
不正アクセス	ユーザーが URL のドキュメント識別子を変更する	すべてのリクエストに対するオブジェクトレベル認可
テナント横断	有効なユーザーが別顧客のファイルを要求する	認可判断にテナントスコープを組み込む
ソース露出	ストレージパスや元ファイルが直接返される	サーバー側でのルックアップとレンダリングフロー
期限切れアクセス	ロールやケースが変更された後もリンクが有効	短いセッション有効期間と認可の再検証
過剰保持	一時的な入力や出力が蓄積される	明示的なライフサイクルジョブと可観測な結果
機密ログ	トークンやファイル位置がログに残る	構造化されたマスクと識別子のみのテレメトリ

システム内の文書とユーザーに応じてリスクの優先順位を付けます。公共のパンフレットライブラリと法的証拠ポータルが同じビューアを使用しているからといって、同一ポリシーを適用すべきではありません。

Doconut の法務文書レビュー事例は、認証済みケース、契約、証拠、コンプライアンスワークフローにおける製品の役割を示す有用なリファレンスです。権限、ストレージ、顧客記録、ビジネスルールはすべてホストアプリケーション側に近い場所で管理されるべきであることを再確認できます。

ドキュメントを開く前に認可する

Doconut でドキュメントを開く前に、認証とオブジェクトレベル認可を実施してください。公式の .NET 6 以降のセットアップガイドではビューアの設定方法とサーバー側ドキュメントの開き方が示されていますが、製品側の手順に入る前に、アプリケーションの ID、テナント、ドキュメント権限チェックを行う必要があります。

アプリケーションが提供するすべての関連操作（ページ表示、サムネイル、検索、注釈、変換、ダウンロード、印刷）に対して同一の認可ルールを適用してください。ボタンを非表示にしただけでは、基礎となるリクエストは保護されません。

ブラウザーから直接ファイルシステムパス、ストレージキー、リモート URL を受け取らないようにします。アプリケーション所有のドキュメント ID をサーバー側でストレージ位置に解決し、解決されたオブジェクトが認可されたテナントとワークフローに属していることを確認してください。

ビューアとストレージポリシーを分離する

ビューアが保持期間を決定すべきではありません。各ストレージクラスと所有者を明確に文書化しましょう。

ソースドキュメント — 主たるコンテンツまたは記録ポリシーで管理。
一時作業ファイル — 処理用に作成され、スケジュールされた可観測ライフサイクルで削除。
レンダリングページまたはキャッシュ — 最小限の有用期間に限定し、ソースと同様に保護。
エクスポート・印刷用ファイル — ユーザーが該当権限を持つ場合にのみ作成。
ログ・監査イベント — 識別子と結果のみを含み、ドキュメント内容や認証情報は含まない。

転送中および保存時の暗号化は、Web サーバー、ストレージプロバイダー、鍵管理、デプロイ設定に依存します。実際の環境でこれらのコントロールを検証し、ビューアライブラリの有無だけで判断しないでください。

短命参照は慎重に使用する

短命参照はリプレイ攻撃の時間窓を縮小しますが、認可の代替にはなりません。署名付きルートやセッショントークンを利用する設計の場合は、次の手順を守ります。

1つのドキュメントと対象操作に紐付ける。
ワークフローに基づく狭い有効期間を設定する。
敏感なクレームやストレージ位置を平文で含めない。
特権操作の際は認可を再検証する。
自然な有効期限前に取り消しが何を意味するか定義する。
トークンを分析ツール、リファラ、例外メッセージ、スクリーンショットに漏らさない。

ブラウザーセッションが期限切れになったら中立的なメッセージを表示し、再認証への安全な手段を提供してください。他テナントがドキュメントを所有しているかどうかは露出させないようにします。

クライアント側コントロールの限界を理解する

ダウンロードや印刷ボタンを削除しても、機密性が保証されるわけではありません。コンテンツを閲覧できるユーザーは、画面キャプチャ、写真撮影、ビューア外のブラウザー機能を利用できる可能性があります。

クライアント側の制限は「使い勝手」や「抑止」目的として扱い、実際の保護はサーバー側でソースファイルを保持し、すべての関連リクエストに認可を適用し、エクスポートを制限し、ポリシーで求められる場合は可視的な透かしを付与することで実現します。

製品機能をコンプライアンス主張に変換しない

規制遵守は目的、データカテゴリ、法的根拠、契約、地域別処理、保持、インシデント対応、組織手順に依存します。ビューアはコンプライアンス設計を支援できますが、単体でアプリケーションを遵守させるものではありません。

GDPR 評価の際は少なくとも以下を文書化してください。

ソースおよび派生ファイルの処理・保存場所
各サービスの管理者（コントローラ）と処理者（プロセッサ）
関与するサブプロセッサとデータ転送先
削除要求がすべてのストレージクラスとバックアップポリシーに届く方法
ログに記録されるイベントと保持期間
アクセスレビューとインシデント対応の実施方法

プライバシー・法務担当者にこれらの決定を検証してもらいましょう。

セキュリティヘッダーとキャッシュルールを追加する

認証済みプレビュー用ルートでは、制限的な Content Security Policy、フレームポリシー、MIME スニッフィング防止、リファラーポリシーを検討してください。プレビューが iframe 内に表示される場合は、許可する親オリジンを明示します。

感度とレンダリングルートに応じてキャッシュヘッダーを選択します。no-store は一部のレスポンスに適切ですが、パフォーマンスに影響し、既に取得されたコンテンツを消去するわけではありません。ヘッダー単体に依存せず、ブラウザー・プロキシ・CDN の挙動をテストしてください。

秘密情報ではなく決定事項を記録する

有用な監査イベント例：

ユーザーおよびテナント識別子
ドキュメント識別子
要求された操作
認可結果
タイムスタンプと相関 ID
保持またはクリーンアップ結果

トークン、クエリ文字列、ストレージ URL、個人情報を含むファイル名、抽出テキストなどはログに残さないでください。監査ログは改ざんから保護し、必要なチームだけがアクセスできるよう制限します。

完全なフローを検証する

セキュリティテストにはネガティブケースも含めます。

認証状態を維持したままドキュメント ID を変更する。
別ユーザーまたは別テナントのプレビュー URL を再利用する。
ページ、サムネイル、印刷、エクスポートエンドポイントに直接アクセスする。
長時間プレビュー中にセッションが期限切れになる。
ドキュメントが開かれたままユーザー権限を取り消す。
未対応・過大・破損・パスワード保護された入力を送信する。
クリーンアップジョブが対象データを削除し、失敗を報告することを確認する。
ログ、分析、エラーページに機密値が残っていないか検査する。

安定ケースは自動化し、ストレージ構成、ブラウザポリシー、ビューアバージョン変更に関しては手動レビューを残します。

結論

セキュリティ志向の統合は所有権が明確であることが鍵です。Doconut は公式ドキュメントで説明されている通りドキュメント閲覧機能を提供しますが、認証・認可・ストレージ制御・保持・モニタリング・インシデント対応はすべてアプリケーション側の責務です。これらの責務を明示的に分担することで、より強固なコントロールと正直なプライバシー主張が実現します。