2026-06-27
顧客のドライブにデータを置く：最小データ保持という設計思想
業務SaaSの情報漏洩リスクをどう下げるか。データの実体を顧客側に置き、サーバ保持を最小化する設計の考え方を解説します。
ためこむほどリスクは増える
サービス提供者のサーバに顧客データをためこむほど、攻撃を受けた際の被害は大きくなります。逆に、サーバに残すデータを減らせば、万一のときの影響範囲を構造的に小さくできます。守るべき対象が少ないほど、守り方も単純にでき、点検の抜けも起きにくくなります。設計の最初に『本当にサーバに残す必要があるか』を問うのが出発点です。
実体は顧客のドライブに
日報の最終的な保存先を顧客自身のGoogleドライブ内のスプレッドシートにすると、データの管理主体が顧客側に戻ります。提供者は中継するだけで、長期保管はしません。顧客は自社のアクセス権の設定でだれが見られるかを自分で決められ、契約を終える場合でもデータの実体は手元に残ります。データを人質にしない設計は、導入時の安心にもつながります。
サーバ保持は時間を区切る
送信から承認までの一時データだけをサーバで預かり、承認時に消去、未承認でも最大24時間で自動消去します。『最大24時間しか残らない』と明示できると、導入側の審査も通りやすくなります。ここで大切なのは、消去が人の操作に頼らず自動で動くことと、保持の上限が言葉として説明できることです。曖昧な『できるだけ早く消す』では、審査する側は判断できません。
消去だけでは不十分
最小保持は強力ですが、それだけで安全になるわけではありません。通信の暗号化、書き込み権限の分離、操作の記録といった基本を合わせて初めて、安心して使える状態になります。たとえば、預かっている間に第三者に読まれない、書き込み先を必要な範囲に限る、あとから何が起きたか追える、の三点を一組で考えると抜けが減ります。
導入前に確かめたい問いの例
導入を検討する側は、次の問いを提供者に投げてみるのが目安です。『データの実体はどこにありますか』『サーバに残る期間の上限はいつまでですか』『消去は自動ですか、手動ですか』『権限を外したい場合、どの手順になりますか』。答えが具体的で、仕組みとして説明できるほど、設計が整理されていると判断しやすくなります。反対に、答えが運用担当者の注意深さに依存しているなら、そこが弱点になりやすい箇所です。最後に、設計の説明が書面で残っているかも確認しておくと、社内の稟議や見直しの際に役立ちます。