Integrationsarchitektur für sicheres Filesharing im Unternehmen: Datenflüsse, Data Loss Prevention (DLP) und Verschlüsselung über M365, iManage, Salesforce und Managed File Transfer

Enterprise-Filesharing findet nicht isoliert statt. Sobald ein Unternehmen eine sichere Filesharing-Plattform mit Microsoft 365, einem Dokumentenmanagementsystem, einem CRM oder einem Managed File Transfer-Kanal verbindet, verschiebt sich die Sicherheitsfrage. Es geht dann nicht mehr nur darum, welche Kontrollen die Kernplattform anwendet – sondern ob diese Kontrollen den Daten folgen, wenn sie Integrationsgrenzen überschreiten.

Das ist das Problem der Integrationsarchitektur. Und dieses Problem wird in Beschaffungsprozessen oft unterschätzt. Anbieterlisten führen unterstützte Integrationen namentlich auf. Was sie selten – klar, öffentlich, überprüfbar – beantworten, ist, ob dieselben Data Loss Prevention (DLP)-Richtlinien, dieselben Zugriffskontrollen, dieselben Audit-Events und dieselbe Verschlüsselung konsequent auf Daten angewendet werden, die über einen Drittanbieter-Connector ein- oder ausgehen – genauso wie auf Daten, die über native Plattformfunktionen bewegt werden.

Dieser Beitrag richtet sich an Integrations- und Sicherheitsarchitekten, die Enterprise-Filesharing-Plattformen bewerten. Er zeigt Datenflüsse je Integrationsmuster – Microsoft 365, iManage, Salesforce und SFTP/MFT – und identifiziert die spezifischen Sicherheitskontrollen, die überall gelten müssen. Zudem wird die eine Frage hervorgehoben, die aktuell ein direktes Gespräch mit Kiteworks erfordert und nicht durch Dokumentation beantwortet wird: Kundenseitiger Besitz des Verschlüsselungsschlüssels für Daten, die Drittanbieter-Connectoren durchlaufen.

Executive Summary

Kernaussage: Integrationssicherheit bedeutet nicht, ob eine Plattform einen bestimmten Connector unterstützt – sondern ob die Policy Engine der Plattform Daten unabhängig vom auslösenden Connector steuert. DLP-Klassifizierung, Zugriffskontrolle, Audit-Logging und Verschlüsselung müssen mit gleicher Konsequenz auf eine Datei angewendet werden, egal ob sie über einen SharePoint-Connector, einen iManage-Sync, einen Salesforce-Anhang oder einen SFTP-Transfer läuft. Lücken an Integrationsgrenzen sind die Stellen, an denen Datensouveränität in der Praxis scheitert.

Warum das relevant ist: NIS 2, DORA und ISO 27001 fordern, dass Sicherheitskontrollen die gesamte Datenverarbeitungskette abdecken – inklusive Drittanbieter-Integrationen. Kann Ihr Anbieter kein datenflussbasiertes Integrationskonzept je Muster vorlegen – oder wird darin der Besitz des Verschlüsselungsschlüssels über den Connector nicht adressiert – entsteht eine Evidenzlücke, die Ihre Auditoren finden werden.

5 Wichtige Erkenntnisse

