Case Study: Jak zabezpieczyć poufne stawki podwykonawców. Trwała ochrona danych handlowych bez ryzyka wycieku
W systemach obsługujących wielu podwykonawców (B2B), bezpieczeństwo danych handlowych jest fundamentem zaufania. Stawki godzinowe, informacje o rozliczeniach i marże stanowią najgłębszą tajemnicę firmy. Tradycyjne podejście polegające na filtrowaniu danych w kodzie programu (np. dopisywanie warunków w zapytaniach) niesie ogromne ryzyko ludzkiego błędu. Jeden przeoczony warunek przez młodszego programistę może doprowadzić do wycieku wrażliwych stawek do konkurencji.
W tym projekcie zabezpieczyliśmy dane u samego źródła – bezpośrednio w silniku bazy danych za pomocą mechanizmu Row-Level Security (RLS). Działa on jak twarda kłódka na poziomie bazy danych, której nie da się ominąć, nawet jeśli w kodzie aplikacji wystąpi błąd.
1. Wyzwanie operacyjne (Stan wyjściowy)
Firma współpracowała z licznymi podwykonawcami na kontraktach B2B. Poprzedni, rozproszony model raportowania nie gwarantował poufności:
- Kierownicy budów i podwykonawcy wymieniali się informacjami za pomocą arkuszy Excel i komunikatorów.
- Istniało duże ryzyko, że stawki jednego podwykonawcy zostaną ujawnione innym uczestnikom projektów, wywołując konflikty i presję na zmianę cen.
- Konieczne było stworzenie centralnej bazy danych, w której każdy podmiot ma dostęp wyłącznie do swojego, ściśle wydzielonego obszaru.
2. Projekt Bazy Danych i Zabezpieczenia
System przechowuje dane w ustrukturyzowany sposób, dzieląc je na kilka obszarów: dane użytkowników, profile firmowe B2B ze stawkami, spis budów oraz rejestr czasu pracy.
Dla wygody biura stworzyliśmy również automatyczny widok rozliczeń, który precyzyjnie kalkuluje godziny pracy, w tym trudne przypadki zmian nocnych przechodzących przez północ.
[!TIP] Obsługa pracy na przełomie dni: System automatycznie oblicza czas pracy netto (np. od 22:00 do 06:00 rano następnego dnia), odejmując przerwy, co eliminuje ręczne wyliczenia kadr.
3. Row-Level Security (RLS) – Bezpieczeństwo u źródła
Najważniejszym elementem systemu jest zabezpieczenie tabeli ze stawkami i logami pracy na poziomie silnika bazy danych. Definiujemy twarde reguły bezpośrednio w bazie.
1. Przykładowa polityka bezpieczeństwa w bazie danych:
-- Włączenie blokady RLS na tabeli logów pracy
ALTER TABLE work_logs ENABLE ROW LEVEL SECURITY;
-- Utworzenie polityki dostępu: dane widzi tylko właściciel (OWNER)
-- lub pracownik, do którego dany rekord należy.
CREATE POLICY work_logs_access_policy ON work_logs
FOR ALL
USING (
(SELECT role FROM users WHERE id = current_user_id) = 'OWNER'
OR
user_id = current_user_id
);2. Jak to działa w praktyce?
Gdy użytkownik loguje się do systemu, program pobiera jego unikalny identyfikator. Zanim system wyśle jakiekolwiek zapytanie o stawki czy godziny, baza danych automatycznie nakłada powyższą regułę.
Nawet jeśli programista zapomni dopisać w kodzie ograniczenie „pokaż tylko stawki dla firmy X”, baza danych PostgreSQL i tak fizycznie zablokuje dostęp do rekordów innych podmiotów.
4. Korzyści Biznesowe z Wdrożenia RLS
- Pewność i bezpieczeństwo (Odporność na błędy programistów): Zabezpieczenie działa na najniższym poziomie. Ogranicza to ryzyko wycieku do zera, chroniąc właściciela przed odpowiedzialnością prawną i wpadkami wizerunkowymi.
- Ochrona tajemnic handlowych i marż: Podwykonawcy realizujący prace na tej samej budowie nie widzą nawzajem swoich stawek ani zysków. Zapobiega to konfliktom i chroni Twoją marżę operacyjną.
- Łatwość weryfikacji: Wszystkie zasady bezpieczeństwa są zapisane w jednym, centralnym miejscu w bazie danych, a nie rozsiane po tysiącach linii kodu aplikacji.
5. Podsumowanie
Wdrożenie Row-Level Security to inwestycja w stabilność i bezpieczeństwo klasy Enterprise przy minimalnych kosztach utrzymania. System jest całkowicie odporny na najczęstsze błędy autoryzacji. Właściciel firmy zyskuje gwarancję, że dane handlowe podwykonawców są bezpieczne, co pozwala budować profesjonalny i godny zaufania wizerunek na rynku.