Bütünlük yaşam döngüsü

Bütünlük ömrü döngüsünü, beklenen yazılımları bulut boyunca beklenen yapılandırmalarla her zaman çalıştırdığımızı garanti eden kasıtlı bir süreç olarak tanımlıyoruz. Bu işlem güvenli önyükleme ile başlar ve yapılandırma yönetimi ve güvenlik izlemesi ile korunur. Bu bölüm, bütünlük ömrü döngüsü sürecine nasıl yaklaşılabileceği konusunda öneriler sağlar.

Güvenli önyükleme

Buluttaki —hesaplama, depolama, ağ, servis ve karma düğümler dahil olmak üzere— düğümlerin otomatik bir hazırlık sürecine sahip olması gerekir. Bu, düğümlerin tutarlı ve doğru şekilde hazırlanmasını sağlar. Bu aynı zamanda güvenlik yamalama, yükseltme, hata düzeltme ve diğer kritik değişiklikleri kolaylaştırır. Bu işlem, bulutun en yüksek ayrıcalık düzeyinde çalışan yeni bir yazılım yüklediğinden, doğru yazılımın yüklü olduğunu doğrulamanız önemlidir. Bu, önyükleme işleminin en erken aşamalarını da içerir.

Bu erken önyükleme aşamalarını doğrulamayı sağlayan çeşitli teknolojiler vardır. Bunlar genellikle güvenilir platform modülü (TPM), Intel Güvenilir Yürütme Teknolojisi (TXT), güven ölçümünün dinamik kökü (DRTM) ve Birleşik Genişletilebilir Ürün Yazılımı Arabirimi (UEFI) güvenli önyükleme gibi bir donanım desteği gerektirir. Bu kitapta, bunların hepsini toplu olarak *güvenli önyükleme teknolojileri * olarak ele alacağız. Güvenli önyüklemeyi kullanmanızı öneririz, ancak bunu dağıtmak için gerekli olan birçok parçanın, araçları her ortam için özelleştirmek için gelişmiş teknik becerilere ihtiyaç duyduğunu kabul ediyoruz. Güvenli önyükleme kullanmak, bu kılavuzdaki diğer önerilerden çok daha derin entegrasyon ve özelleştirme gerektirir. TPM teknolojisi, birçok iş seviyesi dizüstü bilgisayarı ve masaüstünde birkaç yıldır ortak olsa da, artık destekleyen BIOS’la birlikte sunucularda da kullanılmaya başlandı. Başarılı bir güvenli önyükleme dağıtımı için doğru planlama şarttır.

Güvenli önyükleme dağıtımı hakkında eksiksiz bir kılavuz bu kitabın kapsamı dışındadır. Bunun yerine, burada, güvenli önyükleme teknolojilerini tipik düğüm hazırlama süreciyle nasıl bütünleştireceğinizin bir çerçevesi sunuyoruz. Ek ayrıntılar için, bulut mimarları ilgili özelliklere ve yazılım yapılandırma kılavuzlarına bakmalıdır.

Düğüm sağlamak

Düğümler, hazırlık için Önyükleme Öncesi Ortam (PXE) kullanmalıdır. Bu düğümleri yeniden dağıtmak için gereken çabayı önemli ölçüde azaltır. Tipik süreç, düğümün çeşitli önyükleme aşamalarını —aşamalı olarak çalıştırılması daha karmaşık bir yazılım olan— aldığı bir sunucudan yapılır.

Sağlama için yönetim güvenliği alanında ayrı bir izole edilmiş ağ kullanmanızı öneririz. Bu ağ, yukarıda tasvir edilen daha sonraki önyükleme aşaması yüklemeleri ile birlikte tüm PXE trafiğini işleyecektir. Düğüm önyükleme işleminin iki güvensiz işlemle başladığını unutmayın: DHCP ve TFTP. Daha sonra önyükleme işlemi, düğümü dağıtmak için gereken kalan bilgileri indirmek için TLS kullanır. Bu bir işletim sistemi yükleyicisi, Chef veya Puppet tarafından yönetilen temel bir kurulum veya doğrudan diske yazılan eksiksiz bir dosya sistemi imajı olabilir.

PXE önyükleme işlemi sırasında TLS’yi kullanmanın biraz zor olduğu halde, iPXE gibi yaygın PXE ürün yazılımı projeleri bu desteği sağlar. Tipik olarak, bu, sunucu sertifikasını düzgün şekilde doğrulayabilmesi için izin verilen TLS sertifika zincir(ler)inin bilgisi olan PXE bellenimini oluşturmayı içerir. Bu, güvensiz, düz metin ağ operasyonlarının sayısını sınırlandırarak bir saldırganın barını yükseltir.

