Container merevolusi proses pengembangan, bertindak sebagai landasan untuk inisiatif DevOps, tetapi container membawa risiko keamanan kompleks yang tidak selalu terlihat jelas. Organisasi yang tidak mengurangi risiko ini rentan terhadap serangan.
Dalam artikel ini, kami menguraikan bagaimana container berkontribusi pada pengembangan tangkas, yang menghadirkan container risiko keamanan unik – dan apa yang dapat dilakukan organisasi untuk mengamankan beban kerja container, melampaui DevOps untuk mencapai DevSecOps.
Mengapa kontainer menangkap begitu cepat?
Wadah, dalam banyak hal, merupakan evolusi virtualisasi. Tujuannya adalah untuk mempercepat proses pengembangan, menciptakan rute yang lebih gesit dari pengembangan hingga pengujian dan implementasi – metode yang lebih ringan daripada menggunakan mesin virtual lengkap.
Inti dari masalah ini adalah kompatibilitas aplikasi, karena aplikasi memerlukan versi perpustakaan tertentu – yang dapat berbenturan dengan persyaratan aplikasi lain. Kontainer memperbaiki masalah ini dan kebetulan terhubung dengan baik dengan proses pengembangan dan infrastruktur manajemen yang mendorong proses ini.
Kontainer melakukan tugasnya dengan membawa virtualisasi ke level berikutnya. Virtualisasi mengabstraksi lapisan perangkat keras, sedangkan wadah mengabstraksi lapisan sistem operasi, pada dasarnya memvirtualisasikan peran OS. Kontainerisasi bekerja dengan mengemas aplikasi ke dalam “wadah” yang mencakup semua pustaka yang diperlukan untuk membuat aplikasi berfungsi, sambil menjaga aplikasi tidak saling mengetahui karena setiap aplikasi menganggapnya memiliki OS untuk dirinya sendiri.
Secara fungsional, container cukup sederhana – container hanyalah file teks dengan deskripsi yang menguraikan komponen mana yang harus disertakan dalam sebuah instance. Kesederhanaan dan sifat container yang lebih ringan ini memudahkan penggunaan alat otomatisasi (orkestrasi) untuk penerapan di seluruh siklus hidup pengembangan.
DevOps untuk menang… tapi keamanan juga penting
Kontainer memiliki kekuatan untuk meningkatkan efisiensi pengembangan secara signifikan – bertindak sebagai kunci yang membuka kunci DevOps. Itu mungkin salah satu alasan utama mengapa container menjadi sangat populer, dengan Gartner memperkirakan bahwa pada tahun 2023, 70% organisasi akan menjalankan beban kerja dalam container.
Proses pengembangan, pengujian, dan penerapan aplikasi biasanya dipenuhi dengan hambatan, dengan bolak-balik yang konstan antara pengembang dan tim yang menjaga infrastruktur. Hari ini, berkat container, developer dapat membangun dan menguji di lingkungan yang berfungsi dan cukup mengirimkan kode yang sudah jadi bersama spesifikasi yang mendefinisikan lingkungan tersebut.
Di sisi operasional, tim hanya menjalankan spesifikasi ini untuk menciptakan lingkungan yang cocok dan siap digunakan. “Ya, tapi ini berfungsi di mesin saya…” tidak pernah membantu memperbaiki masalah – tetapi hari ini, itu adalah ekspresi yang tidak perlu lagi digunakan oleh pengembang karena tidak ada masalah lingkungan untuk di-debug.
Jadi, ya, DevOps berarti perkembangan pesat. Tapi ada komponen yang hilang: keamanan. Inilah sebabnya mengapa kami semakin sering mendengar tentang DevSecOps seiring evolusinya dari DevOps karena pengembang telah memperhatikan bahwa model DevOps saja tidak cukup mengatasi masalah keamanan.
Kontainer memperkenalkan beberapa risiko keamanan
Wadah menyederhanakan proses pengembangan tetapi memperkenalkan kompleksitas ke dalam gambar keamanan. Saat Anda mengemas seluruh lingkungan operasi ke dalam wadah hanya untuk mendistribusikannya secara luas, Anda juga meningkatkan permukaan serangan dan membuka pintu ke berbagai vektor serangan. Pustaka rentan apa pun yang dikemas dengan wadah akan menyebarkan kerentanan ini ke beban kerja yang tak terhitung jumlahnya.
Ada beberapa risiko. Salah satunya adalah “serangan rantai pasokan” di mana aktor jahat memasang serangan bukan dengan mengacaukan aplikasi Anda, tetapi dengan memodifikasi salah satu paket atau komponen yang disertakan dengan aplikasi Anda. Jadi, tim yang menjaga upaya pengembangan perlu menilai aplikasi yang mereka kembangkan dan setiap perpustakaan ditarik sebagai ketergantungan oleh konfigurasi wadah.
Risiko terhadap keamanan container juga melibatkan alat yang mengaktifkan container – mulai dari Docker hingga alat orkestrasi seperti Kubernetes, karena alat ini perlu dipantau dan dilindungi. Anda tidak boleh, misalnya, mengizinkan sysadmin menjalankan wadah Docker sebagai root. Demikian juga, Anda perlu menjaga ketat pendaftar penampung Anda untuk memastikan bahwa ini tidak dikompromikan.
Keamanan kernel merupakan inti dari keamanan kontainer
Beberapa risiko keamanan terkait kontainer kurang terlihat dibandingkan yang lain. Setiap container memerlukan akses ke kernel – bagaimanapun juga, container hanyalah jenis isolasi proses lanjutan. Tetapi mudah untuk melewatkan fakta bahwa semua container bergantung pada kernel yang sama – tidak masalah bahwa aplikasi di dalam container dipisahkan satu sama lain.
Kernel yang dilihat aplikasi dalam wadah sama dengan kernel yang diandalkan oleh host untuk beroperasi. Ini membawa beberapa masalah. Jika kernel pada host yang mendukung container rentan terhadap eksploitasi, kerentanan ini dapat dieksploitasi dengan memulai serangan dari aplikasi di dalam container.
Jadi fakta bahwa kernel dibagikan oleh semua kontainer di host berarti kernel yang cacat harus ditambal dengan cepat, atau semua kontainer dapat dengan cepat terpengaruh oleh kerentanan.
Sekali lagi, itu tergantung pada penambalan
Oleh karena itu, menjaga kernel host tetap mutakhir merupakan langkah penting dalam memastikan operasi container yang aman dan terjamin. Dan bukan hanya kernel yang perlu ditambal, tambalan harus diterapkan ke perpustakaan yang ditarik oleh sebuah wadah. Tapi, seperti yang kita tahu, menambal secara konsisten lebih mudah diucapkan daripada dilakukan. Itu mungkin mengapa satu studi menemukan bahwa 75% kontainer yang dianalisis mengandung kerentanan yang diklasifikasikan sebagai kritis atau berisiko tinggi.
Kerentanan ini dapat menyebabkan, misalnya, serangan breakout di mana penyerang bergantung pada pustaka yang cacat di dalam wadah untuk dapat mengeksekusi kode di luar wadah. Dengan melanggar satu wadah, penyerang pada akhirnya dapat mencapai target yang diinginkan apakah itu sistem host atau aplikasi di wadah lain.
Dalam konteks container yang memelihara library yang aman bisa sangat memusingkan – seseorang perlu melacak kerentanan baru serta apa yang telah ditambal dan apa yang belum. Prosesnya melelahkan, tetapi juga membutuhkan keterampilan khusus yang merupakan sesuatu yang perlu diperoleh organisasi Anda jika belum memilikinya.
Mengingat nilai penambalan yang teratur dan konsisten, alasan tersebut seharusnya tidak cukup untuk menyebabkan semacam rutinitas penambalan yang sering kita lihat, tetapi – terutama ketika memikirkan tentang kernel OS – gangguan pada reboot yang diperlukan dan yang terkait perlu mempertahankan jendela downtime secara signifikan dapat menunda patching. Patching kernel langsung membantu mengurangi masalah ini, tetapi belum diterapkan oleh semua organisasi.
Selalu sertakan sasaran keamanan dalam operasi penampung Anda
Sudah umum bagi teknologi mutakhir untuk memperkenalkan komplikasi baru dalam hal keamanan informasi. Alat baru biasanya mengarah pada eksploitasi baru dan baru. Itu juga berlaku untuk container dan meskipun tidak merusak nilai keseluruhan dari penggunaan container dalam beban kerja Anda, ini berarti Anda perlu mengawasi risiko yang ditimbulkan oleh container.
Mendidik developer dan sysadmin Anda tentang kelemahan umum dalam keamanan container dan praktik terbaik yang mengurangi kelemahan ini adalah permulaan. Menambal adalah aspek penting lainnya. Seperti biasa, menerapkan langkah-langkah yang tepat untuk mengurangi kelemahan keamanan siber akan membantu melindungi organisasi Anda – dan memungkinkan tim Anda mendapatkan manfaat dari teknologi mutakhir itu tanpa mengalami malam tanpa tidur.