Azure NetApp Files'da veri şifrelemeyi anlama

2024-02-12

Azure NetApp Files verileri iki farklı yöntemle şifreler:

Bekleyen şifreleme: Veriler FIPS 140-2 uyumlu standartlar kullanılarak yerinde şifrelenir.
Aktarım sırasında şifreleme: Veriler, istemci ile sunucu arasında aktarıldığı için aktarım sırasında veya kablo üzerinden şifrelenir.

Dinlenme halindeki verilerin şifrelemesini anlama

Azure NetApp Files'da bekleyen veriler iki şekilde şifrelenebilir:

Tek şifreleme, Azure NetApp Files birimleri için yazılım tabanlı şifreleme kullanır.
Çift şifreleme , fiziksel depolama cihazı katmanına donanım düzeyinde şifreleme ekler.

Azure NetApp Files, AES-256 şifreleme anahtarları oluşturmak için standart CryptoMod kullanır. CryptoMod , CMVP FIPS 140-2 doğrulanmış modüller listesinde listelenir; Daha fazla bilgi için bkz. FIPS 140-2 Sertifika #4144. Şifreleme anahtarları birimlerle ilişkilendirilir ve Microsoft platform tarafından yönetilen anahtarlar veya müşteri tarafından yönetilen anahtarlar olabilir.

Aktarım sırasında veri şifrelemeyi anlama

Azure NetApp Files, bekleyen verilerin güvenliğini sağlamaya ek olarak, uç noktalar arasında aktarım sırasında verilerin güvenliğini sağlayabilir. Kullanılan şifreleme yöntemi protokole veya özelliğe bağlıdır. DNS, Azure NetApp dosyalarında aktarım sırasında şifrelenmez. Azure NetApp Files'da SMB ve NFS şifrelemesi, LDAP ve veri çoğaltma hakkında bilgi edinmek için okumaya devam edin.

SMB şifrelemesi

SMB3.x protokol sürümünü kullanan Windows SMB istemcileri yerel olarak SMB şifrelemesini destekler. SMB şifrelemesi uçtan uca yürütülür ve AES-256-GCM/AES-128-GCM ve AES-256-CCM/AES-128-CCM şifreleme paketleri kullanılarak SMB konuşmasının tamamını şifreler.

Azure NetApp Files birimleri için SMB şifrelemesi gerekli değildir, ancak ek güvenlik için kullanılabilir. SMB şifrelemesi bir performans yükü ekler. SMB şifrelemesi ile ilgili performans konuları hakkında daha fazla bilgi edinmek için bkz. Azure NetApp Files için SMB performansı en iyi yöntemleri.

SMB bağlantıları için şifreleme gerektirme

Azure NetApp Files , tüm SMB bağlantılarında şifrelemeyi zorlama seçeneği sağlar. Şifrelemeyi zorunlu tutma, şifrelenmemiş SMB iletişimlerine izin vermiyor ve SMB bağlantıları için SMB3 ve üzerini kullanıyor. Şifreleme, AES şifrelemesi kullanılarak gerçekleştirilir ve tüm SMB paketlerini şifreler. Bu özelliğin düzgün çalışması için SMB istemcilerinin SMB şifrelemesini desteklemesi gerekir. SMB istemcisi şifrelemeyi ve SMB3'i desteklemiyorsa SMB bağlantılarına izin verilmez. Bu seçenek etkinleştirilirse, aynı IP adresine sahip tüm paylaşımlar şifreleme gerektirir, bu nedenle şifreleme için SMB paylaşımı özellik ayarını geçersiz kılar.

Alternatif olarak şifreleme, Azure NetApp Files biriminin tek tek paylaşımı düzeyinde ayarlanabilir.

UNC sağlamlaştırma

2015'te Microsoft, SMB paylaşımlarında uzaktan kod yürütülmesine izin verebilecek uzak ağ yolu güvenlik açıklarını gidermek için UNC sağlamlaştırmayı (MS15-011 ve MS15-014) kullanıma sunulmuştur. Daha fazla bilgi için bkz. MS15-011 & MS15-014: Sağlamlaştırma Grup Politikası.