1. Policy Enforcement muss Daten über jeden Integrationskanal hinweg begleiten, nicht nur auf der Kernplattform. DLP-Regeln, Sensitivitätslabels und Zugriffskontrollrichtlinien, die bei Datenflüssen über einen M365-Connector oder einen SFTP-Kanal nicht konsequent greifen, schaffen echte Sicherheitslücken – die sich meist genau dann als Compliance-Verstoß zeigen, wenn es am ungünstigsten ist.
2. Jedes Integrationsmuster hat eine eigene Datenfluss-Architektur – und eigene Risiken. Ein SharePoint-Connector, ein iManage-Sync, ein Salesforce-Anhangs-Handler und eine Managed File Transfer-Pipeline gehen unterschiedlich mit Daten um. Wer den tatsächlichen Datenpfad versteht – wo Daten landen, was sie transformiert, welches System sie im ruhenden Zustand hält – versteht auch die Sicherheitslage der Integration.
3. Audit-Abdeckung ist nur dann sinnvoll, wenn durch Integrationen ausgelöste Events im selben Log wie native Vorgänge erscheinen. Ein 632-Event-Audit-Log, das native Dateioperationen erfasst, aber von Drittanbieter-Connectoren ausgelöste Events verschweigt, bietet nur teilweise forensische Abdeckung. Teilabdeckung ist keine Abdeckung. Prüfen Sie die Vollständigkeit der Events je Integrationskanal – nicht nur für die Plattform insgesamt.
4. Verschlüsselungsschlüssel-Besitz über Drittanbieter-Connectoren ist eine Frage, die eine direkte Antwort braucht, keine Annahme aus der Dokumentation. Kundengesteuerte Verschlüsselung (HYOK) ist für native Kiteworks-Operationen dokumentiert. Ob derselbe Schlüsselbesitz – technisch und überprüfbar – auch für Daten gilt, die über einen M365-Connector oder eine Salesforce-Integration laufen, ist öffentlich nicht abschließend geklärt. Fragen Sie explizit nach, bevor Sie sich für eine Architektur entscheiden.
5. MFT/SFTP-Kanäle sind keine Legacy-Infrastruktur – sie sind aktive Hochrisiko-Datenpfade, die dieselbe Policy-Governance wie jede andere Integration erfordern. Managed File Transfer- und SFTP-Kanäle bewegen große Mengen strukturierter Daten, oft im Batch, oft ohne menschliche Kontrolle bei jedem Transfer. Die Policy Engine muss auf diese Kanäle genauso strikt angewendet werden wie auf interaktive Anwendersitzungen.

Warum Integrationsarchitektur eine Souveränitätsfrage ist

Eine verteidigbare Souveränitätsstrategie verlangt, dass Sie exakt nachvollziehen können, wohin Daten bei einer Integration fließen, welches System sie wann hält und welche Sicherheitskontrollen an jedem Punkt greifen. Dieser Standard spiegelt sich in NIS 2 Artikel 21, den DORA-Anforderungen an ICT-Drittparteirisiken und den ISO 27001-Lieferkettensicherheitskontrollen wider.

Die meisten Enterprise-Filesharing-Anbieter veröffentlichen Listen ihrer Integrationsmöglichkeiten. Nur wenige publizieren datenflussbasierte Dokumentationen je Muster – etwa ob DLP-Richtlinien vor oder nach dem Connector greifen, ob HYOK-Schlüsselbesitz durchgehend im Connector-Pipeline gilt oder ob der Verschlüsselungsschlüssel, der die Datei im ruhenden Zustand schützt, derselbe ist (unter demselben Kundenschlüsselbesitz) während des gesamten Prozesses. Diese architektonischen Details sind das Fundament eines Souveränitätsanspruchs. Ihr Fehlen ist keine Bagatelle.

Kiteworks dokumentiert seine Integrationsmöglichkeiten ausführlich. Ehrlicherweise existiert jedoch keine konsolidierte, veröffentlichte Datenflussdokumentation je Muster im öffentlichen Raum. Die in diesem Beitrag beschriebenen Funktionen stammen aus öffentlich zugänglicher Produktdokumentation. Wo kritische Fragen öffentlich unbeantwortet bleiben, werden sie explizit gekennzeichnet.

Datenfluss je Muster: Vier Integrationsarchitekturen

Die Sicherheitslage einer Integration versteht man nur, wenn man den tatsächlichen Datenfluss kennt. Die vier Muster – Microsoft 365, iManage, Salesforce und SFTP/MFT – haben jeweils eigene Architekturen, Risikoprofile und Fragen, die Sicherheitsarchitekten vor dem Einsatz in sensiblen Datenumgebungen klären müssen.

Microsoft 365: SharePoint, Teams, OneDrive und Outlook

Microsoft 365 ist das dominierende Integrationsmuster für die meisten Unternehmenskunden. Die Integrationsoberfläche umfasst vier Produkte – SharePoint-Dokumentbibliotheken, Teams-Filesharing, OneDrive-Synchronisation und Outlook-Mail – die jeweils Daten unterschiedlich bewegen und unterschiedliche Sicherheitsfragen aufwerfen.

Was die Integration leistet

Die Kiteworks-M365-Integration ermöglicht es Anwendern, SharePoint-, Teams- und OneDrive-Daten direkt über die Kiteworks-Oberfläche per Repositories Gateway – Kiteworks‘ nativer Connector-Rahmen für Drittanbieter-Repositorys – zu nutzen und Dateien mit Outlook zu senden und zu empfangen, ohne den nativen Mail-Client zu verlassen. DLP-Richtlinien, Klassifizierungslabels und Zugriffskontrollen von Kiteworks greifen bei diesen Vorgängen über die Policy Engine der Plattform – unabhängig davon, welches M365-Produkt die Aktion ausgelöst hat.

Speziell für E-Mails erweitern das Email Protection Gateway (EPG) und die SMTP-Gateway-Integration die Policy Enforcement von Kiteworks auf Outlook-Mail-Flows – mit Inhaltsprüfung, DLP-Regeln und Verschlüsselungskontrollen für ausgehende Anhänge und eingehende Dateieingänge, nicht nur für Dateien, die direkt über die Filesharing-Oberfläche verschickt werden.

Die Datenflussfrage

Wenn ein Anwender über den Kiteworks-Connector auf eine SharePoint-Datei zugreift, sind zwei Architekturfragen entscheidend. Erstens: Bleibt die Datei im SharePoint-Speicher (Kiteworks agiert als Policy- und Zugriffskontrollschicht), oder durchläuft sie die Kiteworks-Infrastruktur? Zweitens: Falls sie die Kiteworks-Infrastruktur durchläuft, gilt HYOK-Schlüsselbesitz durchgehend auf diesem Transitpfad?

Die öffentliche Dokumentation bestätigt, dass Kiteworks seine Policy Engine – DLP, Klassifizierung, Zugriffskontrollen – auf M365-Integrationsvorgänge anwendet. Sie bestätigt auch, dass Hold Your Own Key (HYOK)-Verschlüsselung für von Kiteworks verwaltete Daten verfügbar ist. Was öffentlich nicht explizit dokumentiert ist: ob der HYOK-Schlüsselbesitz auch für Daten gilt, die speziell über den M365-Connector laufen, oder ob dieser Connector unter anderen Verschlüsselungsannahmen operiert.

Fragen, die Sie direkt an Kiteworks stellen sollten:

• Für Daten, die über den SharePoint-Connector abgerufen werden: Durchläuft die Datei die Kiteworks-Infrastruktur und falls ja, unter welcher Verschlüsselung?
• Gilt HYOK-Schlüsselbesitz für Daten, die durch die M365-Connector-Pipeline verarbeitet werden, oder nur für Daten, die nativ in Kiteworks gespeichert sind?
• Zu welchem Zeitpunkt im Datenfluss erfolgt die DLP-Policy-Prüfung – vor oder nach connector-spezifischer Verarbeitung?

iManage: Dokumentenmanagement-Integration

iManage ist das führende Dokumentenmanagementsystem in juristischen und Professional-Services-Umgebungen. Die iManage-Integration verbindet Kiteworks‘ sichere Filesharing- und Transferfunktionen mit iManage-Mandaten und -Workspaces – so können Daten extern über Kiteworks versendet werden, bleiben aber weiterhin durch die Mandats- und Zugriffskontrollstruktur von iManage geschützt.

Was die Integration leistet

Die Integration erlaubt es Anwendern, iManage-Dokumente über die sicheren Übertragungskanäle von Kiteworks zu teilen, ohne Dateien vorher exportieren zu müssen. Die Zugriffskontrollen von Kiteworks – wer die Datei erhalten darf, zu welchen Bedingungen, mit welchem Ablaufdatum – gelten für den ausgehenden Transfer. Der Audit-Trail des ausgehenden Vorgangs wird im 632-Event-Audit-Log von Kiteworks erfasst.

