Pipeline deployment adalah proses otomatis yang mengambil kode atau artefak siap pakai 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 keseluruhan deployment cloud.
Panduan ini ditujukan untuk engineer DevOps dan keamanan serta menjelaskan praktik terbaik untuk mendesain pipeline deployment yang aman berdasarkan persyaratan kerahasiaan, integritas, dan ketersediaan Anda.
Arsitektur
Diagram berikut menunjukkan alur data dalam pipeline deployment. Panduan 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 diimplementasikan menggunakan salah satu model berikut:
Push model: Dalam model ini, Anda menerapkan pipeline deployment menggunakan sistem CI/CD pusat seperti Jenkins atau GitLab. Sistem CI/CD ini dapat berjalan di Google Cloud, di 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 menghasilkan arsitektur yang lebih terdesentralisasi dengan jumlah agen tujuan tunggal yang berpotensi besar.
Dibandingkan dengan deployment manual, penggunaan pipeline deployment secara konsisten dapat memiliki manfaat berikut:
- Peningkatan efisiensi, karena tidak diperlukan pekerjaan manual.
- Peningkatan keandalan, karena prosesnya sepenuhnya otomatis dan dapat diulang.
- Peningkatan ketertelusuran, karena Anda dapat melacak semua deployment ke perubahan dalam kode atau artefak input.
Untuk melakukan tugas, pipeline deployment memerlukan akses ke resource yang dikelolanya:
- Pipeline yang men-deploy infrastruktur menggunakan alat seperti Terraform mungkin perlu membuat, mengubah, 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 benar, aksesnya ke resource Google Cloud dapat menjadi titik lemah dalam postur keamanan Anda. Keamanan yang lemah dapat menyebabkan beberapa jenis serangan, termasuk:
Serangan poisoning pipeline: Alih-alih 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: Alih-alih menyerang pipeline deployment, pihak tidak bertanggung jawab mungkin mencoba menyusupi 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 yang mendasarinya
- Repositori kode sumber, server yang mendasarinya, dan infrastruktur yang mendasarinya
- Artefak input, lokasi penyimpanannya, dan infrastruktur yang mendasarinya
- Sistem yang menghasilkan artefak input, dan infrastruktur yang mendasarinya
Grafik input yang kompleks menyulitkan identifikasi akses pengguna ke resource dan kelemahan sistemis.
Bagian berikut menjelaskan praktik terbaik untuk mendesain pipeline deployment dengan cara yang membantu Anda mengelola ukuran grafik, dan mengurangi risiko serangan supply chain dan pergerakan lateral.
Menilai tujuan keamanan
Tingkat sensitivitas resource Anda di Google Cloud kemungkinan bervariasi. Beberapa resource mungkin sangat sensitif karena bersifat penting bagi bisnis atau bersifat rahasia. Resource lain mungkin kurang sensitif karena bersifat sementara atau hanya ditujukan untuk tujuan pengujian.
Untuk mendesain pipeline deployment yang aman, Anda harus terlebih dahulu memahami resource yang perlu diakses pipeline, dan seberapa sensitif resource ini. Semakin sensitif resource Anda, semakin Anda harus berfokus untuk mengamankan pipeline.
Resource yang diakses oleh pipeline deployment mungkin mencakup:
- Aplikasi, seperti Cloud Run atau App Engine
- Resource cloud, seperti instance VM atau bucket Cloud Storage
- Data, seperti objek Cloud Storage, kumpulan data BigQuery, atau file
Beberapa resource ini mungkin memiliki dependensi pada resource lain, misalnya:
- Aplikasi mungkin mengakses data, resource cloud, dan aplikasi lainnya.
Resource cloud, seperti instance VM atau bucket Cloud Storage, mungkin berisi aplikasi atau data.
Seperti yang ditunjukkan pada diagram sebelumnya, dependensi memengaruhi tingkat sensitivitas resource. Misalnya, jika Anda menggunakan aplikasi yang mengakses data yang sangat sensitif, biasanya Anda harus memperlakukan aplikasi tersebut sebagai sangat sensitif. Demikian pula, jika resource cloud seperti bucket Cloud Storage berisi data sensitif, Anda biasanya harus memperlakukan bucket tersebut sebagai sensitif.
Karena dependensi ini, sebaiknya perkirakan sensitivitas data Anda terlebih dahulu. Setelah menilai data, Anda dapat memeriksa rantai dependensi dan menilai sensitivitas resource dan aplikasi Cloud Anda.
Mengkategorikan sensitivitas data Anda
Untuk memahami sensitivitas data dalam pipeline deployment, 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 diberi otorisasi dapat mengakses data di pipeline deployment Anda.
Untuk setiap tujuan ini, tanyakan pada diri Anda apa yang akan terjadi jika pipeline Anda dilanggar:
- Kerahasiaan: Seberapa besar kerugian yang akan terjadi jika data diungkapkan kepada pelaku kejahatan, atau bocor ke publik?
- Integritas: Seberapa besar kerugian yang akan terjadi jika data dimodifikasi atau dihapus oleh pihak tidak bertanggung jawab?
- Ketersediaan: Seberapa besar kerugian yang akan terjadi jika pihak tidak bertanggung jawab mengganggu akses data Anda?
Agar hasilnya sebanding di seluruh resource, sebaiknya perkenalkan kategori keamanan. Standar untuk Kategorisasi Keamanan (FIPS-199) menyarankan penggunaan empat kategori berikut:
- Tinggi: Kerusakan akan sangat parah atau katastrofis
- Sedang: Kerusakan akan sangat parah
- Rendah: Kerusakan akan terbatas
- Tidak berlaku: Standar tidak berlaku
Bergantung pada lingkungan dan konteks Anda, kumpulan kategori yang berbeda mungkin lebih sesuai.
Kerahasiaan dan integritas data pipeline berada dalam 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 rendah:
- Integritas rendah: Data pengujian
- Integritas sedang: Konten server web publik, batasan kebijakan untuk organisasi Anda
- Integritas tinggi: Image container, image disk, konfigurasi aplikasi, kebijakan akses (daftar izinkan dan tolak), lien, data tingkat akses
Resource dengan kerahasiaan sedang, tetapi memiliki integritas rendah, sedang, dan tinggi
Semua contoh resource berikut memiliki kerahasiaan sedang:
- 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
Mengkategorikan aplikasi berdasarkan data yang diaksesnya
Saat aplikasi mengakses data sensitif, aplikasi dan pipeline deployment yang mengelola aplikasi juga dapat menjadi sensitif. Untuk menentukan 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 pada awalnya sebelum mendesain pipeline deployment yang aman:
- Kerahasiaan: Kategori tertinggi dari data apa pun yang diakses
- Integritas: Kategori tertinggi dari data apa pun yang diakses
- Ketersediaan: Kategori tertinggi dari data apa pun yang diakses
Penilaian awal ini 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 kumpulan data tersebut, Anda mungkin perlu mengategorikan aplikasi tersebut sebagai kerahasiaan sedang atau tinggi.
- Jika aplikasi memiliki akses ke data berintegritas tinggi, Anda biasanya harus mengategorikan aplikasi tersebut sebagai berintegritas tinggi. Namun, jika akses tersebut hanya dapat dibaca, kategorisasi integritas tinggi mungkin terlalu ketat.
Untuk mengetahui detail tentang pendekatan formal untuk mengategorikan aplikasi, lihat Panduan untuk Memetakan Jenis Informasi dan Sistem Informasi ke Kategori Keamanan (NIST SP 800-60 Vol. 2 Rev1).
Mengkategorikan resource cloud berdasarkan data dan aplikasi yang dihostingnya
Setiap 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 disk persisten, bucket Cloud Storage, atau set data BigQuery.
Jika resource cloud menghosting data atau aplikasi sensitif, resource dan pipeline deployment yang mengelola resource tersebut juga dapat menjadi sensitif. Misalnya, Anda harus menganggap layanan Cloud Run dan pipeline deployment-nya sama sensitifnya dengan aplikasi yang dihostingnya.
Setelah mengkategorikan data dan aplikasi, buat kategori keamanan awal untuk aplikasi. Untuk melakukannya, tentukan level dari kategori berikut:
- Kerahasiaan: Kategori tertinggi dari data atau aplikasi apa pun yang dihosting
- Integritas: Kategori tertinggi dari data atau aplikasi apa pun yang dihosting
- Ketersediaan: Kategori tertinggi dari data atau aplikasi apa pun 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.
- Jika Anda menyimpan salinan data yang redundan, atau menjalankan instance aplikasi yang sama dan redundan 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 sensitif, Anda harus mempertimbangkan postur keamanannya. Semakin sensitif resource, semakin baik Anda harus mencoba mengamankan pipeline. Namun, Anda mungkin mengalami batasan praktis berikut:
- Saat 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 daripada beberapa lingkungan produksi Anda.
- Saat menyiapkan infrastruktur dan sistem baru untuk menjalankan pipeline deployment, mengamankan semua komponen dengan cara yang memenuhi persyaratan keamanan paling ketat mungkin tidak hemat biaya.
Untuk mengatasi batasan ini, sebaiknya tetapkan batasan pada skenario yang harus 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 dengan hak istimewa atau sistem pengelolaan akses dengan hak istimewa, atau hal lain, 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 | Pemimpin tim harus menyetujui |
| Tinggi | Beberapa prospek harus menyetujui dan tindakan harus dicatat |
Bandingkan persyaratan ini dengan kemampuan sistem pengelolaan kode sumber (SCM) dan CI/CD Anda dengan mengajukan pertanyaan berikut dan lainnya:
- Apakah sistem SCM atau CI/CD Anda mendukung kontrol akses dan mekanisme persetujuan yang diperlukan?
- Apakah kontrol dilindungi agar tidak dirusak jika pihak tidak bertanggung jawab menyerang infrastruktur pokok?
- Apakah konfigurasi yang menentukan kontrol diamankan dengan benar?
Bergantung pada kemampuan dan batasan yang diberlakukan oleh sistem SCM atau CI/CD, Anda dapat menentukan batasan data dan aplikasi untuk pipeline deployment. Pertimbangkan panduan yang ditawarkan dalam tabel berikut:
| Kategori resource | Batasan |
|---|---|
| Rendah | Pipeline deployment dapat digunakan, dan developer dapat menyetujui deployment secara mandiri. |
| Sedang | Pipeline deployment dapat digunakan, tetapi pimpinan tim harus menyetujui setiap commit dan deployment. |
| Tinggi | Jangan gunakan pipeline deployment. Sebagai gantinya, administrator harus menggunakan sistem pengelolaan akses dengan hak 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: Pipeline deployment mungkin mendorong kode atau file konfigurasi yang salah, sehingga menyebabkan sistem yang sebelumnya berfungsi rusak, atau data tidak dapat digunakan.
- Memperpanjang pemadaman: Untuk memperbaiki pemadaman, Anda mungkin perlu menjalankan ulang pipeline deployment. Jika pipeline deployment rusak atau tidak tersedia karena alasan lain, hal ini dapat memperpanjang pemadaman.
Pipeline yang dapat menyebabkan atau memperpanjang pemadaman layanan menimbulkan risiko denial of service: pihak tidak bertanggung jawab dapat 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 ekstrem, jika pipeline deployment adalah satu-satunya cara untuk mengelola aplikasi yang penting bagi bisnis, Anda mungkin juga perlu mempertimbangkan pipeline deployment sebagai penting bagi bisnis.
Karena pipeline deployment sering kali dibuat dari beberapa sistem dan alat, mempertahankan tingkat ketersediaan yang tinggi dapat menjadi 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:
- Mengelola satu atau beberapa akun pengguna dengan akses dengan hak istimewa ke resource Google Cloud yang relevan.
- Simpan kredensial akun pengguna akses darurat di lokasi yang aman, atau gunakan sistem pengelolaan akses dengan hak istimewa untuk memediasi akses.
- Tetapkan prosedur yang dapat diikuti karyawan yang diberi otorisasi untuk mengakses kredensial.
- Audit dan tinjau penggunaan akun pengguna akses darurat.
Memastikan artefak input memenuhi permintaan ketersediaan Anda
Pipeline deployment biasanya perlu mendownload kode sumber dari repositori kode sumber sentral sebelum dapat melakukan deployment. Jika repositori kode sumber tidak tersedia, menjalankan pipeline deployment kemungkinan akan gagal.
Banyak pipeline deployment juga bergantung pada artefak pihak ketiga. Artefak tersebut
mungkin mencakup library dari sumber seperti npm, Maven Central, atau Galeri
NuGet, serta image dasar penampung, dan 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 pipeline deployment Anda semuanya memenuhi persyaratan ketersediaan yang sama atau lebih tinggi. Daftar berikut dapat membantu Anda memastikan ketersediaan artefak input:
- Membatasi jumlah sumber untuk artefak input, terutama sumber pihak ketiga
- Mengelola 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 lingkungan, mereka mungkin menerapkan beberapa tahap:
- Pada tahap pertama, pipeline deployment mengupdate lingkungan pengembangan.
- Pada tahap berikutnya, pipeline deployment akan memperbarui lingkungan staging.
- Pada tahap akhir, pipeline deployment akan memperbarui lingkungan produksi.
Saat menggunakan pipeline deployment di beberapa lingkungan, pastikan bahwa pipeline memenuhi permintaan ketersediaan setiap lingkungan. Karena lingkungan produksi biasanya memiliki permintaan ketersediaan tertinggi, Anda harus memperlakukan pipeline deployment dan infrastruktur pokoknya 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 mungkin ditimbulkannya jika disusupi. Pipeline deployment yang disusupi yang memiliki akses ke beberapa project atau bahkan seluruh organisasi Anda, dalam kasus terburuk, dapat menyebabkan kerusakan yang bertahan lama 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 di tingkat project, hanya berikan akses ke setiap resource kepada pipeline deployment.
- Hindari memberikan akses ke resource di beberapa project Google Cloud.
- Membagi pipeline deployment menjadi beberapa tahap jika memerlukan akses ke beberapa project atau lingkungan. Kemudian, amankan setiap tahap.
Menjaga kerahasiaan
Pipeline deployment harus menjaga kerahasiaan data yang dikelolanya. Salah satu risiko utama yang terkait dengan kerahasiaan adalah pemindahan data yang tidak sah.
Ada beberapa cara yang dapat digunakan pihak tidak bertanggung jawab untuk mencoba menggunakan pipeline deployment untuk memindahkan data dari resource Google Cloud Anda. Cara ini meliputi:
- Langsung: Pelaku kejahatan dapat memodifikasi pipeline deployment atau konfigurasinya sehingga mengekstrak data dari resource Google Cloud Anda, lalu menyalinnya ke tempat lain.
- Tidak langsung: Pihak tidak bertanggung jawab dapat 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 oleh pipeline deployment, lalu kategorikan.
- Temukan resource dengan kategori kerahasiaan tertinggi dan gunakan sebagai kategori awal untuk pipeline deployment.
Serupa 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 Bell–LaPadula menyarankan bahwa pipeline deployment tidak boleh:
- Menggunakan artefak input dengan kerahasiaan yang lebih tinggi
- Menulis data ke resource dengan tingkat kerahasiaan yang lebih rendah
Menurut model Bell–LaPadula, diagram sebelumnya menunjukkan cara data harus mengalir di pipeline untuk membantu memastikan kerahasiaan data.
Jangan biarkan pipeline deployment membaca data yang tidak diperlukan
Pipeline deployment sering kali tidak memerlukan akses ke data, tetapi mungkin masih memilikinya. Pemberian akses yang berlebihan tersebut dapat terjadi karena:
- Memberikan izin akses yang salah. Pipeline deployment mungkin diberikan akses ke Cloud Storage di level project, misalnya. Akibatnya, pipeline deployment dapat mengakses semua bucket Cloud Storage dalam project, meskipun akses ke satu bucket mungkin sudah cukup.
- Menggunakan peran yang terlalu permisif. Pipeline deployment mungkin diberi peran yang memberikan akses penuh ke Cloud Storage, misalnya. Namun, izin untuk membuat bucket baru sudah cukup.
Makin banyak data yang dapat diakses oleh pipeline, makin tinggi risiko seseorang atau sesuatu dapat mencuri data Anda. Untuk membantu meminimalkan risiko ini, jangan berikan akses pipeline deployment ke data apa pun yang tidak diperlukan. Banyak pipeline deployment tidak memerlukan akses data sama sekali, karena tujuan utamanya adalah untuk mengelola konfigurasi atau deployment software.
Jangan biarkan pipeline deployment menulis ke lokasi yang tidak diperlukan
Untuk menghapus data, pelaku kejahatan 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 melakukan eksfiltrasi.
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 apa pun.
- Memblokir akses internet, atau membatasi koneksi, ke kumpulan lokasi jaringan yang diizinkan.
Membatasi akses keluar sangat penting untuk pipeline yang telah Anda kategorikan sebagai moderately confidential atau highly confidential karena pipeline tersebut memiliki akses ke data rahasia atau materi kunci kriptografis.
Menggunakan Kontrol Layanan VPC untuk membantu mencegah deployment yang disusupi mencuri data
Daripada membiarkan pipeline deployment melakukan pemindahan data secara tidak sah, pelaku jahat mungkin mencoba menggunakan pipeline deployment untuk men-deploy kode yang 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. Kontrol Layanan VPC memungkinkan Anda membatasi kumpulan resource dan API yang dapat diakses dari dalam project Google Cloud tertentu.
Menjaga integritas
Untuk menjaga keamanan lingkungan Google Cloud, Anda harus melindungi integritasnya. Hal ini mencakup:
- Mencegah modifikasi atau penghapusan data atau konfigurasi yang tidak sah
- Mencegah deployment kode atau konfigurasi yang tidak tepercaya
- Memastikan semua perubahan meninggalkan jejak audit yang jelas
Pipeline deployment dapat membantu Anda mempertahankan integritas lingkungan dengan memungkinkan Anda:
- Terapkan proses persetujuan—misalnya, dalam bentuk peninjauan kode
- Menerapkan proses yang konsisten untuk semua perubahan konfigurasi atau kode
- Menjalankan pengujian otomatis atau pemeriksaan cepat sebelum setiap deployment
Agar efektif, Anda harus mencoba memastikan bahwa pihak tidak bertanggung jawab tidak dapat melemahkan atau mengabaikan tindakan ini. Untuk mencegah aktivitas tersebut, Anda harus melindungi integritas:
- Pipeline deployment dan konfigurasinya
- Infrastruktur yang mendasarinya
- Semua input yang digunakan oleh pipeline deployment
Untuk mencegah pipeline deployment menjadi rentan, cobalah untuk memastikan bahwa standar integritas pipeline deployment cocok atau melebihi permintaan integritas resource yang dikelolanya. Untuk menentukan permintaan ini, Anda dapat menggunakan pendekatan berikut:
- Tentukan data, aplikasi, dan resource yang perlu diakses oleh 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 dengan integritas yang 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
- Paket
.rpmatau.deb - Library Maven,
.npm, atau NuGet
Pihak tidak bertanggung jawab mungkin mencoba memodifikasi pipeline deployment Anda sehingga menggunakan versi artefak pihak ketiga yang disusupi dengan:
- Mengkompromikan repositori yang menyimpan artefak
- Mengubah konfigurasi pipeline deployment untuk menggunakan repositori sumber yang berbeda
- Mengupload paket berbahaya dengan nama yang mirip, 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 paket pihak ketiga yang disusupi dengan:
- Mewajibkan semua artefak pihak ketiga ditandatangani
- Mengelola daftar yang diseleksi dari sertifikat atau kunci publik penerbit tepercaya
- Mengizinkan pipeline deployment memverifikasi tanda tangan artefak pihak ketiga berdasarkan daftar penayang tepercaya
Atau, Anda dapat memverifikasi hash artefak. Anda dapat menggunakan pendekatan ini untuk artefak yang tidak mendukung penandatanganan kode dan tidak sering berubah.
Memastikan infrastruktur dasar memenuhi permintaan integritas Anda
Alih-alih membahayakan pipeline deployment itu sendiri, pihak tidak bertanggung jawab mungkin mencoba membahayakan 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 dapat sulit dideteksi.
Anda dapat membantu mengurangi risiko infrastruktur yang disusupi dengan:
- Mempertahankan infrastruktur dan semua komponennya dengan standar integritas yang sama dengan pipeline deployment dan resource Google Cloud yang dikelolanya
- Memastikan alat berasal dari sumber tepercaya dan memverifikasi keasliannya
- Membangun ulang infrastruktur secara rutin dari awal
- Menjalankan pipeline deployment di VM yang dilindungi
Menerapkan kontrol integritas di pipeline
Meskipun pihak tidak bertanggung jawab merupakan ancaman, mereka bukanlah satu-satunya sumber perubahan software atau konfigurasi yang dapat merusak integritas lingkungan Google Cloud Anda. Perubahan tersebut juga dapat berasal dari developer dan hanya bersifat tidak disengaja, karena ketidaktahuan, atau akibat kesalahan ketik dan kesalahan lainnya.
Anda dapat membantu mengurangi risiko penerapan perubahan berisiko secara tidak sengaja dengan mengonfigurasi pipeline deployment untuk menerapkan kontrol integritas tambahan. Kontrol tersebut dapat mencakup:
- Melakukan analisis statis kode dan konfigurasi
- Mewajibkan semua perubahan untuk lulus serangkaian aturan (kebijakan sebagai kode)
- Membatasi jumlah perubahan yang dapat dilakukan secara bersamaan
Langkah berikutnya
- Pelajari praktik terbaik kami untuk menggunakan akun layanan dalam deployment pipeline.
- 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.