Doğrulanmış önyükleme

Genel olarak, önyükleme işlemini doğrulamak için iki farklı strateji vardır. Geleneksel güvenli önyükleme, işlemin her adımında çalıştırılan kodu doğrulayacak ve kod doğru değilse önyüklemeyi durduracaktır. Önyükleme doğrulaması hangi adımda hangi kodun çalıştırılacağını kaydeder ve bu bilgileri önyükleme işleminin beklendiği gibi tamamlandığının kanıtı olarak başka bir makineye sunar. Her iki durumda da, ilk adım, çalıştırılmadan önce her bir kod parçasını ölçmektir. Bu bağlamda, bir ölçüm, yürürlüğe girmeden önce alınan kodun etkili bir SHA-1 özetidir. Özet, TPM’de bir platform yapılandırma kaydı (PCR) içinde saklanır.

Not

SHA-1 burada kullanılır, çünkü TPM çipleri bunu destekliyor.

Her bir TPM’nin en az 24 PCR’si vardır. TCG Jenerik Sunucu Tanımlaması, v1.0, Mart 2005, önyükleme zamanı bütünlük ölçümleri için PCR atamalarını tanımlar. Aşağıdaki tabloda tipik bir PCR yapılandırması gösterilmektedir. Bağlam, değerlerin düğüm donanımına (ürün yazılımı) veya düğüme sağlanan yazılıma bağlı olarak belirlenip işaret edilmediğini gösterir. Bazı değerler, bellenim sürümlerine, disk boyutlarına ve diğer düşük seviyeli bilgilere göre değişir. Bu nedenle, konuşlandırılan her sistemin tam olarak istediğiniz şekilde yapılandırıldığından emin olmak için yapılandırma yönetimi etrafında iyi uygulamalara sahip olmak önemlidir.

Kayıt	Ne ölçülür	Bağlam
PCR-00	Güven Ölçümünün Çekirdek Kökü (CRTM), BIOS kodu, Sunucu platformu uzantıları	Donanım
PCR-01	Sunucu platformu yapılandırması	Donanım
PCR-02	Seçenek ROM kodu	Donanım
PCR-03	Seçenek ROM yaplandırma ve veri	Donanım
PCR-04	İlk Program Yükleyici (IPL) kodu. Örneğin, ana önyükleme kaydı.	Yazılım
PCR-05	IPL kod yapılandırma ve veri	Yazılım
PCR-06	Durum geçişi ve olayları uyandırmak	Yazılım
PCR-07	Sunucu platformu üreticisi kontrolü	Yazılım
PCR-08	Platforma özgü, genellikle çekirdek, çekirdek uzantıları ve sürücüler	Yazılım
PCR-09	Platforma özgü, genellikle Initramfs	Yazılım
PCR-10’dan PCR-23’a	Platforma özgü	Yazılım

Secure boot may be an option for building your cloud, but requires careful planning in terms of hardware selection. For example, ensure that you have a TPM and Intel TXT support. Then verify how the node hardware vendor populates the PCR values. For example, which values will be available for validation. Typically the PCR values listed under the software context in the table above are the ones that a cloud architect has direct control over. But even these may change as the software in the cloud is upgraded. Configuration management should be linked into the PCR policy engine to ensure that the validation is always up to date.

Her üreticinin sunucuları için BIOS ve üretici yazılımı kodunu sağlamaları gerekir. Farklı sunucular, denetleyiciler ve işletim sistemleri farklı PCR’leri yerleştirmeyi seçecektir. Çoğu gerçek dünya dağıtımında, her PCR’yi bilinen iyi bir miktara (“altın ölçüm”) karşı doğrulamak olanaksızdır. Deneyimler, tek bir satıcının ürün hattında bile belirli bir PCR için ölçüm sürecinin tutarlı olmayabileceğini göstermiştir. Her sunucu için bir taban çizgisi oluşturmanızı ve beklenmedik değişiklikler için PCR değerlerini izlemenizi öneririz. Seçtiğiniz hypervisor çözümüne bağlı olarak, TPM hazırlama ve izleme sürecine yardımcı olmak için üçüncü parti yazılımlar mevcut olabilir.

