M365、iManage、Salesforce、MFTを横断した安全なエンタープライズファイル共有のための統合アーキテクチャ：データフロー、DLP、暗号化

エンタープライズのファイル共有は単独で完結するものではありません。組織がセキュアなファイル共有プラットフォームをMicrosoft 365やドキュメント管理システム、CRM、マネージドファイル転送チャネルに接続した瞬間、セキュリティの課題は変化します。もはやコアプラットフォームがどのような制御を適用しているかだけではなく、データが統合の境界を越えて移動する際にも、その制御が一貫して適用されるかどうかが問われます。

これがインテグレーションアーキテクチャの課題です。そして多くの場合、調達プロセスではこの課題が過小評価されがちです。ベンダーの機能一覧には、サポートされている統合が名前で列挙されますが、実際に同じDLPポリシー、同じアクセス制御、同じ監査イベント、同じ暗号化ポスチャーが、サードパーティコネクタ経由で入出力されるデータにもネイティブ機能と同様に適用されるかどうかは、明確かつ公開・検証可能な形で答えられることはほとんどありません。

本記事は、エンタープライズファイル共有プラットフォームを評価するインテグレーションアーキテクトやセキュリティアーキテクト向けです。Microsoft 365、iManage、Salesforce、SFTP/MFTといった統合パターンごとにデータフローを整理し、それぞれに必須となるセキュリティ制御を明確化します。また、現時点でドキュメントだけでは解決できず、Kiteworksへの直接確認が必要となる唯一の問い――サードパーティコネクタ経由で転送されるデータの顧客側暗号鍵の所有権――についても取り上げます。

エグゼクティブサマリー

主旨：インテグレーションセキュリティは、単にプラットフォームが特定のコネクタをサポートしているかどうかではなく、どのコネクタが操作をトリガーしてもプラットフォームのポリシーエンジンがデータを統制できているかどうかが本質です。DLP分類、アクセス制御の強制、監査ログ、暗号化ポスチャーは、SharePointコネクタ経由、iManage同期、Salesforce添付、SFTP転送のいずれでも同等に一貫して適用されなければなりません。統合の境界でギャップが生じると、データ主権は実質的に破綻します。

なぜ重要か：NIS2、DORA、ISO 27001はいずれも、サードパーティ統合を含むデータ取扱い全体にセキュリティ制御が及ぶことを要求しています。ベンダーがパターンごとのデータフローブリーフを提示できない、またはその中でコネクタ経由の暗号鍵所有権について触れていない場合、それは最終的に監査人に指摘される証拠上のギャップとなります。

5つの重要ポイント

1. ポリシーの強制は、コアプラットフォームだけでなく、すべての統合チャネルを横断してデータに追従しなければならない。データがM365コネクタやSFTPチャネルを通過する際にDLPルールやセンシティビティラベル、アクセス制御ポリシーが一貫して適用されない場合、重大なセキュリティギャップが生じます――そしてそのギャップは、最悪のタイミングでコンプライアンス違反として顕在化しがちです。
2. 各統合パターンには独自のデータフローアーキテクチャとリスクが存在する。SharePointコネクタ、iManage同期、Salesforce添付ハンドラ、マネージドファイル転送パイプラインは、それぞれ異なる形でデータを扱います。実際のデータ経路――データがどこに着地し、何によって変換され、どのシステムが保存するか――を理解することが、その統合のセキュリティポスチャーを把握する前提となります。
3. 監査カバレッジは、統合トリガーのイベントがネイティブ操作と同じログ基盤に記録されて初めて意味を持つ。ネイティブファイル操作だけを記録し、サードパーティコネクタ経由のイベントを黙って省略する632イベント監査ログでは、フォレンジックカバレッジは部分的にしかなりません。部分的なカバレッジはカバレッジとは言えません。統合チャネルごとにイベントの完全性を検証しましょう。
4. サードパーティコネクタ経由の暗号鍵所有権は、ドキュメント上の前提ではなく、明確な回答が必要な問いである。顧客管理型暗号化（HYOK）は、Kiteworksのネイティブ操作については十分にドキュメント化されています。しかし、同じ鍵所有権がM365コネクタやSalesforce統合経由のデータにも技術的かつ検証可能な形で適用されるかどうかは、公開ドキュメントでは十分に説明されていません。アーキテクチャ決定前に必ず明確に質問しましょう。
5. MFT/SFTPチャネルはレガシーインフラではなく、他の統合同様に厳格なポリシー統制が必要な高リスクデータ経路である。マネージドファイル転送やSFTPチャネルは、しばしばバッチで大量の構造化データを、人手を介さず自動的に転送します。これらのチャネルにも、インタラクティブなユーザーセッションと同等のポリシーエンジンの適用が求められます。

なぜインテグレーションアーキテクチャは主権の問題なのか

防御可能なデータ主権ポスチャーを実現するには、統合経由でデータがどこに流れ、どのシステムがいつ保持し、各ポイントでどのセキュリティ制御が適用されるかを正確に追跡できる必要があります。この基準はNIS2第21条、DORAのICTサードパーティリスク要件、ISO 27001のサプライチェーンセキュリティ制御にも反映されています。

多くのエンタープライズファイル共有ベンダーは統合機能リストを公開していますが、DLPポリシーがファイルのコネクタ通過前後のどちらで評価されるか、HYOK鍵所有権がコネクタパイプライン全体で継続的に適用されるか、保存時の暗号鍵が移動中も同じ顧客所有鍵かどうかなど、パターンごとのデータフロードキュメントを公開しているベンダーはごくわずかです。こうしたアーキテクチャの詳細こそが主権主張の根拠であり、その不在は決して些細なギャップではありません。

Kiteworksは統合機能について広範なドキュメントを提供していますが、これらのアーキテクチャ詳細を1つの公開可能なブリーフに統合したパターン別データフロードキュメントは現時点でパブリックドメインには存在しません。本記事で述べる機能は、公開されている製品ドキュメントに基づいています。公開されていない重要な問いについては明示的にフラグを立てています。

パターン別データフロー：4つの統合アーキテクチャ

統合のセキュリティポスチャーを理解するには、データが実際にどのように流れるかを把握することが出発点です。以下の4つのパターン――Microsoft 365、iManage、Salesforce、SFTP/MFT――は、それぞれ独自のアーキテクチャ、リスクプロファイル、セキュリティアーキテクトが機微データ環境で導入前に解決すべき問いを持っています。

Microsoft 365：SharePoint、Teams、OneDrive、Outlook

Microsoft 365は、多くのエンタープライズ顧客にとって主要な統合パターンです。統合対象は4つの製品――SharePointドキュメントライブラリ、Teamsファイル共有、OneDrive同期、Outlookメール――にまたがり、それぞれデータの扱い方やセキュリティ上の課題が異なります。

統合の概要

KiteworksのM365統合では、ユーザーがKiteworksインターフェース内からRepositories Gateway（サードパーティリポジトリ向けのKiteworksネイティブコネクタフレームワーク）を通じてSharePoint、Teams、OneDriveのデータにアクセスでき、Outlookを離れることなくファイルの送受信が可能です。KiteworksのDLPポリシー、分類ラベル、アクセス制御は、どのM365製品から操作がトリガーされてもプラットフォームのポリシーエンジンを通じて適用されます。

メールに特化した機能としては、Email Protection Gateway（EPG）およびSMTPゲートウェイ統合により、Kiteworksのポリシー強制がOutlookメールフローにも拡張されます。これにより、添付ファイルの送信や受信ファイルにもコンテンツ検査、DLPルール、暗号化制御が適用され、ファイル共有インターフェース経由だけでなくメール経由のファイルにも一貫した保護が実現します。

データフローに関する問い

ユーザーがKiteworksコネクタ経由でSharePointファイルにアクセスする場合、2つのアーキテクチャ上の問いが重要です。第一に、ファイルはSharePointストレージに残ったまま（Kiteworksがポリシー・アクセス制御レイヤーとして機能）なのか、それともKiteworksインフラを経由するのか。第二に、Kiteworksインフラを経由する場合、その経路全体でHYOK鍵所有権が継続的に適用されるのか。

公開ドキュメントでは、KiteworksがM365統合操作にもDLP、分類、アクセス制御を適用すること、Kiteworks管理データにはHold Your Own Key（HYOK）暗号化が利用可能であることが記載されています。ただし、HYOK鍵所有権がM365コネクタ経由のデータにも拡張されるか、あるいはコネクタ経路では異なる暗号化前提が適用されるかについては、明示的な記載がありません。

Kiteworksに直接確認すべき質問：

• SharePointコネクタ経由でアクセスされるデータはKiteworksインフラを通過するのか。その場合、どのような暗号化ポスチャーが適用されるのか。
• HYOK鍵所有権はM365コネクタパイプライン経由のデータにも適用されるのか、それともKiteworksにネイティブ保存されたデータのみに適用されるのか。
• DLPポリシーの評価は、ファイルがコネクタ固有の処理を通過する前か後か、どのタイミングで行われるのか。

iManage：ドキュメント管理統合

iManageは、法律やプロフェッショナルサービス分野で主流のドキュメント管理システムです。iManage統合により、Kiteworksのセキュアなファイル共有・転送機能をiManageの案件やワークスペースに接続し、iManageの案件構造やアクセス制御のもとで外部送信が可能となります。

統合の概要

この統合により、ユーザーはiManageのドキュメントをKiteworksのセキュアな配信チャネルで直接共有でき、ファイルを別の場所にエクスポートする必要がありません。Kiteworksのアクセス制御――誰がどの条件でファイルを受け取れるか、有効期限はどうか――が外部転送に適用されます。監査証跡もKiteworksの632イベント監査ログに記録されます。

案件の機密保持が厳格に求められ、BSI C5（ドイツの法律事務所向け）やISO 27001などの規制フレームワークで監査要件が追加される法務分野では、外部ファイル転送を認定監査基盤で記録できること――メール記録のようなアドホックな手段ではなく――がこの統合の本質的価値です。

データフローに関する問い

iManage統合での主要なアーキテクチャ上の問いは、iManageからKiteworks経由で外部送信されるデータがKiteworksストレージに一時的に保持されるのか、即時に受信者へストリーミングされるのかという点です。一時的に保存される場合：どのような暗号化ポスチャーで、どのくらいの期間保持されるのか。ストリーミングの場合：転送中のデータにはどのような保証があるのか。

Kiteworksは統合全般でのエンドツーエンド暗号化をドキュメント化していますが、iManageからKiteworks経由で外部送信されるデータの具体的な転送挙動については、パターン別ドキュメントがあればより明確な保証となります。案件機密保持が厳格に求められる組織は、Kiteworksの技術チームと直接確認することを推奨します。

Salesforce：CRM連携ファイル交換

Salesforce統合は、営業チームやリレーションシップマネージャーがCRMレコード上で契約書や提案書、デューデリジェンス資料などの機微文書を送受信する必要がある一方、Salesforceのネイティブなファイル管理機能では規制業界のセキュリティ要件を満たせないという課題に対応します。

統合の概要

KiteworksのSalesforce統合により、ユーザーはSalesforceレコード内からKiteworksのセキュアな配信基盤を使って直接ファイルを送信できます。受信者にはファイル添付ではなくセキュアリンクが届きます。ファイルはKiteworksのポリシー制御下で配信され、DLPチェック、リンク有効期限、ダウンロード制限、アクセスログが適用されます。Salesforceレコードには配信状況を反映できます。

厳格なデータ分類要件がある業界――金融サービス（DORA対応）、ヘルスケア（各国データ保護法）、法律（職業倫理規定）――では、営業担当者がSalesforce上で作業する際に、単にメール添付で機微ファイルを送信してしまうリスクを防げる点が重要です。

データフローに関する問い

Salesforce統合での重要な問いは、DLPポリシー評価がファイルがSalesforceからKiteworks配信パイプラインに入る時点で行われるか、またその評価がKiteworksに直接アップロードされたファイルと同等に適用されるかです。Salesforce発の転送に異なるコードパスがある場合、攻撃者や不注意なユーザーに悪用されうるポリシー強制のギャップが生じる可能性があります。

公開ドキュメントでは、Kiteworksのポリシーエンジンが統合チャネル全体に適用されるとされていますが、Salesforce発の転送がネイティブアップロードと同じDLPパイプライン（コンテンツ検査を含む）を通るかは、技術評価時に確認する価値があります。

SFTP、AS2、マネージドファイル転送

