Intro
Keamanan data tidaklah bisa ditawar apalagi jika menyangkut kelangsungan bisnis sebuah perusahaan. Standar keamanan data membantu bisnis bekerja dengan aman, terukur, dan terpercaya. Keduanya memastikan bahwa data pelanggan dilindungi dengan baik dan risiko dapat dikendalikan sebelum menjadi masalah besar.
Sebagai seorang software engineer kita perlu aware atas apa yang kita bangun dan kita gunakan untuk membangun. Jika kita tidak memiliki kesadaran atas adanya celah keamanan, kita tidak akan tahu dari mana datangnya sebuah serangan cyber. Kebanyakan tech bros diantara kita masih memiliki mindset yang penting project jalan dulu.
Sementara menjadi "sementahun".
Kita bisa membagi sumber kebocoran data dan potensi celah keamanan menjadi 3 bagian:
- infrastruktur
- code
- orang dalam
Karena saat ini saya bekerja sebagai DevOps, maka tulisan kali ini akan membahas tentang keamanan dari sisi infrastruktur, khususnya yang berhubungan dengan container dan Kubernetes. Saya akan mencoba menulis dengan bahasa awam yang mudah di pahami.
Teman-teman juga bisa membaca tulisan saya sebelumnya pada seri "DevOps Starter Pack" berikut:
- Hal-hal yang perlu diketahui DevOps
- Grant SSH Access
- Dasar Reverse Proxy dan Load Balancing
- Mengenal CORS Origin, Header, dan Method
Sekilas Tentang Container
Penggunaan teknologi container memang bertujuan untuk mempermudah workflow dan deployment sebuah aplikasi. Baik waktu masih development ataupun saat di-deploy ke production. Saya pernah mengulas tentang docker di blog ini pada artikel Docker contaienr dan tips untuk pemula.
Lebih advanced lagi dengan container, kita bisa mengaplikasikannya lewat Kubernetes. Sebuah platform orkestrasi container yang menjadi landasan banyak layanan di era microservices salah satunya karena fitur self-healing. Baik yang self-managed beserta segala keruwetannya atau menggunakan layanan Cloud seperti AWS EKS atau Azure.
Bicara soal cloud, tiap provider juga menyediakan layanan managed container. Tentu, semua layanan cloud ini perlu digunakan dengan bijak seperti penggunaan instance, bandwidth dan storage.
Container Vulnerabilities
Sebuah container memang dijamin terisolasi antar services. Tetapi perlu diingat bahwa celah keamanan masih bisa mengintai. Beberapa contoh yang sering terjadi:
- membuka port yang tidak perlu
- tidak meng-update base image
- tidak meng-update package code
Untuk poin pertama, gampang saja mengatasinya dengan menutup port lewat manifest baik di docker-compose.yml atau dari deployment.yml di kubernetes. Rules yang harus diingat adalah hanya buka port tertentu untuk akses dari public (80/http, 443/https). Jangan pernah membuka akses secara public ke port milik service-service penting seperti DB dan Redis.
Sedangkan untuk poin yang ke 2 dan 3 ini agak tricky untuk mengatasinya. Bayangkan jika teman-teman memiliki 100 repository git. Tentu, mengupdate satu-persatu repo akan merepotkan sekali. Jika base image container tersebut tidak pernah diperbarui package-nya, maka sudah barang tentu akan rentan terhadap celah keamanan dan exploit yang sering di indentifikasi lewat CVE (Common Vulnerabilities and Exposures).
CVE dalam bahasa yang awam adalah sebuah katalog yang berisi kode unik dari sebuah celah keamanan pada software, hardware atau firmware yang telah teridentifikasi oleh profesional dibidang keamanan. Kode CVE ini digunakan agar proses pelacakan, identifikasi, pencegahan dan perilisan security patch menjadi lebih efisien.
Memang cara paling gampang untuk menambal celah keamanan adalah menggunakan base image versi terbaru misal memakai image dengan tag latest. Tetapi cara ini ada efek samping mengganggu ke stabilan service atau inkompatibilitas dengan library yang dipakai dalam project.
Pendekatan yang lebih baik menurut keyakinan saya adalah dengan meng-upgrade package yang ada di base image versi tersebut, atau memisah antara image yang dipakai pada build time dan runtime melalui Docker multistage build. Bisa juga menggunakan rootless image untuk runtime sehingga lebih aman sebab container tidak berjalan sebagai root.
Ada sebuah tools opensource yang sangat berguna untuk membantu dalam mengidentifikasi celah keamanan yang ada pada project kita yaitu: Trivy. Alternatif yang lain bisa memakai Grype. Fungsi keduanya sama, yakni melakukan scanning SBOM (Software bill of materials) dari sebuah project dan bisa juga digunakan untuk scanning vulnerabilities dari docker image.
SBOM merupakan file yang berisi daftar package, library, komponen yang digunakan atau yang terinstall untuk membuat sebuah perangkat lunak dengan format tertentu sehingga memudahkan pengembang dalam menginventaris elemen perangkat lunak. Lebih lengkap ada di link berikut Apa itu Software Bill of Materials (SBOM)? | IBM.
Jika kita kesusahan dalam membuat SBOM, tools seperti trivy dan grype masih bisa digunakan jika ada file berikut di dalam project:
- requirements.txt (python)
- go.mod (golang)
- package.json, yarn.lock, bun.lock atau package.lock (nodejs)
- cargo.toml (rust)
Untuk menggunakannya pastikan sudah menginstall Trivy di komputer. Kemudian gunakan command berikut untuk melakukan proses scanning di dalam project.
trivy fs .Jika ada vulnerability maka hasilnya akan seperti berikut:
Dari hasil tersebut, bisa dijadikan patokan oleh tim Devops untuk mengarahkan engineer menambal celah keamanan dari package/library yang telah terdeteksi lewat scanning trivy.
Selain itu Trivy bisa digunakan untuk scanning docker image, sebagai contoh kita akan melakukan scanning pada image node:16.9.1 seperti berikut:
trivy image --vuln-type os --ignore-unfixed node:16.9.1Dari proses scanning tersebut dapat terlihat bahwa terdapat 2805 celah keamanan yang ada di image node:16.9.1
Untuk case docker image seperti ini, perlu diskusi lebih lanjut dengan tim engineer sebab jika kita melakukan upgrade secara sembarangan menggunakan node versi lebih tinggi, bisa jadi menimbulkan breaking code pada service.
Outro
Dari tulisan ini, semoga teman-teman lebih awar terhadap project yang di kelola. Apalagi jika menyangkut bisnis perusahaan. Seperti pepatah lama bahwa lebih baik mencegah daripada mengobati.