Güvenli referans mimarileri

Hem kamu ağlarında hem de yönetim ağlarında SSL/TLS kullanmanızı öneririz bkz. TLS vekiller ve HTTP servisler. Bununla birlikte, gerçekte her yerde SSL/TLS dağıtmak çok zorsa, OpenStack SSL/TLS ihtiyaçlarınızı değerlendirmenizi ve burada tartışılan mimarilerden birini izlemenizi öneririz.

OpenStack SSL/TLS ihtiyaçlarını değerlendirirken yapılması gereken ilk şey, tehditleri tanımlamaktır. Bu tehditleri harici ve dahili saldırgan kategorilerine bölebilirsiniz, ancak OpenStack’in belirli bileşenleri hem kamu hem de yönetim ağlarında faaliyet gösterdiğinden hatlar bulanıklaşır.

Kamuya açık servisler için tehditler oldukça basittir. Kullanıcılar horizon ve keystone’a kullanıcı adı ve parolasıyla kimlik doğrulaması yapacaklardır. Kullanıcılar ayrıca, keystone belirteçlerini kullanarak diğer hizmetler için API uç noktalarına erişiyor olacaklardır. Bu ağ trafiği şifrelenmemişse, parolalar ve belirteçler bir saldırgan tarafından bir ortada-adam saldırısı kullanılarak erişilebilir. Saldırgan, daha sonra bu geçerli kimlik bilgilerini kötü amaçlı işlemleri gerçekleştirmek için kullanabilir. Tüm gerçek dağıtımlar, servisleri korumak için SSL/TLS kullanmalıdır.

Yönetim ağlarında konuşlandırılan servisler için, güvenlik alanlarının ağ güvenliği ile köprülemesi nedeniyle tehditler o kadar açık değildir. Yönetim şebekesine erişimi olan bir yöneticinin kötü niyetli bir şeyler yapmaya karar verme ihtimali her zaman vardır. Saldırganın özel anahtara erişmesine izin verilirse SSL/TLS bu durumda yardımcı olmaz. Yönetim ağındaki herkesin tabii ki özel anahtara erişmesine izin verilmez, bu nedenle kendinizi dahili saldırganlardan korumak için SSL/TLS kullanmaya değer. Yönetim ağınıza erişmesine izin verilen herkes % 100 güvenilir olsa dahi, yetkisiz bir kullanıcının yanlış yapılandırma veya yazılım açıklarından yararlanarak dahili ağınıza erişmesi için hala bir tehlike söz konusudur. Kullanıcıların, yönetim ağında konuşlandırılan OpenStack Hesaplama düğümlerinde bulunan örneklerde kendi kodlarını çalıştırdıklarını unutmamalısınız. Bir güvenlik açığı hipervizörden ayrılmalarına izin verirse, yönetim ağına erişebilirler. Yönetim ağında SSL/TLS kullanmak, bir saldırganın neden olabileceği zararı en aza indirebilir.

Ön taraftaki SSL/TLS vekili

Genel olarak, hassas veriyi olabildiğince erken şifrelemek ve olabildiğince geç şifresini çözmek en iyisidir. Bu en iyi uygulamaya rağmen, OpenStack servislerinin önünde bir SSL/TLS vekil kullanmanın ve daha sonra aşağıda gösterilen net iletişimin yaygın olduğu görünüyor:

../_images/secure-arch-ref-1.png

Yukarıda gösterildiği gibi SSL/TLS vekillerini kullanmakla ilgili endişelerden bazıları:

  • OpenStack servislerindeki yerli SSL/TLS, SSL vekilleri kadar iyi çalışmaz/ölçeklenmez (özellikle de Eventlet gibi Python uygulamaları için).

  • OpenStack hizmetlerindeki yerli SSL / TLS daha fazla kanıtlanmış çözümler kadar iyi incelenmedi/denetlenmedi.

  • Yerli SSL/TLS yapılandırması zordur (iyi belgelendirilmemiştir, test edilmemiştir, servisler arası tutarlı değildir).

  • Ayrıcalık ayrımı (OpenStack servis süreçleri, SSL/TLS için kullanılan özel anahtarlara doğrudan erişemez).

  • Yük dengeleme için trafik inceleme ihtiyaçları.

Yukarıdakilerin hepsi geçerli endişeler, ancak hiçbiri SSL/TLS’nin yönetim ağında kullanılmasını engellemez. Bir sonraki dağıtım modelini düşünelim.

API uç noktaları ile aynı fiziksel ana makinelerde SSL/TLS

../_images/secure-arch-ref-2.png