UNC sağlamlaştırma, UNC yollarının güvenliğini sağlamak için üç seçenek sağlar:

RequireMutualAuthentication – Kimlik sahtekarlık saldırılarını engellemek için kimlik doğrulaması gerekli/gerekli değildir.
RequireIntegrity – Kurcalama saldırılarını engellemek için bütünlük denetimi gerekli/gerekli değildir.
RequirePrivacy – Trafik algılamayı önlemek için gizlilik (SMB paketlerinin toplam şifrelenmesi) etkinleştirildi/devre dışı bırakıldı.

Azure NetApp Files, UNC sağlamlaştırmanın üç türünü de destekler.

NFS Kerberos

Azure NetApp Files ayrıca AES-256-GCM/AES-128-GCM ve AES-256-CCM/AES-128-CCM şifreleme paketlerini kullanarak Kerberos kimlik doğrulaması aracılığıyla NFSv4.1 konuşmalarını şifreleme olanağı sağlar.

NFS Kerberos ile Azure NetApp Files üç farklı güvenlik çeşidini destekler:

Kerberos 5 (krb5) – Yalnızca ilk kimlik doğrulaması; NFS dışarı aktarma işlemine erişmek için bir Kerberos bileti değişimi/kullanıcı oturum açması gerektirir. NFS paketleri şifrelenmez.
Kerberos 5i (krb5i) – İlk kimlik doğrulaması ve bütünlük denetimi; NFS dışarı aktarma işlemine erişmek için bir Kerberos anahtar değişimi/kullanıcı oturum açması gerektirir ve ortadaki adam saldırılarını (MITM) önlemek için her NFS paketine bütünlük denetimleri ekler.
Kerberos 5p (krb5p) – İlk kimlik doğrulaması, bütünlük denetimi ve gizlilik; NFS dışarı aktarma işlemine erişmek için bir Kerberos anahtar değişimi/kullanıcı oturum açması gerektirir, bütünlük denetimleri gerçekleştirir ve içeriğini şifrelemek için her NFS paketine bir GSS sarmalayıcı uygular.

Her Kerberos şifreleme düzeyinin performans üzerinde bir etkisi vardır. Şifreleme türleri ve güvenlik önlemleri daha güvenli yöntemler benimsedikçe, performans etkisi artış gösterir. Örneğin, krb5krb5i'den daha iyi performans gösterir, krb5i krb5p'den daha iyi performans gösterir, AES-128, AES-256'dan daha iyi performans gösterir, vb. Azure NetApp Files'da NFS Kerberos'un performans etkisi hakkında daha fazla bilgi için bkz. Kerberos'un Azure NetApp Files NFSv4.1 birimleri üzerindeki performans etkisi.

Uyarı

NFS Kerberos yalnızca Azure NetApp Files'da NFSv4.1 ile desteklenir.

Aşağıdaki görüntüde Kerberos 5 (krb5) kullanılır; yalnızca ilk kimlik doğrulama isteği (oturum açma/anahtar alma) şifrelenir. Diğer tüm NFS trafiği düz metin olarak gelir.

Kerberos 5i (krb5i; bütünlük denetimi) kullanılırken, bir izleme NFS paketlerinin şifrelenmediğini, ancak pakete istemci ve sunucunun sağlama toplamı kullanılarak aktarılan verilerin bütünlüğünü sağlamasını gerektiren bir GSS/Kerberos sarmalayıcısı eklendiğini gösterir.

Kerberos 5p (gizlilik; krb5p), GSS/Kerberos sarmalayıcı kullanarak izleme görüntüsünde gösterildiği gibi tüm NFS trafiğinin uçtan uca şifrelemesini sağlar. Bu yöntem, her NFS paketinin şifrelemesini işleme gereksiniminden dolayı en fazla performans yükünü oluşturur.

Veri replikasyonu

