(ESTIMATION TIME: 11 MINUTES)
W moim poprzednim artykule przybliżyłem Ci głównych odbiorców PowerApps i Microsoft Flow. W części trzeciej przyjrzę się bliżej kwestiom zarządzania bezpieczeństwem w PowerPlatform. I tak jak obiecywałem od początku: będzie szczerze. Dowiesz się o ode mnie o rzeczach o których nie wyczytasz w dokumentacji i które podkreślą kiedy należy przyłożyć szczególną uwagę w kwestiach bezpieczeństwa pracując z PowerPlatform
Disclaimer
Kiedy rozpoczynałem pracę nad tą częścią chciałem poruszyć tylko kwestie związane z bezpieczeństwem PowerApps i Flow. Z czasem okazało się, że opisując bezpieczeństwo małego fragmentu usługi (np konektorów) bardzo łatwo nieopatrznie poruszyć kilka wątków z których każdy wypadałoby troszkę szerzej omówić (np czy komunikacja zabezpieczona OAUTH2 jest bezpieczna? Czy publiczna dostępność naszych usług i chmura to dobry pomysł?). No i nie wspomnę, że możliowści zabezpieczania są zależne od licencji. Jednak Zdałem sobie w końcu sprawę (przyznaję, trochę za późno stąd też ten wpis pojawił się z drobnym poślizgiem), że aby ten artykuł nie zamienił się w książkę, to należy go solidnie zredukować. W związku z tym podjąłem decyzję, że należy pozostać tylko przy kwestiach dotyczących stricte PowerPlatform. Jeśli jakaś kwestia wydaje Ci się, że mogłaby się pojawić, a nie ma, to zapewne masz rację. Była to jednak świadoma i konieczna decyzja. Ale jeśli uważasz, że jakąś kwestię warto byłoby omówić szerzej, to daj znać w komentarzu – na pewno odpowiem. Jeśli natomiast interesowałby Cię pełny obrazek security, to polecam obserwować osoby takie jak Tomasz Onyszko czy Kamil Bączyk, które w obszarze security znają się jak mało kto.
Security by Design
Wracając do meritum. Powód dla którego zająłem się tym tematem jest prosty: w IT kładzie sie duży nacisk na bezpieczeństwo. A powód jest bardzo prosty: nieautoryzowany dostęp do danych może przynieść ogromne straty majątkowe. Żeby nie szukać daleko w 2016 roku wyszło na jaw, że z popularnego (wtedy) serwisu Yahoo wyciekły informacje dotyczące łącznie ok. 3 mld użytkowników. To spowodowało straty w wysokości 50mln dolarów z tytułu odszkodowania, o 350mln dolarów niższą kwotę przejęcia Yahoo przez Verizon oraz ekstra 35mln dolarów za przeciąganie zamknięcia sprawy wycieku danych. Łącznie 435mln dolarów straty. Ale to nie koniec problemów, bo wartość firmy, to nie tylko twarda waluta. To także klienci czyli użytkownicy. Na ich zaufanie pracuje się latami, a stracić je można w chwilę. Odrobienie takiej straty jest bardzo trudne i bardzo kosztowne.
Zaufanie to waluta przyszłości
I dlatego właśnie inżynierowie IT stawiają bezpieczeństwo na pierwszym miejscu. Microsoft mówi nawet, że swoje usługi projektuje tak by wpierw były bezpieczne, a potem dopiero myśli o całej reszcie: tzw. Security-by-design. Pytania, które pojawiły się w pierwszej części niniejszej serii wpisów są żywym przykładem dociekliwości jaką przykładają inżynierowie, kiedy w grę wchodzi bezpieczeństwo i zarządzanie nim, bo są oni świadomi możliwych konsekwencji.
Bezpieczeństwo oraz zarządzanie w PowerApps i Flow
Bezpieczeństwo i tzw. Governance rozwiązań opartych o PowerPlatform rozbić można na kilka podpunktów:
- Licenses
- Connectors
- User Context
- App sharing & versioning
- Environments & Data Policies
Poniżej opiszę po krótce na czym polega dana forma zabezpieczenia oraz na co należy uważać przy jej stosowaniu. Ponieważ jednak chciałbym możliwie nie wchodzić w niuanse techniczne, to będę odsyłał do obszerniejszych źródeł.
Licenses
Licencje to sposób na przypisanie uprawnień użytkownikowi do jakiejkolwiek pracy z daną platformą. W panelu administracyjnym Office365, jeśli tylko posiadamy odpowiednie uprawnienia, możemy w prosty przydzielić bądź zabrać użytkownikowi licencje do produktu bądź aplikacji.
Na co uważać
Licencje określają ogólny dostęp do aplikacji, ale nie definiują poziomu uprawnień (read-only, edit, delete itd). Przydzielając komuś licencje pamiętaj aby zadbać o odpowiedni poziom uprawnień w samej aplikacji (usłudze).
Connectors
Tak jak opisywałem w drugiej części tej serii idea konektorów, to jeden z fundamentów PowerPlatform. Użytkownicy PowerPlatform mają dostęp do ponad 200 konektorów. A gdyby to było za mało, to mogą zbudować własny konektor lub użyć konektorów HTTP do połączenia się z dowolnym serwisem wspierającym REST/GRAPH API
Korzystanie z takich konektorów jest bardzo proste i łatwo dostępne. Po wybraniu dowolnego konektora użytkownik uzyska dostęp do jego metod. Oczywiście tylko do tych które zaimplementował dostawca. Natomiast dostawca ma obowiązek zadbać aby konektor zapewniał odpowiednią jakość bezpieczeństwa (uwierzytelnianie), wsparcia i SLA. Co ważne dostawca musi także udowodnić, że ma prawa własności do serwisu z którym łączy się opublikowany konektor. Dzięki temu nie będzie sytuacji w której nagle firmy trzecie zaczną robić wyścigi o miano najlepszego dostawcy konektorów produkując 10tki takich samych połączeń zaśmiecając tym samym kolekcję konektorów.
NA CO UWAŻAĆ
Konektory w głowach wielu rodzi pytanie czy poza tym, że łatwe, to są one także bezpieczne? Przy czym bezpieczne może oznaczać bardzo wiele:
- Dane przesyłane za ich pomocą nie zostaną przechwycone i zmienione po drodze?
- Czy dane dotrą tam, gdzie chcemy aby trafiły?
- W jaki sposób kontrolować z którego konektora może korzystać dany użytkownik?
- Gdzie znaleźć logi wywołań danego konektora?
Przede wszystkim z całą pewnością komunikacja z wykorzystaniem konektorów jest bezpieczna. W tym celu Microsoft wymusza korzystanie sprawdzonych standardów do zabezpieczenia przesyłu danych.
Jednakże na chwilę obecną konektory posiadają skromną warstwę zarządzania uprawnieniami do nich i odkładania logów. Np możemy zdefiniować kto może tworzyć aplikacje (i tym samym korzystać z konektorów), ale nie możemy już zdefiniować kto jakie konektory może wykorzystywać. Podobnie nie znajdziemy opcji by dla konektorów HTTP zdefiniować whiteliste URLi czy wydobyć logi zawierające URLem oraz body wykonanych połączeń.
Komunikacja z wykorzystaniem konektorów jest bezpieczna, ale ich governance jest jeszcze skromny
User Context
W zasadzie ten temat pasuje do poprzedniego fragmentu o konektorach, ale chciałbym aby dobrze wybrzmiał – użytkownik pracując z konektorami działa WYŁĄCZNIE we własnych kontekście. Innymi słowy pracując np z PowerApps powinieneś myśleć jak o widoku danych do których użytkownik ma dostęp. Jeśli do czegoś mieć nie powinien lub aplikacja miałaby zadziałać w kontekście konta o wyższych uprawnieniach, to nie polecam realizować tego za pomocą PowerApps.
Jednak teoria, to tylko teoria. W życiu jak bywa każdy wie. Sam widziałem różne podejścia w IT. I nie dziwią mnie już poważne i duże firmy, które jako bazę danych używały zwykłego pliku excel. Bo na koniec dnia liczy się efekt (czyt: pieniądz), a nie best practices i bezpieczna architektura (nią przejmujemy się dopiero wtedy gdy zaczyna zagrażać “efektowi” 😉 ). Tak więc czasem zdarza się, że:
- możesz potrzebować zrealizować operację na wyższych uprawnieniach. Wtedy do tego celu możesz zastosować sztuczkę z Flow o której pisałem w tym artykule.
- na podstawie grupy O365 do której przynależy użytkownik chcesz ograniczyć mu widoczność pewnych kontrolek na ekranie. Wtedy możesz skorzystać z konektora Office365 groups dostępnego w PowerApps. W przypadku ograniczenia widoku na podstawie grupy SharePoint sprawa nieco się komplikuje, ale z pomocą Flow i Graph API jest do zrobienia.
Jeśli użyjesz PowerApps do kontroli dostępu (np poprzez warunkowe ukrycie kontrolek), to pamiętaj, że użytkownik dalej będzie miał dostęp do danych w źródle (np na liście SharePoint)
Na co uważać:
Niektóre konektory nie wykorzystują kontekstu użytkownika i wymagają podania konta serwisowego – takim przykładem jest np SQL connector. Wówczas przy korzystaniu z aplikacji kontekst użytkownika nie jest brany pod uwagę. Połączenie działa w ramach kontekstu podanego konta serwisowego. To oznacza, że gdyby użytkownik miał dodatkowo możliwość tworzenia aplikacji, to mógłby z pomocą konektora dostać się do każdej tablicy czy widoku do której ma dostęp konto serwisowe(!). Warto o tym pamiętać. Ale jest na to sposób pokazany przez guru PowerApps – Shane Young. Sposób ten wykorzystuje dodatkowe środowisko (tzw. environment) oraz odpowiednie uprawnienia na nim. Więcej w filmie poniżej:
App sharing & versioning
Dla każdej aplikacji można zdefiniować użytkowników mogących jej używać jak i ją edytować.
Na powyższym obrazku zwróć uwagę na informację przy checkboxie Co-owner: nawet jeśli dodamy użytkownika jako co-ownera, to nie będzie on mógł usunąć aplikacji bądź zmienić ownera.
Przy tej okazji możemy zaobserwować jeszcze jedną ciekawą rzecz – konektor CDS posiada dodatkową opcję zarządzania rolami:
CDS posiada dodatkowy model uprawnień (security roles) . Tylko CDS.
Każda aplikacja poza opcją udostępniania posiada również mechanizm wersjonowania.
Każdorazowe zapisanie aplikacji zostawi w repozytorium oddzielny wpis. Dzięki temu w każdym momencie możemy cofnąć się do dowolnej wersji. Dodatkowo wersja dostępna publicznie dla wszystkich jest oznaczona odpowiednią etykietą. Tak więc mechanizm wersjonowania pozwala spać spokojnie, że jeśli któryś z Co-ownerów popsuje w aplikacji, to wszystko będzie do odratowania.
Na co uważać
Jak już pisałem co-ownerzy nie mogą usuwać aplikacji PowerApps – może to zrobić tylko owner. Ale jeśli już to zrobi, to NIE MA sposobu na odwrócenie tego. Tak więc warto co jakiś czas robić export swojej aplikacji w bezpieczne miejsce.
Rób eksport kolejnych pełnych wersji swoich aplikacji. Jeśli kiedyś z jakiegoś powodu je stracisz, to wyeksportowane paczki będą Twoją ostatnią deską ratunku.
Environments & Data Policies
Środowiska, to specjalne kontenery na aplikacje i konektory w ramach tenanta. Tenant może posiadać wiele środowisk, a każde środowisko może zawierać mnóstwo aplikacji i konektorów. Co ważne środowiska nie współdzielą między sobą swojej zawartości, a co więcej każde z nich może posiadać unikalną definicję makerów i userów. Userzy mogą korzystać z zawartości środowiska. Makerzy mogą w nim tworzyć własne apki. Łatwo więc wyobrazić sobie przykładową architekturę środowisk w organizacji: produkcja, test i development.
Oprócz uprawnień na środowisku można jeszcze zdefiniować Data Policies czyli specjalne reguły mówiące o tym które konektory mogą współdzielić między sobą informację.
Dla powyższego przykładu w żadnej aplikacji PowerApps czy Flow nie może pojawić któryś z konektorów grupy “Business data only” i jednocześnie konektor z grupy “No business data allowed”. Gdy tak się stanie zobaczymy błąd podczas próby dodania niedozwolonego konektora
Co ważne – utworzona polityka działa natychmiastowo na wszystkich aplikacjach. Tam, gdzie znajdują niedozwolone konektory po prostu przestają one zwracać dane. W przypadku Flow flowy zostaną wyłączone.
Środowiska to kontenery na aplikacje i konektory w organizacji. Minimalny zalecany zestaw środowisk to Produkcyjne i Testowe.
Na co uważać
Podobnie jak w przypadku konektorów governance środowisk i polityk jest jeszcze skromny. A czasem przydałoby móc wykluczyć pewne konektory zupełnie z użycia lub chociaż ograniczyć osoby mogące z nich korzystać. Bo sam podział na business data i non-business data wcale nie chroni organizacji przed tym aby ktoś zbudował sobie 2 apki i połączył je np plikiem excel. Więc jeśli przykładasz najwyższą ostrożność do bezpieczeństwa danych, może jeszcze daj chwilę na usprawnienie w/w narzędzi. Jak obserwuję poczynania Microsoftu, to jest kwestią czasu, kiedy narzędzia do governance i security zostaną upsrawnione.
Skoro więc przy każdej z powyższych opcji istnieje jakieś niebezpieczeństwo na które należy uważać, to czy jest sens już teraz wykorzystywać PowerApps i Flow?
PowerPlatform to nie jest lekarstwo na wszystko
Jeśli czytałeś mój poprzedni wpis, to wiesz, że PowerApps i Flow nie mają zastąpić 100% rozwiązań. Mają zastąpić 80% tych małych i prostych aplikacji, które przyspieszają codzienną pracę, a jednocześnie oszczędzają czasu i energię programistom. Dzięki temu mogą się oni zająć trudniejszymi przypadkami aniżeli setna implementacja listy zadań. Bo i tak znając życie to nie będzie standardowa implementacja. Tym razem wymagania utrudni np ktoś z marketingu kto wymyśli sobie, że chce mieć integrację z tym serwisem którego developer odszedł właśnie z firmy i trzeba się bedzie wpierw nauczyć tego serwisu. Czyli jakiś miesiąc pracy…o ile wycena nie zostanie podniesiona dwókrotnie by za klawiaturą posadzić interna. A potem będą już tylko jęki, szok i niedowierzanie, że prosta aplikacja do organizowania spotkań zajęła 3 razy tyle i kosztowała 5x więcej niż początkowo zakładano (intern robi błędy, błędy trzeba poprawić).
sztuka wyboru
W rozwiązaniach budowanych w oparciu o platformy low-code chodzi więc o wiedzę, znajomość możliwości różnych gotowych usług (nie tylko Microsoft), rozumienie ich elastyczności oraz przede wszystkim rozumienie biznesu. I parafrazując słynny żart (wybierz 2 z 3ech: szybko, tanio, dobrze), projekty w firmie operujące na styku biznesu i IT chciałbyś aby wykonała osoba która:
- Dobrze rozumie biznes
- Posiada rozeznanie narzędziowe
- Posiada specjalistyczne umiejętności techniczne
Wybierz 2 z powyższych.
Sztuka Kompromisu
PowerApps i Microsoft Flow to lewar, ktory nie daje userowi wiecej niz on sam by mogl, ale pozwala mu zrobic pewne rzeczy prościej i na wieksza skale. To oczywiscie jest pewien kompromis miedzy usprawnianiem pracy a konfigurowalnością. Między zaufaniem a kontrolą. Ale to chyba fundamentalny trend w IT(?). Gdyby tak nie było, to nadal byśmy pisali w assemblerze i nie tworzylibyśmy języków pozwalających pisać szybciej i łatwiej, frameworków realizujących złożone operacje za pomocą jednej metody i nie budowalibyśmy rozwiązań Open Source. Zapotrzebowanie na programistów nie maleje, więc buduje się rozwiązania możliwie proste do zaadoptowania przez nowych adeptów. Chodzi o to aby programistow moglo byc wiecej (tym samym tworząc naturalne rozwarstwienie) a oni sami odciążeni od prostych zadań (szczególnie, gdy może to wykonać ktoś inny równie szybko i wcale nie gorzej).
Podsumowując
PowerPlatform daje pewne mechanizmy kontroli i bezpieczeństwa informacji. Póki co jeszcze skromne, z czasem z pewnością zostaną rozwinięte. Ale wątpię by osiągnęły one poziom konfigurowalności i kontroli jaki daje nam napisana wewnętrznie aplikacja .NET osadzona na IIS zainstalowanym na naszym serwerze on-prem. Jednak wydaje mi się, że PowerApps i Flow nie pretendują do takiego miana. To ma być szybki zwinny samochód do poruszania się po mieście (że tak pozwolę sobie na porównanie). A jeśli chcesz jechać na wojne, to weź czołg.
