wytyczne dotyczące UWIERZYTELNIANIA poczty e-mail

!! UWAGA !! Ten dokument został automatycznie przetłumaczony z języka włoskiego

Wytyczne

Konfiguracja usługi poczty elektronicznej do uwierzytelniania

Włoska Narodowa Agencja Cyberbezpieczeństwa opublikowała Wytyczne dotyczące konfiguracji poczty elektronicznej w celu uwierzytelniania. Mają one na celu zwiększenie niezawodności poczty elektronicznej dla wszystkich zainteresowanych organizacji oraz zwiększenie jej ogólnego poziomu bezpieczeństwa.

Kontrola wersji

INDEKS

1. Wprowadzenie

1.1. Założenie

Poczta e-mail stanowi obecnie jedną z najważniejszych usług w kontekście cyfrowym, ponieważ jest jednym z głównych kanałów wykorzystywanych przez organizacje i użytkowników do komunikacji i wymiany informacji¹.

Funkcjonowanie usługi poczty elektronicznej, a w szczególności przesyłanie wiadomości, opiera się na protokole SMTP, który jednak nie zawiera natywnych mechanizmów uwierzytelniania nadawcy ani ochrony poufności i integralności wiadomości. Luki te narażają ją na ryzyko ataków takich jak spoofing, phishing, manipulacja i przechwytywanie wiadomości w trakcie transmisji.

Aby ograniczyć słabości protokołu SMTP i tym samym ograniczyć ryzyko wynikające ze wspomnianych ataków, z czasem opracowano mechanizmy uwierzytelniania nadawcy i ochrony integralności wiadomości, takie jak SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) i DMARC (Domain-based Message Authentication, Reporting and Conformance).

W niniejszych wytycznych zilustrowano te mechanizmy, których celem jest wzmocnienie niezawodności usługi poczty elektronicznej i podniesienie jej ogólnego poziomu bezpieczeństwa, ze szczególnym uwzględnieniem zagrożeń opisanych w rozdziale 4.

Środki zaradcze i protokoły niezbędne do ochrony poufności wiadomości e-mail (takie jak S/MIME i OpenPGP dotyczące szyfrowania wiadomości) nie są przedmiotem niniejszych wytycznych.

1.2. Przepisy referencyjne

1.3. Dokumenty referencyjne

» powrót na górę

2. Kontekst regulacyjny

Aby chronić cyfrowe zasoby kraju, w tym usługi poczty elektronicznej i infrastrukturę, na której się one znajdują, wdrożono i stale aktualizowano szeroką gamę środków bezpieczeństwa opracowanych na podstawie obowiązujących przepisów.

Najwyższy poziom ochrony najważniejszych usług kraju, związanych z ochroną bezpieczeństwa narodowego, zapewnia Krajowy Perymetr Cyberbezpieczeństwa, ustanowiony dekretem-ustawą z dnia 21 września 2019 r. nr 105, przekształconym ze zmianami ustawą z dnia 18 listopada 2019 r. nr 133. Zapewnia on środki bezpieczeństwa o szczególnie wysokim poziomie ochrony, szczegółowo opisane w załączniku B do dekretu Prezesa Rady Ministrów z dnia 14 kwietnia 2021 r. nr 81, które mają zastosowanie do sieci, systemów informatycznych i usług informatycznych podmiotów publicznych i prywatnych, od których zależy wykonywanie istotnej funkcji państwa lub świadczenie istotnej usługi w celu utrzymania działalności cywilnej, społecznej lub gospodarczej, fundamentalnej dla interesów państwa, której naruszenie mogłoby skutkować naruszeniem bezpieczeństwa narodowego.

Ponadto usługi poczty elektronicznej, podobnie jak wszystkie usługi cyfrowe administracji publicznej, podlegają przepisom tzw. Rozporządzenia w sprawie chmury, przyjętego zgodnie z artykułem 33-septies Dekretu-Ustawy z dnia 18 października 2012 r. nr 179 i zaktualizowanego przez Narodową Agencję Cyberbezpieczeństwa (ACN) Dekretem Dyrektora nr 21007 z dnia 27 czerwca 2024 r. Zgodnie z wyżej wymienionym Rozporządzeniem wszystkie administracje publiczne są zobowiązane do klasyfikowania swoich danych i usług cyfrowych jako zwykłych, krytycznych lub strategicznych, zgodnie z modelem opracowanym przez ACN. Działanie to ma na celu zapewnienie, że dane cyfrowe i usługi administracji publicznej są przetwarzane i dostarczane za pośrednictwem infrastruktury cyfrowej i usług w chmurze, które spełniają wymagania, w tym bezpieczeństwa, odpowiednie do ryzyka związanego z względnym poziomem klasyfikacji, zgodnie ze szczegółowym opisem w Rozporządzeniu.

Dekret ustawodawczy z dnia 4 września 2024 r. nr 138 (tzw. dekret NIS) transponujący dyrektywę (UE) 2022/2555 ustanowił również – poprzez załączniki 1 i 2 do decyzji ACN 379907/2025 – podstawowe środki bezpieczeństwa, które podmioty kluczowe i ważne przyjmują w celu wypełnienia obowiązków wynikających z art. 23 i 24 dekretu NIS, definiując ramy bezpieczeństwa w celu wzmocnienia ochrony systemów sieciowych i informatycznych, w tym usług poczty elektronicznej.

» powrót na górę

3. Architektura usług poczty elektronicznej

Jak zauważono w założeniu, funkcjonowanie usługi poczty elektronicznej opiera się na protokole SMTP, który reguluje przesyłanie wiadomości e-mail od nadawcy do odbiorcy.

Protokół SMTP został pierwotnie zdefiniowany w 1982 roku^[2] jako protokół typu „store-and-forward”, w którym nadawca generuje wiadomość za pośrednictwem swojego klienta pocztowego, w żargonie Mail User Agent (MUA), który wysyła ją do serwera pocztowego nadawcy. Ten, za pośrednictwem komponentu zwanego Mail Transfer Agent (MTA), przekazuje wiadomość, ewentualnie również przez jeden lub więcej pośredniczących MTA, dostarczając ją do MTA serwera pocztowego docelowego. Użytkownik-odbiorca uzyskuje dostęp do wiadomości za pośrednictwem swojego klienta pocztowego (MUA)[1].

