Hacker mendapatkan akses ke kode aplikasi Anda dapat menghancurkan perangkat lunak berpemilik, tetapi menyimpan kredensial di Git dapat memberi mereka akses database yang lebih tinggi. Bahkan jika Anda tidak berencana agar repositori Git Anda diretas, ada baiknya manajemen risiko untuk meminimalkan potensi kerusakan. Akses Kontrol Sumber
sebagai Vektor Serangan
Perangkat lunak sumber terbuka bukannya tidak aman; Lagi pula, sebagian besar perangkat lunak yang digunakan untuk menjalankan Internet dikembangkan secara publik di GitHub. Meskipun memiliki kode publik berarti peretas dapat menemukan eksploit dengan lebih mudah, open source telah membuktikan bahwa itu bagus untuk transparansi dan perbaikan bug komunitas. Namun, ini tidak berarti bahwa perangkat lunak sumber tertutup secara inheren lebih aman. Ketika pengembang berasumsi bahwa kontrol sumber bersifat pribadi, mereka sering mengambil solusi termudah saat mengelola rahasia seperti kunci API atau kredensial database: mengkodekan mereka ke dalam aplikasi daripada menggunakan manajemen rahasia yang tepat.
Salah satu vektor serangan utama untuk peretas adalah mendapatkan akses ke kontrol sumber, dan memindai proyek untuk kunci API atau rahasia lain yang seharusnya tidak ada. Hal ini memungkinkan mereka meningkatkan izin dan menyerang seluruh jaringan, seringkali mendapatkan akses ke data atau database pelanggan yang sensitif. Nbsp
Baru-baru ini, daftar “No-Fly” TSA bocor melalui metode yang tepat ini. Server build Jenkins yang tidak aman dibiarkan terbuka untuk umum, kesalahan umum yang dilakukan saat menyiapkan perangkat lunak yang seharusnya berada di subnet pribadi di belakang kontrol akses. Di server Jenkins, peretas dapat mengakses riwayat pembuatan, yang berisi kode, dan menemukan kredensial AWS S3 untuk maskapai yang dikodekan keras ke dalam aplikasi.
Jangan Menyimpan Rahasia di Kontrol Sumber
Setiap aplikasi akan memiliki metode yang berbeda untuk menyimpan kunci API dan kredensial database dengan aman, tetapi ada beberapa metode umum.
Yang pertama adalah menggunakan file konfigurasi, yang dapat diterapkan dalam produksi ke server, dan dibaca oleh aplikasi saat runtime. Misalnya, proyek ASP.NET secara default menggunakan file appsettings.json yang kosong saat disimpan di kontrol sumber. Terserah administrator yang menerapkan aplikasi untuk menyebarkan file konfigurasi produksi.
Anda juga dapat menggunakan variabel lingkungan, yang diatur oleh sistem sebelum menjalankan aplikasi. Ini biasanya digunakan untuk wadah Docker, karena ini adalah cara mudah untuk menyuntikkan kredensial ke dalam wadah yang sudah dibangun. Misalnya, Portainer menawarkan pengelolaan variabel lingkungan sebagai bagian dari antarmuka web Docker.
Biasanya, sebaiknya merotasi rahasia secara rutin, karena kredensial yang sudah usang menimbulkan risiko keamanan. Salah satu alat yang dapat mengelola rahasia yang berputar adalah AWS’s Secrets Manager, yang berfungsi sebagai sistem penyimpanan yang dapat dengan mudah memasok rahasia ke aplikasi AWS Anda.
Untuk aplikasi di luar AWS, atau aplikasi apa pun yang menggunakan layanan serupa, ada sedikit masalah di bahwa Anda masih memerlukan kunci IAM untuk mengakses Pengelola Rahasia, yang berarti Anda harus mengelola kunci IAM, yang merupakan masalah persis yang Anda mulai. Namun, sistem IAM AWS memungkinkan pengelolaan peran dan izin yang terpisah. Anda dapat, misalnya, membuat pengguna untuk setiap server yang Anda miliki, dan mengontrol kunci mana di Pengelola Rahasia yang dapat mereka akses. Anda juga dapat menerapkan kebijakan keamanan pada pengguna IAM, mengharuskan mereka untuk dirotasi secara teratur juga.
TERKAIT:Jangan Tinggalkan Kata Sandi di Kode Anda; Alih-alih, gunakan Pengelola Rahasia AWS
Jangan Menyimpan Rahasia dalam Skrip Build
Salah satu kesalahan keamanan terburuk yang dapat dilakukan pengembang adalah menyimpan kunci untuk penerapan produksi dalam skrip build yang digunakan dalam pipeline CI/CD.
Misalnya, Anda mungkin memiliki skrip shell atau YAML file yang digunakan untuk mengontrol pembuatan, pengujian, dan, yang terpenting, menerapkan aplikasi Anda ke server atau layanan penyimpanan seperti Amazon S3. Namun, jika penyerang mendapatkan akses ke skrip ini, mereka akan dapat menyebarkan apa pun ke server atau keranjang penyimpanan Anda.
Salah satu cara paling umum untuk mengatasinya adalah dengan menggunakan alat manajemen rahasia seperti GitHub Secrets, yang menyimpan kredensial di repositori Anda yang dapat diakses dengan nama di GitHub Actions build scripts.
Jika aplikasi Anda diterapkan secara otomatis menggunakan GitHub Actions, dan memerlukan kredensial agar berfungsi, Anda juga dapat menggunakan Secrets untuk memasukkannya ke dalam proses build saat runtime, baik dengan membuat yang diperlukan file konfigurasi, atau mengatur variabel lingkungan yang diperlukan. Dengan cara ini, repositori Anda bahkan dapat bersifat publik dan tetap membuat aplikasi yang diinjeksi dengan kredensial produksi sebelum diterapkan.
GitHub Rahasia yang dibuat dalam suatu organisasi bahkan dapat dibagikan ke beberapa repositori, menyediakan cara mudah untuk mengelola kunci aman secara terpusat. Alat server build lainnya seperti Jenkins atau TeamCity juga akan memiliki manajemen rahasia bawaan.