Pipeline deployment adalah proses otomatis yang mengambil kode atau artefak bawaan dan men-deploy-nya ke lingkungan pengujian atau lingkungan produksi. Pipeline deployment biasanya digunakan untuk men-deploy aplikasi, konfigurasi, atau infrastruktur cloud (infrastruktur sebagai kode), dan dapat memainkan peran penting dalam postur keamanan deployment cloud secara keseluruhan.
Panduan ini ditujukan untuk DevOps dan engineer keamanan serta menjelaskan praktik terbaik untuk mendesain pipeline deployment yang aman berdasarkan persyaratan kerahasiaan, integritas, dan ketersediaan Anda.
Arsitektur
Diagram berikut menunjukkan aliran data dalam pipeline deployment. Bagian ini menggambarkan cara mengubah artefak menjadi resource.
Pipeline deployment sering kali merupakan bagian dari alur kerja continuous integration/continuous deployment (CI/CD) yang lebih besar dan biasanya diterapkan menggunakan salah satu model berikut:
Model push: Dalam model ini, Anda mengimplementasikan pipeline deployment menggunakan sistem CI/CD terpusat seperti Jenkins atau GitLab. Sistem CI/CD ini dapat berjalan di Google Cloud, infrastruktur lokal, atau di lingkungan cloud yang berbeda. Sering kali, sistem CI/CD yang sama digunakan untuk mengelola beberapa pipeline deployment.
Model push mengarah ke arsitektur terpusat dengan beberapa sistem CI/CD yang digunakan untuk mengelola resource atau aplikasi dalam jumlah besar. Misalnya, Anda dapat menggunakan satu instance Jenkins atau GitLab untuk mengelola seluruh lingkungan produksi, termasuk semua project dan aplikasinya.
Pull model: Pada model ini, proses deployment diterapkan oleh agen yang di-deploy bersama resource tersebut. Misalnya, dalam cluster Kubernetes yang sama. Agen mengambil artefak atau kode sumber dari lokasi terpusat, dan men-deploy-nya secara lokal. Setiap agen mengelola satu atau dua resource.
Model pull mengarah ke arsitektur yang lebih terdesentralisasi dengan potensi agen tunggal yang sangat banyak.
Dibandingkan dengan deployment manual, penggunaan pipeline deployment secara konsisten dapat memiliki manfaat berikut:
- Peningkatan efisiensi, karena tidak memerlukan pekerjaan manual.
- Keandalan meningkat, karena prosesnya sepenuhnya otomatis dan dapat diulang.
- Kemampuan pelacakan yang lebih baik, karena Anda dapat melacak semua deployment terhadap perubahan kode atau artefak input.
Agar dapat melakukannya, pipeline deployment memerlukan akses ke resource yang dikelolanya:
- Pipeline yang men-deploy infrastruktur dengan menggunakan alat seperti Terraform mungkin perlu membuat, memodifikasi, atau bahkan menghapus resource seperti instance VM, subnet, atau bucket Cloud Storage.
- Pipeline yang men-deploy aplikasi mungkin perlu mengupload image container baru ke Artifact Registry, dan men-deploy versi aplikasi baru ke App Engine, Cloud Run, atau Google Kubernetes Engine (GKE).
- Pipeline yang mengelola setelan atau men-deploy file konfigurasi mungkin perlu mengubah metadata instance VM, konfigurasi Kubernetes, atau mengubah data di Cloud Storage.
Jika pipeline deployment Anda tidak diamankan dengan baik, akses mereka ke resource Google Cloud dapat menjadi titik lemah bagi postur keamanan Anda. Keamanan yang lemah dapat menyebabkan beberapa jenis serangan, termasuk yang berikut:
Serangan pipeline poisoning: Bukannya menyerang resource secara langsung, pihak tidak bertanggung jawab mungkin mencoba menyusupi pipeline deployment, konfigurasinya, atau infrastruktur yang mendasarinya. Dengan memanfaatkan akses pipeline ke Google Cloud, pihak tidak bertanggung jawab tersebut dapat membuat pipeline melakukan tindakan berbahaya pada resource Cloud, seperti yang ditunjukkan dalam diagram berikut:
Serangan supply chain: Bukannya menyerang pipeline deployment, pihak tidak bertanggung jawab mungkin mencoba menyusup atau mengganti input pipeline—termasuk kode sumber, library, atau image container, seperti yang ditunjukkan dalam diagram berikut:
Untuk menentukan apakah pipeline deployment Anda sudah diamankan dengan tepat, lihat kebijakan izinkan dan penolakan dari resource Google Cloud yang terisolasi saja tidaklah cukup. Sebagai gantinya, Anda harus mempertimbangkan seluruh grafik sistem yang secara langsung atau tidak langsung memberikan akses ke resource. Grafik ini mencakup informasi berikut:
- Pipeline deployment, sistem CI/CD yang mendasarinya, dan infrastruktur dasarnya
- Repositori kode sumber, server yang mendasarinya, dan infrastruktur dasarnya
- Artefak input, lokasi penyimpanannya, dan infrastruktur dasarnya
- Sistem yang menghasilkan artefak input, dan infrastruktur yang mendasarinya
Grafik input yang kompleks menyulitkan identifikasi akses pengguna ke resource dan kelemahan sistemik.
Bagian berikut menjelaskan praktik terbaik untuk mendesain pipeline deployment dengan cara yang membantu Anda mengelola ukuran grafik, dan mengurangi risiko pergerakan lateral dan serangan supply chain.
Menilai tujuan keamanan
Resource Anda di Google Cloud cenderung bervariasi dalam seberapa sensitifnya. Beberapa resource mungkin sangat sensitif karena bersifat penting atau rahasia untuk bisnis. Resource lain mungkin kurang sensitif karena bersifat sementara atau hanya dimaksudkan untuk tujuan pengujian.
Untuk mendesain pipeline deployment yang aman, Anda harus terlebih dahulu memahami resource yang perlu diakses pipeline, dan seberapa sensitif resource tersebut. Semakin sensitif resource, semakin Anda harus berfokus untuk mengamankan pipeline.
Resource yang diakses oleh pipeline deployment dapat mencakup:
- Aplikasi, seperti Cloud Run atau App Engine
- Resource cloud, seperti instance VM atau bucket Cloud Storage
- Data, seperti objek Cloud Storage, data BigQuery, atau file
Beberapa resource ini mungkin memiliki dependensi pada resource lain, misalnya:
- Aplikasi dapat mengakses data, resource cloud, dan aplikasi lainnya.
Resource cloud, seperti instance VM atau bucket Cloud Storage, dapat berisi aplikasi atau data.
Seperti ditunjukkan dalam diagram sebelumnya, dependensi memengaruhi seberapa sensitif resource. Misalnya, jika Anda menggunakan aplikasi yang mengakses data yang sangat sensitif, biasanya Anda harus memperlakukan aplikasi tersebut sebagai aplikasi yang sangat sensitif. Demikian pula, jika resource cloud seperti bucket Cloud Storage berisi data sensitif, biasanya Anda harus memperlakukan bucket sebagai sensitif.
Karena dependensi ini, sebaiknya nilai sensitivitas data Anda terlebih dahulu. Setelah menilai data, Anda dapat memeriksa rantai dependensi dan menilai sensitivitas resource dan aplikasi Cloud.
Mengategorikan sensitivitas data Anda
Untuk memahami sensitivitas data dalam pipeline deployment Anda, pertimbangkan tiga tujuan berikut:
- Kerahasiaan: Anda harus melindungi data dari akses yang tidak sah.
- Integritas: Anda harus melindungi data dari modifikasi atau penghapusan yang tidak sah.
- Ketersediaan: Anda harus memastikan bahwa orang dan sistem yang memiliki otorisasi dapat mengakses data di pipeline deployment Anda.
Untuk masing-masing tujuan tersebut, tanyakan pada diri Anda apa yang akan terjadi jika pipeline Anda dilanggar:
- Kerahasiaan: Seberapa berbahaya jika data diungkapkan kepada pihak tidak bertanggung jawab, atau dibocorkan ke publik?
- Integritas: Seberapa besar kerugian yang akan terjadi jika data dimodifikasi atau dihapus oleh pihak tidak bertanggung jawab?
- Ketersediaan: Seberapa besar kerusakan yang akan ditimbulkan jika pihak tidak bertanggung jawab mengganggu akses data Anda?
Agar hasilnya sebanding di seluruh resource, sebaiknya perkenalkan kategori keamanan. Standards for Security Categorization (FIPS-199) menyarankan penggunaan empat kategori berikut:
- Tinggi: Kerusakan akan bersifat parah atau fatal
- Sedang: Kerusakan akan bersifat serius
- Rendah: Kerusakan akan dibatasi
- Tidak berlaku: Standar tidak berlaku
Bergantung pada lingkungan dan konteks Anda, kumpulan kategori yang berbeda mungkin lebih sesuai.
Kerahasiaan dan integritas data pipeline terdapat pada spektrum, berdasarkan kategori keamanan yang baru saja dibahas. Subbagian berikut berisi contoh resource dengan pengukuran kerahasiaan dan integritas yang berbeda:
Resource dengan kerahasiaan rendah, tetapi memiliki integritas rendah, sedang, dan tinggi
Semua contoh resource berikut memiliki kerahasiaan yang rendah:
- Integritas rendah: Data pengujian
- Integritas sedang: Konten server web publik, batasan kebijakan untuk organisasi Anda
- Integritas tinggi: Image container, disk image, konfigurasi aplikasi, kebijakan akses (daftar yang diizinkan dan ditolak), lien, data tingkat akses
Resource dengan kerahasiaan sedang, tetapi integritas rendah, sedang, dan tinggi
Semua contoh resource berikut memiliki kerahasiaan media:
- Integritas rendah: Konten server web internal
- Integritas sedang: Log audit
- Integritas tinggi: File konfigurasi aplikasi
Resource dengan kerahasiaan tinggi, tetapi memiliki integritas rendah, sedang, dan tinggi
Semua contoh resource berikut memiliki kerahasiaan tinggi:
- Integritas rendah: Data penggunaan dan informasi identitas pribadi
- Integritas sedang: Rahasia
- Integritas tinggi: Data keuangan, Kunci KMS
Mengategorikan aplikasi berdasarkan data yang diakses
Saat aplikasi mengakses data sensitif, aplikasi dan pipeline deployment yang mengelola aplikasi juga dapat menjadi sensitif. Untuk memenuhi syarat sensitivitas tersebut, lihat data yang perlu diakses oleh aplikasi dan pipeline.
Setelah mengidentifikasi dan mengategorikan semua data yang diakses oleh aplikasi, Anda dapat menggunakan kategori berikut untuk mengategorikan aplikasi di awal sebelum mendesain pipeline deployment yang aman:
- Kerahasiaan: Kategori tertinggi dari data yang diakses
- Integritas: Kategori tertinggi dari semua data yang diakses
- Ketersediaan: Kategori tertinggi dari data yang diakses
Penilaian awal ini akan memberikan panduan, tetapi mungkin ada faktor tambahan yang perlu dipertimbangkan, misalnya:
- Dua set data mungkin memiliki kepercayaan yang rendah secara terisolasi. Tetapi ketika digabungkan, mereka dapat mengungkapkan insight baru. Jika aplikasi memiliki akses ke kedua set data tersebut, Anda mungkin perlu mengategorikannya sebagai kerahasiaan sedang atau tinggi.
- Jika aplikasi memiliki akses ke data integritas tinggi, biasanya Anda harus mengategorikan aplikasi sebagai integritas tinggi. Namun, jika akses tersebut bersifat hanya baca, kategorisasi integritas tinggi mungkin terlalu ketat.
Untuk mengetahui detail tentang pendekatan formal untuk mengategorikan aplikasi, lihat Panduan untuk Pemetaan Jenis Sistem Informasi dan Informasi hingga Kategori Keamanan (NIST SP 800-60 Vol. 2 Rev1).
Mengategorikan resource cloud berdasarkan data dan aplikasi yang dihosting
Semua data atau aplikasi yang Anda deploy di Google Cloud dihosting oleh resource Google Cloud:
- Aplikasi mungkin dihosting oleh layanan App Engine, instance VM, atau cluster GKE.
- Data Anda mungkin dihosting oleh persistent disk, bucket Cloud Storage, atau set data BigQuery.
Jika resource cloud menghosting data atau aplikasi sensitif, resource dan pipeline deployment yang mengelola resource juga dapat menjadi sensitif. Misalnya, Anda harus menganggap layanan Cloud Run dan pipeline deployment-nya bersifat sensitif dengan aplikasi yang dihostingnya.
Setelah mengategorikan data dan aplikasi Anda, buat kategori keamanan awal untuk aplikasi tersebut. Untuk melakukannya, tentukan level dari kategori berikut:
- Kerahasiaan: Kategori tertinggi dari semua data atau aplikasi yang dihosting
- Integritas: Kategori tertinggi dari semua data atau aplikasi yang dihosting
- Ketersediaan: Kategori tertinggi dari semua data atau aplikasi yang dihosting
Saat melakukan penilaian awal, jangan terlalu ketat—misalnya:
- Jika Anda mengenkripsi data yang sangat rahasia, perlakukan kunci enkripsi sebagai sangat rahasia. Namun, Anda dapat menggunakan kategori keamanan yang lebih rendah untuk resource yang berisi data tersebut.
- Jika Anda menyimpan salinan data yang redundan, atau menjalankan instance redundan dari aplikasi yang sama di beberapa resource, Anda dapat membuat kategori resource lebih rendah daripada kategori data atau aplikasi yang dihostingnya.
Membatasi penggunaan pipeline deployment
Jika pipeline deployment Anda perlu mengakses resource Google Cloud yang sensitif, Anda harus mempertimbangkan postur keamanannya. Makin sensitif resource, semakin baik Anda dalam mencoba mengamankan pipeline. Namun, Anda mungkin mengalami batasan praktis berikut:
- Jika menggunakan infrastruktur yang ada atau sistem CI/CD yang ada, infrastruktur tersebut mungkin membatasi tingkat keamanan yang dapat Anda capai secara realistis. Misalnya, sistem CI/CD Anda mungkin hanya mendukung serangkaian kontrol keamanan yang terbatas, atau mungkin berjalan di infrastruktur yang Anda anggap kurang aman dibandingkan dengan beberapa lingkungan produksi Anda.
- Saat menyiapkan infrastruktur dan sistem baru untuk menjalankan pipeline deployment, mengamankan semua komponen dengan cara yang memenuhi persyaratan keamanan Anda yang paling ketat mungkin tidak hemat biaya.
Untuk menangani batasan ini, sebaiknya tetapkan batasan terkait skenario yang boleh dan tidak boleh menggunakan pipeline deployment dan sistem CI/CD tertentu. Misalnya, deployment yang paling sensitif sering kali ditangani dengan lebih baik di luar pipeline deployment. Deployment ini dapat dilakukan secara manual, menggunakan sistem pengelolaan sesi hak istimewa atau sistem pengelolaan akses istimewa, atau yang lainnya, seperti proxy alat.
Untuk menetapkan batasan, tentukan kontrol akses yang ingin Anda terapkan berdasarkan kategori resource. Pertimbangkan panduan yang ditawarkan dalam tabel berikut:
| Kategori resource | Kontrol akses |
|---|---|
| Rendah | Tidak perlu persetujuan |
| Sedang | Ketua tim harus menyetujui |
| Tinggi | Beberapa prospek harus disetujui dan tindakan harus dicatat |
Bandingkan persyaratan ini dengan kemampuan pengelolaan kode sumber (SCM) dan sistem CI/CD dengan mengajukan pertanyaan berikut dan pertanyaan lainnya:
- Apakah sistem SCM atau CI/CD Anda mendukung kontrol akses dan mekanisme persetujuan yang diperlukan?
- Apakah kontrol tersebut dilindungi agar tidak disalahgunakan jika pihak tidak bertanggung jawab menyerang infrastruktur yang mendasarinya?
- Apakah konfigurasi yang mendefinisikan kontrol telah diamankan dengan tepat?
Bergantung pada kemampuan dan batasan yang diberlakukan oleh sistem SCM atau CI/CD, Anda dapat menentukan batasan data dan aplikasi untuk pipeline deployment Anda. Pertimbangkan panduan yang ditawarkan dalam tabel berikut:
| Kategori resource | Batasan |
|---|---|
| Rendah | Pipeline deployment dapat digunakan, dan developer dapat menyetujui deployment sendiri. |
| Sedang | Pipeline deployment dapat digunakan, tetapi ketua tim harus menyetujui setiap komitmen dan deployment. |
| Tinggi | Jangan gunakan pipeline deployment. Sebagai gantinya, administrator harus menggunakan sistem pengelolaan akses istimewa dan perekaman sesi. |
Mempertahankan ketersediaan resource
Menggunakan pipeline deployment untuk mengelola resource dapat memengaruhi ketersediaan resource tersebut dan dapat menimbulkan risiko baru:
- Menyebabkan pemadaman layanan: Pipeline deployment mungkin mengirim kode yang salah atau file konfigurasi, yang menyebabkan sistem yang sebelumnya bekerja rusak, atau data menjadi tidak dapat digunakan.
- Memperpanjang pemadaman layanan: Untuk memperbaiki pemadaman layanan, Anda mungkin perlu menjalankan kembali pipeline deployment. Jika pipeline deployment rusak atau tidak tersedia karena alasan lain, penghentian layanan dapat berlangsung lama.
Pipeline yang dapat menyebabkan atau memperpanjang pemadaman layanan memiliki risiko penolakan layanan: Pihak tidak bertanggung jawab mungkin menggunakan pipeline deployment untuk sengaja menyebabkan pemadaman layanan.
Membuat prosedur akses darurat
Jika pipeline deployment adalah satu-satunya cara untuk men-deploy atau mengonfigurasi aplikasi atau resource, ketersediaan pipeline dapat menjadi sangat penting. Dalam kasus yang ekstrem, jika pipeline deployment merupakan satu-satunya cara untuk mengelola aplikasi yang penting bagi bisnis, Anda mungkin juga perlu mempertimbangkan pipeline deployment yang penting bagi bisnis.
Karena pipeline deployment sering kali dibuat dari beberapa sistem dan alat, mempertahankan tingkat ketersediaan yang tinggi bisa jadi sulit atau tidak ekonomis.
Anda dapat mengurangi pengaruh pipeline deployment terhadap ketersediaan dengan membuat prosedur akses darurat. Misalnya, buat jalur akses alternatif yang dapat digunakan jika pipeline deployment tidak beroperasi.
Membuat prosedur akses darurat biasanya memerlukan sebagian besar proses berikut:
- Mempertahankan satu atau beberapa akun pengguna dengan akses istimewa ke resource Google Cloud yang relevan.
- Simpan kredensial akun pengguna akses darurat di lokasi yang aman, atau gunakan sistem pengelolaan akses istimewa untuk broker akses.
- Tetapkan prosedur yang dapat diikuti karyawan yang diotorisasi untuk mengakses kredensial.
- Mengaudit dan meninjau penggunaan akun pengguna dengan akses darurat.
Memastikan artefak input memenuhi permintaan ketersediaan Anda
Pipeline deployment biasanya perlu mendownload kode sumber dari repositori kode sumber terpusat sebelum dapat menjalankan deployment. Jika repositori kode sumber tidak tersedia, menjalankan pipeline deployment mungkin akan gagal.
Banyak pipeline deployment juga bergantung pada artefak pihak ketiga. Artefak tersebut
dapat mencakup library dari sumber seperti npm, Maven Central, atau NuGet
gallery, serta image dasar container, serta paket .deb dan .rpm. Jika salah satu sumber pihak ketiga tidak tersedia, menjalankan pipeline deployment mungkin akan gagal.
Untuk mempertahankan tingkat ketersediaan tertentu, Anda harus memastikan bahwa artefak input dari pipeline deployment Anda semuanya memenuhi persyaratan ketersediaan yang sama atau lebih tinggi. Daftar berikut dapat membantu Anda memastikan ketersediaan artefak input:
- Batasi jumlah sumber untuk artefak input, terutama sumber pihak ketiga
- Mempertahankan cache artefak input yang dapat digunakan pipeline deployment jika sistem sumber tidak tersedia
Memperlakukan pipeline deployment dan infrastrukturnya seperti sistem produksi
Pipeline deployment sering berfungsi sebagai jaringan penghubung antara lingkungan pengembangan, staging, dan produksi. Bergantung pada lingkungannya, mereka mungkin menerapkan beberapa tahap:
- Pada tahap pertama, pipeline deployment akan mengupdate lingkungan pengembangan.
- Pada tahap berikutnya, pipeline deployment akan mengupdate lingkungan staging.
- Pada tahap akhir, pipeline deployment akan memperbarui lingkungan produksi.
Saat menggunakan pipeline deployment di beberapa lingkungan, pastikan pipeline tersebut memenuhi permintaan ketersediaan setiap lingkungan. Karena lingkungan produksi biasanya memiliki permintaan ketersediaan tertinggi, Anda harus memperlakukan pipeline deployment dan infrastruktur dasarnya seperti sistem produksi. Dengan kata lain, terapkan standar kontrol akses, keamanan, dan kualitas yang sama ke infrastruktur yang menjalankan pipeline deployment seperti yang Anda lakukan untuk sistem produksi.
Membatasi cakupan pipeline deployment
Semakin banyak resource yang dapat diakses oleh pipeline deployment, semakin besar kerusakan yang dapat ditimbulkannya jika disusupi. Pipeline deployment yang disusupi dan memiliki akses ke beberapa project atau bahkan seluruh organisasi Anda, dalam kasus terburuk, dapat menyebabkan kerusakan berkepanjangan pada semua data dan aplikasi Anda di Google Cloud.
Untuk membantu menghindari skenario terburuk ini, batasi cakupan pipeline deployment Anda. Tentukan cakupan setiap pipeline deployment sehingga hanya memerlukan akses ke sejumlah kecil resource di Google Cloud:
- Alih-alih memberikan akses pada level project, hanya berikan akses pipeline deployment ke resource individual.
- Hindari memberikan akses ke resource di beberapa project Google Cloud.
- Memisahkan pipeline deployment menjadi beberapa tahap jika memerlukan akses ke beberapa project atau lingkungan. Kemudian, amankan setiap tahapannya.
Menjaga kerahasiaan
Pipeline deployment harus menjaga kerahasiaan data yang dikelolanya. Salah satu risiko utama terkait kerahasiaan adalah pemindahan data yang tidak sah.
Ada beberapa cara yang dapat digunakan pihak tidak bertanggung jawab untuk menggunakan pipeline deployment untuk memindahkan data secara tidak sah dari resource Google Cloud Anda. Cara tersebut meliputi:
- Langsung: Pihak tidak bertanggung jawab dapat mengubah pipeline deployment atau konfigurasinya agar dapat mengekstrak data dari resource Google Cloud Anda, lalu menyalinnya di tempat lain.
- Tidak langsung: Pihak tidak bertanggung jawab mungkin menggunakan pipeline deployment untuk men-deploy kode yang disusupi, yang kemudian mencuri data dari lingkungan Google Cloud Anda.
Anda dapat mengurangi risiko kerahasiaan dengan meminimalkan akses ke resource rahasia. Namun, menghapus semua akses ke resource rahasia mungkin tidak praktis. Oleh karena itu, Anda harus mendesain pipeline deployment untuk memenuhi permintaan kerahasiaan resource yang dikelolanya. Untuk menentukan permintaan ini, Anda dapat menggunakan pendekatan berikut:
- Tentukan data, aplikasi, dan resource yang perlu diakses pipeline deployment, lalu kategorikan.
- Temukan resource dengan kategori kerahasiaan tertinggi dan gunakan sebagai kategori awal untuk pipeline deployment.
Mirip dengan proses kategorisasi untuk aplikasi dan resource cloud, penilaian awal ini tidak selalu sesuai. Misalnya, Anda dapat menggunakan pipeline deployment untuk membuat resource yang pada akhirnya akan berisi informasi yang sangat rahasia. Jika Anda membatasi pipeline deployment agar dapat membuat–tetapi tidak dapat membaca–resource ini, kategori kerahasiaan yang lebih rendah mungkin cukup.
Untuk menjaga kerahasiaan, model Bel–LaPadula menyarankan bahwa pipeline deployment tidak boleh:
- Menggunakan artefak input dengan kerahasiaan yang lebih tinggi
- Menulis data ke resource dengan kerahasiaan yang lebih rendah
Menurut model Bell–LaPadula, diagram sebelumnya menunjukkan alur data dalam pipeline untuk membantu memastikan kerahasiaan data.
Jangan biarkan pipeline deployment membaca data yang tidak mereka perlukan
Pipeline deployment sering kali tidak memerlukan akses ke data, tetapi mungkin masih memilikinya. Pemberian akses yang berlebihan tersebut dapat disebabkan oleh:
- Memberikan izin akses yang salah. Misalnya, pipeline deployment mungkin diberi akses ke Cloud Storage pada level project. Akibatnya, pipeline deployment dapat mengakses semua bucket Cloud Storage dalam project, meskipun akses ke satu bucket mungkin cukup.
- Menggunakan peran yang terlalu permisif. Pipeline deployment mungkin diberi peran yang, misalnya, memberikan akses penuh ke Cloud Storage. Namun, izin untuk membuat bucket baru sudah cukup.
Semakin banyak data yang dapat diakses pipeline, semakin tinggi risiko seseorang atau sesuatu dapat mencuri data Anda. Untuk membantu meminimalkan risiko ini, hindari pemberian akses pipeline deployment ke data yang tidak dibutuhkan. Banyak pipeline deployment tidak memerlukan akses data sama sekali, karena tujuannya hanya untuk mengelola deployment konfigurasi atau software.
Jangan biarkan pipeline deployment menulis ke lokasi yang tidak mereka butuhkan
Untuk menghapus data, pihak tidak bertanggung jawab memerlukan akses dan cara untuk mentransfer data keluar dari lingkungan Anda. Makin banyak lokasi penyimpanan dan jaringan yang dapat menjadi tujuan pengiriman data oleh pipeline deployment, makin besar kemungkinan pihak tidak bertanggung jawab dapat menggunakan salah satu lokasi tersebut untuk pemindahan data yang tidak sah.
Anda dapat membantu mengurangi risiko dengan membatasi jumlah lokasi jaringan dan penyimpanan tempat pipeline dapat mengirim data:
- Cabut akses tulis ke resource yang tidak diperlukan pipeline, meskipun resource tersebut tidak berisi data rahasia.
- Memblokir akses internet, atau membatasi koneksi, ke sekumpulan lokasi jaringan yang diizinkan.
Membatasi akses keluar sangat penting untuk pipeline yang telah Anda kategorikan sebagai cukup rahasia atau sangat rahasia karena memiliki akses ke data rahasia atau materi kunci kriptografis.
Gunakan Kontrol Layanan VPC untuk membantu mencegah deployment yang disusupi agar tidak mencuri data
Bukannya membiarkan pipeline deployment melakukan pemindahan data yang tidak sah, pihak tidak bertanggung jawab mungkin mencoba menggunakan pipeline deployment untuk men-deploy kode yang telah disusupi. Kode yang disusupi tersebut kemudian dapat mencuri data dari dalam lingkungan Google Cloud Anda.
Anda dapat membantu mengurangi risiko ancaman pencurian data tersebut dengan menggunakan Kontrol Layanan VPC. Dengan Kontrol Layanan VPC, Anda dapat membatasi sekumpulan resource dan API yang dapat diakses dari dalam project Google Cloud tertentu.
Menjaga integritas
Agar lingkungan Google Cloud tetap aman, Anda harus melindungi integritasnya. Hal ini mencakup:
- Mencegah modifikasi atau penghapusan data atau konfigurasi tanpa izin
- Mencegah deployment kode atau konfigurasi yang tidak tepercaya
- Memastikan bahwa semua perubahan meninggalkan jejak audit yang jelas
Pipeline deployment dapat membantu Anda mempertahankan integritas lingkungan dengan memungkinkan Anda:
- Mengimplementasikan proses persetujuan—misalnya, dalam bentuk peninjauan kode
- Menerapkan proses yang konsisten untuk semua perubahan konfigurasi atau kode
- Jalankan pengujian otomatis atau pemeriksaan cepat sebelum setiap deployment
Agar efektif, Anda harus mencoba memastikan bahwa pihak tidak bertanggung jawab tidak dapat merusak atau mengabaikan tindakan ini. Untuk mencegah aktivitas tersebut, Anda harus melindungi integritas:
- Pipeline deployment dan konfigurasinya
- Infrastruktur dasar
- Semua input yang digunakan oleh pipeline deployment
Agar pipeline deployment tidak menjadi rentan, coba pastikan bahwa standar integritas pipeline deployment sesuai atau melebihi permintaan integritas resource yang dikelolanya. Untuk menentukan permintaan ini, Anda dapat menggunakan pendekatan berikut:
- Tentukan data, aplikasi, dan resource yang perlu diakses pipeline deployment, lalu kategorikan.
- Temukan resource dengan kategori integritas tertinggi dan gunakan sebagai kategori untuk pipeline deployment.
Untuk mempertahankan integritas pipeline deployment, model Biba menyarankan bahwa:
- Pipeline deployment tidak boleh menggunakan artefak input dengan integritas yang lebih rendah.
- Pipeline deployment tidak boleh menulis data ke resource yang memiliki integritas lebih tinggi.
Menurut model Biba, diagram sebelumnya menunjukkan bagaimana data harus mengalir dalam pipeline untuk membantu memastikan integritas data.
Memverifikasi keaslian artefak input
Banyak pipeline deployment menggunakan artefak dari sumber pihak ketiga. Artefak tersebut dapat mencakup:
- Image dasar Docker
.rpmatau.debpaket- Library Maven,
.npm, atau NuGet
Pihak tidak bertanggung jawab mungkin mencoba mengubah pipeline deployment Anda sehingga menggunakan versi artefak pihak ketiga yang disusupi dengan:
- Merusak repositori yang menyimpan artefak
- Mengubah konfigurasi pipeline deployment untuk menggunakan repositori sumber yang berbeda
- Mengupload paket berbahaya dengan nama serupa, atau nama yang berisi kesalahan ketik
Banyak pengelola paket memungkinkan Anda memverifikasi keaslian paket dengan mendukung penandatanganan kode. Misalnya, Anda dapat menggunakan PGP untuk menandatangani paket RPM dan Maven. Anda dapat menggunakan Authenticode untuk menandatangani paket NuGet.
Anda dapat menggunakan penandatanganan kode untuk mengurangi risiko menjadi korban penyusupan paket pihak ketiga dengan:
- Mewajibkan semua artefak pihak ketiga ditandatangani
- Mempertahankan daftar sertifikat penerbit tepercaya atau kunci publik pilihan
- Mengizinkan pipeline deployment memverifikasi tanda tangan artefak pihak ketiga berdasarkan daftar penerbit tepercaya
Atau, Anda dapat memverifikasi hash artefak. Anda dapat menggunakan pendekatan ini untuk artefak yang tidak mendukung penandatanganan kode dan jarang berubah.
Memastikan infrastruktur dasar memenuhi permintaan integritas Anda
Bukannya membahayakan pipeline deployment itu sendiri, pihak tidak bertanggung jawab mungkin mencoba menyusupi infrastrukturnya, termasuk:
- Software CI/CD yang menjalankan pipeline deployment
- Alat yang digunakan oleh pipeline—misalnya, Terraform, kubectl, atau Docker
- Sistem operasi dan semua komponennya
Karena infrastruktur yang mendasari pipeline deployment sering kali kompleks dan mungkin berisi komponen dari berbagai vendor atau sumber, jenis pelanggaran keamanan ini mungkin sulit dideteksi.
Anda dapat membantu mengurangi risiko penyusupan infrastruktur dengan:
- Memiliki infrastruktur dan semua komponennya dengan standar integritas yang sama seperti pipeline deployment dan resource Google Cloud yang dikelolanya
- Memastikan alat berasal dari sumber tepercaya dan memverifikasi keasliannya
- Membangun kembali infrastruktur dari awal secara teratur
- Menjalankan pipeline deployment di shielded VM
Menerapkan kontrol integritas di pipeline
Meskipun pihak tidak bertanggung jawab adalah ancaman, mereka bukanlah satu-satunya sumber perubahan software atau konfigurasi yang dapat mengganggu integritas lingkungan Google Cloud Anda. Perubahan tersebut juga dapat berasal dari developer dan tidak disengaja, karena ketidaktahuan, atau akibat dari kesalahan ketik dan kesalahan lainnya.
Anda dapat membantu mengurangi risiko penerapan perubahan yang berisiko secara tidak sengaja dengan mengonfigurasi pipeline deployment untuk menerapkan kontrol integritas tambahan. Kontrol tersebut dapat mencakup:
- Melakukan analisis statis pada kode dan konfigurasi
- Mewajibkan semua perubahan agar dapat meloloskan serangkaian aturan (kebijakan sebagai kode)
- Membatasi jumlah perubahan yang dapat dilakukan secara bersamaan
Langkah selanjutnya
- Pelajari praktik terbaik kami untuk menggunakan akun layanan di pipeline deployment.
- Tinjau praktik terbaik untuk mengamankan akun layanan.
- Pelajari lebih lanjut cara Menyelidiki dan merespons ancaman.
- Untuk arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.