Na spotkaniach wdrożeniowych to pytanie pada zawsze, zwykle od osoby odpowiedzialnej za bezpieczeństwo: „czy nasze dane wyjdą na zewnątrz i czy ktoś na nich nauczy swojego modelu?”.
Odpowiedź nie brzmi „tak” ani „nie”. Zależy od czterech decyzji, które podejmuje się na etapie projektu - i które łatwo przeoczyć, bo żadna z nich nie wygląda na decyzję o bezpieczeństwie.
Decyzja 1: gdzie stoi model
Trzy warianty, w kolejności od najmniejszej do największej kontroli:
Model publiczny przez API. Dane wychodzą do dostawcy. Umowy biznesowe zwykle wykluczają wykorzystanie ich do trenowania, ale wychodzą - i to jest fakt, który trzeba nazwać wprost w analizie ryzyka.
Model w chmurze prywatnej. Instancja przypisana do Twojej organizacji, w wybranym regionie. Dane nie mieszają się z ruchem innych klientów.
Model na własnej infrastrukturze. Nic nie opuszcza Twojej serwerowni. Najwyższa kontrola i najwyższy koszt - ktoś musi to utrzymywać i aktualizować.
Nie ma tu jednej dobrej odpowiedzi. Jest odpowiedź dopasowana do tego, jakie dane faktycznie przechodzą przez proces.
Decyzja 2: co w ogóle wysyłasz
To pytanie zadaje się o wiele rzadziej niż poprzednie, a ma większy wpływ na ryzyko.
Bardzo często do modelu leci cały dokument, choć do wykonania zadania potrzebne są trzy pola. Klasyczny przykład: żeby zakwalifikować zapytanie ofertowe, model nie potrzebuje nazwiska, adresu ani numeru telefonu osoby, która je wysłała. Potrzebuje treści zapytania.
Minimalizacja danych na wejściu jest tańsza niż każde inne zabezpieczenie i działa niezależnie od tego, gdzie stoi model. Warto ją zaprojektować, zanim zacznie się dyskusja o infrastrukturze.
Decyzja 3: co zostaje w logach
Logi to najczęściej pomijane miejsce wycieku. System działa poprawnie, dane są szyfrowane w transporcie, a jednocześnie pełne treści zapytań lądują w pliku logu, do którego dostęp ma cały dział IT i który leży tam przez rok.
Dwie rzeczy do ustalenia na starcie: co dokładnie zapisujemy i jak długo to trzymamy. Do audytu zwykle wystarczy identyfikator operacji, znacznik czasu, wynik i kto zatwierdził - nie cała treść.
Decyzja 4: kto ma dostęp do wyników
Model zwraca odpowiedź, która trafia gdzieś dalej - do CRM, na skrzynkę, do arkusza. Jeśli ten arkusz jest współdzielony z całą firmą, to poziom ochrony całego rozwiązania jest równy poziomowi ochrony tego arkusza.
Ta zasada brzmi banalnie, ale w praktyce to właśnie tutaj najczęściej rozszczelnia się dobrze zaprojektowany system.
Jak to zapisać, żeby przeszło audyt
Niezależnie od wybranego wariantu, warto mieć dokument odpowiadający na pięć pytań:
- Jakie kategorie danych przechodzą przez proces?
- Dokąd fizycznie trafiają i na jak długo?
- Kto ma do nich dostęp na każdym etapie?
- Co się dzieje, gdy proces zawiedzie - dane zostają czy są usuwane?
- Jak wycofać się z rozwiązania i co wtedy dzieje się z danymi?
Piąte pytanie jest tym, którego prawie nikt nie zadaje przed podpisaniem, a które decyduje o tym, jak kosztowna będzie zmiana dostawcy za dwa lata.
Praktyczna wskazówka na start
Zanim zdecydujesz o architekturze, przejdź jeden konkretny proces i wypisz, jakie pola faktycznie muszą dotrzeć do modelu. W większości przypadków po tym ćwiczeniu okazuje się, że dane wrażliwe w ogóle nie muszą opuszczać firmy - bo do wykonania zadania nie są potrzebne.
To najtańsze zabezpieczenie, jakie istnieje, i wymaga wyłącznie godziny rozmowy.
Chcesz przejść przez to na swoim procesie? Umów bezpłatną konsultację - zaczynamy od tego, jakie dane naprawdę są potrzebne, a nie od tego, co da się sprzedać.
