Arsitektur referensi yang aman¶
Sebaiknya gunakan SSL/TLS di jaringan publik ataupun jaringan manajemen di Proxy TLS dan layanan HTTP. Namun, jika benar-benar menerapkan SSL/TLS di mana saja terlalu sulit, sebaiknya Anda mengevaluasi kebutuhan OpenStack SSL/TLS dan mengikuti salah satu arsitektur yang dibahas di sini.
Hal pertama yang harus dilakukan saat mengevaluasi kebutuhan OpenStack SSL/TLS adalah untuk mengidentifikasi ancaman. Anda dapat membagi ancaman ini ke dalam kategori penyerang eksternal dan internal, namun garis tersebut cenderung menjadi kabur karena beberapa komponen OpenStack beroperasi pada jaringan publik dan manajemen.
Untuk layanan yang dihadapi publik, ancamannya sangat mudah. Pengguna akan melakukan otentikasi terhadap horizon dan keystone dengan nama pengguna dan kata sandinya. Pengguna juga akan mengakses API endpoint untuk layanan lain menggunakan token kunci mereka. Jika lalu lintas jaringan ini tidak terenkripsi, kata sandi dan tanda dapat dicegat oleh penyerang menggunakan serangan man-in-the-middle. Penyerang kemudian dapat menggunakan kredensial yang valid ini untuk melakukan operasi berbahaya. Semua penerapan sebenarnya harus menggunakan SSL/TLS untuk melindungi layanan yang dihadapi secara publik.
Untuk layanan yang dikerahkan di jaringan manajemen, ancamannya tidak begitu jelas karena menjembatani domain keamanan dengan keamanan jaringan. Selalu ada kemungkinan administrator dengan akses ke jaringan manajemen memutuskan untuk melakukan sesuatu yang jahat. SSL/TLS tidak akan membantu dalam situasi ini jika penyerang diizinkan untuk mengakses kunci privat. Tidak semua orang di jaringan manajemen akan diizinkan untuk mengakses kunci privat tentunya, jadi masih ada nilai dalam menggunakan SSL/TLS untuk melindungi diri dari penyerang internal. Bahkan jika setiap orang yang diizinkan mengakses jaringan manajemen Anda 100% dipercaya, masih ada ancaman bahwa pengguna yang tidak berwenang mendapatkan akses ke jaringan internal Anda dengan memanfaatkan kerentanan misconfiguration atau perangkat lunak. Kita harus ingat bahwa Anda memiliki pengguna yang menjalankan kode mereka sendiri pada instance di node OpenStack Compute, yang digunakan pada jaringan manajemen. Jika kerentanan memungkinkan mereka keluar dari hypervisor, mereka akan memiliki akses ke jaringan manajemen Anda. Menggunakan SSL/TLS pada jaringan manajemen dapat meminimalkan kerusakan yang dapat menyebabkan penyerang.
Proxy SSL/TLS di depan¶
Umumnya diterima bahwa yang terbaik adalah mengenkripsi data sensitif sedini mungkin dan mendekripsinya selambat mungkin. Meskipun ada praktik terbaik ini, nampaknya umum menggunakan proxy SSL/TLS di depan layanan OpenStack dan menggunakan komunikasi yang jelas setelahnya seperti yang ditunjukkan di bawah ini:
Beberapa kekhawatiran dengan penggunaan proxy SSL/TLS seperti yang digambarkan di atas:
SSL/TLS native di layanan OpenStack tidak melakukan/skala serta proxy SSL (terutama untuk implementasi Python seperti Eventlet).
SSL/TLS native di layanan OpenStack tidak dicermati/diaudit serta bukan solusi yang lebih terjamin.
Konfigurasi SSL/TLS native sulit (tidak terdokumentasi dengan baik, teruji, atau konsisten di seluruh layanan).
Pemisahan hak istimewa (proses layanan OpenStack seharusnya tidak memiliki akses langsung ke kunci privat yang digunakan untuk SSL/TLS).
Inspeksi lalu lintas membutuhkan load balancing.
Semua hal di atas adalah masalah yang valid, namun tidak ada satupun yang mencegah SSL/TLS digunakan pada jaringan manajemen. Mari pertimbangkan model penerapan berikutnya.
SSL/TLS pada host fisik yang sama dengan endpoint API¶
Ini sangat mirip dengan :ref: secure-communication-proxy-in-front tapi proxy SSL/TLS berada pada sistem fisik yang sama dengan endpoint API. Endpoint API akan dikonfigurasi untuk hanya mendengarkan pada antarmuka jaringan lokal. Semua komunikasi jarak jauh dengan endpoint API akan melalui proxy SSL/TLS. Dengan model penyebaran ini, kami menangani sejumlah butir di :ref: secure-communication-proxy-in-front Implementasi SSL yang telah teruji yang berkinerja baik akan digunakan. Perangkat lunak proxy SSL yang sama akan digunakan untuk semua layanan, jadi konfigurasi SSL untuk endpoint API akan konsisten. Proses layanan OpenStack tidak akan memiliki akses langsung ke kunci privat yang digunakan untuk SSL/TLS, karena Anda akan menjalankan proxy SSL sebagai pengguna yang berbeda dan membatasi akses menggunakan izin (dan juga kontrol akses wajib menggunakan sesuatu seperti SELinux). Kami idealnya memiliki endpoint API mendengarkan di soket Unix sehingga kami dapat membatasi akses ke sana menggunakan izin dan kontrol akses wajib juga. Sayangnya, sepertinya ini tidak bekerja saat ini di Eventlet dari pengujian kami. Ini adalah tujuan pembangunan masa depan yang baik.
SSL/TLS over load balancer¶
Bagaimana dengan ketersediaan tinggi atau penerapan seimbang yang perlu untuk memeriksa lalu lintas? Model penyebaran sebelumnya (:ref: secure-communication-proxy-on-same-physical-hosts-as-api-endpoints) tidak akan mengizinkan pemeriksaan paket dalam karena lalu lintas dienkripsi. Jika lalu lintas hanya perlu diperiksa untuk keperluan perutean dasar, mungkin tidak perlu penyeimbang beban untuk mendapatkan akses ke lalu lintas yang tidak dienkripsi. HAProxy memiliki kemampuan untuk mengekstrakSSL/TLS session ID selama handshake, yang kemudian dapat digunakan untuk mencapai afinitas (`session ID configuration details here <http://blog.exceliance.fr/2011/07/04/maintain -affinity-based-on-ssl-session-id /> `_). HAProxy juga dapat menggunakan ekstensi TLS Server Name Indication (SNI) untuk menentukan lalu lintas yang harus diarahkan ke ( `SNI configuration details here <http://blog.exceliance.fr/2012/04/13/enhanced-ssl-load- menyeimbangkan-dengan-server-name-indication-sni-tls-extension /> `_). Fitur ini kemungkinan mencakup beberapa penyeimbang beban yang paling umum. HAProxy hanya bisa melewati lalu lintas HTTPS langsung ke sistem endpoint API dalam kasus ini:
Pemisahan kriptografi lingkungan eksternal dan internal¶
Bagaimana jika Anda ingin pemisahan kriptografi lingkungan eksternal dan internal Anda? Penyedia awan publik mungkin menginginkan agar publik mereka menghadapi layanan (atau proxy) untuk menggunakan sertifikat yang dikeluarkan oleh CA yang mengarah ke Root CA tepercaya yang didistribusikan di perangkat lunak browser web populer untuk SSL/TLS. Untuk layanan internal, orang mungkin ingin menggunakan PKI mereka sendiri untuk menerbitkan sertifikat SSL/TLS. Pemisahan kriptografi ini dapat dilakukan dengan menghentikan SSL pada batas jaringan, kemudian mengenkripsi ulang menggunakan sertifikat yang dikeluarkan secara internal. Lalu lintas tidak akan dienkripsi untuk periode singkat di hadapan publik yang menghadap proxy SSL/TLS, namun tidak akan pernah ditransmisikan melalui jaringan secara jelas. Pendekatan enkripsi ulang yang sama yang digunakan untuk mencapai pemisahan kriptografi juga dapat digunakan jika inspeksi paket dalam benar-benar dibutuhkan pada penyeimbang beban. Inilah model penggelaran ini yang akan terlihat:
Seperti kebanyakan hal, ada trade-off. Trade-off utama akan terjadi antara keamanan dan kinerja. Enkripsi memiliki biaya, tapi begitu juga diretas. Persyaratan keamanan dan kinerja akan berbeda untuk setiap penyebaran, jadi bagaimana SSL/TLS digunakan pada akhirnya akan menjadi keputusan individual.
