TLS ve SSL’e giriş

Bir OpenStack dağıtımında ağ trafiğinin gizliliğini veya bütünlüğünü sağlamak için bir güvenlik gereksinimi olduğu durumlar vardır. Bu genellikle Taşıma Katmanı Güvenliği (TLS) protokolü gibi şifreleme önlemleri kullanılarak gerçekleştirilir.

Tipik bir dağıtımda, kamuya açık ağlar üzerinden iletilen tüm trafik güvenlidir, ancak en iyi güvenlik prensibi, dahili trafiğin de güvence altına alınması gerektiğini belirtir. Koruma için güvenlik bölgesi ayrımına güvenmek yetersizdir. Bir saldırgan, bir hipervizöre veya sunucu kaynaklarına erişir, bir API uç noktasını veya başka herhangi bir servise erişirse, bulutların kolayca yönetim komutlarını, iletilerini, komutlarını veya enformasyonlarını yakalayamamalı veya bulamamamalıdır.

Tüm etki alanları, yönetim alanı servisleri ve servis içi iletişimler de dahil TLS ile güvence altına alınmalıdır. TLS, OpenStack servislerine ve OpenStack servisleri arasındaki kullanıcı iletişiminin doğruluğunu, reddedilmemesini, gizliliğini ve bütünlüğünü sağlamak için mekanizmalar sağlar.

Güvenli Soket Katmanı (SSL) protokollerinde yayınlanan güvenlik açıklarından ötürü, TLS’in SSL’ye göre öncelikli olarak kullanılmasını ve eski tarayıcılara veya kitaplıklara uyumluluk gerekmedikçe SSL’nin her durumda devre dışı bırakılmasını şiddetle öneririz.

Kamu Anahtar Altyapısı (PKI), bir ağdaki iletişimi sağlamak için kullanılan bir çatıdır. Tarafların kimliğini doğrularken trafiğin güvenli bir şekilde gönderilebilmesini sağlamak için bir dizi sistem ve işlemden oluşur. Burada açıklanan PKI profili PKIX çalışma grubu tarafından geliştirilen İnternet Mühendisliği Görev Gücü (IETF) Ortak Anahtar Altyapısı (PKIX) profilidir. PKI’nın temel bileşenleri şunlardır:

Sayısal Sertifikalar

İmzalı kamu anahtarı sertifikaları, bir varlığın doğrulanabilir verisine, diğer anahtara ve diğer bazı niteliklere sahip olan veri yapılarıdır. Bu sertifikalar bir Sertifika Otoritesi (CA) tarafından verilir. Sertifikalar, güvenilir olan bir CA tarafından imzalanmış olduğundan, doğrulandıktan sonra varlık ile ilişkili ortak anahtarın söz konusu varlıkla ilişkilendirilmesi garanti edilir. Bu sertifikaları tanımlamak için kullanılan en yaygın standart X.509 standardıdır. Şu andaki standart olan X.509 v3, RFC5280 adresinde ayrıntılı olarak açıklanmıştır. Sertifikalar, çevrimiçi varlıklar kimliğini kanıtlamak için bir mekanizma olarak CA’lar tarafından verilir. CA, sertifikadan bir ileti özeti oluşturarak ve özetini kendi özel anahtarıyla şifreleyerek sertifikaya sayısal olarak imzalar.

Son varlık

Bir sertifikanın konusu olan kullanıcı, işlem veya sistem. Son taraf sertifika talebini onay için bir Kayıt Otoritesine (RA) gönderir. Onaylandığı takdirde, RA talebi bir Sertifika Otoritesine (CA) iletir. Sertifika Yetkilisi isteği doğrular ve eğer bilgi doğruysa, bir sertifika üretilir ve imzalanır. Bu imzalı sertifika daha sonra bir Sertifika Havuzuna gönderilir.

Güvenme partisi

Sertifikada listelenen genel anahtarı referans alarak doğrulanabilir dijital olarak imzalanmış sertifikayı alan uç nokta. Bağlayıcı parti, sertifika zincirini doğrulamak için bir konumda olmalı, CRL içinde yer almamalı ve sertifikadaki geçerlilik tarihini doğrulayabilmelisiniz.

Sertifikasyon Otoritesi (CA)

CA, son taraf tarafından hem sertifika ilkeleri, yönetim yönetimi ve sertifika verme için sertifikaya güvenen taraflardan güvenilir bir varlıktır.

Kayıt Otoritesi (RA)

Bir CA’nın belirli yönetim işlevlerini devrettiği isteğe bağlı bir sistem; bu, bir CA tarafından bir sertifika verilmeden önce son varlıkların kimlik doğrulaması gibi işlevleri içerir.

Sertifika İptal Listesi (CRL)

Bir Sertifika İptal Listesi (CRL), iptal edilen sertifika seri numaralarının bir listesidir. Bu sertifikaları sunan uç birimler bir PKI modelinde güvenilmemelidir. İptal, örneğin çeşitli nedenlerle, kilit ödünleme, CA açık vermesi nedeniyle olabilir.

CRL veren

Sertifika iptal listelerinin bir CA tarafından delege edilmesi için isteğe bağlı bir sistem.

Sertifika Deposu

Son varlık belgelerinin ve sertifika iptal listelerinin depolandığı ve bakıldığı - bazen sertifika paketi olarak da anılır.

PKI, veri ve kimlik doğrulamayı güvence altına almak için şifreleme algoritmaları, şifre modları ve protokoller sunacak çatıyı oluşturur. API uç noktaları için TLS kullanımı da dahil olmak üzere, tüm hizmetleri Genel Anahtar Altyapısı (PKI) ile sağlamanız önerilir. Tüm bu sorunları çözmek için tek başına nakliye veya mesajların şifrelenmesi veya imzalanması imkansızdır. Ev sahiplerinin kendileri güvende olmalı ve özel kimlik bilgilerini ve anahtarlarını korumak için ilke, ad alanları ve diğer denetimleri uyguluyor olmalıdır. Bununla birlikte, anahtar yönetim ve koruma zorlukları, bu kontrollerin gerekliliğini azaltmaz veya önemini azaltmaz.

Sertifika otoriteleri

Birçok organizasyon, kendi OpenStack kullanıcıları veya servisleri için sertifika vermek üzere kullanmaları gereken kendi Sertifika Otoritesi (CA), sertifika ilkeleri ve yönetimi olan bir Genel Anahtar Altyapısına sahiptir. Kamu güvenliği alanının İnternet’e baktığı organizasyonlar ayrıca, yaygın olarak tanınan bir genel CA tarafından imzalanmış sertifikalara ihtiyaç duyacaktır. Yönetim ağı üzerinden şifreleme iletişimi için, genel bir CA kullanmamaları önerilir. Bunun yerine, çoğu dağıtımın kendi dahili CA’sını kurmasını bekliyoruz ve öneriyoruz.

OpenStack bulut mimarının dahili sistemler ve müşterilere yönelik servisler için ayrı PKI dağıtımları kullanmayı düşünmesi önerilir. Bu, bulut kurucusunun PKI altyapısının kontrolünü elinde tutmasına ve diğer şeylerin yanısıra dahili sistemler için sertifika talep etme, imzalama ve dağıtmayı kolaylaştırır. Gelişmiş yapılandırmalar, farklı güvenlik etki alanları için ayrı PKI dağıtımları kullanabilir. Bu, uygulayıcıların, birine verilen sertifikaların başka biri tarafından tanınmadığından emin olarak, ortamların kriptografik ayrımını sürdürebilmelerini sağlar.

Bulut uç noktalarına (veya müşterinin standart işletim sistemi tarafından sağlanan sertifika paketleri dışında bir şey yüklememesi beklenen müşteri arayüzleri) İnternet’te TLS’yi desteklemek için kullanılan sertifikalar, işletim sistemi sertifika paketinde yüklü olan Sertifika Otoriteleri kullanılarak sağlanmalıdır. Tipik tanınmış sağlayıcılar Let’s Encrypt, Verisign ve Thawte’dir ancak diğerleri mevcuttur.

Sertifika oluşturma ve imzalama konusunda yönetimsel, politik ve teknik zorluklar vardır. Bu, bulut mimarlarının veya operatörlerin, burada önerilen rehberliğin yanı sıra endüstri liderleri ve tedarikçilerinin tavsiyelerini almak isteyebilecekleri bir alandır.

TLS kitaplıkları

OpenStack ekosistemindeki bileşenler, servisler ve uygulamalar veya OpenStack’in bağımlılıkları uygulanır veya TLS kitaplıklarını kullanacak şekilde yapılandırılabilir. OpenStack içindeki TLS ve HTTP servisleri genellikle FIPS 140-2 için doğrulanmış bir modülü olan OpenSSL kullanılarak gerçekleştirilir. Bununla birlikte, her uygulamanın veya servisin hala OpenSSL kitaplıklarını kullandıklarında zayıf yönleri olabileceğini unutmayın.

Kriptografik algoritmalar, şifreleme kipleri, ve protokoller

We recommend that a minimum of TLS 1.2 be used. Older versions such as TLS 1.0, 1.1, and all versions of SSL (TLS’s predecessor) are vulnerable to multiple publicly known attacks and therefore must not be used. TLS 1.2 may be used for broad client compatibility, however exercise caution when enabling this protocol. Only enable TLS version 1.1 if there is a mandatory compatibility requirement and you are aware of the risks involved.

TLS 1.2 kullanırken hem istemcileri hem de sunucuyu denetlediğinizde şifre paketi ECDHE-ECDSA-AES256-GCM-SHA384 ile sınırlı olmalıdır. Her iki sonlandırma notasını da kontrol etmediğiniz ve TLS 1.1 veya 1.2’yi kullanmadığınız durumlarda, daha genel makul bir şifreleme seçimi olarak HIGH:!aNULL:!eNULL:!DES:!3DES:!SSLv3:!TLSv1:!CAMELLIA kullanabilirsiniz.

Bununla birlikte, bu kitap kriptografi hakkında kapsamlı bir referans olmayı amaçlamadığından, OpenStack servislerinizde hangi algoritmaları veya şifre modlarını etkinleştirmeniz veya devre dışı bırakmanız gerektiğine ilişkin kurallar vermek istemiyoruz. Daha fazla bilgi için tavsiye etmek istediğimiz bazı otoriter referanslar var:

Özet

OpenStack bileşenlerinin karmaşıklığı ve dağıtım olasılıkları göz önüne alındığında, her bileşenin TLS sertifikalarının, anahtarlarının ve CA’ların uygun yapılandırmasını almasını sağlamanız gerekir. Sonraki bölümlerde aşağıdaki servisler tartışılmaktadır:

  • Hesaplama API uç noktaları

  • Kimlik API uç noktaları

  • Ağ API uç noktaları

  • Depolama API uç noktaları

  • Mesajlaşma sunucusu

  • Veritabanı sunucusu

  • Kontrol Paneli