Izolacja egzekwowana przez bazę danych, a nie przez kod aplikacji.

Kontrolka w interfejsie pyta, czy zalogowana osoba ma dane uprawnienie, zanim się wyrenderuje. Obsługa żądania na serwerze weryfikuje to samo uprawnienie, zanim wykona jakąkolwiek pracę. Następnie baza danych stosuje politykę, która decyduje, jakie wiersze może zobaczyć zapytanie. Trzy mechanizmy, trzy osobne miejsca, w których trzeba mieć rację, a odmowa któregokolwiek z nich kończy żądanie.

• Sprawdzenie w interfejsie to wygoda, a nie granica. Ukrywa przycisk; nie chroni tabeli.
• Każde sprawdzenie przechodzi przez jeden katalog uprawnień i jedną funkcję. Żadna obsługa żądania nie odczytuje nazwy roli i nie decyduje samodzielnie, co ta rola oznacza.
• Rola nadana na oddziale w drzewie organizacji spływa w dół tej gałęzi — a polityki bazy danych czytają to samo drzewo co interfejs, więc nie mogą się ze sobą rozminąć.

Izolacja jest schematem, a nie konwencją. Tabele powstają z włączonym bezpieczeństwem na poziomie wierszy i politykami, które delegują decyzję do tej samej funkcji uprawnień, którą wywołuje serwer, a kontrola migracji szuka tabel, do których nadano dostęp bez stojącej za nim polityki. Ta liczba nie jest figurą marketingową — to odpowiedź bazy danych na pytanie, ile polityk egzekwuje.

• Polityki nie wpisują własnej logiki w treść. Wywołują funkcję uprawnień, więc odpowiedź nie może rozminąć się z tym, co serwer zdecydował chwilę wcześniej.
• Polityki zapisu mają klauzulę sprawdzającą obok klauzuli odczytu, więc wstawienie danych nie umieści wiersza w organizacji, do której zapisujący nie ma uprawnienia.
• Tam, gdzie widok udostępnia dane osobowe, dostęp nadaje się kolumna po kolumnie. Uprawnienie nadane na całą tabelę po cichu zniosłoby ochronę na poziomie kolumn, więc go nie stosujemy.

Tabele aplikacji znajdują się w czternastu nazwanych schematach — jeden dla tożsamości i dostępu, jeden dla organizacji, jeden dla mediów i tak dalej. Nic, co ma znaczenie, nie leży w domyślnym schemacie publicznym, czyli w miejscu, w którym przypadkowo nadane uprawnienie albo zbyt pobłażliwe ustawienie domyślne najłatwiej ujawni dane. Prywatne media nie mają w ogóle polityk magazynu dla zalogowanych przeglądarek: każdy odczyt podpisuje serwer, który najpierw sprawdził wiersz właścicielski, i tak samo powstaje każde uprawnienie do wgrania pliku.

• Tokeny jednorazowe — zaproszenia, resety hasła, odzyskiwanie konta — są przechowywane jako solone skróty. Surowy token pokazuje się raz, w wiadomości e-mail, i nigdy więcej.
• Publiczna jest wyłącznie identyfikacja wizualna. Logo i favicon organizacji muszą wyrenderować się, zanim ktokolwiek się zaloguje; awatary i media lekcji nie muszą, więc pozostają podpisane.

Pliki zapisujemy przez interfejs magazynu z czterema implementacjami: Supabase Storage, Amazon S3, Azure Blob Storage i Google Cloud Storage. To zwykle uczciwa odpowiedź na wymóg dotyczący lokalizacji danych — wdrożenie może zapisywać pliki do bucketu w regionie, którego Państwo potrzebują, zamiast czekać, aż dostawca taki region otworzy. Prosimy podać wymóg wcześnie, a powiemy wprost, czy jest dziś spełniony.

• Baza danych, uwierzytelnianie i funkcje, na których działa API, są hostowane przez Supabase. To jedyna zależność, której nie da się skonfigurować inaczej, i jest ona wymieniona w umowie DPA.
• Własne domeny poszczególnych organizacji obsługuje Cloudflare, z certyfikatami wystawianymi automatycznie, więc uczestnik w Bejrucie albo Mediolanie widzi Państwa domenę, a nie naszą.

Analityka platformy działa przez PostHog w jego regionie UE, za warstwą abstrakcji, dzięki której dostawcę można wymienić bez dotykania produktu. Nagrania sesji są maskowane i nigdy nie rejestrują uczestników — powierzchnia uczestnika nie jest w ogóle oprzyrządowana pod nagrywanie.

• Pola tekstowe i wszystko, co oznaczono jako dane osobowe, są maskowane w przeglądarce, zanim nagranie gdziekolwiek trafi.
• Analityka wymaga zgody i jest wyłączona, dopóki organizacja jej nie włączy. Nic dotyczącego osoby niepełnoletniej nie jest profilowane na żadnej powierzchni.