MTA jest zatem składnikiem usługi poczty elektronicznej, który obsługuje przesyłanie wiadomości e-mail od nadawcy do odbiorcy. Składniki MTA znajdują się na serwerach pocztowych nadawcy i odbiorcy, a pośredniczące MTA można również skonfigurować, na przykład do zarządzania listami dystrybucyjnymi.

Mimo że termin MTA identyfikuje konkretny składnik serwerów poczty elektronicznej3^,to na potrzeby niniejszego dokumentu odwołujemy się do nich głównie w kontekście ich funkcji MTA, w przypadkach, w których nie ma dwuznaczności, dla uproszczenia wyjaśnienia często będzie używany termin serwer poczty elektronicznej zamiast bardziej szczegółowego terminu MTA.

W tych wytycznych skupiamy się na konfiguracji protokołów SPF, DKIM i DMARC, aby umożliwić serwerom pocztowym weryfikację autentyczności i integralności wiadomości e-mail.

» powrót na górę

4. Zagrożenia

Protokół SMTP przedstawiony w poprzednim rozdziale został pierwotnie zaprojektowany do działania w stosunkowo małej sieci akademickiej i nie uwzględniał aspektów związanych z bezpieczeństwem przesyłanych wiadomości czy uwierzytelnianiem nadawcy [1].

Rosnąca popularność poczty elektronicznej i wewnętrzne słabości protokołu SMTP z czasem przyczyniły się do pojawienia się ataków, których główne typy pokrótce zilustrowano w poniższych akapitach.

4.1. Podszywanie się pod nadawcę

Spoofing to technika cyberataku polegająca na fałszowaniu adresu nadawcy wiadomości tak, aby wydawała się pochodzić z wiarygodnego adresu (np. adresu współpracownika, znajomego lub banku). Ma to na celu nakłonienie odbiorcy do wykonania potencjalnie niebezpiecznych działań, takich jak otwarcie załącznika do wiadomości e-mail lub kliknięcie linków zawartych w wiadomości.

Tego typu atak jest stosunkowo prosty do przeprowadzenia, ponieważ protokół SMTP nie obejmuje mechanizmów uwierzytelniania nadawcy, dlatego też za pośrednictwem klienta poczty elektronicznej można skonfigurować dowolny adres nadawcy podczas nadawania wiadomości.

Adres e-mail nadawcy: koperta-od i wiadomość-od

Format wiadomości e-mail zawiera dwa oddzielne pola wskazujące adres e-mail nadawcy. Pola te noszą nazwy „ od koperty” i „od wiadomości”: pierwsze (nazywane również ścieżką powrotu, ponieważ określa adres e-mail, na który muszą zostać wysłane komunikaty o błędach generowane w przypadku niedostarczenia wiadomości e-mail do odbiorcy) to adres używany do prawidłowego przekierowania wiadomości, a drugie to adres wyświetlany przez odbiorcę w nagłówku otrzymanej wiadomości.

Analogicznie do wysyłania listu w kopercie tradycyjną pocztą, „nadawca ” oznacza adres nadawcy widniejący na kopercie listu, natomiast „nadawca ” odpowiada nagłówkowi znajdującemu się w liście, który wskazuje, kto napisał do adresata listu.

Należy pamiętać, że te dwa adresy mogą się nie pokrywać. To rozróżnienie pozwala na zarządzanie sytuacjami takimi jak przekazywanie wiadomości z usług zewnętrznych, dystrybucja za pośrednictwem list mailingowych czy automatyczne odpowiedzi e-mail.

Rzeczywiście, możliwe jest wskazanie dowolnego nadawcy zarówno na nadawcy wiadomości (adres e-mail nadawcy wyświetlany przez odbiorcę w nagłówku otrzymanej wiadomości), jak i na poziomie koperty nadawcy (adres e-mail nadawcy użyty do przesłania wiadomości).

Aby przeciwdziałać tym zagrożeniom, konieczne jest zatem zapewnienie mechanizmów, które pozwolą na wiarygodne uwierzytelnienie nadawcy i sprawdzenie, czy osoba wysyłająca wiadomość jest rzeczywiście do tego upoważniona.

4.2. Phishing

Phishing to technika cyberataków mająca na celu oszukańcze pozyskanie informacji (takich jak na przykład dane logowania, numery kart kredytowych lub inne poufne dane), zazwyczaj poprzez wysyłanie oszukańczych wiadomości, które udają, że pochodzą od wiarygodnych nadawców³.

Spoofing, omówiony w poprzednim akapicie, to jedna z głównych technik stosowanych przez atakujących w celu sfałszowania tożsamości nadawcy i sprawienia, aby wiadomość wydawała się pochodzić od legalnego użytkownika lub domeny.

Alternatywnie można użyć adresu/domeny nadawcy podobnego do adresu/domeny rozpoznawalnej przez odbiorcę, zmieniając na przykład tzw. nazwę wyświetlaną⁴ w celu wzmocnienia pozornej autentyczności wiadomości.

Do wysyłania wiadomości phishingowych mogą być wykorzystywane również legalne konta, które wcześniej zostały przejęte przez atakującego.

Treść wiadomości phishingowej zazwyczaj ma na celu wzbudzenie u odbiorcy poczucia pilności, alarmu lub zainteresowania ekonomicznego, stwarzając sytuacje skłaniające go do impulsywnej reakcji i wykonania określonych czynności, takich jak otwieranie złośliwych załączników lub klikanie łączy przekierowujących do pozornie legalnych stron internetowych, które w rzeczywistości zostały utworzone przez atakującego w celu kradzieży informacji i/lub zainstalowania złośliwego oprogramowania.

Zazwyczaj ataki phishingowe polegają na wysyłaniu tej samej wiadomości e-mail do dużej liczby ofiar, bez dostosowywania jej treści do konkretnego profilu ofiary.

Odmianą phishingu jest tzw. spear phishing, w którym atakujący zna profil ofiary i celowo go wykorzystuje.

W przeciwieństwie do typowego e-maila phishingowego, wiadomość spear phishing wykorzystuje bardziej precyzyjne informacje kontekstowe, aby przekonać użytkownika, że ​​wchodzi w interakcję z wiarygodnym nadawcą [2].

4.3. Manipulowanie wiadomościami

Treść wiadomości e-mail, podobnie jak każda inna komunikacja przesyłana przez sieć internetową, która nie korzysta z technik szyfrowania typu end-to-end (E2EE), może zostać przechwycona i zmodyfikowana w trakcie przesyłania między nadawcą a odbiorcą (taki typ zagrożenia powszechnie określa się mianem „man-in-the-middle”).

W konsekwencji, oprócz utraty poufności, otrzymana wiadomość może nie odpowiadać wiadomości pierwotnie napisanej przez nadawcę.

Napastnik może na przykład manipulować treścią wiadomości, tak aby sprawiała wrażenie, że pochodzi od wiarygodnego nadawcy, modyfikować tekst lub wszelkie łącza i/lub załączniki zawarte w wiadomości lub wstawiać złośliwy kod.

Odbiorca, ufając pozornej autentyczności wiadomości, może zostać nakłoniony do wykonania potencjalnie szkodliwych działań, takich jak podanie danych logowania, autoryzacja płatności lub otwarcie złośliwych plików.

Aby przeciwdziałać tym zagrożeniom, konieczne jest zatem wprowadzenie mechanizmów gwarantujących integralność i autentyczność wiadomości, dających pewność, że otrzymana treść nie została zmodyfikowana, a nadawca jest rzeczywiście tym, za kogo się podaje.

» powrót na górę

5. Środki zaradcze

W rozdziale 2 przypomniano przepisy, które przewidują środki bezpieczeństwa również w zakresie ochrony usług poczty elektronicznej. Niniejszy dokument ma przede wszystkim służyć jako przewodnik po wdrażaniu środków bezpieczeństwa przewidzianych w tych przepisach i wymienionych w Załączniku A, które są również istotne dla konfiguracji usług poczty elektronicznej, w celu ograniczenia ryzyka związanego z zagrożeniami omówionymi w rozdziale 4.Należy jednak zauważyć, że wskazówki zawarte w niniejszych wytycznych są zalecane również podmiotom, które nie podlegają wyżej wymienionym przepisom.

Omawiane środki bezpieczeństwa nie odnoszą się wprost do konfiguracji usługi poczty elektronicznej, lecz – w zależności od rozpatrywanego rozporządzenia – do konfiguracji systemów informatycznych i systemów sterowania przemysłowego (rozporządzenie PCSS i Cloud Regulation) lub systemów informatycznych i sieciowych (NIS2). Usługi poczty elektronicznej, będące przedmiotem niniejszych wytycznych, zaliczają się do obu typów systemów.

W szczególności poniżej przedstawiono protokoły SPF , DKIM , DMARC , które zapewniają mechanizmy bezpieczeństwa mające na celu wzmocnienie ogólnego bezpieczeństwa usługi poczty elektronicznej, a w szczególności uwierzytelniania nadawcy i kontroli integralności wiadomości

5.1. Filtr SPF

SPF – Sender Policy Framework to protokół uwierzytelniania sformalizowany przez RFC 7208, który umożliwia właścicielowi domeny określenie, które adresy IP są upoważnione do wysyłania wiadomości e-mail w jego imieniu, a także ustanowienie zasad, które odbiorca musi zastosować, jeśli adres IP powiązany z domeną⁵ adresu e-mail nadawcy nie znajduje się wśród adresów wyraźnie upoważnionych.

Autoryzowane adresy IP są wymienione w rekordzie DNS TXT odnoszącym się do domeny nadawcy, nazywanym rekordem SPF, i zilustrowane w dalszej części tego akapitu.

W ten sposób serwer poczty e-mail odbiorcy⁶ po otrzymaniu wiadomości z danej domeny może sprawdzić powiązany rekord SPF i uwierzytelnić jego pochodzenie, sprawdzając, czy adres IP, z którego odebrano wiadomość, należy do adresów upoważnionych do wysyłania wiadomości w imieniu domeny.

Należy zauważyć, że domeną weryfikowaną na poziomie SPF jest domena odnosząca się do koperty nadawcy, w związku z czym samo przyjęcie protokołu SPF nie wystarczy do przeciwdziałania podszywaniu się, ponieważ tego typu ataki mogą być przeprowadzane na poziomie wiadomości nadawcy⁷.

W przypadku gdy organizacja zleca, w całości lub w części, obsługę poczty elektronicznej podmiotowi zewnętrznemu, na przykład dostawcy usług w chmurze, musi upewnić się, że wiadomości wysyłane przez takich dostawców przechodzą weryfikację SPF. W tym celu organizacja powinna uwzględnić w swoim rekordzie SPF adresy IP, z których dostawcy wysyłają wiadomości e-mail w imieniu domeny organizacji.

W przypadku automatycznego przekierowywania wiadomości e-mail, ponieważ wiadomości są zazwyczaj przekierowywane przez serwer pośredniczący, adres IP, który ostatecznie dostarcza wiadomość, nie pokrywa się z adresem pierwotnie autoryzowanym przez domenę nadawcy. W takich przypadkach, aby uniknąć niepowodzenia weryfikacji SPF, konieczne jest autoryzowanie również pośrednich serwerów przekierowujących lub skorzystanie z mechanizmów takich jak SRS (Sender Rewriting Scheme) lub ARC (Authenticated Received Chain), które mogą być bardziej skuteczne, zwłaszcza w obecności wielu pośrednich serwerów przekierowujących.

Należy podkreślić, że aby SPF był naprawdę skuteczny, musi zostać poprawnie skonfigurowany nie tylko przez nadawcę, ale także przez odbiorcę. W szczególności:

• nadawca , deklarując adresy upoważnione do wysyłania wiadomości e-mail w jego imieniu;
• Odbiorca musi skonfigurować własny serwer pocztowy tak, aby mógł on przeprowadzać weryfikację SPF otrzymanych wiadomości i spójnie stosować wynikające z niej zasady .

5.1.1. Rekord SPF

