E-posta kimlik doğrulama yönergeleri

!! DİKKAT !! Bu belge İtalyancadan otomatik olarak çevrilmiştir

Yönergeler

Kimlik doğrulama için e-posta hizmetinin yapılandırılması

İtalyan Ulusal Siber Güvenlik Ajansı , ilgili tüm kuruluşlar için e-posta hizmetinin güvenilirliğini güçlendirmek ve genel güvenlik düzeyini artırmak amacıyla, kimlik doğrulama için e-posta hizmetinin yapılandırılmasına ilişkin kılavuzu yayınladı

Sürüm Kontrolü

DİZİN

1. Giriş

1.1. Önerme

E-posta, günümüzde dijital bağlamda en kritik hizmetlerden birini temsil etmektedir; zira kuruluşlar ve kullanıcılar tarafından iletişim ve bilgi alışverişi için kullanılan başlıca kanallar arasındadır¹.

E-posta hizmetinin işleyişi ve özellikle mesaj iletimi, gönderici kimlik doğrulaması ve mesajların gizliliğinin ve bütünlüğünün korunması için yeterli mekanizmaları doğal olarak içermeyen SMTP protokolüne dayanmaktadır. Bu güvenlik açıkları, onu kimlik avı, kurcalama ve iletim sırasında mesaj ele geçirme gibi saldırı risklerine maruz bırakmaktadır.

SMTP protokolünün zayıf yönlerini gidermek ve dolayısıyla yukarıda bahsedilen saldırılardan kaynaklanan riski azaltmak için zaman içinde SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) ve DMARC (Domain-based Message Authentication, Reporting and Conformance) gibi gönderici kimlik doğrulama ve mesaj bütünlüğünün korunmasına yönelik mekanizmalar geliştirilmiştir.

Bu yönergeler, özellikle 4. bölümde açıklanan tehditlere atıfta bulunarak, e-posta hizmetinin güvenilirliğini güçlendirmek ve genel güvenlik düzeyini artırmak amacıyla bu mekanizmaları açıklamaktadır.

E-posta mesajlarının gizliliğini korumak için gerekli olan önlemler ve protokoller (mesaj şifrelemesiyle ilgili S/MIME ve OpenPGP gibi) bu kılavuzların konusu değildir.

1.2. Referans Yönetmelikleri

1.3. Referans Belgeleri

» başa dön

2. Düzenleyici Bağlam

Ülkenin dijital varlıklarını, e-posta hizmetlerini ve bunları barındıran altyapıları korumak için, mevcut mevzuattan türetilen ve sürekli olarak güncellenen geniş bir güvenlik önlemleri paketi uygulanmaktadır.

Ulusal güvenliğin korunmasıyla bağlantılı, ülkenin en kritik hizmetleri için en üst düzeyde koruma, 21 Eylül 2019 tarihli ve 105 sayılı Kanun Hükmünde Kararname ile kurulan ve 18 Kasım 2019 tarihli ve 133 sayılı Kanun ile değişikliklerle güncellenen Ulusal Siber Güvenlik Çevresi ile sağlanmaktadır. Bu, 14 Nisan 2021 tarihli ve 81 sayılı Başbakanlık Kararnamesinin B Ekinde ayrıntılı olarak belirtilen, özellikle yüksek düzeyde koruma sağlayan güvenlik önlemlerini içermektedir. Bu önlemler, devletin temel bir işlevinin yerine getirilmesi veya devletin çıkarları için temel olan sivil, sosyal veya ekonomik faaliyetlerin sürdürülmesi için gerekli bir hizmetin sağlanmasının bağlı olduğu kamu ve özel kuruluşların ağlarına, bilgi sistemlerine ve BT hizmetlerine uygulanır ve bunların tehlikeye atılması ulusal güvenliğe zarar verebilir.

Ayrıca, kamu yönetiminin tüm dijital hizmetleri gibi e-posta hizmetleri de, 18 Ekim 2012 tarihli ve 179 sayılı Kanun Hükmünde Kararnamenin 33-septies maddesi uyarınca kabul edilen ve Ulusal Siber Güvenlik Ajansı (ACN) tarafından 27 Haziran 2024 tarihli ve 21007 sayılı Direktörlük Kararnamesi ile güncellenen Bulut Yönetmeliği hükümlerine tabidir. Söz konusu Yönetmeliğe göre, tüm kamu idareleri, ACN tarafından hazırlanan modele göre dijital verilerini ve hizmetlerini sıradan, kritik veya stratejik olarak sınıflandırmakla yükümlüdür. Bu faaliyet, kamu yönetiminin dijital verilerinin ve hizmetlerinin, Yönetmelikte ayrıntılı olarak belirtilen ilgili sınıflandırma düzeyine uygun risklere yönelik güvenlik gereksinimleri de dahil olmak üzere, gereksinimleri karşılayan dijital altyapılar ve bulut hizmetleri aracılığıyla işlenmesini ve sunulmasını sağlamayı amaçlamaktadır.

4 Eylül 2024 tarihli ve 138 sayılı Kanun Hükmünde Kararname (bundan böyle NIS kararnamesi olarak anılacaktır), (AB) 2022/2555 sayılı Direktifi ulusal mevzuata aktarırken, ACN kararı 379907/2025'in Ek 1 ve 2'si aracılığıyla, NIS kararnamesinin 23 ve 24. maddeleri kapsamındaki yükümlülükler için temel ve önemli kuruluşların benimsemesi gereken temel güvenlik önlemlerini de belirlemiş ve e-posta hizmetleri de dahil olmak üzere ağ ve bilgi sistemlerinin korunmasını güçlendirmek için bir güvenlik çerçevesi tanımlamıştır.

» başa dön

3. E-posta Hizmeti Mimarisi

Giriş bölümünde belirtildiği gibi, e-posta hizmetinin işleyişi, göndericiden alıcıya e-posta mesajlarının iletimini düzenleyen SMTP protokolüne dayanmaktadır.

SMTP protokolü, başlangıçta 1982 yılında ^[1] bir depolama ve iletme protokolü olarak tanımlanmıştır ; bu protokolde gönderici, posta istemcisi (jargon adıyla Posta Kullanıcı Aracısı - MUA) aracılığıyla bir mesaj oluşturur ve bu mesajı göndericinin posta sunucusuna gönderir. Bu sunucu, Posta Aktarım Aracısı (MTA) adı verilen bir bileşen aracılığıyla mesajı, muhtemelen bir veya daha fazla ara MTA üzerinden de geçirerek, hedef posta sunucusunun MTA'sına iletir. Alıcı kullanıcı, mesajı posta istemcisi (MUA) [1] aracılığıyla erişir .

