Menyelesaikan Ketersediaan vs. Keamanan, Konflik Konstan di TI

  • Whatsapp
Menyelesaikan Ketersediaan vs. Keamanan, Konflik Konstan di TI
Menyelesaikan Ketersediaan vs Keamanan Konflik Konstan di TI

News.nextcloud.asia –

Persyaratan bisnis yang saling bertentangan adalah masalah umum – dan Anda menemukannya di setiap sudut organisasi, termasuk di bidang teknologi informasi. Menyelesaikan konflik ini adalah suatu keharusan, tetapi tidak selalu mudah – meskipun terkadang ada solusi baru yang membantu.

Dalam manajemen TI ada perjuangan terus-menerus antara tim keamanan dan operasi. Ya, kedua tim pada akhirnya ingin memiliki sistem aman yang lebih sulit untuk dilanggar. Namun, keamanan bisa datang dengan mengorbankan ketersediaan – dan sebaliknya. Dalam artikel ini, kita akan melihat ketersediaan vs. konflik keamanan, dan solusi yang membantu menyelesaikan konflik tersebut.

Tim operasi fokus pada ketersediaan… tim keamanan terkunci

Tim operasi akan selalu memiliki stabilitas, dan oleh karena itu ketersediaan, sebagai prioritas utama. Ya, tim operasi juga akan menjadikan keamanan sebagai prioritas, tetapi hanya sejauh menyangkut stabilitas atau ketersediaan, tidak pernah sebagai tujuan mutlak.

Ini dimainkan dalam sasaran waktu aktif “lima sembilan” yang menetapkan persyaratan yang sangat tinggi – bahwa sistem sedang berjalan dan tersedia untuk melayani permintaan 99,999% setiap saat. Ini adalah tujuan terpuji yang membuat para pemangku kepentingan senang. Alat seperti ketersediaan tinggi membantu di sini dengan menyediakan redundansi tingkat sistem atau layanan, tetapi tujuan keamanan dapat dengan cepat menghalangi pencapaian “lima sembilan”.

Untuk tim keamanan, tujuan utamanya adalah membuat sistem terkunci semaksimal mungkin, mengurangi permukaan serangan dan tingkat risiko keseluruhan ke tingkat minimum absolut. Dalam praktiknya, tim keamanan dapat membuat permintaan bahwa sistem harus dimatikan untuk patch sekarang dan tidak dua minggu dari sekarang, mengurangi ketersediaan untuk patch segera – tidak peduli apa konsekuensinya bagi pengguna.

Sangat mudah untuk melihat bahwa pendekatan ini akan membuat sakit kepala yang besar bagi tim operasi. Lebih buruk lagi, di mana ketersediaan tinggi benar-benar membantu tim operasi untuk mencapai tujuan ketersediaan dan stabilitas mereka, itu sebenarnya dapat memperburuk keadaan bagi tim keamanan yang sekarang harus menangani peningkatan jumlah server, atau layanan, yang semuanya memerlukan perlindungan dan pemantauan.

Praktik terbaik mana yang harus diikuti?

Ini menciptakan konflik antara operasi dan keamanan yang berarti bahwa kedua kelompok dengan cepat berselisih dalam topik seperti praktik dan proses terbaik. Saat memikirkan tentang penambalan, kebijakan penambalan berbasis jendela pemeliharaan akan menyebabkan lebih sedikit gangguan dan meningkatkan ketersediaan karena ada penundaan beberapa minggu antara upaya penambalan dan waktu henti terkait.

Tapi ada satu hal yang menarik: jendela pemeliharaan tidak cukup cepat untuk ditambal untuk mempertahankan diri dari ancaman yang muncul karena ancaman ini sering dieksploitasi secara aktif dalam beberapa menit setelah pengungkapan (atau bahkan sebelum pengungkapan, misalnya Log4j).

Masalah terjadi di semua jenis beban kerja dan tidak masalah apakah Anda menggunakan DevOps, DevSecOps, atau pendekatan operasi apa pun sebagai cita rasa hari ini. Pada akhirnya, Anda melakukan patch lebih cepat untuk operasi yang aman dengan mengorbankan ketersediaan atau kinerja, atau patch lebih lambat dan mengambil risiko yang tidak dapat diterima dengan keamanan.

