Container Linux vs. VM: Perbandingan keamanan

Pengembang menyukai kontainer. Mereka mudah digunakan dan cepat dimulai. Anda dapat menjalankan banyak dari mereka bahkan pada perangkat keras sederhana. Overhead startup selalu menjadi kutukan bagi pengembangan dan pengujian, dan overhead ini hanya meningkat dengan arsitektur layanan mikro. Jika pengembang membutuhkan setengah lusin layanan, dia mungkin dengan mudah menghabiskan satu atau dua hari dengan penyiapan - mengonfigurasi perangkat keras, menjalankan penginstal, melawan ketidakcocokan.

Dengan container, yang menciut menjadi beberapa menit atau detik dan dapat dijalankan di satu workstation pengembangan. Repositori gambar container yang bermanfaat dan tersedia menggandakan produktivitas developer, seperti halnya open source, tetapi tanpa kesulitan melakukan build. Tim operasi lebih lambat dalam mengadopsi kontainer. Salah satu alasannya adalah banyak aplikasi yang harus mereka dukung belum dimasukkan ke dalam container. Alasan lainnya adalah keengganan untuk menjauh dari VM.

Untuk operasi, peralihan dari bare metal ke VM adalah hal yang wajar. VM individual terlihat dan dapat dikelola seperti sistem individual, menggunakan alat dan proses yang sama. Kekhawatiran awal tentang keamanan VM diredakan oleh sejarah produksi VM yang panjang di dunia mainframe, oleh kemampuan untuk menerapkan kontrol yang sama seperti yang digunakan untuk sistem bare-metal, dengan dukungan virtualisasi perangkat keras, dan oleh kematangan yang berkembang dari alat manajemen VM.

Banyak kekhawatiran awal tentang keamanan bermuara pada satu pertanyaan: Apakah VM seaman logam biasa? Sekarang pertanyaan serupa muncul tentang kontainer. Seberapa aman container, dan bagaimana perbandingannya dengan VM? Tentunya jika kita membandingkan layanan yang berjalan dalam penampung dengan layanan yang sama yang berjalan sebagai proses terpisah pada sistem yang sama, versi penampung lebih aman. Pemisahan yang disediakan oleh namespace Linux dan cgroups memberikan batasan yang tidak ada antara proses biasa. Perbandingan dengan VM kurang jelas. Mari kita lihat VM dan container dari perspektif keamanan.

Dalam artikel ini, saya akan mengambil dua pendekatan berbeda untuk membandingkan VM dan keamanan kontainer. Pendekatan pertama akan lebih struktural, atau teoritis, melihat karakteristik masing-masing dari perspektif keamanan. Kemudian saya akan menerapkan analisis yang lebih praktis dengan melihat apa yang terjadi dalam pelanggaran tipikal dan bagaimana hal itu dapat dipengaruhi oleh arsitektur container dan VM.

Tampilan struktural

Untuk pendekatan struktural saya akan membandingkan permukaan serangan kedua sistem. Permukaan serangan mewakili jumlah titik di mana sistem dapat diserang. Ini tidak didefinisikan secara tepat (sebagai angka, misalnya) tetapi berguna untuk perbandingan. Bagi pencuri, rumah dengan 10 pintu memiliki permukaan serang yang lebih besar daripada rumah dengan satu pintu, meskipun pintunya sama. Satu pintu mungkin dibiarkan tidak terkunci; satu kunci mungkin rusak; pintu di lokasi yang berbeda mungkin menawarkan privasi lebih bagi penyusup, dan seterusnya.

Dalam sistem komputer, permukaan serangan mencakup segala sesuatu di mana penyerang (atau perangkat lunak yang bertindak atas namanya) dapat "menyentuh" ​​sistem target. Antarmuka jaringan, koneksi perangkat keras, dan sumber daya bersama semuanya merupakan titik serangan yang memungkinkan. Perhatikan bahwa permukaan serangan tidak menyiratkan bahwa ada kerentanan yang sebenarnya. Kesepuluh pintu mungkin benar-benar aman. Tetapi permukaan serangan yang lebih besar berarti lebih banyak tempat untuk dilindungi dan semakin besar kemungkinan penyerang akan menemukan kelemahan setidaknya di satu tempat.

