Veritabanı erişim kontrolü¶
Çekirdek OpenStack servislerinin her biri (Hesaplama, Kimlik, Ağ Oluşturma, Blok Depolama) veritabanlarındaki durumu ve yapılandırma bilgilerini saklar. Bu bölümde, veritabanlarının şu an OpenStack’te nasıl kullanıldığını tartışıyoruz. Güvenlik endişelerini ve veritabanı arka uç seçeneklerinin güvenlik sonuçlarını keşfediyoruz.
OpenStack veritabanı erişim modeli¶
Bir OpenStack projesindeki tüm servisler tek bir veritabanına erişir. Veritabanına tablo veya satır bazlı erişim kısıtlamaları oluşturmak için şu anda referans politikası yoktur.
OpenStack’te veritabanı işlemlerinin ayrıntılı kontrolü için genel bir hüküm bulunmamaktadır. Erişim ve ayrıcalıklar yalnızca bir düğümün veritabanına erişimi olup olmadığına bağlı olarak verilir. Bu senaryoda, veritabanına erişimi olan düğümler, DROP, INSERT veya UPDATE işlevlerine tam ayrıcalıklara sahip olabilir.
Ayrıntılı erişim kontrolü¶
Varsayılan olarak, OpenStack servislerinin ve süreçlerinin her biri, paylaşılan bir kimlik bilgisi kümesi kullanarak veritabanına erişir. Bu, veritabanı işlemlerini denetlemeyi ve bir hizmetten ve işlemlerinden veritabanına erişim ayrıcalıklarını özellikle zorlaştırır.
Nova-conductor¶
Hesaplama düğümleri, kiracı örneklerini barındırdığı için OpenStack’deki servislerinden en az güvenilen kişilerdir. Nova-conductor hizmeti, hesaplama düğümleri ve veritabanı arasında aracı olarak görev yapan bir veritabanı vekil kaynağı olarak tanıtıldı. Etkilerini bu bölümün ilerleyen bölümlerinde tartışacağız.
Kesinlikle öneriyoruz:
Tüm veritabanı iletişimleri bir yönetim ağına ayrılmış
İletişimi, TLS ile güvenli hale getirmek
Her OpenStack servis uç noktası için ayrı özel veritabanı kullanıcı hesapları oluşturmak (aşağıda örneklendirilmiştir)
Veritabanı kimlik doğrulaması ve erişim kontrolü¶
Veritabanına erişimle ilgili riskler göz önünde bulundurulduğunda, veritabanına erişmesi gereken düğüm başına benzersiz veritabanı kullanıcı hesaplarının oluşturulmasını kuvvetle öneririz. Bunu yapmak, uyumluluğu sağlamak için daha iyi analiz ve denetim sağlamanıza ya da bir düğümün ele geçirilmesi durumunda, ele geçirildiğinde o düğümün veritabanına erişimi kaldırarak saldırıya uğramış sunucuyu ayırmanıza izin verir. Hizmet başına bitiş noktası veritabanı kullanıcı hesaplarını oluştururken bunların TLS’yi gerektirdiği şekilde yapılandırılmasına özen gösterilmelidir. Alternatif olarak, artan güvenlik için veritabanı hesaplarının kullanıcı adlarına ve parolalara ek olarak X.509 sertifika kimlik doğrulaması kullanılarak yapılandırılması önerilir.
Ayrıcalıklar¶
Veritabanları oluşturmak/silmek, kullanıcı hesapları oluşturmak ve kullanıcı ayrıcalıklarını güncellemek için ayrıcalıklara sahip olan ayrı bir veritabanı yöneticisi (DBA) hesabı oluşturulmalı ve korunmalıdır. Sorumluluğun bu şekilde basitçe ayrılması, yanlış yapılandırmanın önlenmesine yardımcı olur, riski düşürür ve tehlikenin kapsamını düşürür.
OpenStack servisleri ve her düğüm için oluşturulan veritabanı kullanıcı hesaplarının, düğümün üye olduğu servise ilişkin yalnızca veritabanıyla sınırlı ayrıcalıklara sahip olması gerekir.
Kullanıcı hesaplarının SSL taşımasını gerektir¶
Yapılandırma örneği #1: (MySQL)¶
GRANT ALL ON dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'NOVA_DBPASS' REQUIRE SSL;
Yapılandırma örneği #2: (PostgreSQL)¶
pg_hba.conf dosyasında:
hostssl dbname compute01 hostname md5
Bu komutu yalnızca SSL üzerinden iletişim kurma yeteneğini ekler ve özel değildir. Şifrelenmemiş aktarmaya izin verebilecek diğer erişim yöntemleri devre dışı bırakılmalıdır, böylece SSL tek erişim yöntemidir.
md5 parametresi, özetlenmiş parola yöntemi olarak bir kimlik doğrulama yöntemi tanımlar. Aşağıdaki bölümde güvenli bir kimlik doğrulama örneği sağlıyoruz.
OpenStack servis veritabanı yapılandırması¶
Veritabanı sunucunuz TLS aktarımı için yapılandırılmışsa, SQLAlchemy sorgusundaki ilk bağlantı dizesiyle birlikte kullanmak üzere sertifika otoritesi bilgilerini belirtmeniz gerekir.
MySQL için :sql_connection örneği:¶
sql_connection = mysql://compute01:NOVA_DBPASS@localhost/nova?charset=utf8&ssl_ca=/etc/mysql/cacert.pem
X.509 sertifikası ile kimlik doğrulama¶
Kimlik doğrulama için X.509 istemci sertifikası isteyerek güvenlik arttırılabilir. Veritabanına bu şekilde kimlik doğrulama yapılması, müşteriye veritabanına bağlantı kurma konusunda daha fazla kimlik güvencesi sağlar ve iletişimlerin şifrelenmesini sağlar.
Yapılandırma örneği #1: (MySQL)¶
GRANT ALL on dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'NOVA_DBPASS' REQUIRE SUBJECT
'/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=compute01' AND ISSUER
'/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=cloud-ca';
Yapılandırma örneği #2: (PostgreSQL)¶
hostssl dbname compute01 hostname cert
OpenStack servis veritabanı yapılandırması¶
Veritabanı sunucunuz, kimlik doğrulaması için X.509 sertifikaları isteyecek şekilde yapılandırılmışsa, veritabanı arka uç için uygun SQLAlchemy sorgu parametrelerini belirtmeniz gerekir. Bu parametreler, ilk bağlantı dizesiyle birlikte kullanılmak üzere sertifika, özel anahtar ve sertifika yetkisi bilgilerini belirtir.
MySQL ile X.509 sertifikası ile kimlik doğrulama için :sql_connection örneği:
sql_connection = mysql://compute01:NOVA_DBPASS@localhost/nova?
charset=utf8&ssl_ca = /etc/mysql/cacert.pem&ssl_cert=/etc/mysql/server-cert.pem&ssl_key=/etc/mysql/server-key.pem
Nova-conductor¶
OpenStack Hesaplama, veritabanıyla doğrudan iletişim kurmanın aksine, veri kalıcılık gereksinimlerini karşılamak için nova hesaplama düğümlerinin nova iletkeniyle etkileşime girmesini temel amacı ile veritabanı bağlantılarını temsil eden bir alt-servis sunar.
Nova-conductor, RPC üzerinden istek alır ve veritabanına, tablolarına veya içindeki verilere ayrıntılı erişim vermeden çağıran servis adına eylemler gerçekleştirir. Nova-conductor, esasen doğrudan veritabanı erişimini hesaplama düğümlerinden uzaklaştırır.
Bu soyutlama, servisleri çok sayıda sistemin doğrudan erişmesini veya veri tabanını değiştirmesini engelleyerek, saklı yordamlara benzer şekilde, parametreleri yöntemlerle yürütme işlemlerine kısıtlama avantajını sunar. Bu, bu prosedürlerin, tipik saklanan prosedürlerin sıkça eleştirildiği veritabanının içeriği veya kapsamı içerisinde saklanması veya yürütülmesine gerek kalmadan gerçekleştirilir.
Maalesef, bu çözüm, daha hassas erişim kontrolü ve veri erişimini denetleme becerisini zorlaştırıyor. nova-conductor servisi, RPC üzerinden istek aldığından mesajlaşma güvenliğini artırmanın önemini vurgular. Mesaj sırasına erişimi olan herhangi bir düğüm, nova-conductor’un sağladığı bu yöntemleri uygulayabilir ve veritabanını etkili bir şekilde değiştirebilir.
nova-conductr yalnızca OpenStack Hesaplama için geçerli olduğundan, hesaplama ana makinelerinden doğrudan veritabanı erişimi, Telemetri (ceilometre), Ağ Oluşturma ve Blok Depolama Alanı gibi diğer OpenStack bileşenleri için hala gerekli olabilir.
Nova-conductor’u devre dışı bırakmak için, aşağıdakileri nova.conf dosyanıza (bilgisayarlarınız üzerinde) yerleştirin:
[conductor]
use_local = true
