Kryptografia, TLS i VPN

• Rozróżnisz szyfrowanie symetryczne, asymetryczne, funkcję skrótu i podpis cyfrowy.
• Wyjaśnisz rolę certyfikatu, urzędu certyfikacji i łańcucha zaufania.
• Opiszesz, jak TLS łączy uwierzytelnienie z ustanowieniem chronionej sesji.
• Porównasz ochronę TLS i VPN bez traktowania ich jako zabezpieczenia przed wszystkim.
• Zaplanujesz inwentaryzację, ochronę, rotację i unieważnianie kluczy.

Wymagania wstępne

• Modele OSI i TCP/IP
• TCP, UDP i porty
• DNS
• Sieci WAN i VPN
• Podstawy bezpieczeństwa sieci

Do przechowywania haseł nie stosuje się szyfrowania odwracalnego ani szybkiego, ogólnego SHA bez odpowiedniej konstrukcji. Używa się sprawdzonych funkcji przeznaczonych do haseł, z unikalną solą i parametrami dobranymi zgodnie z aktualną dokumentacją platformy.

Certyfikat klucza publicznego wiąże tożsamość, na przykład nazwę DNS, z kluczem publicznym i okresem ważności. Urząd certyfikacji (Certification Authority, CA) podpisuje certyfikat zgodnie ze swoją polityką. Klient buduje ścieżkę od certyfikatu końcowego przez pośrednie CA do lokalnie zaufanego korzenia.

Walidacja nie polega tylko na sprawdzeniu podpisu. Klient ocenia nazwę, czas ważności, przeznaczenie klucza, ograniczenia ścieżki, zaufany korzeń i dostępne informacje o unieważnieniu. Certyfikat samopodpisany może być poprawny technicznie, ale nie staje się z tego powodu zaufany dla klienta.

TLS (Transport Layer Security) działa nad niezawodnym transportem i chroni dane aplikacji, na przykład HTTPS. W TLS 1.3 strony uzgadniają parametry, ustanawiają klucze sesji, a serwer zwykle przedstawia łańcuch certyfikatów i dowód posiadania klucza prywatnego. Po poprawnej weryfikacji dalsze rekordy są chronione mechanizmem uwierzytelnionego szyfrowania.

W praktyce asymetryczne mechanizmy i podpisy pomagają uwierzytelnić oraz ustanowić sekret, a szybkie szyfrowanie symetryczne chroni właściwy ruch. Klucze sesji są odrębne od długoterminowego klucza certyfikatu.

VPN tworzy chroniony tunel przez niezaufaną sieć, lecz nie oznacza automatycznego zaufania do użytkownika, urządzenia i całego ruchu. Potrzebne są uwierzytelnianie, minimalne trasy, polityki dostępu, aktualizacje klienta oraz monitoring.

Rotacja nie pomaga, jeśli stary klucz nadal działa bez ograniczeń. Po podejrzeniu kompromitacji trzeba określić zasięg, unieważnić zaufanie, rozprowadzić nowy materiał, sprawdzić zależności i przeanalizować wcześniejsze użycie klucza.

Firma udostępnia panel zamówień przez HTTPS i VPN dla administratorów. Właściciel usługi prowadzi rejestr domeny, certyfikatu, CA, daty wygaśnięcia, miejsca przechowywania klucza i procedury odnowienia. Monitoring ostrzega z wyprzedzeniem, a odnowienie jest testowane na środowisku kontrolnym.

Klucz prywatny panelu nie trafia do dokumentacji ani zwykłego repozytorium. VPN daje administratorom tylko potrzebne trasy, wymaga MFA i zarządzanego urządzenia. Certyfikat TLS chroni kanał, ale aplikacja nadal wymaga aktualizacji, autoryzacji i rejestrowania działań.

• Nie projektuj własnego algorytmu, trybu szyfrowania ani protokołu wymiany kluczy; używaj utrzymywanych bibliotek i bezpiecznych ustawień platformy.
• Nie wyłączaj walidacji certyfikatu, nazwy lub czasu w celu usunięcia ostrzeżenia.
• Szyfrowanie danych w tranzycie nie chroni ich po odszyfrowaniu na przejętej końcówce.
• Hash potwierdza zgodność danych tylko względem zaufanej wartości odniesienia; napastnik może podmienić plik i niezabezpieczony hash razem.
• Wyciek klucza, błędne uprawnienia i brak rotacji mogą zniweczyć silny algorytm.

• Nazywanie hashowania szyfrowaniem albo oczekiwanie, że hash można odszyfrować.
• Przesyłanie klucza prywatnego pocztą, w komunikatorze lub repozytorium kodu.
• Traktowanie ikony kłódki jako potwierdzenia uczciwości właściciela strony.
• Brak inwentaryzacji dat wygaśnięcia, zależności i planu unieważnienia.
• Uznanie VPN za pełne zabezpieczenie bez kontroli tożsamości, urządzenia i tras.

• Dlaczego TLS używa zarówno mechanizmów asymetrycznych, jak i symetrycznych?
• Co oprócz podpisu CA trzeba sprawdzić podczas walidacji certyfikatu serwera?
• Dlaczego zwykły hash pobrany z tej samej niezaufanej strony nie potwierdza pochodzenia pliku?
• Czym różni się unieważnienie klucza od planowej rotacji?
• Które zagrożenia pozostają mimo prawidłowego tunelu VPN?

Narysuj przepływ zaufania dla fikcyjnej usługi `portal.lab.test`: certyfikat końcowy, pośredni CA, zaufany korzeń, klient i magazyn klucza prywatnego. Dopisz właściciela, datę rotacji, sposób unieważnienia i trzy testy po odnowieniu. Nie generuj własnych algorytmów ani produkcyjnych kluczy.

1. Przyporządkuj poufność, integralność i uwierzytelnienie do szyfrowania, HMAC, podpisu oraz certyfikatu, wskazując ograniczenia każdego mechanizmu.
2. Przeanalizuj ostrzeżenie certyfikatu w fikcyjnym LAB-CYBER: nazwa, czas, łańcuch, przeznaczenie i zaufany korzeń. Nie dodawaj certyfikatu do zaufanych.
3. Przygotuj rejestr pięciu kluczy lub certyfikatów małej firmy bez zapisywania samych sekretów.

• Szyfrowanie, hash, MAC i podpis cyfrowy rozwiązują różne problemy i nie są zamienne.
• Zaufanie do certyfikatu wynika z poprawnej walidacji całej ścieżki i tożsamości usługi.
• TLS oraz VPN chronią komunikację w określonym zakresie, ale nie zastępują bezpieczeństwa aplikacji i końcówek.
• Bezpieczeństwo kryptografii zależy od sprawdzonej implementacji i pełnego cyklu życia kluczy.

• Sieci WAN i VPN
• DNS
• Wi-Fi
• Zagrożenia i ochrona sieci

• NIST SP 800-57 Part 1 Rev. 5 — Key Management
• RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 5280 — Internet X.509 PKI Certificate and CRL Profile
• OWASP — Cryptographic Storage Cheat Sheet
• OWASP — Password Storage Cheat Sheet