Rekord SPF to rekord DNS typu TXT, którego nazwa odpowiada domenie nadawcy, a którego zawartość składa się z sekcji wskazującej wersję ⁸ oraz serii dyrektyw ^, które wskazują zachowanie serwera poczty odbiorcy w przypadku dopasowania adresu IP domeny nadawcy do dyrektywy.

Dyrektywy są tworzone przez mechanizm poprzedzony kwalifikatorem. Główne mechanizmy używane w rekordach SPF to: [2]:

• ip4, wyświetla autoryzowane adresy IPv4;
• ip6, wyświetla autoryzowane adresy IPv6;
• a, autoryzuje adresy IP obecne w rekordzie A domeny;
• mx, autoryzuje adresy IP odnoszące się do rekordów MX domeny;
• include, autoryzuje adresy IP obecne w rekordzie SPF innej domeny;
• all, reprezentuje wszystkie adresy IP, które nie zostały wyraźnie autoryzowane za pomocą innych mechanizmów.

W szczególności ten pozwala na ustalanie zasad dla wiadomości pochodzących z adresów IP, które nie zostały zadeklarowane przez poprzednie mechanizmy.

Ponadto SPF udostępnia następujące kwalifikatory umożliwiające powiązanie z mechanizmami:

• + (pass) oznacza, że ​​adresy IP pasujące do powiązanego mechanizmu są autoryzowane. Jest to domyślny kwalifikator, jeśli nie określono innego;
• - (niepowodzenie) oznacza, że ​​adresy IP pasujące do powiązanego mechanizmu nie są autoryzowane;
• ~ (softfail) oznacza, że ​​adresy IP pasujące do powiązanego mechanizmu prawdopodobnie nie są autoryzowane. Jest to mniej pewna deklaracja niż poprzednia. W takich przypadkach wiadomość powinna zostać zaakceptowana, ale oznaczona do bardziej szczegółowej analizy. Jest to używane na przykład w przypadku debugowania lub gdy przewiduje się, że weryfikacja SPF może się nie powieść;
• ? (neutralny) oznacza, że ​​nie podano żadnych wskazań dotyczących adresów IP pasujących do powiązanego mechanizmu. Domyślnym zachowaniem jest akceptacja wiadomości.

Warto podkreślić, że w praktyce rekord SPF jest tworzony w celu określenia autoryzowanych adresów IP, a następnie za pomocą dyrektywy -all określa się, że wszystkie pozostałe adresy nie są autoryzowane (w tym zakresie prosimy o zapoznanie się z poniższymi przykładami). Jest to zalecana konfiguracja, ponieważ pozwala ona na wyraźne wskazanie autoryzowanych adresów IP i wykluczenie wszystkich pozostałych.

W każdym razie zaleca się, aby nigdy nie używać dyrektywy +all (lub równoważnej all), ponieważ odpowiadałoby to autoryzacji wszystkich adresów IP.

Przykłady rekordów SPF

Autoryzuj określony adres IP

v=spf1 ip4:203.0.113.0 -all

Powyższy rekord SPF używa SPF w wersji 1 i autoryzuje za pomocą mechanizmu IP4 adres IP 203.0.113.0 (w rzeczywistości, ponieważ nie określono kwalifikatora dla mechanizmu IP4 , domyślnie używany jest domyślny znak + ). Dyrektywa -all utworzona przez mechanizm all i kwalifikator - (fail) oznacza, że ​​wszystkie pozostałe adresy nie są autoryzowane.

Autoryzuj określoną przestrzeń adresów IP

v=spf1 ip4:203.0.113.0/24 -all

Przedstawiony powyżej rekord SPF jest analogiczny do poprzedniego, ale autoryzuje wszystkie adresy IP z 203.0.113.0/24 .

Autoryzuj wiele adresów IP

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -all

Pokazany powyżej rekord SPF autoryzuje wyłącznie adresy IPv4 203.0.113.22 i 203.0.113.44.

Autoryzuj adresy rekordów MX i określoną domenę

v=spf1 mx include:spf.emailprovider.it -all

Pokazany powyżej rekord SPF autoryzuje wyłącznie adresy IP rekordów MX tej samej domeny co rekord SPF i autoryzuje adresy domeny spf.emailprovider.it (na przykład domeny dostawcy usług poczty e-mail).

5.1.2. Proces uwierzytelniania

Jeśli poprawnie skonfigurowano weryfikację SPF, serwer pocztowy odbiorcy po otrzymaniu nowej wiadomości e-mail pobiera rekord SPF domeny nadawcy, wysyłając zapytanie do serwera DNS zawierającego rekordy tej domeny, zgodnie z adresem podanym w polu „Nadawca”. Na przykład, jeśli adres podany w polu „Nadawca” to alice@example.com, serwer pocztowy odbiorcy pobiera rekord SPF domeny example.com.

Serwer pocztowy odbiorcy przeprowadza następnie weryfikację SPF, analizując rekord SPF w celu ustalenia, czy adres IP, z którego odebrano wiadomość, jest autoryzowany do wysyłania wiadomości e-mail dla example.com . Jeśli wiadomość e-mail przejdzie weryfikację SPF, zostanie dostarczona do odbiorcy.

Na przykład, gdyby rekord SPF domeny example.com miał postać v=spf1 ip4:203.0.113.22 -all, weryfikacja przebiegłaby pomyślnie tylko wtedy, gdyby adres IP serwera nadawcy wynosił 203.0.113.22, natomiast nie powiodłaby się w przypadku innych adresów.

» powrót na górę

5.2. DKIM

DKIM – DomainKeys Identified Mail to protokół uwierzytelniania sformalizowany przez RFC 6376, który umożliwia właścicielowi domeny zagwarantowanie autentyczności wysyłanych wiadomości e-mail poprzez dołączenie podpisu cyfrowego (podpisu DKIM) wygenerowanego przez serwer pocztowy za pośrednictwem publicznych algorytmów kryptograficznych i wstawionego do nagłówków wiadomości przeznaczonej do przesłania.