Total permukaan serangan tergantung pada jumlah titik sentuh yang berbeda dan kompleksitas masing-masing. Mari kita lihat contoh sederhana. Bayangkan sistem kuno yang menyajikan kutipan pasar saham. Ini memiliki antarmuka tunggal, garis serial sederhana. Protokol pada baris itu juga sederhana: Simbol stok dengan panjang tetap, misalnya lima karakter, dikirim ke server, yang merespons dengan kutipan harga panjang tetap - katakanlah, 10 karakter. Tidak ada Ethernet, TCP / IP, HTTP, dan sebagainya. (Saya benar-benar bekerja pada sistem seperti itu dahulu kala di galaksi yang sangat jauh.)

Permukaan serangan sistem ini sangat kecil. Penyerang dapat memanipulasi karakteristik listrik dari jalur serial, mengirim simbol yang salah, mengirim terlalu banyak data, atau mengubah protokol. Melindungi sistem akan melibatkan penerapan kontrol yang sesuai terhadap serangan tersebut.

Sekarang bayangkan layanan yang sama, tetapi dalam arsitektur modern. Layanan ini tersedia di Internet dan menampilkan RESTful API. Sisi listrik dari serangan itu hilang - yang akan dilakukan hanyalah menggoreng router atau sakelar penyerang. Tetapi protokolnya jauh lebih kompleks. Ini memiliki lapisan untuk IP, TCP, mungkin TLS, dan HTTP, masing-masing menawarkan kemungkinan kerentanan yang dapat dieksploitasi. Sistem modern memiliki permukaan serangan yang jauh lebih besar, meskipun bagi penyerang masih terlihat seperti titik antarmuka tunggal.

Permukaan serangan bare-metal

Untuk penyerang yang tidak secara fisik ada di pusat data, permukaan serangan awal adalah jaringan ke server. Hal ini menyebabkan "tampilan perimeter" keamanan: Lindungi titik masuk ke pusat data dan tidak ada yang masuk. Jika penyerang tidak bisa masuk, tidak masalah apa yang terjadi di antara sistem di dalam. Ini bekerja dengan baik ketika antarmuka perimeter sederhana (pikirkan dial-up), tetapi menumbuhkan kelemahan pada antarmuka internal. Penyerang yang menemukan lubang di perimeter sering kali menemukan bahwa permukaan serangan internal dari server farm jauh lebih besar daripada yang eksternal, dan mereka dapat melakukan kerusakan yang cukup besar saat berada di dalam.

Permukaan serangan internal ini termasuk koneksi jaringan antar server tetapi juga interaksi proses-ke-proses dalam satu server. Lebih buruk lagi, karena banyak layanan berjalan dengan hak istimewa yang ditinggikan (pengguna "root"), berhasil membobolnya secara efektif berarti akses tak terbatas ke hal lain di sistem itu, tanpa harus mencari kerentanan tambahan. Seluruh industri tumbuh untuk melindungi server - firewall, antimalware, deteksi intrusi, dan seterusnya - dengan hasil yang kurang sempurna.

Ada juga serangan "saluran samping" yang menarik terhadap server. Para peneliti telah menunjukkan contoh penggunaan konsumsi daya, kebisingan, atau radiasi elektromagnetik dari komputer untuk mengekstrak informasi, terkadang data yang sangat sensitif seperti kunci kriptografi. Serangan lain telah memanfaatkan antarmuka yang terbuka seperti protokol keyboard nirkabel. Secara umum, bagaimanapun, serangan ini lebih sulit - mereka mungkin memerlukan kedekatan dengan server, misalnya - jadi jalur utama untuk "down the wire" lebih umum.

