Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / DLP für Microsoft Fabric und Power Platform: versteckte Connectoren, Umgebungen und Datenlecks stoppen (KI-Synchronfassung)

Transcript

DLP für Microsoft Fabric und Power Platform: versteckte Connectoren, Umgebungen und Datenlecks stoppen (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

0:00
Bereit für 10 Tage voller Microsoft 365, Co-Pilot, KI-Azure und den Vordenkern, die die Zukunft der Arbeit gestalten.
0:07
Diesen Januar ist die M365-Con zurück und wir legen noch eine Schippe drauf.
0:12
Seien Sie dabei bei Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Fachleuten aus aller Welt.
0:18
Keine generischen Folien, keine endlosen Modewörter.
0:21
Wir gehen die echten Herausforderungen an.
0:23
Co-Pilot-Studio, KI-Agenten, Fabric, Sicherheit, Governance und Automatisierung.
0:28
Egal ob IT-Profi, Entwickler oder Führungskraft, es gibt Sessions, die genau für Sie gemacht sind.
0:35
In 10 vollen Tagen können Sie vielfältige Technologien erkunden und sich mit einer globalen Community vernetzen.
0:40
Verfolgen Sie die Live-Inhalte und nehmen Sie praxisnahe Erkenntnisse mit in Ihr Unternehmen.
0:45
Januar 2027, 10 Tage, eine Microsoft-Community.
0:49
Die Registrierung ist ab sofort geöffnet.
0:51
Sichern Sie sich heute noch Ihren Platz.
0:52
Besuchen Sie m31565hecon.it henefitab.
1:00
Melden Sie sich jetzt unter m31565.it an.
1:03
Wir sehen uns live im Januar.
1:05
Haben Sie sich jemals gefragt, was wirklich passiert, wenn eine Power-App geschäftskritische Daten an eine persönliche Dropbox sendet?
1:11
Wenn Sie glauben, DLP sei nur für E-Mails, dann sehen Sie nur die halbe Wahrheit.
1:16
Lassen Sie uns den Entscheidungsprozess hinter den Kulissen betrachten, der Ihr Unternehmen schützt oder eben Sicherheitslücken zulässt.
1:21
Heute werfen wir ein Schlaglicht auf die versteckten, wenn-dann-Regeln in Fabric- und Power-Plattform-DLP, damit Sie Datenlacks erkennen, bevor Sie bei Ihrer Compliance-Stelle landen.
1:34
Warum DLP oft versagt und die blinden Flecken, über die niemand spricht.
1:37
Wenn Sie schon einmal ein grünleuchtendes DLP-Dashboard sahen, nur um kurz darauf eine E-Mail wegen eines Lacks zu erhalten, kennen Sie das Gefühl.
1:44
Kennen Sie das Gefühl.
1:45
Die meisten hacken einfach alles ab, legen Ihre Richtlinien fest und glauben, die Arbeit sei getan.
1:50
Einrichten und vergessen ist verlockend.
1:52
Aber Fabric- und Power-Plattformen folgen nicht den alten Regeln und in den Lücken entstehen die echten Probleme, entstehen die echten Probleme.
1:58
Hier kommt der unbequeme Teil.
1:59
Sie können das strengste Regelwerk erstellen und trotzdem blinde Flecken übersehen, weil die Welt nicht nur nach Richtlinien-Checklisten funktioniert.
2:05
In der Sekunde, in der Sie sich abwenden, findet jemand einen brandneuen Connector.
2:09
Es könnte ein glänzendes SaaS-Tool sein, das das Marketing dringend braucht oder eine Schatten-IT-Lösung, die entstand,
2:14
weil jemand eine einfache Aufgabe automatisieren wollte.
2:17
Plötzlich steht das, was wie ein gut umzäunter Gartenhauer sperrangelweit offen, gibt keine Warnsignale.
2:22
Die meisten DLP-Richtlinien basieren auf dem, was bereits im Einsatz ist, bestehende E-Mail-Regeln, bekannte Plattformen, gängige Connector.
2:28
Gängige Connector.
2:29
Wenn Power-Plattform oder Fabric einen neuen Connector oder eine Integration einführt, kann dieser unbemerkt in Ihre Umgebung schlüpfen, als wäre er schon immer da gewesen.
2:36
Admins prüfen neue Connectoren gelegentlich, aber die Wahrheit ist, dass Unternehmen sie viel schneller hinzufügen, als jemand Risiken bewerten kann.
2:42
Schatten-IT ist eben nicht nur ein Schlagwort für illegale USB-Sticks.
2:47
Da Plattformen wie Power-Apps es jedem leicht machen, Lösungen zu erstellen, entwickeln, Business-Teams-Apps und Automatisierungen im Handumdrehen.
2:57
Ihr Ziel sind Schnelligkeit und Ergebnisse, nicht Risikominimierung.
3:00
Wenn Sie noch nie geprüft haben, welche Abläufe zwischen geschäftlichen und privaten Konten bestehen, könnten Sie schockiert sein, was im Hintergrund alles läuft.
3:06
Jemand verknüpft seine Power-App mit einem privaten OneDrive oder Gmail und sensible Daten gelangen unbemerkt durch die Hintertür nach außen, während ihr DLP-Scanner noch den E-Mail-Ausgang überwacht.
3:18
Ein persönlicher Favorit, und das nicht im positiven Sinne ist, die Finanz-App, die harmlos aussieht, aber bricht in die Dropbox und irgendjemandem teilt.
3:23
Es geschieht so schnell, dass man es erst bemerkt, wenn die falschen Leute eine Rechnung oder einen Lohnabrechnungsexport sehen.
3:31
Das sind die, das passiert uns nicht, Geschichten, die man vermeiden will, aber sie sind überall.
3:36
Untersuchungen der letzten Jahre bestätigen zunehmend, was viele Administratoren bereits vermutet haben.
3:40
Datenlecks entstehen selten über die offensichtlichen Hauptkanäle.
3:44
Stattdessen sickern sie durch Verbindungen, die niemand erfasst hat, Integrationen.
3:47
Die harmlosschienen oder Abläufe, die vor sechs Monaten von einem Team erstellt wurden, das es nicht mehr gibt.
3:52
Es gibt hier noch einen weiteren unterschätzten Aspekt, Umgebungen.
3:56
Unternehmen richten mehrere Power-Plattformen oder Fabrik-Umgebungen für Entwicklung, Test und Produktion ein.
4:01
Das ist doch Best Practice, oder?
4:03
Doch Daten bewegen sich häufiger zwischen hin und her, als man denkt.
4:06
Wenn jemand Daten aus der Produktion zu Testzwecken in eine niedrigere Umgebung exportiert, wer überwacht?
4:11
Diesen Fluss? Wer überwacht diesen Fluss?
4:13
Wenn diese Umgebungen nicht einheitlich verwaltet werden, haben sie gerade ihre eigene Grauzone geschaffen.
4:18
Die alte Annahme, dass Richtlinien alles innerhalb der Plattform abdecken, bricht.
4:21
In dem Moment zusammen, in dem Daten in einer halbgesicherten Sandbox oder einem unwichtigen Entwicklungsbereich landen.
4:27
Administratoren konzentrieren sich erwartungsgemäß auf die offensichtlichen Pfade.
4:30
E-Mail ist gesichert, bekannte, riskante Konnektoren sind gruppiert.
4:34
Aber genau diese kleinen Übergaben, bei denen Geschäftsdaten von einer genehmigten Plattform zu anderen gleiten,
4:38
bevor sie nach außen gelangen, sind der Ort, an dem sich die Falltüren verbergen.
4:41
Viele Richtlinien gehen davon aus, dass alle Business-Konnektoren sicher sind,
4:44
aber das bricht in dem Moment zusammen, in dem ein benutzerdefinierter Konnektor der letztes Quartal für ein Nebenprojekt gebaut wurde,
4:49
eine Lücke reißt, die sie nie bemerkt haben.
4:52
Oder jemand aus der Personalabteilung nutzt einen Business-Konnektor,
4:55
der im Stillen öffentliche API-Frufe ins Internet unterstützt und die Datengrenze umgeht, die sie für sicher hielten.
5:02
Schwierigst du daran?
5:03
Die meisten von uns erfahren erst im Nachhinein von diesen Risiken.
5:06
Wenn Sie schon einmal ein internes Audit hatten, bei dem ein Datenflussbericht erstellt wurde,
5:09
der nicht mit Ihrer schönen DLP-Konfiguration übereinstimmte, wissen Sie genau, wovon ich spreche.
5:13
Dem Audit ist es egal, wie viele Kontrollen Sie festgelegt haben.
5:16
Es interessiert sich nur dafür, wohin die Daten tatsächlich fließen.
5:19
Die Diskrepanz tut am meisten weh, wenn Daten erst bei einem privaten Konto oder einem nicht verwalteten Dienst landen
5:23
und niemand es merkt, bis die Auskunftsanfrage auf Ihrem Schreibtisch landet.
5:27
Das Risiko liegt nicht dort, wo man es vermutet.
5:29
Daher ist es im Dashboard fast unmöglich zu finden.
5:32
Die unangenehme Wahrheit ist, dass das echte Leck fast nie das ist, das in Ihrer richtigen Übersicht rot blinkt.
5:37
Es ist diese unsichtbare Verbindung zwischen dem Offiziellen und dem Vergessenen durch die sensible Daten spurlos abfließen.
5:45
Fabric und Power-Plattformen machen es, nicht IT-Anwendern extrem leicht, Tools zu kombinieren.
5:50
Eine DLP-Richtlinie von letztem Jahr schützt daher kaum vor heutigen Risiken.
5:54
Sie denken jetzt vielleicht, na toll, wo fange ich denn überhaupt an?
5:57
Diese versteckten Datenflüsse zu erkennen, erfordert eine Neugensweise bei der Suche.
6:00
Anstatt Richtlinien zu durchforsten, in der Hoffnung ein übersehenes Häkchen zu finden,
6:04
müssen Sie nachverfolgen, wie Daten wirklich fließen, wer, was verbindet, wo sie landen
6:08
und welche Konnektoren in den Umgebungen überhaupt genutzt werden.
6:14
Der größte Gewinn liegt darin, jene Grauzonen zu erfassen, die Sie bisher nie auf dem Schirm hatten.
6:18
Denn solange Sie nicht jeden Datenfluss zwischen Plattformen und Konnektoren sehen,
6:21
übersehen Sie die Hälfte der entscheidenden blinden Flecken.
6:24
Das bringt uns zunächst eine Herausforderung.
6:26
Wie können Sie diese unsichtbaren Datenflüsse und harmlosen Verbindungen erkennen und abbilden,
6:30
bevor es jemand anderes für Sie tut, bevor Sie tun?
6:32
Das Labyrinth kartieren, die Vendant-Szenarien, die über den Erfolg Ihrer Richtlinie entscheiden.
6:36
Nehmen wir ein Szenario an.
6:38
Sie haben eine Power-App, die geschäftskritisch ist?
6:41
Vielleicht verarbeitet sie Gehaltsabrechnungen oder verfolgt Kundenrechnungen?
6:44
Stellen Sie sich nun vor, ein Benutzer fügt sein persönliches OneDrive als Konnektor hinzu.
6:48
Auf den ersten Blick wirkt das völlig harmlos.
6:50
Der Benutzer möchte nur eine Sicherungskopie speiten.
6:52
Aber was passiert eigentlich unter der Motorhaube?
6:53
Die App wird plötzlich zur Brücke eine Seite verankert,
6:57
in ihrer streng geschützten Geschäftsumgebung.
6:59
Die andere baumelt über einem privaten Cloud-Konto, auf das Sie keinerlei Kontrolle haben.
7:05
Ihre DLP-Richtlinie sollte da eigentlich sofort eingreifen und die Notbremse ziehen.
7:08
Genau hier erkennen die meisten von uns,
7:09
dass das Labyrinth bei weitem nicht so gut kartiert ist wie wir dachten.
7:13
Über Fabric- und Power-Plattformen hinweg bringt jeder Konnektor,
7:15
ob integriert, benutzerdefiniert oder etwas,
7:17
das das Marketing-Team letzte Woche entdeckt hat,
7:18
einen Entscheidungspunkt mit sich.
7:19
Und nicht alle sind auf den ersten Blick erkennbar.
7:22
Die DLP-Richtlinien-Engine versucht, diese binär zu behandeln,
7:25
erlaubt oder blockiert, geschäftlich oder privat.
7:29
Doch die Realität bietet etwa ein Dutzend Graustufen.
7:32
Wer mit diesen Systemen gearbeitet hat,
7:34
weiß, dass kleine ungeprüfte logische Lücken sich schnell summieren.
7:39
Nehmen wir zum Beispiel an,
7:40
ein Entwickler erstellt einen Fabrikarbeitsbereich
7:42
und exportiert zu Testzwecken Live-Kundendaten
7:45
über einen Drittanbieter-Konnektor in ein externes SaaS-Tool,
7:48
das er gerade testet.
7:51
War Ihre DLP so konfiguriert,
7:52
dass sie diesen Connector überhaupt als Risiko erkennt?
7:55
Bei vielen ist das nicht der Fall.
7:56
Und das erste Anzeichen für Probleme tritt erst auf,
7:58
wenn die Daten bereits abgewandert sind.
8:00
Die Herausforderung verschärft sich,
8:01
wenn Umgebungen sich überschneiden.
8:03
Dev, Test, Prod, alles ist streng getrennt,
8:05
außer wenn es das eben nicht ist?
8:06
Vielleicht denken Sie,
8:07
Herr Prod abgesichert,
8:07
der Rest ist zum Experimentieren da.
8:09
Aber was, wenn eine Kopie von Kundendaten
8:11
in diese leichtgewichtige Dev-Umgebung gelangt
8:13
und ein Connector,
8:14
der als harmlos eingestuft
8:15
oder bei der Richtlinienprüfung übersehen wurde,
8:17
die Tür nach außen öffnet?
8:20
Die Van-Dun-Logik bricht schnell in sich zusammen.
8:22
Der DLP-Logikbaum sollte theoretisch
8:24
jede Datenbewegung aus einer geschützten Umgebung
8:25
zu einem nicht verwalteten Connector erfassen,
8:27
aber wir wissen,
8:27
dass nur wenige Richtlinien so präzise sind.
8:30
Die meisten Administratoren,
8:31
die unter Zeitdruck stehen,
8:32
erstellen Richtlinien,
8:32
die nur das widerspiegeln,
8:33
was sie direkt vor Augen haben.
8:35
Gmail und Dropbox sperren SharePoint
8:36
und Teams erlauben vielleicht noch
8:37
ein paar benutzerdefinierte Einschränkungen hinzufügen.
8:39
Aber was ist mit den Konnektoren,
8:42
die unter dem Radar fliegen?
8:44
Eine benutzerdefinierte SaaS-Integration,
8:46
ein für einen schnellen Proof-of-Concept erstellter Connector
8:48
oder einfach ein neuer Microsoft-Connector
8:49
aus einem Update.
8:51
Das sind die Lücken,
8:52
durch die Daten entwischen.
8:54
Der Logikbaum in den meisten Umgebungen
8:55
wird bei weitem nicht so oft überprüft,
8:57
wie neue Konnektoren hinzugefügt werden.
8:59
Und anders als bei Mailfluss-Regeln
9:00
sind diese nicht immer selbst erklärend.
9:02
Oberflächlich betrachtet wirken sie geschäftsfreundlich,
9:04
doch im Hintergrund können sie mehr übertragen,
9:06
als ihnen lieb ist.
9:07
Hier ist ein weiterer Aspekt.
9:08
Die meisten DLP-Konfigurationen
9:10
behandeln Connector-Gruppierungen
9:11
wie einen Punkt auf einer Checkliste.
9:13
Nur als Geschäftsdaten markieren klingt gut,
9:15
bis ein benutzerdefinierter Connector
9:17
oder ein unbekanntes SaaS auftaucht.
9:19
Jetzt verlassen sie sich auf Namenskonventionen
9:21
und Microsoft-Standard-Vorlagen,
9:22
die möglicherweise nicht einmal annähernd
9:24
ihren tatsächlichen geschäftlichen Anforderungen entsprechen.
9:28
Die Wenn-Dann-Ketten werden länger und unhandlicher.
9:31
Wenn ein Connector als nur für Geschäftsdaten markiert ist,
9:33
bedeutet das dann,
9:34
dass er für die private Nutzung gesperrt ist.
9:35
Was passiert,
9:36
wenn sich die Definition von geschäftlich ändert,
9:38
weil die Marketingabteilung ein neues Cloud-Tool findet?
9:41
Wenn die Richtlinie nicht getestet wurde,
9:42
ist das alles nur theoretische Sicherheit.
9:44
Sicherheit.
9:45
Verpasste Auslöser sind ein weiterer Grund,
9:46
warum diese Szenarien für echte Kopfschmerzen sorgen.
9:49
Die meisten DLP-Tools
9:50
priorisieren Warnmeldungen bei bekannten Risiken.
9:53
Wenn aber niemand die Logik
9:54
für einen neuen Connector
9:55
oder einen übergreifenden Transfer definiert hat,
9:57
erfahren sie erst davon,
9:58
wenn die Compliance-Abteilung die Spur entdeckt.
9:59
Manchmal gibt es nicht einmal eine Warnung,
10:03
sondern nur ein unbemerktes Datenleck,
10:04
das so lange anhält,
10:05
bis jemand fragt,
10:05
wo die Gehaltsabrechnungen des letzten Quartals geblieben sind.
10:09
Untersuchungen zeigen immer wieder,
10:10
dass Unternehmen diese übergreifenden Szenarien
10:12
selten simulieren,
10:13
bevor etwas schief geht.
10:15
Die Feedbackschleife ist zu langsam.
10:16
Viele Administratoren
10:17
finden sich bei der Fehlerbehebung wieder,
10:19
nachdem sie festgestellt haben,
10:20
dass eine Richtlinie
10:21
nicht rechtzeitig gegriffen
10:22
oder einen subtilen Grenzfall übersehen hat.
10:24
Admins mit den wenigsten Horrorgeschichten
10:26
über Datenverlust
10:27
spielen nicht nur
10:27
Hau den Maulwurf mit neuen Diensten.
10:29
Sie betrachten jeden Connector,
10:31
besonders neue oder benutzerdefinierte,
10:32
als potenzielles Fragezeichen.
10:35
Anstatt darauf zu warten,
10:36
dass etwas kaputt geht,
10:37
erstellen sie mentale,
10:38
wenn dann Landkarten.
10:39
Wenn ein Benutzer versucht,
10:40
Gehaltsdaten in eine neue SARS-Anwendung zu exportieren,
10:43
verhindert die Richtlinie dies.
10:44
Falls nicht, warum?
10:46
Wenn ein Fabrikarbeitsbereich
10:47
Zugriff auf einen externen Speicherort erhält,
10:49
welche Wege können diese Daten nehmen
10:50
und sind einige davon unüberwacht?
10:52
Diese Admins überprüfen
10:54
die tatsächlichen Geschäftsworkflows
10:55
nicht nur die Liste
10:56
der verfügbaren Connectoren.
10:57
Wenn das Unternehmen also
10:58
ein Tool hinzufügt,
10:59
stellen sie die richtigen Fragen,
11:00
bevor sie den Schalter umlegen.
11:02
Am Ende besteht der Kern
11:04
ihrer DLP-Geschichte
11:04
nicht aus dem,
11:05
was auf dem offiziellen Richtlinien
11:06
im Blatt steht.
11:08
Er liegt in diesen komplizierten,
11:10
realen Szenarien begraben,
11:11
in denen eine einzige übersehene Option
11:13
in einem Logikbaum
11:14
Firmengeheimnisse
11:15
durch die Hintertür entweichen lässt.
11:18
Je mehr sie diese
11:18
Wenn-Dann-Momente vorhersehen
11:20
und genauso testen,
11:21
wie es ihre Benutzer tun würden,
11:22
desto stärker werden
11:23
ihre Daten kontrollen,
11:24
desto Daten kontrollen.
11:25
Aber jedes Leck zu finden
11:26
bedeutet nicht nur,
11:27
Mauern zu bauen.
11:28
Es geht darum,
11:29
zu identifizieren,
11:29
welche Mauern sie wirklich brauchen.
11:31
Denn solange sie sich
11:32
nicht auf die Connectoren konzentrieren,
11:33
die für die Arbeit
11:34
ihrer Teams wichtig sind,
11:35
werden alle
11:36
Logikbäume der Welt
11:37
den falschen Ausgang
11:38
nicht stoppen.
11:39
Und das eröffnet
11:40
eine völlig neue Ebene
11:41
der Herausforderung.
11:42
Herauszufinden,
11:43
welche Connectoren
11:44
überhaupt ihre Aufmerksamkeit verdienen.
11:47
Connector-Klassifizierung
11:48
die Trennung von Signal und Rauschen.
11:51
Sie kennen das endlose Scrollen
11:52
durch die Connector-Liste,
11:53
Reihen um Reihen von Namen,
11:54
die nach einer Weile
11:55
alle ineinander verschwimmen.
11:57
Die meisten sehen
11:57
routinemäßig aus.
11:58
Dinge wie SharePoint,
11:59
Excel,
12:00
Azure,
12:01
vielleicht ein paar
12:01
mit den Initialen
12:02
ihres Unternehmens.
12:03
Auf dem Papier
12:04
ist es beruhigend zu sehen,
12:05
dass diese riesige Auswahl
12:06
in saubere Gruppen
12:07
unterteilt ist.
12:07
Aber das wirkliche Risiko
12:10
liegt nicht immer dort,
12:10
wo man es vermutet.
12:12
Herauszufinden,
12:12
welche Connectoren
12:13
tatsächlich ein hohes Risiko
12:14
darstellen und welche
12:15
nur zum normalen
12:15
Geschäftsalltag gehören,
12:16
ist nicht so einfach,
12:17
wie es sein sollte.
12:18
Genau da biegen
12:19
die meisten Teams falsch.
12:21
Die Wahrheit ist,
12:21
dass jede Umgebung
12:22
mit Dutzend von
12:23
integrierten Connectoren
12:23
vollgestopft ist,
12:24
gestopft ist.
12:26
Wenn Sie jemals versucht haben,
12:27
den Überblick darüber zu behalten,
12:28
was tatsächlich angeschlossen ist
12:29
und Daten verschiebt,
12:30
wissen Sie,
12:30
wie schnell die Einstellungen
12:31
unübersichtlich werden.
12:32
Ein Teil der Herausforderung
12:33
besteht darin,
12:34
dass das Connector-Management
12:35
immer organisiert beginnt.
12:35
Ein solider Plan,
12:37
einige Regeln
12:37
und feste Absichten.
12:39
Dann bewegt sich das Unternehmen
12:40
schneller,
12:40
als die IT-Schritt halten kann.
12:42
Es geht nicht nur darum,
12:43
was die Connectoren tun,
12:44
sondern auch,
12:44
was sie tun könnten,
12:45
je nachdem,
12:45
wie Benutzer ihre Abläufe einrichten.
12:48
Ein Connector zu
12:48
OneDrive for Business
12:49
mag harmlos erscheinen,
12:50
wenn er für den internen
12:51
Gebrauch eingerichtet ist,
12:52
aber durch eine einzige
12:53
Fehlklassifizierung
12:54
oder eine übersehene
12:54
Konfiguration
12:55
könnte derselbe Connector beginnen,
12:57
sensible Dokumente
12:58
an nicht verwaltete
12:58
Speicherorte weiterzuleiten.
13:01
Wenn Sie schon einmal
13:02
in Meetings saßen,
13:02
in denen die Lösung lautete,
13:03
einfach alles zu blockieren,
13:05
wie das ausgeht.
13:07
Die Leute finden Umwege,
13:08
die Schatten-IT wächst
13:09
und plötzlich ist das Risiko
13:10
höher, nicht niedriger.
13:12
Sie möchten die Produktivität
13:14
nicht bremsen,
13:14
aber jedes nicht kontrollierte Feld
13:15
fühlt sich wie eine potenzielle
13:16
Sicherheitslücke an.
13:18
Einige Administratoren
13:19
versuchen alles außerhalb
13:20
des Microsoft-Kern-Ökosystems
13:22
wie SharePoint und Teams
13:23
zu sperren
13:23
und alles andere auszuschließen.
13:24
Aber das reicht selten aus.
13:26
Hier ist eine Wahrgeschichte.
13:27
Ein Unternehmen
13:28
setzte voll auf diesen Ansatz
13:29
in der Annahme,
13:30
dass nichts Kritisches
13:31
über weniger bekannte
13:33
Konnektoren fließen würde.
13:34
Sie ließen nur eine Handvoll offen,
13:36
Teams, SharePoint,
13:37
die üblichen Verdächtigen
13:38
im Vertrauen darauf,
13:39
alles fremde blockiert zu haben.
13:41
Doch jemand in der Personalabteilung
13:43
entdeckte ein cleveres
13:43
No-Code-Integrationstool
13:45
und erstellte einen
13:45
benutzerdefinierten Connector
13:46
zu einer öffentlichen API.
13:48
Es schien harmlos.
13:50
Wochen später
13:50
stellten sie fest,
13:51
dass HR-Daten
13:52
unbemerkt abflossen.
13:53
Nicht,
13:53
weil es ein bekanntes Risiko war,
13:55
sondern weil
13:55
niemand den benutzerdefinierten
13:57
Connector
13:57
für mehr als ein Nebenprojekt hielt.
13:59
Die Folgen waren unangenehm
14:01
und unterstreichen,
14:01
dass Connectoren
14:02
nicht alle gleich sind
14:03
und auch nicht einfach
14:04
mit pauschalen
14:04
Ja- oder Nein-Regeln
14:05
gehandhabt werden können.
14:07
Microsoft bietet ihnen
14:08
Kategorien nicht ohne Grund an,
14:10
geschäftlich nicht geschäftlich
14:11
blockieren.
14:12
Auf dem Papier
14:12
sollten diese Kategorien
14:13
ihr Leben vereinfachen.
14:15
In der Realität
14:16
greifen die Standardeinstellungen
14:17
oft zu kurz,
14:18
da sie nicht widerspiegeln,
14:19
was in ihrem Unternehmen
14:20
wirklich passiert.
14:22
Ein als geschäftlich
14:23
eingestufter Connector
14:25
mag für ein Finanzteam
14:26
völlig sinnvoll sein,
14:26
aber setzen sie
14:27
denselben Connector
14:28
in der Rechts- oder
14:29
Forschungsabteilung ein,
14:30
sieht er plötzlich riskant aus.
14:32
Einige Konnektoren
14:33
legen klar offen,
14:33
wohin ihre Daten fließen,
14:34
aber viele verbergen
14:35
ihre Komplexität
14:36
hinter freundlichem Namen.
14:37
Sie sehen vielleicht
14:38
eine geschäftsfreundliche Bezeichnung,
14:39
aber im Hintergrund
14:40
könnte derselbe Connectortüren
14:41
zu externen Apps,
14:43
nicht verwalteten Diensten
14:44
oder APIs öffnen,
14:45
die nicht ihrem
14:46
Compliance-Profil entsprechen.
14:49
Es sind die Konnektoren,
14:50
die nicht auffallen,
14:50
über die niemand zweimal
14:51
nachdenkt,
14:52
die am häufigsten
14:53
das perfekte Sprungbrett
14:53
für einen Datenabfluss bilden.
14:55
Bilden.
14:56
Das Marketing greift
14:56
zu etwas glänzendem,
14:58
die IT erstellt
14:59
einen benutzerdefinierten
15:00
Webhook für ein Pilotprogramm.
15:02
Ein Entwickler,
15:02
der spät arbeitet,
15:03
findet ein SaaS-Tool,
15:04
baut eine Integration
15:05
und macht weiter.
15:07
Bis es jemand bemerkt,
15:08
läuft der Connector
15:08
bereits im Hintergrund
15:09
in der Produktion
15:10
und er steht oft nicht
15:11
auf dem monatlichen Prüfbericht.
15:13
Die Plattformen
15:14
senden ihm nicht gerade
15:14
eine Benachrichtigung,
15:15
wenn jemand etwas Neues
15:16
baut oder einführt.
15:19
Mit der Zeit
15:19
wächst die Liste
15:20
der Konnektoren an
15:21
und ohne jemanden,
15:22
der sie aktiv bereinigt
15:23
und überprüft,
15:24
übertönt das Rauschen
15:25
die Hochrisikosignale.
15:26
Aktuelle Studien zeigen,
15:28
dass der intelligenteste
15:29
Ansatz nicht darin besteht,
15:30
einfach nur längere
15:31
Listen zu erstellen
15:31
oder mehr Konnektoren
15:32
zu einer Blockgruppe
15:33
hinzuzufügen.
15:34
Es geht um Abstimmung.
15:35
Wenn Connector-Gruppen
15:36
ihren realen
15:37
Geschäftsprozessen
15:37
entsprechen,
15:38
sinken sowohl Datenlacks
15:39
als auch Reibungsverluste
15:40
bei den Nutzern drastisch.
15:41
Das ist nicht nur Theorie,
15:42
sondern gelebte Erfahrung
15:42
in großen Unternehmen.
15:44
Die Teams,
15:45
die sich tatsächlich
15:45
mit den Fachbereichen
15:46
zusammensetzen,
15:46
um Arbeitsabläufe abzubilden,
15:48
erkennen ungewöhnliche
15:49
Konnektoren,
15:50
bevor sie zum Problem werden.
15:51
Sie erfahren,
15:52
warum ein Connector
15:53
verwendet wird,
15:54
welche Aufgabe er
15:55
tatsächlich erfüllt
15:55
und welche Abläufe
15:56
geschäftskritisch sind
15:57
im Gegensatz zu solchen,
15:58
die nur dem Komfort
15:58
eines einzelnen Nutzers dienen.
16:00
Wenn Sie die Klassifizierung
16:01
von Konnektoren
16:02
wie eine starre
16:02
Aufgabenliste behandeln,
16:03
überwachen Sie am Ende
16:04
eine Parade,
16:05
während die wichtigen Dinge
16:06
unbemerkt über Seitenwege
16:07
entweichen.
16:08
Durch einen klareren
16:09
Überblick,
16:09
der darauf basiert,
16:10
wie Ihre Mitarbeiter
16:11
wirklich arbeiten,
16:12
können Sie schneller reagieren
16:13
und erkennen,
16:14
wenn sich der Datenfluss
16:15
verändert hat.
16:16
Connector-Risiken
16:17
sind selten statisch.
16:18
Die sichere Wahl von heute
16:19
kann durch eine einzige
16:20
Änderung im Workflow
16:21
oder eine neue
16:21
Plattformfunktion
16:22
riskant werden.
16:23
Reibung ist hier
16:24
nicht der Feind,
16:25
sondern Unwissenheit.
16:26
Zu verstehen,
16:26
wie sich das Geschäft
16:27
entwickelt und wie schnell
16:28
Integrationen entstehen
16:29
oder sich verändern,
16:30
hält Ihre Klassifizierung
16:31
aktuell,
16:32
anstatt sie sofort
16:32
nach Abschluss
16:33
der Überprüfung
16:34
obsolet zu machen.
16:36
Der eigentliche Trick
16:37
liegt also in der Kommunikation,
16:38
nicht nur in der Konfiguration.
16:40
Führen Sie einen Dialog
16:41
mit Ihren Power-Usern,
16:41
also jenen Teams,
16:42
die neue Lösungen aufbauen
16:43
und Dinge ausprobieren,
16:44
bevor die meisten anderen
16:45
überhaupt davon hören.
16:46
Wenn Administratoren
16:48
eng mit den Verantwortlichen
16:49
für Geschäftsprozesse
16:50
zusammenarbeiten,
16:51
führen sie nicht nur
16:51
eine Prüfung durch,
16:52
sondern erhalten einen Einblick,
16:53
welche Konnektoren
16:54
die tatsächliche Arbeit
16:55
vorantreiben
16:55
und welche nur
16:56
die Optionsliste füllen.
16:58
Diese Art der Partnerschaft
16:59
ermöglicht das frühzeitige
17:01
Erkennen riskanter Konnektoren
17:02
und nimmt dem Blockieren
17:03
den Schrecken,
17:04
da sie den realen Hintergrund
17:05
der Richtlinie
17:06
bereits erläutert haben.
17:08
Bei der Connector-Klassifizierung
17:09
geht es nicht darum,
17:10
Anforderungen abzuhaken,
17:11
sondern jeden Schritt
17:11
zu verfolgen,
17:12
den Ihre Daten machen könnten
17:13
und die Kategorien
17:14
anzupassen,
17:14
während das Unternehmen wächst,
17:15
sich wandelt und Neues ausprobiert,
17:17
sich wandelt und Neues ausprobiert.
17:18
Ein Klassifizierungssystem,
17:19
das mit dem Unternehmen
17:20
Schritt hält,
17:20
ist immer leistungsfähiger
17:21
als eines,
17:22
das in der Einrichtungsphase
17:23
erstarrt ist.
17:25
Wenn Sie erst einmal
17:25
herausgefunden haben,
17:26
wo das Risiko wirklich liegt,
17:27
ist das nächste Kopfzerbrechen
17:28
das Testen,
17:29
das Testen.
17:30
Wie führt man neue
17:31
DLP-Richtlinien ein,
17:32
die zwar die richtigen
17:33
Abläufe erfassen,
17:34
aber nicht die kritischen
17:34
Prozesse unterbrechen,
17:35
auf die die Nutzer
17:36
täglich angewiesen sind?
17:39
Testen ohne Tränen,
17:40
adaptive DLP-Richtlinien
17:41
für die reale Welt entwickeln.
17:43
Wenn Sie schon einmal
17:44
einen Montag erlebt haben,
17:45
an dem eine brandneue
17:46
DLP-Richtlinie
17:47
noch vor dem Frühstück
17:47
fünf Hauptarbeitsabläufe
17:48
Ihres Teams lahmgelegt hat,
17:50
wissen Sie,
17:50
wie brutal Tests
17:51
in der Produktion sein können.
17:53
Sie erhalten diese E-Mail,
17:54
eine Automatisierung
17:55
ist fehlgeschlagen,
17:56
verärgerte Nutzer
17:56
kontaktieren die IT
17:57
und niemand erinnert sich daran,
17:58
die Regel genehmigt zu haben,
17:59
die das halbe Geschäft
18:00
lahmgelegt hat.
18:01
Es fühlt sich an,
18:02
als hätte man nur die Wahl,
18:03
entweder alles so stark zu sperren,
18:04
dass nichts mehr geht,
18:04
oder alles so locker zu lassen,
18:05
dass man nur auf den Anruf
18:06
des Wirtschaftsprüfers wartet.
18:08
Keines der beiden Extreme
18:09
funktioniert auf Dauer.
18:11
Aber wenn man den schwierigen Teil,
18:12
das Testen,
18:13
der Richtlinien
18:13
vor dem Live-Gang überspringt,
18:15
entdeckt man Datenlecks
18:16
erst, wenn sie bereits
18:16
Probleme verursacht haben.
18:19
Das ist keine Situation,
18:20
in der man als Administrator
18:20
stecken will.
18:21
Lassen Sie uns darüber
18:22
sprechen, wie echtes Testen auch.
18:23
In Fabric und der Power-Plattform
18:24
ist es verlockend,
18:25
Änderungen direkt
18:25
in der Produktion vorzunehmen,
18:26
um zu sehen, was passiert.
18:28
Meistens liegt das an dem Druck,
18:30
Lösungen schnell bereitzustellen,
18:31
ohne das Tagesgeschäft zu bremsen.
18:33
Doch wer schon einmal
18:34
eine neue Regel aktiviert hat
18:35
und dabei zusehen musste,
18:36
wie Exporte, Genehmigungen
18:37
und Benachrichtigungen
18:38
zum Stillstand kamen,
18:39
weiß, dass es einen
18:40
intelligenteren Weg
18:40
zum Ausgleich geben muss.
18:42
Ein Szenario taucht dabei
18:43
immer wieder auf.
18:45
Eine Abteilung automatisiert
18:46
den Export von Kundenberichten
18:47
in Fabric.
18:48
Das Unternehmen ist
18:48
auf diese Automatisierung angewiesen.
18:50
Es spart jede Woche Stunden,
18:51
bis ihre neue DLP-Richtlinie
18:52
den Prozess blockiert,
18:53
weil die Logik ihn als Risiko
18:54
für Datenabfluss einstuft.
18:56
Jetzt sitzen Sie in der Klemme.
18:57
Der Export ist geschäftskritisch,
18:58
aber die Richtlinie sagt nein.
19:00
Wer darf die Sperre aufheben?
19:01
Wie sieht die Umgehungslösung?
19:02
Was ist der eigentliche Konflikt?
19:03
Das Geschäft basiert
19:04
auf diesen unsichtbaren Abläufen
19:05
und DLP erkennt nicht immer
19:06
den Unterschied zwischen einem Leck
19:07
und einer lebenswichtigen Funktion.
19:09
Tests zu überspringen geht schnell,
19:10
ist aber auch der sicherste Weg,
19:12
die wirklich wichtigen Lacks zu übersehen.
19:14
Erschwerend kommt hinzu,
19:15
dass Richtlinien Nebenwirkungen
19:16
haben können,
19:17
die man nie geplant hatte,
19:18
die man nie geplant hat.
19:19
Sind die Bedingungen zu strengen,
19:20
suchen sich die Benutzerwege,
19:21
diese zu umgehen.
19:22
Sind sie zu locker,
19:23
landen stapelweise Support-Tickets
19:24
auf ihrem Schreibtisch.
19:26
Das Ziel ist nur das Abhaken
19:26
an der Checkliste.
19:27
Es geht darum,
19:28
die Workflows,
19:28
auf die sich alle verlassen,
19:29
reibungslos zu halten
19:30
und gleichzeitig das zu verhindern,
19:31
was auf keinen Fall
19:32
nach außen dringen darf.
19:33
Wie erreicht man das also?
19:34
Untersuchungen und Praxiserfahrungen
19:36
bestätigen,
19:36
dass stufenweise Rollouts
19:37
fast immer besser sind
19:38
als eine große Umstellung auf einmal.
19:40
Äh, das sieht dann so aus.
19:42
Anstatt alles auf einmal umzustellen,
19:43
führen sie neue Richtlinienänderungen
19:45
erst für eine kleine Gruppe
19:45
von Pilotanwendern ein.
19:48
Durch gezielte Überwachung,
19:49
echtes Prüfen der Protokolle,
19:51
Messen von Fehlern
19:52
und direktes Feedback der Benutzer
19:54
erkennen sie Richtlinienkonflikte,
19:56
solange sie noch beherrschbar sind.
19:57
Der Unterschied ist,
19:59
dass die Benutzer,
19:59
die auf Probleme stoßen,
20:00
echte Menschen mit echten Aufgaben
20:02
sind keine theoretischen Testfälle,
20:04
die niemand wirklich braucht.
20:05
Analysen sind der nächste Schritt.
20:07
Fabric und die Power-Plattform
20:08
bieten umfangreiche Aktivitätsprotokolle
20:10
und sie werden überrascht sein,
20:11
was sie sehen,
20:11
wenn sie diese wirklich im Blick behalten,
20:13
wenn sie diese wirklich überhalten.
20:14
Die Überwachung dieser Abläufe wäre,
20:16
womit verbunden ist
20:17
und welche Apps,
20:18
wann Daten verschieben,
20:19
zeigt Muster,
20:19
die beim Reinlesen
20:20
von Richtlinienzusammenfassungen
20:22
verborgen bleiben.
20:24
Nehmen wir an,
20:24
sie bemerken,
20:25
dass die Personalabteilung
20:25
jeden Freitag Exportläufe testen,
20:27
und Daten an einen kaum genutzten
20:28
Connector sendet,
20:29
sendet.
20:31
Wenn ihre Analysen zeigen,
20:32
dass der Connector
20:32
sonst nirgends verwendet wird,
20:33
besteht die Lösung vielleicht darin,
20:35
nur diese Richtlinie anzupassen,
20:36
statt in Panik
20:36
das gesamte Unternehmen zu blockieren.
20:39
Indem sie Analysen nutzen,
20:40
um sich entwickelnde Datenpfade
20:41
zu erkennen,
20:42
können sie ihre Richtlinien anpassen,
20:43
bevor sie zu Frust
20:43
bei den Anwendern
20:44
oder Compliance-Problemen
20:45
führen führen.
20:46
Sandbox-Umgebungen
20:47
sind längst nicht mehr
20:47
nur für Entwickler da.
20:49
Die Realität ist,
20:49
dass die meisten Richtlinien
20:50
viel erst aufwahlen,
20:51
wenn in der Produktion
20:52
etwas kaputt geht.
20:53
Es ist dann viel zu spät.
20:54
In Sandboxes können sie
20:55
neue Richtlinien
20:56
basierend auf echtem
20:57
Nutzerverhalten erstellen,
20:58
anpassen und prüfen,
20:59
ohne Angst haben zu müssen,
21:00
dass kritische Systeme
21:01
dauerhaft ausfallen.
21:03
Sie können legitime
21:04
Geschäftsaktivitäten simulieren,
21:05
Testdaten exportieren,
21:06
Connectors ausprobieren,
21:07
Abläufe ausführen
21:07
und sehen,
21:08
was die Regeln blockieren
21:08
und was durchgelassen wird.
21:10
Durch Tests
21:11
in einer sicheren Umgebung
21:12
sehen sie tatsächlich,
21:13
wo ihre Logik sinnvoll ist
21:14
und wo sie in sich zusammenfällt.
21:16
Es ist wesentlich einfacher,
21:17
eine Regel in der Sandbox
21:18
neu zu schreiben,
21:19
als den Schaden
21:19
nach einem Rollout zu beheben.
21:21
Wenn Sie sowohl Anwender
21:23
als auch Prüfer
21:23
zufriedenstellen wollen,
21:24
sollten Sie die Einführung
21:25
von Richtlinien
21:25
als iterativen Prozess betrachten.
21:28
Die erfolgreichsten
21:29
Administratoren,
21:30
die am wenigsten Stress haben,
21:31
binden die Anwender
21:32
immer in die Feedback-Schleife ein.
21:35
Prüfen Sie nach jeder Testrunde,
21:36
welche Workflows
21:37
tatsächlich unterbrochen wurden
21:38
und fragen Sie,
21:38
hat die Richtlinie
21:39
ein Leck gestoppt
21:40
oder nur den Geschäftsbetrieb
21:41
behindert?
21:42
Passen Sie die Regeln an,
21:44
informieren Sie
21:44
die beteiligten Teams
21:45
und setzen Sie die Änderung um,
21:47
bevor Sie die Produktion
21:47
überhaupt berühren.
21:48
Die Leute erinnern sich daran,
21:51
wenn
21:51
Sie es nicht verbunden haben,
21:54
aber auch die
21:55
keit
21:55
noch
21:56
dass
21:57
die
21:57
die
21:57
die
21:58
die
21:59
Herausforderung
22:00
sehen Sie,
22:00
wenn Sie,
22:01
wenn Sie das
22:03
sehen,
22:03
dann
22:03
sehen Sie,
22:03
dann
22:05
sehen Sie,
22:06
das
22:07
sehen Sie,
22:08
dann
22:08
sehen Sie,
22:08
jetzt
22:09
sind
22:09
die
22:10
see
22:10
out
22:11
sehen Sie,
22:12
dann
22:13
die
22:13
kommen
22:15
oder
22:15
sehen Sie,
22:16
indem
22:17
sie
22:18
sind
22:18
zu
22:19
sehen,