Başlangıç > VMware > 215: VM şifreleme üzerine

215: VM şifreleme üzerine

zero-trustHer geçen gün popülerliğini daha da artıran bir kavram güvenlik konusu, hele de son dönem veri hırsızlığı örneklerini göz önünde bulundurduğumuz zaman (Bkz. Yahoo ve 500M kullanıcı hesabı). Dolayısı ile artık bir ürünün ne kadar yetenekli olduğu kadar ne kadar güvenli olduğu da ciddi bir kriter, firmalar için.

VMware, NSX tarafında distributed firewall ve micro-segmentation ile güvenlik alanında önemli bir oyuncu olduğunu gösterdi. Ancak hipervizör seviyesinde halen boşluklar vardı. Örnek olarak, bir vSphere admininin, bir sanal sunucuyu export edip, alıp götürmesini engelleyecek built-in bir mekanizma yoktu. Elbette, roller ile oynayıp yetkiler kısılabilir veya SIEM yazılımları ile kontrol artırılabilir ancak diğer potansiyel senaryoları da düşündüğümüzde, kolay oluşturulabilir bir çözüm sağlamayacaktır.

Diğer taraftan konunun bir de cloud tarafı var. Public cloud yapılar ile ilgili en büyük endişe güvenlik iken, şifreleme konusundaki yetersizlikler bu endişeyi daha da destekler nitelikte idi. Ayrıca sadece şifrelemek de tam çözüm sağlamayacak, public ve private key’lerin kimin elinde olduğu da kritik bir nokta.

İyi haber, vSphere 6.5 ile bu tip endişeler adreslenmiş durumda. En önemli iki adet özellik, sanal sunucuların disklerinin ve vMotion trafiğinin şifrelenebilecek olması. VM şifreleme daha önceden, ekosistem içerisinde belirli ürünler tarafından, belirli şartlarda gerçekleştirilebiliyordu (HyTrust gibi) ancak yine üçüncü parti bir firmaya bağımlıydık, artık native bir şekilde gerçekleşebilecek.

Sanal Sunucu şifrelemesi:

Sanal sunucuların, hipervizör seviyesinde şifrelenebilmesini sağlar. OS katmanı ile hiçbir entegrasyonu olmadığından dolayı, işletim sistemi üzerinde hiçbir gereksinimi yoktur, isterseniz Windows 3.1 sistemi bile şifreleyebilirsiniz. VM şifreleme arka tarafta VAIO (vStorage APIs for I/O Filtering) kullanır. VAIO, vSphere 6.0 U1 ile birlikte gündeme gelen, üçüncü parti firmaların entegrasyon sağlayabilmeleri için oluşturulmuş bir mekanizmadır, VMM (Virtual Machine Monitor) ile sanal disk arasında bulunur. VMM ile disk arasında gerçekleşecek tüm disk talepleri, bu filtrelerden geçer. Talep tüm filtrelerden başarı ile geçerse, hedefine ulaşabilir. Artık bu filtreler içerisinde native şifreleme de destekleniyor.

vm_encryption

Mekanizma VAIO tabanlı olduğundan, storage politikaları ile yönetilmektedir. Yapılması gereken bir adet şifreleme politikası oluşturmak ve bunu sunucu kapalı iken VM seviyesinde uygulamak.

Şifrelemeden bahsettiğimiz durumda, elbette bir “Key Management” çözümüne ihtiyacımız var. Bunun için VMware’ın entegre bir çözümü henüz yok, bunu bir eksik olarak nitelendirebiliriz ancak beklentim, ilerleyen versiyonlarda (tıpkı VMCA ile yapıldığı gibi) kendi key manager yazılımını oluşturması olacaktır. Şifreleme özelliğini kullanabilmemiz için, KMIP 1.1 (Key Management Interoperability Protocol) desteği olan bir çözümü kullanmamız gerekmektedir.

Çözüm içerisinde key yönetimi tamamen dışarıdan yapılır. vCenter sunucusunun görevi bir client gibi davranmaktır. Bir VM’e şifreleme politikası uyguladığınız zaman, vCenter sunucusu, key manager üzerinden şifreleme anahtarlarını alır ve ilgili ESXi sunucusunda kernel seviyesinde bulunan “VM encryption” modülüne gönderir ve anahtarlar bellekte tutulur. VAIO filtreleri arasında yer alan bu modül ise artık VMM ile sanal disk arasında gerçekleşen tüm trafiği encrypt/decrypt eder.