Gerade in juristischen Umgebungen, in denen Vertraulichkeit von Mandaten zwingend ist und in denen regulatorische Rahmen wie BSI C5 (relevant für deutsche Kanzleien) oder ISO 27001 zusätzliche Audit-Anforderungen stellen, ist die Möglichkeit, externe Dateiübertragungen in einer zertifizierten Audit-Infrastruktur zu protokollieren – statt in improvisierten E-Mail-Logs – der zentrale Mehrwert dieser Integration.

Die Datenflussfrage

Die entscheidende Architekturfrage bei der iManage-Integration ist, ob Daten, die aus iManage für die externe Übertragung über Kiteworks abgerufen werden, temporär in Kiteworks gespeichert oder direkt an den Empfänger gestreamt werden. Falls temporär gespeichert: Unter welcher Verschlüsselung und wie lange? Falls gestreamt: Welche Garantien gelten für Daten während der Übertragung?

Kiteworks dokumentiert Ende-zu-Ende-Verschlüsselung für Daten in der Übertragung über Integrationen allgemein. Das spezifische Übertragungsverhalten von Daten, die aus iManage über Kiteworks für die externe Zustellung laufen, ist ein Bereich, in dem eine musterbasierte Dokumentation mehr Sicherheit bieten würde als allgemeine Plattformangaben. Für Unternehmen mit strikten Anforderungen an Mandatsvertraulichkeit empfiehlt sich eine direkte Rücksprache mit dem technischen Team von Kiteworks.

Salesforce: CRM-integrierter Dateiaustausch

Die Salesforce-Integration adressiert ein häufiges operatives Problem: Vertriebsteams und Relationship Manager müssen vertrauliche Dokumente – Verträge, Angebote, Due-Diligence-Unterlagen – im Kontext von CRM-Datensätzen senden und empfangen, doch die native Salesforce-Dateiverwaltung entspricht nicht den Sicherheitsanforderungen regulierter Branchen für sensible Daten.

Was die Integration leistet

Die Kiteworks-Salesforce-Integration ermöglicht es Anwendern, Dateien direkt aus Salesforce-Datensätzen über die sichere Übertragungsinfrastruktur von Kiteworks zu versenden. Empfänger erhalten einen sicheren Link statt eines Datei-Anhangs. Die Datei wird über die policy-kontrollierte Umgebung von Kiteworks bereitgestellt – DLP-Prüfung, Link-Ablauf, Download-Limits und Zugriffsprotokollierung greifen. Der Salesforce-Datensatz kann mit dem Lieferstatus aktualisiert werden.

Für Branchen mit strikten Datenklassifizierungs-anforderungen – Finanzdienstleister unter DORA, Gesundheitswesen unter nationalen Datenschutzvorgaben, Juristen unter berufsrechtlichen Regeln – ist dieses Integrationsmuster wichtig, weil es verhindert, dass sensible Dateien als unkontrollierte Anhänge per E-Mail verschickt werden, nur weil der Vertriebler in Salesforce arbeitet und nicht in einer dedizierten Filesharing-Oberfläche.

Die Datenflussfrage

Die entscheidende Frage bei der Salesforce-Integration ist, ob die DLP-Policy-Prüfung in dem Moment erfolgt, in dem die Datei Salesforce verlässt und in die Kiteworks-Delivery-Pipeline gelangt – und ob diese Prüfung genauso konsequent erfolgt wie bei direkt in Kiteworks hochgeladenen Dateien. Gibt es einen anderen Codepfad für Salesforce-Transfers, könnte eine Policy-Lücke entstehen, die Angreifer (oder unachtsame Anwender) ausnutzen könnten.

Die öffentliche Dokumentation besagt, dass die Policy Engine von Kiteworks über alle Integrationskanäle hinweg greift. Die Bestätigung, dass speziell Salesforce-Transfers durch denselben DLP-Pfad laufen wie native Uploads – inklusive Inhaltsprüfung, nicht nur Metadatenklassifizierung – sollte im Rahmen der technischen Bewertung eingeholt werden.

SFTP, AS2 und Managed File Transfer

