Dlaczego dane biura potrzebują izolowanej bazy danych

Gdy zespół IT lub bezpieczeństwa ocenia narzędzie do rezerwacji miejsc w biurze, ankieta pyta zwykle o szyfrowanie, logowanie jednokrotne i lokalizację serwerów. Rzadko pada pytanie, które ma największe znaczenie dla tej kategorii danych: czy dane naszej organizacji są fizycznie oddzielone od danych każdego innego klienta, czy są kolumną we wspólnej tabeli?

Rezerwacja biurek wygląda na dane niskiego ryzyka, dopóki nie wypisze się, co zawiera: kto był w którym budynku którego dnia, przy którym biurku, obok kogo, z jakimi gośćmi i gdzie zaparkował samochód. To dziennik przemieszczania się Twoich pracowników. Zasługuje na taką samą izolację, jakiej wymagałbyś dla danych kadrowych czy płacowych.

Ten artykuł wyjaśnia dwa sposoby, w jakie dostawcy SaaS przechowują dane wielu klientów, dlaczego Desk & Park daje każdej organizacji własną izolowaną bazę danych i co ta decyzja oznacza dla osób, które podpisują się pod bezpieczeństwem, prywatnością i zgodnością.

Dwie architektury, jeden kompromis

Prawie każdy produkt SaaS jest wielodostępny: jedna aplikacja obsługuje wielu klientów. Pytanie brzmi, gdzie przebiega granica między klientami.

Wspólna baza, kolumna z identyfikatorem najemcy

Podejście najczęstsze. Wiersze każdego klienta leżą w tych samych tabelach, a każdy wiersz ma tenant_id. Każde zapytanie musi po nim filtrować. Za rozdzielanie klientów odpowiada aplikacja, nie baza danych.

Jest popularne, bo tanie w utrzymaniu: jedna baza, jeden schemat, jedna migracja. To także źródło całej klasy incydentów bezpieczeństwa. Jedno brakujące WHERE tenant_id = ? w jednym z tysięcy zapytań, jeden raport łączący tabele bez filtra, jeden błąd w cache, i klient A widzi dane klienta B. To nie są hipotetyczne błędy; to powtarzająca się kategoria ujawnionych naruszeń w SaaS, trudna do znalezienia, bo każde pojedyncze zapytanie wygląda poprawnie.

Izolowana baza per organizacja

Każdy klient dostaje własną bazę danych, z własnymi tabelami, własnymi poświadczeniami i własnymi kopiami zapasowymi. Aplikacja łączy się z właściwą bazą dla organizacji, która wysyła żądanie. Nie ma filtra tenant_id, o którym można zapomnieć, bo w bazie nie ma innego najemcy, z którego dane mogłyby wyciec.

Kosztuje to dostawcę więcej dyscypliny operacyjnej: provisionowanie, migrowanie i monitorowanie setek lub tysięcy baz zamiast jednej. Ten koszt jest sednem sprawy. Płaci go dostawca, raz, w inżynierii, zamiast klienta, później, w incydencie.

Jak zbudowany jest Desk & Park

Desk & Park działa w architekturze bazy danych per organizacja. Konkretnie:

• Płaszczyzna sterowania przechowuje tylko to, co potrzebne do routingu i rozliczeń: nazwy organizacji, plan, mapowanie organizacji na jej bazę oraz własny dziennik audytu platformy. Nie zawiera rezerwacji, planów pięter ani katalogu pracowników.
• Jedna baza PostgreSQL per organizacja przechowuje wszystko o tej organizacji: użytkowników, role, lokalizacje, mapy, biurka, miejsca parkingowe, salki, rezerwacje, meldunki, gości, powiadomienia i dziennik audytu organizacji.
• Poświadczenia per organizacja. Aplikacja otwiera połączenie z bazą organizacji poświadczeniami ograniczonymi do tej bazy. Żądanie organizacji A nie może zostać wykonane na bazie organizacji B nawet przez pomyłkę, bo aplikacja nigdy nie trzyma do niej połączenia.
• Kopie zapasowe, przywracanie i usuwanie per organizacja. Kopie zapasowe są wykonywane per baza. Przywrócenie jednej organizacji do stanu z wczoraj nie dotyka nikogo innego. Usunięcie organizacji po zakończeniu umowy oznacza usunięcie jej bazy, co jest weryfikowalnym, kompletnym wymazaniem, a nie DELETE WHERE tenant_id, które ma nadzieję, że znalazło każdy wiersz.

Kod aplikacji jest wspólny; dane nie. To granica, którą audytor może wskazać palcem.

Co izolacja daje osobom, które się podpisują

Dla CISO: mniejszy zasięg awarii

