Sürekli sistem yönetimi¶
Bulutun her zaman hataları olacaktır. Bunlardan bazıları güvenlik sorunları olacaktır. Bu nedenle, güvenlik güncelleştirmelerini ve genel yazılım güncelleştirmelerini uygulamak için hazırlıklı olunması çok önemlidir. Bu, aşağıda tartışılan yapılandırma yönetimi araçlarının akıllıca kullanılmasını gerektirir. Bu aynı zamanda bir yükseltmenin ne zaman gerekli olduğunu bilmeyi de içerir.
Güvenlik açığı yönetimi¶
Güvenlikle ilgili değişikliklere ilişkin duyurular için, OpenStack Duyuru eposta listesi ne abone olun. Güvenlik bildirimleri ayrıca, paket güncellemelerinin bir parçası olarak abone olabileceğiniz Linux dağıtımı gibi, aşağı doğru paketler yoluyla da gönderilir.
OpenStack bileşenleri bir buluttaki yazılımın yalnızca küçük bir bölümüdür. Bu diğer bileşenlerle de güncel tutmak önemlidir. Bazı veri kaynakları dağıtıma özgü olmakla birlikte, bir bulut yöneticisinin, organizasyonun ortamına uygulanabilir tüm güvenlik güncelleştirmelerini bildirmek için gerekli posta listelerine abone olması önemlidir. Genellikle bu, bir akış yukarı Linux dağıtımını izlemek kadar basittir.
Not
OpenStack, güvenlik bilgilerini iki kanal üzerinden yayınlar.
OpenStack Güvenlik Açıklamaları (OSSA), OpenStack Güvenlik Açığı Yönetimi Ekibi (VMT) tarafından oluşturulmuştur. Bunlar çekirdek OpenStack servislerindeki güvenlik açıkları ile ilgilidir. VMT hakkında daha fazla bilgi Güvenlik Açığı Yönetimi Süreci nde bulunabilir.
OpenStack Security Notes (OSSN) are created by the OpenStack Security Group (OSSG) to support the work of the VMT. OSSN address issues in supporting software and common deployment configurations. They are referenced throughout this guide. Security Notes are archived at OSSN.
Aciliyetine göre sıralama¶
After you are notified of a security update, the next step is to determine how critical this update is to a given cloud deployment. In this case, it is useful to have a pre-defined policy. Existing vulnerability rating systems such as the common vulnerability scoring system (CVSS) do not properly account for cloud deployments.
Bu örnekte güvenlik açıklarını üç kategoriye yerleştiren bir puanlama matrisi sunuyoruz: İmtiyaz Artışı, Hizmet Reddi ve Bilginin Açığa Çıkması. Güvenlik açığının türünü ve altyapınızda nerede olduğunu anlamak, mantıklı tepki kararları vermenizi sağlayacaktır.
İmtiyaz Yükseltme, kullanıcının uygun yetkilendirme denetimlerini atlayarak bir sistemdeki bir başka kullanıcının ayrıcalıklarıyla hareket etme yeteneğini açıklar. Yönetici ayrıcalıklarıyla yetkisiz işlemleri yapmalarına izin veren bir işlemi gerçekleştiren bir konuk kullanıcı bu tür güvenlik açığının bir örneğidir.
Hizmet Reddi, hizmete veya sistemin bozulmasına neden olabilecek bir istismar güvenlik açığı anlamına gelir. Buna aşırı yüklü ağ kaynaklarına yönelik dağıtılmış saldırılar ve genellikle kaynak tahsisi hataları veya girişe bağlı sistem hatası kusurları nedeniyle oluşan tek kullanıcı saldırıları da dahildir.
Bilginin Açığa Çıkması güvenlik açıkları, sisteminiz veya işlemleriniz hakkında bilgi verir. Bu güvenlik açıkları, bilgi açıklığının hata ayıklamasından, kimlik doğrulama kimlik bilgileri ve parolalar gibi kritik güvenlik verilerinin ortaya çıkmasına kadar değişir.
Saldırgan konumu / Ayrıcalık seviyesi |
||||
|---|---|---|---|---|
Harici |
Bulut kullanıcısı |
Bulut yöneticisi |
Denetim Paneli |
|
Öncelik yükseltmesi (3 seviye) |
Kritik |
yok |
yok |
yok |
Imtiyaz yükselmesi (2 seviye) |
Kritik |
Kritik |
yok |
yok |
Imtiyaz yükselmesi (1 seviye) |
Kritik |
Kritik |
Kritik |
yok |
Hizmet reddi |
Yüksek |
Orta |
Düşük |
Düşük |
Bilgi ifşası |
Kritik / yüksek |
Kritik / yüksek |
Orta / düşük |
Düşük |
Bu tablo, güvenlik açığının dağıtımınızdaki yerini ve etkisini temel alan genel bir yaklaşım göstermektedir. Örneğin, Bir Hesaplama API düğümündeki tek düzey ayrıcalık artışı, API’nın standart bir kullanıcısının düğümdeki root kullanıcıyla aynı ayrıcalıklara sahip olmak üzere iletilmesini sağlar.
Bulut yöneticileri, çeşitli güvenlik düzeyleri için hangi eylemlerin gerçekleştirileceğini tanımlamanıza yardımcı olması için bu tabloyu bir model olarak kullanmanızı öneririz. Örneğin, kritik düzeyde bir güvenlik güncelleştirmesi, bulutun hızla yükseltilmesine ihtiyaç duyabilirken düşük seviyeli bir güncelleme tamamlanması daha uzun sürebilir.
Güncelleştirmeleri test etmek¶
Herhangi bir güncelleştirmeyi bir canlı ortama dağıtmadan önce test etmelisiniz. Genellikle bu, önce güncellemeyi alan ayrı bir test bulutu kurulumuna ihtiyaç duyar. Bu bulut, yazılım ve donanım bakımından olabildiğince canlı ortam bulutuna yakın olmalıdır. Güncellemeler, performans etkisi, istikrar, uygulama etkisi ve daha fazlası bakımından iyice test edilmelidir. Özellikle önemli olan, güncellemenin teorik olarak ele aldığı, belirli bir güvenlik açığı gibi problemin gerçekte giderildiğini doğrulamaktır.
Güncelleştirmeleri uygulamak¶
Güncellemeler tamamen test edildikten sonra, canlı ortama uygulanabilir. Bu işlem, aşağıda açıklanan yapılandırma yönetimi araçlarını kullanarak tamamen otomatikleştirilmelidir.
Yapılandırma yönetimi¶
Bir yayın kalitesindeki bulut her zaman yapılandırmayı ve kurulumu otomatikleştirmek için araçlar kullanmalıdır. Bu, insan hatasını ortadan kaldırır ve bulutun çok daha hızlı ölçeklenmesini sağlar. Otomasyon, sürekli entegrasyon ve test etme konusunda da yardımcı olur.
Bir OpenStack bulutu oluştururken tasarım ve uygulamanızın bir yapılandırma yönetimi aracı veya çerçevesi göz önünde bulundurulması önemle tavsiye edilir. Yapılandırma yönetimi, bir altyapıyı OpenStack kadar karmaşık hale getirmede, yönetmede ve korumada doğuran pek çok tuzaktan kaçınmanıza izin verir. Bir yapılandırma yönetimi yardımcı programı için gereken tezahürleri, hazırlık kitaplarını veya şablonları üreten bir dizi belge ve yasal raporlama gereksinimlerini yerine getirebilirsiniz. Ayrıca, yapılandırma yönetimi, iş akış süreci planında (BCP) ve veri kurtarma (DR) planlarının bir parçası olarak işlev görebilir ve burada bir düğümü veya hizmeti bir DR olayında bilinen bir duruma geri yükleyebilir veya bir açık vermeye sahipsiniz.
Buna ek olarak, Git veya SVN gibi bir sürüm kontrol sistemi ile birleştirildiğinde, zaman içinde ortamınızdaki değişiklikleri izleyebilir ve gerçekleşebilecek yetkisiz değişiklikleri bulabilirsiniz. Örneğin, nova.conf dosyası veya diğer yapılandırma dosyası standartlarınızla uyuşmazsa, yapılandırma yönetim aracınız dosyayı geri döndürebilir veya değiştirebilir ve yapılandırmanızı bilinen bir duruma getirebilirsiniz. Sonunda bir yapılandırma yönetimi aracı da güncellemeleri dağıtmak için kullanılabilir; güvenlik düzeltme eki işlemini basitleştirir. Bu araçların bu alanda kullanışlı geniş bir yetenek yelpazesi var. Bulutunuzu güvence altına almanın kilit noktası, yapılandırma yönetimi için bir araç seçmek ve kullanmaktır.
Birçok yapılandırma yönetimi çözümü vardır; Bu yazının yazıldığı tarihte, piyasada OpenStack ortamlarını destekleyen iki güçlü araç var: Puppet ve Puppet. Bu alandaki kapsamlı olmayan bir liste aşağıda sunulmuştur:
Chef
Puppet
Salt Stack
Ansible
İlke değişiklikleri¶
Bir politika veya yapılandırma yönetimi her değiştirildiğinde, etkinliği kaydetmek ve yeni grubun bir kopyasını yedeklemek iyi bir uygulamadır. Çoğu zaman, bu gibi ilkeler ve yapılandırmalar Git gibi sürüm kontrollü bir depoda depolanır.
Güvenli yedekleme ve kurtarma¶
It is important to include backup procedures and policies in the overall System Security Plan. For a good overview of OpenStack’s Backup and Recovery capabilities and procedures, refer to the OpenStack Operations Guide on backup and recovery.
Sadece doğrulanan kullanıcıların ve yedek istemcilerin yedekleme sunucusuna erişebildiğinden emin olun.
Yedeklerin depolanması ve aktarılması için veri şifreleme seçeneklerini kullanın.
Özel ve sıkılaştırılmış yedekleme sunucuları kullanın. Yedekleme sunucusu günlükleri günlük olarak izlenmelidir ve yalnızca birkaç kişi tarafından erişilebilir olmalıdır.
Veri kurtarma seçeneklerini düzenli olarak test edin. Güvenli yedeklemelerden geri yüklenebilecek şeylerden biri imajlardır. Bir taviz durumunda, en iyi uygulama, çalışan örnekleri hemen sonlandırmak ve ardından örnekleri güvenli yedekleme havuzundaki imajlarla tekrar başlatmak olacaktır.
Güvenlik denetim araçları¶
Güvenlik denetim araçları yapılandırma yönetim araçlarını tamamlayabilir. Güvenlik denetim araçları, belirli bir sistem yapılandırması için çok sayıda güvenlik denetiminin uygulanmasını doğrulama işlemini otomatikleştirir. Bu araçlar, güvenlik yapılandırma yönergeleri belgelerine (örneğin, STIG ve NSA Kılavuzları) olan boşluğu belirli bir sistem kurulumuna bağlamaya yardımcı olur. Örneğin, SCAP çalışan bir sistemi önceden tanımlanmış bir profille karşılaştırabilir. SCAP, profildeki hangi kontrollerin, hangilerinin başarısız olduğunu ve hangilerinin kontrol edilmediğini ayrıntılandıran bir rapor çıkarır.
Yapılandırma yönetimini ve güvenlik denetim araçlarını birleştirmek, güçlü bir kombinasyon oluşturur. Denetim araçları, dağıtım endişelerini vurgulayacaktır. Yapılandırma yönetimi araçları, denetim endişelerini gidermek için her bir sistemin değiştirilme sürecini basitleştirir. Bu araçlar birlikte kullanıldığında bu araçlar, temel güvenlik zorunluluğundan uygunluğun doğrulanmasına kadar değişen güvenlik gereksinimlerini karşılayan bir bulutun korunmasına yardımcı olur.
Yapılandırma yönetimi ve güvenlik denetim araçları, bulut içine başka bir karmaşıklık katmanı sunacak. Bu karmaşıklık, bununla birlikte ek güvenlik kaygıları getiriyor. Bunları, güvenlik avantajları göz önüne alındığında, kabul edilebilir bir risk dengelemesi olarak görüyoruz. Bu araçların operasyonel kullanımını sağlamak bu kılavuzun kapsamı dışındadır.