Dolayısıyla MTA, e-posta mesajlarının göndericiden alıcıya iletilmesini sağlayan e-posta hizmetinin bir bileşenidir. MTA bileşenleri gönderici ve alıcının posta sunucularında bulunur ve örneğin dağıtım listelerini yönetmek için ara MTA'lar da yapılandırılabilir.

MTA terimi e-posta sunucularının belirli bir bileşenini tanımlasa da³^,bu belgenin amacı doğrultusunda e-posta sunucularına esas olarak MTA işlevleri bağlamında atıfta bulunulduğu için, herhangi bir belirsizlik olmadığı durumlarda, açıklama kolaylığı açısından daha spesifik olan MTA yerine genellikle e-posta sunucusu terimi kullanılacaktır.

Bu kılavuzda, posta sunucularının e-posta mesajlarının orijinalliğini ve bütünlüğünü doğrulamasına olanak tanıyan SPF, DKIM ve DMARC protokollerinin yapılandırmasına odaklanacağız.

» başa dön

4. Tehditler

Önceki bölümde tanıtılan SMTP protokolü, başlangıçta nispeten küçük bir akademik ağda çalışmak üzere tasarlanmıştı ve iletilen mesajların güvenliği veya gönderici kimlik doğrulamasıyla ilgili hususları dikkate almamıştı [1].

E-postanın giderek yaygınlaşması ve SMTP protokolünün doğasında var olan zayıflıklar, zaman içinde, aşağıdaki paragraflarda kısaca açıklanan başlıca saldırı türlerinin ortaya çıkmasına zemin hazırlamıştır.

4.1. Gönderici Sahtekarlığı

Sahtekarlık (spoofing) , bir mesajın göndericisinin adresini taklit ederek, mesajın güvenilir bir adresten (örneğin, bir meslektaşın, bir tanıdığın veya kişinin kendi banka kurumunun adresi gibi) geliyormuş gibi görünmesini sağlayan bir siber saldırı tekniğidir. Bu teknik, alıcıyı potansiyel olarak tehlikeli eylemler gerçekleştirmeye, örneğin e-posta ekini açmaya veya mesajda yer alan bağlantılara tıklamaya teşvik eder.

Bu tür bir saldırıyı gerçekleştirmek nispeten kolaydır, çünkü SMTP protokolü gönderici kimlik doğrulama mekanizmalarını içermez ve bu nedenle, e-posta istemcisi aracılığıyla mesaj oluşturulurken herhangi bir gönderici adresi yapılandırılabilir.

Gönderen e-posta adresi: envelope-from ve message-from