SFTP-, AS2- und FTPS-Kanäle werden oft als Legacy-Infrastruktur betrachtet. Das sollten sie nicht. In Finanzdienstleistungen, Lieferketten, Gesundheitswesen und Behörden bewegen Managed File Transfer (MFT)-Kanäle große Mengen strukturierter Daten – oft im Batch, oft automatisiert, oft ohne menschliche Kontrolle bei jedem Transfer. Die Policy Controls für diese Kanäle sind genauso wichtig wie für interaktive Anwendersitzungen, wenn nicht sogar wichtiger.

Was die Integration leistet

Die MFT-Funktion von Kiteworks bietet SFTP-, AS2- und FTPS-Protokollunterstützung neben REST-API und Web-Oberfläche. Automatisierte Transferjobs, Batch-Dateiverarbeitung und Partneranbindungen – gängig im Healthcare-EDI, bei finanziellen Abrechnungen und im behördlichen Datenaustausch – lassen sich über diese Kanäle abbilden. Die Plattform unterstützt geplante Transfers, bedingte Weiterleitung und Protokollübersetzung zwischen MFT-Standardformaten.

Die Architektur unterscheidet sich von den connector-basierten Integrationen oben. SFTP- und AS2-Transfers sind oft vollautomatisiert, ohne interaktive Anwendersitzung. Deshalb ist die Vollständigkeit des Audit-Logs für diese Kanäle besonders wichtig: Wenn ein Batch-Transfer mehrere Tausend Dateien bewegt und etwas schiefgeht, muss der forensische Nachweis so vollständig sein wie bei einem manuell ausgelösten Transfer.

Die Datenflussfrage

Für automatisierte MFT-Kanäle gelten spezielle Fragen. Der Kiteworks MFT Server integriert DLP, Advanced Threat Protection (ATP), Antivirus und Content Disarm & Reconstruct (CDR) direkt in die Transfer-Workflows – das heißt, DLP-Inhaltsprüfung ist ein fester Bestandteil des Workflows, nicht nur eine optionale Nachkontrolle. Die Frage für Hochdurchsatzumgebungen ist, ob die DLP-Inhaltsprüfung auch bei großen Batches in Ihrer spezifischen Umgebung performant skaliert. Audit-Events für MFT-Operationen werden im selben 632-Event-Log wie andere Plattformaktivitäten über den konsolidierten Unified Log Stream erfasst.

Für Unternehmen mit hochvolumigen, automatisierten MFT-Pipelines ist es entscheidend zu prüfen, ob der DLP-Scan-Durchsatz den Transferanforderungen der eigenen Umgebung entspricht – und einen Testlauf durchzuführen, um zu bestätigen, dass einzelne Datei-Events im Audit-Log erscheinen, nicht nur Zusammenfassungen auf Job-Ebene.

Kanalübergreifende Kontrollen: Was überall gelten muss

Jedes Integrationsmuster hat eigene Datenflüsse. Aber vier Kontrollen müssen überall konsequent greifen, sonst ist das Sicherheitsmodell unvollständig. Diese Kontrollen sollten Integrationsarchitekten je Kanal prüfen – nicht nur für die Plattform insgesamt.

DLP und Klassifizierung: Policy Enforcement über alle Kanäle

Datenverlustprävention ist wirkungslos, wenn sie nur bei Interaktion mit der Kernplattform greift. Der Sinn von DLP in einer integrierten Umgebung ist, dass die Policy den Daten folgt – unabhängig davon, welche Anwendung den Vorgang auslöst. Eine Datei, die direkt in Kiteworks hochgeladen wird, und eine Datei, die über einen SharePoint-Connector zugreift, müssen beide der gleichen Inhaltsprüfung, Klassifizierung und denselben Block/Warn/Audit-Maßnahmen unterliegen, wenn eine Policy greift.