Aby umożliwić odbiorcy sprawdzenie, czy wiadomość nie została zmodyfikowana podczas transmisji, klucz publiczny skojarzony z podpisem DKIM jest zachowywany w rekordzie TXT publicznego serwera DNS domeny nadawcy, zwanym rekordem DKIM, który jest sprawdzany przez serwer pocztowy odbiorcy po odebraniu wiadomości.

Podpis i zapis DKIM zilustrowano w kolejnych sekcjach tego akapitu.

Podobnie jak w przypadku SPF, protokół DKIM musi zostać prawidłowo skonfigurowany przez nadawcę i odbiorcę, a w szczególności:

• nadawca musi skonfigurować swój serwer pocztowy w celu generowania podpisów DKIM i publikowania rekordu DKIM na odpowiednim serwerze DNS;
• Odbiorca musi skonfigurować swój serwer pocztowy tak, aby mógł przeprowadzać weryfikację DKIM otrzymanych wiadomości.

5.2.1. Podpis DKIM

Podpis DKIM jest generowany na podstawie wyznaczonych elementów treści wiadomości i nagłówków i składa się z serii par klucz-wartość, które określają następujące elementy:

• v: wersja protokołu¹⁰;
• a: użyty algorytm szyfrowania¹¹;
• d: podpisywanie domeny deklarującej autentyczność wiadomości¹²;
• s: selektor wskazujący, którego klucza publicznego DKIM należy szukać w rekordzie DNS¹³;
• h: lista nagłówków wiadomości e-mail zawartych w podpisie¹⁴;
• bh: skrót treści wiadomości zakodowany w formacie base64¹⁵;
• b: rzeczywisty podpis cyfrowy wygenerowany przy użyciu klucza prywatnego i zakodowany w formacie base64¹⁶;
• x: data ważności podpisu;
• c: typ kanonizacji.

Kanonizacja to proces normalizacji elementów wiadomości przed ich cyfrowym podpisaniem, aby zminimalizować wpływ drobnych modyfikacji, które mogą wystąpić podczas przesyłania, takich jak powtarzające się spacje czy podziały wierszy. Istnieją dwa rodzaje kanonizacji: prosta, która wymaga dokładnego dopasowania między wiadomością oryginalną a odebraną, oraz rozluźniona, która stosuje normalizacje takie jak usuwanie spacji, zamiana wielkich liter na małe w nagłówkach oraz redukcja liczby kolejnych pustych wierszy w treści wiadomości.

5.2.2. Rekord DKIM

Rekord DKIM jest zachowywany w rekordzie DNS typu TXT, którego nazwa ma strukturę selector._domainkey.domain, gdzie _domainkey to etykieta wskazująca, że ​​rekord DNS jest rzeczywiście rekordem DKIM. Zawartość rekordu DKIM składa się z serii par klucz-wartość, określających elementy, wśród których znajdują się:

• v: wersja protokołu;
• k: typ klucza, domyślnie RSA;
• p: klucz publiczny zakodowany w formacie base64.

Przykład rekordu DKIM

Nazwa: s1._domainkey.example.com
Wartość: v=DKIM1; k=rsa; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...

Przykładowy rekord DKIM jest powiązany z selektorem s1 domeny example.com , używa wersji 1 i zawiera klucz publiczny RSA zakodowany w formacie base64 ( Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h ... ).

5.2.3. Proces uwierzytelniania

Jeśli protokół DKIM jest poprawnie skonfigurowany zarówno na serwerach pocztowych nadawcy, jak i odbiorcy, działanie procesu uwierzytelniania i weryfikacji DKIM zakłada, że ​​serwer pocztowy nadawcy utworzy podpis DKIM wiadomości, zgodnie z opisem w punkcie 5.2.1, który zostanie dodany do samej wiadomości. W szczególności podpis DKIM zawiera w polu d domenę podpisującą¹⁷ , a w b podpis cyfrowy wiadomości wygenerowany przy użyciu klucza prywatnego domeny podpisującej.

Po odebraniu wiadomości serwer pocztowy odbiorcy pobiera rekord DKIM domeny podpisującej (d podpisu DKIM) z serwera DNS zawierającego rekordy tej domeny. Następnie używa klucza publicznego zawartego w rekordzie DKIM do weryfikacji podpisu cyfrowego (b ) zawartego w podpisie DKIM. Jeśli weryfikacja zakończy się pomyślnie, wiadomość jest dostarczana do odbiorcy.

5.2.4. Aspekty kryptograficzne

Na froncie kryptograficznym DKIM historycznie wykorzystywał RSA , szczególnie w rsa-sha256 , uważanym za standard od 2007 r. Nową alternatywą, wprowadzoną w RFC 8463, jest Ed25519-SHA256, nowoczesna forma podpisu cyfrowego oparta na krzywych eliptycznych, która gwarantuje większą wydajność i znacznie bardziej kompaktowe klucze.

Na poziomie technicznym RSA z kluczem o długości 2048 bitów pozostaje uniwersalnym standardem, ale klucze są długie, a podpisy stosunkowo duże, podczas gdy Ed25519 oferuje dziewięciokrotnie krótsze klucze i czterokrotnie mniejsze podpisy, a wydajność podpisywania jest nawet trzydziestokrotnie lepsza w porównaniu z RSA 2048. Pomimo tych zalet, rzeczywiste wsparcie jest ograniczone: w 2026 Ed25519 jest weryfikowany tylko przez kilku dostawców, a niektórzy główni operatorzy nie obsługują niezawodnie ani podpisywania, ani weryfikacji, co sprawia, że ​​nie nadaje się on jako jedyne rozwiązanie w środowisku produkcyjnym.

Z tego powodu, pomimo technicznej przewagi, w momencie pisania niniejszego dokumentu, stosowanie Ed25519 nie jest zalecane, chyba że w połączeniu z RSA, poprzez podwójny podpis, z perspektywy eksperymentalnej i jako przyszły środek zapewnienia kompatybilności. Dopóki główni dostawcy nie wdrożą w pełni tej weryfikacji, RSA pozostaje niezbędny do zagwarantowania maksymalnej pewności dostarczania wiadomości.

