HTTPS i bezpieczne sesje
Polityka prywatności wymienia szyfrowane połączenie HTTPS, a kod serwera ustawia cookies z flagami HttpOnly i SameSite, a w środowisku produkcyjnym także Secure.
bezpieczenstwo danych i receptur
Bezpieczeństwo danych i receptur chemicznych
Ta strona opisuje ochronę kont, receptur i dokumentów SDS w sposób spokojny i konkretny. Nie używa haseł typu „100% bezpieczne dane”, tylko rozdziela informacje potwierdzone w kodzie i dokumentach od elementów, które trzeba jeszcze sprawdzić przed publikacją finalnej deklaracji bezpieczeństwa.
HTTPS
hashowanie haseł
ograniczenie dostępu administratorów
kopie zapasowe
retencja danych
Sposób prezentacji
Ta strona rozróżnia fakty od pól wymagających uzupełnienia
W repozytorium widać zarówno elementy bezpieczeństwa już opisane w kodzie i dokumentach, jak i miejsca oznaczone wprost jako „do uzupełnienia”. Zamiast to ukrywać, lepiej pokazać jasno, co jest potwierdzone, a co wymaga jeszcze decyzji przed publikacją.
Potwierdzone informacje
Co można dziś opisać na podstawie kodu i dokumentów?
Haszowanie haseł
Interfejs ustawień i kod backendu potwierdzają przechowywanie haseł jako skrótów kryptograficznych. W implementacji używany jest Argon2id.
Ochrona logowania
W ustawieniach platformy opisano limit prób logowania i opcjonalne 2FA. W kodzie są też ścieżki konfiguracji oraz wyłączania mechanizmu MFA.
Separacja i dostęp
Polityka prywatności wskazuje separację danych użytkowników oraz ograniczenie dostępu administratorów. W kodzie istnieją też role admin i curator oraz kontrola dostępu do paneli administracyjnych.
Kopie zapasowe i retencja
To jest opisane dość konkretnie w regulaminie i polityce prywatności
- Kopie zapasowe projektów są wykonywane co najmniej raz dziennie.
- Kopie zapasowe mogą być przechowywane przez okres do 12 miesięcy.
- Po zakończeniu abonamentu projekty mogą być przechowywane w stanie nieaktywnym przez 12 miesięcy.
- Po upływie tego okresu projekty mogą zostać trwale usunięte albo skutecznie zanonimizowane.
To nadal nie jest obietnica odtworzenia każdej wersji dokumentu. Regulamin wyraźnie zaznacza, że backupy służą ciągłości działania i nie są indywidualną usługą archiwizacji.
Dostęp administratorów
Kiedy dostęp do projektu jest dopuszczalny według dokumentów?
Z regulaminu i polityki prywatności wynika, że dostęp personelu i administratorów technicznych do projektów ma być ograniczony do osób upoważnionych i do określonych sytuacji.
Obsługa zgłoszeń i awarii
Dostęp może być potrzebny do naprawy błędu, usunięcia awarii lub obsługi zgłoszenia użytkownika.
Ochrona systemu
Dokumenty przewidują dostęp związany z zapewnieniem bezpieczeństwa albo odtworzeniem danych po awarii.
Usługa ekspercka i obowiązek prawny
Dostęp może też nastąpić przy realizacji usługi eksperckiej albo wykonaniu obowiązku prawnego.
Usunięcie konta i eksport danych
Co można potwierdzić w tym obszarze?
Z regulaminu i polityki prywatności wynika, że użytkownik może zażądać natychmiastowego zamknięcia konta, a dostęp do niego jest wtedy niezwłocznie wyłączany. Dane operacyjne mają być usuwane lub anonimizowane w rozsądnym terminie, z zastrzeżeniem kopii zapasowych i obowiązków prawnych.
W dokumentach jest też wskazane, że po zakończeniu abonamentu użytkownik może zwrócić się o udostępnienie własnych danych oraz pobrać dokumenty, do których wcześniej nabył uprawnienie, o ile jest to technicznie możliwe.
Logi i incydenty
Jak opisywać reagowanie na incydenty bez przesady?
Polityka prywatności mówi o prowadzeniu logów bezpieczeństwa i procedurach reagowania na incydenty. Logi techniczne i bezpieczeństwa są co do zasady przechowywane do 12 miesięcy, a gdy dotyczą incydentu, nadużycia albo roszczenia, mogą być przechowywane dłużej do czasu wyjaśnienia sprawy.
Ważne:
Repozytorium nie zawiera publicznej listy historycznych incydentów bezpieczeństwa. Jeżeli chcesz publikować taki rozdział, trzeba go przygotować oddzielnie na podstawie realnej historii operacyjnej.
Do weryfikacji przed publikacją
Tych elementów nie warto opisywać jako zamkniętych faktów bez uzupełnienia
W repo są obszary, które wyglądają na planowane albo częściowo opisane, ale nie powinny jeszcze trafić na stronę jako pełne deklaracje bezpieczeństwa bez sprawdzenia z właścicielem systemu.
Lokalizacja serwera i dostawców
W tabeli dostawców w polityce prywatności wiele pól nadal ma oznaczenie „do uzupełnienia”, więc nie warto publikować precyzyjnej lokalizacji bez potwierdzenia.
Transfer poza EOG
Dokumenty wspominają, że niektórzy dostawcy mogą przetwarzać dane poza EOG, ale tabela dostawców nie jest jeszcze kompletnie uzupełniona.
Publiczny opis dostawców bezpieczeństwa
Monitoring błędów, hosting, backupy i część narzędzi są opisane w tabeli roboczej, ale nie jako kompletna, finalna lista produkcyjna.
Czego unikać
Jakich sformułowań lepiej nie używać na tej stronie?
„100% bezpieczne dane”
To zbyt szeroka deklaracja i stoi w sprzeczności z podejściem opisanym nawet w samej polityce prywatności.
„Serwery na pewno w Polsce”
Tego nie należy publikować, dopóki lokalizacja i dostawcy nie zostaną jednoznacznie uzupełnieni w dokumentacji.
„Stosujemy środki odpowiednie do ryzyka”
To sformułowanie jest spokojniejsze, zgodne z polityką prywatności i nie obiecuje rzeczy, których repo nie potwierdza wprost.
FAQ
Najczęstsze pytania o bezpieczeństwo danych i receptur
Czy hasła są przechowywane w formie jawnej?
Nie. Dokumenty i kod wskazują na przechowywanie haseł jako skrótów kryptograficznych, a implementacja w backendzie używa Argon2id.
Czy system wspiera dodatkowe zabezpieczenie logowania?
Tak. W kodzie i interfejsie ustawień widać obsługę opcjonalnego 2FA oraz mechanizmy związane z resetem hasła i MFA.
Jak długo mogą być przechowywane projekty po zakończeniu abonamentu?
Zgodnie z dokumentami do 12 miesięcy w stanie nieaktywnym, po czym mogą zostać trwale usunięte lub zanonimizowane.
Czy po usunięciu konta dane znikają natychmiast ze wszystkich kopii?
Nie musi tak być. Dokumenty wyraźnie zaznaczają, że dane mogą czasowo pozostać w zabezpieczonych kopiach zapasowych i zostać objęte procedurą usunięcia po odtworzeniu systemu po awarii.
Co jeszcze warto zrobić przed publikacją tej strony?
Uzupełnić tabelę dostawców i lokalizacji w polityce prywatności, potwierdzić rzeczywiste środowisko produkcyjne oraz zdecydować, czy i jak publicznie opisywać historię incydentów bezpieczeństwa.