Rejestr aplikacji SaaS

czym jest

Rejestr aplikacji SaaS to na bieżąco aktualizowany zapis każdego narzędzia SaaS, które organizacja faktycznie używa. Każdy wpis zawiera informacje potrzebne do odpowiedzialnego zarządzania narzędziem: nazwę aplikacji i dostawcę, właściciela lub zespół odpowiedzialny za nią, główną funkcję, jaką pełni, rodzaje przetwarzanych danych, czy istnieje DPA (Data Processing Agreement), gdzie geograficznie przechowywane są dane i jakie certyfikaty bezpieczeństwa ma dostawca.

Rejestr to fundament bezpieczeństwa i zarządzania SaaS. Przeglądy dostępów, procesy offboardingu, zarządzanie wydatkami i oceny dostawców zależą od tego, żeby w ogóle wiedzieć, jakie aplikacje istnieją. Bez rejestru wszystkie te procesy działają tylko na fragmencie rzeczywistego środowiska.

Rejestr wymaga stałej pielęgnacji: dopisywania nowych narzędzi, aktualizacji przy zmianie dostawców i usuwania wpisów po wycofaniu narzędzia. Jego wartość jest proporcjonalna do tego, jak bardzo jest aktualny.

dlaczego narasta

Brak rejestru aplikacji sam w sobie jest formą narastania problemu. Organizacje, które go nie zbudowały, mają zwykle lukę, która rośnie z każdym kolejnym wdrożonym narzędziem.

Odpowiedzialność jest niejasna. Żaden zespół nie jest właścicielem spisu aplikacji. IT śledzi to, co przeszło przez proces zatwierdzania. Finanse śledzą subskrypcje opłacane centralnie. Operacje widzą to, co pojawia się w systemie zarządzania urządzeniami końcowymi. Żadna z tych list nie jest kompletna, a rzadko są ze sobą uzgadniane.

Wdrażanie wyprzedza dokumentowanie. Nowe narzędzia pojawiają się w takim tempie, że prowadzenie zapisów wydaje się zbędnym obciążeniem. Narzędzie zostaje zainstalowane, praca się zaczyna, a krok z dokumentacją nigdy nie następuje. Narzędzie istnieje w środowisku, ale w żadnym rejestrze.

Luka staje się widoczna dopiero przy pierwszym audycie. Organizacje często odkrywają prawdziwą skalę swojego środowiska SaaS podczas audytu bezpieczeństwa albo procesu due diligence klienta. Audytor prosi o listę procesorów danych. Organizacja podaje to, o czym wie. Audytor znajduje luki. I dopiero wtedy, pod presją, zaczyna się projekt budowy rejestru.

co to kosztuje

Niezaliczony audyt. Artykuł 30 RODO wymaga od organizacji prowadzenia rejestru czynności przetwarzania, w tym przepływów danych do procesorów. Aplikacja SaaS, która przetwarza dane osobowe w twoim imieniu, jest procesorem. Bez rejestru twój rejestr czynności przetwarzania jest niekompletny. Audytorzy to sprawdzają.

Niepełne pokrycie umowami DPA. Nie możesz mieć DPA z dostawcą, o którego istnieniu nie wiesz. W audycie RODO albo w dochodzeniu po naruszeniu pytanie, którzy dostawcy mieli podpisaną umowę, a którzy mieli twoje dane bez niej, ma konsekwencje prawne.

Luki w ocenie bezpieczeństwa. Zarówno ISO 27001, jak i SOC 2 wymagają kontroli zarządzania dostawcami. Oceny bezpieczeństwa dostawców, wymagania dotyczące kontroli dostępu i przeglądy obchodzenia się z danymi obejmują dostawców z twojego spisu. Dostawcy spoza spisu są poza twoimi kontrolami. Po prostu nikt nimi nie zarządza.

Ankiety dużych klientów enterprise. Duzi klienci enterprise coraz częściej wpisują w oceny bezpieczeństwa szczegółowe pytania o dostawców i procesorów danych, jako część procesu zakupowego. „Kim są wasi dostawcy SaaS? Jakie dane przetwarzają? Jakie umowy nimi rządzą?" Niepełne odpowiedzi opóźniają lub blokują transakcje.

Ocena zasięgu naruszenia. Gdy u dostawcy dochodzi do incydentu bezpieczeństwa, pierwsze pytanie brzmi: które z waszych danych były w jego systemie i kogo trzeba powiadomić. Bez rejestru, który pokazuje, jakie dane przetwarza każdy dostawca, oszacowanie skali szkody jest powolne i niepewne.

co działa

Żaden pojedynczy system nie ma pełnego obrazu, więc wiarygodny rejestr zaczyna się od uzgadniania danych z różnych źródeł. Uprawnienia OAuth z IdP, cykliczne opłaty SaaS z systemu finansowego, lista zainstalowanych aplikacji z MDM i historia zgłoszeń IT to cząstkowe spisy, każdy z innymi lukami; połączone dają listę startową pełniejszą niż jakiekolwiek pojedyncze źródło. Reszta, głównie shadow SaaS wdrożone bez udziału IT, wychodzi na jaw dzięki krótkiej, bezpośredniej ankiecie wśród liderów zespołów o to, czego ich ludzie faktycznie używają na co dzień.

Minimalny działający rejestr jest lepszy niż ambitny, który nigdy nie powstanie. Pola, które robią robotę, to nazwa aplikacji, dostawca, właściciel, główna funkcja, rodzaje przetwarzanych danych i to, czy istnieje DPA. Arkusz kalkulacyjny spokojnie to udźwignie przy małej i średniej skali, a kompletność liczy się dużo bardziej niż zaawansowanie narzędzia, w którym rejestr trzymasz; geografia przechowywania danych i certyfikaty dostawców mogą dołączyć później, bez blokowania startu.

Rejestr najszybciej zwraca się na kolumnie z DPA. Każda aplikacja, która przetwarza dane osobowe bez umowy, to otwarta sprawa RODO, a większość dużych dostawców SaaS ma gotowe standardowe DPA do podpisania, więc zamykanie tych luk to głównie formalność, gdy tylko staną się widoczne.

Rejestry umierają od nieaktualności, nie od złego projektu, dlatego reguła utrzymania jest ważniejsza niż format: nowe narzędzie dostaje wpis w rejestrze, zanim subskrypcja zostanie zatwierdzona, a kwartalny przegląd wyłapuje wdrożenia, które się prześlizgnęły. Organizacje bez takiej reguły zwykle odkrywają prawdziwą skalę swojego środowiska podczas audytu bezpieczeństwa albo przeglądu due diligence klienta, czyli w najdroższym możliwym momencie na budowanie spisu.