Slackで機密ファイルを安全に共有する方法 — ワークスペースに平文を残さない
Slack公式のセキュリティページに記載のとおり、同プラットフォームは通信時・保管時にデータを暗号化しており、オプションとしてEnterprise Key Management（EKM）でAWS KMS上の自社鍵を使う構成も提供しています。ただし通常チャンネルには真のエンドツーエンド暗号化は提供されていません — ワークスペース管理者、同プラットフォーム自身のシステム、管理者権限を持つ者はサーバー側で平文を読めます。人事書類、APIキー、財務諸表、コンプライアンス規制下のファイルを生のまま投稿するのは、理論上のリスクではなく実際のポリシー違反になり得ます。本ガイドでは、同プラットフォームをワークフローハブとして使い続けつつ、ペイロードの暗号化を外で完結させ、ベンダー側に残るのが暗号文だけになる状態を作る方法を解説します。
手順
SecureMintのブラウザ上でファイルを暗号化する
/encrypt を開き、ファイルをドロップしてパスフレーズを設定します。AES-256-GCMはブラウザ内で完結し、平文はサーバーを一切経由しません。生成された .enc ファイルをローカルに保存してください。（受信者がSecureMintを使わずに開ける自己復号HTMLが必要な場合は /self-decrypt をご利用ください）
暗号化済みファイルをチャンネルまたはDMにアップロード
生成した .enc ファイルをチャンネルまたはDMにドラッグします。今後会話が漏洩したり、外部共有チャンネルに含まれたり、コンプライアンスエクスポートで抽出されても、暗号文しか出ません。
パスフレーズは別経路で共有する
パスフレーズを同じ会話に貼り付けてはいけません。それでは暗号化の意味がなくなります。別アプリ経由で送るSecureMint Memo（一度読むと消える）、電話、Signal、パスワードマネージャーの共有機能など、完全に別ルートで伝達してください。
受信者は自分のブラウザで復号する
受信者はチャンネルから .enc ファイルをダウンロードし、SecureMintの復号ページを開いてパスフレーズを入力すれば、平文がローカルで復元されます。ベンダーのサーバーもワークスペース管理者も中身を一切見られません。
保存期間を設定、または配送後に削除する
暗号文であっても無期限に残すべきではありません。管理パネルでチャンネル単位の保存期間を設定するか、受信確認後に .enc を削除して、将来パスフレーズが漏れた場合の被害範囲を狭めてください。
なぜ安全なのか
- 同プラットフォームの公式セキュリティドキュメントに記載のとおり、顧客データは通信時・保管時にサーバー側の鍵で暗号化されており、鍵はベンダーが保持しています。法的要請があれば技術的に復号可能です。
- Connect DMには2021年に限定的なエンドツーエンド暗号化が追加されましたが、通常のチャンネル、チャンネル内のファイルアップロード、外部共有チャンネルの添付には及びません。
- チャンネルアップロードで生成される公開ファイルリンクはワークスペース認証を迂回します。一度URLが漏れると、管理者が無効化するまで世界中から読める状態になります。
- 同プラットフォームの外でペイロードを暗号化しておけば、ワークスペース管理者・コンプライアンスエクスポート・シャドーIT連携・マーケットプレースの外部アプリのすべてに対し、暗号文しか見せずに済みます。
- SecureMintのゼロ知識ブラウザ暗号化により、平文はあなたのPCから外に出ません。SecureMint自身のサーバーにも、いかなるコラボレーションベンダーにも、一度も送信されません。
既存の対策では不十分な理由
多くのチームはアクセス制御、Connect DM、Enterprise Key Management の組み合わせがエンドツーエンド暗号化と同等だと考えがちですが、ベンダーのトラストセンター自身が明示しているのはサーバー側暗号化（オプションで顧客保持のKMS鍵）であり、エンドツーエンドとは別物かつ弱いモデルです。内部不正、コンプライアンスディスカバリ、管理者アカウント侵害を脅威モデルに含めると、以下のように既存対策は穴が残ります。
アクセス制御（プライベートチャンネル、DM、きめ細かい権限）は、ワークスペースUI上で誰がファイルを見られるかを制限するだけです。ワークスペースオーナーや組織オーナー権限を持つ管理者は中身を読めますし、コンプライアンスエクスポートはチャンネルの可視性に関係なくメッセージとファイルをフルダンプします。
Connect DMのエンドツーエンド暗号化は、2つの外部組織間のダイレクトメッセージかつ双方がオプトインしたケースに限定されます。ファイル共有の大半が行われる通常チャンネルのアップロードは対象外です。ベンダー公式ドキュメント自身がこの機能を限定的な利用シーンに制約しています。
Enterprise Key Management（ベンダーのEKMヘルプによればEnterprise Grid / Enterprise+ および GovSlackで提供）は、自組織がAWS KMS上で暗号鍵を保持する仕組みです。ベンダー側侵害に対しては有効で、鍵アクセスを失効させれば復号を止められます。ただしメッセージとファイルはインデックス化と表示のためにサーバー側で復号され続けるため、適切な権限を持つ管理者は依然として平文にアクセスできます。EKMはペイロード暗号化の代替ではなく補完です。
対策比較表: ネイティブ機能 vs ペイロード暗号化
| 対策 | 鍵保持者 | 管理者が平文を読めるか | チャンネルのファイルアップロードを保護 | コンプライアンスエクスポートに耐性 |
|---|---|---|---|---|
| 通常チャンネル（デフォルト） | ベンダー（サーバー側） | はい | 保管時暗号化のみ | いいえ（平文でエクスポート） |
| Connect DM（E2E） | 送信者と受信者の鍵 | いいえ（そのDM内に限る） | いいえ（DMのテキストのみ） | 一部 |
| Enterprise Key Management | 顧客のAWS KMS | はい | 顧客鍵で暗号化 | エクスポートは平文を含む |
| SecureMintペイロード暗号化（本ガイド） | 送信者とパスフレーズのみ | いいえ（暗号文のみ） | はい（任意のチャンネル・DM） | はい（エクスポートも暗号文） |
プラットフォーム内外に何が残るか
ペイロード暗号化を使うと、プラットフォームの責任は「機密情報を安全に扱う」から「不透明なブロブを運び受信者に通知する」だけに縮小します。プラットフォームから漏れ得るもの（訴訟対応のホールド、召喚状によるエクスポート、内部者の覗き見、侵害された管理者トークン、マーケットプレース経由の悪性アプリ）はすべて暗号文しか見ません。実際に平文アクセスが必要なもの（復号時点での送信者のPCと受信者のPC）は完全にプラットフォームの外にあります。
実務的には、コンプライアンス上のストーリーが変わります。「EKM + DLP + 監査ログでベンダーリスクを軽減している」ではなく「平文はそもそもベンダーに届いていない」と言えるようになります。ゼロトラスト審査で本当に求められるのは後者の短い一文です。
参考情報
よくある質問
同プラットフォームは既にメッセージを暗号化しているのでは？
組み込みのファイル権限で十分では？
Enterprise Key Management (EKM) を使っている場合は？
無料プランでも使えますか？
公開チャンネルではなくDMを使えば安全ですか？
暗号化するとプレビューや検索が効かなくなりませんか？
この手順を業務導入まで落とし込むなら
税理士・採用・士業のような実務フローにあてはめるときは、こちらの導入ガイドが近道です。