Bezpieczeństwo danych i kontrola dostępu w platformie VIMS

Konto użytkownika w VIMS samo w sobie nie daje dostępu do żadnych danych operacyjnych. Dostęp wynika z członkostwa w organizacji. Zgłoszenie chęci dołączenia trafia najpierw w stan oczekujący i musi zostać rozpatrzone przez właściciela lub administratora tej organizacji. Do momentu zatwierdzenia użytkownik nie widzi ani jednego rekordu — nie ma tu sytuacji, w której samo założenie konta z firmowym adresem otwiera dostęp do rejestrów.

W obrębie organizacji obowiązują role o różnym zakresie: właściciel, administrator i członek. Właściciel zarządza całą przestrzenią, w tym eksportem danych i archiwizacją. Administrator prowadzi bieżącą pracę z użytkownikami i konfiguracją. Członek pracuje na danych operacyjnych w zakresie, jaki przewiduje jego rola. Rozdzielona od tego jest warstwa uprawnień platformowych, wykorzystywana wyłącznie do obsługi technicznej i administracyjnej samej usługi.

Uprawnienia są przechowywane w osobnej tabeli i sprawdzane przez dedykowaną funkcję bazodanową działającą z podwyższonymi uprawnieniami, poza zwykłą ścieżką odczytu. Jest to celowa decyzja architektoniczna: uniemożliwia najczęstszy błąd projektowy w aplikacjach wielofirmowych, w którym użytkownik potrafi zmodyfikować swój własny profil i w ten sposób podnieść sobie rolę.

Każda zmiana członkostwa i statusu zatwierdzenia trafia do rejestru zdarzeń bezpieczeństwa. Przy sporze kompetencyjnym lub audycie wewnętrznym można odtworzyć, kto komu i kiedy nadał dostęp do danych organizacji.

VIMS jest platformą wielofirmową: w tej samej instancji pracują obok siebie niezależne organizacje, a w modelu obsługi zewnętrznej służby BHP jeden doradca może prowadzić kilkanaście podmiotów. Bezpieczeństwo takiego układu nie może opierać się na tym, że interfejs pokazuje odpowiednio przefiltrowaną listę. Filtr w interfejsie chroni przed pomyłką, ale nie przed świadomym obejściem.

Dlatego separacja jest realizowana bezpośrednio w bazie danych, na poziomie pojedynczego wiersza. Każdy istotny zbiór danych ma włączoną tę ochronę, a reguły dostępu opisują, kto może dany rekord odczytać, dodać, zmienić i usunąć. Zapytanie wysłane przez użytkownika spoza organizacji nie jest odrzucane komunikatem o braku uprawnień — po prostu nie zwraca żadnego rekordu, bo rekord dla tego kontekstu nie istnieje.

Analogicznie chronione są pliki. Zdjęcia dokumentujące zdarzenia wypadkowe trafiają do przestrzeni, do której nie prowadzi żadna publiczna ścieżka: nie da się do nich dotrzeć bezpośrednim adresem, a dostęp odbywa się wyłącznie przez kontrolowaną warstwę serwerową sprawdzającą uprawnienia. To istotne, bo fotografia z miejsca wypadku bywa materiałem wrażliwszym niż sam protokół.

Odsłonięcie danych szczególnie chronionych w interfejsie administracyjnym jest osobno rejestrowane jako zdarzenie. Nie blokujemy pracy osobom, które muszą takie dane zobaczyć — dokumentujemy fakt, że je zobaczyły.

Rejestr zdarzeń bezpieczeństwa jest zbiorem zapisywanym po stronie serwera, niezależnym od tego, co użytkownik robi w przeglądarce. Każdy wpis zawiera identyfikator organizacji, identyfikator użytkownika, nazwę zdarzenia, znacznik czasu oraz zestaw danych kontekstowych. Zapisywane są między innymi: wysłanie i poprawna weryfikacja kodu logowania, nieudana wysyłka kodu, włączenie i wyłączenie uwierzytelniania dwuetapowego, utworzenie organizacji, zmiana członkostwa, eksport danych oraz odsłonięcie danych wrażliwych.

Poza tym rejestrem procesy merytoryczne prowadzą własną historię. Zdarzenie wypadkowe zachowuje ślad kolejnych etapów postępowania, analiza przyczyn przechowuje wersje ustaleń, a zmiany konfiguracji modułów są odnotowywane wraz z autorem. Dzięki temu podczas audytu zewnętrznego rozmowa nie sprowadza się do pytania „czy to było zrobione”, tylko do pokazania, kiedy i przez kogo.

Warstwa danych działa na zarządzanej usłudze bazodanowej z automatycznymi kopiami zapasowymi wykonywanymi po stronie dostawcy infrastruktury. Odtworzenie środowiska po awarii odbywa się z tych kopii. Nie deklarujemy tu umownego czasu przywrócenia usługi jako standardu handlowego — konkretne parametry ciągłości działania, w tym poziom dostępności, ustalamy indywidualnie w umowie, jeżeli organizacja tego wymaga.

Akceptacje dokumentów prawnych — regulaminu i polityki przetwarzania danych — są przechowywane wraz z wersją dokumentu i datą. Przy zmianie treści widać, kto zaakceptował którą wersję, co bywa pierwszym pytaniem podczas kontroli.

W relacji z klientem VIMS występuje jako podmiot przetwarzający dane na zlecenie administratora, którym pozostaje organizacja korzystająca z systemu. Współpraca wymaga zawarcia umowy powierzenia przetwarzania danych osobowych; przygotowujemy ją na etapie podpisywania umowy głównej i dołączamy do dokumentacji przetargowej, gdy zamawiający tego oczekuje.

Zakres danych osobowych przetwarzanych w systemie wynika z procesów, które organizacja zdecyduje się uruchomić. Uruchomienie samego rejestru zdarzeń wymaga węższego zakresu niż prowadzenie kartoteki badań lekarskich czy ewidencji szkoleń. Zalecamy, aby przy wdrożeniu świadomie ograniczyć zbierane pola do tych rzeczywiście potrzebnych — jest to zarówno praktyka zgodna z zasadą minimalizacji, jak i prostsza w utrzymaniu.

Klient zachowuje własność swoich danych przez cały okres współpracy i po jej zakończeniu. Archiwum organizacji można pobrać samodzielnie z poziomu systemu, bez zgłaszania wniosku i bez oczekiwania na obsługę. Operacja jest dostępna dla właściciela i administratora organizacji, a jej wykonanie zostaje odnotowane.

Usunięcie danych po zakończeniu współpracy realizujemy na pisemne żądanie administratora danych, w trybie i terminie uzgodnionym w umowie powierzenia. Nie stosujemy praktyki zatrzymywania danych jako narzędzia nacisku przy przedłużaniu abonamentu.

Logowanie jednokrotne w oparciu o firmowego dostawcę tożsamości oraz publiczne, dokumentowane API do integracji z systemami kadrowymi i utrzymania ruchu znajdują się na mapie rozwoju produktu i nie są dziś dostępne jako funkcja gotowa do włączenia. Nie umieszczamy ich na liście cech systemu, bo dla działu IT to informacja rozstrzygająca, a nie dodatek.

Nie posiadamy własnego certyfikatu systemu zarządzania bezpieczeństwem informacji. Infrastruktura, na której działa platforma, jest utrzymywana przez zewnętrznego dostawcę chmurowego posiadającego własne certyfikaty, ale nie traktujemy tego jako naszej certyfikacji i nie prezentujemy w ten sposób.

Nie publikujemy również gwarantowanego poziomu dostępności jako parametru marketingowego. Jeżeli Twoja organizacja wymaga zobowiązania umownego w tym zakresie, jest to temat do uzgodnienia indywidualnego, a nie deklaracja ze strony internetowej.

Takie podejście wydłuża czasem rozmowę handlową, ale skraca wdrożenie. Dział IT, który dostaje rzetelną listę z jasno oznaczonymi brakami, podejmuje decyzję szybciej niż dział IT, który musi weryfikować obietnice.