Permukaan serangan VM

Jika VM digunakan dengan cara yang sama seperti bare metal, tanpa perbedaan dalam arsitektur aplikasi (seperti yang sering terjadi), VM berbagi sebagian besar titik serangan yang sama. Satu permukaan serangan tambahan adalah potensi kegagalan di hypervisor, OS, atau perangkat keras untuk mengisolasi sumber daya dengan benar di antara VM, memungkinkan VM entah bagaimana membaca memori VM lain. Antarmuka antara VM dan hypervisor juga mewakili titik serangan. Jika VM dapat menerobos dan menjalankan kode arbitrer di hypervisor, VM tersebut dapat mengakses VM lain di sistem yang sama. Hypervisor itu sendiri merupakan titik serangan karena memperlihatkan antarmuka manajemen.

Ada titik serangan tambahan tergantung pada jenis sistem VM. Sistem VM tipe 2 menggunakan hypervisor yang dijalankan sebagai proses pada OS host yang mendasarinya. Sistem ini dapat diserang dengan menyerang OS host. Jika penyerang bisa mendapatkan kode yang berjalan di sistem host, dia berpotensi mempengaruhi hypervisor dan VM, terutama jika dia bisa mendapatkan akses sebagai pengguna yang memiliki hak istimewa. Kehadiran seluruh OS, termasuk utilitas, alat manajemen, dan mungkin layanan lain serta titik masuk (seperti SSH) memberikan sejumlah kemungkinan titik serangan. Sistem VM tipe 1, di mana hypervisor berjalan langsung pada perangkat keras yang mendasarinya, menghilangkan titik masuk ini dan karenanya memiliki permukaan serangan yang lebih kecil.

Permukaan serangan kontainer

