Salesforce już nie taki sexy jak się promuje. Więcej Klientów chce uciec niż zostać.
Power Apps Portals i wyciek danych
Wczoraj wieczorem polskiego czasu gruchnęła wiadomość, która może zatrząść postrzeganiem jednego z flagowych projektów Microsoftu – Power Apps, a dokładnie Power Apps Portals. Portals to platforma do budowania portali dla zewnętrznych Klientów i jest częścią Power Platform – technologii pozwalającej programistom, analitykom i nie-programistom na tworzenie komercyjnych rozwiązań na potrzeby swoich firm. Wyciek danych dotyczy portali i wynika z ich domyślnej konfiguracji. Dzięki zespołowi badaczy z UpGuard Research dowiedzieliśmy się, jak w kilka chwil funkcjonalność „by design” może stać się „critical security issue” i być przyczyną wycieku wrażliwych danych.
(źródło: https://www.upguard.com/breaches/power-apps)
Ale o co właściwie chodzi? Cóż, wypłynęły dane ponad 38 milionów rekordów z portali budowanych właśnie w Power Apps Portals. Wyciek danych dotyczy głównie Klientów w USA, ale ryzyko jest globalne.
Co jest przyczyną wycieku danych?
Cały problem wynika z braku kompetencji i umiejętności osób budujących portale na Power Apps Portals. Głównie braku zrozumienia jak działają tzw. OData feeds, które pozwalają na udostępnienie części danych gromadzonych w Power Platform (dokładnie Dataverse) za pomocą OData API. Chodzi o udostępnianie danych do zewnętrznych aplikacji. Feed domyślnie pozwalał na anonimowy dostęp do danych, wyłączając całkowicie model zabezpieczeń po stronie Dataverse / CDS / Power Platform. To ma sens, jeśli pomyślimy na przykład o rządowych instytucjach w stylu GUS czy CEiDG, które upubliczniają odpowiednio dane statystyczne i dane o przedsiębiorstwach każdemu chętnemu, a to tej klasy rządowe (federalne czy stanowe) instytucje używały portali opartych o Power Apps Portals.
Dokumentacja na stronach Microsoftu jasno mówiła o ryzyku anonimowego dostępu do danych, więc gdzie leży problem? Czy ktoś nie zapoznał się lub nie zrozumiał dokumentacji? Może gdyby powierzyć zadanie programistom nie doszłoby do masowego wycieku? Czy w sytuacji, gdy informacja była dostępna w dokumentacji, Microsoft jest winien wyciekowi?
Problemem było to, że domyślnie feed włączał się z dostępem anonimowym i należało wiedzieć i mieć doświadczenie, żeby skonfigurować dostępy ręcznie, czego spora część firm po prostu nie zrobiła.
Kto zawinił? Czy to atak hakerski?
Kto więc zawinił? Naszym zdaniem to głównie wina ludzi tworzących rozwiązania i ich ignorancji. Nie należy jednak przechodzić wokół tego wydarzenia obojętnie w kontekście winy samego Microsoftu – jednak wcale nie dlatego, że stworzył złą platformę, a dlatego, że do Microsoft usilnie twierdzi we własnym marketingu, że wdrożenia takich portali mogą robić tzw. citizen developers, czyli konsultanci bez doświadczenia technicznego. Dodatkowo, ustawianie niebezpiecznych konfiguracji jako domyślnych na platformie skierowanej przede wszystkim dla citizen developerów to proszenie się o kłopoty.
Przyczyną wycieku danych z Power Apps Portals nie jest błąd platformy, ani atak hakerski. Jest nią odpowiednik pozostawienia hasła „admin” w ruterach używanych na całym świecie, czyli po prostu pozostawienie domyślnej konfiguracji w realnym, produkcyjnym wdrożeniu.
Jako partner Microsoft w jednym z dużych międzynarodowych projektów, już w marcu 2021 pisaliśmy do Microsoft i podwykonawców Microsoft, że używanie portali w podobnym wdrożeniu grozi problemami z wydajnością, bezpieczeństwem i jakością danych z uwagi na wiele ustawień Power Apps Portals, które pomijane są we wdrożeniach robionych przez ludzi bez doświadczenia w Dataverse. Jak można się domyślać, Microsoft Services ma jednak swoją wizję rozwoju takich projektów i pozostał tylko nasz email i uczucie w rodzaju „We told you so…„.
Szczegóły techniczne – jak się zabezpieczyć?
Jeszcze do niedawna po włączeniu OData API, API pobierało dane z list, które są Power Apps’owym kontenerem używanym do udostępniania rekordów do wyświetlania w portalach. Listy pobierają dane z tabel z Dataverse w którym zaszyta jest cała warstwa bezpieczeństwa dostępu do danych. Widać więc, że wyciągnięcie danych z Dataverse odbywa się na poprawnych uprawnieniach i jest dystrybuowane dalej bez wbudowanej kontroli. Żeby zabezpieczyć listy, należało skonfigurować Table Permissions, a na koniec włączyć je za pomocą dodatkowego parametru na liście. Inaczej cała komunikacja z API mogła odbywać się anonimowo. Co gorsze, ustawienie to nie działało dla niestandardowych tabel, czyli dla większości dostosowywanych elementów systemu. Wczoraj, po upublicznieniu wycieku przez ekspertów UpGuard Microsoft przygotował łatkę, która będzie umożliwiać zmianę parametrów.
Dodatkowo, zachęcamy również do sprawdzenia, które listy mają włączone anonimowe udostępnianie i wyłączony Table Permissions. W tym celu możemy użyc narzędzia Portal Checker, które Microsoft udostępnia w Power Platform. Więcej o krokach wymaganych przy sprawdzaniu portali znajduje się w dokumentacji Microsoft, która… jest dostępna od dawna, ale „citizen developerzy” rzadko zadają sobie trud jej rozumienia (jak widać po kwiatniowym i majowym wycieku danych):
https://docs.microsoft.com/en-us/powerapps/maker/portals/admin/portal-checker-analysis
Podsumowanie
Netwise jest kluczowym i największym partnerem Microsoft zajmującym się wdrożeniami Dynamics 365 i Power Platform w Polsce. Robimy to od 2008 roku. Mimo kilkudziesięciu wdrożeń portali biznesowych i portali B2B opartych o Dynamics nigdy nie zdecydowaliśmy się na wdrożenie Power Apps Portals i aktywnie odradzamy Klientom ich stosowanie w scenariuszach innych niż prototypowanie testowych rozwiązań. Nie dlatego, że portale są złe i nie działają. Ale dlatego, że Microsoft zachęca wręcz do używania i konfiguracji portali przez nie-programistów, którzy nie mają często wiedzy o „platformie pod spodem”. A ta platforma „pod spodem” istnieje od 2002 roku. Aktualny wyciek danych to nie wynik błędów w Power Platform, ani ataków hakerskich! To wynik braku wiedzy osób konfigurujących rozwiązania oparte o Power Apps Portals o sposobie działania Power Platform i Dataverse, a także całego modelu uprawnień, który w Dynamics 365 istnieje od 19 lat.
Artykuł przygotowany w oparciu o stan wiedzy na dzień 24.08.2021.
Autorzy:
Piotr Kerner, Solution Architect
Jakub Skałbania, Principal Consultant