Bezpieczeństwo aplikacji low-code buduje się w stałej kolejności: najpierw inwentarz z imiennym właścicielem aplikacji, potem rozstrzygnięcie, co zabezpiecza platforma, a co organizacja, potem polityki DLP na konektorach, na końcu kontrole aplikacyjne i przegląd uprawnień po każdej zmianie. Ten artykuł rozpisuje każdy krok na czynności sprawdzalne.
Na skróty
Czego dowiesz się z artykułu:
- Jak zbudować inwentarz aplikacji low-code, który nie starzeje się po tygodniu
- Gdzie przebiega granica między odpowiedzialnością dostawcy platformy a Twoją
- Jak polityki DLP odcinają wypływ danych, zanim ktokolwiek napisze pierwszy ekran
- Które kontrole aplikacyjne trzeba sprawdzić samodzielnie, bo platforma ich nie zapewnia
Dla kogo jest ten artykuł:
- Administratorzy środowisk Power Platform i pokrewnych platform low-code
- Liderzy zespołów, w których aplikacje powstają poza działem IT
- Osoby odpowiadające za zgodność przetwarzania danych osobowych w firmie
Czas czytania: 7 minut
Krok pierwszy: inwentarz i imienny właściciel aplikacji
Pierwszym krokiem nie jest konfiguracja, a lista. Aplikacja low-code bez wpisu w inwentarzu nie ma właściciela, nie ma przeglądu i nie ma miejsca, w którym ktokolwiek zauważy, że od pół roku wysyła arkusz na prywatną skrzynkę. Shadow IT w low-code nie powstaje ze złej woli — powstaje dlatego, że narzędzie jest dostępne każdemu pracownikowi, a rejestr nie.
Wpis w inwentarzu, żeby był użyteczny, musi odpowiadać na cztery pytania sprawdzalne bez rozmowy z autorem: kto jest właścicielem aplikacji z imienia i nazwiska, jakie dane aplikacja odczytuje, z jakimi systemami się łączy i w którym środowisku działa. Właściciel aplikacji to nie autor — autor może odejść z firmy, właściciel jest rolą, którą przejmuje następca.
Przewodnik learn.microsoft.com o budowie Center of Excellence dla Power Platform opisuje ten zespół jako funkcję, która prowadzi inwentarz, ustala standardy i wspiera twórców aplikacji. Nazwa jest wtórna, a rozstrzygnięcie nie: w organizacji musi istnieć wskazane miejsce, które wie, ile aplikacji istnieje. Inaczej żaden kolejny krok tej checklisty nie ma zakresu.
Czynność do odhaczenia: zestaw listę aplikacji z konsoli administracyjnej platformy, nie z ankiety wśród zespołów. Ankieta pokazuje aplikacje, o których ktoś pamięta.
Krok drugi: granica odpowiedzialności platformy i organizacji
Model współdzielonej odpowiedzialności jest w low-code mylący, bo platforma faktycznie zdejmuje bardzo dużo: utrzymanie środowiska uruchomieniowego, aktualizacje, szyfrowanie składowanych danych, uwierzytelnianie użytkownika. Zostaje jednak dokładnie to, czego żaden dostawca nie może rozstrzygnąć za Ciebie — kto ma widzieć które dane i w jakim celu.
Dlatego drugim krokiem jest spisanie granicy na konkretnym przykładzie, a nie na schemacie. Bierzesz jedną aplikację i przy każdej kontroli zapisujesz, czyja ona jest: szyfrowanie w spoczynku — platforma; zakres danych zwracanych przez połączenie — autor aplikacji; nadanie uprawnienia do źródła danych — administrator środowiska; ocena podstawy prawnej przetwarzania — inspektor ochrony danych. Kontrola, przy której nie potrafisz wpisać właściciela, jest luką, nie niejasnością.
Dokument csrc.nist.gov SP 800-218 porządkuje to po stronie wytwarzania: przypisuje praktyki bezpiecznego tworzenia oprogramowania do nazwanych grup — przygotowania organizacji, ochrony wytworzonego oprogramowania, wytwarzania oprogramowania bezpiecznego z założenia i reagowania na podatności. Aplikacja low-code jest oprogramowaniem, więc te praktyki jej dotyczą; różnica jest ta, że część z nich wykonuje platforma, a nie Twój zespół. Granica przebiega wewnątrz tych grup, nie wokół nich.
Krok trzeci: polityki DLP na konektorach
To jest krok, który faktycznie zmienia zachowanie, bo działa zanim powstanie pierwszy ekran. Dokumentacja learn.microsoft.com o klasyfikacji konektorów opisuje w polityce danych grupy Business, Non-Business i Blocked, przy czym konektor może należeć tylko do jednej grupy naraz. Przewodnik tego samego źródła o zarządzaniu politykami danych nazywa skutek wprost: przeniesienie konektora do grupy biznesowej uniemożliwia tworzenie aplikacji i przepływów łączących go z konektorami z grupy pozabiznesowej albo zablokowanej.
Praktyczne następstwo jest takie, że polityka nie zakazuje narzędzi, a zakazuje mostów. Konektor do firmowej bazy i konektor do zewnętrznej usługi notatek mogą istnieć oba, ale nie w tej samej aplikacji. Właśnie tę ścieżkę wypływu danych najtrudniej wychwycić przeglądem gotowej aplikacji, bo w interfejsie wygląda jak zwykłe kopiowanie.
Czynności do odhaczenia w tym kroku: środowisko produkcyjne ma dodatkową politykę środowiskową, bo polityki na poziomie dzierżawy i tak je obejmują; konektory niestandardowe są przypisane jawnie, bo polityka ich nie klasyfikuje za Ciebie; grupa domyślna dla nowych konektorów pozostaje pozabiznesowa — dokumentacja wprost to zaleca, a konektor dodany do platformy po utworzeniu polityki wpada właśnie do niej.
Krok czwarty: kontrole aplikacyjne i przegląd uprawnień
Standard owasp.org ASVS daje listę wymagań weryfikacyjnych uporządkowaną w rozdziały — od uwierzytelniania i zarządzania sesją, przez autoryzację i walidację danych wejściowych, po logowanie i obsługę błędów. W low-code część z tych rozdziałów odhacza platforma, ale autoryzacja i walidacja danych wejściowych zostają po stronie autora aplikacji, bo wynikają z tego, co aplikacja ma robić.
W przeglądach wracają te same ustalenia. Pierwsze: aplikacja ukrywa przycisk przed użytkownikiem bez uprawnienia, ale źródło danych nadal udostępnia mu pełny zestaw rekordów — ukrycie elementu interfejsu nie jest kontrolą dostępu. Drugie: aplikacja loguje operacje do własnej tabeli, której nikt nie czyta i która sama nie ma kontroli dostępu.
Przegląd uprawnień zamyka checklistę i jest jedynym krokiem powtarzalnym. Wyzwala go zdarzenie, nie kalendarz: zmiana właściciela aplikacji, dodanie nowego źródła danych, zmiana zakresu danych w istniejącym połączeniu, odejście osoby z zespołu. Przegląd roczny w organizacji, w której aplikacje powstają w ciągu tygodnia, opisuje stan, który już nie istnieje.
Czytaj także
- Low-code / No-code — kiedy to dobry wybór dla firmy — decyzja o samej platformie, zanim zaczniesz ją zabezpieczać
- Automatyzacja procesów biznesowych bez kodu — kompletny przewodnik — co powstaje w tych aplikacjach i jakie dane przez nie płyną
- Microsoft Power Platform: Power Apps, Power Automate, Power BI — przewodnik — komponenty platformy i ich rola w architekturze
Rozwijaj kompetencje
Temat rozwijają szkolenia Low-Code/No-Code — Power Platform, Mendix, OutSystems oraz Low-Code dla biznesu — budowanie aplikacji bez kodowania. Pierwsze porównuje platformy i ich mechanizmy nadzoru, drugie pracuje na budowie aplikacji przez osoby bez doświadczenia programistycznego. Skontaktuj się z nami, żeby dopasować zakres do sytuacji w Twojej organizacji.
Najczęściej zadawane pytania (FAQ)
Czy aplikacje low-code są mniej bezpieczne od pisanych kodem?
Inaczej rozkładają ryzyko. Platforma zdejmuje całe klasy błędów implementacyjnych, bo twórca nie pisze obsługi sesji ani zapytań do bazy. W zamian rośnie ryzyko po stronie uprawnień i przepływu danych, bo aplikacje powstają szybciej, częściej i poza przeglądem działu IT. Zabezpieczenie polega więc na nadzorze nad środowiskiem, nie na przeglądzie kodu.
Od czego zacząć, gdy aplikacje już działają i nikt nie wie ile ich jest?
Od zestawienia listy z konsoli administracyjnej platformy i przypisania właściciela do każdej pozycji, nawet tymczasowo. Dopiero mając listę, warto ustawiać polityki DLP — polityka wprowadzona przed inwentarzem zablokuje działające procesy, o których nie wiedziałeś, i wdrożenie zatrzyma się na pierwszej eskalacji.
Czy polityka DLP wystarczy, żeby spełnić wymogi ochrony danych osobowych?
Nie, bo rozstrzyga o technicznej możliwości przepływu, a nie o podstawie przetwarzania. Aplikacja low-code przetwarzająca dane osobowe podlega RODO tak samo jak każdy inny system: potrzebuje udokumentowanego celu, zakresu danych i oceny po stronie inspektora ochrony danych. Polityka DLP jest środkiem technicznym, który tę ocenę wspiera, a nie zastępuje.
Kto powinien odpowiadać za bezpieczeństwo aplikacji zbudowanej przez dział biznesowy?
Właściciel aplikacji wskazany z nazwiska w inwentarzu, a nie dział IT jako całość. IT odpowiada za środowisko, polityki i standard kontroli; właściciel odpowiada za to, czy aplikacja nadal robi to, co opisuje jej wpis, i zgłasza każdą zmianę zakresu danych. Bez tej roli przegląd nie ma adresata i nie zostanie wykonany.