[ English | Indonesia | Deutsch | 日本語 ]
Faktor-faktor yang mempengaruhi pengerahan OpenStack¶
Persyaratan keamanan¶
Ketika menggunakan OpenStack di perusahaan sebagai cloud pribadi, biasanya di balik firewall dan di dalam jaringan tepercaya bersama sistem yang ada. Pengguna adalah karyawan yang terikat oleh persyaratan keamanan perusahaan. Ini cenderung mendorong sebagian besar domain keamanan ke arah model yang lebih tepercaya. Namun, ketika menggunakan OpenStack dalam peran publik, tidak ada asumsi yang dapat dibuat dan vektor serangan meningkat secara signifikan.
Pertimbangkan implikasi dan persyaratan keamanan berikut:
Mengelola pengguna untuk cloud publik dan pribadi. Layanan Identity memungkinkan LDAP menjadi bagian dari proses otentikasi. Ini dapat memudahkan manajemen pengguna jika berintegrasi ke sistem yang ada.
Permintaan otentikasi pengguna mencakup informasi sensitif termasuk nama pengguna, kata sandi, dan token otentikasi. Sangat disarankan untuk menempatkan layanan API di belakang perangkat keras yang melakukan penghentian SSL.
Pengguna negatif atau bermusuhan yang akan menyerang atau membahayakan keamanan penyebaran Anda terlepas dari firewall atau perjanjian keamanan.
Vektor serangan meningkat lebih lanjut di publik yang menghadapi penyebaran OpenStack. Misalnya, endpoint API dan perangkat lunak di belakangnya menjadi rentan terhadap entitas yang bermusuhan yang berusaha mendapatkan akses tidak sah atau mencegah akses ke layanan. Anda harus memberikan penyaringan yang sesuai dan audit keamanan berkala.
Peringatan
Berhati-hatilah terhadap konsistensi saat menggunakan cloud pihak ketiga untuk menjelajahi opsi otentikasi.
Untuk informasi lebih lanjut, OpenStack Security, lihat OpenStack Security Guide.
Domain keamanan¶
Domain keamanan terdiri dari pengguna, aplikasi, server atau jaringan yang berbagi persyaratan dan harapan kepercayaan bersama dalam suatu sistem. Biasanya mereka memiliki persyaratan dan pengguna otentikasi dan otorisasi yang sama.
Domain keamanan meliputi:
- Domain keamanan publik
Domain keamanan publik dapat merujuk ke internet secara keseluruhan atau jaringan di mana Anda tidak memiliki wewenang. Domain ini dianggap tidak tepercaya. Misalnya, dalam penyebaran cloud hybrid, setiap informasi yang melintasi antara dan di luar cloud berada dalam domain publik dan tidak dapat dipercaya.
- Domain keamanan guest
Domain keamanan guest menangani data komputasi yang dihasilkan oleh instance di cloud, tetapi bukan layanan yang mendukung operasi cloud, seperti panggilan API. Penyedia cloud publik dan penyedia cloud pribadi yang tidak memiliki kontrol ketat pada penggunaan instance atau yang memungkinkan akses internet tidak terbatas ke instance harus menganggap domain ini tidak dapat dipercaya. Penyedia cloud swasta mungkin ingin mempertimbangkan jaringan ini sebagai internal dan karenanya hanya dipercaya jika mereka memiliki kontrol untuk menegaskan bahwa mereka mempercayai mesin virtual dan semua penyewa mereka.
- Manajemen domain keamanan
Domain keamanan manajemen adalah tempat layanan berinteraksi. Kadang-kadang disebut sebagai bidang kontrol, jaringan dalam domain ini mengangkut data rahasia seperti parameter konfigurasi, nama pengguna, dan kata sandi. Dalam sebagian besar penggunaan, domain ini dianggap tepercaya saat berada di belakang firewall organisasi.
- Domain keamanan data
Domain keamanan data terutama berkaitan dengan informasi yang berkaitan dengan layanan penyimpanan dalam OpenStack. Data yang melintasi jaringan ini memiliki persyaratan integritas dan kerahasiaan yang tinggi dan, tergantung pada jenis penyebaran, mungkin juga memiliki persyaratan ketersediaan yang kuat. Tingkat kepercayaan jaringan ini sangat tergantung pada keputusan penempatan lainnya.
Domain keamanan ini dapat dipetakan secara individual atau kolektif ke penyebaran OpenStack. Operator cloud harus mengetahui masalah keamanan yang sesuai. Domain keamanan harus dipetakan terhadap topologi penyebaran OpenStack spesifik Anda. Domain dan persyaratan kepercayaan mereka bergantung pada apakah mesin virtual tersebut publik, pribadi, atau hibrid.
Keamanan hypervisor¶
Hypervisor juga membutuhkan penilaian keamanan. Dalam cloud publik, organisasi biasanya tidak memiliki kendali atas pilihan hypervisor. Mengamankan hypervisor dengan benar adalah penting. Serangan yang dilakukan pada hypervisor yang tidak aman disebut sebagai hypervisor breakout. Hypervisor breakout menggambarkan peristiwa yang berkompromi atau berbahaya yang memecah kontrol sumber daya dari hypervisor dan mendapatkan akses ke sistem operasi bare metal dan sumber daya perangkat keras.
Keamanan hypervisor bukan masalah jika keamanan instance tidak penting. Namun, perusahaan dapat meminimalkan kerentanan dengan menghindari berbagi perangkat keras dengan orang lain di cloud publik.
Keamanan baremetal¶
Ada layanan lain yang layak dipertimbangkan yang menyediakan contoh bare metal bukan cloud. Dalam kasus lain, dimungkinkan untuk mereplikasi cloud pribadi kedua dengan mengintegrasikannya dengan penyebaran Cloud-as-a-Service pribadi. Organisasi tidak membeli perangkat keras, tetapi juga tidak berbagi dengan penyewa lain. Dimungkinkan juga untuk menggunakan penyedia yang meng-host instance cloud publik bare-metal yang perangkatnya didedikasikan hanya untuk satu pelanggan, atau penyedia yang menawarkan Cloud-as-a-Service pribadi.
Penting
Setiap cloud mengimplementasikan layanan secara berbeda. Memahami persyaratan keamanan setiap cloud yang menangani data atau beban kerja organisasi.
Keamanan jaringan¶
Pertimbangkan implikasi dan persyaratan keamanan sebelum merancang topologi jaringan fisik dan logis. Pastikan bahwa jaringan dipisahkan dengan baik dan arus lalu lintas menuju ke tujuan yang benar tanpa melintasi lokasi yang tidak diinginkan. Pertimbangkan faktor-faktor berikut:
Firewalls
Overlay interkoneksi untuk bergabung dengan jaringan penyewa yang terpisah
Routing melalui atau menghindari jaringan tertentu
Bagaimana jaringan dilampirkan ke hypervisor dapat mengekspos kerentanan keamanan. Untuk mengurangi gangguan hypervisor, pisahkan jaringan dari sistem lain dan jadwalkan instance untuk jaringan ke node Compute khusus. Ini mencegah penyerang memiliki akses ke jaringan dari instance yang dikompromikan.
Keamanan multi-situs¶
Mengamankan instalasi OpenStack multi-situs membawa beberapa tantangan. Penyewa dapat mengharapkan jaringan yang dibuat penyewa aman. Dalam instalasi multi-situs, penggunaan koneksi non-pribadi antara situs mungkin diperlukan. Ini mungkin berarti bahwa lalu lintas akan terlihat oleh pihak ketiga dan, dalam kasus di mana aplikasi membutuhkan keamanan, masalah ini membutuhkan mitigasi. Dalam hal ini, instal VPN atau koneksi terenkripsi antara situs untuk menyembunyikan lalu lintas sensitif.
Identitas adalah pertimbangan keamanan lainnya. Sentralisasi otentikasi menyediakan titik otentikasi tunggal untuk pengguna di seluruh penyebaran, dan titik administrasi tunggal untuk operasi tradisional membuat, membaca, memperbarui, dan menghapus. Otentikasi terpusat juga berguna untuk tujuan audit karena semua token otentikasi berasal dari sumber yang sama.
Penyewa di instalasi multi-situs membutuhkan isolasi satu sama lain. Tantangan utama adalah memastikan fungsi jaringan penyewa di seluruh wilayah yang saat ini tidak didukung di OpenStack Networking (neutron). Oleh karena itu sistem eksternal mungkin diperlukan untuk mengelola pemetaan. Jaringan penyewa dapat berisi informasi sensitif yang membutuhkan pemetaan yang akurat dan konsisten untuk memastikan bahwa penyewa di satu situs tidak terhubung ke penyewa yang lain di situs lain.
Persyaratan legal¶
Menggunakan sumber daya jarak jauh untuk pengumpulan, pemrosesan, penyimpanan, dan pengambilan memberikan potensi keuntungan bagi bisnis. Dengan pertumbuhan data yang cepat di dalam organisasi, bisnis harus proaktif tentang strategi penyimpanan data mereka dari sudut pandang kepatuhan.
Sebagian besar negara memiliki persyaratan legislatif dan peraturan yang mengatur penyimpanan dan pengelolaan data di lingkungan cloud. Ini sangat relevan untuk model cloud publik, komunitas, dan hybrid, untuk memastikan privasi data dan perlindungan bagi organisasi yang menggunakan penyedia cloud pihak ketiga.
Area regulasi yang umum meliputi:
Kebijakan penyimpanan data memastikan penyimpanan data yang persisten dan manajemen catatan untuk memenuhi persyaratan arsip data.
Kebijakan kepemilikan data yang mengatur kepemilikan dan tanggung jawab atas data.
Kebijakan kedaulatan data yang mengatur penyimpanan data di negara asing atau yurisdiksi terpisah.
Kebijakan kepatuhan data yang mengatur jenis informasi tertentu yang perlu berada di lokasi tertentu karena masalah peraturan - dan yang lebih penting, tidak dapat berada di lokasi lain karena alasan yang sama.
Kebijakan lokasi data yang memastikan bahwa layanan yang digunakan untuk cloud digunakan sesuai dengan hukum dan peraturan yang berlaku untuk karyawan, anak perusahaan asing, atau pihak ketiga.
Kebijakan pemulihan bencana memastikan pencadangan data berkala dan relokasi aplikasi cloud ke pemasok lain dalam skenario di mana penyedia mungkin keluar dari bisnis, atau pusat data mereka bisa menjadi tidak dapat dioperasikan.
Kebijakan pelanggaran keamanan yang mengatur cara untuk memberi tahu individu melalui sistem penyedia cloud atau cara lain jika data pribadi mereka dikompromikan dengan cara apa pun.
Kebijakan standar industri yang mengatur persyaratan tambahan tentang jenis data pemegang kartu yang dapat disimpan atau tidak dan bagaimana data itu harus dilindungi.
Ini adalah contoh kerangka hukum tersebut:
Peraturan penyimpanan data di Eropa saat ini didorong oleh ketentuan Data protection board. Financial Industry Regulatory Authority bekerja pada ini di Amerika Serikat.
Privasi dan keamanan tersebar di berbagai undang-undang dan peraturan khusus industri:
Health Insurance Portability and Accountability Act (HIPAA)
Gramm-Leach-Bliley Act (GLBA)
Payment Card Industry Data Security Standard (PCI DSS)
Family Educational Rights and Privacy Act (FERPA)
Arsitektur keamanan cloud¶
Arsitektur keamanan cloud harus mengenali masalah yang muncul dengan manajemen keamanan, yang mengatasi masalah ini dengan kontrol keamanan. Kontrol keamanan cloud diterapkan untuk melindungi segala kelemahan dalam sistem, dan mengurangi efek serangan.
Kontrol keamanan berikut dijelaskan di bawah ini.
- Kontrol pencegah (deterrent):
Biasanya mengurangi tingkat ancaman dengan memberi tahu penyerang potensial bahwa akan ada konsekuensi yang merugikan bagi mereka jika mereka melanjutkan.
- Kontrol pencegahan (preventive):
Perkuat sistem terhadap insiden, umumnya dengan mengurangi jika tidak benar-benar menghilangkan kerentanan.
- Kontrol detektif:
Dimaksudkan untuk mendeteksi dan bereaksi secara tepat terhadap setiap insiden yang terjadi. Pemantauan keamanan sistem dan jaringan, termasuk deteksi intrusi dan pengaturan pencegahan, biasanya digunakan untuk mendeteksi serangan pada sistem cloud dan infrastruktur komunikasi pendukung.
- Kontrol korektif:
Kurangi konsekuensi dari suatu insiden, biasanya dengan membatasi kerusakan. Mereka mulai berlaku selama atau setelah suatu insiden. Mengembalikan cadangan sistem untuk membangun kembali sistem yang dikompromikan adalah contoh dari kontrol korektif.
Untuk informasi lebih lanjut, lihat Lihat juga NIST Special Publication 800-53.
Lisensi perangkat lunak¶
Berbagai bentuk perjanjian lisensi untuk perangkat lunak sering ditulis dengan menggunakan perangkat keras khusus. Model ini relevan untuk platform cloud itu sendiri, termasuk sistem operasi hypervisor, perangkat lunak pendukung untuk item seperti basis data, RPC, cadangan, dan sebagainya. Pertimbangan harus dibuat ketika menawarkan layanan Compute instance dan aplikasi untuk end users cloud, karena persyaratan lisensi untuk perangkat lunak itu mungkin memerlukan beberapa penyesuaian untuk dapat beroperasi secara ekonomis di cloud.
Penyebaran OpenStack multi-situs menghadirkan pertimbangan lisensi tambahan di atas dan di atas cloud OpenStack biasa, khususnya di mana lisensi situs digunakan untuk menyediakan akses yang efisien biaya ke lisensi perangkat lunak. Lisensi untuk sistem operasi host, sistem operasi guest, distribusi OpenStack (jika ada), infrastruktur yang ditentukan perangkat lunak termasuk pengontrol jaringan dan sistem penyimpanan, dan bahkan aplikasi individual perlu dievaluasi.
Topik yang perlu dipertimbangkan meliputi:
Definisi dari apa yang merupakan situs dalam lisensi yang relevan, karena istilah tersebut tidak selalu menunjukkan lokasi geografis atau lokasi yang terisolasi secara fisik.
Perbedaan antara situs "hot" (active) dan "cold" (inactive), di mana penghematan yang signifikan dapat dilakukan dalam situasi di mana satu situs siaga cold untuk tujuan pemulihan bencana saja.
Lokasi tertentu mungkin memerlukan vendor lokal untuk memberikan dukungan dan layanan untuk setiap situs yang mungkin berbeda dengan perjanjian lisensi yang berlaku.
