Kontrol akses Database¶
Masing-masing layanan OpenStack inti (Compute, Identity, Networking, Block Storage) menyimpan informasi keadaan dan konfigurasi di database. Pada bab ini, kita membahas bagaimana database digunakan saat ini di OpenStack. Kami juga mengeksplorasi masalah keamanan, dan konsekuensi keamanan dari pilihan back end database.
Model akses database OpenStack¶
Semua layanan dalam proyek OpenStack mengakses database tunggal. Saat ini tidak ada kebijakan referensi untuk membuat batasan akses berbasis tabel atau baris ke database.
Tidak ada ketentuan umum untuk pengendalian operasi database di OpenStack. Akses dan hak istimewa diberikan hanya berdasarkan apakah node memiliki akses ke database atau tidak. Dalam skenario ini, node dengan akses ke database mungkin memiliki hak penuh untuk fungsi DROP, INSERT, atau UPDATE.
Kontrol akses Granular¶
Secara default, masing-masing layanan OpenStack dan prosesnya mengakses database menggunakan sekumpulan kredensial bersama. Hal ini membuat operasi database auditing dan mencabut hak akses dari sebuah layanan dan prosesnya ke database sangat sulit dilakukan.
Nova-conductor¶
Node komputasi adalah yang paling tidak dipercaya dari layanan di OpenStack karena mereka menghosting instance penyewa. Layanan nova-conductor telah diperkenalkan untuk dijadikan basis data proxy, bertindak sebagai perantara antara node dan database. Kami mendiskusikan ramalannya nanti di bab ini.
Kami sangat menyarankan:
Semua komunikasi database diisolasi ke jaringan manajemen
Mengamankan komunikasi dengan menggunakan TLS
Membuat akun pengguna database unik per endpoint layanan OpenStack (diilustrasikan di bawah)
Database otentikasi dan kontrol akses¶
Mengingat risiko seputar akses ke database, kami sangat menyarankan agar akun pengguna database unik dibuat per node yang memerlukan akses ke database. Melakukan hal ini memudahkan analisis dan audit yang lebih baik untuk memastikan kepatuhan atau jika kompromi sebuah node memungkinkan Anda untuk mengisolasi host yang dikompromikan dengan menghapus akses node tersebut ke database pada saat deteksi. Saat membuat akun pengguna database endpoint per layanan ini, perhatian harus dilakukan untuk memastikan bahwa mereka dikonfigurasi untuk mewajibkan TLS. Sebagai alternatif, untuk keamanan yang meningkat, disarankan agar akun database dikonfigurasi menggunakan otentikasi sertifikat X.509 selain nama pengguna dan kata sandi.
Hak istimewa¶
database administrator (DBA) terpisah harus dibuat dan dilindungi yang memiliki hak penuh untuk create/drop databases, create user accounts, dan update user privileges. Cara pemisahan tanggung jawab yang sederhana ini membantu mencegah kesalahan konfigurasi yang tidak disengaja, mengurangi risiko dan menurunkan cakupan bahaya (compromise).
Akun pengguna database dibuat untuk layanan OpenStack dan untuk setiap node harus memiliki hak istimewa terbatas hanya pada database yang relevan dengan layanan di mana node adalah anggota.
Perlu akun pengguna untuk meminta transport SSL¶
Configuration example #1: (MySQL)¶
GRANT ALL ON dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'NOVA_DBPASS' REQUIRE SSL;
Configuration example #2: (PostgreSQL)¶
Dalam file pg_hba.conf:
hostssl dbname compute01 hostname md5
Perhatikan perintah ini hanya menambahkan kemampuan untuk berkomunikasi melalui SSL dan tidak eksklusif. Metode akses lain yang memungkinkan pengangkutan yang tidak dienkripsi harus dinonaktifkan sehingga SSL adalah satu-satunya metode akses.
Parameter md5 mendefinisikan metode otentikasi sebagai hashed password. Kami memberikan contoh otentikasi yang aman pada bagian di bawah ini.
Konfigurasi database layanan OpenStack¶
Jika server database Anda dikonfigurasi untuk transport TLS, Anda harus menentukan informasi otoritas sertifikat untuk digunakan dengan string koneksi awal dalam query SQLAlchemy.
Contoh string :sql_connection ke MySQL:¶
sql_connection = mysql://compute01:NOVA_DBPASS@localhost/nova?charset=utf8&ssl_ca=/etc/mysql/cacert.pem
Otentikasi dengan sertifikat X.509¶
Keamanan dapat ditingkatkan dengan mewajibkan sertifikat klien X.509 untuk otentikasi. Mengotentikasi ke database dengan cara ini memberikan jaminan identitas yang lebih besar dari klien yang membuat koneksi ke database dan memastikan bahwa komunikasi dienkripsi.
Configuration example #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';
Configuration example #2: (PostgreSQL)¶
hostssl dbname compute01 hostname cert
Konfigurasi database layanan OpenStack¶
Jika server database Anda dikonfigurasi untuk meminta sertifikat X.509 untuk otentikasi, Anda perlu menentukan parameter kueri SQLAlchemy yang sesuai untuk database back end. Parameter ini menentukan sertifikat, private key, dan informasi otoritas sertifikat untuk digunakan dengan string koneksi awal.
Contoh string :sql_connection untuk otentikasi sertifikat X.509 ke MySQL:
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 Compute menawarkan sub-service yang disebut nova-conductor yang menghubungkan koneksi database, dengan tujuan utama memiliki nova compute node yang berinteraksi dengan nova-conductor untuk memenuhi kebutuhan persistensi data yang bertentangan dengan komunikasi langsung dengan database.
Nova-conductor menerima permintaan di atas RPC dan melakukan tindakan atas nama layanan panggilan tanpa memberikan akses terperinci ke database, tabel, atau data di dalamnya. Nova-konduktor pada dasarnya abstrak akses database langsung dari node komputasi.
Abstraksi ini menawarkan keuntungan untuk membatasi layanan terhadap metode eksekusi dengan parameter, mirip dengan prosedur tersimpan, mencegah sejumlah besar sistem untuk mengakses atau memodifikasi data database secara langsung. Hal ini dilakukan tanpa prosedur yang tersimpan atau dijalankan dalam konteks atau ruang lingkup database itu sendiri, sering mengkritik prosedur tersimpan yang umum.
Sayangnya, solusi ini mempersulit tugas kontrol akses yang lebih halus dan kemampuan untuk mengaudit akses data. Karena layanan nova-conductor menerima permintaan di atas RPC, ini menyoroti pentingnya meningkatkan keamanan pesan. Setiap node dengan akses ke antrian pesan (message queue) dapat menjalankan metode yang disediakan oleh konduktor nova dan memodifikasi database secara efektif.
Catatan, karena nova-konduktor hanya berlaku untuk OpenStack Compute, akses database langsung dari host komputasi mungkin masih diperlukan untuk pengoperasian komponen OpenStack lainnya seperti Telemetry (ceilometer), Networking, dan Block Storage.
Untuk menonaktifkan nova-conductor, tempatkan hal berikut ke file nova.conf Anda (pada host komputasi Anda):
[conductor]
use_local = true
