Bezpieczeństwo dla działów IT

Opis zabezpieczeń WyślijBezpiecznie do oceny dostawcy i dokumentacji SZBI. Wersja 2026-10-22.

Pobierz PDF Wzór umowy powierzenia

Usługa w skrócie

WyślijBezpiecznie służy do przekazywania dokumentów z danymi osobowymi poza organizację: zastępuje załącznik w mailu i hasło wysyłane w drugim mailu. Pliki są szyfrowane na urządzeniu nadawcy, link trafia do odbiorcy mailem, a kod dostępu osobnym kanałem (SMS, drugi adres e-mail albo telefonicznie). Odbiorca widzi zweryfikowane dane nadawcy.

Usługa nie zastępuje e-Doręczeń ani innej korespondencji urzędowej ze skutkiem prawnym i nie jest usługą zaufania w rozumieniu rozporządzenia eIDAS.

Usługodawca

SOFTART Krzysztof Michałowski, ul. Pomorska 16D/11, 80-333 Gdańsk, NIP 5841182350

Kontakt w sprawach bezpieczeństwa

security@wyslijbezpiecznie.pl

Architektura i przepływ klucza

• Komponenty: strona i panel (SvelteKit), API (Node.js 22, Fastify), baza PostgreSQL 16, magazyn plików zgodny z S3, bramka Caddy z TLS. Kontenery Docker zarządzane przez Coolify na serwerze VPS.
• Nadawca losuje klucz przesyłki w przeglądarce albo w programie Windows; każdy plik ma własny klucz wyprowadzony HKDF-SHA-256. Na serwer trafia wyłącznie szyfrogram.
• Klucz odbiorcy powstaje z dwóch części po 256 bitów: część A jest w adresie linku (w części po znaku #, której przeglądarka nie wysyła na serwer), część B przechowuje serwer, zaszyfrowaną kluczem serwera.
• Serwer wydaje część B dopiero po poprawnym kodzie dostępu z drugiego kanału. Część A przetwarzamy tylko w pamięci na czas wysłania maila; gdy nadawca wysyła link ze swojej poczty, w ogóle do nas nie trafia.
• Bez linku i kodu nie da się otworzyć przesyłki; usługodawca nie ma treści ani nazw plików.
• Prośba o pliki (klient firmy przesyła dokumenty bez zakładania konta): przeglądarka klienta szyfruje pliki tak samo, z jednym odbiorcą, osobą proszącą. Część A trafia tylko do linku w mailu do tej osoby, a część B serwer wydaje wyłącznie po zalogowaniu na jej konto. Wiadomość i lista dokumentów w prośbie są szyfrowane w przeglądarce osoby proszącej; klucz jest w linku do klienta.

Link i kod idą dwoma kanałami, przez różnych dostawców. Dostęp do jednego z nich nie wystarcza do otwarcia przesyłki:

• SMS zawiera tylko nazwę firmy nadawcy i kod, bez linku. Dostawca SMS (także w swojej historii wiadomości) zna numer telefonu i kod, ale nie wie, do której przesyłki kod pasuje, i nie ma części A klucza.
• Mail z linkiem nie zawiera kodu. Serwer poczty widzi link, ale bez kodu serwer usługi nie wyda części B.
• Kod działa dla jednego odbiorcy jednej przesyłki. Po 5 błędnych próbach odbiorca jest blokowany, a nadawca dostaje powiadomienie; obowiązuje też limit prób z jednego adresu IP. Po wygaśnięciu przesyłki (najpóźniej po 30 dniach) i usunięciu plików kod niczego nie otwiera.
• Osoba trzecia musiałaby jednocześnie mieć dostęp do obu kanałów: na przykład do skrzynki i telefonu odbiorcy albo do obu dostawców.
• Kod można też przekazać ręcznie (np. telefonicznie); wtedy nie przechodzi przez żadnego dostawcę. Gdy kod idzie drugim e-mailem, oba kanały przechodzą przez pocztę: kodu do tej samej skrzynki co link serwer nie przyjmuje, a przy adresie w tej samej domenie firmowej panel ostrzega nadawcę i zaleca SMS.

Do ustalenia: Okres przechowywania historii SMS u dostawców bramek SMS: sprawdzić w panelach, skrócić i wpisać.

Kryptografia

Szyfrowanie plików

AES-256-GCM, kawałki po 4 MiB, osobny klucz na plik (HKDF-SHA-256)

Klucz odbiorcy

KEK = HKDF(A ‖ B, sól); A i B po 256 bitów

Kody dostępu

6 cyfr, losowane kryptograficznie, porównywane HMAC-SHA-256 w stałym czasie, 5 prób

Hasła kont

argon2id (19 MiB, 2 iteracje, wg OWASP)

Dane w spoczynku

sekrety 2FA i części B kluczy zaszyfrowane kluczem serwera (AES-256-GCM)

Transmisja

HTTPS (TLS) z HSTS; ścisła polityka CSP, brak skryptów i analityki firm trzecich

Specyfikacja

format WB1 opublikowany z wektorami testowymi: /bezpieczenstwo/wb1

Uwierzytelnianie i dostęp

• Weryfikacja dwuetapowa (TOTP) z kodami zapasowymi; Organizacja może ją uczynić obowiązkową.
• Role w Organizacji: właściciel, administrator, nadawca. Nadawca widzi tylko swoje wysyłki.
• Sesje w ciasteczku HttpOnly: wygasają po 12 godzinach bezczynności, najpóźniej po 14 dniach.
• Przy kodzie 2FA użytkownik może zapamiętać przeglądarkę na 30 dni (logowanie w niej wymaga wtedy tylko hasła). Zmiana hasła, włączenie lub wyłączenie 2FA i wyłączenie konta unieważniają zapamiętanie; użytkownik widzi listę przeglądarek w Ustawieniach. Konto operatora zawsze podaje kod.
• Program Windows łączy się z kontem przez parowanie urządzenia (RFC 8628) zatwierdzane w panelu; token jest w Menedżerze poświadczeń Windows, a urządzenie można w każdej chwili odłączyć.
• Limity prób logowania, rejestracji i wpisywania kodów; konto operatora usługodawcy wymaga 2FA.

Lokalizacja danych i podprocesorzy

Serwer i zaszyfrowane pliki są w Warszawie, kopie zapasowe we Frankfurcie nad Menem. Nie przekazujemy danych poza Europejski Obszar Gospodarczy.

OVHcloud

serwer aplikacji (VPS), magazyn zaszyfrowanych plików (Object Storage), kopie zapasowe. Lokalizacja: Warszawa (serwer i pliki), Frankfurt nad Menem (kopie zapasowe); UE. Dane: wszystkie dane serwisu; pliki wyłącznie zaszyfrowane, bez kluczy do odczytu.

MyDevil (mydevil.net)

serwer poczty wychodzącej (SMTP). Lokalizacja: Polska; UE. Dane: adresy e-mail odbiorców i nadawców, treść powiadomień z linkami; bez plików.

SMSAPI (smsapi.pl)

bramka SMS. Lokalizacja: Polska; UE. Dane: numer telefonu i treść SMS z kodem dostępu albo kodem potwierdzającym.

Do ustalenia: Pełne nazwy prawne i adresy podprocesorów (do umowy powierzenia): uzupełnić z umów z dostawcami.

Dane firm sprawdzamy w publicznych rejestrach (biała lista VAT, CEIDG, KRS), przekazując im jedynie NIP, numer KRS albo numer rachunku.

Retencja i usuwanie

Pliki przesyłek

do wygaśnięcia (najdłużej 30 dni), wykorzystania limitu pobrań albo cofnięcia; potem trwale usuwane razem z kluczami

Niedokończone wysyłki

usuwane po 24 godzinach

Prośby o pliki

link ważny do wybranego terminu (najdłużej 30 dni); po przesłaniu plików, anulowaniu albo wygaśnięciu treść prośby i klucz są usuwane

Pliki od klientów (z próśb)

do terminu z prośby (najdłużej 30 dni od przesłania) albo usunięcia przez osobę proszącą; potem trwale usuwane razem z kluczami

Historia przesyłki i prośby o pliki

6 lat od usunięcia plików, potem usuwana w całości

Kopie zapasowe bazy

14 dni

Kopia zapasowa plików

kopia lustrzana; plik usunięty z serwisu znika z kopii najpóźniej po 24 godzinach

Sesje logowania

do wylogowania, najdłużej 14 dni

Zgłoszenia z formularza testów

1 rok

Do ustalenia: Okres przechowywania dzienników serwera (logi kontenerów w Coolify): ustalić i wpisać.

Logowanie i monitoring

• Dzienniki aplikacji w formacie JSON bez treści plików, kodów dostępu i haseł (pola wrażliwe są maskowane).
• Adres IP w dzienniku zdarzeń przesyłki zapisujemy wyłącznie jako skrót.
• Zdarzenia każdej przesyłki (wysłanie, kod, otwarcie, pobranie, usunięcie) w dzienniku z łańcuchem skrótów, który ujawnia późniejsze zmiany; działania operatora usługodawcy w osobnym dzienniku.

Do ustalenia: Monitoring dostępności i alerty (narzędzie, kto dostaje alarmy, w jakim czasie): ustalić i wpisać.

Zarządzanie podatnościami i aktualizacje

• Biblioteki: automatyczne cotygodniowe propozycje aktualizacji (Dependabot), łatki bezpieczeństwa niezwłocznie.
• Każda zmiana jest sprawdzana w CI automatycznymi testami: jednostkowymi, integracyjnymi, end-to-end i dostępności.
• Obrazy kontenerów są budowane od nowa przy każdym wdrożeniu.
• System serwera: codzienne automatyczne łatki bezpieczeństwa (unattended-upgrades), pełna aktualizacja co miesiąc.

Do ustalenia: Zewnętrzny test penetracyjny: brak, decyzja biznesowa (zakres, termin, wykonawca).

Kopie zapasowe i ciągłość działania

• Kopia bazy danych co najmniej raz dziennie do magazynu S3 we Frankfurcie, przechowywana 14 dni.
• Codzienna kopia lustrzana zaszyfrowanych plików z Warszawy do Frankfurtu, bez wersjonowania.
• Klucz serwera i klucz podpisu przechowywane poza kopiami zapasowymi; kopia bez klucza nie pozwala odczytać danych.
• Test odtworzenia z kopii raz na kwartał według procedury w dokumentacji wdrożenia.
• Maksymalna utrata danych przy awarii (RPO): do 24 godzin.

Do ustalenia: Pierwszy test odtworzenia: wykonać przed startem produkcji i wpisać datę.

Do ustalenia: Docelowy czas przywrócenia działania (RTO): ustalić i wpisać.

Incydenty bezpieczeństwa

• O incydencie dotyczącym danych Organizacji powiadamiamy jej administratorów mailem w ciągu 24 godzin od jego stwierdzenia: co się stało, jakich danych dotyczy, co zrobiliśmy i co zalecamy.
• Jako podmiot przetwarzający wspieramy Organizację w zgłoszeniu naruszenia do UODO i zawiadomieniu osób (art. 33 i 34 RODO).
• Incydenty i podejrzane wiadomości podszywające się pod serwis prosimy zgłaszać na security@wyslijbezpiecznie.pl.

Zgłaszanie podatności

Podatności prosimy zgłaszać na security@wyslijbezpiecznie.pl (dane kontaktowe także w /.well-known/security.txt), bez publikowania szczegółów przed wydaniem poprawki.

Do ustalenia: Czas potwierdzenia zgłoszenia i zasady wobec badaczy działających w dobrej wierze: ustalić i wpisać.

NIS2 i krajowy system cyberbezpieczeństwa

Usługa wspiera realizację środków z art. 21 ust. 2 NIS2 i art. 32 RODO przy przekazywaniu dokumentów: szyfrowanie (lit. h), uwierzytelnianie wieloskładnikowe i zabezpieczona komunikacja (lit. j), bezpieczeństwo łańcucha dostaw (lit. d: umowa powierzenia, lista podprocesorów, dane w UE).

Sama usługa nie czyni organizacji zgodną z przepisami: system zarządzania bezpieczeństwem, analiza ryzyka i zgłaszanie incydentów pozostają obowiązkiem podmiotu.

Dokumenty

• Wzór umowy powierzenia przetwarzania: /umowa-powierzenia
• Polityka prywatności: /polityka-prywatnosci
• Regulamin: /regulamin
• Specyfikacja szyfrowania WB1: /bezpieczenstwo/wb1
• Deklaracja dostępności: /dostepnosc

Jak działa szyfrowanie: szczegóły

Pliki są szyfrowane na komputerze nadawcy, zanim go opuszczą. Do otwarcia przesyłki potrzebne są dwie rzeczy, które idą różnymi drogami: link z maila i kod dostępu. Poniżej opisujemy, jak to działa, co to daje i czego szyfrowanie nie obejmuje.

Krok po kroku

1. Szyfrowanie u nadawcy. Przeglądarka (albo program dla Windows) losuje klucz przesyłki i szyfruje nim pliki algorytmem AES-256-GCM. Na serwer trafia wyłącznie szyfrogram. Nazwy plików i wiadomość dla odbiorcy też są zaszyfrowane.
2. Klucz każdego odbiorcy z dwóch części. Dla każdego odbiorcy powstają dwie losowe części: A i B. Dopiero razem dają klucz, który otwiera przesyłkę.
3. Część A w linku. Link w mailu wygląda tak: wyslijbezpiecznie.pl/o/r_…#część-A. Fragment po znaku # przeglądarka zatrzymuje u siebie i nie wysyła go do serwera przy otwieraniu strony.
4. Część B na serwerze. Przechowujemy ją dodatkowo zaszyfrowaną kluczem serwera i wydajemy dopiero po podaniu poprawnego kodu.
5. Kod osobnym kanałem. Odbiorca dostaje 6-cyfrowy kod SMS-em, na drugi adres e-mail albo od nadawcy telefonicznie. Kod nie jest częścią klucza: to przepustka do części B.
6. Odszyfrowanie u odbiorcy. Po wpisaniu kodu przeglądarka odbiorcy dostaje część B, składa klucz i odszyfrowuje pliki u siebie. Część A strona od razu usuwa z paska adresu i historii.
7. Usunięcie. Po wygaśnięciu przesyłki, wykorzystaniu limitu otwarć albo cofnięciu przez nadawcę usuwamy pliki i część B. Od tej chwili link z maila jest bezużyteczny, nawet jeśli ktoś go później zdobędzie.

Dwa tryby wysyłki linku

Dlaczego 6-cyfrowy kod wystarcza

• Sam kod nic nie daje. Bez linku z maila (część A) nie ma czego odszyfrować. Trzeba by przejąć jednocześnie skrzynkę i telefon odbiorcy.
• Nie da się go zgadywać. Po 5 błędnych próbach dostęp odbiorcy się blokuje, a nadawca dostaje powiadomienie. Szansa na trafienie to 5 na milion (0,0005%). Dodatkowo ograniczamy liczbę prób z jednego adresu IP.
• Nie da się go łamać „u siebie”. Kod nie jest częścią klucza, więc nawet wykradziona baza i szyfrogramy nie pozwalają sprawdzać kodów poza naszym serwerem. Każda próba przechodzi przez limit.
• Kod nie zostaje w bazie. Kody wysyłane SMS-em i e-mailem przechowujemy tylko jako skrót (HMAC). Kod do podyktowania przechowujemy zaszyfrowany, żeby nadawca mógł go odczytać w historii wysyłek.

Tak samo działają kody w bankowości: krótki kod jest bezpieczny, bo ma limit prób.

Czego szyfrowanie nie chroni

Żadne zabezpieczenie nie jest absolutne. Uczciwie opisujemy granice:

• Przejęcie obu kanałów. Kto ma jednocześnie link z maila odbiorcy i jego kod (np. przejął skrzynkę i telefon), otworzy przesyłkę jak odbiorca.
• Nieuczciwy lub przejęty serwer. W trybie standardowym serwer w chwili wysyłki maila ma na moment wszystkie części potrzebne do odszyfrowania. Poza tym, jak w każdej aplikacji szyfrującej w przeglądarce, kod strony dostarcza nasz serwer, więc przejęty serwer mógłby podać zmieniony skrypt. Ograniczamy to ryzyko: strona nie wczytuje żadnych skryptów firm trzecich, a ścisła polityka bezpieczeństwa treści (CSP) nie pozwala jej wysyłać danych do innych domen. Przed nieuczciwym operatorem w chwili wysyłki chroni tryb maksymalnej poufności, a po stronie nadawcy także program dla Windows.
• Firmowe filtry poczty. Część dostawców poczty (np. Microsoft Safe Links) przepisuje linki w mailach razem z częścią A. Bez kodu taki link nadal nie otwiera przesyłki.
• Metadane. Aby dostarczyć przesyłkę, widzimy, kto, do kogo i kiedy ją wysyła, liczbę i rozmiar plików, adresy e-mail i numery telefonów do kodów. Znamy też skróty SHA-256 plików, bo na nich opiera się metryka i weryfikacja: pozwalają potwierdzić, że wysłano konkretny plik, który ktoś już ma, ale nie pozwalają odtworzyć treści. Nie widzimy treści ani nazw plików.
• Urządzenia i dalszy los plików. Szyfrowanie nie chroni przed złośliwym oprogramowaniem na komputerze nadawcy lub odbiorcy ani przed tym, co odbiorca zrobi z pobranymi plikami.
• Celowa blokada. Osoba, która ma link, może celowo wpisać złe kody i zablokować dostęp odbiorcy. Nadawca wysyła wtedy nowy kod.

Dobre praktyki dla nadawcy

• Wysyłaj kod SMS-em. Drugi adres e-mail jest słabszy, zwłaszcza w tej samej firmie albo na tym samym telefonie; panel ostrzega, gdy oba adresy są w tej samej domenie.
• Najbardziej wrażliwe dokumenty wysyłaj w trybie maksymalnej poufności.
• Ustawiaj krótką ważność przesyłki i mały limit otwarć.
• Włącz weryfikację dwuetapową konta, a w firmie ustaw ją jako obowiązkową.

Dla specjalistów

• Szyfrowanie: AES-256-GCM, kawałki po 4 MiB, osobny klucz na plik (HKDF-SHA-256).
• Klucz odbiorcy: KEK = HKDF(A ‖ B, sól), A i B po 256 bitów; klucz przesyłki owinięty KEK z identyfikatorem odbiorcy jako danymi uwierzytelnianymi.
• Część B zaszyfrowana kluczem serwera; identyfikatory linków losowe (96 bitów).
• Kody: losowane kryptograficznie, porównywane przez HMAC w stałym czasie, 5 prób na odbiorcę.
• Strona: ścisła polityka CSP (tylko własne skrypty, połączenia tylko z własną domeną), HSTS, brak analityki i skryptów firm trzecich.
• Zapis wysyłki: skróty SHA-256 plików i dane nadawcy podpisane kluczem Ed25519 platformy; pobrany plik sprawdzisz na stronie Sprawdź plik.

Pełna specyfikacja formatu szyfrowania: WB1, z wektorami testowymi do sprawdzenia własnej implementacji. Błędy bezpieczeństwa prosimy zgłaszać na adres kontakt@wyslijbezpiecznie.pl.