Seperti halnya VM, container berbagi titik serangan masuk jaringan fundamental dari sistem bare-metal. Selain itu, seperti mesin virtual Tipe 2, sistem kontainer yang menggunakan OS host yang "terisi penuh" tunduk pada semua serangan yang sama yang tersedia terhadap utilitas dan layanan OS host tersebut. Jika penyerang dapat memperoleh akses ke host tersebut, ia dapat mencoba mengakses atau memengaruhi container yang sedang berjalan. Jika dia mendapat akses istimewa ("root"), penyerang akan dapat mengakses atau mengontrol container apa pun. OS "minimalis" (seperti Apcera's KurmaOS) dapat membantu mengurangi permukaan serangan ini tetapi tidak dapat menghilangkannya sepenuhnya, karena beberapa akses ke OS host diperlukan untuk pengelolaan kontainer.

Mekanisme dasar pemisahan wadah (ruang nama) juga menawarkan titik serangan potensial. Selain itu, tidak semua aspek proses pada sistem Linux memiliki namespace, jadi beberapa item dibagikan di seluruh container. Ini adalah area alami bagi penyerang untuk diselidiki. Akhirnya, proses ke antarmuka kernel (untuk panggilan sistem) berukuran besar dan diekspos di setiap penampung, berlawanan dengan antarmuka yang jauh lebih kecil antara VM dan hypervisor. Kerentanan dalam panggilan sistem dapat menawarkan akses potensial ke kernel. Salah satu contohnya adalah kerentanan yang baru-baru ini dilaporkan pada key ring Linux.

Pertimbangan arsitektur

Untuk VM dan container, ukuran permukaan serangan dapat dipengaruhi oleh arsitektur aplikasi dan cara penggunaan teknologi.

Banyak aplikasi VM lama memperlakukan VM seperti logam biasa. Dengan kata lain, mereka belum mengadaptasi arsitekturnya secara khusus untuk VM atau untuk model keamanan yang tidak didasarkan pada keamanan perimeter. Mereka mungkin menginstal banyak layanan pada VM yang sama, menjalankan layanan dengan hak akses root, dan memiliki sedikit atau tidak ada kontrol keamanan antar layanan. Merancang ulang aplikasi ini (atau lebih mungkin menggantinya dengan yang lebih baru) mungkin menggunakan VM untuk menyediakan pemisahan keamanan antara unit fungsional, bukan hanya sebagai sarana untuk mengelola mesin dalam jumlah yang lebih besar.

Penampung sangat cocok untuk arsitektur layanan mikro yang "menyatukan" sejumlah besar layanan (biasanya) kecil menggunakan API standar. Layanan semacam itu sering kali memiliki masa hidup yang sangat singkat, di mana layanan dalam peti kemas dimulai sesuai permintaan, menanggapi permintaan, dan dihancurkan, atau di mana layanan dengan cepat naik dan turun berdasarkan permintaan. Pola penggunaan itu bergantung pada instansiasi cepat yang didukung container. Dari perspektif keamanan, hal ini memiliki kelebihan dan kekurangan.

Jumlah layanan yang lebih besar berarti semakin banyak jumlah antarmuka jaringan dan karenanya permukaan serangan yang lebih besar. Namun, ini juga memungkinkan lebih banyak kontrol di lapisan jaringan. Misalnya, di Apcera Platform, semua traffic container-to-container harus diizinkan secara eksplisit. Penampung penipu tidak dapat menjangkau titik akhir jaringan apa pun secara sewenang-wenang.

Umur kontainer yang pendek berarti bahwa jika penyerang berhasil masuk, waktu yang harus dilakukannya untuk melakukan sesuatu akan dibatasi, berlawanan dengan jendela peluang yang disajikan oleh layanan yang berjalan lama. Sisi negatifnya adalah forensik lebih sulit. Setelah wadah hilang, itu tidak dapat diselidiki dan diperiksa untuk menemukan malware. Arsitektur ini juga mempersulit penyerang untuk menginstal malware yang bertahan setelah penghancuran kontainer, seperti yang mungkin terjadi pada bare metal dengan menginstal driver yang memuat saat boot. Container biasanya dimuat dari repositori terpercaya, read-only, dan dapat diamankan lebih jauh dengan pemeriksaan kriptografi.

Sekarang mari kita pertimbangkan apa yang terjadi selama pelanggaran.

Perlindungan terhadap pelanggaran

Penyerang biasanya memiliki satu atau dua tujuan dalam membobol sistem server. Mereka ingin mendapatkan data atau melakukan kerusakan.

Jika mereka mengejar data, mereka ingin menyusup ke sebanyak mungkin sistem, dengan hak istimewa setinggi mungkin, dan mempertahankan akses itu selama mungkin. Mencapai ini memberi mereka waktu untuk menemukan data, yang mungkin sudah ada di sana - database yang tidak diamankan dengan baik, misalnya - atau mungkin memerlukan pengumpulan yang lambat dari waktu ke waktu saat menetes masuk, seperti mengumpulkan transaksi saat mereka masuk dari pengguna. Mempertahankan akses untuk waktu yang lama membutuhkan stealth. Serangan itu juga membutuhkan cara untuk mengeluarkan data.

Jika penyerang hanya mencoba untuk melakukan kerusakan, tujuannya lagi adalah untuk mengakses sebanyak mungkin sistem dan hak istimewa. Tetapi ada tindakan penyeimbang: Setelah kerusakan dimulai, kemungkinan akan diketahui, tetapi semakin lama penyerang menunggu untuk memulai (sementara malware memfilter dari sistem ke sistem), semakin besar kemungkinan untuk terdeteksi. Mendapatkan data kurang penting daripada kontrol terkoordinasi dari malware. Idenya adalah menginfeksi sebanyak mungkin sistem, kemudian merusaknya pada titik yang disinkronkan, baik yang telah diatur sebelumnya atau sesuai perintah.

Pelanggaran melibatkan sejumlah elemen. Mari kita lihat masing-masing dan lihat apakah VM dan arsitektur dalam container dapat memengaruhi permukaan serangan untuk masing-masing.