[ English | 한국어 (대한민국) | English (United Kingdom) | Indonesia | français | русский | Deutsch ]
Keamanan¶
Keamanan adalah salah satu prioritas utama dalam OpenStack-Ansible (OSA), dan banyak peningkatan keamanan untuk awan OpenStack tersedia dalam penyebaran secara default. Bagian ini memberikan tinjauan mendetail tentang peningkatan keamanan yang paling penting.
Catatan
Setiap deployer memiliki persyaratan keamanan yang berbeda. The OpenStack Security Guide memiliki petunjuk dan saran tentang cara mengoperasikan dan mengkonsumsi cloud OpenStack dengan menggunakan metode yang paling aman.
Komunikasi terenkripsi¶
Setiap OpenStack cloud memiliki informasi sensitif yang dikirimkan antara layanan, termasuk kredensial pengguna, kredensial layanan atau informasi tentang sumber daya yang dibuat. Mengenkripsi lalu lintas ini sangat penting dalam lingkungan di mana jaringan tidak dapat dipercaya. (Untuk informasi lebih lanjut tentang mengamankan jaringan, lihat bagian Mengamankan akses jaringan ke layanan OpenStack).
Banyak layanan yang disebarkan dengan OpenStack-Ansible dienkripsi secara default atau menawarkan enkripsi sebagai opsi. Playbooks menghasilkan sertifikat yang ditandatangani sendiri secara default, tetapi para penyusun memiliki opsi untuk menggunakan sertifikat, kunci, dan sertifikat CA mereka yang sudah ada.
Untuk mempelajari lebih lanjut tentang cara menyesuaikan penyebaran komunikasi terenkripsi, lihat Securing services with SSL certificates.
Pengerasan keamanan host¶
OpenStack-Ansible menyediakan security hardening role komprehensif yang menerapkan lebih dari 200 konfigurasi keamanan seperti yang direkomendasikan oleh Security Technical Implementation Guide (STIG) yang disediakan oleh Badan Defense Information Systems Agency (DISA). Konfigurasi keamanan ini banyak digunakan dan didistribusikan dalam domain publik oleh pemerintah Amerika Serikat.
Pengerasan keamanan host diperlukan oleh beberapa program kepatuhan dan peraturan, seperti Payment Card Industry Data Security Standard (PCI DSS) (Requirement 2.2).
Secara default, OpenStack-Ansible secara otomatis menerapkan peran ansible-hardening untuk semua penyebaran. Peran telah dirancang dengan cermat untuk melakukan sebagai berikut:
Terapkan tanpa gangguan ke lingkungan OpenStack produksi
Seimbangkan keamanan dengan kinerja dan fungsionalitas OpenStack
Jalankan secepat mungkin
Untuk informasi lebih lanjut tentang konfigurasi keamanan, lihat dokumentasi security hardening role .
Isolasi¶
Secara default, OpenStack-Ansible menyediakan isolasi secara default antara kontainer yang menjalankan layanan infrastruktur OpenStack (control plane) dan juga antara mesin virtual yang membuat pengguna pembiakan (spawn) dalam penyebaran (deployment). Isolasi ini sangat penting karena dapat mencegah penumpukan kontainer atau mesin virtual, atau setidaknya mengurangi kerusakan yang mungkin ditimbulkan oleh kebocoran (breakout).
Kerangka kerja Linux Security Modules (LSM) memungkinkan administrator untuk mengatur mandatory access controls (MAC) pada sistem Linux. MAC berbeda dari discretionary access controls (DAC) karena kernel memberlakukan kebijakan ketat yang tidak dapat dilewati oleh pengguna. Meskipun setiap pengguna mungkin dapat mengubah kebijakan DAC (seperti chown bob secret.txt), hanya pengguna root yang dapat mengubah kebijakan MAC.
OpenStack-Ansible saat ini menggunakan AppArmor untuk memberikan kebijakan MAC pada server infrastruktur dan hypervisor. Konfigurasi AppArmor menetapkan kebijakan akses untuk mencegah satu container mengakses data container lain. Untuk mesin virtual, libvirtd menggunakan ekstensi sVirt untuk memastikan bahwa satu mesin virtual tidak dapat mengakses data atau perangkat dari mesin virtual lain.
Kebijakan ini diterapkan dan diatur di tingkat kernel. Setiap proses yang melanggar suatu kebijakan tidak diberi akses ke sumber daya. Semua penolakan masuk auditd dan tersedia di /var/log/audit/audit.log.
Hak istimewa terkecil (least privilege)¶
Prinsip principle of least privilege digunakan di seluruh OpenStack-Ansible untuk membatasi kerusakan yang dapat disebabkan jika penyerang mendapatkan akses ke kredensial.
OpenStack-Ansible mengonfigurasi kombinasi nama pengguna dan kata sandi unik untuk setiap layanan yang berinteraksi dengan RabbitMQ dan Galera/MariaDB. Setiap layanan yang terhubung ke RabbitMQ menggunakan host virtual terpisah untuk mempublikasikan dan mengkonsumsi pesan. Pengguna MariaDB untuk setiap layanan hanya diberikan akses hanya ke database yang mereka butuhkan untuk query.
Mengamankan akses jaringan ke layanan OpenStack¶
Cloud OpenStack menyediakan banyak layanan kepada end user, yang memungkinkan mereka untuk membuat instance, penyimpanan provisi, dan membuat jaringan. Setiap layanan ini memaparkan satu atau beberapa port layanan dan API endpoint ke jaringan.
Namun, beberapa layanan dalam cloud OpenStack dapat diakses oleh semua end user, sementara yang lain hanya dapat diakses oleh administrator atau operator di jaringan yang aman.
Layanan yang all end users dapat mengakses
Layanan ini termasuk Compute (nova), Object Storage (swift), Networking (neutron), and Image (glance).
Layanan ini harus ditawarkan pada jaringan terbatas yang masih memungkinkan semua pengguna akhir (end user) untuk mengakses layanan.
Firewall harus digunakan untuk membatasi akses ke jaringan.
Layanan only administrators or operators yang dapat mengakses.
Layanan ini termasuk MariaDB, Memcached, RabbitMQ, dan admin API endpoint untuk layanan Identity (keystone).
Layanan ini must ditawarkan pada jaringan yang sangat terbatas yang hanya tersedia untuk pengguna administratif.
Firewall harus digunakan untuk membatasi akses ke jaringan.
Membatasi akses ke jaringan ini memiliki beberapa manfaat:
Mengizinkan pemantauan jaringan dan peringatan
Mencegah pengawasan jaringan yang tidak sah
Mengurangi kesempatan pencurian kredensial
Mengurangi kerusakan dari kerentanan layanan yang tidak diketahui atau tidak ditambal (unpatched).
OpenStack-Ansible mengerahkan HAProxy back end untuk setiap layanan dan membatasi akses untuk layanan yang sangat sensitif dengan menjadikannya hanya tersedia di jaringan manajemen. Deployer dengan load balancer eksternal harus memastikan bahwa back end dikonfigurasikan dengan aman dan bahwa firewall mencegah lalu lintas yang melintas antar jaringan.
Untuk informasi lebih lanjut tentang kebijakan jaringan yang disarankan untuk cloud OpenStack, lihat bagian API proses isolasi titik akhir dan kebijakan pada OpenStack Security Guide