SFTP、AS2、FTPSチャネルはしばしばレガシーインフラと見なされがちですが、そうではありません。金融サービス、サプライチェーン、ヘルスケア、政府分野では、マネージドファイル転送（MFT）チャネルが大量の構造化データをバッチで、自動的に、しばしば人手を介さずに転送しています。これらのチャネルにも、インタラクティブなユーザーセッションと同等、あるいはそれ以上に厳格なポリシー制御が必要です。

統合の概要

KiteworksのMFT機能は、SFTP、AS2、FTPSプロトコルをREST APIやWebインターフェースと並行してサポートします。自動転送ジョブ、バッチファイル処理、パートナー接続シナリオ――ヘルスケアEDI、金融決済、政府間データ交換で一般的――もこれらのチャネルで対応可能です。プラットフォームはスケジュール転送、条件付きルーティング、MFT標準フォーマット間のプロトコル変換もサポートします。

ここでのアーキテクチャは、前述のコネクタベース統合とは異なります。SFTPやAS2転送は完全自動化されていることが多く、インタラクティブなユーザーセッションがありません。したがって、これらのチャネルでの監査ログの完全性は特に重要です。バッチ転送ジョブで数千ファイルを移動し、問題が発生した場合でも、人手による転送と同等のフォレンジック記録が求められます。

データフローに関する問い

自動化されたMFTチャネルには特有の問いがあります。Kiteworks MFT ServerはDLP、高度な脅威対策（ATP）、アンチウイルス、Content Disarm and Reconstruct（CDR）スキャンを転送ワークフローに直接統合しており、DLPコンテンツ検査はワークフロー実行の一部として自動MFT転送にも適用されます。これはドキュメント化された機能であり、DLPスキャンは内蔵ワークフローノードとして組み込まれており、転送後のオプションチェックではありません。大規模バッチ環境での実運用では、DLPスキャンのスループットが転送ボリューム要件を満たすかどうか、テストバッチで個々のファイルレベルイベントが監査ログに記録されるかどうかを確認することが重要です。MFTトリガーの操作も他のプラットフォームアクティビティと同じ632イベントログ基盤に記録されます。

高ボリュームの自動MFTパイプラインを運用する組織では、DLPスキャンのスループットが要件を満たすか、ファイル単位のイベントがジョブ単位のサマリーだけでなく監査ログに記録されるかをテストで確認することが実践的な検証手順です。

横断的な統合制御：すべてに一貫して適用すべきもの

個別の統合パターンごとにデータフローは異なりますが、4つの制御はすべてのパターンで一貫して適用されなければセキュリティモデルは不完全です。これらは統合アーキテクトがチャネルごとに必ず検証すべき制御です。

DLPと分類：全チャネル横断のポリシー強制

データ損失防止は、ユーザーがコアプラットフォームとやり取りする場合だけに適用されても意味がありません。統合環境におけるDLPの本質は、どのアプリケーションが操作をトリガーしてもポリシーがデータに追従することです。Kiteworksに直接アップロードされたファイルも、SharePointコネクタ経由のファイルも、同じコンテンツ検査、同じ分類ラベル評価、同じブロック/警告/監査の結果が適用されなければなりません。

Kiteworksは統合対応型DLPポリシーを実装しており、すべての統合チャネルで適用される設計です。Microsoft Information Protection（MIP）センシティビティラベルもポリシー評価の一部として認識・強制されます。つまり、M365のラベリング基盤で分類済みのファイルも、M365コネクタ経由だからといってKiteworksのDLPルールを回避できません。独自の分類体系を持つ組織では、MIPラベルとは別にカスタム分類ラベルも適用可能です。

検証すべき制御：DLPコンテンツ検査（メタデータやラベルのチェックだけでなく、実際の内容検査）が各統合チャネル経由で到着したファイルにも適用されるか。上記4パターンごとに、ベンダーに技術ドキュメントやリファレンスアーキテクチャでDLP評価シーケンスを説明してもらいましょう。

アクセス制御：エントリーポイントを問わない一貫した強制

ネイティブKiteworksアクセスだけを統制し、SharePointコネクタ経由のアクセスをバイパスできるアクセス制御モデルは、単なる設定の寄せ集めであり、悪用可能なギャップを残します。すべての統合チャネルが潜在的なエントリーポイントであり、同じロールベース・属性ベースのポリシーがすべてに適用されなければなりません。

Kiteworksはポリシーエンジンレベルでアクセス制御を強制しており、どのインターフェースや統合がリクエストをトリガーしても制御が評価されます。ユーザーロール、部門属性、データのセンシティビティラベル、地理情報、デバイス準拠状況、時間帯アクセスウィンドウなどのコンテキストも、統合トリガー操作のアクセス判定に活用できます。

特にSalesforceやiManage統合では、Kiteworks統合が呼び出される前にサードパーティシステムでユーザーIDが確立されるため、アイデンティティフェデレーションの仕組みや、Kiteworksポリシーエンジンが十分な属性情報を受け取れるかを確認しましょう。統合時のハンドシェイクで属性情報が切り捨てられると、ネイティブセッションよりも限定的な情報でアクセス制御が適用されるリスクがあります。

監査ログ：統合チャネルごとの完全なイベントカバレッジ

Kiteworksの632イベント監査ログは、ガバナンスの大きな差別化要素です。その価値は完全性――統合操作で発生したイベントも、ネイティブユーザー操作と同じログ基盤に記録されること――に依存します。コネクタトリガー操作が部分的なイベント記録しか残さなかったり、自動MFT転送が別の簡易ログにしか記録されない場合、監査証跡のフォレンジック完全性は損なわれます。

632イベントの範囲は統合操作もカバーすることがドキュメント化されています。実践的な検証はシンプルです：対象統合チャネルごとにテスト環境でイベントログサンプルを取得し、ファイルアクセスイベント、DLPポリシートリガーイベント、認証イベントがネイティブ操作と同等の属性で記録されているか確認しましょう。SIEM統合の場合、コネクタトリガーイベントが同じsyslogフィードでリアルタイムに配信されるかも確認してください。

暗号化：統合境界を越えた鍵所有権

この制御については、公開ドキュメントだけでは問いが完全に解決されないため、直接検証が必須です。

KiteworksはHold Your Own Key（HYOK）暗号化をサポートしており、Kiteworksプラットフォームに保存されるデータの暗号鍵を顧客が管理できます。ネイティブKiteworksストレージでは、これは実質的な主権保証となります。

未解決の問いは、HYOK保証が統合コネクタ経由で転送されるデータにも継続的に適用されるかどうかです。M365 SharePointコネクタ経由でアクセスされるファイル、Salesforce統合パイプラインで処理されるファイル、iManageコネクタ経由で配信されるファイル――これらすべてにHYOK鍵所有権が適用されるかは、コネクタ構成ごとにKiteworksと技術的に確認すべきアーキテクチャ上の問いです。

これは製品の欠陥ではなく、ドキュメント上のギャップです。技術的にはすべての統合経路でHYOKが一貫して適用される可能性もありますが、それがパターン別アーキテクチャドキュメントで明示されるか、Kiteworks技術チームから直接確認できるまでは、前提ではなく未解決の問いとして扱うべきです。HYOKが厳格な要件となる組織――特にBSI C5の顧客鍵要件やアーキテクチャ主権制御を実装する組織――は、この問いを技術評価のゲート条件としてください。

実装チェックリスト：チャネルごとの統合セキュリティ検証

このチェックリストは、技術評価を行うインテグレーションアーキテクト向けです。検証すべき項目とその方法をまとめています。

開始前に

• 対象範囲のすべての統合チャネルをマッピングする。ローンチ時に使う予定のチャネルだけでなく、有効化されている未使用コネクタも攻撃対象領域となるため、すべて評価しましょう。
• 各チャネルで流通するデータの分類を特定する。以下の検証項目は、特に機微データや規制対象データを扱うチャネルで重要です。
• Kiteworksの最新BSI C5 Type 2アテステーションレポート、ISO 27001認証書、関連するSOC2 Type IIレポートを取得する。これらはセキュリティ制御の第三者検証を示しますが、チャネルごとの検証の代替にはなりません。

統合チャネルごとのDLP検証