Kiteworks implementiert integrationsfähige DLP-Richtlinien, die für alle Integrationskanäle gelten. Microsoft Information Protection (MIP)-Sensitivitätslabels werden erkannt und als Teil der Policy-Prüfung durchgesetzt – eine Datei, die bereits durch M365 klassifiziert wurde, umgeht die DLP-Regeln von Kiteworks nicht, nur weil sie über den M365-Connector kommt. Eigene Klassifizierungslabels können zusätzlich zu MIP-Labels angewendet werden, falls Unternehmen eigene Taxonomien pflegen.

Die Kontrolle, die zu prüfen ist: Gilt DLP-Inhaltsprüfung – nicht nur Metadaten- oder Label-Check, sondern echte Inhaltsprüfung – auch bei Dateien, die über jeden Integrationskanal ankommen? Lassen Sie sich vom Anbieter die DLP-Prüfsequenz für jedes der vier Muster anhand technischer Dokumentation oder Referenzarchitektur erläutern.

Zugriffskontrolle: Konsequente Durchsetzung unabhängig vom Einstiegspunkt

Ein Zugriffskontrollmodell, das native Kiteworks-Zugriffe steuert, aber umgangen werden kann, wenn ein Anwender über einen SharePoint-Connector zugreift, ist kein Zugriffskontrollmodell – sondern eine Sammlung gut gemeinter Einstellungen mit ausnutzbarer Lücke. Jeder Integrationskanal ist ein potenzieller Einstiegspunkt, und dieselben rollen- und attributbasierten Policies müssen überall gelten.

Kiteworks erzwingt Zugriffskontrollen auf Ebene der Policy Engine – das heißt, Kontrollen werden unabhängig davon geprüft, über welche Oberfläche oder Integration die Anfrage ausgelöst wurde. Benutzerrollen, Abteilungsattribute, Sensitivitätslabels und Kontextfaktoren – wie Geostandort, Geräte-Compliance und zeitbasierte Zugriffsfenster – können in die Zugriffskontrolle für Integrationsvorgänge einfließen, nicht nur für native UI-Interaktionen.

Gerade bei Salesforce- und iManage-Integrationen, wo die Identität des Anwenders im Drittsystem festgelegt wird, bevor die Kiteworks-Integration greift, sollten Sie prüfen, wie die Identitätsföderation funktioniert und ob die Policy Engine von Kiteworks den vollständigen Attributkontext erhält. Wird der Identitätskontext beim Integrations-Handshake gekürzt, könnte die Zugriffskontrolle weniger Attribute berücksichtigen als bei einer nativen Sitzung.

Audit-Logging: Vollständige Event-Abdeckung je Integrationskanal

Das 632-Event-Audit-Log von Kiteworks ist ein wesentliches Governance-Unterscheidungsmerkmal der Plattform. Sein Wert basiert auf Vollständigkeit – Events, die durch Integrationen ausgelöst werden, erscheinen im selben Log wie native Aktivitäten. Wenn Connector-Operationen nur teilweise protokolliert werden oder automatisierte MFT-Transfers in einem separaten, weniger detaillierten Log landen, ist die forensische Vollständigkeit des Audit-Trails kompromittiert.

Der 632-Event-Umfang ist dokumentiert als Abdeckung für Integrationsoperationen. Die praktische Prüfung ist einfach: Für jeden Integrationskanal im Scope fordern Sie ein Beispiel-Event-Log aus einer Testumgebung an und prüfen, ob Datei-Events, DLP-Policy-Trigger und Authentifizierungsereignisse mit denselben Attributen wie bei nativen Vorgängen erscheinen. Für SIEM-Integrationen prüfen Sie, ob Connector-Events im selben Syslog-Feed und mit denselben Echtzeit-Eigenschaften ankommen.

Verschlüsselung: Schlüsselbesitz über Integrationsgrenzen hinweg

Hier gilt: Die öffentliche Dokumentation beantwortet die Frage nicht abschließend – und direkte Verifizierung ist essenziell, nicht optional.

Kiteworks unterstützt Hold Your Own Key (HYOK)-Verschlüsselung, sodass Kunden die Kontrolle über die Verschlüsselungsschlüssel für ihre Daten im ruhenden Zustand auf der Kiteworks-Plattform behalten. Für native Kiteworks-Speicherung ist das ein echtes Souveränitätsversprechen.