Azure NetApp Files'da , veri koruması sağlamak için birimlerin tamamını Azure'daki bölgeler veya bölgeler arasında çoğaltabilirsiniz. Çoğaltma trafiği Azure bulutunda bulunduğundan aktarımlar, paket algılama ve ortadaki adam saldırılarını (gizli dinleme veya iletişim uç noktaları arasında kimliğe bürünme) önlemek için erişimi sınırlı olan güvenli Azure ağ altyapısında gerçekleşir. Ayrıca, çoğaltma trafiği FIPS 140-2 uyumlu TLS 1.2 standartları kullanılarak şifrelenir. Ayrıntılar için bkz . Güvenlik hakkında SSS.

LDAP şifrelemesi

Normalde LDAP arama ve bağlama trafiği düz metin olarak kablo üzerinden geçer, yani ağ paketlerini algılama erişimi olan herkes LDAP sunucusundan kullanıcı adları, sayısal kimlikler, grup üyelikleri vb. bilgi edinebilir. Bu bilgiler daha sonra kullanıcıları yanıltmak, kimlik avı saldırıları için e-posta göndermek vb. için kullanılabilir.

LDAP iletişimlerinin kesilmesini ve okunmasını engellemek için LDAP trafiği sırasıyla LDAP imzalama ve TLS üzerinden LDAP aracılığıyla AES ve TLS 1.2'den yararlanarak kablo üzerinden şifrelemeden yararlanabilir. Bu seçenekleri yapılandırma hakkında ayrıntılı bilgi için bkz. Active Directory bağlantılarını oluşturma ve yönetme.

LDAP imzalama

LDAP imzalama, kullanıcılar ve gruplar için UNIX kimliklerini barındıran Microsoft Active Directory sunucularında bulunan bağlantılara özgüdür. Bu işlevsellik, LDAP bağlantılarını barındıran AD sunucularına Basit Kimlik Doğrulama ve Güvenlik Katmanı (SASL) LDAP bağlamaları için bütünlük doğrulaması sağlar. İmzalama, Active Directory'nin Kerberos Anahtar Dağıtım Merkezi (KDC) hizmetleriyle GSS-API iletişim kullandığından güvenlik sertifikalarının yapılandırılmasını gerektirmez. LDAP imzalama yalnızca LDAP paketinin bütünlüğünü denetler; paketin yükünü şifrelemez.

LDAP imzalama, Grup İlkesi aracılığıyla Windows sunucusu tarafından LDAP imzalama (hiçbiri – istemci tarafından istenirse destek) veya LDAP imzalamayı zorunlu kılmak (gerekli) için de yapılandırılabilir. LDAP imzalama, LDAP trafiğine genellikle son kullanıcılar için fark edilemeyen bir performans yükü ekleyebilir.

Windows Active Directory ayrıca LDAP imzalama ve sızdırmazlık (LDAP paketlerinin uçtan uca şifrelenmesi) kullanmanızı sağlar. Azure NetApp Files bu özelliği desteklemez.

LDAP kanalı bağlama

Windows Active Directory etki alanı denetleyicilerinde bulunan bir güvenlik açığı nedeniyle, Windows sunucuları için varsayılan bir ayar değiştirildi. Ayrıntılar için bkz. Microsoft Güvenlik Önerisi ADV190023.

Temelde, Microsoft yöneticilerin kanal bağlama ile birlikte LDAP imzalamayı etkinleştirmesini önerir. LDAP istemcisi kanal bağlama belirteçlerini ve LDAP imzalamayı destekliyorsa, kanal bağlama ve imzalama gereklidir ve kayıt defteri seçenekleri yeni Microsoft düzeltme eki tarafından ayarlanır.

Azure NetApp Files varsayılan olarak LDAP kanal bağlamasını fırsatçı olarak destekler; yani istemci bunu desteklediğinde LDAP kanal bağlaması kullanılır. Kanal bağlamayı desteklemiyorsa/göndermiyorsa, iletişime hala izin verilir ve kanal bağlama zorlanmaz.

SSL üzerinden LDAP (bağlantı noktası 636)

Azure NetApp Files'daki LDAP trafiği her durumda 389 numaralı bağlantı noktasının üzerinden geçer. Bu bağlantı noktası değiştirilemez. SSL üzerinden LDAP (LDAPS) desteklenmez ve çoğu LDAP sunucusu satıcısı tarafından eski olarak kabul edilir (RFC 1777 1995'te yayımlandı). Azure NetApp Files ile LDAP şifrelemesi kullanmak istiyorsanız TLS üzerinden LDAP kullanın.

StartTLS üzerinden LDAP

StartTLS üzerinden LDAP , 2000 yılında RFC 2830 ile kullanıma sunulmuştur ve 2006'da RFC 4511 ile LDAPv3 standardıyla birleştirilmiştir. StartTLS bir standart haline getirildikten sonra LDAP satıcıları LDAPS'ye kullanım dışı olarak başvurmaya başladı.

StartTLS üzerinden LDAP, LDAP bağlantısı için 389 numaralı bağlantı noktasını kullanır. İlk LDAP bağlantısı yapıldıktan sonra bir StartTLS OID değişimi yapılır ve sertifikalar karşılaştırılır; ardından tüm LDAP trafiği TLS kullanılarak şifrelenir. Aşağıda gösterilen paket yakalama, LDAP kimlik doğrulamasını, StartTLS el sıkışmasını ile sonraki TLS ile şifrelenmiş LDAP trafiğini gösterir.

LDAPS ile StartTLS arasında iki temel fark vardır:

StartTLS LDAP standardının bir parçasıdır; LDAPS değildir. Sonuç olarak, LDAP sunucularında veya istemcilerinde LDAP kitaplığı desteği farklılık gösterebilir ve işlevsellik her durumda çalışabilir veya çalışmayabilir.
Şifreleme başarısız olursa, StartTLS yapılandırmanın normal LDAP'ye geri dönmesine izin verir. LDAPS bunu yapmaz. Sonuç olarak, StartTLS bazı esneklik ve dayanıklılık sunar, ancak yanlış yapılandırılmışsa güvenlik riskleri de sunar.

StartTLS üzerinden LDAP ile ilgili güvenlik konuları

StartTLS, yöneticilerin isterlerse normal LDAP trafiğine geri dönmesini sağlar. Güvenlik amacıyla, çoğu LDAP yöneticisi buna izin vermez. StartTLS için aşağıdaki öneriler LDAP iletişiminin güvenliğini sağlamaya yardımcı olabilir:

StartTLS'nin etkinleştirildiğinden ve sertifikaların yapılandırıldığından emin olun.
İç ortamlar için otomatik olarak imzalanan sertifikaları kullanabilirsiniz, ancak dış LDAP için bir sertifika yetkilisi kullanın. Sertifikalar hakkında daha fazla bilgi için bkz. Otomatik olarak imzalanan SSL ve Sertifika Yetkilisi Arasındaki Fark.
StartTLS kullanmayan LDAP sorgularını ve bağlamalarını önleyin. Varsayılan olarak, Active Directory anonim bağlamaları devre dışı bırakır.

Active Directory güvenlik bağlantısı

Azure NetApp Files birimleriyle Active Directory bağlantıları, önce en güçlü kullanılabilir Kerberos şifreleme türünü deneyecek şekilde yapılandırılabilir: AES-256. AES şifrelemesi etkinleştirildiğinde, etki alanı denetleyicisi iletişimleri (zamanlanmış SMB sunucusu parola sıfırlamaları gibi) etki alanı denetleyicilerinde desteklenen en yüksek kullanılabilir şifreleme türünü kullanır. Azure NetApp Files, kimlik doğrulama girişimi sırasında etki alanı denetleyicisi iletişimleri için aşağıdaki şifreleme türlerini destekler: AES-256, AES-128, RC4-HMAC, DES