Pengantar TLS dan SSL

Ada situasi di mana ada persyaratan keamanan untuk memastikan kerahasiaan atau integritas lalu lintas jaringan dalam penerapan OpenStack. Hal ini umumnya dicapai dengan menggunakan ukuran kriptografi, seperti protokol Transport Layer Security (TLS).

Dalam penyebaran yang khas, semua lalu lintas yang dikirim melalui jaringan publik dijamin, namun praktik keamanan terbaik menentukan bahwa lalu lintas internal juga harus diamankan. Tidak cukup mengandalkan pemisahan domain keamanan untuk perlindungan. Jika penyerang memperoleh akses ke hypervisor atau sumber daya host, kompromi API endpoint, atau layanan lainnya, mereka tidak boleh dapat dengan mudah menyuntikkan atau menangkap pesan, perintah, atau mempengaruhi kemampuan pengelolaan awan.

Semua domain harus diamankan dengan TLS, termasuk layanan domain manajemen dan komunikasi intra-layanan. TLS menyediakan mekanisme untuk memastikan otentikasi, non-penolakan, kerahasiaan, dan integritas komunikasi pengguna terhadap layanan OpenStack dan antara layanan OpenStack itu sendiri.

Karena kerentanan yang dipublikasikan dalam protokol Secure Sockets Layer (SSL), kami sangat menyarankan agar TLS digunakan untuk preferensi SSL, dan SSL dinonaktifkan dalam semua kasus, kecuali kompatibilitas dengan browser usang atau perpustakaan diperlukan.

Public Key Infrastructure (PKI) adalah kerangka kerja untuk mengamankan komunikasi dalam jaringan. Ini terdiri dari seperangkat sistem dan proses untuk memastikan lalu lintas dapat dikirim dengan aman sambil memvalidasi identitas para pihak. Profil PKI yang dijelaskan di sini adalah Internet Engineering Task Force (IETF) profil Public Key Infrastructure (PKIX) yang dikembangkan oleh kelompok kerja PKIX. Komponen inti PKI adalah:

Digital Certificates

Sertifikat kunci publik yang masuk adalah struktur data yang memiliki data yang dapat diverifikasi dari suatu entitas, kunci publiknya beserta beberapa atribut lainnya. Sertifikat ini dikeluarkan oleh Certificate Authority (CA). Karena sertifikat ditandatangani oleh CA yang dipercaya, setelah diverifikasi, kunci publik yang terkait dengan entitas dijamin terkait dengan entitas tersebut. Standar yang paling umum digunakan untuk mendefinisikan sertifikat ini adalah : erm: X.509 standard. The :term: X.509 v3 yang merupakan standar saat ini dijelaskan secara rinci di `RFC5280 <http://tools.ietf.org/html/5280> `_. Sertifikat dikeluarkan oleh CA sebagai mekanisme untuk membuktikan identitas entitas online. CA secara digital menandatangani sertifikat dengan membuat pesan yang dicerna dari sertifikat dan mengenkripsi mencerna dengan kunci privatnya.

End entity

Pengguna, proses, atau sistem yang menjadi subjek sertifikat. Entitas akhir mengirimkan permintaan sertifikasinya ke Registration Authority (RA) untuk mendapatkan persetujuan. Jika disetujui, RA meneruskan permintaan ke Certification Authority (CA). Certification Authority memverifikasi permintaan dan jika informasinya benar, sertifikat dibuat dan ditandatangani. Sertifikat yang ditandatangani ini kemudian dikirim ke Certificate Repository.

Relying party

Endpoint yang menerima sertifikat yang ditandatangani secara digital yang dapat diverifikasi dengan mengacu pada kunci publik yang tercantum pada sertifikat. Pihak yang mengandalkan harus berada dalam posisi untuk memverifikasi sertifikat atas rantai tersebut, memastikan bahwa hal itu tidak ada dalam CRL dan juga harus dapat memverifikasi tanggal kadaluarsa sertifikat.

Certification Authority (CA)

CA adalah entitas terpercaya, baik oleh end party maupun party yang bergantung pada sertifikat untuk kebijakan sertifikasi, penanganan manajemen, dan penerbitan sertifikat.

Registration Authority (RA)

Sistem opsional dimana CA mendelegasikan fungsi manajemen tertentu, ini mencakup fungsi seperti, otentikasi entitas akhir sebelum dikeluarkan sertifikat oleh CA.

Certificate Revocation Lists (CRL)

Certificate Revocation List (CRL) adalah daftar nomor seri sertifikat yang telah dicabut. Entitas akhir yang mempresentasikan sertifikat ini tidak boleh dipercaya dalam model PKI. Pencabutan bisa terjadi karena beberapa alasan misalnya, kompromi kunci, kompromi CA.

CRL issuer

Sistem opsional dimana CA mendelegasikan publikasi daftar pencabutan sertifikat.

Certificate Repository

Dimana sertifikat entitas akhir dan daftar pencabutan sertifikat disimpan dan diperbaiki (looked up) - kadang-kadang disebut sebagai certificate bundle.

PKI membangun kerangka kerja untuk menyediakan algoritma enkripsi, mode cipher, dan protokol untuk mengamankan data dan otentikasi. Kami sangat menyarankan untuk mengamankan semua layanan dengan Public Key Infrastructure (PKI), termasuk penggunaan TLS untuk API endpoint. Tidak mungkin untuk enkripsi atau penandatanganan transport atau pesan saja untuk menyelesaikan semua masalah ini. Host sendiri harus aman dan menerapkan kebijakan, ruang nama, dan kontrol lainnya untuk melindungi kredensial dan kunci pribadi mereka. Namun, tantangan pengelolaan dan perlindungan utama tidak mengurangi perlunya pengendalian ini, atau mengurangi kepentingan mereka.

