Manajemen sistem kontinu¶
Awan akan selalu memiliki bug. Beberapa di antaranya akan menjadi masalah keamanan. Untuk alasan ini, sangat penting untuk bersiap menerapkan pembaruan keamanan dan pembaruan perangkat lunak umum. Ini melibatkan penggunaan alat manajemen konfigurasi yang cerdas, yang akan dibahas di bawah ini. Ini juga melibatkan mengetahui kapan upgrade diperlukan.
Manajemen Kerentanan¶
Untuk pengumuman terkait perubahan keamanan yang relevan, berlangganan ke OpenStack Announce mailing list. Pemberitahuan keamanan juga diposting melalui paket hilir, misalnya melalui distribusi Linux yang mungkin Anda andalkan sebagai bagian dari pembaruan paket.
Komponen OpenStack hanya sebagian kecil dari perangkat lunak di awan. Penting untuk tetap up to date dengan semua komponen lainnya juga. Sementara sumber data tertentu akan diterapkan secara khusus, administrator awan harus berlangganan milis yang diperlukan untuk menerima pemberitahuan tentang pembaruan keamanan apa pun yang berlaku untuk lingkungan organisasi. Seringkali ini sesederhana melacak distribusi Linux hulu.
Catatan
OpenStack merilis informasi keamanan melalui dua saluran.
OpenStack Security Advisories (OSSA) dibuat oleh OpenStack Vulnerability Management Team (VMT). Mereka terkait dengan lubang keamanan di layanan inti OpenStack. Informasi lebih lanjut tentang VMT dapat ditemukan di Vulnerability Management Process.
OpenStack Security Notes (OSSN) dibuat oleh OpenStack Security Group (OSSG) untuk mendukung pekerjaan VMT. OSSN mengatasi masalah dalam mendukung perangkat lunak dan konfigurasi penggunaan umum. Mereka dirujuk di seluruh panduan ini. Catatan Keamanan diarsipkan di OSSN.
Triage¶
Setelah Anda diberitahu tentang pembaruan keamanan, langkah selanjutnya adalah menentukan seberapa penting pembaruan ini untuk penyebaran cloud yang diberikan. Dalam hal ini, penting untuk memiliki kebijakan yang telah ditentukan sebelumnya. Sistem peringkat kerentanan yang ada seperti common vulnerability scoring system (CVSS) tidak memperhitungkan dengan benar penyebaran cloud.
Dalam contoh ini kami memperkenalkan matriks penilaian yang menempatkan kerentanan dalam tiga kategori: rivilege Escalation, Denial of Service dan Information Disclosure. Memahami jenis kerentanan dan di mana hal itu terjadi di infrastruktur Anda akan memungkinkan Anda membuat keputusan respons beralasan.
Privilege Escalation menggambarkan kemampuan pengguna untuk bertindak dengan hak istimewa beberapa pengguna lain dalam sebuah sistem, melewati pemeriksaan otorisasi yang tepat. Pengguna tamu yang melakukan operasi yang memungkinkan mereka melakukan operasi yang tidak sah dengan hak istimewa administrator adalah contoh jenis kerentanan ini.
Denial of Service mengacu pada kerentanan yang dieksploitasi yang dapat menyebabkan gangguan layanan atau sistem. Ini termasuk serangan terdistribusi untuk membanjiri sumber daya jaringan, dan serangan pengguna tunggal yang biasanya disebabkan oleh bug alokasi sumber daya atau kekurangan kegagalan sistem yang disebabkan masukan.
Kerentanan Information Disclosurei mengungkapkan informasi tentang sistem atau operasi Anda. Kerentanan ini berkisar dari debugging pengungkapan informasi, hingga pemaparan (exposure) data keamanan penting, seperti kredensial dan kata kunci otentikasi.
Posisi penyerang / tingkat privilege |
||||
|---|---|---|---|---|
External |
Cloud user |
Cloud admin |
Control plane |
|
Privilege elevation (3 tingkat) |
Critical |
n/a |
n/a |
n/a |
Privilege elevation (2 tingkat) |
Critical |
Critical |
n/a |
n/a |
Privilege elevation (1 tingkat) |
Critical |
Critical |
Critical |
n/a |
Denial of service |
High |
Medium |
Low |
Low |
Information disclosure |
Critical / high |
Critical / high |
Medium / low |
Low |
Tabel ini menggambarkan pendekatan generik untuk mengukur dampak kerentanan berdasarkan pada mana hal itu terjadi dalam penerapan dan pengaruhnya. Sebagai contoh, eskalasi hak istimewa tingkat tunggal pada node Compute API berpotensi memungkinkan pengguna standar API meningkat untuk memiliki hak istimewa yang sama seperti pengguna root di node.
Kami menyarankan agar administrator awan menggunakan tabel ini sebagai model untuk membantu menentukan tindakan mana yang harus dilakukan untuk berbagai tingkat keamanan. Misalnya, pembaruan keamanan tingkat kritis mungkin memerlukan awan untuk ditingkatkan dengan cepat sedangkan pembaruan tingkat rendah mungkin memerlukan waktu lebih lama untuk diselesaikan.
Menguji pembaruan¶
Anda harus menguji pembaruan sebelum menerapkannya di lingkungan produksi. Biasanya ini memerlukan setup awan uji terpisah yang pertama kali menerima pembaruan. Awan ini harus sedekat mungkin dengan awan produksi, dalam hal perangkat lunak dan perangkat keras. Pembaruan harus diuji secara menyeluruh dalam hal dampak kinerja, stabilitas, dampak aplikasi, dan lainnya. Terutama yang penting adalah untuk memverifikasi bahwa masalah yang secara teoritis ditangani oleh pembaruan, seperti kerentanan spesifik, dan masalah ini diperbaiki secara nata.
Menyebarkan pembaruan¶
Setelah pembaruan diuji sepenuhnya, mereka dapat dikirim ke lingkungan produksi. Penyebaran ini harus sepenuhnya otomatis menggunakan alat manajemen konfigurasi yang dijelaskan di bawah ini.
Manajemen konfigurasi¶
Awan kualitas produksi harus selalu menggunakan alat untuk mengotomatisasi konfigurasi dan penyebaran. Ini menghilangkan kesalahan manusia, dan memungkinkan awan untuk skala jauh lebih cepat. Otomasi juga membantu dengan integrasi dan pengujian terus menerus.
Saat membangun awan OpenStack, sangat disarankan untuk mendekati desain dan implementasi Anda dengan alat manajemen konfigurasi atau kerangka kerja. Manajemen konfigurasi memungkinkan Anda menghindari banyak jebakan yang melekat dalam membangun, mengelola, dan memelihara infrastruktur sekompleks OpenStack. Dengan memproduksi manifes, buku masak, atau templat yang diperlukan untuk utilitas pengelolaan konfigurasi, Anda dapat memenuhi sejumlah persyaratan pelaporan dokumentasi dan peraturan. Selanjutnya, manajemen konfigurasi juga dapat berfungsi sebagai bagian dari business continuity plan (BCP) dan perencanaan data recovery (DR) Anda di mana Anda dapat membangun kembali node atau layanan mundur (service back) ke keadaan yang sudah diketahui dalam kejadian DR atau bahaya yang ada.
Selain itu, bila digabungkan dengan sistem kontrol versi seperti Git atau SVN, Anda dapat melacak perubahan pada lingkungan Anda dari waktu ke waktu dan memediasi kembali perubahan yang tidak sah yang mungkin terjadi. Misalnya, file nova.conf atau file konfigurasi lainnya tidak sesuai dengan standar Anda, alat manajemen konfigurasi Anda dapat mengembalikan atau mengganti file dan membawa konfigurasi Anda kembali ke keadaan yang sudah diketahui. Akhirnya alat manajemen konfigurasi juga bisa digunakan untuk menyebarkan update; menyederhanakan proses patch keamanan. Alat ini memiliki berbagai kemampuan yang berguna di ruang ini. Titik kunci untuk mengamankan awan Anda adalah memilih alat untuk pengelolaan konfigurasi dan menggunakannya.
Ada banyak solusi manajemen konfigurasi; Pada saat penulisan ini ada dua di pasar yang kuat dalam mendukung lingkungan OpenStack: Chef dan Puppet. Daftar alat yang tidak lengkap (non-exhaustive) di ruang ini disediakan di bawah ini:
Chef
Puppet
Salt Stack
Ansible
Perubahan kebijakan¶
Kapan pun kebijakan atau manajemen konfigurasi diubah, ada baiknya melakukan log aktivitas, dan membuat cadangan salinan dari kumpulan yang baru. Seringkali, kebijakan dan konfigurasi seperti itu disimpan dalam repositori yang dikendalikan oleh versi seperti Git.
Amankan backup dan recovery¶
Penting untuk memasukkan prosedur dan kebijakan cadangan dalam System Security Plan secara keseluruhan. Untuk tinjauan umum yang baik tentang kemampuan dan prosedur OpenStack's Backup dan Recovery, lihat OpenStack Operations Guide on backup and recovery.
Pastikan hanya pengguna terotentikasi dan klien cadangan yang memiliki akses ke server cadangan.
Gunakan opsi enkripsi data untuk penyimpanan dan pengiriman backup.
Gunakan server backup dedicated dan hardened. Log untuk server backup harus dipantau setiap hari dan hanya dapat diakses oleh beberapa individu.
Uji opsi pemulihan data secara teratur. Salah satu hal yang bisa dipulihkan dari backup yang aman adalah image nya. Jika terjadi bahaya, praktik terbaik adalah segera menghentikan instance yang sedang berjalan dan kemudian meluncurkan kembali instance dari image di repositori cadangan yang aman.
Alat audit keamanan¶
Alat audit keamanan dapat melengkapi alat manajemen konfigurasi. Alat audit keamanan mengotomatisasi proses verifikasi bahwa sejumlah besar kontrol keamanan terpenuhi untuk konfigurasi sistem yang diberikan. Alat ini membantu menjembatani kesenjangan dari dokumentasi panduan konfigurasi keamanan (misalnya, the STIG and NSA Guides) ke instalasi sistem tertentu. Misalnya, SCAP dapat membandingkan sistem yang berjalan dengan profil yang telah ditentukan sebelumnya. SCAP mengeluarkan sebuah laporan yang merinci kontrol mana dalam profil yang terpenuhi, mana yang gagal, dan mana yang tidak diperiksa.
Menggabungkan alat manajemen konfigurasi dan keamanan audit menciptakan kombinasi yang hebat. Alat audit akan menyoroti masalah penerapan. Dan alat manajemen konfigurasi menyederhanakan proses perubahan setiap sistem untuk mengatasi masalah audit. Digunakan bersamaan dengan cara ini, alat ini membantu menjaga awan yang memenuhi persyaratan keamanan mulai dari pengerasan (hardening) dasar sampai validasi kepatuhan.
Alat manajemen konfigurasi dan keamanan audit akan mengenalkan lapisan kompleksitas lain ke dalam awan. Kompleksitas ini membawa masalah keamanan tambahan dengannya. Kami menganggap ini sebagai trade-off risiko yang dapat diterima, mengingat manfaat keamanan mereka. Mengamankan penggunaan operasional alat ini berada di luar cakupan panduan ini.
