クライアント側暗号化とサーバー側暗号化（アップロード向け）の比較

アップロードされた文書で暗号化の選択が重要な理由

アプリでファイルをアップロードさせる場合、単なる「書類」を保存しているわけではありません。署名済みの契約書、パスポートや運転免許の写真、医療フォームや検査結果など、ユーザーのもう一つの身元情報を預かっていることが多いのです。ファイル自体は小さくても、それに伴うリスクは大きいです。

流出した契約書は法的・財務的な問題を引き起こします：価格が公開され、署名が悪用され、争いが深刻化することがあります。盗まれたIDのスキャン画像は身元詐欺やアカウントの乗っ取りにつながります。医療文書は、共有されるとは思っていなかったプライベートな健康情報をさらけ出す可能性があります。一度のミスで何年も信頼が損なわれることがあります。

チームはよく「暗号化された保存」と言いますが、その意味するところは様々です。時にはアップロード接続が暗号化されている（HTTPS）ことを指し、時にはディスク上でファイルが暗号化されている（保存時の暗号化）ことを意味し、また時にはファイルがユーザーの端末上で事前に暗号化されてサーバーは平文を見ない（クライアント側暗号化）ことを意味します。これらは同じではなく、異なる失敗に対して守る対象が違います。

セキュリティの選択は日々の使いやすさやサポート体験にも影響します。プライバシーを強化すると手間が増えることがあります：ファイル閲覧のための追加ステップ、共有の難化、検索やプレビューの制限、端末や鍵を失った際の復旧の困難さなどです。アクセスを簡単にするとインデックス化、アンチウイルススキャン、プレビュー、パスワードリセットが可能になりますが、その分サーバー（とそれを侵害した者）が見られる情報が増えます。

例えば、保険証や医療PDFをアップロードする小さな診療所を考えてみてください。スタッフは迅速に正しいファイルを見つける必要がありますが、管理者アカウントが侵害されたときの被害を小さくしたいとも考えています。どちらが「正しい」かは、どの失敗が最も痛手になるか、そしてユーザーがどの程度の不便を許容するかによります。

簡単な定義：クライアント側暗号化とサーバー側暗号化

実務的な疑問は単純です：ファイルはいつ暗号化され、誰が後で復号できるのか？

サーバー側暗号化は、ファイルがバックエンドに届く時点で読み取れる状態であり、保存前にサーバー側で暗号化することを意味します。これは保存時の暗号化です：もしドライブが盗まれたりストレージバケットに直接アクセスされたりしても、データはスクランブルされた状態になります。サーバーは必要に応じてファイルを復号できます。

クライアント側暗号化は、ファイルがユーザーの端末（ブラウザやモバイル）上でアップロード前に暗号化されることを意味します。サーバーは暗号化されたデータ（シフターテキスト）しか保存しません。通常の運用では、サーバーは復号鍵にアクセスできない限りドキュメントを読むことができません。

鍵の所有権が本質的な境界線です：

• サーバー側暗号化では鍵はバックエンド（多くは鍵管理サービス）で管理され、バックエンドが認可されたユーザーのためにファイルを復号します。
• クライアント側暗号化では鍵はユーザー、端末、またはクライアント側に保持された秘密で管理され、バックエンドは主に保存とアクセスルールの適用を担当します。

どちらのモデルでも、認証と権限管理は必要です。暗号化はアクセス制御の代わりにはなりません。

人々はまた「エンドツーエンド暗号化」という言葉を、送信者の端末で暗号化され、サーバー上では暗号化されたまま、許可された受取人の端末だけで復号されることを指して使うことがあります。それは機密性を高めますが、サーバー側でのプレビュー、全文検索、ウイルススキャン、容易な復旧を非常に難しくします（脅威モデルを変えるか、クライアント側に処理を移す必要があります）。

脅威モデル：実際に何を防ごうとしているのか

暗号化は、守りたいリスクが明確なときにのみ役立ちます。「意図したユーザー以外はファイルを読めないこと」を目指すのか、「保存領域が漏えいした場合の被害を減らすこと」を目指すのかで選択が変わります。

契約書、ID、医療文書を保存するアプリに共通する脅威には以下が含まれます：

• 盗まれたまたは再利用されたパスワード（アカウントの乗っ取り）
• 想定より広い内部アクセス（サポート、管理者、契約社員）
• クラウドアカウントの侵害や設定ミスのあるストレージバケット
• バグや漏洩によるデータベースやバックアップの露出
• ユーザー端末のマルウェア感染

露出がどこで起きうるかを分けて考えると役立ちます：

• 転送中（In transit）: 端末からサーバーへファイルが移動する間
• 保存時（At rest）: オブジェクトストレージ、データベース行、バックアップ、ログ
• 閲覧・処理時: プレビュー、OCR、検索、変換処理

核心はこうです。サーバー側暗号化ではシステムが復号できるため、プレビュー、スキャン、インデックス化が可能です。クライアント側暗号化ではサーバーはシフターテキストしか保存しないため、サーバー側の侵害や内部者がアクセスしても影響範囲を小さくできます。

暗号化が万能ではないことも覚えておいてください。端末が感染していれば、マルウェアは暗号化前または復号後のファイルを取得できます。誰かがドキュメントを閲覧できるなら、スクリーンショットを撮る、再共有する、印刷することは止められません。

各モデルが何から守り、何を守れないか

比較の役に立つ問いは：どの段階で誰が平文を見られるのか？ その答えが侵害時の影響範囲、内部者リスク、バックアップの安全性を決めます。

サーバー側暗号化ではサーバー侵害時に多くが露出する可能性があります。バックエンドは通常、プレビュー生成、ウイルスチェック、検索、共有処理のために復号鍵にアクセスできるか鍵を要求できるためです。最悪の場合、保存データと鍵の両方にアクセスできる攻撃者はすべてを復号できます。

クライアント側暗号化では、インフラが侵害されても暗号化されたバイナリが盗まれるだけで、ユーザーが保持する鍵がなければそれらはほとんど役に立ちません。

内部者アクセスでは差が顕著になります。サーバー側暗号化では、特権を持つ従業員やクラウド管理者、もしくは侵害されたサポートアカウントがアプリを偽装したりストレージに問い合わせたりしてドキュメントにアクセスできることが多いです。クライアント側暗号化では、インフラはファイルを保存・移動できますが、鍵が提供されない限り閲覧できません。

ただしクライアント側暗号化は端末侵害を解決しません。IDや医療PDFなど高リスクのアップロードでは、端末のセキュリティやアカウント保護も保存の暗号化と同じくらい重要です。

また「ファイルストア外」の漏洩にも注意してください。多くの事故は以下を通じて起きます：

• 復号済みファイルや鍵を含むバックアップやスナップショット
• ファイル名、メタデータ、抽出テキストを記録したログ
• サムネイル、プレビュー、検索インデックス
• メール、チャット、チケットツールへのエクスポート
• アップロードや変換中に作成される一時ファイル

ユーザーがすぐに気づくUX上のトレードオフ

最大の違いは数学的な話ではなく、ユーザーが何を簡単にできるか、何が難しくなるかです。

サーバー側暗号化はしばしば目に見えない形で動作します。ユーザーはログインしてアップロードし、すぐにプレビューできます。サポートは通常、アクセスをリセットできます。欠勤時に上司が権限を再割当てするのも比較的容易です。

クライアント側暗号化はオンボーディングや日常作業を変えます。ユーザーはより強いパスフレーズ、端末に保持されたローカル鍵、追加の解除ステップを必要とするかもしれません。端末切替やブラウザのクリア、アプリの再インストールでアクセスが壊れる可能性があるため、鍵のバックアップとリカバリーを計画しておく必要があります。

アカウント復旧はチームが驚くポイントです。もし復号鍵をユーザーだけが持っているなら、「パスワードを忘れた」は「アクセス喪失」になることがあります。復旧鍵やエスクローの仕組みを追加することはできますが、それが何を意味するかを正直に説明する必要があります。

共有も複雑になります。サーバー側暗号化では共有はほとんど権限の問題ですが、クライアント側暗号化では鍵の共有や取り消しに関する問題が発生し、古いコピーへの対処も必要になります。

検索や利便性機能はどこかで復号を強いることがあります。全文検索、プレビュー、OCRはサーバーがファイルを読める場合に最も簡単に実現できます。エンドツーエンド的なプライバシーを維持したいなら、クライアント側でのOCRやローカルインデックス、あるいはファイル名やタグのみの限定検索を採る必要があります。

例：診療所が検査PDFをアップロードして患者名をスキャン内でOCR検索したい場合、サーバー側暗号化は高速なOCRと検索をサポートします。クライアント側暗号化ではその処理を端末に押し付けることになり、Webとモバイルでのサポートが難しく遅くなりがちです。

文書別のニーズ：契約書、ID、医療記録

最良の選択はファイルの種類自体よりもワークフローに依存します：誰が読める必要があるか、どれくらい速く、どれくらい頻繁に、どのくらいの期間ですか。

契約書

契約書はレビュー、差し戻し、承認、監査トレイルを伴うことが多いです。チームは検索、共有、保持ルールも求めます。

製品内での共同レビューをサポートするなら、システムがプレビューをレンダリングし、検索を実行し、ロールベースのアクセスを強制できるため、サーバー側暗号化が実務上のデフォルトになることが多いです。

クライアント側暗号化は、最終的に署名されたPDFを少数の幹部グループ用に保管する「ボールト」的な用途に適します。ただしその場合、クライアント側のツールを追加しない限り利便性は下がります。

ID（パスポート、運転免許）

IDはリスクが高いものの、多くの場合短期間だけ必要とされます。多くのチームは本人確認が終わったら削除します。ワークフローは迅速な閲覧と厳格な取り扱いであって、共同作業ではありません。

よくある方法は、厳格なアクセス制御、強力な監査ログ、短期間の保持と組み合わせたサーバー側暗号化です。スタッフがIDをまったく見てはいけないならクライアント側暗号化が合う場合もありますが、その場合は別の確認方法を用意する必要があります。

医療文書

医療記録はより強いプライバシー期待があります。ユーザーは通常、最小限の人だけが閲覧できると想定します。

クライアント側暗号化はサーバー侵害や管理者の誤用時の露出を減らせますが、パスワードリセット、端末変更、緊急アクセスが現実的な運用上の問題になります。

選ぶ前に各文書タイプをワークフローに対してマッピングしてください：

• 誰が読まなければならないか（どこからか）
• どれくらい速く読み込む必要があるか
• どれくらいの期間保持するか
• どの製品機能が重要か（プレビュー、検索、自動削除など）

選び方：ステップバイステップの意思決定プロセス

まず何を保存し誰が触るかを書き出してください。「uploads」というフォルダ名だけでは方針になりません。

ステップ1："ユーザー"だけでなくアクセスをマップする

ロールを列挙し、次の2つに答えてください：誰がファイルを開ける必要があるか、誰が決して開けてはならないか（管理者含む）。ここで保持期間も決めてください。

ステップ2：防御対象の仮定を決める

何から守るのか率直に決めてください。

• 内部者リスクが最大の懸念なら、クライアント側暗号化が魅力的になります。
• 端末紛失やパスワードリセットが頻繁に起きるなら、復旧の複雑さが代償になります。

その後、体験を実地で検証してください：

1. 復旧とサポート： 誰かがパスワードを忘れたり端末を失った場合はどうしますか？ 純粋なクライアント側暗号化は適合しないかもしれません。

2. 必須機能： プレビュー、検索、OCR、電子署名、APIベースの処理が必要ですか？ これらの多くはサーバー側で復号できる方が簡単です。

3. 監査とコンプライアンス： 誰がいつ何を見たかの明確なログが必要ですか？ 両方のモデルでログは可能ですが、クライアント側の設計は「我々は助けられない」結果にならないよう注意が必要です。

多くのチームはハイブリッドに落ち着きます：ほとんどの文書はサーバー側暗号化にし、「スタッフに決して見られては困る」少数のアップロードにはクライアント側暗号化を使う、という形です。

避けるべき一般的なミスと罠

最大の罠は、暗号化を全体の解決策とみなすことです。プライバシーとコンプライアンスは、誰がデータにアクセスできるか、アクセスがどう承認されるか、何がログに残るか、どれだけ保持するか、削除要求をどう扱うかにも依存します。

次に多いのは、復旧計画なしでクライアント側暗号化を構築することです。ユーザーが端末を失ったりパスフレーズを忘れたり退職した場合、アクセスを回復できますか？ 「助けられない」は個人用ボールトなら受け入れられるかもしれませんが、業務アプリでは通常受け入れられません。

これらのミスは実際の情報漏洩や回避行為を生みます：

• 管理者に隠れた「すべてを見る」経路を与えたり、サポートがユーザーになりすますことを許して監査が不十分だったりする。
• ブラウザやアプリで復号し、そのコピーがキャッシュや一時ダウンロード、同期フォルダに残ること。
• 「安全な」ドキュメントを後で安全でない経路（メール、チャット、チケット）で送ってしまうこと。
• セキュアなフローが面倒すぎて、ユーザーが個人のドライブに移したり画面写真を撮ったりすること。
• 「保存時の暗号化」が同意、アクセス履歴、保持、漏洩報告要件を自動的に満たすと仮定すること。

例：診療所が受付フォームを暗号化しているが、スタッフが請求レポートをエクスポートしてローカルの暗号化されていないフォルダに保存すると、そのフォルダが共有ドライブにバックアップされる。漏洩は暗号技術ではなくワークフローで起きます。

最終決定前の簡単チェックリスト

誰がこれらのファイルを読めて、誰が決して読めないのかを一文で書いてください（サーバーが侵害されても含めて）。

次にチェックしてください：

• 誰がいつ復号できるか？ 正確なロールと条件を列挙します。方針に「アップローダーのみ」とあるなら、共有鍵をこっそり追加しないでください。
• アクセスを迅速に取り消せるか？ オフボーディングが実際に機能するか決めます（アカウント、端末、グループのいずれに紐づくか）。
• 端末紛失やパスワードリセット後はどうなるか？ 復旧が必要なら強力な承認で保護してください。
• プレビュー、ウイルススキャン、OCRが必要か？ 必要なら復号がどこで行われ誰がそれをトリガーできるか計画してください。
• 監査ログは十分に詳細か？ 「閲覧」と「ダウンロード」を区別し、ユーザー、日時、端末、理由を記録する基準を定義してください。

例：IDと医療PDFを保管する小さなチームの場合

小さな診療所がスタッフによる患者紹介PDFや保険証の写真をアップロードするアプリを持っているとします。目的はドキュメントを適切な人に素早く届けることと、端末紛失、アカウント侵害、クラウドの誤設定による被害を減らすことです。

1つの現実的なアプローチは、厳格なロール管理を伴うサーバー側暗号化です。ファイルは保存時に暗号化され、アクセスは権限で制御されます：受付はアップロード、請求担当はID閲覧、臨床担当は紹介状閲覧、という具合です。日常運用が楽で、デスクトップやモバイルで追加の手順なしに開ける利点がありますし、欠勤時に上司がアクセスを再割当てできます。

別のアプローチは最も敏感な項目に対してクライアント側暗号化を使う方法です。ファイルは端末で暗号化されてアップロードされるため、サーバーはシフターテキストしか保存しません。これによりサーバー侵害や内部者アクセス時の影響は小さくなりますが、運用が変わります：

• サーバー側暗号化ならパスワードリセットで通常のアクセス復元が可能ですが、クライアント側暗号化では鍵がバックアップされていない限り復旧不能になることがあります。
• スタッフの入れ替えはサーバー側暗号化の方が簡単です。クライアント側暗号化では鍵の移譲やエスクロー計画が必要になります。

ユーザーは共有、モバイルアクセス、端末紛失後の復旧で摩擦を感じます。これらの詳細は暗号化モデル自体と同じくらい重要です。

次のステップ：決定、方針の文書化、実装

まず脅威仮定を平易な言葉で書いてください。リスク要件を満たす最もシンプルなアプローチを選び、文書が本当に必要とする部分だけで強化してください。

決定を短い内部ルールに落とし込み、従うべき手順を作ってください：

• 許可されるファイル種別と保存先
• 誰がどのようにアクセス・共有を承認するか
• 保存期間と削除ルール
• パスワードリセットや端末紛失後の復旧方法
• エクスポート（ダウンロード、メール、メッセージ）の扱いとブロック条件

そのルールに基づいて実装を設計します：ロールチェック、監査ログ（閲覧・ダウンロード・共有）、安全なプレビュー、慎重な鍵管理などです。

もしAppMasterのようなノーコードプラットフォーム（appmaster.io）の上に構築するなら、早い段階でロールと承認フローをモデル化しておくと、要件が変わってもアプリ全体を書き直すことなく調整できます。重要なのは、実際のユーザーにとってセキュアな流れが簡単であることです。