• 各コネクタ（M365、iManage、Salesforce、SFTP/MFT）経由で到着するファイルにもDLPコンテンツ検査（メタデータ分類だけでなく内容検査）が適用されることを、書面で確認する。
• テスト環境で、DLPルールが発動するファイルを各コネクタ経由で転送し、ルールが発動し、イベントが期待通りの属性で監査ログに記録されることを確認する。
• MIPセンシティビティラベルについて：M365でラベル付与したファイルをSharePointコネクタ経由で転送し、Kiteworksがラベルを認識・強制し、ユーザーによる再分類を要求しないことを確認する。

統合チャネルごとの監査ログ検証

• 各コネクタでテスト転送を実施し、対応する監査ログエントリを取得。イベント種別、ユーザーID、ファイル識別子、タイムスタンプ、結果属性がすべて記録されていることを確認する（単なる「転送実施」記録だけでなく）。
• コネクタトリガーイベントがSIEMへのsyslogフィードに同じタイミングで出力されることを確認する（別チャネルや遅延がないか）。
• 自動MFT/SFTP転送については、テストバッチ転送でファイル単位のイベントがログに記録されること（ジョブ単位サマリーだけでなく）を確認する。

暗号化と鍵所有権

• HYOKが要件の場合：各コネクタタイプでHYOKが適用されるかどうか、Kiteworksから書面の技術ドキュメントを取得する。前提とせず、必ず明示的に質問する。
• Kiteworksインフラを経由するコネクタごとに、HYOK鍵所有権がコネクタパイプライン全体で継続的に適用されるか、構成ごとに書面のアーキテクチャ確認を取得する。
• 暗号鍵のローテーション手順が、統合経由で処理されたデータにもネイティブ保存データと同じ条件で適用されることを確認する。

Kiteworksの統合セキュリティへのアプローチ

多くのエンタープライズファイル共有プラットフォームは、統合を機能拡張――ユーザーの利便性を広げる追加接続ポイント――と捉えています。Kiteworksの設計思想は、統合をポリシー強制範囲の拡張と位置づけ、すべてのコネクタがプラットフォームのポリシーエンジン適用ポイントであり、バイパス経路ではないとしています。

この設計意図は、独立した認証によって裏付けられています。KiteworksはBSI C5 Type 2アテステーション――EUで最も厳格なクラウドセキュリティ認証フレームワークの一つであるドイツ連邦情報セキュリティ庁のクラウドセキュリティカタログ――を取得しています。BSI C5 Type 2アテステーションは、Kiteworksが認証機関と合意した範囲をカバーしており、利用中の統合チャネルが認証範囲内かどうかは最新のスコープ記述で確認する必要があります。ISO 27001認証やSOC2 Type IIレポートも追加の第三者検証となります。Cyber Essentials Plusは英国規制範囲をカバーし、IRAP PROTECTED認証はオーストラリア政府ユースケースに対応します。KiteworksのFedRAMP High In Processステータス――米国連邦認証フレームワークで最も厳しいインパクトレベル――は、米国外の規制組織にも重要なベンチマークとして評価されています。

このような認証ポートフォリオの幅広さは、セキュリティ制御がプラットフォーム全体に適用されていることを独立して証明する点で重要です。ただし、パターン別データフロードキュメントの代替にはなりません。Kiteworksのドキュメントが今後解消すべき「正直なギャップ」は、各統合パターンごとにデータフローを追跡し、コネクタ経由の暗号鍵所有権を明示的に扱った統合アーキテクチャブリーフが公開されていない点です。こうしたドキュメントは社内には存在しており、公開されれば主権重視の調達判断にとって大きな証拠基盤となるでしょう。

Kiteworksを機微な統合アーキテクチャで評価する組織は、本記事の問いを「障害」と捉えるのではなく、構造化された評価プロセスで解決すべき具体的な技術検証項目として扱ってください。機能自体は強力です。パターン別ドキュメント化こそが、次の成熟度段階です。

まとめ

統合アーキテクチャこそが、実際にセキュリティポスチャーの成否を分ける現場です――そして、データ主権を堅牢に築く組織は、パターンごと・チャネルごと・制御ごとに検証を重ね、プラットフォーム全体の保証だけで満足しません。DORAやNIS2などの規制フレームワークがデータフローアーキテクチャのドキュメント化を求める中、一般的な機能主張とパターン別ドキュメントのギャップは縮小し、積極的にギャップを埋めるプラットフォームが新たな標準を築くことになるでしょう。

よくある質問