Otoritas sertifikasi

Banyak organisasi memiliki Public Key Infrastructure yang mapan dengan Certification Authority (CA) mereka sendiri, kebijakan sertifikat, dan manajemen yang harus mereka gunakan untuk menerbitkan sertifikat untuk pengguna atau layanan OpenStack internal. Organisasi di mana domain keamanan publik yang dihadapi Internet juga memerlukan sertifikat yang ditandatangani oleh CA publik yang diakui secara luas. Untuk komunikasi kriptografi melalui jaringan manajemen, disarankan agar tidak menggunakan CA publik. Sebagai gantinya, kami mengharapkan dan merekomendasikan sebagian besar penerapan menggunakan CA internal mereka sendiri.

Dianjurkan agar arsitek awan OpenStack mempertimbangkan untuk menggunakan penerapan PKI terpisah untuk sistem internal dan layanan yang dihadapi pelanggan. Hal ini memungkinkan deployer awan untuk mengendalikan infrastruktur PKI mereka dan antara lain membuat permintaan, penandatanganan dan penggelaran sertifikat untuk sistem internal menjadi lebih mudah. Konfigurasi lanjutan dapat menggunakan penerapan PKI yang terpisah untuk domain keamanan yang berbeda. Hal ini memungkinkan deployer untuk menjaga pemisahan kriptografi lingkungan, memastikan bahwa sertifikat yang dikeluarkan untuk satu tidak dikenali pihak lain.

Sertifikat yang digunakan untuk mendukung TLS di internet yang menghadapi endpoint awan (atau antarmuka pelanggan yang tidak diharapkan pelanggannya telah menginstal apa pun selain kumpulan berkas sistem operasi standar yang disediakan) harus disediakan menggunakan Certificate Authorities yang terpasang dalam berkas sertifikat sistem operasi. Vendor terkenal yang terkenal termasuk Let's Encrypt, Verisign dan Thawte tapi ada banyak lainnya.

Ada tantangan manajemen, kebijakan, dan teknis seputar pembuatan dan penandatanganan sertifikat. Ini adalah area dimana arsitek awan atau operator mungkin ingin mencari saran dari pemimpin industri dan vendor disamping panduan yang direkomendasikan di sini.

Perpustakaan TLS

Komponen, layanan, dan aplikasi dalam ekosistem OpenStack atau dependensi OpenStack diimplementasikan atau dapat dikonfigurasi untuk menggunakan perpustakaan TLS. Layanan TLS dan HTTP dalam OpenStack biasanya diimplementasikan dengan menggunakan OpenSSL yang memiliki modul yang telah divalidasi untuk FIPS 140-2. Namun, perlu diingat bahwa setiap aplikasi atau layanan masih dapat mengenalkan kelemahan dalam bagaimana mereka menggunakan perpustakaan OpenSSL.

Algoritma kriptografi, mode cipher, dan protokol

Kami menyarankan minimum TLS 1.2 digunakan. Versi lama seperti TLS 1.0, 1.1, dan semua versi SSL (pendahulu TLS) rentan terhadap beberapa serangan yang diketahui publik dan karenanya tidak boleh digunakan. TLS 1.2 dapat digunakan untuk kompatibilitas klien yang luas, namun berhati-hatilah saat mengaktifkan protokol ini. Hanya aktifkan TLS versi 1.1 jika ada persyaratan kompatibilitas wajib dan Anda mengetahui risiko yang terlibat.

Bila Anda menggunakan TLS 1.2 dan mengendalikan klien dan server, suite cipher harus dibatasi pada ECDHE-ECDSA-AES256-GCM-SHA384. Dalam keadaan di mana Anda tidak mengendalikan kedua endpoint dan menggunakan TLS 1.1 atau 1.2, HIGH:!aNULL:!eNULL:!DES:!3DES:!SSLv3:!TLSv1:!CAMELLIA yang lebih umm adalah pilihan cipher yang masuk akal. .

Namun, karena buku ini tidak bermaksud menjadi referensi menyeluruh tentang kriptografi, kami tidak ingin menjadi preskriptif tentang algoritma atau mode cipher tertentu yang harus Anda aktifkan atau nonaktifkan di layanan OpenStack Anda. Ada beberapa referensi terpercaya yang ingin kami rekomendasikan untuk informasi lebih lanjut:

• National Security Agency, Suite B Cryptography

• OWASP Guide to Cryptography

• OWASP Transport Layer Protection Cheat Sheet

• SoK: SSL and HTTPS: Revisiting past challenges and evaluating certificate trust model enhancements

• The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software

• OpenSSL and FIPS 140-2

Ringkasan

Mengingat kompleksitas komponen OpenStack dan jumlah kemungkinan penyebaran, Anda harus berhati-hati untuk memastikan bahwa setiap komponen mendapatkan konfigurasi TLS certificates, keys, and CAs yang sesuai. Bagian selanjutnya membahas layanan berikut:

• Compute API endpoints

• Identity API endpoints

• Networking API endpoints

• Storage API endpoints

• Server Messaging

• Server Database

• Dasbor