Örnekler için güvenlik servisleri¶

Örneklere entropi¶

Entropi, bir örnek için mevcut rastgele verilerin kalitesine ve kaynağına atıfta bulunmayı düşünüyoruz. Şifreleme teknolojileri genellikle rastgeleğe dayanır; bunun sonucunda yüksek kaliteli bir entropi havuzu oluşturulur. Sanal makinenin, entropi açlığı olarak adlandırılan bu işlemleri desteklemek için yeterli entropi elde etmesi genellikle zor. Entropi açlığı görünüşte ilgisiz bir şey olarak ortaya çıkabilir. Örneğin, yavaş önyükleme zamanı, ssh anahtarının oluşturulmasını bekleyen örneğe bağlı olabilir. Entropi açlığı, kullanıcıları, örnek içindeki kalitesiz entropi kaynaklarını kullanmaya yönlendirerek, genel olarak uygulamaları bulutta daha az güvende kılıyor.

Neyse ki, bir bulut mimarı bulut örneklerine yüksek kaliteli bir entropi kaynağı sağlayarak bu sorunları çözebilir. Bu, örnekleri desteklemek için bulutta yeterli donanım rastgele sayı üreticileri (HRNG) bulundurarak yapılabilir. Bu durumda, “yeterli” alanı belirli bir alana özgüdür. Günlük operasyonlar için, modern bir HRNG’nin 50-100 hesaplama düğümünü destekleyecek yeterli entropi üretmesi muhtemeldir. Intel Ivy Bridge ve daha yeni işlemcilerle kullanılabilen RdRand yönergesi gibi yüksek bant genişliğili HRNG’ler potansiyel olarak daha fazla düğüm işleyebilir. Belirli bir bulut için, bir mimar yeterli entropinin mevcut olduğundan emin olmak için uygulama gereksinimlerini anlamalıdır.