E-posta mesaj formatı, gönderenin e-posta adresini belirtmek için iki ayrı alan sağlar. Bu alanlar "envelope-from" ve "message-from": birincisi ( "return-path ), mesajı doğru şekilde yönlendirmek için kullanılan adrestir; ikincisi ise alıcının alınan mesaj başlığında görüntülediği adrestir.

Geleneksel posta yoluyla zarf içinde mektup göndermeyle bir benzetme yapacak olursak, zarftan gönderilen kısım, mektubun zarfında gösterilen gönderenin adresini temsil ederken, mesajdan gönderilen kısım mektubu kimin alıcıya yazdığını gösteren mektup başlığına karşılık gelir.

İki adresin aynı olmayabileceğini belirtmek önemlidir. Bu ayrım, örneğin üçüncü taraf hizmetlerinden gelen mesajların iletilmesi, posta listeleri aracılığıyla dağıtım veya otomatik e-posta yanıtları gibi durumların yönetilmesine olanak tanır.

Hem mesaj gönderen düzeyinde (alıcının aldığı mesaj başlığında görüntülenen gönderenin e-posta adresi) hem de zarf gönderen düzeyinde (mesaj iletimi için kullanılan gönderenin e-posta adresi) herhangi bir göndereni belirtmek gerçekten mümkündür

Bu tehditlere karşı koymak için, göndereni güvenilir bir şekilde doğrulamaya ve mesajı gönderen kişinin gerçekten bunu yapmaya yetkili olup olmadığını teyit etmeye olanak sağlayan mekanizmalar sunmak şarttır.

4.2. Kimlik Avı

Kimlik avı , genellikle güvenilir göndericilerden geliyormuş gibi görünen aldatıcı mesajlar göndererek bilgilerin (örneğin, giriş kimlik bilgileri, kredi kartı numaraları veya diğer hassas veriler gibi) hileli bir şekilde elde edilmesini amaçlayan bir siber saldırı tekniğidir³ ^.

kimlik taklit etme (spoofing), saldırganın gönderenin kimliğini taklit ederek mesajın meşru bir kullanıcıdan veya alan adından geliyormuş gibi görünmesini sağlamak için kullandığı başlıca tekniklerden biridir.

Alternatif olarak, alıcı tarafından tanınabilir bir gönderen adresi/alan adı kullanılabilir; örneğin, mesajın görünürdeki gerçekliğini güçlendirmek için sözde görünen ad ⁴ değiştirilebilir

Kimlik avı mesajları göndermek için, saldırgan tarafından daha önce ele geçirilmiş meşru hesaplar da kullanılabilir.

Kimlik avı mesajları genellikle alıcıda aciliyet, endişe veya ekonomik ilgi uyandırmak üzere tasarlanmış içeriklere sahiptir ve bu da alıcının dürtüsel olarak tepki vermesine ve kötü amaçlı ekleri açmak veya görünüşte meşru web sitelerine yönlendiren bağlantılara tıklamak gibi belirli eylemler gerçekleştirmesine yol açan durumlar yaratır; ancak bu siteler gerçekte saldırgan tarafından bilgi çalmak ve/veya kötü amaçlı yazılım yüklemek amacıyla oluşturulmuştur.

Genellikle, kimlik avı saldırıları, metni kurbanların özel profiline uyarlamadan, aynı e-posta mesajını çok sayıda kurbana göndererek gerçekleştirilir.

Kimlik avının bir varyantı olan hedefli kimlik avında, saldırgan kurbanın profilini bilir ve özellikle onu hedef alır.

Sıradan bir kimlik avı e-postasının aksine, hedefli kimlik avı mesajı, kullanıcının güvenilir bir göndericiyle etkileşimde bulunduğuna ikna etmek için daha hassas bağlamsal bilgiler kullanır [2].

4.3. Mesajda Değişiklik Yapılması

Uçtan uca şifreleme (E2EE) tekniklerini kullanmayan internet ağı üzerinden iletilen diğer tüm iletişimler gibi, bir e-posta mesajının içeriği de gönderici ve alıcı arasında iletim sırasında ele geçirilebilir ve değiştirilebilir (bu tür bir tehdit genellikle "ortadaki adam" saldırısı olarak adlandırılır).

Sonuç olarak, gizliliğin kaybına ek olarak, alınan mesaj gönderen tarafından başlangıçta yazılan mesajla aynı olmayabilir.

Örneğin, bir saldırgan mesaj içeriğini güvenilir bir göndericiden geliyormuş gibi gösterecek şekilde değiştirebilir, mesajdaki metni veya bağlantıları ve/veya ekleri değiştirebilir veya kötü amaçlı kod ekleyebilir.

Alıcı, mesajın görünürdeki gerçekliğine güvenerek, giriş bilgilerini paylaşmak, ödemeleri onaylamak veya kötü amaçlı dosyaları açmak gibi potansiyel olarak zararlı eylemlerde bulunmaya yönlendirilebilir.

Bu tehditlere karşı koymak için, mesajın bütünlüğünü ve orijinalliğini garanti eden, alınan içeriğin değiştirilmediğini ve gönderenin gerçekten iddia ettiği kişi olduğunu doğrulayan mekanizmaların benimsenmesi şarttır.

» başa dön

5. Karşı Önlemler

2. Bölümde, e-posta hizmetlerinin korunması için de güvenlik önlemleri öngören düzenlemeler hatırlatılmıştı. Bu belge, öncelikle, 4. Bölümde ele alınan tehditlerle ilişkili riskleri azaltmak amacıyla, söz konusu düzenlemelerde öngörülen ve Ek A'da belirtilen, e-posta hizmetlerinin yapılandırılması için de geçerli olan güvenlik önlemlerinin uygulanmasına ilişkin bir kılavuz sağlamayı amaçlamaktadır. Bununla birlikte, bu kılavuzda yer alan önerilerin, söz konusu düzenlemelere tabi olmayan taraflar için de tavsiye niteliğinde olduğu belirtilmelidir.

Söz konusu güvenlik önlemleri açıkça e-posta hizmetinin yapılandırmasına değil, – ele alınan düzenlemeye bağlı olarak – BT sistemlerinin ve endüstriyel kontrol sistemlerinin (PSNC ve Bulut Düzenlemesi) veya bilgi ve ağ sistemlerinin (NIS2) yapılandırmasına atıfta bulunmaktadır. Bu yönergelerin konusu olan e-posta hizmetleri, her iki sistem türüne de girmektedir.

Özellikle, e-posta hizmetinin genel güvenliğini ve özellikle gönderici kimlik doğrulamasını ve mesaj bütünlüğü kontrolünü güçlendirmek amacıyla tasarlanmış güvenlik mekanizmaları sağlayan SPF , DKIM ve DMARC protokolleri aşağıda gösterilmiştir

5.1. Güneş Koruma Faktörü (SPF)

SPF (Sender Policy Framework) , RFC 7208 ile resmileştirilmiş bir kimlik doğrulama protokolüdür ve bir alan adı sahibinin, kendi adına e-posta mesajı göndermeye yetkili IP adreslerini belirlemesine ve gönderenin e-posta adresinin bağlı olduğu alan adı ⁵ ile ilişkili IP adresi açıkça yetkilendirilmiş adresler arasında değilse alıcının uygulaması gereken politikaları oluşturmasına olanak tanır.

Yetkilendirilmiş IP adresleri, gönderen etki alanıyla ilgili bir DNS TXT kaydında (SPF kaydı olarak adlandırılır) listelenir ve bu paragrafın sonraki bölümünde açıklanmaktadır.

Bu şekilde, alıcının e-posta sunucusu^6, belirli bir alandan gelen bir mesajı aldığında, ilgili SPF kaydını sorgulayabilir ve mesajın alındığı IP adresinin, alan adına mesaj göndermeye yetkili IP adresleri arasında yer aldığını doğrulayarak kaynağının kimliğini doğrulayabilir.

SPF seviyesinde doğrulanan alanın zarf-gönderen ile ilgili alan olduğunu gözlemlemek önemlidir; dolayısıyla SPF protokolünün tek başına benimsenmesi, sahtekarlığı önlemek için yeterli değildir, çünkü bu tür bir saldırı mesaj-gönderen seviyesinde gerçekleştirilebilir⁷.

Bir kuruluş, e-posta hizmetini tamamen veya kısmen üçüncü bir tarafa, örneğin bir bulut sağlayıcısına, dış kaynak olarak devrettiğinde, bu sağlayıcılar tarafından gönderilen mesajların SPF kontrollerinden geçmesini sağlamalıdır. Bu amaçla, kuruluş, sağlayıcıların kuruluşun alan adı adına e-posta gönderdiği IP adreslerini SPF kaydına eklemelidir.

Otomatik e-posta yönlendirme durumunda, mesajlar genellikle ara bir sunucu tarafından yeniden yönlendirildiğinden, son teslimatı yapan IP adresi artık gönderen alan adı tarafından başlangıçta yetkilendirilen IP adresiyle aynı olmaz. Bu durumlarda, SPF doğrulamasının başarısız olmaması için, ara yönlendirme sunucularının da yetkilendirilmesi veya özellikle çok sayıda ara yönlendirme sunucusunun bulunduğu durumlarda daha etkili olabilen SRS (Gönderici Yeniden Yazma Şeması) veya ARC (Kimliği Doğrulanmış Alınan Zinciri) gibi mekanizmalara başvurulması gerekir.

SPF'nin gerçekten etkili olabilmesi için, yalnızca gönderen tarafından değil, alıcı tarafından da doğru şekilde yapılandırılması gerektiğinin altını çizmek gerekir. Özellikle:

• Gönderici , kendi adına e-posta göndermeye yetkili adresleri belirten SPF kaydını ilgili DNS sunucusunda yayınlamalıdır;
• Alıcı , alınan mesajlarda SPF doğrulamasını gerçekleştirecek ve ortaya çıkan politikaları tutarlı bir şekilde uygulayacak şekilde kendi posta sunucusunu yapılandırmalıdır.

5.1.1. SPF Kaydı

SPF Kaydı, adı gönderen alan adına karşılık gelen ve içeriği, sürümü gösteren bölüm ve gönderen alan adının IP adresi ile bir yönerge arasında eşleşme olduğunda alıcının posta sunucusunun davranışını belirten bir dizi yönergeden oluşan TXT türünde ^bir DNS ^kaydıdır .

Yönergeler, bir niteleyiciyle başlayan bir mekanizma tarafından oluşturulur. SPF kayıtlarında kullanılan ana mekanizmalar şunlardır: [2]:

• ip4, yetkilendirilmiş IPv4 adreslerini listeler;
• ip6, yetkilendirilmiş IPv6 adreslerini listeler;
• a, etki alanının A kaydında bulunan IP adreslerini yetkilendirir;
• MX kaydı, alan adının MX kayıtlarıyla ilgili IP adreslerini yetkilendirir;
• Dahil et seçeneği, başka bir alan adının SPF kaydında bulunan IP adreslerini yetkilendirir;
• "all" ifadesi, diğer mekanizmalar aracılığıyla açıkça yetkilendirilmemiş tüm IP adreslerini temsil eder.

Özellikle, bu mekanizma, önceki mekanizmalar tarafından tanımlanmamış IP adreslerinden gelen mesajlar için politikalar oluşturulmasına olanak tanır.

Ayrıca, SPF mekanizmalarla ilişkilendirilebilecek aşağıdaki nitelikleri sunmaktadır:

• + (pass) ifadesi, ilgili mekanizmayla eşleşen IP adreslerinin yetkilendirildiğini gösterir. Başka bir niteleyici belirtilmediyse varsayılan niteleyicidir;
• - (başarısız) ifadesi, ilgili mekanizmayla eşleşen IP adreslerinin yetkilendirilmediğini gösterir;
• ~ (softfail), ilgili mekanizmayla eşleşen IP adreslerinin muhtemelen yetkilendirilmediğini gösterir. Bu, bir öncekine göre daha belirsiz bir bildirimdir. Bu durumlarda mesaj kabul edilmeli ancak daha derinlemesine analiz için işaretlenmelidir; örneğin hata ayıklama durumlarında veya SPF doğrulamasının başarılı olmayabileceği öngörüldüğünde kullanılır;
• ? (nötr) ifadesi, ilgili mekanizmayla eşleşen IP adresleri için herhangi bir gösterge verilmediğini belirtir. Varsayılan davranış, mesajı kabul etmektir.

Uygulamada, SPF kaydının yetkilendirilmiş IP adreslerini belirtmek için oluşturulduğunu ve ardından -all (bu konuda lütfen aşağıdaki örneklere bakın). Bu, yetkilendirilmiş IP adreslerini açıkça belirtmeye ve diğerlerini hariç tutmaya olanak sağladığı için önerilen yapılandırmayı temsil eder.

Her durumda, +all (veya eşdeğeri all ) yönergesini asla kullanmamanız önerilir, çünkü bu tüm IP adreslerinin yetkilendirilmesi anlamına gelir.

SPF kayıtlarına örnekler

Belirli bir IP adresini yetkilendirin

v=spf1 ip4:203.0.113.0 -all

Yukarıda gösterilen SPF kaydı, SPF sürüm 1'i kullanır ve ip4 mekanizması aracılığıyla 203.0.113.0 IP adresini yetkilendirir (aslında, ip4 mekanizması için herhangi bir niteleyici belirtilmediğinden , varsayılan + örtük olarak kullanılır). all mekanizması ve - (fail) niteleyicisi tarafından oluşturulan -all yönergesi , diğer tüm adreslerin yetkilendirilmediğini belirtir.

Belirli bir IP adresi alanını yetkilendirin

v=spf1 ip4:203.0.113.0/24 -all

Yukarıda gösterilen SPF kaydı, bir öncekine benzerdir ancak 203.0.113.0/24 adres aralığındaki tüm IP adreslerine yetki verir.

Birden fazla IP adresini yetkilendirin

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -tümü

Yukarıda gösterilen SPF kaydı, yalnızca 203.0.113.22 ve 203.0.113.44 IPv4 adreslerine erişim izni vermektedir .

MX kayıt adreslerini ve belirli bir etki alanını yetkilendirin

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

Yukarıda gösterilen SPF kaydı, yalnızca SPF kaydıyla aynı etki alanına sahip MX kayıtlarının IP adreslerini ve spf.emailprovider.it (örneğin, bir e-posta servis sağlayıcısının etki alanı) yetkilendirdiği IP adreslerini yetkilendirir.

5.1.2. Kimlik Doğrulama Süreci

SPF doğrulaması yapmak üzere doğru şekilde yapılandırılmışsa, alıcının posta sunucusu yeni bir e-posta mesajı aldığında, zarfın gönderen alanında bildirilen adresten yola çıkarak, gönderen alan adının kayıtlarını içeren DNS sunucusunu sorgulayarak gönderen alan adının SPF kaydını alır. Örneğin, zarfın gönderen alanında bildirilen adres alice@example.com, alıcının posta sunucusu example.com.

Alıcının posta sunucusu daha sonra SPF doğrulamasını gerçekleştirir ve mesajı aldığı IP adresinin example.com alan adı için e-posta gönderme yetkisine sahip olup olmadığını belirlemek için SPF kaydını analiz eder. E-posta mesajı SPF doğrulamasından geçerse, alıcıya iletilir.

Örneğin, example.com alan v=spf1 ip4:203.0.113.22 -all , doğrulama yalnızca gönderen sunucunun IP adresi 203.0.113.22, diğer tüm adresler için başarısız olurdu.

» başa dön

5.2. DKIM

DKIM – DomainKeys Identified Mail , RFC 6376 ile resmileştirilmiş bir kimlik doğrulama protokolüdür ve bir alan adı sahibinin, posta sunucusu tarafından kamuya açık şifreleme algoritmaları kullanılarak oluşturulan ve iletilecek mesajın başlıklarına eklenen dijital bir imza (DKIM imzası) ekleyerek gönderilen e-posta mesajlarının orijinalliğini garanti etmesini sağlar.

Alıcının mesajın iletim sırasında değiştirilmediğini doğrulayabilmesi için, DKIM imzasıyla ilişkili genel anahtar, gönderen alan adının genel DNS'sinde DKIM kaydı adı verilen bir TXT kaydında saklanır ve bu kayıt, mesaj alındığında alıcı posta sunucusu tarafından sorgulanır.

Bu paragrafın sonraki bölümlerinde DKIM imzası ve kaydı gösterilmektedir.

SPF'de olduğu gibi, DKIM de gönderici ve alıcı tarafından doğru şekilde yapılandırılmalıdır ve özellikle şu hususlara dikkat edilmelidir:

• Gönderici, posta sunucusunu DKIM imzaları oluşturacak ve DKIM kaydını ilgili DNS sunucusunda yayınlayacak şekilde yapılandırmalıdır;
• Alıcının, gelen mesajlarda DKIM doğrulaması yapacak şekilde posta sunucusunu yapılandırması gerekir.

5.2.1. DKIM İmzası

DKIM imzası, mesaj gövdesinin ve başlıklarının belirlenmiş öğelerinden yola çıkarak oluşturulur ve aşağıdaki öğeleri belirten bir dizi anahtar-değer çiftinden oluşur:

• v: protokol sürüm¹⁰;
• a: kullanılan şifreleme algoritması¹¹;
• d: Mesajın orijinalliğini beyan eden imzalama alanı¹²;
• s: DNS kaydında hangi DKIM genel anahtarının aranacağını belirten seçici¹³;
• h: imzaya dahil edilen e-posta başlıklarının listesi¹⁴;
• bh: mesaj gövdesinin base64 formatında kodlanmış özeti¹⁵;
• b: Özel anahtarla oluşturulan ve base64 formatında kodlanan gerçek dijital imza¹⁶;
• x: İmzanın geçerlilik tarihi;
• c: kanonikleştirme türü.

Kanonikleştirme, dijital olarak imzalanmadan önce mesaj öğelerinin normalleştirilmesi işlemidir; bu işlem, iletim sırasında meydana gelebilecek küçük değişikliklerin (örneğin tekrarlanan boşluklar veya satır sonları) etkisini azaltmayı amaçlar. İki tür kanonikleştirme vardır: Basit, orijinal mesaj ile alınan mesaj arasında tam bir eşleşme gerektirir; gevşekkanonikleştirme ise boşlukların kaldırılması, başlıklardaki büyük harflerin küçük harflere dönüştürülmesi ve mesaj gövdesindeki ardışık boş satırların azaltılması gibi normalleştirmeler uygular.

5.2.2. DKIM Kaydı

DKIM kaydı, adı selector._domainkey.domain yapısına sahip bir TXT türünde DNS kaydında saklanır; burada _domainkey, DNS kaydının gerçekten bir DKIM kaydı olduğunu belirtmek için kullanılan bir etikettir. DKIM kaydının içeriği, aşağıdakiler de dahil olmak üzere öğeleri belirten bir dizi anahtar-değer çiftinden oluşur:

• v: protokol sürümü;
• k: anahtar türü, varsayılan olarak RSA'dır;
• p: Base64 formatında kodlanmış açık anahtar.

DKIM kaydı örneği

Adı: s1._domainkey.example.com
Değeri: v=DKIM1; k=rsa; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...

Örnek DKIM kaydı, example.com alan adının s1 seçicisiyle ilişkilidir , 1. sürümü kullanır ve base64 formatında kodlanmış RSA genel anahtarını içerir ( Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h... ).

5.2.3. Kimlik Doğrulama Süreci

Hem gönderenin hem de alıcının posta sunucularında DKIM protokolü doğru şekilde yapılandırılmışsa, DKIM kimlik doğrulama ve onaylama sürecinin işleyişi, gönderen posta sunucusunun 5.2.1 paragrafında açıklandığı gibi mesajın DKIM imzasını oluşturmasını ve bu imzanın mesajın kendisine eklenmesini sağlar. Özellikle, DKIM imzası d alanında imzalama alanını ¹⁷ ve b alanında imzalama alanının özel anahtarıyla oluşturulan mesajın dijital imzasını içerir.

Mesaj alındığında, alıcı posta sunucusu, imzalayan alan adının DKIM kaydını ( DKIM imzasının d alanı) o alan adının kayıtlarını içeren DNS sunucusundan alır. Ardından, DKIM kaydında bulunan genel anahtarı kullanarak DKIM imzasında bulunan dijital imzayı ( b alanı) doğrular. Doğrulama başarılı olursa, mesaj alıcıya iletilir.

5.2.4. Kriptografik Yönler

Kriptografik cephede, DKIM tarihsel olarak RSA algoritmasını, özellikle de 2007'den beri standart olarak kabul edilen rsa-sha256 varyantını kullanmıştır. RFC 8463 ile tanıtılan yeni alternatif ise, daha yüksek verimlilik ve çok daha kompakt anahtarlar sağlayan, eliptik eğrilere dayalı modern bir dijital imza biçimi olan Ed25519-SHA256'dır .

Teknik düzeyde, 2048 bit anahtar uzunluğuna sahip RSA, evrensel standart olmaya devam ediyor, ancak anahtarlar uzun ve imzalar nispeten büyükken, Ed25519, RSA 2048'e kıyasla dokuz kat daha kısa anahtarlar ve dört kat daha küçük imzalar sunarken, imzalama performansı otuz kata kadar daha üstün. Bu avantajlara rağmen, gerçek dünya desteği sınırlı: 2026 yılında Ed25519 yalnızca birkaç sağlayıcı tarafından doğrulanmış durumda, bazı büyük operatörler ise imzalama veya doğrulama konusunda güvenilir bir destek sunmuyor, bu da onu üretimde tek çözüm olarak uygunsuz hale getiriyor.

Bu nedenle, teknik olarak üstün olmasına rağmen, bu belgenin yazıldığı sırada, Ed25519'un kullanımı, deneysel bir bakış açısıyla ve gelecekteki uyumluluk önlemi olarak, çift imza yoluyla RSA ile birlikte kullanılması dışında önerilmemektedir . Büyük sağlayıcılar doğrulamasını tam olarak uygulamaya koyana kadar, RSA, maksimum mesaj teslim güvencesini sağlamak için vazgeçilmez olmaya devam etmektedir.

Uzun vadeli güvenlik açısından, ne RSA'nın ne de Ed25519'un gelecekteki kuantum bilgisayarların saldırılarına karşı dirençli olmadığını hatırlamak önemlidir [3] ve kuantum sonrası algoritmalara geçiş, şu anda mevcut olmayan yeni DKIM standartlarını gerektirecektir; bu nedenle yeni nesil kriptografi gelişmelerini ve bu alandaki gelecekteki ACN önerilerini izlemek çok önemlidir.

Kriptografik anahtar yönetimi hususlarında, DKIM özel anahtarı, yetkisiz erişimi veya güvenlik ihlallerini önlemek için, yalnızca yetkili hizmetlerin erişebileceği izole sistemlerde tutularak, kısıtlayıcı izinler benimsenerek, periyodik olarak değiştirilerek ve sürekli olarak izlenerek, sıkı güvenlik önlemleriyle korunmalıdır.

» başa dön

5.3. DMARC

DMARC – Alan Adı Tabanlı Mesaj Kimlik Doğrulaması, Raporlama ve Uyumluluk, RFC 7489, SPF ve DKIM mekanizmalarını entegre eden^adı sahibinin, o alan adından iletilen mesajların alıcılarına, SPF ve DKIM doğrulamalarından geçemeyen mesajları yönetme politikalarını belirtmesine olanak tanıyan bir kimlik doğrulama protokolüdür.

Özellikle DMARC, SPF ve DKIM tarafından doğrulanan alanlar ile alınan mesajın "message-from " alanıyla ilgili alan arasındaki uyumu doğrulayan bir doğrulama mekanizması (hizalama olarak adlandırılır) sunar. "Mesajdan gelen" alanı ile SPF/DKIM alanı arasındaki hizalama kontrolünün, ilgili SPF/DKIM doğrulaması başarısız olursa her durumda başarısız olacağını unutmayın (Şekil 4'e bakınız)

Hizalama, katı modda doğrulanabilir ; bu modda SPF/DKIM tarafından kimliği doğrulanan alan adları ile mesajdan gelen alan adıyla ilgili alan adı arasında tam bir eşleşme gereklidir. Gevşek modda ise alt alan adları farklı olsa bile birincil alan adlarının eşleşmesi yeterlidir.

Örneğin, gevşek modda sub1.example.com ve sub2.example.com alan adları için DMARC doğrulama amacıyla bir eşleşme bulunur (çünkü birincil alan adı olan example.com aynıdır). Ancak katı modda, alan adları arasında tam bir eşleşme olmadığı için DMARC eşleşme kontrolü başarısız olur.

Hizalama doğrulaması sayesinde, bir saldırgan SPF ve/veya DKIM kontrollerini, SPF ve/veya kimliği doğrulanmış imza alanından farklı bir zarf göndericisinden farklı bir mesaj göndericisi kullanarak geçmeyi başarsa bile , DMARC yine de tutarsızlığı tespit ederek gönderenin kimliğinin tutarlı ve güvenilir bir şekilde doğrulanmasını sağlar [2] .

DMARC doğrulamasında başarısız ^olan mesajların yönetimine ilişkin politikalar, gönderen etki alanının göreceli DNS sunucusunun DMARC kaydı adı verilen bir TXT kaydında belirtilir ve bu paragrafın sonraki bölümünde açıklanır.

DMARC ayrıca, alıcılara, o alan adından kaynaklandığı iddia edilen mesajlarla ilgili olarak gönderen alan adı sahiplerine rapor göndermelerini belirtme olanağı da sunar. Bu sayede, alan adı sahibi, alan adının yetkisiz bir şekilde kullanılıp kullanılmadığını ve ne ölçüde kullanıldığını doğrulayabilir; örneğin, toplam kaynak iddiasında bulunan mesajlar arasından kaç mesajın gerçekten kendilerine ait olduğunu analiz edebilir.

SPF ve DKIM'de olduğu gibi, DMARC'ın da gönderici ve alıcı tarafından doğru şekilde yapılandırılması gerekir ve özellikle şu hususlara dikkat edilmelidir:

• Gönderici, DMARC doğrulamasından geçemeyen mesajların nasıl yönetileceğine dair politikaları belirten DMARC kaydını DNS'inde yayınlamalıdır;
• Alıcının, aldığı mesajlarda DMARC doğrulamasını gerçekleştirecek şekilde posta sunucusunu yapılandırması gerekir.

5.3.1. DMARC Kaydı

DMARC kaydı adı, _dmarc.domain yapısına sahiptir ; burada _dmarc, DNS kaydının bir DMARC kaydı olduğunu belirtmek için kullanılan bir etikettir ve domain ise politikanın atıfta bulunduğu etki alanıdır.

DMARC kaydı, aşağıdakiler de dahil olmak üzere çeşitli öğeleri belirten bir dizi anahtar-değer çiftinden oluşur:

• v: DMARC protokolü sürüm²⁰;
• p : DMARC doğrulamasında başarısız olan mesajlara uygulanacak politika; none , quarantine , reject değerlerinden birini alabilir .
• aspf: SPF kontrolüne uygulanacak hizalama modu ( relaxed, default value veya strict);
• adkim : DKIM kontrolüne uygulanacak hizalama modu ( gevşek , varsayılan değer veya katı olabilir );
• rua: Gönderen alan adından alınan mesajlara ilişkin istatistiksel ve özet bilgiler içeren toplu raporların gönderileceği e-posta adresleri;
• ruf: DMARC doğrulamasından geçemeyen gönderen alan adından alınan bireysel mesajlar hakkında ayrıntılı raporların gönderileceği e-posta adresleri.

DMARC kaydına örnek

Adı:
_dmarc.example.com
Değer:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s

Örnek DMARC kaydı example.com alan adıyla ilişkilidir , sürüm 1'i kullanır ve DMARC doğrulamasında başarısız olan mesajlar için reddetme politikasını belirtir; SPF ve DKIM alan adlarının uyumunun doğrulanması için katı mod ( ) talep eder ve toplu raporları dmarc-reports@example.com adresine , başarısızlık raporlarını ise dmarc-fail@example.com adresine iletir .

5.3.2. DMARC Politikaları

Önceki paragrafta açıklandığı gibi, DMARC kaydı, alıcı posta sunucusunun DMARC doğrulamasından geçemeyen mesajlar için uygulaması gereken politikayı belirtir. Olası politikalar şunlardır:

• Hiçbiri: Gönderen alan adı, DMARC doğrulamasında başarısız olan mesajların teslimiyle ilgili herhangi bir bilgi vermez;
• Karantina: Gönderen alan adı, DMARC doğrulamasından geçemeyen mesajların şüpheli olarak değerlendirilmesi gerektiğini belirtir (örneğin, daha fazla incelemeye tabi tutulmalı, spam olarak ele alınmalı veya şüpheli olarak etiketlenmelidir);
• Reddet: Gönderen alan adı, DMARC doğrulamasından geçemeyen mesajların reddedilmesi gerektiğini belirtir.

5.3.3. Politika Doğrulama ve Uygulama Süreci

Hem gönderenin hem de alıcının posta sunucularında DMARC protokolü doğru şekilde yapılandırılmışsa, mesaj alındığında alıcı posta sunucusu ilgili doğrulamaları gerçekleştirmek için SPF ve DKIM kayıtlarını ve ayrıca DMARC kaydını (5.2.4 paragrafının başında ayrıntılı olarak açıklanmıştır) alır. Mesaj DMARC doğrulamasından geçemezse, DMARC kaydında belirtilen politika (yok, karantinaya al veya reddet) uygulanır.

Her posta sunucusunun, SPF, DKIM ve DMARC doğrulamalarının sonuçlarını da dikkate alarak, bir mesajın teslim edilip edilmeyeceğine karar vermek için yerel sezgisel yöntemler ve politikalar benimseyebileceğini unutmayın. Bu nedenle, genellikle yukarıda belirtilen doğrulamaların ardından ek bir karar verme süreci ("Şekil 5'teki "Standart filtre") vardır ve bu süreç, örneğin spam önleme ve kötü amaçlı yazılım önleme filtreleri gibi daha fazla kontrol içerebilir.

Ayrıca, alıcı posta sunucusu şunları iletebilir:

• DMARC kaydının rua alanında belirtilen adreslere , gönderen alan adından alınan mesajlara ilişkin istatistiksel ve özet bilgiler içeren toplu raporlar gönderilir;
• DMARC kaydının ruf alanında belirtilen adreslere , DMARC doğrulamasından geçemeyen gönderen alan adından alınan bireysel mesajlara ilişkin ayrıntılı raporlar gönderilir

» başa dön

6. Sonuçlar

Önceki bölümde tartışıldığı gibi, gönderici alan adı taklitine bağlı tehditlerle en iyi şekilde mücadele etmek için incelenen üç protokolün de birlikte uygulanması ve özellikle de şu hususların dikkate alınması gerekmektedir: [3]:

• Gönderen alan adı, DNS'te SPF, DKIM ve DMARC kayıtlarını doğru şekilde yayınlar;
• Gönderenin posta sunucusu, mesajları DKIM ile imzalamak üzere yapılandırılmıştır;
• Alıcının posta sunucusu, SPF ve DKIM doğrulamalarını gerçekleştirmek ve DMARC politikalarını uygulamak üzere yapılandırılmıştır.

Protokolün uygulanmasına ilişkin olarak, aşağıdaki öneriler de formüle edilmiştir [2]:

• Alan adı adına e-posta göndermeye yetkili IP adreslerini belirterek SPF'yi yapılandırın; e-posta iletimi için kullanılmayan alan adları için, örneğin yalnızca web siteleri için tasarlanmış olanlar için, o alan adı için geçerli e-posta göndericisinin olmadığını açıkça belirtmek üzere bir SPF kaydı oluşturulmalıdır;
• Bu belgenin yazıldığı tarih itibariyle DKIM anahtarları için güvenli kabul edilen en gelişmiş şifreleme protokolleri ve algoritmaları kullanılmalıdır; 2048 bit RSA önerilmektedir;
• Posta sunucusunda saklanan DKIM özel anahtarını yeterli şekilde koruyun, kısıtlayıcı erişim izinleri benimseyin ve yalnızca posta sunucusu yazılımının anahtara okuma ayrıcalığına sahip olmasını sağlayın;
• Olası bir özel anahtar güvenliğinin ihlalinin etkisini azaltmak için her posta sunucusunu benzersiz bir anahtar çifti ve seçici ile yapılandırın;
• Özel anahtarı hem kaz accidental ifşadan hem de bir saldırgan tarafından erişim veya değiştirme girişimlerinden koruyun;
• Posta listeleriyle ilgili yazılımın gelen mesajlardaki DKIM imzalarını doğrulamasını ve giden mesajlara yeni DKIM imzaları eklemesini sağlayın;
• Kuruluş adına e-posta gönderen her üçüncü taraf için benzersiz DKIM anahtar çiftleri kullanın;
• Olası bir güvenlik ihlalinin etkisini azaltmak için DKIM anahtar çiftlerini periyodik olarak (en az altı ayda bir) değiştirin;
• Güvenlik ihlalinden şüphelenilmesi durumunda anahtarları derhal geri alın;
• DMARC raporlarını izleyerek yapılandırma hatalarını veya kötüye kullanım girişimlerini tespit edin.

Daha ayrıntılı bilgi için, Referans Belgelerinde listelenen kaynaklara bakınız .

E-posta güvenliğini yeterince korumak için, burada incelenen kimlik doğrulama protokollerine ek olarak, bu kılavuzların konusu olmayan başka protokoller de olduğu gözlemlenmiştir; örneğin, iletim kanalı şifrelemesini garanti eden TLS (Transport Layer Security) ve uçtan uca şifreleme ve mesaj kimlik doğrulamasıyla ilgili olan SMIME ve OpenPGP gibi

Ayrıca, kesin anlamda bir e-posta güvenlik protokolü olmasa da, e-posta hizmeti güvenliği amacıyla DNSSEC'in (Alan Adı Sistemi Güvenlik Uzantıları) uygulanmasının önerildiği belirtilmektedir. DNSSEC, DNS sorgularının bütünlüğünü ve orijinalliğini garanti altına almak için DNS kayıtlarına kriptografik imzalar ekleyen bir DNS protokol uzantısıdır. Örneğin, DNSSEC sayesinde SPF, DKIM ve DMARC kayıtlarıyla ilgili bilgiler iletim sırasında korunarak, değiştirilme riski azaltılır ve dolayısıyla e-posta hizmeti güvenliği artırılır.

» başa dön

Ek A: Güvenlik Önlemleri

Ulusal Siber Güvenlik Çevresi (PSNC)

PR.IP-1: Güvenlik ilkelerini (örneğin, en az işlevsellik ilkesi) içeren BT sistemlerinin ve endüstriyel kontrol sistemlerinin yapılandırılması için referans uygulamalar (temel standartlar olarak adlandırılır) tanımlanır ve yönetilir.

1. Kategori ID.AM ile ilgili olarak da en azından şu hususları belirten ayrıntılı ve güncellenmiş bir belge bulunmaktadır:
   • a) BT ve endüstriyel kontrol sistemlerinin yapılandırmalarının geliştirilmesi ve yalnızca benimsenen yapılandırmaların devreye alınması için benimsenen güvenlik politikaları;
   • b) Kullanılan BT ve endüstriyel kontrol sistemi konfigürasyonlarının listesi ve ilgili referans uygulamalarına atıf;
   • c) Güvenlik politikalarına uyumluluğa katkıda bulunan süreçler, metodolojiler ve teknolojiler.

Bulut Bilişim Düzenlemesi – Kamu Yönetimi için Dijital Altyapılar ve Hizmetler

PR.IP-01: Güvenlik ilkelerini (örneğin, en az işlevsellik ilkesi) içeren BT sistemlerinin ve endüstriyel kontrol sistemlerinin yapılandırılması için referans uygulamalar (temel standartlar olarak adlandırılır) tanımlanır ve yönetilir.

1. Uygulama güvenliğiyle ilgili politikalar ve prosedürler, uygulama güvenliği özelliklerinin planlanması, gerçekleştirilmesi ve sürdürülmesi için yeterli desteği sağlamak amacıyla tanımlanır ve en az yılda bir kez gözden geçirilip güncellenmelidir.
2. Kategori ID.AM ile ilgili olarak da en azından şu hususları belirten ayrıntılı ve güncellenmiş bir belge bulunmaktadır:
   • a) BT ve endüstriyel kontrol sistemlerinin yapılandırmalarının geliştirilmesi ve yalnızca benimsenen yapılandırmaların devreye alınması için benimsenen güvenlik politikaları;
   • b) Kullanılan BT ve endüstriyel kontrol sistemi konfigürasyonlarının listesi ve ilgili referans uygulamalarına atıf;
   • c) Güvenlik politikalarına uyumluluğa katkıda bulunan süreçler, metodolojiler ve teknolojiler.