Die offene Frage ist, ob die HYOK-Garantie auch für Daten gilt, die Integrations-Connectoren durchlaufen. Wenn eine Datei über den M365-SharePoint-Connector abgerufen, durch die Salesforce-Integration verarbeitet oder über den iManage-Connector geliefert wird – gilt der HYOK-Schlüsselbesitz durchgehend? Das ist eine technische Architekturfrage, die Sie für Ihre spezifische Connector-Konfiguration mit Kiteworks klären sollten.

Das ist kein Produktmangel – sondern eine Dokumentationslücke. Die technische Antwort mag sein, dass HYOK überall konsequent gilt. Aber solange das nicht explizit in einer musterbezogenen Architekturdokumentation steht oder direkt von den technischen Teams von Kiteworks bestätigt wird, sollte es als offene Frage behandelt werden. Unternehmen, für die HYOK zwingend ist – insbesondere solche, die BSI C5-Kunden-Schlüsselanforderungen erfüllen oder Souveränitätskontrollen implementieren – sollten diese Frage als Ausschlusskriterium in ihre technische Bewertung aufnehmen.

Implementierungs-Checkliste: Integrationssicherheit je Kanal verifizieren

Diese Checkliste richtet sich an Integrationsarchitekten für die technische Bewertung. Sie zeigt, was und wie zu prüfen ist – nicht nur, welche Kontrollen existieren.

Vor dem Start

• Kartieren Sie alle Integrationskanäle im Scope. Prüfen Sie nicht nur die Kanäle, die Sie zum Start nutzen wollen – auch aktivierte, aber ungenutzte Connectoren sind Angriffsfläche.
• Bestimmen Sie für jeden Kanal die Datenklassifizierung der Daten, die darüber laufen. Die untenstehenden Prüfungen sind besonders kritisch für Kanäle mit sensiblen oder regulierten Daten.
• Fordern Sie den aktuellen BSI C5 Type 2-Attestierungsbericht, das ISO 27001-Zertifikat und ggf. einen SOC 2 Type II-Bericht von Kiteworks an. Diese bestätigen die Überprüfung der Sicherheitskontrollen durch Dritte. Sie sind eine Basis, aber kein Ersatz für die Prüfung je Integration.

DLP-Prüfung je Integrationskanal

• Fordern Sie eine schriftliche Bestätigung an, dass DLP-Inhaltsprüfung (nicht nur Metadatenklassifizierung) für Dateien gilt, die über jeden relevanten Connector ankommen: M365, iManage, Salesforce, SFTP/MFT.
• Übertragen Sie in einer Testumgebung eine Datei, die eine DLP-Regel auslösen würde, über jeden Connector. Prüfen Sie, ob die Regel greift und das Event mit den erwarteten Attributen im Audit-Log erscheint.
• Für MIP-Sensitivitätslabels: Übertragen Sie eine Datei mit in M365 gesetztem Sensitivitätslabel über den SharePoint-Connector. Prüfen Sie, ob Kiteworks das Label erkennt und durchsetzt, ohne dass der Anwender die Datei erneut klassifizieren muss.

Audit-Log-Prüfung je Integrationskanal

• Führen Sie für jeden Connector einen Testtransfer durch und holen Sie die entsprechenden Audit-Log-Einträge ab. Prüfen Sie, ob Eventtyp, Benutzeridentität, Datei-ID, Zeitstempel und Ergebnisattribute vollständig sind – nicht nur ein generischer „Transfer erfolgt“-Eintrag.
• Stellen Sie sicher, dass Connector-Events im selben Syslog-Feed für Ihr SIEM erscheinen, nicht in einem separaten oder verzögerten Kanal.
• Für automatisierte MFT/SFTP-Transfers: Führen Sie einen Test-Batchtransfer durch und prüfen Sie, ob einzelne Datei-Events geloggt werden, nicht nur Zusammenfassungen auf Job-Ebene.

Verschlüsselung und Schlüsselbesitz

