Layanan Security untuk instance¶

Entropy ke instance¶

Kami mempertimbangkan entropi untuk mengacu pada kualitas dan sumber data acak yang tersedia untuk sebuah instance. Teknologi kriptografi biasanya sangat bergantung pada keacakan, membutuhkan kolam entropi berkualitas tinggi untuk menariknya. Biasanya sulit bagi mesin virtual untuk mendapatkan entropi yang cukup untuk mendukung operasi ini, yang disebut sebagai entropy starvation. Kelainan entropi dapat bermanifestasi dalam instance sebagai sesuatu yang tampaknya tidak terkait. Misalnya, waktu boot yang lambat mungkin disebabkan oleh instance menunggu generasi kunci ssh. Entropy starvation juga dapat memotivasi pengguna untuk menggunakan sumber entropi berkualitas buruk dari dalam instance, membuat aplikasi berjalan di awan kurang aman secara keseluruhan.

Untungnya, seorang arsitek awan dapat mengatasi masalah ini dengan menyediakan sumber entropi berkualitas tinggi ke awan. Hal ini dapat dilakukan dengan memiliki cukup banyak hardware random number generator (HRNG) di awan untuk mendukung kejadian tersebut. Dalam hal ini, "enough" agak spesifik domain. Untuk operasi sehari-hari, HRNG modern kemungkinan menghasilkan entropi yang cukup untuk menopang 50-100 node. HRNG dengan bandwidth tinggi, seperti instruksi RdRand yang tersedia dengan Intel Ivy Bridge dan prosesor yang lebih baru berpotensi menangani lebih banyak node. Untuk awan yang ada, seorang arsitek perlu memahami persyaratan aplikasi untuk memastikan entropi yang memadai tersedia.

Virtio RNG adalah generator bilangan acak yang menggunakan /dev/random sebagai sumber entropi secara default, namun dapat dikonfigurasi untuk menggunakan perangkat keras RNG atau alat seperti entropy gathering daemon (EGD) untuk menyediakan cara mendistribusikan distribusi entropi secara adil dan aman melalui sistem terdistribusi. Virtio RNG diaktifkan menggunakan properti hw_rng dari metadata yang digunakan untuk membuat instance.

Penjadwalan instance ke node¶

Sebelum sebuah instance dibuat, host untuk image instantiation harus dipilih. Pilihan ini dilakukan oleh nova-scheduler yang menentukan bagaimana mengirim dan menghitung permintaan volume.

The FilterScheduler adalah penjadwal default untuk OpenStack Compute, meskipun penjadwal lain ada (lihat bagian Scheduling dalam OpenStack Configuration Reference ). Ini bekerja sama dengan 'filter hints' untuk memutuskan di mana instance harus dimulai. Proses pemilihan host ini memungkinkan administrator untuk memenuhi berbagai persyaratan keamanan dan kepatuhan. Bergantung pada jenis penyebaran cloud misalnya, seseorang dapat memilih untuk memiliki instance penyewa yang berada di host yang sama bila memungkinkan jika isolasi data menjadi perhatian utama. Sebaliknya seseorang dapat mencoba untuk memiliki instance untuk penyewa tinggal di sebanyak mungkin host yang berbeda untuk ketersediaan atau toleransi kesalahan (fault tolerance reason)..

Penjadwal filter termasuk dalam empat kategori utama:

Filter berbasis sumber daya: Filter ini akan membuat sebuah instance berdasarkan utilisasi dari set host hypervisor dan dapat memicu pada properti bebas atau bekas seperti utilisasi RAM, IO, atau CPU.
Filter berbasis image: Hal ini mendelegasikan pembuatan instance berdasarkan image yang digunakan, seperti sistem operasi VM atau jenis image yang digunakan.
Filter berbasis lingkungan: Filter ini akan membuat sebuah instance berdasarkan rincian eksternal seperti pada kisaran IP tertentu, di seluruh zona ketersediaan, atau pada host yang sama seperti instance lainnya.
Kriteria khusus: Filter ini akan mendelegasikan pembuatan instance berdasarkan kriteria yang diberikan pengguna atau administrator seperti penguraian atau parsing metadata.

Beberapa filter dapat diterapkan sekaligus, seperti filter ServerGroupAffinity untuk memastikan sebuah instance dibuat pada anggota host tertentu dan filter ServerGroupAntiAffinity` untuk memastikan bahwa instance yang sama tidak dibuat pada set host spesifik yang lain. Filter ini harus dianalisis dengan seksama untuk memastikan mereka tidak saling bertentangan dan menghasilkan peraturan yang mencegah pembuatan instance.

Filter GroupAffinity dan GroupAntiAffinity terjadi konflik dan seharusnya keduanya tidak diaktifkan secara bersamaan.

Filter DiskFilter mampu melampaui batas ruang disk. Meskipun biasanya tidak menjadi masalah, ini bisa menjadi perhatian pada perangkat penyimpanan yang tersedia secara tipis, dan filter ini harus digunakan dengan kuota yang teruji dengan baik.

Sebaiknya Anda menonaktifkan filter yang mengurai hal-hal yang disediakan oleh pengguna atau dapat dimanipulasi seperti metadata.

Images tepercaya¶

Di lingkungan awan, pengguna bekerja dengan image atau image pra-instal yang mereka upload sendiri. Dalam kedua kasus tersebut, pengguna harus dapat memastikan image yang mereka gunakan belum dirusak. Kemampuan untuk memverifikasi image adalah keharusan mendasar untuk keamanan. Sebuah rantai kepercayaan dibutuhkan dari sumber image ke tempat tujuan penggunaannya. Hal ini dapat dilakukan dengan menandatangani image yang diperoleh dari sumber terpercaya dan dengan memverifikasi tanda tangan sebelum digunakan. Berbagai cara untuk mendapatkan dan membuat image terverifikasi akan dibahas di bawah ini, disusul dengan deskripsi fitur verifikasi tanda tangan image.

Proses pembuatan image¶

OpenStack Documentation memberikan panduan bagaimana membuat dan mengunggah image ke layanan Image. Selain itu diasumsikan bahwa Anda memiliki proses di mana Anda menginstal dan mengeras sistem operasi. Dengan demikian, item berikut akan memberikan panduan tambahan tentang bagaimana memastikan image Anda ditransfer dengan aman ke dalam OpenStack. Ada berbagai pilihan untuk mendapatkan image. Masing-masing memiliki langkah-langkah khusus yang membantu memvalidasi asalnya image.

Pilihan pertama adalah untuk mendapatkan media boot dari sumber terpercaya.

$ mkdir -p /tmp/download_directorycd /tmp/download_directory
$ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/ubuntu-12.04.2-server-amd64.iso
$ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS
$ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS.gpg
$ gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451
$ gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2>&1 | grep OK

Pilihan kedua adalah menggunakan OpenStack Virtual Machine Image Guide. Dalam kasus ini, Anda akan ingin mengikuti panduan pengarahan OS organisasi Anda atau yang disediakan oleh pihak ketiga yang tepercaya seperti Linux STIGs.

Pilihan terakhir adalah menggunakan pembangun image otomatis. Contoh berikut menggunakan pembangun image Oz. Komunitas OpenStack baru-baru ini menciptakan alat baru yang layak untuk penyeledikan: disk-image-builder. Kami belum mengevaluasi alat ini dari perspektif keamanan.

Contoh RHEL 6 CCE-26976-1 yang akan membantu mengimplementasikan NIST 800-53 Section * AC-19 (d) * di Oz.

<template>
<name>centos64</name>
<os>
  <name>RHEL-6</name>
  <version>4</version>
  <arch>x86_64</arch>
  <install type='iso'>
  <iso>http://trusted_local_iso_mirror/isos/x86_64/RHEL-6.4-x86_64-bin-DVD1.iso</iso>
  </install>
  <rootpw>CHANGE THIS TO YOUR ROOT PASSWORD</rootpw>
</os>
<description>RHEL 6.4 x86_64</description>
<repositories>
  <repository name='epel-6'>
  <url>http://download.fedoraproject.org/pub/epel/6/$basearch</url>
  <signed>no</signed>
  </repository>
</repositories>
<packages>
  <package name='epel-release'/>
  <package name='cloud-utils'/>
  <package name='cloud-init'/>
</packages>
<commands>
  <command name='update'>
  yum update
  yum clean all
  rm -rf /var/log/yum
  sed -i '/^HWADDR/d' /etc/sysconfig/network-scripts/ifcfg-eth0
  echo -n > /etc/udev/rules.d/70-persistent-net.rules
  echo -n > /lib/udev/rules.d/75-persistent-net-generator.rules
  chkconfig --level 0123456 autofs off
  service autofs stop
  </command>
</commands>
</template>

Dianjurkan untuk menghindari proses pembuatan image manual karena kompleks dan rentan terhadap kesalahan. Selain itu, dengan menggunakan sistem otomatis seperti Oz untuk pembuatan image atau utilitas pengelolaan konfigurasi seperti Chef atau Puppet untuk pengerasan image post-boot memberi Anda kemampuan untuk menghasilkan image yang konsisten serta melacak kepatuhan image dasar Anda untuk masing-masing panduan pengerasan dari waktu ke waktu.

Jika berlangganan layanan awan publik, Anda harus memeriksa dengan penyedia awan untuk garis besar (outline) proses yang digunakan untuk menghasilkan image default mereka. Jika penyedia memungkinkan Anda untuk mengunggah image Anda sendiri, Anda akan ingin memastikan bahwa Anda dapat memverifikasi bahwa image Anda tidak dimodifikasi sebelum menggunakannya untuk membuat sebuah instance. Untuk melakukan ini, lihat bagian berikut pada Image Signature Verification, atau paragraf berikut jika tanda tangan tidak dapat digunakan.

Image berasal dari layanan Image ke layanan Compute pada sebuah simpul. Transfer ini harus dilindungi dengan menjalankan lebih dari TLS. Begitu image ada di simpul, maka diverifikasi dengan checksum dasar dan kemudian disk diperluas berdasarkan ukuran instance yang diluncurkan. Jika, di lain waktu, image yang sama diluncurkan dengan ukuran instance yang sama pada simpul ini, diluncurkan dari image yang sama. Karena image yang diperluas ini tidak diverifikasi ulang secara default sebelum diluncurkan, mungkin saja telah mengalami gangguan. Pengguna tidak akan menyadari adanya gangguan, kecuali jika dilakukan pemeriksaan manual terhadap file yang dihasilkan pada image yang dihasilkan.

Verifikasi tanda tangan (signature) image¶

Beberapa fitur yang terkait dengan penandatanganan image sekarang tersedia di OpenStack. Pada rilis Mitaka, layanan Image dapat memverifikasi image yang ditandatangani ini, dan, untuk menyediakan rantai kepercayaan penuh, layanan Compute memiliki opsi untuk melakukan verifikasi tanda tangan image sebelum melakukan booting image. Validasi tanda tangan yang berhasil sebelum boot image memastikan image yang ditandatangani tidak berubah. Dengan fitur ini diaktifkan, modifikasi image yang tidak sah (mis., memodifikasi image untuk menyertakan perangkat lunak perusak atau rootkit) dapat terdeteksi.

Administrator dapat mengaktifkan verifikasi instance signature dengan mengatur flag verify_glance_signatures ke True dalam file /etc/nova/nova.conf. Saat diaktifkan, layanan Compute secara otomatis memvalidasi instance yang ditandatangani ketika diambil dari layanan Image. Jika verifikasi ini gagal, boot tidak akan terjadi. OpenStack Operations Guide memberikan panduan tentang cara membuat dan mengunggah image yang ditandatangani, dan cara menggunakan fitur ini. Untuk informasi lebih lanjut, lihat`Adding Signed Images <https://docs.openstack.org/operations-guide/ops-user-facing-operations.html#adding-signed-images>`_ di Operations Guide.

