セキュリティ資料の共有管理｜NDA・閲覧期限・アクセス失効を揃える方法

SaaSの商談や取引先審査では、SOC 2報告書、ペネトレーションテストの要約、ネットワーク構成、BCP資料、セキュリティチェックシートの根拠など、公開サイトには置けない資料を求められます。営業担当者がメール添付や期限のない共有リンクで渡すと、商談終了後も閲覧でき、担当者の退職や異動、転送、端末保存を追えない状態が残ります。

結論から言うと、セキュリティ資料は「誰に、何の目的で、どの資料を、いつまで」共有するかを承認し、記名された相手だけが認証して閲覧できる場所で渡します。資料区分に応じてNDA、閲覧のみ、ダウンロード制限、透かし、期限を組み合わせ、商談終了・担当変更・期限到来を権限失効のトリガーにします。

---

本記事のポイント

1. 公開資料、条件付き資料、個別承認資料を分け、共有前に相手、目的、範囲、期限を一つの台帳へ記録します。
2. 記名認証、閲覧のみ、ダウンロード制限、透かし、期限は層として組み合わせ、どれか一つを完全な流出防止策と考えません。
3. 期限到来、商談終了、担当変更、NDA終了、事故発生を失効条件にし、資料本体、リンク、外部アカウント、複製の残存を確認します。

---

資料区分と共有条件を先に決める

最初に行うのは、NDAを締結することではなく、資料を分類することです。同じ「セキュリティ資料」でも、公開して透明性を高める資料と、特定の取引先だけへ見せる資料、個別審査が必要な資料では、必要な制御が異なります。公開できる情報まで個別申請にすると営業が滞り、逆に機密資料を一律の共有リンクで渡すと必要以上の情報が残ります。

Cloud Security AllianceのSTAR Registryは、クラウドサービスが提供するセキュリティ・プライバシー統制を公開する仕組みです。CAIQはCloud Controls Matrixに沿って統制を説明する自己評価資料として使われます。まず公開されているSTAR、認証の概要、標準回答を案内し、それだけでは取引先の審査目的を満たせない場合に限って、機密度の高い証跡へ進むと過剰共有を減らせます。

資料区分	例	共有条件	原則の扱い
公開資料	認証取得の概要、公開CAIQ、公開ポリシー、サービス稼働情報	個別承認なし	最新版と公開URLを正本にする
条件付き資料	SOC 2報告書、監査報告書、BCP概要、ペネトレーションテスト要約	取引関係、利用目的、受領者、必要に応じてNDAを確認	記名認証、閲覧期限、原則閲覧のみ
個別承認資料	詳細な脆弱性、ネットワーク構成、復旧手順、未公表の事故資料	資料所有者とセキュリティ・法務の承認	必要部分だけを別版にし、短期限で共有
共有禁止	秘密鍵、パスワード、実顧客データ、悪用可能な手順、無加工の診断データ	通常の商談資料として共有しない	代替証跡や画面共有、第三者確認を検討

AICPAのSOC 2ガイドは、顧客やビジネスパートナーがサービス組織の統制の設計・運用・有効性を評価するためにSOC 2報告書を求めると説明しています。SOC 2報告書は、サービスや統制を十分に理解する利用者を想定したrestricted-useの報告書になり得ます。ただし「SOC 2だから必ずNDA」という単純な規則ではありません。報告書の利用制限、契約、監査法人や自社法務の条件を確認し、自社がNDAを共有条件にするなら、締結主体、対象資料、目的、存続期間を台帳に結びます。

SOC 2・ISO 27001・ISMAPなどの違いを先に整理したい場合はSaaSセキュリティ認証・審査の種類、チェックシート回答と根拠の版管理は取引先セキュリティチェックシートの回答管理を参照してください。本記事では、作成済みの保証資料を外部へ渡す段階に焦点を絞ります。

NDA・閲覧期限・ダウンロード可否を一つの判断表にする

NDAは法的な利用制限を合意する手段であり、アクセス制御の代わりではありません。NDA締結済みでも、受領者を識別できないURL、期限のないリンク、編集権限、組織外への再共有を許せば、技術的には広く複製できます。逆に、強いアクセス制御をかけても、資料の利用目的や受領者の社内共有範囲が合意されていなければ、適切な利用か判断できません。

判断項目	低い機密度	高い機密度	記録すること
受領者	相手企業の指定担当者	担当者を個人単位で限定し、追加は再承認	氏名、所属、メール、役割
NDA	既存契約の秘密保持条項で足りるか確認	対象資料・目的・再開示先・存続期間を確認	契約ID、締結主体、有効期間
権限	閲覧のみを既定	記名認証、閲覧のみ、再共有不可	共有方式、付与権限、承認者
ダウンロード	業務上必要なら許可	ブラウザ閲覧を優先し、必要時だけ個別許可	許可理由、対象版、解除日時
期限	審査予定と商談期間に合わせる	短い期限と定期再承認を使う	開始、終了、見直し日
識別表示	版番号と機密区分	受領者や共有IDにひもづく透かし	生成版、受領者、発行時刻

Microsoftの公式資料では、Specific peopleリンクは組織外の相手をゲストとして認証し、ファイルやフォルダーの活動を監査できます。一方、Anyoneリンクは認証なしで転送され得るため、期限を設定しても、期限前の転送やダウンロード済みコピーまでは回収できません。機密資料では、受領者を識別できるリンクを既定にし、匿名リンクは使わない方針にします。

SharePointやOneDriveのblock download policyは、対象サイトの利用者をブラウザ閲覧に限定し、ダウンロード、印刷、同期、デスクトップアプリからのアクセスを止めます。ただし、業務アプリへの影響があるため、Microsoftも対象利用者で事前テストするよう案内しています。スクリーンショットや撮影まで完全に防ぐ制御ではないため、透かしと契約上の利用制限、最小限の資料内容を組み合わせます。

Google Workspaceで共有ドライブを使う場合の外部共有境界は共有ドライブの外部共有をどこまで許可するかで整理しています。製品が違っても、匿名リンクを避け、記名された受領者へ閲覧権限だけを付け、期限と失効責任者を決める原則は共通です。

申請から失効までを7段階で運用する

共有申請フォームは、資料名だけでなく相手、目的、審査期限、必要な範囲を入力させます。「取引先から言われたから」では承認条件になりません。どの統制を確認したいのか、公開資料や要約版で代替できないかを聞き、必要最小限の資料へ絞ります。

1. 依頼を受け付ける：相手企業、受領者、利用目的、必要資料、審査期限、商談・契約IDを記録します。
2. 代替資料を確認する：公開認証、STAR、標準回答、要約版で目的を満たせるなら、機密資料を追加共有しません。
3. 資料区分と契約を照合する：NDAや契約の締結主体、秘密情報の範囲、再開示、利用目的、存続期間を確認します。
4. 資料所有者が承認する：最新版、対象範囲、マスキング、受領者、ダウンロード可否、期限を確定します。
5. 記名アクセスを発行する：共有ポータルや管理された文書基盤で相手を認証し、閲覧のみと期限を設定します。
6. 利用と期限を監視する：招待、閲覧、ダウンロード、再共有、権限変更、期限延長を台帳と監査ログへ結びます。
7. 終了時に失効・確認する：リンクとゲスト権限を止め、複製の削除要否、例外、履歴保持、再共有の有無を確認します。

安全な共有は、NDAを結んだ時ではなく、必要な相手だけが必要な期間だけ閲覧でき、終了時に権限と複製を回収できる状態で成立します。

NIST SP 800-53 Rev. 5.1のアクセス制御群は、アカウント管理、アクセスの実施、最小権限、セッション終了などを分けて扱います。監査・説明責任群では、記録すべきイベントを選び、事後調査に十分か理由を持ち、記録をレビューすることが求められます。これを共有運用へ置き換えると、付与だけでなく、誰が共有を承認し、誰が閲覧し、いつ権限を変え、いつ失効したかを追える必要があります。

失効トリガー	実行する操作	確認する残存
閲覧期限の到来	リンク停止、ゲスト権限削除、延長申請の分離	別リンク、個別例外、ローカル複製
商談・審査の終了	案件IDにひもづく全共有を一括確認	CRMメモ、メール添付、データルーム
受領者の異動・退職	個人権限を削除し、後任は新規申請	共有グループ、転送先、代理アクセス
NDA・契約の終了	契約条件に従いアクセス停止と削除依頼	存続条項、法令・監査上の保持例外
誤共有・事故	即時停止、影響範囲固定、ログ保全、責任者連絡	閲覧者、ダウンロード、再共有、二次保存
資料の改訂・失効	旧版を無効化し、必要な相手だけ新版へ切替	旧版URL、添付、透かし付き派生版

期限延長は自動更新にせず、当初目的が続いているか再承認します。複数案件で同じ相手へ共有していても、案件ごとに必要な資料と期限は異なります。企業ドメイン単位の恒久アクセスではなく、受領者・目的・案件・版・期限の組み合わせを正本にします。

透かし・閲覧ログ・共有履歴を証跡として残す

透かしは、受領者名、企業名、共有ID、発行日時などを表示し、資料の出所を識別しやすくする抑止策です。透かしがあっても内容の転載を技術的に止めるわけではありません。全員に同じ透かしを入れるより、受領者または共有IDへひもづけ、発行した派生版を台帳に記録した方が追跡に使えます。

監査ログでは、共有リンクの作成だけでなく、外部ユーザーの追加、権限変更、リンク利用、ファイル閲覧、ダウンロード、再共有、削除、失効を確認します。Microsoft Purviewの共有監査資料では、secure linkへの外部ユーザー追加や、そのリンクを使ったファイルアクセスが監査イベントとして記録されます。ログを取得できることと、必要な期間保持・検索できることは別なので、製品プラン、保持期間、時刻、ユーザー識別子、エクスポート方法を確認します。

台帳項目	目的	完了条件
資料ID・版・checksum	何を渡したかを固定する	最新版と共有版の内容を照合できる
相手企業・受領者・案件ID	誰のどの審査かを識別する	共有先不明のリンクがない
目的・根拠・承認者	必要性と責任を説明する	口頭依頼だけの共有がない
NDA・契約ID	利用制限と期間を結ぶ	締結主体と対象資料を確認済み
権限・期限・例外	実際のアクセス条件を追う	現在権限と台帳が一致する
招待・閲覧・取得・再共有	事後調査と利用状況確認	製品ログの時刻と利用者を追える
失効日時・実行者・結果	終了処理を証明する	リンク、権限、例外の残存を確認済み

Google Driveの外部共有を調べる具体的なログ項目はGoogle Drive監査ログの見方、退職・異動で共有リンクが残る問題は共有リンク運用の落とし穴も役立ちます。セキュリティ資料だけ別運用にせず、組織全体のゲスト・共有・監査の基盤に乗せると、担当者が変わっても失効を追跡できます。

よくある質問

どのセキュリティ資料をNDA締結後だけ共有しますか？

SOC 2報告書、監査報告書、ペネトレーションテスト要約、非公開の構成・復旧資料など、公開情報より詳細で悪用や誤解の影響がある資料を候補にします。ただしNDA要否は報告書の利用制限と自社契約方針で決め、公開認証やSTAR、要約版で足りる場合は機密資料を共有しません。

閲覧期限とダウンロード可否をどう決めますか？

審査予定、商談期間、契約締結予定のうち最も短い実務期間に合わせ、延長は再承認します。ダウンロードは受領者側の正式な保管や監査に必要な場合だけ許可し、通常は記名認証とブラウザ閲覧を既定にします。許可する場合は対象版、理由、保管・削除条件を記録します。

共有先の担当者変更や商談終了時にアクセスをどう失効しますか？

CRMや契約管理の担当変更・商談終了を失効タスクへつなぎ、リンク停止、ゲスト権限削除、共有グループ確認、例外解除を行います。後任者へ権限を移すのではなく、新しい受領者として目的と期限を再承認します。

透かし・閲覧ログ・共有履歴をどこまで残しますか？

少なくとも資料ID・版、受領者、案件、承認、権限、期限、招待、閲覧・取得、再共有、失効結果を追える状態にします。保持期間は契約、監査、事故調査、個人情報の最小化を踏まえて決め、無期限に本文や個人情報を複製しません。

NDAを締結すればメール添付で送っても安全ですか？

NDAは技術的な回収機能ではありません。添付は送信後の期限設定や権限失効が難しく、転送・複製も追いにくいため、管理された共有基盤を使います。やむを得ない場合は暗号化、別経路での鍵共有、受領確認、削除期限を定めます。

ダウンロード禁止にすれば情報流出を防げますか？

完全には防げません。ブラウザ閲覧でも画面撮影や手作業の転記は残ります。ダウンロード制限は一つの層として使い、資料内容の最小化、記名認証、期限、透かし、契約上の利用制限、ログ確認を組み合わせます。

---

関連ページと関連記事

• 取引先セキュリティチェックシートの回答管理
• SaaSセキュリティ認証・審査の種類
• Google Workspaceで共有ドライブの外部共有を許可する範囲
• Google Drive監査ログの見方
• 共有リンク運用の落とし穴

セキュリティ資料の共有台帳と失効手順を整えたい場合

営業、法務、セキュリティが別々にNDA、資料、共有リンクを管理していると、誰が現在も閲覧できるかを説明できません。資料区分、申請項目、承認、記名アクセス、期限、失効条件、監査ログを一つの運用へそろえると、取引先の審査速度を落とさず、不要な外部アクセスを残しにくくなります。

セキュリティ資料共有の運用設計について相談する