Yukarıda açıklanan düğüm dağıtım stratejisi varsayılarak, ilk program yükleyici (IPL) kodu büyük olasılıkla PXE yazılımı olacaktır. Bu nedenle, güvenli önyükleme veya önyükleme onaylama işlemi, BIOS, üretici yazılımı, PXE yazılımı ve çekirdek görüntüsü gibi tüm erken aşama önyükleme kodunu ölçebilir. Her bir düğümün, bu parçaların doğru sürümlerini yüklediğinden emin olun, kalan düğüm yazılım yığını oluşturmak için sağlam bir temel oluşturur.

Seçilen stratejiye bağlı olarak, bir arıza durumunda, düğüm önyükleme başarısız olur veya başarısızlığı buluttaki başka bir öğeye tekrar rapor edebilir. Güvenli önyükleme için düğüm önyükleme başarısız olur ve yönetim güvenlik alanı içindeki bir sağlama hizmeti bunu tanır ve olayı günlüğe kaydetmelidir. Önyükleme doğrulaması için, hata tespit edildiğinde düğüm zaten çalışıyor demektir. Bu durumda, düğüm, ağ erişimini devre dışı bırakarak derhal karantinaya alınmalıdır. O zaman olay, kök sebep için analiz edilmelidir. Her iki durumda da, politika bir başarısızlıktan sonra ne şekilde ilerleyeceklerini belirlemelidir. Bir bulut otomatik olarak bir düğüme belirli sayıda tekrar sağlanmaya çalışabilir. Veya problemi araştırması için hemen bir bulut yöneticisine bilgi verebilir. Burada doğru politika, dağıtım ve hata modu özel olacaktır.

Düğüm sıkılaştırma

Bu noktada, düğümün doğru çekirdek ve alttaki bileşenlerle önyüklendiğini biliyoruz. Bir sonraki adım, işletim sistemini sıkılaştırmaktır ve sektörde kabul görmüş bir dizi sıkılaştırma denetimi ile başlar. Aşağıdaki kılavuzlar iyi örneklerdir:

Güvenlik Teknik Uygulama Kılavuzu (STIG)

Savunma Bilişim Sistemleri Kurumu (DISA) (Birleşik Devletler Savunma Bakanlığı’nın bir bölümü), çeşitli işletim sistemleri, uygulamalar ve donanımlar için STIG içeriği yayınlamaktadır. Kontroller herhangi bir lisans olmadan yayınlanır.

İnternet Güvenliği Merkezi (CIS) Testleri

CIS düzenli olarak bu güvenlik denetimlerini otomatik olarak uygulayan güvenlik ölçütlerini ve otomatik araçları yayınlar. Bu kıyaslamalar, bazı sınırlamaları olan bir Creative Commons lisansı altında yayınlanmaktadır.

Bu güvenlik kontrolleri en iyi otomatik yöntemlerle uygulanır. Otomasyon, her sistem için denetimlerin her seferinde aynı şekilde uygulanmasını sağlar ve mevcut bir sistemi denetlemek için hızlı bir yöntem de sağlar. Otomasyon için birden fazla seçenek vardır:

OpenSCAP

OpenSCAP, SCAP içeriğini (güvenlik denetimlerini açıklayan XML dosyaları) alan ve bu içeriği çeşitli sistemlere uygulayan açık kaynaklı bir araçtır. Mevcut mevcut içeriğin çoğu bugün Red Hat Enterprise Linux ve CentOS içindir, ancak araçlar herhangi bir Linux veya Windows sistemlerinde çalışmaktadır.

ansible-hardening

Ansible-hardening projesi, güvenlik kontrollerini geniş bir Linux işletim sistem dizisi için geçerli bir Ansible rolü sağlar. Mevcut bir sistemi denetlemek için de kullanılabilir. Her bir kontrol, bir üretim sistemine zarar verip vermeyeceğini belirlemek için dikkatlice gözden geçirilir. Kontroller, Red Hat Enterprise Linux 7 STIG’a dayanıyor.

Bir sistemi tamamen sıkılaştırmak zor bir süreçtir ve bazı sistemlerde büyük miktarda değişiklikler gerektirebilir. Bu değişikliklerden bazıları üretim iş yüklerini etkileyebilir. Bir sistem tam olarak sıkılaştırılamıyorsa, büyük bozulmalara gerek duymadan güvenliği artırmak için aşağıdaki iki değişiklik önerilir:

Zorunlu Erişim Kontrolü (MAC)