Tüm bu şifreleme yeteneği gayet faydalı görünüyorken, bir sıkıntıyı gündeme getiriyor, görevlerin ayrılığı ilkesi. Günün sonunda kurumların, bu işlemi kimin yönetmesi gerektiği konusuna karar vermesi ve doğru dizayn etmesi gerekecektir. Anahtar yönetiminin yapılacağı platform dışarıda olacağı için bu konuda sıkıntı yok, bilgi güvenliği ekiplerinin sorumluluğunda olabilir. Ancak vSphere seviyesinde politikaların oluşturulması, yönetilmesi gibi konular vSphere yöneticilerinin yönetiminde olmaması gerekebilir. Buna istinaden VMware, yeni bir role oluşturmuş durumda; “No Cryptography Administrator“. Bu role, tüm vSphere admin haklarına sahip iken, aşağıdaki yetkilere sahip olmayacaktır;

  • Anahtar sunucuların yönetimi
  • Anahtarların yönetimi
  • Şifreleme politikaların yönetimi
  • Şifrelenmiş VM’lerin konsollarına erişim
  • Şifrelenmiş VM’lerde export/import seçenekleri

vMotion şifrelemesi:

vMotion, kabaca network üzerinden aktif bellek verisinin transfer edilmesi anlamına geldiğinden dolayı, VMware best-practice’ler içerisinde, izole bir network kullanılması ve network seviyesinde güvenliğinin sağlanması önerilirdi. vSphere 6.0 öncesi bu bir nebze anlam ifade ediyordu çünkü trafik L2’de dönen bir trafik idi. Ancak vSphere 6.0 ile birlikte birden fazla TCP/IP stack desteklendiği andan itibaren, vMotion trafiğini L3 döndürebilmeye ve WAN üzerinden gerçekleştirebilmeye başladık. Elbette bu da beraberinde “man in the middle” problemini gündeme getiriyor. 6.5 ile birlikte gelen çözüm, bu trafiğin de şifrelenmesi.

VM seviyesinde yapılabilen bu tanımlama, üç adet alternatif sunuyor;

  • Disabled: vMotion trafiğinin şifrelenmemesi.
  • Opportunistic: Hedef ve kaynak ESXi sunucuları desteklediği sürece şifrelemenin yapılması, aksi taktirde şifrelenmeden bellek verisinin transfer edilmesi.
  • Required: Şifrelemenin kesinlikle gerçekleşmesi, ESXi sunucularının desteklemediği durumda başarısız sonuçlanması.

Eğer bir VM üzerinde şifreleme politikası uygulanmış ise, bu sunucunun vMotion trafiği de mutlaka şifreli olacaktır. Diğer durumlarda, VM seviyesinde karar verebiliriz.

Bir vMotion başladığında, vCenter tarafından rastgele bir şekilde 256-bitlik bir anahtar oluşturulur ve bu anahtar API çağrısının içerisinde yer alan spec objesi aracılığı ile ESXi sunuculara gönderilir. Bu anahtar sayesinde de encrypt/decrypt işlemi gerçekleştirilir.

Performans etkileri ve diğer konular:

Hem VM hem vMotion şifrelemesi söz konusu olduğunda, elbette akla ilk gelen konu, bunun performansa olan etkisi olacaktır. Bu konuda henüz bir benchmark yok ancak yakın zamanda paylaşılacağını düşünüyorum. Yeni Intel Broadwell işlemciler ile birlikte daha da geliştirilen AES-NI (Advanced Encryption Standard New Instructions) ile birlikte, daha önceki jenerasyonlara oranla daha az performans etkisi bekleniyor ancak rakamları görmek lazım.

KMS ürününün üçüncü parti ürünler tarafından yönetilmesi gerektiğinden kısaca bahsetmiştik, bu bağımlılık bazı kurumlar için geri adım atılmasına sebebiyet verebilir.

Şifrelenmiş VM’ler için SAN yedekleme desteklenmeyecektir. Proxy kullanarak yedekleme yapan ürünlerde ise, neyin desteklenip neyin desteklenmediği, yedekleme çözümünün yapısı ile bağlantılı olacaktır. Ancak, tahminim, proxy sunucusunun da şifreli olması gerekecektir. Diğer taraftan, yedeklenen veri şifreli olmayacaktır, yedekleme çözümünün kendi şifreleme mekanizmasının kullanılması gerekmektedir.

Son konu ise vCenter sunucusunun şifrelenmesi. Bunu yapmak isteyecek birileri olur mu bilmiyorum ancak bu iş kolaylıkla yumurta-tavuk senaryosuna dönme potansiyeline sahip görünüyor.

cwk9xvgwaaapfrd

 

 

 

Kategoriler:VMware Etiketler:,
  1. Henüz yorum yapılmamış.
  1. No trackbacks yet.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Connecting to %s

%d blogcu bunu beğendi: