2026-04-16
Secure SharingTTL — Time To Live — to okno wygasania bezpiecznego linku. Złe ustawienie w którąkolwiek stronę ma realne konsekwencje dla bezpieczeństwa.
Wygasły link to niedostępny link. TTL zamienia czas w granicę bezpieczeństwa.
TTL — Time To Live — to czas, po którym bezpieczny link staje się trwale niedostępny, niezależnie od tego, czy był kiedykolwiek otwierany. To nie jest tylko funkcja wygody; to twarda granica bezpieczeństwa. Wygasłego linku nie można otworzyć, przekazać ani odtworzyć — nawet jeśli adres URL jest nienaruszony.
Krótki TTL (5–30 minut) to właściwy wybór dla jednorazowych danych uwierzytelniających: tymczasowych haseł, kodów odzyskiwania dwuskładnikowego lub kluczy API przekazywanych podczas rozmowy o wdrożeniu. Okno jest wystarczająco długie dla prawdziwego odbiorcy w tej samej rozmowie, a zbyt krótkie, by było użyteczne po przechwyceniu kilka minut później.
Średni TTL (24–72 godziny) sprawdza się w przepływach asynchronicznych, gdy odbiorca może być w innej strefie czasowej lub potrzebuje czasu na działanie: projekt umowy do przejrzenia, dane wynagrodzenia udostępniane działowi HR lub dane dostępowe do środowiska stagingowego.
Długi TTL (30–90 dni) jest odpowiedni dla wolniejszych procesów — recenzji dokumentów prawnych, pakietu onboardingowego dla nowego pracownika lub współdzielonego sekretu, do którego mały zespół potrzebuje dostępu raz w ciągu kwartału.
Najczęstszy błąd zespołów polega na ustawianiu TTL z przyzwyczajenia zamiast według realnej ekspozycji. Jeśli sekret jest przydatny przez 15 minut, ale pozostaje dostępny przez 30 dni, to faktyczna polityka dostępu wynosi 30 dni, a nie 15 minut. TTL powinien odzwierciedlać operacyjny czas życia informacji, a nie wygodę nadawcy.
W przypadku każdych aktywnie używanych danych uwierzytelniających: połącz TTL z burn-after-reading. Dwie niezależne ścieżki zniszczenia — czas i pierwsze otwarcie — oznaczają, że sekret nie przeżyje dłużej niż to konieczne w żadnym scenariuszu.
Praktyczne scenariusze
Najczęstszy problem nie polega na tym, że zespoły nie używają TTL, tylko że wybierają go automatycznie, bez związku z rzeczywistym czasem przydatności informacji.
Jeżeli odbiorca czeka po drugiej stronie rozmowy lub czatu, ustaw TTL liczony w minutach, nie dniach. Taki sekret ma sens tylko przez chwilę i nie powinien żyć dłużej niż sama czynność, której dotyczy.
Przy projektach umów, dokumentach HR albo paczkach onboardingowych sensowniejsze są godziny lub 1–3 dni. Odbiorca potrzebuje czasu, ale nie ma powodu, by dostęp pozostawał otwarty tygodniami.
Jeśli kilka osób ma realnie skorzystać z informacji w dłuższym oknie, TTL powinien pokrywać tylko ten konkretny projekt lub etap wdrożenia. Długi dostęp bez kontekstu szybko zamienia się w nieformalny magazyn haseł.
Krótkotrwałe wiadomości (≤24h) są przechowywane w Redis z natywnym TTL — Redis usuwa je automatycznie po wygaśnięciu. Długotrwałe wiadomości są przechowywane w PostgreSQL, a zadanie czyszczące uruchamia się co godzinę, usuwając rekordy, których expires_at minął.
Nie. TTL jest ustawiany przy tworzeniu i nie można go modyfikować. Jeśli odbiorca potrzebuje więcej czasu, utwórz nowy bezpieczny link z dłuższym oknem.
Najkrótszy możliwy jest najbezpieczniejszym domyślnym wyborem, ale tylko jeśli jest realistyczny dla Twojego odbiorcy. Link, który wygasa zanim odbiorca sprawdzi wiadomości, nie spełnia swojego celu. Dopasuj TTL do swojego rzeczywistego wzorca komunikacji.
Nie. TTL ogranicza czas, przez jaki sekret pozostaje dostępny. Szyfrowanie kontroluje, kto może go odczytać, gdy jeszcze istnieje. Bezpieczne udostępnianie potrzebuje obu elementów: szyfrowania dla poufności i TTL dla redukcji ekspozycji.
Czytaj dalej
2026-04-24
WeTransfer i podobne usługi mogą odczytać każdy plik, który wgrywasz. Oto kogo to dotyczy, dlaczego ma znaczenie i jak działa udostępnianie plików zero-knowledge.
2026-03-28
E-mail powstał w 1971 roku do przesyłania tekstu między terminalami. Nigdy nie był zaprojektowany z myślą o poufności — a te pięć scenariuszy boleśnie to pokazuje.
2026-03-20
Wiadomość, która usuwa się po przeczytaniu, brzmi jak motyw z filmu szpiegowskiego. Oto techniczna rzeczywistość — i dlaczego jest bardziej niezawodna niż myślisz.