Apakah VM lebih aman daripada container?

Kami sering mengatakan, "HTTPS aman", atau "HTTP tidak aman". Tapi yang kami maksud adalah “HTTPS sulit untuk diintip dan mempersulit serangan man-in-the-middle” atau “nenek saya tidak kesulitan mengintip HTTP.”

Namun demikian, HTTPS telah diretas, dan dalam beberapa keadaan, HTTP cukup aman. Selain itu, jika saya menemukan cacat yang dapat dieksploitasi dalam implementasi umum yang mendukung HTTPS (pikirkan OpenSSL dan Heartbleed), HTTPS dapat menjadi gateway peretasan sampai implementasinya diperbaiki.

HTTP dan HTTPS adalah protokol yang ditentukan dalam IETF RFC 7230-7237 dan 2828. HTTPS dirancang sebagai HTTP yang aman, tetapi mengatakan HTTPS aman dan HTTP tidak masih menyembunyikan pengecualian penting.

Mesin virtual (VM) dan container tidak didefinisikan secara ketat, dan tidak ada yang sengaja dirancang agar lebih aman daripada yang lain. Karenanya, masalah keamanan masih lebih suram.

Mengapa saya yakin VM lebih aman daripada container

Bagilah dan taklukkan adalah strategi kemenangan dalam perang dan perangkat lunak. Ketika arsitektur membagi satu masalah keamanan yang kompleks dan sulit dipecahkan menjadi masalah yang lebih mudah, hasilnya akan, dalam banyak kasus, lebih aman daripada solusi tunggal yang menangani semua masalah.

Container adalah contoh divide-and-conquer yang diterapkan secara horizontal ke aplikasi. Dengan mengunci setiap aplikasi di jailnya sendiri, kelemahan di satu aplikasi tidak melemahkan aplikasi di container lain. VM juga membagi dan menaklukkan, tetapi mereka melangkah lebih jauh dalam isolasi.

Marvin Waschke /

Cacat dalam aplikasi yang di-jailbreak tidak dapat mempengaruhi aplikasi lain secara langsung, tetapi aplikasi yang di-jailbreak dapat merusak sistem operasi tunggal (OS) yang digunakan bersama dengan container lain dan mempengaruhi semua container. Dengan OS bersama, kekurangan di titik mana pun dalam aplikasi, wadah, dan tumpukan implementasi OS dapat membuat keamanan seluruh tumpukan tidak valid dan membahayakan mesin fisik.

+ Juga di Dunia Jaringan: Mana yang lebih murah: Kontainer atau mesin virtual? +

Arsitektur berlapis seperti virtualisasi memisahkan tumpukan eksekusi setiap aplikasi hingga ke perangkat keras, menghilangkan kemungkinan aplikasi mengganggu satu sama lain melalui OS bersama. Selain itu, antarmuka antara setiap tumpukan aplikasi dan perangkat keras ditentukan dan dibatasi untuk mencegah penyalahgunaan. Ini memberikan perimeter yang kuat tambahan untuk melindungi aplikasi dari satu sama lain.

VM memisahkan OS yang mengontrol aktivitas pengguna dari hypervisor yang mengontrol interaksi antara OS tamu dan perangkat keras. OS tamu VM mengontrol aktivitas pengguna tetapi tidak interaksi perangkat keras. Cacat dalam aplikasi atau OS tamu kemungkinan tidak akan memengaruhi perangkat keras fisik atau VM lainnya. Jika OS tamu VM dan OS yang mendukung penampung identik, yang sering terjadi, kerentanan yang sama yang akan membahayakan semua penampung lain yang berjalan di OS tidak akan membahayakan VM lain. Jadi, VM memisahkan aplikasi secara horizontal dan juga secara vertikal memisahkan OS dari perangkat keras.

Overhead VM

Keamanan ekstra VM menimbulkan biaya. Transfer kontrol selalu mahal dalam sistem komputasi, baik dalam siklus prosesor maupun sumber daya lainnya. Tumpukan eksekusi disimpan dan disetel ulang, operasi eksternal mungkin harus dijeda atau dibiarkan selesai, dan seterusnya.

Pergeseran antara OS tamu dan hypervisor memakan banyak biaya dan sering terjadi. Bahkan dengan instruksi kontrol khusus yang dibakar ke dalam chip prosesor, overhead transfer kontrol menurunkan efisiensi VM secara keseluruhan. Apakah penurunannya signifikan? Pertanyaan yang sulit. Aplikasi dapat disetel untuk mengurangi overhead dengan mengelola transfer kontrol, dan sebagian besar prosesor server sekarang dirancang untuk menyederhanakan transfer kontrol. Dengan kata lain, signifikansi bergantung pada aplikasi dan server, tetapi overhead tidak pernah dapat sepenuhnya dihilangkan, hanya dikurangi.

Kerentanan hypervisor

Untuk lebih memperumit masalah, memisahkan lapisan dalam arsitektur VM menimbulkan momok lain: kelemahan hypervisor. Pelanggaran hypervisor adalah satu titik kegagalan dengan potensi konsekuensi besar, terutama di cloud publik. Dapat dibayangkan, satu peretas dapat meluncurkan kode di VM yang mengendalikan aplikasi yang dimiliki oleh konsumen cloud publik lainnya, membuat bagian dari cloud publik dalam satu exploit.

Arsitektur yang kokoh masih dapat memiliki cacat implementasi yang melemahkan sistem secara substansial. Pelanggaran hypervisor sering kali dipalsukan dengan mengklaim bahwa pelanggaran tersebut tidak akan pernah terjadi: Menurut ceritanya, hypervisor begitu sederhana, ditulis dengan baik, dan diperiksa dengan sangat cermat sehingga tidak pernah gagal. Pelanggaran hypervisor mungkin sama menghancurkannya dengan WannaCry, tetapi jangan khawatir tentang itu. Tapi Heartbleed terjadi. Dan OpenSSL memiliki baris kode yang jauh lebih sedikit daripada hypervisor. Aku harus keluar sekarang — babi terbangku ingin lebih banyak omong kosong.

Saya tidak mengetahui adanya pelanggaran hypervisor yang signifikan hingga saat ini. Tetapi dengan melihat sekilas database Common Vulnerabilities and Exposures (CVE), peneliti menemukan kelemahan hypervisor yang dapat dieksploitasi. Pengembang hypervisor dan vendor dengan cepat menambal kerentanan saat terjadi. Pada bulan Maret 2017, Microsoft mengeluarkan Buletin Keamanan MS17-008, yang mendokumentasikan tujuh kerentanan yang ditambal di hypervisor Hyper-V-nya, semuanya ditetapkan penting atau kritis.

Saya masih yakin VM memberikan keamanan yang lebih baik daripada container, tetapi kita harus melihat keamanan sistem VM dengan mata yang jernih. Saya berencana untuk membahas kelemahan hypervisor lebih detail di masa mendatang. Selain itu, container dan VM sering digabungkan. Masih banyak yang harus dibicarakan.