Virtio RNG, varsayılan olarak entropinin kaynağı olarak /dev/random kullanan rasgele sayı üreteci olmasına rağmen, bir donanım RNG veya entropi toplama daemonu gibi bir araç (‘EGD <http: //egd.sourceforge.net>`_), entropiyi dağıtılmış bir sistem yoluyla adil ve güvenli bir şekilde dağıtmanın bir yolunu sunmak için yapılandırılabilir. Virtio RNG, örneği oluşturmak için kullanılan metaverilerin hw_rng özelliği kullanılarak etkinleştirilir.

Örnekleri düğümlere planlamak¶

Bir örnek oluşturulmadan önce, imaj oluşturulması için bir ana makine seçilmelidir. Bu seçim, hesaplama ve hacim isteklerinin nasıl gönderileceğini belirleyen nova-scheduler tarafından gerçekleştirilir.

The FilterScheduler is the default scheduler for OpenStack Compute, although other schedulers exist (see the section Scheduling in the OpenStack Configuration Reference ). This works in collaboration with ‘filter hints’ to decide where an instance should be started. This process of host selection allows administrators to fulfill many different security and compliance requirements. Depending on the cloud deployment type for example, one could choose to have tenant instances reside on the same hosts whenever possible if data isolation was a primary concern. Conversely one could attempt to have instances for a tenant reside on as many different hosts as possible for availability or fault tolerance reasons.

Zamanlayıcıları filtreleme dört ana kategoride toplanır:

Kaynak tabanlı filtreler: Bu filtreler, hipervizör ana bilgisayar kümelerinin kullanımına dayalı bir örnek oluşturur ve durduk yere veya RAM, GÇ veya CPU kullanımı gibi özellikleri tetikleyebilir.
İmaj tabanlı filtreler: Bu, örnek oluşturmayı, VM’nin işletim sistemi ya da hangi tür imaj kullanıldığı gibi imaj özelliklerine devreder.
Ortam tabanlı filtreler: Bu filtre, belirli bir IP aralığında, kullanılabilirlik bölgeleri arasında veya başka bir örnekle aynı ana bilgisayardaki gibi harici ayrıntılara dayalı bir örnek oluşturacaktır.
Özel kriter: Bu filtre, kullanıcı veya yönetici tarafından güven veya metaveri ayrıştırması gibi ölçütlere dayalı olarak örnek oluşturma yetkisi verir.

Bir örneği belirli bir sunucu grubunun bir üyesinde oluşturulmasını sağlamak için ServerGroupAffinity süzgeci ve aynı örneği başka bir spesifik bir grupta yaratılmamasını sağlamak için ServerGroupAntiAffinity süzgeci gibi birden fazla filtre aynı anda uygulanabilir. Bu filtreler birbirleriyle çakışmamalarını ve örneklerin oluşturulmasını engelleyen kurallarla sonuçlanmasını sağlamak için dikkatli bir şekilde analiz edilmelidir.

GroupAffinity ve GroupAntiAffinity filtreleri çakışır ve her ikisinde de aynı anda etkin olmamalıdır.

DiskFilter süzgeci, disk alanını aşırı abone etme yeteneğine sahiptir. Normalde bir sorun olmamakla birlikte, bu ince ayarlanmış depolama aygıtları için bir endişe kaynağı olabilir ve bu filtre, iyi uygulanmış kotalarla birlikte kullanılmalıdır.

Kullanıcıların sağladığı veya metaveri gibi manipüle edilebilen şeyleri ayrıştıran filtreleri devre dışı bırakmanızı öneririz.

Güvenilen imajlar¶

Bulut ortamında, kullanıcılar önceden yüklenmiş imajlarla veya kendilerinin yüklediği imajlarla çalışır. Her iki durumda da, kullanıcılar kullandıkları imajın bozulmadığından emin olmalıdır. İmajların doğrulama özelliği, güvenlik için temel bir zorunluluktur. İmajın kaynağından kullanıldığı yere bir güven zincirine ihtiyaç vardır. Bu, güvenilir kaynaklardan elde edilen imzalayarak ve imza kullanımdan önce doğrulanarak gerçekleştirilebilir. Doğrulanmış imajlar elde etmek ve oluşturmak için çeşitli yollar aşağıda izah edilecek ve ardından görüntü imza doğrulama özelliğinin bir açıklaması gelecektir.

İmaj oluşturma süreci¶

OpenStack Belgelendirmesi, İmaj servisine bir imajın nasıl oluşturulacağı ve yükleneceği konusunda rehberlik eder. Buna ek olarak, işletim sistemlerini yüklemek ve sıkılaştırmak için bir işleminiz olduğunu varsaymaktadır. Bu nedenle, aşağıdaki öğeler, imajlarınızın OpenStack’e güvenli bir şekilde nasıl aktarılmasını sağlayacak ek rehberlik sağlayacaktır. İmaj elde etmek için çeşitli seçenekler bulunmaktadır. Her birinin, imajın kimliğini doğrulamaya yardımcı olan belirli adımları vardır.

İlk seçenek güvenilir bir kaynaktan önyükleme medyası almaktır.

$ mkdir -p /tmp/download_directorycd /tmp/download_directory
$ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/ubuntu-12.04.2-server-amd64.iso
$ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS
$ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS.gpg
$ gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451
$ gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2>&1 | grep OK

İkinci seçenek, `OpenStack Sanal Makine İmaj Rehberi'ni (https://docs.openstack.org/image-guide/)`_ kullanmaktır. Bu durumda organizasyonlarınızın OS sıkılaştırma yönergelerini veya `Linux STIGs <http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx`_ gibi güvenilir bir üçüncü taraf tarafından sağlanan yönergeleri izlemek isteyeceksiniz.

Son seçenek, otomatik bir imaj oluşturucu kullanmaktır. Aşağıdaki örnek Oz imaj oluşturucuyu kullanmaktadır. OpenStack topluluğu son zamanlarda araştırmaya değer yeni bir araç yarattı: disk-image-builder. Bu aracı güvenlik açısından değerlendirmedik.

OZ’da NIST 800-53 Bölüm AC-19(d) ‘nin uygulanmasına yardımcı olacak RHEL 6 CCE-26976-1 örneği.

<template>
<name>centos64</name>
<os>
  <name>RHEL-6</name>
  <version>4</version>
  <arch>x86_64</arch>
  <install type='iso'>
  <iso>http://trusted_local_iso_mirror/isos/x86_64/RHEL-6.4-x86_64-bin-DVD1.iso</iso>
  </install>
  <rootpw>CHANGE THIS TO YOUR ROOT PASSWORD</rootpw>
</os>
<description>RHEL 6.4 x86_64</description>
<repositories>
  <repository name='epel-6'>
  <url>http://download.fedoraproject.org/pub/epel/6/$basearch</url>
  <signed>no</signed>
  </repository>
</repositories>
<packages>
  <package name='epel-release'/>
  <package name='cloud-utils'/>
  <package name='cloud-init'/>
</packages>
<commands>
  <command name='update'>
  yum update
  yum clean all
  rm -rf /var/log/yum
  sed -i '/^HWADDR/d' /etc/sysconfig/network-scripts/ifcfg-eth0
  echo -n > /etc/udev/rules.d/70-persistent-net.rules
  echo -n > /lib/udev/rules.d/75-persistent-net-generator.rules
  chkconfig --level 0123456 autofs off
  service autofs stop
  </command>
</commands>
</template>

Elle imaj oluşturma işleminin karmaşık olması ve hataya eğilimli olması nedeniyle önlenmesi önerilir. Ek olarak, görüntü oluşturma için Oz gibi otomatik bir sistem veya açılış sonrası imaj sıkılaştırması için Chef veya Puppet gibi bir yapılandırma yönetimi programı kullanarak, tutarlı bir imaj üretmenin yanı sıra, taban görüntüsünün kendi sıkılaştırma kurallarına uyumunu izleyebilirsiniz.

Bir genel bulut hizmetine abone oluyorsanız, varsayılan görüntülerini üretmek için kullanılan işlemin ana hatlarını bulmak için bulut sağlayıcısına danışmalısınız. Sağlayıcı kendi imajlarınızı yüklemenizi sağlarsa, imajınızın bir örneğini oluşturmak için kullanmadan önce değiştirilmediğini doğrulayabildiğinizden emin olmasını isteyeceksiniz. Bunu yapmak için imaj İmzalama Doğrulama hakkında aşağıdaki bölüme veya imzalar kullanılamıyorsa aşağıdaki paragrafa bakın.

İmajlar, imaj servisinden bir düğümdeki Hesaplama servisine gelir. Bu aktarım, TLS üzerinden çalıştırılarak korunmalıdır. İmaj düğümde olduğunda, temel bir sağlama toplamı ile doğrulanır ve ardından diski başlatılacak örnek boyutuna dayalı olarak genişletilir. Daha sonra, aynı görüntü bu düğümde aynı örnek boyutu ile başlatılırsa, aynı genişletilmiş imajdan başlatılır. Bu genişletilmiş imaj başlatılmadan önce varsayılan olarak yeniden doğrulanmadığından, kurcalamaya maruz kalması mümkündür. Elde edilen imajda dosyaların elle incelenmesi yapılmadığı sürece, kullanıcı kurcalamanın farkında değildir.

İmaj imza doğrulama¶

İmaj imzalama ile ilgili birçok özellik artık OpenStack’da mevcuttur. Mitaka sürümünden itibaren İmaj servisi imzalanmış imajları doğrulayabilir ve tam bir güven zinciri sağlamak için Hesaplama servisi imaj önyüklemeden önce imza doğrulamasını gerçekleştirme seçeneğine sahiptir. İmaj önyüklemeden önce imzanın geçerliliği başarılı bir şekilde imzalanmış imajın değişmediğinden emin olabilirsiniz. Bu özellik etkinleştirildiğinde, imajların yetkisiz olarak değiştirilmesi (ör. Kötü amaçlı yazılım veya rootkit’leri içerecek şekilde görüntüyü değiştirme) tespit edilebilir.

Administrators can enable instance signature verification by setting the verify_glance_signatures flag to True in the /etc/nova/nova.conf file. When enabled, the Compute service automatically validates the signed instance when it is retrieved from the Image service. If this verification fails, the boot won’t occur. The OpenStack Operations Guide provides guidance on how to create and upload a signed image, and how to use this feature. For more information, see Adding Signed Images in the Operations Guide.

Örnek göçleri¶

OpenStack ve altta yatan sanallaştırma katmanları, OpenStack düğümleri arasında imajların canlı olarak taşınmasını sağlar ve böylece OpenStack hesaplama düğümlerinizi kesintisiz olarak sorunsuz bir şekilde güncelleyebilirsiniz. Bununla birlikte, canlı göçler de önemli risk taşıyor. İlgili riskleri anlamak için, canlı geçiş sırasında gerçekleştirilen üst düzey adımlar şunlardır:

Hedef sunucuda örneği başlatmak
Bellek aktarımı
Misafiri durdurmak ve diskleri senkronize etmek
Aktarım durumu
Misafiri başlatmak

Canlı göç riskleri¶

Canlı geçiş sürecinin çeşitli aşamalarında örneklerin içeriği çalışma zamanı belleği ve disk ağ üzerinden düz metin halinde iletilir. Dolayısıyla canlı göç kullanıldığında ele alınması gereken çeşitli riskler vardır. Aşağıdaki ayrıntılı liste, bu risklerden bazılarını ayrıntılarıyla açıklamaktadır:

Hizmet Reddi (DoS): Taşıma işlemi sırasında bir şey başarısız olursa, örnek kaybolabilir.
Veri maruziyeti: Bellek veya disk aktarmaları güvenli bir şekilde ele alınmalıdır.
Data manipulation: If memory or disk transfers are not handled securely, then an attacker could manipulate user data during the migration.
Code injection: If memory or disk transfers are not handled securely, then an attacker could manipulate executables, either on disk or in memory, during the migration.

Canlı göç sınırlamaları¶

Canlı göçlerle ilişkili bazı riskleri hafifletmek için birkaç yöntem vardır, aşağıdaki liste bazılarının ayrıntılarını vermektedir:

Canlı göçü kapatmak
İzole göç ağı
Şifreli canlı göç

Canlı göçü kapatmak¶

Şu anda, canlı göç, varsayılan olarak OpenStack’da etkinleştirilmiştir. Canlı göç işlemleri, nova policy.json dosyasına aşağıdaki satırları ekleyerek devre dışı bırakılabilir:

{
    "compute_extension:admin_actions:migrate": "!",
    "compute_extension:admin_actions:migrateLive": "!",
}

Göç ağı¶

Genel bir uygulama olarak, canlı göç trafiği, yönetim güvenliği alanıyla sınırlanmalıdır, bkz. Güvenlik sınırları ve tehditler. Düz metin niteliğinden ve çalışan bir örneğin disk ve bellek içeriğini aktardığından canlı geçiş trafiği ile canlı geçiş trafiğini ayrılmış bir ağa daha da ayırmanız önerilir. Trafiği özel bir ağa ayırabilmek maruz kalma riskini azaltabilir.

Şifreli canlı göç¶

Canlı geçiş’i etkinleştirmek için yeterli bir iş durumu olursa, libvirtd canlı geçişler için şifrelenmiş tüneller sağlayabilir. Bununla birlikte, bu özellik şu anda hem OpenStack Panel’de hem de nova-client komutlarında bulunmamaktadır ve yalnızca libvirtd’in manuel yapılandırması aracılığıyla erişilebilir. Daha sonra canlı geçiş işlemi aşağıdaki üst düzey adımlara geçer:

Örnek verileri, hipervizör’den libvirtd’ye kopyalanır.
Hem kaynak hem de hedef bilgisayarlarda libvirtd işlemleri arasında şifrelenmiş bir tünel oluşturulur.
Hedef libvirtd sunucu, örnekleri alttaki bir hipervizör’e geri kopyalar.

İzleme, uyarı ve raporlama¶

Bir OpenStack sanal makinesi ana makinelerde çoğaltılabilen bir sunucu imajı olduğundan, günlükte en iyi uygulama fiziksel ve sanal ana makineler arasında benzer şekilde geçerlidir. Ana makinelere ve verilere erişim olayları, kullanıcı eklemeleri ve kaldırma işlemleri, ayrıcalık değişiklikleri ve çevre tarafından belirlenen diğer olaylar da dahil olmak üzere, işletim sistemi düzeyinde ve uygulama düzeyindeki olaylar günlüğe kaydedilmelidir. İdeal olarak, bu günlükleri, günlük olaylarını toplayan, bunları analiz için ilişkilendiren ve referans veya daha ileri eylemler için depolayan bir günlük toplayıcıya dışa aktaracak şekilde yapılandırabilirsiniz. Bunu yapmak için kullanılan ortak bir araç, bir ELK yığını veya Elasticsearch, Logstash ve Kibana’dir.

Bu günlükler, bir ağ operasyon merkezi (NOC) tarafından canlı bir görünüm gibi düzenli bir kademede gözden geçirilmelidir veya ortam NOC gerektirecek kadar büyük değilse, günlükler düzenli bir günlük inceleme sürecinden geçmelidir.

Many times interesting events trigger an alert which is sent to a responder for action. Frequently this alert takes the form of an email with the messages of interest. An interesting event could be a significant failure, or known health indicator of a pending failure. Two common utilities for managing alerts are Nagios and Zabbix.

Güncellemeler ve yamalar¶

Bir hipervizör, bağımsız sanal makineleri çalıştırır. Bu hipervizör bir işletim sisteminde veya doğrudan donanımda (baremetal olarak adlandırılır) çalışabilir. Hipervizördeki güncellemeler, sanal makinelere iletilmez. Örneğin, bir dağıtım, XenServer’ı kullanıyorsa ve bir Debian sanal makinelerine sahipse, XenServer’a yapılan bir güncelleme, Debian sanal makinelerinde çalışan bir şeyi güncelleyemez.

Bu nedenle, sanal makinelerin sahipliğinin atanmasını ve bu sahiplerin sanal makinelerin sıkılaştırılmasından, kurulumundan ve işlevselliğinden sorumlu olmasını öneririz. Ayrıca, güncellemelerin düzenli bir programda dağıtılmasını öneriyoruz. Bu yamalar, yamanın istikrar ve sorun çözülmesini sağlamak için olabildiğince canlıya benzeyen bir ortamda test edilmelidir.

Güvenlik duvarları ve diğer sunucu tabanlı güvenlik kontrolleri¶

En yaygın işletim sistemleri, ek güvenlik için sunucu tabanlı güvenlik duvarlarını içerir. Sanal makinelerin olabildiğince az sayıda uygulama (mümkünse tek amaçlı örnek olması açısından) çalıştırmamızı öneririz, ancak sanal makinede çalışan tüm uygulamalar, uygulamanın hangi sistem kaynaklarına erişmesi gerektiğini belirlemek için profillendirilmelidir; en düşük çalıştırılabilmesi için gereken ayrıcalık düzeyini ve sanal makineye giden ve gelen sanal trafik nedir. Bu beklenen trafik, SSH veya RDP gibi gerekli günlük kaydı ve yönetim iletişimiyle birlikte, izin verilen trafik (veya beyaz listeye eklenmiş olarak) olarak sunucu tabanlı güvenlik duvarına eklenmelidir. Tüm diğer trafik, güvenlik duvarı yapılandırmasında açıkça reddedilmelidir.

Linux sanal makinelerinde, yukarıdaki uygulama profili, daha da koruyacak bir SELinux politikası oluşturmak için çoğu Linux dağıtımında hassas sistem bilgileri korumak için audit2allow <http://wiki.centos.org/HowTos/SELinux#head-faa96b3fdd922004cdb988c1989e56191c257c01> gibi bir araçla birlikte kullanılabilir. SELinux, bir uygulamanın çalışması için gerekli kaynakları bölümlemek ve ihtiyaç duyulmayan diğer sistem kaynaklarından ayırmak için kullanıcıların, ilkelerin ve güvenlik bağlamlarının bir kombinasyonunu kullanır.

OpenStack, belirli bir projedeki sanal makinelere derinlemesine savunma eklemek için hem ana makineler hem de ağ için güvenlik grupları sağlar. Gelen trafiği port, protokol ve adres temelinde kabul veya reddettiği için bunlar sunucu tabanlı güvenlik duvarlarına benzer, ancak güvenlik grup kuralları yalnızca gelen trafiğe uygulanır, ancak sunucu tabanlı güvenlik duvarı kuralları hem gelen hem de giden trafik. Ana bilgisayar ve ağ güvenlik grubu kurallarının çakışması ve meşru trafiği reddetmesi de mümkündür. Kullanılan ağlar için güvenlik gruplarının doğru yapılandırılmasını sağlamanızı öneririz. Daha ayrıntılı bilgi için bakınız Güvenlik Grupları.

Örnekler için güvenlik servisleri