Współczesna architektura bezpieczeństwa sieci komputerowych to złożony ekosystem protokołów, mechanizmów kryptograficznych oraz infrastruktur zarządzania tożsamością i zaufaniem. W centrum znajdują się cztery kluczowe komponenty, które razem tworzą spójny system ochrony danych przesyłanych przez sieci publiczne i prywatne:
- IPsec – bezpieczeństwo na warstwie sieciowej i transparentna ochrona ruchu IP;
- IKE – negocjacja parametrów i bezpieczna wymiana kluczy dla IPsec;
- PKI – zarządzanie certyfikatami i łańcuchami zaufania (X.509);
- SSL/TLS – szyfrowanie i uwierzytelnianie na wyższych warstwach (np. HTTPS).
Zrozumienie ich architektury, działania i zależności jest niezbędne do projektowania, wdrażania i utrzymania bezpiecznych środowisk sieciowych w organizacjach.
Podstawy bezpieczeństwa komunikacji sieciowej
Bezpieczeństwo komunikacji opiera się na zasadach kryptografii oraz mechanizmach uwierzytelniania, które zapewniają trzy filary ochrony:
- poufność,
- integralność,
- autentyczność.
Model bezpieczeństwa musi obejmować wszystkie warstwy – od fizycznej po aplikacyjną – z mechanizmami dopasowanymi do rodzaju danych i protokołów. Warstwa sieciowa (IPsec) jest szczególnie ważna, bo pozwala chronić cały ruch IP niezależnie od aplikacji.
Kryptografia symetryczna i asymetryczna to dwa podstawowe paradygmaty. Algorytmy symetryczne, takie jak AES (128/192/256), są bardzo wydajne i nadają się do szyfrowania danych w czasie rzeczywistym (10/12/14 rund odpowiednio dla kluczy 128/192/256). Kryptografia asymetryczna, reprezentowana przez RSA, wykorzystuje parę kluczy (publiczny/prywatny) do szyfrowania i podpisów cyfrowych.
Najważniejsze różnice między szyfrowaniem symetrycznym a asymetrycznym można podsumować następująco:
- zarządzanie kluczami – symetryczne wymaga bezpiecznego współdzielenia tajnego klucza; asymetryczne rozwiązuje dystrybucję przez klucze publiczne;
- wydajność – operacje asymetryczne są znacznie cięższe obliczeniowo od symetrycznych;
- rozmiary kluczy – typowo RSA 2048–4096 bitów ≈ bezpieczeństwo 128–256 bitów w szyfrach symetrycznych.
W praktyce stosuje się systemy hybrydowe: asymetria do uzgodnienia i uwierzytelnienia kluczy sesyjnych, a symetria do szyfrowania danych. Przykładami są SSL/TLS i IPsec z IKE.
Funkcje skrótu zapewniają integralność i uwierzytelnianie wiadomości (HMAC). MD5 i SHA‑1 są przestarzałe; współczesnym minimum jest SHA‑256.
Architektura protokołu IPsec
Internet Protocol Security to zestaw protokołów ochrony ruchu IP na warstwie sieciowej, zapewniający uwierzytelnianie, integralność, poufność i ochronę przed powtórzeniami. Przezroczystość dla aplikacji czyni IPsec idealnym fundamentem dla VPN, gdzie tunele między bramami chronią cały ruch bez zmian w aplikacjach.
IPsec składa się z dwóch głównych komponentów: AH i ESP. Authentication Header (AH) zapewnia uwierzytelnianie, integralność i ochronę anty‑replay, ale nie szyfruje danych. Encapsulating Security Payload (ESP) zapewnia integralność/uwierzytelnianie oraz szyfrowanie (poufność). ESP typowo korzysta z AES/AES‑GCM, a uwierzytelnianie z HMAC (np. HMAC‑SHA‑256/384/512).
Poniższe zestawienie ułatwia wybór właściwego mechanizmu:
| Aspekt | AH | ESP |
|---|---|---|
| Poufność | brak | tak (szyfrowanie danych) |
| Integralność/uwierzytelnianie | tak (HMAC‑MD5/SHA/SHA‑256/384/512) | tak (HMAC lub tryby AEAD, np. AES‑GCM) |
| Ochrona przed powtórzeniami | tak (numer sekwencyjny) | tak (numer sekwencyjny) |
| Widoczność nagłówka IP | zachowany/uwzględniany w MAC | zależna od trybu (transport/tunel) |
| Typowe zastosowanie | rzadko; gdy wymagana tylko integralność | domyślny wybór dla VPN |
Struktura nagłówka AH zawiera Security Parameters Index (SPI) oraz numer sekwencyjny do ochrony anty‑replay. SPI pozwala dobrać właściwe SA, algorytmy i klucze.
IPsec działa w trybie transportowym i tunelowym. Różnice podsumowuje tabela:
| Aspekt | Transport | Tunel |
|---|---|---|
| Zakres ochrony | dane i protokoły wyższych warstw | cały oryginalny pakiet IP (nagłówek + ładunek) |
| Widoczność oryginalnego nagłówka IP | widoczny | ukryty (nowy zewnętrzny nagłówek) |
| Narzut/rozmiar pakietu | niższy | wyższy |
| Zastosowanie | host‑to‑host | site‑to‑site, bramy bezpieczeństwa, ukrywanie topologii |
| Wymóg przy bramie | nie | tak (obowiązkowy) |
Koncepcja Security Association (SA) jest fundamentem IPsec. SA jest jednokierunkowe, więc dla pełnej komunikacji potrzeba co najmniej dwóch SA (kierunek w/out i in/coming). SA identyfikuje kombinacja:
- SPI,
- adres IP miejsca docelowego,
- protokół bezpieczeństwa (AH lub ESP).
Zarządzanie kluczami w IPsec wymaga precyzyjnego planowania. Dla ESP w obu kierunkach potrzeba co najmniej czterech kluczy (szyfrowanie + uwierzytelnianie na każdy kierunek). Klucze można ustawiać ręcznie lub negocjować dynamicznie przez IKE.
Protokół wymiany kluczy IKE
Internet Key Exchange automatyzuje ustanawianie, negocjację i zarządzanie SA dla IPsec. Łączy elementy Oakley i ISAKMP i opiera się na wymianie Diffie–Hellmana do bezpiecznego uzgodnienia sekretu i derywacji kluczy.
W IKEv1 negocjacja odbywała się dwuetapowo. Faza pierwsza tworzyła bezpieczny kanał (Main Mode lub Aggressive Mode), a Faza druga (Quick Mode) negocjowała SA dla IPsec i mogła zapewnić Perfect Forward Secrecy (PFS). Tryb agresywny ujawnia tożsamość i sprzyja atakom offline na PSK, dlatego nie jest zalecany.
IKEv2 upraszcza wymianę do czterech komunikatów, wzmacnia bezpieczeństwo i dodaje nowoczesne funkcje (np. NAT Traversal – UDP/4500, MOBIKE, EAP, mechanizmy anty‑DoS z COOKIE). Uproszczenie sprzyja poprawnej implementacji i certyfikacji (np. Common Criteria, FIPS 140‑2).
Najważniejsze różnice między IKEv1 a IKEv2 prezentuje zestawienie:
| Aspekt | IKEv1 | IKEv2 |
|---|---|---|
| Specyfikacja | RFC 2407/2408/2409 | RFC 4306 (i kolejne aktualizacje) |
| Wymiana początkowa | 4–6 pakietów, różne tryby | 4 komunikaty, jeden tryb |
| Ochrona tożsamości | Main Mode – tak; Aggressive – nie | domyślnie tak |
| NAT Traversal | rozszerzenia | natywnie (UDP/4500) |
| Mobilność | brak | MOBIKE |
| Uwierzytelnianie | PSK/podpisy | PSK/podpisy + EAP |
| Odporność na DoS | ograniczona | COOKIE po stronie respondera |
W IKE komunikat inicjalny to IKE_SA_INIT; w razie ataku DoS responder może wymagać ponowienia z wartością COOKIE.
Wymiana Diffie–Hellmana bazuje na trudności obliczeniowej problemu logarytmu dyskretnego. Zalecane są grupy co najmniej 2048‑bitowe, a używanie wspólnych 1024‑bitowych liczb pierwszych jest ryzykowne (po kompromitacji jednej wartości możliwe byłoby pasywne łamanie dużej części ruchu VPN/SSH).
Perfect Forward Secrecy (PFS) chroni klucze sesyjne na wypadek kompromitacji kluczy długoterminowych – osiąga się to przez efemeryczną wymianę DH i usuwanie materiału kluczowego po zakończeniu sesji.
Infrastruktura klucza publicznego PKI
Public Key Infrastructure to ludzie, polityki, procedury i systemy zapewniające uwierzytelnianie, szyfrowanie, integralność i niezaprzeczalność przy użyciu par kluczy i certyfikatów X.509 v3. PKI tworzy hierarchiczny łańcuch zaufania i stanowi fundament dla SSL/TLS, podpisów elektronicznych, S/MIME, podpisywania kodu i wielu usług IAM.
Podstawowe komponenty PKI są następujące:
- Certification Authority (CA) – wystawia, weryfikuje i unieważnia certyfikaty, podpisując je kluczem prywatnym CA;
- Registration Authority (RA) – weryfikuje tożsamość wnioskujących i przekazuje żądania do CA;
- subskrybenci/użytkownicy końcowi – generują pary kluczy i wykorzystują certyfikaty;
- infrastruktura PKI – oprogramowanie, repozytoria, listy CRL/OCSP, moduły HSM do ochrony kluczy.
Koncepcja łańcucha zaufania prowadzi od certyfikatu końcowego przez certyfikaty pośrednie do root CA. Certyfikaty pośrednie ograniczają skutki kompromitacji i upraszczają zarządzanie, bo łatwiej je wymienić niż root CA.
Certyfikaty końcowe służą m.in. do SSL/TLS, S/MIME, podpisywania i szyfrowania dokumentów oraz kodu. Organizacje mogą używać publicznie zaufanych certyfikatów lub wdrożyć prywatną CA dla potrzeb wewnętrznych – często tańszą i elastyczniejszą przy dużej skali.
Struktura certyfikatu X.509 obejmuje: tbsCertificate (treść podpisywana), Signature Algorithm oraz Signature Value. W tbsCertificate znajdują się m.in. pola poniżej:
- Version,
- Serial Number,
- Signature,
- Issuer,
- Validity (notBefore, notAfter),
- Subject,
- Subject Public Key Info,
- Extensions.
Pole Extensions kontroluje użycie certyfikatu (np. keyUsage, extendedKeyUsage), weryfikację ścieżki (basicConstraints) i wskazuje lokalizacje CRL/OCSP. Kodowanie binarne to BER/DER; do transportu tekstowego używa się Base64/PEM (.crt, .cer, .pem).
Zarządzanie cyklem życia certyfikatów można ująć w krokach:
- generacja pary kluczy przez podmiot (klucz prywatny w bezpiecznym środowisku);
- utworzenie i podpisanie CSR kluczem prywatnym;
- weryfikacja tożsamości przez RA/CA zgodnie z polityką;
- wystawienie i podpisanie certyfikatu przez CA oraz dystrybucja;
- eksploatacja, monitorowanie ważności i statusu (CRL/OCSP);
- odnowienie lub unieważnienie (suspend/revoke) i archiwizacja.
Weryfikacja certyfikatu obejmuje podpis cyfrowy, okres ważności, status CRL/OCSP i pełny łańcuch do zaufanego root CA. Kontrola łańcucha i poprawność podpisu to element krytyczny bezpieczeństwa.
Protokoły SSL i TLS
Secure Sockets Layer i Transport Layer Security zapewniają szyfrowanie, uwierzytelnianie i integralność między klientem a serwerem, działając pomiędzy warstwą transportową a aplikacyjną. Najbardziej rozpoznawalnym zastosowaniem jest HTTPS.
Kluczowym mechanizmem jest handshake, w którym strony negocjują parametry bezpieczeństwa i klucze sesyjne. Proces można streścić następująco:
- klient wysyła ClientHello (wersja TLS, losowość, identyfikator sesji, lista cipher suites);
- serwer odpowiada ServerHello (wybór wersji i szyfrów) i przesyła certyfikat X.509;
- klient weryfikuje certyfikat (podpis, CRL/OCSP, zgodność nazwy, ważność) – ochrona przed MITM;
- klient generuje pre‑master secret, szyfruje kluczem publicznym serwera i przesyła ClientKeyExchange;
- obie strony wyliczają master secret i derywują klucze sesyjne;
- wymiana ChangeCipherSpec i Finished – od tej chwili ruch jest szyfrowany i uwierzytelniany.
Po uzgodnieniu kluczy stosuje się szybkie szyfry symetryczne (np. AES‑GCM, ChaCha20‑Poly1305). SSLv2 i SSLv3 są niebezpieczne i niezalecane – standardem jest aktualny TLS.
