Pemindaian IaC: Peluang Belajar yang Fantastis dan Terabaikan

Semua yang Anda baca tentang infrastruktur sebagai kode (IaC) difokuskan pada cara kerjanya atau mengapa Anda ingin memastikan bahwa itu benar-benar membangun seperti yang Anda inginkan.

Ini adalah area kritis. Tapi apakah kita cukup berpikir tentang bagaimana kita menggunakan pendekatan ini dalam organisasi kita?

As Tanda Melinda dari ESG menyatakan dalam laporan perusahaan, "83% organisasi mengalami peningkatan kesalahan konfigurasi template IAC" karena mereka terus mengadopsi teknologi tersebut.

Kami tahu dari pekerjaan yang dilakukan oleh Cloud Security Alliance (“Ancaman Teratas terhadap Cloud Computing: Egregious Eleven“) dan lainnya, kesalahan konfigurasi terus menjadi risiko utama di cloud.

IaC didukung untuk menurunkan
kesalahan konfigurasi dengan mensistematisasikan pembuatan infrastruktur, menambahkan tingkat ketelitian dan proses yang memastikan tim membangun apa yang mereka inginkan dan hanya apa yang mereka inginkan. Jika ~83% tim tidak menyadarinya, ada masalah yang lebih dalam.

Pada tim yang lebih kecil, di mana bagian Dev dan Ops dari filosofi DevOps bersatu, itu masuk akal. IaC memungkinkan tim kecil ini menggunakan bahasa yang sama — kode — untuk mendeskripsikan semua yang mereka lakukan.

Inilah mengapa kami melihat abstraksi tingkat yang lebih tinggi daripada alat seperti Terraform atau AWS CloudFormation di CDK AWS dan proyek seperti cdk8s. Abstraksi tingkat tinggi itu lebih nyaman bagi pengembang.

Perspektif ops/SRE/platform dari layanan cloud akan sangat berbeda dari perspektif pengembang dari layanan yang sama. Pengembang akan melihat layanan antrean dan mempelajari antarmukanya — titik akhir sederhana untuk ditambahkan dan satu untuk dibaca? Terjual. Itu integrasi yang mudah.

Perspektif operasional ini bertujuan untuk menemukan ujung-ujungnya. Jadi, kapan antrian ini mencapai batasnya? Apakah kinerjanya konstan atau berubah secara radikal di bawah beban?

Ya, ada kekhawatiran yang tumpang tindih. Dan ya, ini adalah tampilan yang disederhanakan. Tapi idenya bertahan. IaC memecahkan banyak masalah, tetapi juga dapat membuat dan memperkuat keterputusan antar tim. Lebih penting lagi, itu dapat menyoroti kesenjangan antara niat dari apa yang Anda coba bangun dan kenyataan dari apa yang telah Anda bangun.

Akibatnya, di sinilah masalah keamanan sering meningkat.

Sebagian besar perkakas — komersial atau sumber terbuka — difokuskan untuk mengidentifikasi hal-hal yang salah dengan templat infrastruktur. Kredensial mikro
adalah konstruk yang baik. Membuat ini
akan buruk. Alat-alat ini bertujuan untuk menghasilkan hasil ini sebagai bagian dari pipeline continuous integration/continuous delivery (CI/CD).

Itu awal yang bagus. Tapi itu menggemakan masalah bahasa yang sama.

Siapa yang Berbicara dan Siapa yang Mendengarkan?

Saat alat IAC menyoroti suatu masalah, siapa yang akan menanganinya? Jika itu adalah tim pengembangan, apakah ada cukup informasi untuk mengetahui mengapa hal ini ditandai sebagai masalah? Jika itu adalah tim operasi, apakah konsekuensi dari masalah tersebut tercantum dalam laporan?

Untuk pengembang, yang sering terjadi adalah mereka hanya akan menyesuaikan konfigurasi agar pengujian IaC lulus.

Untuk operasi, biasanya masalah lulus atau tidaknya tes. Jika ya, lanjutkan ke tugas berikutnya. Itu bukan ketukan di kedua tim; sebaliknya, ini menyoroti kesenjangan harapan versus kenyataan.

Yang dibutuhkan adalah konteks. Alat keamanan IaC memberikan visibilitas ke dalam apa yang akan (semoga) dibangun. Tujuannya adalah untuk menghentikan masalah sebelum mereka mulai berproduksi.

Alat keamanan IaC hari ini menyoroti masalah nyata yang perlu ditangani. Mengambil keluaran dari alat ini dan memperkayanya dengan konteks tambahan yang khusus untuk tim yang bertanggung jawab atas kode adalah peluang sempurna untuk otomatisasi kustom.

Ini juga akan membantu menjembatani kesenjangan bahasa. Output dari perkakas Anda pada dasarnya dalam bahasa ketiga — hanya untuk membuat segalanya lebih rumit — dan perlu dikomunikasikan dengan cara yang masuk akal baik untuk audiens pengembangan atau operasi. Seringkali keduanya.

Misalnya, saat pemindaian menandai bahwa aturan grup keamanan tidak memiliki deskripsi, mengapa hal itu penting? Hanya mendapatkan peringatan yang mengatakan "Tambahkan deskripsi untuk konteks" tidak membantu siapa pun membangun lebih baik.

Jenis bendera ini merupakan peluang bagus untuk mengedukasi tim yang sedang membangun di cloud. Menambahkan penjelasan bahwa aturan grup keamanan harus sespesifik mungkin mengurangi peluang serangan berbahaya. Berikan referensi untuk contoh aturan yang kuat. Sebut itu tanpa mengetahui niatnya, dan tim lain tidak dapat menguji validitas konfirmasi keamanan.

Keamanan adalah tanggung jawab semua orang, jadi memahami kesenjangan bahasa antara pengembang dan operasi akan menyoroti peluang seperti ini untuk menambahkan otomatisasi sederhana yang memberikan wawasan ke tim Anda. Ini akan membantu meningkatkan apa yang sedang mereka bangun dan, sebagai hasilnya, akan mendorong hasil keamanan yang lebih baik.

tentang Penulis

Saya seorang ilmuwan forensik, pembicara, dan analis teknologi yang mencoba membantu Anda memahami dunia digital dan pengaruhnya terhadap kita. Untuk pengguna sehari-hari, karya saya membantu menjelaskan apa saja tantangan dunia digital. Seberapa besar dampak penggunaan media sosial terhadap privasi Anda? Apa artinya ketika teknologi seperti pengenalan wajah mulai digunakan di komunitas kita? Saya membantu menjawab pertanyaan seperti ini dan lainnya. Untuk orang-orang yang membangun teknologi, saya membantu mereka menerapkan lensa keamanan dan privasi pada pekerjaan mereka, sehingga mereka dapat memungkinkan pengguna membuat keputusan yang lebih jelas tentang informasi dan perilaku mereka. Ada banyak kebingungan dalam hal privasi dan keamanan. Seharusnya tidak ada. Saya membuat keamanan dan privasi lebih mudah dipahami.