Zorunlu erişim denetimleri, root dahil sistemler üzerindeki tüm kullanıcıları etkiler ve etkinliği mevcut güvenlik ilkesine göre gözden geçirmek çekirdeğin görevi olur. Etkinlik izin verilen politikanın içinde değilse, root kullanıcısı için bile engellenir. Daha fazla ayrıntı için aşağıdaki sVirt, SELinux ve AppArmor tartışmalarını inceleyin.

Paketleri kaldırın ve servisleri durdurun

Sistemin mümkün olan en az sayıda paket yüklenmiş olduğundan ve servislerin çalışıp çalışmadığından emin olun. Gereksiz paketleri kaldırmak, yamayı kolaylaştırır ve sistemdeki ihlal oluşturabilecek öğe sayısını azaltır. Gereksiz servislerin durdurulması, sistemdeki saldırı yüzeyini küçültür ve saldırmak daha zor hale gelir.

Canlı ortam düğümleri için aşağıdaki ek adımları da öneriyoruz:

Salt okunur dosya sistemi

Mümkün olduğunda salt okunur bir dosya sistemi kullanın. Yazılabilir dosya sistemlerinin çalıştırmaya izin vermediğinden emin olun. Bu, /etc/fstab de noexec, nosuid ve nodev mount seçenekleriyle işlenebilir.

Sistem doğrulama

Son olarak, düğüm çekirdeğinin, düğümün geri kalanının bilinen iyi durumda başladığını doğrulamak için bir mekanizması olmalıdır. Bu, tüm sistemi doğrulamak için önyükleme doğrulama işleminden gerekli bağlantıyı sağlar. Bunu yapmanın adımları dağıtıma özgü olacaktır. Örnek olarak, bir çekirdek modülü dm-verity kullanılarak dosya sistemini oluşturan bloklar üzerinde bir özeti doğrulayabilir.

Çalışma zamanı doğrulama

Düğüm çalışmaya başladıktan sonra, zamanla iyi durumda kalmasını sağlamalıyız. Genel olarak, bu hem yapılandırma yönetimi hem de güvenlik izleme içerir. Bu alanların her birinin hedefleri farklıdır. Her ikisini de kontrol ederek, sistemin istenen şekilde çalıştığını daha yüksek güvence altına alıyoruz. Yapılandırma yönetimini yönetim bölümünde ve güvenlik izlemeyi aşağıda tartışırız.

Saldırı tespit sistemi

Sunucu tabanlı saldırı tespit araçları, bulut içlerinin otomatik olarak doğrulanması için de yararlıdır. Çok çeşitli barındırma tabanlı saldırı tespit aletleri mevcuttur. Bazıları serbestçe temin edilebilen, diğerleri ise ticari olan açık kaynaklı projelerdir. Genellikle bu araçlar, çeşitli kaynaklardan gelen verileri analiz eder ve kural setleri ve/veya eğitim temelinde güvenlik uyarıları üretir. Tipik yetenekler arasında günlük analizi, dosya bütünlüğü denetimi, ilke izleme ve kök dizin algılama bulunur. Daha gelişmiş – çoğunlukla özel araçlar –, bellek içi işlem görüntülerinin disk üzerindeki çalıştırılabilirle eşleştiğini doğrulayabilir ve çalışan bir işlemin yürütme durumunu doğrulayabilir.

Bir bulut mimarına yönelik kritik bir ilke kararı, bir güvenlik izleme aracının çıktısıyla ne yapılacağıdır. Etkili olarak iki seçenek vardır. Birincisi, bir insanı araştırmak ve/veya düzeltici önlem almak için uyarmaktır. Bu, güvenlik alarmını bulut yöneticileri için bir günlük veya etkinlikler akışına dahil ederek yapılabilir. İkinci seçenek, bulutun olayı günlüğe eklemenin yanı sıra otomatik olarak iyileştirici bir işlem yapmasını sağlamaktır. Telafi edici eylemler, bir düğümün yeniden kurulmasından küçük servis yapılandırmasını gerçekleştirmeye kadar her şeyi içerebilir. Bununla birlikte, yanlış düzeltme olasılığı nedeniyle otomatik telafi işlemi zor olabilir.

Yanlış pozitiflikler, güvenlik izleme aracı iyi huylu bir olay için bir güvenlik alarmı ürettiğinde ortaya çıkar. Güvenlik izleme araçlarının doğası gereği yanlış pozitiflikler kesinlikle zaman zaman ortaya çıkacaktır. Tipik olarak bir bulut yöneticisi, yanlış pozitiflikleri azaltmak için güvenlik izleme araçlarını ayarlayabilir, ancak aynı zamanda genel algılama oranını da düşürebilir. Bulutta bir güvenlik izleme sistemi kurarken bu klasik dengeler anlaşılmalı ve açıklanmalıdır.