3. Çeşitli uygulamaların güvenliğine ilişkin temel gereksinimler tanımlanmış ve belgelenmiştir.
4. Tanımlanmış güvenlik gereksinimlerine ve uyumluluk yükümlülüklerine uyma düzeyini izlemek için yararlı olan teknik nitelikteki ölçütler tanımlanır ve uygulanır.
5. Uygulama güvenliği için, mümkün olduğunda düzeltmeyi otomatikleştiren, uygulama güvenlik açıklarının azaltılması ve giderilmesine yönelik bir süreç mevcuttur.
6. Cihazın işletim sistemleri ve uygulamalarla uyumluluğunu doğrulamak için bir süreç mevcuttur.
7. İşletim sistemi, yama ve/veya uygulamalar açısından bir varyasyon yönetim sistemi mevcuttur.

Bulut Düzenlemesi – Kamu Yönetimi için Bulut Hizmetleri

PR.IP-01: Güvenlik ilkelerini (örneğin, en az işlevsellik ilkesi) içeren BT sistemlerinin ve endüstriyel kontrol sistemlerinin yapılandırılması için referans uygulamalar (temel standartlar olarak adlandırılır) tanımlanır ve yönetilir.

1. Uygulama güvenliği ile ilgili politikalar ve prosedürler, uygulama güvenliği özelliklerinin planlanması, gerçekleştirilmesi ve sürdürülmesi için yeterli desteği sağlamak amacıyla tanımlanır ve en az yılda bir kez gözden geçirilip güncellenmelidir [IaaS, SaaS].
2. Kategori ID.AM ile ilgili olarak da en azından şu hususları belirten ayrıntılı ve güncellenmiş bir belge bulunmaktadır:
   • a) BT ve endüstriyel kontrol sistemlerinin yapılandırmalarının geliştirilmesi ve yalnızca benimsenen yapılandırmaların devreye alınması için benimsenen güvenlik politikaları;
   • b) Kullanılan BT ve endüstriyel kontrol sistemi konfigürasyonlarının listesi ve ilgili referans uygulamalarına atıf;
   • c) [SaaS] güvenlik politikalarına uyumluluğa katkıda bulunan kullanılan süreçler, metodolojiler ve teknolojiler.