Bu, Ön taraftaki SSL/TLS vekili ile çok benzer, ancak SSL / TLS vekili API uç noktası ile aynı fiziksel sistemdedir. API bitiş noktası yalnızca yerel ağ arayüzünde dinlenecek şekilde yapılandırılacaktır. API uç noktasıyla olan tüm uzaktan iletişim, SSL/TLS vekilinden geçecektir. Bu dağıtım modeliyle, birkaç sayıdaki madde işareti noktasına değindik Ön taraftaki SSL/TLS vekili İyi performans gösteren kanıtlanmış bir SSL uygulaması kullanılacaktır. Tüm hizmetler için aynı SSL vekil yazılımı kullanılacaktır, bu nedenle API uç noktaları için SSL yapılandırması tutarlı olacaktır. SSL vekillerini farklı bir kullanıcı olarak çalıştırıp izinleri (ve ayrıca SELinux gibi bir şey kullanarak zorunlu erişim denetimlerini) kullanarak erişimi kısıtladığınız için OpenStack servis süreçleri, SSL/TLS için kullanılan özel anahtarlara doğrudan erişemezdi. İdeal olarak, API uç noktalarının bir Unix soketi üzerinde dinlenmesini sağlayacağız, böylece izinleri ve zorunlu erişim denetimlerini kullanarak erişimi sınırlandırabiliriz. Maalesef, bu, testlerimizde gördüğümüz kadarıyla şu anda Eventlet’te çalışmıyor. Bu, gelecekteki iyi bir geliştirme hedefidir.

yük dengeleyici üzerinden SSL/TLS

Trafiği kontrol etmeniz gereken yüksek kullanılabilirlik veya yük dengeli dağıtımlar ne olacak? Önceki dağıtım modeli (API uç noktaları ile aynı fiziksel ana makinelerde SSL/TLS) trafik şifrelendiği için derin iletişim paketi incelemesine izin vermez. Trafiğin temel yönlendirme amaçlarıyla incelenmesi gerekiyorsa, yük dengeleyicisinin şifrelenmemiş trafiğe erişmesi gerekli olmayabilir. HAProxy, el sıkışma sırasında SSL/TLS oturum kimliğini ayıklama yeteneğine sahiptir ve bu, daha sonra oturum yakınlığına erişmek için kullanılabilir (oturum ID yapılandırma ayrıntıları burada). HAProxy, trafiğin yönlendirileceği yeri belirlemek için TLS Sunucu Adı Gösterimi (SNI) uzantısını da kullanabilir (burada `SNI yapılandırma ayrıntıları <http://blog.exceliance.fr/2012/04/13/enhanced-ssl-load- server-name-indication-sni-tls-uzantısı /> `_ ile dengeleme). Bu özellikler muhtemelen en yaygın yük dengeleyici ihtiyaçlarını karşılar. HAProxy, bu durumda HTTPS trafiğini doğrudan API son nokta sistemlerine geçirebilir:

../_images/secure-arch-ref-3.png

Harici ve dahili ortamların kriptografik ayrımı

Harici ve dahili ortamlarınızı kriptografik olarak ayırmak isterseniz ne olur? Genel bir bulut sağlayıcısı, halka açık servisleri (veya vekilleri), SSL / TLS için popüler web tarayıcı yazılımında dağıtılan güvenilir bir Kök CA’ya kadar zincirlenen bir CA tarafından verilen sertifikaları kullanmak isteyebilir. Dahili servisler için bunun yerine kendi PKI’sini kullanarak SSL/TLS için sertifika vermek isteyebilirsiniz. Bu şifreleme ayrımı, SSL’yi ağ sınırında sonlandırıp, dahili olarak verilen sertifikaları kullanarak yeniden şifreleyerek başarılabilir. Trafik, kamuya bakan SSL/TLS vekilinin kısa bir süre için şifrelenmemiş olacak, ancak hiçbir zaman net bir şekilde ağ üzerinden iletilemez. Bir yük dengeleyici üzerinde derin paket incelemesine gerçekten ihtiyaç duyuluyorsa, kriptografik ayrımı yapmak için kullanılan aynı yeniden şifreleme yaklaşımı da kullanılabilir. İşte bu dağıtım modeli nasıl görünür:

../_images/secure-arch-ref-4.png

Çoğu şeyde olduğu gibi, bazı ödünler vardır. Temel ödün, güvenlik ve performans arasında olacak. Şifrelemenin bir maliyeti var, ancak saldırı da kesiliyor. Güvenlik ve performans gereksinimleri her dağıtım için farklı olacak, bu nedenle SSL/TLS nasıl kullanılır sonuçta bireysel bir karar olacaktır.