Pułapka shadow IT: dlaczego nadmierne blokowanie konektorów zniechęca użytkowników
By Mirko Peters ·
Witamy ponownie w towarzyszącym blogu do naszych trwających głębokich analiz dotyczących governance, bezpieczeństwa i administrowania Microsoft 365. Jeśli zarządzasz nowoczesną dzierżawą przedsiębiorstwa…
Automatically translated with AI from the original post. Read the English original
Witamy ponownie w towarzyszącym blogu do naszych trwających głębokich analiz dotyczących governance, bezpieczeństwa i administrowania Microsoft 365. Jeśli zarządzasz nowoczesną dzierżawą przedsiębiorstwa, prawdopodobnie odczuwasz ogromną presję, by wszystko zablokować. Gdy kadra zarządzająca wyraża obawy o eksfiltrację danych, pierwszą reakcją zespołów IT i bezpieczeństwa jest zwykle szybki i bezwzględny odruch: zablokować konektory, ograniczyć zasady ochrony danych (DLP) do absolutnego minimum i zmusić każdego użytkownika do przechodzenia przez mocno ograniczony tunel. Wygląda to na proaktywne działanie. Dobrze prezentuje się na slajdzie o zgodności. Jednak, jak widzimy raz za razem w audytach środowisk produkcyjnych, takie podejście tworzy niebezpieczne złudzenie bezpieczeństwa.
Aby dokładnie omówić ten kluczowy problem, niedawno nagraliśmy dedykowany odcinek podcastu, który dotyczy właśnie tych punktów tarcia w governance. Jeśli chcesz posłuchać naszej żywej dyskusji, prawdziwych historii z audytów i praktycznych wskazówek, koniecznie sprawdź Strengthen Power Platform DLP and Default Environment Governance. W tym wpisie rozwiniemy te koncepcje, koncentrując się przede wszystkim na tym, dlaczego agresywne ograniczenia konektorów przynoszą odwrotny skutek i jak znaleźć właściwy punkt równowagi między bezpieczeństwem a możliwościami użytkowników.
Wprowadzenie: fałszywe poczucie bezpieczeństwa przy restrykcyjnym DLP
Podstawowa filozofia, którą kieruje się wiele architektur bezpieczeństwa, jest prosta: jeśli narzędzie może przenosić dane, a my nie możemy jednoznacznie zagwarantować jego bezpieczeństwa, musimy je wyłączyć. W kontekście Microsoft Power Platform – Power Apps, Power Automate i Copilot Studio – objawia się to zwykle jako agresywne zasady DLP, które blokują niemal wszystkie konektory spoza Microsoftu albo wrzucają wszystko do sztywnej grupy danych biznesowych „Blocked”.
Administratorzy śpią spokojniej, wiedząc, że dane firmowe nie mogą swobodnie płynąć do niezweryfikowanych usług zewnętrznych. Ten model zgodności opiera się jednak na zasadniczo błędnym założeniu: że użytkownicy po prostu przestaną próbować rozwiązywać swoje problemy biznesowe, gdy napotkają przeszkodę techniczną. W rzeczywistości nowocześni pracownicy wiedzy są zaradni, działają pod presją terminów i coraz lepiej radzą sobie z technologią. Gdy IT mówi „nie” uzasadnionej potrzebie biznesowej, ukrytej za sztucznym ograniczeniem, użytkownicy nie rezygnują z pracy. Zamiast tego znajdują sposób, by to obejść. Właśnie wtedy rodzi się shadow IT.
Pułapka środowiska domyślnego: „kuchenny zlew” Power Platform
Zanim przyjrzymy się, jak użytkownicy omijają blokady konektorów, musimy wskazać miejsce, w którym faktycznie biorą początek większość tych awarii bezpieczeństwa: środowisko domyślne. W niemal każdej standardowej dzierżawie każdy licencjonowany użytkownik domyślnie ma dostęp Maker do środowiska domyślnego. Jest ono ostatecznym cyfrowym „kuchennym zlewem”. Ludzie budują tam osobiste automatyzacje produktywności, szybkie rozwiązania typu proof of concept, powiadomienia zespołowe i eksperymentalne aplikacje, ponieważ uruchomienie ich nie wymaga żadnego nakładu pracy administracyjnej.
Niebezpieczeństwo zaczyna się wtedy, gdy te niewinne prototypy odnoszą sukces. Użytkownik buduje prosty przepływ, który synchronizuje opinie klientów z formularza do wspólnego arkusza kalkulacyjnego. Nagle zespół zaczyna z tego korzystać. Kierownictwo na tym polega. Po trzech miesiącach aplikacja typu proof of concept staje się operacyjnym narzędziem biznesowym działającym w najbardziej permisywnym środowisku dzierżawy, całkowicie odłączonym od formalnego przeglądu zarządzania cyklem życia aplikacji (ALM). Ponieważ środowisko domyślne musi pozostać szeroko dostępne, aby nie hamować podstawowej produktywności, ogólne reguły DLP stosowane tutaj często powodują ogromne szkody uboczne i tworzą grunt pod bunt użytkowników.
Dlaczego nadmierne blokowanie konektorów popycha pracowników do shadow IT
Gdy organizacje wdrażają drastyczne zasady DLP, na przykład całkowicie blokując dostęp do standardowych konektorów produktywności i komunikacji, zakładają, że powstrzymują wycieki danych. W rzeczywistości zachęcają one do zachowań, których nie widać.
Weźmy pod uwagę pracownika działu sprzedaży, który chce usprawnić cotygodniowe raportowanie, łącząc wewnętrzną listę Microsoft 365 z zewnętrznym narzędziem do zarządzania projektami lub popularną usługą przechowywania w chmurze. Jeśli firmowe środowisko Power Platform blokuje ten łącznik zewnętrzny z powodu ogólnofirmowego zakazu, pracownik staje przed wyborem: zrezygnować z automatyzacji i tracić trzy godziny tygodniowo na ręczne kopiowanie i wklejanie danych albo znaleźć inny sposób.
Jaki to inny sposób? Pracownik zakłada osobiste lub nieautoryzowane konto w oprogramowaniu jako usłudze (SaaS), używając firmowego adresu e-mail, eksportuje dane poza bezpieczny perymetr i buduje integrację bezpośrednio w niemonitorowanym zewnętrznym narzędziu. Może też napisać lokalne skrypty, korzystając z surowych tokenów API przechowywanych w niezabezpieczonych plikach tekstowych. Nadmiernie blokując natywne, audytowalne łączniki w firmowym ekosystemie, dział IT nie chroni danych, lecz skutecznie wypycha je poza platformę, gdzie nie ma rejestrowania zdarzeń, monitoringu ani nadzoru nad zarządzaniem.
Niebezpieczeństwo myślenia w kategoriach wewnętrznych i zewnętrznych
Kolejną poważną wadą architektoniczną, na jaką natrafiamy podczas przeglądów dzierżaw, jest poleganie na tradycyjnym modelu bezpieczeństwa opartym na podziale na „wewnętrzne” i „zewnętrzne”. Historycznie zespoły bezpieczeństwa traktowały wszystko wewnątrz granic dzierżawy firmowej jako z założenia bezpieczne, a wszystko poza nią jako z założenia ryzykowne.
We współczesnych hybrydowych modelach biznesowych ta granica traci całkowicie znaczenie. Wraz z podwykonawcami, zewnętrznymi partnerami agencyjnymi, przejętymi spółkami zależnymi i zautomatyzowanymi procesami business-to-business, użytkownicy „wewnętrzni” regularnie obsługują wrażliwą własność intelektualną. Z kolei działy często muszą bezpiecznie współpracować z usługami zewnętrznymi w ramach codziennej pracy. Traktowanie wszystkich wewnętrznych twórców i wszystkich wewnętrznych środowisk jako równie godnych zaufania prowadzi do katastrofalnego, strukturalnego nadmiernego udostępniania. Gdy blokuje się uzasadnione łączniki zewnętrzne, a wewnętrzne udostępnianie pozostawia się szeroko otwarte, powstaje środowisko sprzyjające przypadkowemu ujawnieniu danych, w którym do poważnego incydentu bezpieczeństwa nie jest nawet potrzebny złośliwy zamiar.
Trzy filary: strategia środowisk, strategia łączników i filozofia udostępniania
Rozwiązanie pułapki shadow IT wymaga spojrzenia na zarządzanie nie jako na zbiór odrębnych reguł, lecz jako na powiązany ekosystem. Jak szczegółowo opisujemy w naszych podstawowych ramach zarządzania, trzy filary muszą działać razem:
1. Strategia środowisk
Przestań traktować domyślne środowisko jako przestrzeń produkcyjną. Ogranicz je, monitoruj i ogranicz jego możliwości. Wdróż jasną ścieżkę, dzięki której twórcy będą mogli zamówić dedykowane środowiska deweloperskie, testowe i produkcyjne z odpowiednimi limitami zasobów i zautomatyzowanym udostępnianiem.
2. Strategia łączników
Odejdź od generalnych zakazów. Zamiast blokować łączniki wyłącznie dlatego, że są „zewnętrzne”, klasyfikuj je według rzeczywistych profili ryzyka, klasyfikacji danych i uzasadnienia biznesowego. Wykorzystaj zasady DLP na poziomie dzierżawy i środowiska, aby umożliwić kontrolowane korzystanie tam, gdzie jest to uzasadnione, i połącz je z rygorystycznym audytem.
3. Filozofia udostępniania
Przejdź od otwartego modelu udostępniania do podejścia opartego na najmniejszych potrzebnych uprawnieniach. Regularnie sprawdzaj, kto ma dostęp do aplikacji i przepływów, i wdrażaj zabezpieczenia, które domyślnie zapobiegają szerokiemu udostępnianiu w całej dzierżawie, zwłaszcza w warstwach nieprodukcyjnych.
Co istotne, to nie są trzy odrębne decyzje. Tworzą jeden spójny system. Jeśli strategia środowisk jest mocna, ale strategia łączników jest zbyt restrykcyjna, użytkownicy uciekną do shadow IT. Jeśli filozofia udostępniania jest słaba, nawet najlepsza strategia łączników nie zapobiegnie strukturalnemu wyciekowi danych.
Przejście od statycznego do adaptacyjnego DLP
Statyczne DLP, czyli reguła stosowana globalnie w całej dzierżawie i pozostawiana bez zmian przez lata, szybko staje się przestarzałe. Nowoczesne organizacje potrzebują adaptacyjnego DLP. Adaptacyjne zasady dynamicznie dostosowują się do tożsamości użytkownika, zgodności urządzenia, klasyfikacji środowiska i etykiet poufności danych.
Wyobraźmy sobie sytuację, w której standardowy twórca w domyślnym środowisku ma ograniczony dostęp do łączników, a zweryfikowany członek wyspecjalizowanego środowiska deweloperskiego, działającego pod ściślejszym monitoringiem i według surowszych standardów klasyfikacji danych, ma dostęp do rozszerzonych możliwości integracji. Dopasowując zasady do kontekstu zamiast stosować tępe narzędzie w każdym przypadku, dział IT może wspierać uzasadnione innowacje, zachowując przy tym solidne granice bezpieczeństwa.
Podsumowanie: jak połączyć zasady z produktywnością
Governance nie polega na mówieniu „nie” organizacji; chodzi o stworzenie bezpiecznych pasów ruchu, dzięki którym użytkownicy mogą działać szybko, nie powodując przy tym awarii. Gdy zespoły IT z obawy polegają na nadmiernym blokowaniu konektorów i restrykcyjnych zasadach, same nieumyślnie tworzą dokładnie te zagrożenia związane z shadow IT, którym mają zapobiegać. Dopracowując strategię środowisk, stosując zniuansowaną politykę konektorów i modernizując podejście do udostępniania, możesz zbudować odporną architekturę Power Platform, w której użytkownicy naprawdę chcą pozostawać.
Jeśli jesteś gotowy, by przestać walczyć ze swoimi użytkownikami i zacząć dopasowywać ramy governance do rzeczywistej produktywności biznesowej, koniecznie sięgnij po nasz towarzyszący przewodnik audio. Posłuchaj pełnej dyskusji i poznaj wszystkie wewnętrzne strategie, odwiedzając stronę Strengthen Power Platform DLP and Default Environment Governance. Daj znać, jak Twoja organizacja równoważy udostępnianie możliwości użytkownikom z rygorystycznymi kontrolami bezpieczeństwa w Twojej własnej dzierżawie!