Jeśli chodzi o bezpieczeństwo długoterminowe, należy pamiętać, że ani RSA, ani Ed25519 nie są odporne na ataki przyszłych komputerów kwantowych [3], a przejście na algorytmy postkwantowe będzie wymagało nowych standardów DKIM, które obecnie nie istnieją, co sprawia, że ​​monitorowanie rozwoju kryptografii nowej generacji i przyszłych zaleceń ACN w tym obszarze staje się koniecznością.

Jeśli chodzi o zarządzanie kluczami kryptograficznymi, prywatny klucz DKIM musi być chroniony rygorystycznymi środkami bezpieczeństwa, poprzez przechowywanie go w odizolowanych systemach, do których dostęp mają wyłącznie upoważnione usługi, stosowanie ograniczonych uprawnień, okresową rotację i stałe monitorowanie w celu zapobiegania nieautoryzowanemu dostępowi lub naruszeniom.

» powrót na górę

5.3. DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) to protokół uwierzytelniania sformalizowany przez RFC 7489, który integruje^SPF i DKIM, umożliwiając właścicielowi domeny określenie odbiorcom wiadomości przesyłanych z tej domeny zasad zarządzania wiadomościami, które nie przejdą weryfikacji SPF i DKIM.

W szczególności protokół DMARC wprowadza mechanizm uwierzytelniania – zwany wyrównaniem – który weryfikuje zgodność między domenami uwierzytelnionymi przez SPF i DKIM a domeną powiązaną z „wiadomość nadawcy ” otrzymanej wiadomości. Należy pamiętać, że sprawdzenie zgodności między „wiadomość nadawcy” a domeną SPF/DKIM kończy się niepowodzeniem w każdym przypadku, gdy odpowiednia weryfikacja SPF/DKIM zakończy się niepowodzeniem (patrz rysunek 4).

Zgodność można zweryfikować w ścisłym , w którym wymagane jest dokładne dopasowanie domen uwierzytelnionych przez SPF/DKIM i domen powiązanych z polem wiadomości nadawcy , lub w trybie swobodnym, w którym wystarczy, że domeny podstawowe są zgodne, nawet jeśli subdomeny mogą się różnić.

Na przykład, w rozluźnionym dla domen sub1.example.com i sub2.example.com dopasowanie zostanie znalezione na potrzeby weryfikacji DMARC (ponieważ domena podstawowa, example.com, jest taka sama). Natomiast w ścisłym sprawdzenie dopasowania DMARC zakończy się niepowodzeniem z powodu braku dokładnego dopasowania między domenami.

Nawet jeśli atakujący zdoła przejść kontrolę SPF i/lub DKIM, używając wiadomości innej niż koperta, uwierzytelnionej przez SPF i/lub z uwierzytelnionej domeny podpisującej, dzięki weryfikacji zgodności protokół DMARC i tak wykryje rozbieżność, zapewniając spójne i niezawodne sprawdzenie tożsamości nadawcy [2].

Zasady zarządzania wiadomościami, które nie przejdą^weryfikacji DMARC, są określone w rekordzie TXT serwera DNS domeny nadawcy, nazywanym rekordem DMARC, i zilustrowane w dalszej części tego akapitu.

Protokół DMARC umożliwia również wskazanie odbiorcom wysyłania raportów do właścicieli domen nadawców, dotyczących wiadomości deklarujących pochodzenie z danej domeny. W ten sposób właściciel domeny może zweryfikować, czy jego domena jest używana w nieautoryzowany sposób i w jakim stopniu, analizując na przykład, ile wiadomości jest faktycznie do niego przypisanych w stosunku do wszystkich wiadomości deklarujących swoje pochodzenie.

Podobnie jak w przypadku SPF i DKIM, protokół DMARC musi zostać prawidłowo skonfigurowany przez nadawcę i odbiorcę, a w szczególności:

• nadawca musi opublikować rekord DMARC w swoim systemie DNS, określając w nim zasady zarządzania wiadomościami, które nie przejdą weryfikacji DMARC;
• Odbiorca musi skonfigurować swój serwer pocztowy tak, aby przeprowadzał weryfikację DMARC w przypadku otrzymanych wiadomości.

5.3.1. Rekord DMARC

Nazwa rekordu DMARC ma strukturę _dmarc.domain, gdzie _dmarc to etykieta wskazująca, że ​​rekord DNS jest rekordem DMARC, a domena to domena, do której odnosi się polityka.

Rekord DMARC składa się z serii par klucz-wartość określających elementy, wśród których znajdują się:

• v: protokół DMARC w wersji²⁰;
• p: polityka stosowana do wiadomości, które nie przeszły weryfikacji DMARC; może przyjąć jedną z wartości: none, quarantine, reject;
• aspf: tryb wyrównania stosowany do sprawdzania SPF (może być łagodny, o wartości domyślnej lub ścisły);
• adkim: tryb wyrównania stosowany do sprawdzania DKIM (może być łagodny, o wartości domyślnej lub ścisły);
• rua: adresy e-mail, na które będą wysyłane zbiorcze raporty zawierające informacje statystyczne i podsumowujące dotyczące wiadomości otrzymanych z domeny nadawcy;
• ruf: adresy e-mail, na które wysyłane są szczegółowe raporty dotyczące poszczególnych wiadomości otrzymanych z domeny nadawcy, które nie przeszły weryfikacji DMARC.

Przykład rekordu DMARC

Nazwa:
_dmarc.example.com
Wartość:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s

Przykładowy rekord DMARC jest powiązany z example.com , używa wersji 1 i określa odrzucania wiadomości, które nie przejdą weryfikacji DMARC, żądając ścisłego trybu (trybów) w celu weryfikacji zgodności domen SPF i DKIM oraz przesyłania raportów zbiorczych na adres e-mail dmarc-reports@example.com , a raportów o błędach na adres dmarc-fail@example.com.

5.3.2. Zasady DMARC

Jak opisano w poprzednim akapicie, rekord DMARC wskazuje politykę, którą serwer pocztowy odbiorcy powinien stosować w przypadku wiadomości, które nie przejdą weryfikacji DMARC. Możliwe są następujące polityki:

• brak: domena nadawcy nie podaje żadnych wskazówek dotyczących dostarczenia wiadomości, które nie przeszły weryfikacji DMARC;
• kwarantanna: domena nadawcy wskazuje, że wiadomości, które nie przejdą weryfikacji DMARC, należy uznać za podejrzane (np. poddać dalszej kontroli, potraktować jako spam lub oznaczyć jako podejrzane);
• odrzuć: domena nadawcy wskazuje, że wiadomości, które nie przejdą weryfikacji DMARC, powinny zostać odrzucone.

5.3.3. Proces weryfikacji i stosowania zasad

Jeśli protokół DMARC jest poprawnie skonfigurowany zarówno na serwerach pocztowych nadawcy, jak i odbiorcy, po odebraniu wiadomości serwer pocztowy odbiorcy pobiera rekordy SPF i DKIM w celu przeprowadzenia odpowiednich weryfikacji, a także weryfikacji DMARC (opisanej szczegółowo w incipicie paragrafu 5.2.4). W przypadku, gdy wiadomość nie przejdzie weryfikacji DMARC, stosowana jest polityka wskazana w rekordzie DMARC ( brak , kwarantanna lub odrzucenie )

Należy pamiętać, że każdy serwer pocztowy może stosować lokalne heurystyki i polityki, aby określić, czy wiadomość została dostarczona, czy nie, uwzględniając również wyniki weryfikacji SPF, DKIM i DMARC. Dlatego zazwyczaj po wyżej wymienionych weryfikacjach następuje dodatkowy proces decyzyjny („Filtr standardowy” na rysunku 5), który może obejmować również dalsze kontrole (na przykład filtry antyspamowe i antymalware).

Ponadto serwer poczty odbiorczej może przesyłać:

• na adresy wskazane w rua rekordu DMARC wysyłać raporty zbiorcze zawierające informacje statystyczne i podsumowujące dotyczące wiadomości otrzymanych z domeny nadawcy;
• na adresy wskazane w ruf rekordu DMARC wysyłane są szczegółowe raporty dotyczące poszczególnych wiadomości otrzymanych z domeny nadawcy, które nie przeszły weryfikacji DMARC.

» powrót na górę

6. Wnioski

Jak omówiono w poprzednim rozdziale, aby najlepiej przeciwdziałać zagrożeniom związanym z podszywaniem się pod domenę nadawcy, konieczne jest wspólne wdrożenie wszystkich trzech badanych protokołów, a w szczególności: [3]:

• domena nadawcy poprawnie publikuje rekordy SPF, DKIM i DMARC w DNS;
• serwer pocztowy nadawcy jest skonfigurowany do podpisywania wiadomości za pomocą protokołu DKIM;
• Serwer pocztowy odbiorcy jest skonfigurowany do przeprowadzania weryfikacji SPF i DKIM oraz stosowania zasad DMARC.

W odniesieniu do wdrażania protokołu sformułowano również następujące zalecenia: [2]:

• skonfiguruj SPF określając, które adresy IP są upoważnione do wysyłania wiadomości e-mail w imieniu domeny; w przypadku domen nieużywanych do przesyłania wiadomości e-mail, na przykład tych przeznaczonych wyłącznie dla stron internetowych, należy utworzyć rekord SPF, aby wyraźnie wskazać, że dla danej domeny nie ma prawidłowych nadawców wiadomości e-mail;
• należy stosować najnowocześniejsze protokoły szyfrowania i algorytmy uważane za bezpieczne dla kluczy DKIM; w momencie pisania tego dokumentu zaleca się stosowanie 2048-bitowego szyfru RSA;
• zapewnić odpowiednią ochronę prywatnego klucza DKIM przechowywanego na serwerze pocztowym, stosując ograniczone uprawnienia dostępu i upewnić się, że jedynie oprogramowanie serwera pocztowego ma uprawnienia do odczytu klucza;
• skonfiguruj każdy serwer pocztowy przy użyciu unikalnej pary kluczy i selektora, aby ograniczyć skutki potencjalnego naruszenia klucza prywatnego;
• chronić klucz prywatny zarówno przed przypadkowym ujawnieniem, jak i próbami dostępu lub modyfikacji przez atakującego;
• zapewnić, aby oprogramowanie powiązane z listami mailingowymi weryfikowało podpisy DKIM w wiadomościach przychodzących i dołączało nowe podpisy DKIM do wiadomości wychodzących;
• stosować unikalne pary kluczy DKIM dla każdej strony trzeciej wysyłającej wiadomości e-mail w imieniu organizacji;
• okresowo wymieniaj pary kluczy DKIM (przynajmniej raz na sześć miesięcy), aby ograniczyć skutki potencjalnego naruszenia;
• natychmiast cofnij klucze w przypadku podejrzenia naruszenia;
• monitoruj raporty DMARC, aby identyfikować błędy konfiguracji i próby nadużyć.

Więcej szczegółów znajdziesz w materiałach źródłowych wymienionych w Dokumentach referencyjnych.

Należy zauważyć, że w celu zapewnienia odpowiedniej ochrony bezpieczeństwa poczty elektronicznej, oprócz protokołów uwierzytelniania omówionych w tym miejscu, istnieją dalsze protokoły – niebędące przedmiotem niniejszych wytycznych – takie jak na przykład TLS (Transport Layer Security) , który gwarantuje szyfrowanie kanału transmisyjnego, oraz SMIME i OpenPGP , które dotyczą kompleksowego szyfrowania i uwierzytelniania wiadomości.

Należy również zauważyć, że – choć nie jest to protokół bezpieczeństwa poczty elektronicznej w ścisłym tego słowa znaczeniu – w celu zapewnienia bezpieczeństwa usług poczty elektronicznej zaleca się wdrożenie protokołu DNSSEC (Domain Name System Security Extensions), rozszerzenia protokołu DNS, które dodaje podpisy kryptograficzne do rekordów DNS w celu zagwarantowania integralności i autentyczności zapytań DNS. Dzięki DNSSEC, na przykład, informacje dotyczące rekordów SPF, DKIM i DMARC są chronione podczas transmisji, co zmniejsza ryzyko modyfikacji, a tym samym zwiększa bezpieczeństwo usług poczty elektronicznej.

» powrót na górę

Załącznik A: Środki bezpieczeństwa

Narodowy Perimetr Cyberbezpieczeństwa (PCSC)

PR.IP-1: Definiuje się i zarządza praktykami referencyjnymi (tzw. liniami bazowymi) w celu konfiguracji systemów informatycznych i systemów sterowania przemysłowego, które uwzględniają zasady bezpieczeństwa (np. zasadę najmniejszej funkcjonalności).

1. Istnieje szczegółowy zaktualizowany dokument wskazujący, także w odniesieniu do kategorii ID.AM, co najmniej:
   • a) polityki bezpieczeństwa przyjęte przy opracowywaniu konfiguracji systemów informatycznych i sterowania przemysłowego oraz wdrażaniu wyłącznie przyjętych konfiguracji;
   • b) wykaz stosowanych konfiguracji systemów informatycznych i sterowania przemysłowego oraz odniesienie do odpowiednich praktyk odniesienia;
   • c) procesy, metodologie i technologie wykorzystywane w celu zapewnienia zgodności z politykami bezpieczeństwa.

Regulacja chmury – infrastruktura cyfrowa i usługi dla administracji publicznej

PR.IP-01: Definiuje się i zarządza praktykami referencyjnymi (tzw. liniami bazowymi) w celu konfiguracji systemów informatycznych i systemów sterowania przemysłowego, które uwzględniają zasady bezpieczeństwa (np. zasadę najmniejszej funkcjonalności).

1. Zasady i procedury są definiowane w odniesieniu do bezpieczeństwa aplikacji, aby zapewnić odpowiednie wsparcie przy planowaniu, wdrażaniu i utrzymywaniu funkcji bezpieczeństwa aplikacji, które muszą być przeglądane i aktualizowane przynajmniej raz w roku.
2. Istnieje szczegółowy zaktualizowany dokument wskazujący, także w odniesieniu do kategorii ID.AM, co najmniej:
   • a) polityki bezpieczeństwa przyjęte przy opracowywaniu konfiguracji systemów informatycznych i sterowania przemysłowego oraz wdrażaniu wyłącznie przyjętych konfiguracji;
   • b) wykaz stosowanych konfiguracji systemów informatycznych i sterowania przemysłowego oraz odniesienie do odpowiednich praktyk odniesienia;
   • c) procesy, metodologie i technologie wykorzystywane w celu zapewnienia zgodności z politykami bezpieczeństwa.
3. Określono i udokumentowano podstawowe wymagania dotyczące bezpieczeństwa różnych aplikacji.
4. Określono i wdrożono wskaźniki o charakterze technicznym, przydatne do monitorowania poziomu przestrzegania określonych wymogów bezpieczeństwa i obowiązków zgodności.
5. Istnieje proces łagodzenia luk w zabezpieczeniach aplikacji i odzyskiwania ich bezpieczeństwa, który umożliwia automatyzację działań naprawczych, gdy jest to możliwe.
6. Istnieje proces weryfikacji zgodności urządzenia z systemami operacyjnymi i aplikacjami.
7. Istnieje system zarządzania zmiennością w zakresie systemu operacyjnego, poprawek i/lub aplikacji.

Regulacja chmury – usługi chmurowe dla administracji publicznej

PR.IP-01: Definiuje się i zarządza praktykami referencyjnymi (tzw. liniami bazowymi) w celu konfiguracji systemów informatycznych i systemów sterowania przemysłowego, które uwzględniają zasady bezpieczeństwa (np. zasadę najmniejszej funkcjonalności).

1. Zasady i procedury są definiowane w odniesieniu do bezpieczeństwa aplikacji, aby zapewnić odpowiednie wsparcie przy planowaniu, realizacji i utrzymywaniu funkcji bezpieczeństwa aplikacji, które muszą być przeglądane i aktualizowane co najmniej raz w roku [IaaS, SaaS].
2. Istnieje szczegółowy zaktualizowany dokument wskazujący, także w odniesieniu do kategorii ID.AM, co najmniej:
   • a) polityki bezpieczeństwa przyjęte przy opracowywaniu konfiguracji systemów informatycznych i sterowania przemysłowego oraz wdrażaniu wyłącznie przyjętych konfiguracji;
   • b) wykaz stosowanych konfiguracji systemów informatycznych i sterowania przemysłowego oraz odniesienie do odpowiednich praktyk odniesienia;
   • c) procesy, metodologie i technologie wykorzystywane w celu zapewnienia zgodności z politykami bezpieczeństwa [SaaS].
3. Określono i udokumentowano podstawowe wymagania dotyczące bezpieczeństwa różnych aplikacji.
4. Zdefiniowano i wdrożono metryki o charakterze technicznym, przydatne do monitorowania poziomu przestrzegania zdefiniowanych wymogów bezpieczeństwa i obowiązków zgodności. 5. Istnieje proces łagodzenia luk w zabezpieczeniach aplikacji i odzyskiwania ich w celu zapewnienia bezpieczeństwa aplikacji, który w miarę możliwości automatyzuje działania naprawcze.
5. Istnieje proces weryfikacji zgodności urządzenia z systemami operacyjnymi i aplikacjami [PaaS, SaaS].
6. Istnieje system zarządzania zmiennością w zakresie systemu operacyjnego, poprawek i/lub aplikacji [PaaS, SaaS].

NIS 2

PR.PS-01: Ustanowiono i wdrożono praktyki zarządzania konfiguracją.

1. Przynajmniej w przypadku istotnych informacji i systemów sieciowych zdefiniowano i udokumentowano ich bezpieczne konfiguracje bazowe (wzmocnione) na zaktualizowanej liście.
2. Zgodnie z politykami, o których mowa w punkcie GV.PO-01, przyjęto i udokumentowano procedury w odniesieniu do punktu 1.

» powrót na górę

Bibliografia

[1] NIST, „Nota techniczna 1945”.
[2] NIST, „Specjalna publikacja NIST 800-177, rewizja 1”.
[3] Narodowa Agencja Cyberbezpieczeństwa, „Kryptografia postkwantowa i kwantowa – przygotowanie do zagrożenia kwantowego”.
[4] Narodowa Agencja Cyberbezpieczeństwa, „Struktura uwierzytelniania poczty elektronicznej”.

» powrót na górę