3. Çeşitli uygulamaların güvenliğine ilişkin temel gereksinimler tanımlanmış ve belgelenmiştir.
4. Tanımlanmış güvenlik gereksinimlerine ve uyumluluk yükümlülüklerine uyma düzeyini izlemek için yararlı olan teknik nitelikteki ölçütler tanımlanır ve uygulanır. 5. Uygulama güvenliği için uygulama güvenlik açığı azaltma ve kurtarma süreci vardır ve mümkün olduğunda düzeltme otomatikleştirilir.
5. İşletim sistemleri ve uygulamalarla [PaaS, SaaS] cihaz uyumluluğunu doğrulamak için bir süreç vardır.
6. İşletim sistemi, yama ve/veya uygulamalar [PaaS, SaaS] açısından bir varyasyon yönetim sistemi mevcuttur.

2 NIS

PR.PS-01: Yapılandırma yönetimi uygulamaları oluşturulur ve uygulanır.

1. En azından ilgili bilgi ve ağ sistemleri için, güvenli temel yapılandırmaları (güçlendirilmiş) tanımlanmış ve güncellenmiş bir listede belgelenmiştir.
2. GV.PO-01 numaralı önlemde belirtilen politikalara uygun olarak, 1. maddeyle ilgili prosedürler benimsenmiş ve belgelendirilmiştir.

» başa dön

Kaynakça

[1] NIST, «Teknik Not 1945».
[2] NIST, «NIST Özel Yayın 800-177 Revizyon 1»
[3] Ulusal Siber Güvenlik Ajansı, «Kuantum sonrası ve kuantum kriptografi - Kuantum tehdidine hazırlık».
[4] Ulusal Siber Güvenlik Ajansı, «E-posta kimlik doğrulama çerçevesi».

» başa dön