Ini dengan cepat menjadi sangat rumit

Memutuskan seberapa cepat untuk menambal hanyalah permulaan. Terkadang, menambal tidak sederhana. Anda bisa, misalnya, berurusan dengan kerentanan di tingkat bahasa pemrograman – yang pada gilirannya berdampak pada aplikasi yang ditulis dalam bahasa itu, misalnya, CVE-2022-31626kerentanan PHP.

Ketika ini terjadi, ada grup lain yang berpartisipasi dalam ketersediaan vs. konflik keamanan: pengembang yang perlu menangani kerentanan tingkat bahasa dalam dua langkah. Pertama, dengan memperbarui versi bahasa yang dimaksud, yang merupakan bagian yang mudah.

Tetapi memperbarui versi bahasa tidak hanya membawa peningkatan keamanan; itu juga membawa perubahan mendasar lainnya. Itu sebabnya pengembang harus melalui langkah kedua: mengkompensasi perubahan tingkat bahasa yang dibawa oleh penulisan ulang kode aplikasi.

Itu juga berarti pengujian ulang dan bahkan sertifikasi ulang dalam beberapa kasus. Sama seperti tim operasi yang ingin menghindari waktu henti terkait restart, pengembang benar-benar ingin menghindari pengeditan kode ekstensif selama mungkin karena ini menyiratkan pekerjaan besar yang, ya, memastikan keamanan yang lebih ketat – tetapi sebaliknya membuat pengembang tidak menunjukkan apa-apa untuk waktu mereka .

Anda dapat dengan mudah melihat mengapa proses manajemen tambalan saat ini menyebabkan konflik berlapis-lapis antar tim. Kebijakan top-to-bottom dapat mengatasi masalah sampai batas tertentu, tetapi biasanya berarti tidak ada yang benar-benar senang dengan hasilnya.

Lebih buruk lagi, kebijakan ini seringkali dapat membahayakan keamanan dengan membiarkan sistem tidak ditambal terlalu lama. Menambal sistem pada interval mingguan atau bulanan dengan berpikir bahwa risikonya dapat diterima, pada tingkat ancaman saat ini, mengarah pada pemeriksaan realitas yang serius cepat atau lambat.

Ada satu cara untuk mengurangi secara signifikan – atau bahkan menyelesaikan konflik antara penambalan langsung (dan gangguan) dan penambalan tertunda (dan lubang keamanan). Jawabannya terletak pada penambalan yang bebas gangguan dan tanpa gesekan, di setiap level atau setidaknya sebanyak level yang praktis.

Tambalan tanpa gesekan dapat menyelesaikan konflik

Patching langsung adalah alat patch tanpa gesekan yang harus diwaspadai oleh tim keamanan Anda. Berkat live patching, Anda menambal lebih cepat daripada yang bisa diharapkan oleh jendela pemeliharaan reguler, dan tidak perlu memulai ulang layanan untuk menerapkan pembaruan. Patching yang cepat dan aman, dengan sedikit atau tanpa downtime. Cara sederhana dan efektif untuk menyelesaikan konflik antara ketersediaan dan keamanan.

Pada TuxCare kami menyediakan tambalan langsung yang komprehensif untuk komponen sistem Linux yang penting, dan tambalan untuk beberapa bahasa pemrograman dan versi bahasa pemrograman yang berfokus pada masalah keamanan dan tidak memperkenalkan perubahan tingkat bahasa yang akan memaksa pemfaktoran ulang kode – kode Anda akan terus berjalan apa adanya, hanya dengan aman. Bahkan jika bisnis Anda bergantung pada aplikasi yang tidak didukung, Anda tidak perlu khawatir tentang kerentanan yang masuk ke sistem Anda melalui kelemahan bahasa pemrograman – dan Anda juga tidak perlu memperbarui kode aplikasi.

Jadi untuk mengakhiri, dalam ketersediaan vs. konflik keamanan, tambalan langsung adalah satu-satunya alat yang secara signifikan dapat mengurangi ketegangan antara operasi dan tim keamanan.

Pos terkait

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan.