顧客ファイルを安全に収集する：権限・検査・保管の管理

顧客ファイルを安全に収集するには、アップロードから利用承認までの流れを定める必要があります。提出・取得できる人を制限し、作業で開く前に受信内容を検査し、受け渡し後のコピーも把握します。アップロード成功は、ある段階で受信できたことを示すもので、すべての安全確認が済んだことを意味しません。

撮影素材、デザインデータ、文書を集める制作会社では、それぞれの判断をどこで行うかが重要です。顧客には明確な案内が必要です。受信チームには、不審な提出物や想定外の提出物を保留し、追跡可能な記録を残せる担当者が必要です。

リンクを共有する前にアクセス範囲を決める

案件に必要な素材だけを依頼します。承認済みの送信先と受け付けるパッケージの種類を示し、範囲外のものを相談できる既知の連絡先を案内します。特定の書き出しデータで足りるなら、個人や会社のフォルダー一式を要求しないようにします。

新規ファイルの提出、提出物の取得、リクエストの管理という3つの権限を分けて考えます。アップロードだけが必要な協力者に、チームの作業フォルダーや他の顧客の提出物へのアクセスまで与える必要はありません。担当者の権限は作業に合わせ、外部スタッフの離任や案件の終了時に見直します。これは OWASP の最小権限の原則を受信業務に適用したものです。

アカウント不要のリンクでもこの方式は取れますが、特定の送信者の本人確認にはなりません。共有パスワードはリンクの利用者を絞れても、転送される可能性があります。案件が求めるのはリンクの所持、メールアドレスを使えることの確認、それともより強い本人確認なのかを決めてください。それぞれ異なる要件です。見慣れたロゴも本人確認の証拠にはなりません。

設定はアカウント不要のアップロードリンクのガイドを参照してください。必要なアクセス制限を実施できないサービスで、ログイン画面をなくすために権限を広げるのではなく、承認された別の方法を選びます。

各制御が何を確認できるかで判断する

接続、内容、権限の確認を分けます。OWASP の TLS ガイドは、通信の保護とサーバー認証を説明しています。通常の HTTPS だけでは、ファイルを提出している人物を確認できません。

チェックサムは特に意味を広く捉えすぎないようにします。Microsoft のファイルハッシュの説明は、ファイル内容の比較を扱っています。チェックサムの一致は、カメラ素材が変わっていないことも、悪意のあるファイルが変わっていないことも確認できます。整合性の確認と内容の検査は別々に記録します。

作業に渡す前に受信内容を検査する

セキュリティ担当者と受信場所および検査手順を決めます。「隔離」というフォルダー名だけでは隔離になりません。アクセス権、処理ツール、自動的に続く操作によって境界が決まります。アップロード直後に同期、プレビュー生成、展開、編集ソフトへの読み込みが始まらないか確認します。

OWASP のファイルアップロードガイドは、多層の検証、制限された保存場所、適切なマルウェア検査やサンドボックスを推奨しています。また、送信側が指定するコンテンツタイプだけを信用しないことや、公開スキャンサービスへの提出による情報漏えいのリスクを挙げています。サービスが提供する制御と、受信チームで用意すべき制御を確認してください。

日常の判断には、次のように当てはめられます。

• **デザインデータに想定外の実行ファイルやスクリプトが混ざっている：**作業プロジェクトに入れず、既知の案件窓口を通じて必要性を確認します。動作を確かめるためだけに実行しないでください。
• **必須の検査ツールがアーカイブを読めない：**未検査として記録します。承認済みの処理方法や適切な代替物を求め、検査のスキップを合格扱いにしません。
• **認識できる形式で、スキャナーの警告がない：**作業に渡す前にほかの必要な確認も完了します。1つの結果で無害だと保証されるわけではありません。
• **依頼範囲外の情報が含まれる：**配布を保留し、収集すべき内容だったか担当者に確認します。確認のために余分な個人情報や機密情報を広めないようにします。

顧客の機密資料は承認された検査システム内で扱います。アップロードを受け付けるオンラインスキャナーも、そのファイルの別の受信者です。利用方法は顧客と組織の取り扱い要件に合う必要があります。

暗号化された提出物の検査を計画する

サービスが内容の復号鍵を持たなければ、その段階で平文の内容を検査できません。検査が必要な場合は、受信環境で権限に基づいて復号した後、プロジェクトへ渡す前に実施します。それに合わせて受信ツールと保存場所を選びます。

自動配信でも同じです。暗号化された提出物が指定端末に保存されたことは配信の1段階であり、復号後のファイルがチームのセキュリティ確認を通過した証拠ではありません。「受信済み」から「承認済み」に変更できる人を決めておきます。

セキュリティ承認と編集上の検収を分ける

例えば、顧客がカメラオリジナルと案件の文書を提出したとします。受信担当者は、まず想定した提出物かを確認し、承認済みの安全確認を実施します。その後で編集者が、素材を読み込めるか、文書が使えるか、依頼した一式が揃っているかを確認します。

提出物の識別番号、実施済みの確認、未解決の例外、承認担当者、保存先を記録します。「受信済み・検査待ち」という状態なら、別の担当者がアップロード完了を利用許可と取り違えにくくなります。

制作工程で必要なカメラオリジナルの名前やカードのフォルダー構造は維持します。提出単位を外側のフォルダーや識別番号で分け、個々のクリップの名前を変えることを安全対策にしないでください。撮影素材の受信フローでは、欠品確認、修正版、編集者への引き継ぎを説明しています。

アクセスを終了し、保管するコピーを把握する

収集開始前に、クラウド受信箱、受信端末、作業用ストレージ、バックアップ先を洗い出します。各区分の保管責任者と保管理由を決めます。日数を任意に決めるのではなく、組織で適用される保管規則と案件の合意に従います。

受付リンクを閉じること、サービス上の提出物を削除すること、端末上の作業コピーを削除することは別の操作です。サービスの動作を確認し、各保存先で何を行ったかを記録します。クラウドから削除しただけでは、担当者のダウンロードやバックアップまで消えたとはいえません。

案件終了時には、検収済みの原本を誰が保管するかを確認し、不要な権限を外し、残るコピーとその保管方針を記録します。ほかのチームがまだ使っている原本の唯一の検収済みコピーを削除しないようにします。

WarpSend File Requests に適用する

WarpSend File Requestsは、アップロードする人にアカウント作成やアプリのインストールを求めず、クラウド受信箱に提出物を集めます。所有者が取得するほか、任意で端末への配信を選べます。

エンドツーエンド暗号化はリクエスト作成時に選択し、WarpSignet が必要です。有効な場合、内容はアップロードする人のブラウザーで、権限を持つ受信者向けに暗号化されます。受付用パスワードだけでは、この暗号化は有効になりません。エンドツーエンド暗号化を使わないリクエストは、TLS とサービス管理の保存・アクセス制御を使います。ファイル名、パス、サイズ、配信状態などの運用メタデータはサービスから見えます。詳しくはセキュリティの説明を参照してください。

検査が必要なチームでは、管理された受信先を選び、必要な確認を終えてからファイルを作業に渡します。これは受信手順の要件であり、暗号化設定から推測できる機能ではありません。導入前にサービスの制御を比較する場合は、顧客向け大容量アップロードポータルの選び方を参照してください。

よくある質問

顧客がアカウントを作らなくても安全にアップロードできますか？

アカウント不要の受付でも、アクセス方式が案件の要件を満たせば利用できます。ただし、リンクや共有パスワードの所持だけでは特定の人物の本人確認にはなりません。必要な場合は、承認された本人確認方法を使います。

暗号化されていれば、受信ファイルを安全に開けますか？

いいえ。暗号化は定められた経路の内容を保護しますが、内容が悪意を持つかどうかは判定しません。権限を持つ受信者が復号できる場所で検査し、その後に作業プロジェクトへ渡す計画が必要です。

必須のスキャンツールで提出物を検査できない場合はどうしますか？

作業プロジェクトに入れず、未対応の形式や暗号化アーカイブなど、検査できない理由を記録します。セキュリティ担当者に承認済みの処理方法を確認するか、適切な代替物を依頼します。未検査は合格ではありません。

アップロードリクエストを閉じると、すべてのコピーが削除されますか？

そうとは限りません。受付の終了、サービス上の提出物の削除、ダウンロード済み・バックアップ済みコピーの削除は別の操作です。各保存先の動作を確認し、案件で承認された保管方針に従います。