• Wenn HYOK im Scope ist: Fordern Sie schriftliche technische Dokumentation von Kiteworks an, ob HYOK für Daten gilt, die über jeden Connector-Typ verarbeitet werden. Nicht annehmen – explizit nachfragen.
• Für jeden Connector, der Daten durch die Kiteworks-Infrastruktur leitet: Fragen Sie, ob HYOK-Schlüsselbesitz durchgehend im Connector-Pipeline gilt, und fordern Sie eine schriftliche Architektur-Bestätigung für Ihre spezifische Connector-Konfiguration an.
• Prüfen Sie, ob Schlüsselrotation für integrationsverarbeitete Daten unter denselben Bedingungen gilt wie für nativ gespeicherte Daten.

Wie Kiteworks Integrationssicherheit umsetzt

Die meisten Enterprise-Filesharing-Plattformen betrachten Integrationen als Funktions-Erweiterungen – zusätzliche Verbindungspunkte, die den Anwendern mehr Möglichkeiten bieten. Die Designphilosophie von Kiteworks ist: Integrationen sind Erweiterungen des Policy-Enforcement-Scopes – jeder Connector ist ein Punkt, an dem die Policy Engine der Plattform greifen muss, nicht ein Umgehungspfad.

Diese Designabsicht ist unabhängig validiert. Kiteworks verfügt über eine BSI C5 Type 2-Attestierung – den Cloud-Sicherheitskatalog des Bundesamts für Sicherheit in der Informationstechnik, einen der strengsten Cloud-Sicherheitsstandards in der EU. Die BSI C5 Type 2-Attestierung deckt den Scope ab, der in der Zertifizierung definiert ist – Organisationen sollten die aktuelle Scope-Definition prüfen, um sicherzustellen, dass die genutzten Integrationskanäle im attestierten Bereich liegen. ISO 27001-Zertifizierung und SOC 2 Type II-Berichte bieten zusätzliche Drittverifizierung. Cyber Essentials Plus deckt den britischen regulatorischen Perimeter ab. IRAP PROTECTED-Zertifizierung gilt für australische Behörden. Der FedRAMP High In Process-Status von Kiteworks – die anspruchsvollste Stufe im US-Bundesautorisierungsrahmen – signalisiert eine Sicherheitsreife, die auch außerhalb der USA als Benchmark gilt.

Die Breite dieses Zertifizierungsportfolios ist hier relevant, weil sie unabhängig belegt, dass Sicherheitskontrollen im gesamten Plattform-Scope greifen. Sie ersetzt aber keine musterbasierte Datenflussdokumentation. Die ehrliche Lücke – die Kiteworks besser schließen kann als jede Zertifizierung – ist das Fehlen einer konsolidierten, veröffentlichten Architekturübersicht, die Datenflüsse je Integrationsmuster nachzeichnet und explizit den Schlüsselbesitz je Connector adressiert. Diese Dokumentation existiert intern. Ihre öffentliche Verfügbarkeit würde die Evidenzbasis für souveränitätsbewusste Beschaffungsentscheidungen deutlich stärken.

Organisationen, die Kiteworks für sensible Integrationsarchitekturen evaluieren, sollten die in diesem Beitrag genannten Fragen nicht als Blocker, sondern als konkrete technische Prüfpositionen in einem strukturierten Bewertungsprozess behandeln. Die Fähigkeiten sind stark. Die Dokumentation dieser Fähigkeiten auf Muster-Ebene ist der nächste Reifeschritt.

Fazit

Integrationsarchitektur entscheidet in der Praxis über die Sicherheitslage – und die Unternehmen, die nachhaltige Datensouveränität erreichen, sind diejenigen, die je Muster, je Kanal, je Kontrolle verifizieren, statt sich auf Plattform-Pauschalaussagen zu verlassen. Da regulatorische Rahmen wie DORA und NIS 2 zunehmend eine dokumentierte Datenflussarchitektur fordern, wird die Lücke zwischen allgemeinen Fähigkeitsbehauptungen und veröffentlichter musterbasierter Dokumentation kleiner werden – und die Plattformen, die sie proaktiv schließen, setzen den Standard für den Markt.

Häufig gestellte Fragen