Bir sunucu tabanlı saldırı tespit aletinin seçimi ve yapılandırması son derece kuruluma özgüdür. Başlangıçta, çeşitli sunucu tabanlı saldırı tespit ve dosya izleme özelliklerini uygulayan aşağıdaki açık kaynak projelerini incelemenizi öneriyoruz.

• OSSEC

• Samhain

• Tripwire

• AIDE

Ağ saldırı tespit araçları, sunucu tabanlı araçları tamamlar. OpenStack’in dahili olarak belirli bir IDS yapısı yoktur, ancak OpenStack Ağ, Ağ API’si aracılığıyla farklı teknolojileri etkinleştirmek için eklenti bir mekanizma sağlar. Bu eklenti mimarisi, kiracılar için bir güvenlik duvarı, saldırı tespit sistemi veya VM’ler arasında bir VPN gibi kendi gelişmiş ağ servislerini yerleştirmek ve yapılandırmak için API uzantıları geliştirmelerine izin verecek.

Sunucu tabanlı araçlara benzer şekilde, bir ağa dayalı hırsızsızlık algılama aracının seçimi ve yapılandırması dağıtıma özgüdür. Snort, lider açık kaynaklı ağ saldırı tespit aracıdır ve daha fazla bilgi edinmek için iyi bir başlangıç noktasıdır.

Ağ ve sunucu tabanlı saldırı tespit sistemleri için birkaç önemli güvenlik önlemi vardır.

• Network IDS’in bulut üzerinde yerleştirilmesini göz önünde bulundurmak önemlidir (örneğin, ağ sınırına ve / veya hassas ağların çevresine eklenmesi). Yerleşim, ağ ortamınıza bağlıdır, ancak nerede eklemek istediğinize bağlı olarak IDS’nin servisleriniz üzerindeki etkisini izlediğinizden emin olun. TLS gibi şifreli trafik, genel olarak bir Ağ Kimliği tarafından içeriğe denetlenemez. Bununla birlikte, Network IDS, ağdaki anormal şifrelenmemiş trafiği tanımlamada yine de bir miktar fayda sağlayabilir.

• Bazı dağıtımlarda, güvenlik etki köprüleri üzerindeki hassas bileşenlere sunucu tabanlı IDS eklenmesi gerekebilir. Bir sunucu tabanlı IDS, bileşendeki tehlikeye veya yetkisiz işlemler yoluyla anormal bir etkinlik tespit edebilir. IDS, Yönetim ağı üzerinde uyarı ve günlük bilgisi göndermelidir.

Sunucu sıkılaştırma

Asgari bulut ve aşırı bulut altyapı da dahil olmak üzere buluttaki sunucular, en iyi yöntemlerle sıkılaştırmalıdır. İS ve sunucu sıkılaştırması yaygın olduğundan, günlüğe kaydetme, kullanıcı hesabı kısıtlamaları ve düzenli güncellemeler ile sınırlı olmaksızın geçerli en iyi yöntemler burada ele alınmayacak, ancak tüm altyapılara uygulanmalıdır.

Dosya bütünlüğü yönetimi (FIM)

Dosya bütünlüğü yönetimi (FIM), hassas sistem veya uygulama yapılandırma dosyaları gibi dosyaların bozulmaması veya yetkisiz erişime veya kötü amaçlı davranışa izin vermek üzere değiştirilmemesine ilişkin yöntemdir. Bu, belirtilen kaynağın bir sağlama toplamı özeti yaratacak ve ardından düzenli aralıklarla bu özeti doğrulamak üzere Samhain gibi bir yardımcı program aracılığıyla gerçekleştirilebilir veya DMVerity gibi bir blok aygıtların özeti alabilen ve bu özetleri geçerli olarak doğrulayacak bir araçla kullanıcıya sunulmadan önce sistem tarafından erişilir.

Bunlar, sistem, hipervizör, /etc/pam.d/system-auth, /etc/keystone/keystone.conf ve çekirdek modülleri (virtio gibi) gibi uygulama yapılandırma dosyalarındaki değişiklikleri izlemek ve raporlamak için uygulanmalıdır. En iyi uygulama, lsmod komutunu kullanarak FIM kontrollerine dahil edilmesinin veya verilmemesi gerektiğini belirlemenize yardımcı olması için düzenli olarak bir sistemde yüklü olanı göstermektir.