Migrasi instance¶

OpenStack dan lapisan virtualisasi yang mendasari menyediakan migrasi langsung image antara node OpenStack, yang memungkinkan Anda melakukan upgrade rolling node OpenStack tanpa downtime tanpa batas. Namun, migrasi langsung juga membawa risiko signifikan. Untuk memahami risiko yang terlibat, berikut adalah langkah tingkat tinggi yang dilakukan selama migrasi langsung:

Start instance di host tujuan
Transfer memori
Hentikan guest and sync disk
Transfer status
Start guest

Resiko migrasi langsung (live).¶

Pada berbagai tahap proses migrasi langsung, isi instance menjalankan memori dan disk waktu dikirimkan melalui jaringan dalam teks biasa. Dengan demikian ada beberapa risiko yang perlu diperhatikan saat menggunakan migrasi langsung. Berikut daftar lengkap rincian beberapa dari risiko ini:

Denial of Service (DoS): Jika sesuatu gagal selama proses migrasi, instance bisa hilang.
Data exposure: Transfer memori atau disk harus ditangani dengan aman.
Data manipulation: Jika transfer memori atau disk tidak ditangani dengan aman, maka penyerang dapat memanipulasi data pengguna selama migrasi berlangsung.
Code injection: Jika transfer memori atau disk tidak ditangani dengan aman, maka penyerang dapat memanipulasi file executable, baik pada disk atau memori selama migrasi berlangsung.

Keterbatasan migrasi langsung¶

Ada beberapa metode untuk mengurangi beberapa risiko yang terkait dengan migrasi langsung, beberapa rincian berikut ini:

Nonaktifkan migrasi langsung
Jaringan migrasi terisolasi
Migrasi langsung terenkripsi

Nonaktifkan migrasi langsung¶

Pada saat ini, migrasi langsung diaktifkan di OpenStack secara default. Migrasi langsung dapat dinonaktifkan dengan menambahkan baris berikut ke file nova policy.json`:

{
    "compute_extension:admin_actions:migrate": "!",
    "compute_extension:admin_actions:migrateLive": "!",
}

Jaringan migrasi¶

Sebagai praktik umum, lalu lintas migrasi langsung harus dibatasi pada domain keamanan manajemen, lihat Batas dan ancaman keamanan. Dengan lalu lintas migrasi langsung, karena sifat teksnya yang biasa dan kenyataan bahwa Anda mentransfer isi disk dan memori instance yang berjalan, sebaiknya Anda memisahkan lalu lintas migrasi langsung ke jaringan dedicated. Mengisolasi lalu lintas ke jaringan dedicated dapat mengurangi risiko terkena exposure (pembukaan).

Migrasi langsung terenkripsi¶

Jika ada kasus bisnis yang memadai untuk mengaktifkan migrasi aktif, libvirtd dapat menyediakan terowongan (tunnel) terenkripsi untuk migrasi langsung. Namun, fitur ini saat ini tidak terbuka di OpenStack Dashboard atau perintah nova-client, dan hanya dapat diakses melalui konfigurasi manual libvirtd. Proses migrasi langsung kemudian berubah ke langkah tingkat tinggi berikut:

Instance data disalin dari hypervisor ke libvirt.
Terowongan terenkripsi dibuat antara proses libvirtd pada host sumber dan tujuan.
Tujuan libvirtd host menyalin instance kembali ke hypervisor yang mendasarinya.

Monitoring, peringatan, dan pelaporan¶

Sebagai mesin virtual OpenStack adalah image server yang dapat direplikasi di host, praktik terbaik dalam logging berlaku serupa antara host fisik dan virtual. Tingkat sistem operasi dan tingkat aplikasi harus dicatat, termasuk aktivitas akses ke host dan data, penambahan dan kepindahan pengguna, perubahan hak istimewa, dan lainnya seperti yang didikte oleh lingkungan. Idealnya, Anda dapat mengonfigurasi log ini untuk diekspor ke agregator log yang mengumpulkan peristiwa log, mengkorelasikannya untuk analisis, dan menyimpannya untuk referensi atau tindakan lebih lanjut. Salah satu alat yang umum dilakukan adalah ELK stack, atau Elasticsearch, Logstash, dan Kibana <https://www.elastic.co/> _.

Log ini harus ditinjau ulang pada irama reguler seperti live view oleh network operations center (NOC), atau jika lingkungannya tidak cukup besar untuk memerlukan NOC, maka log harus menjalani proses peninjauan log reguler.

Sering kali peristiwa menarik memicu peringatan yang dikirim ke penjawab untuk bertindak. Seringkali lansiran ini berbentuk email dengan pesan menarik. Peristiwa yang menarik bisa berupa kegagalan yang signifikan, atau indikator kesehatan yang diketahui tentang kegagalan yang tertunda. Dua utilitas umum untuk mengelola peringatan adalah Nagios dan Zabbix.

Pembaruan dan tambalan (patch)¶

Sebuah hypervisor menjalankan mesin virtual independen. Hypervisor ini bisa berjalan di sistem operasi atau langsung pada perangkat keras (disebut baremetal). Pembaruan hypervisor tidak disebarkan ke mesin virtual. Misalnya, jika penggelaran menggunakan XenServer dan memiliki satu set mesin virtual Debian, pembaruan ke XenServer tidak akan memperbarui apa pun yang berjalan di mesin virtual Debian.

Oleh karena itu, kami merekomendasikan agar kepemilikan mesin virtual yang jelas diberikan, dan bahwa pemiliknya bertanggung jawab atas pengerasan, penerapan, dan fungsionalitas lanjutan dari mesin virtual. Kami juga merekomendasikan bahwa pembaruan akan diterapkan pada jadwal reguler. Patch ini harus diuji di lingkungan yang menyerupai produksi semaksimal mungkin untuk memastikan stabilitas dan penyelesaian masalah di balik patch.

Firewall dan kontrol keamanan berbasis host lainnya¶

Sistem operasi yang paling umum mencakup firewall berbasis host untuk keamanan tambahan. Meskipun kami menyarankan agar mesin virtual menjalankan aplikasi sesedikit mungkin (sampai pada titik tujuan tunggal, jika mungkin), semua aplikasi yang berjalan pada mesin virtual harus diprofilkan untuk menentukan sumber daya sistem yang dibutuhkan akses aplikasi, yang terendah tingkat hak istimewa yang dibutuhkan agar bisa berjalan, dan lalu lintas lalu lintas yang diharapkan akan masuk dan masuk dari mesin virtual. Lalu lintas yang diharapkan ini harus ditambahkan ke firewall berbasis host sebagai lalu lintas yang diizinkan (atau masuk whitelisted), bersamaan dengan komunikasi logging dan manajemen yang diperlukan seperti SSH atau RDP. Semua lalu lintas lainnya harus ditolak secara eksplisit dalam konfigurasi firewall.

Pada mesin virtual Linux, profil aplikasi di atas bisa digunakan bersamaan dengan tool seperti audit2allow untuk membangun sebuah kebijakan SELinux yang selanjutnya akan melindungi informasi sistem yang sensitif pada sebagian besar distribusi Linux. SELinux menggunakan kombinasi antara pengguna, kebijakan dan konteks keamanan untuk mengelompokkan sumber daya yang dibutuhkan agar aplikasi dapat berjalan, dan melakukan segmentasi dari sumber daya sistem lain yang tidak diperlukan.

OpenStack menyediakan kelompok keamanan untuk kedua host dan jaringan untuk menambahkan pertahanan secara mendalam ke mesin virtual dalam proyek tertentu. Ini mirip dengan firewall berbasis host saat mereka mengizinkan atau menolak lalu lintas masuk berdasarkan port, protokol, dan alamat, namun peraturan kelompok keamanan hanya berlaku untuk lalu lintas masuk, sementara aturan firewall berbasis host dapat diterapkan pada masuk dan masuk lalu lintas keluar. Hal ini juga memungkinkan peraturan kelompok host dan keamanan jaringan bertentangan dan menolak lalu lintas yang sah. Sebaiknya pastikan bahwa kelompok keamanan dikonfigurasi dengan benar untuk jaringan yang sedang digunakan. Lihat :ref: networking-security-groups dalam panduan ini untuk detail lebih lanjut.

Layanan Security untuk instance