Skonfiguruję zabezpieczenia na poziomie wierszy PostgreSQL, aby każdy użytkownik widział tylko swoje dane, w tym Supabase

Każda aplikacja z kontami użytkowników, płatnymi planami lub kilkoma zespołami w jednej bazie danych musi zdecydować, kto może widzieć które wiersze. Jeśli ta reguła istnieje tylko w kodzie aplikacji, zawodzi za pierwszym razem, gdy ktoś uzyskuje dostęp do danych w inny sposób: nowy punkt końcowy, o którym ktoś zapomniał zabezpieczyć, druga aplikacja na tej samej bazie danych lub API, które Supabase generuje dla Twoich tabel. Zabezpieczenia na poziomie wierszy umieszczają regułę tam, gdzie znajdują się dane.

Zrobiłem to w produkcie subskrypcyjnym objętym umową NDA: polityki bezpieczeństwa na poziomie wierszy w tabelach i oddzielna rola bazy danych dla każdego poziomu subskrypcji, więc to, co obejmuje plan, jest egzekwowane przez PostgreSQL, a nie przez sprawdzenie, o którym ktoś mógłby zapomnieć.

W pakiecie Starter przeglądam polityki, które posiada lub których brakuje maksymalnie pięciu tabelom, i wysyłam pisemną listę luk, z przykładowym zapytaniem, które pokazuje każdą z nich. Pakiet Standard pisze lub naprawia polityki dla maksymalnie dziesięciu tabel, konfiguruje role potrzebne Twojej aplikacji, dostarcza je jako pliki migracji i dodaje testy, w których użytkownik A próbuje odczytać i zmienić wiersze użytkownika B i ponosi porażkę. Pakiet Advanced obejmuje maksymalnie dwadzieścia pięć tabel, dodaje limity planów lub poziomów egzekwowane w bazie danych i uruchamia testy w CI.

W Supabase obowiązują te same funkcje PostgreSQL, z auth.uid() i roszczeniami JWT używanymi w ramach polityk. W czystym PostgreSQL polityki odczytują bieżącego użytkownika z ustawienia sesji, które Twój backend ustawia dla każdego żądania.

Brak połączeń. Każdy pakiet kończy się prostą notatką o tym, kto co może zobaczyć; w pakietach Standard i Advanced polityki są również dostarczane jako migracje do Twojego repozytorium, wraz z testami. Przez 14 dni po dostarczeniu naprawiam wszystko, co nie działa zgodnie z naszymi ustaleniami, bezpłatnie.

Kroki do ukończenia Twojego projektu
1. Mapowanie danych – Wymieniam tabele, kto jest właścicielem każdego wiersza i kto powinien go odczytywać lub zmieniać: właściciele, członkowie zespołu, administratorzy, każdy plan.
2. Przegląd istniejących elementów – Bieżące polityki, uprawnienia i role są sprawdzane pod kątem tej mapy, a każda luka jest zapisywana wraz z zapytaniem, które ją pokazuje.
3. Polityki i role – Polityki są pisane dla każdej tabeli i dla każdej akcji, z rolami dla planów lub zespołów, jako pliki migracji, które możesz przejrzeć.
4. Udowodnij to – Testy logują się jako różni użytkownicy i próbują odczytywać i zmieniać dane innych użytkowników. Każda zabroniona akcja musi zakończyć się niepowodzeniem, a każda dozwolona musi działać.
5. Przekazanie – Krótka notatka w prostych słowach o tym, kto co może zobaczyć, migracje i jak dodać politykę, gdy pojawi się nowa tabela.