Podatność w wielodostępnej warstwie zapytań ujawnia wszystkich klientów naraz. Przy izolowanych bazach ta sama klasa błędu nie może przekroczyć granicy organizacji, bo granicę egzekwuje silnik bazy i poświadczenia połączenia, a nie logika aplikacji. Izolacja nie uodparnia aplikacji na błędy; sprawia, że błąd w jednym miejscu jest problemem jednego klienta, a nie całej platformy.

Dla inspektora ochrony danych: czyste odpowiedzi na pytania z RODO

Przeglądy ochrony danych zadają przewidywalne pytania, a baza per organizacja daje na nie krótkie odpowiedzi.

Prawo do usunięcia i obowiązek ograniczenia przetwarzania stają się operacjami na bazie o jasnym zakresie, a nie funkcjami aplikacji, których kompletność trzeba testować.

Dla osoby odpowiedzialnej za zgodność: kontrola, której da się bronić

Ramy takie jak ISO 27001 i SOC 2 wymagają od dostawcy wykazania logicznej separacji między klientami. „Każde zapytanie filtruje po najemcy" to kontrola, którą trzeba weryfikować na nowo przy każdym nowym zapytaniu. „Każdy klient ma własną bazę i poświadczenia" to kontrola weryfikowana raz, strukturalnie, która utrzymuje się w miarę rozwoju produktu. Tę drugą znacznie łatwiej udowodnić, zarówno dostawcy, jak i w audycie klienta.

Dla CIO: przewidywalna wydajność i cykl życia

Ciężki raport jednej organizacji nie spowalnia porannej fali meldunków innej, bo nie dzielą tabel ani indeksów. Migracje wdraża się per baza, więc problem można wychwycić na jednej organizacji, zanim dotrze do kolejnej. Zakończenie współpracy to usunięcie bazy, a nie projekt sprzątania.

Reszta historii o bezpieczeństwie

Izolacja to fundament, nie cały budynek. Kontrole, których oczekują zespoły IT, leżą nad nią i warto je wymienić, bo dobra architektura ze słabym uwierzytelnianiem wciąż jest słaba:

• Logowanie jednokrotne przez OpenID Connect z Waszym dostawcą tożsamości oraz provisioning SCIM, dzięki któremu nowe i odchodzące osoby są tworzone i dezaktywowane z Waszego katalogu, a nie ręcznie.
• Uwierzytelnianie dwuskładnikowe (TOTP) i klucze dostępu (WebAuthn), z polityką na poziomie organizacji wymuszającą MFA.
• Polityki bezpieczeństwa per organizacja: limit czasu sesji, zasady haseł, listy dozwolonych adresów IP.
• Zarządzanie aktywnymi sesjami, żeby administrator widział i mógł odwołać sesje.
• Dziennik audytu per organizacja zapisujący, kto co zmienił, w bazie tej organizacji.
• Płatności przez Stripe, więc dane kart w ogóle nie trafiają na platformę.
• Dostęp oparty na rolach: pracownicy widzą i rezerwują; administratorzy konfigurują; członkowie zarządu i menedżerowie dostają raporty zawężone do swoich zespołów.

Nic z tego nie jest niezwykłe w SaaS dla przedsiębiorstw. Niezwykłe jest połączenie tego z warstwą danych, w której granica między klientami jest fizyczna.

Pytania do każdego dostawcy narzędzi dla biura

Jeśli porównujesz narzędzia, te pięć pytań oddziela marketing od architektury:

1. Czy nasze dane są w dedykowanej bazie, czy we wspólnych tabelach z kolumną najemcy?
2. Czy kopie zapasowe, przywracanie i usuwanie wykonuje się per klient?
3. Jakich poświadczeń używa aplikacja, żeby dotrzeć do naszych danych, i czy są ograniczone do nas?
4. Jak udowadniacie audytorom separację klientów?
5. Czy błąd w raporcie lub eksporcie może kiedykolwiek zwrócić wiersze innego klienta?

Dostawca z izolowaną bazą odpowiada na wszystkie pięć jednym zdaniem każde. Dostawca ze wspólną bazą musi opisać proces testowania.

Izolacja powinna być domyślna

Dane o miejscu pracy to dane osobowe o fizycznej obecności Twoich pracowników. Najtańsza dla dostawcy architektura kładzie te dane obok danych każdego innego klienta i ufa, że aplikacja utrzyma je osobno. Desk & Park wybrał tę droższą, żeby granicą między organizacjami była baza danych, a nie filtr.

Szczegóły techniczne znajdziesz w podsumowaniu architektury na stronie „jak to działa" i w polityce prywatności platformy. Wdrożenie dla przedsiębiorstwa z logowaniem jednokrotnym, SCIM i przeglądem bezpieczeństwa zaczyna się od kontaktu Enterprise na stronie cennika.