Praktik terbaik Secret Manager

Panduan ini memperkenalkan beberapa praktik terbaik saat menggunakan Secret Manager. Panduan ini bukan daftar rekomendasi yang lengkap. Sebaiknya tinjau ringkasan platform untuk memahami gambaran umum dan ringkasan Secret Manager sebelum membaca panduan ini. Google Cloud

Kontrol akses

Akses ke Secret Manager API dilindungi oleh IAM. Ikuti prinsip hak istimewa terendah saat memberikan izin ke secret.

Kredensial diperlukan untuk mengautentikasi ke Secret Manager API. Semua library klien menggunakan strategi serupa untuk mencari kredensial yang disebut sebagai Kredensial Default Aplikasi.

  • Saat mengembangkan secara lokal, gunakan gcloud auth application-default login. Tindakan ini akan membuat file dengan kredensial yang diambil secara otomatis oleh library klien.

  • Di Compute Engine dan platform komputasi Google Cloud lainnya seperti fungsi Cloud Run, library klien mendapatkan kredensial melalui server metadata instance.

  • Di GKE, workload identity juga menyediakan kredensial melalui layanan metadata.

  • Di platform lain seperti Amazon Web Services atau Microsoft Azure, pertimbangkan untuk menyiapkan workload identity federation, yang menggunakan mekanisme identitas yang ada untuk melakukan autentikasi ke API Google Cloud .

Semua metode ini lebih disukai daripada mengekspor kredensial akun layanan karena tidak memerlukan penyimpanan dan akses rahasia tambahan yang aman di luar Secret Manager API.

Praktik coding

Hindari meneruskan secret ke aplikasi Anda melalui sistem file atau melalui variabel lingkungan. Berikut adalah beberapa alasan untuk menggunakan metode lain dalam menangani rahasia:

  • Jika rahasia dapat diakses di sistem file, kerentanan aplikasi seperti serangan penelusuran direktori dapat menjadi lebih parah karena penyerang dapat memperoleh kemampuan untuk membaca materi rahasia.

  • Saat secret digunakan melalui variabel lingkungan, kesalahan konfigurasi seperti mengaktifkan endpoint debug atau menyertakan dependensi yang mencatat detail lingkungan proses dapat membocorkan secret.

  • Saat menyinkronkan materi rahasia ke penyimpanan data lain (seperti Kubernetes Secrets), evaluasi kontrol akses yang disediakan oleh penyimpanan data tersebut. Pertimbangkan hal berikut:

    • Apakah datastore memperluas akses secret?

    • Apakah akses secret dapat diaudit?

    • Apakah penyimpanan data mematuhi persyaratan enkripsi data dalam penyimpanan dan regionalisasi Anda?

Sebaiknya gunakan Secret Manager API secara langsung menggunakan salah satu library klien yang disediakan, atau dengan mengikuti dokumentasi REST atau GRPC.

Namun, untuk beberapa integrasi produk seperti integrasi serverless, Anda dapat meneruskan secret melalui sistem file atau melalui variabel lingkungan. Untuk informasi, lihat Menggunakan Secret Manager dengan produk lain.

Administrasi

Pilih kebijakan replikasi otomatis saat membuat secret, kecuali jika workload Anda memiliki persyaratan lokasi tertentu (dapat diterapkan menggunakan batasan constraints/gcp.resourceLocations).

Referensi secret berdasarkan nomor versinya, bukan menggunakan alias terbaru. Deploy pembaruan ke nomor versi menggunakan proses rilis yang tersedia. Biasanya, hal ini berarti mengonfigurasi aplikasi Anda dengan versi secret tertentu yang dibaca saat startup. Meskipun penggunaan alias terbaru mungkin memudahkan, jika ada masalah dengan versi baru secret, workload Anda mungkin tidak akan dapat menggunakan versi secret. Dengan menyematkan ke nomor versi, konfigurasi dapat divalidasi dan di-roll back menggunakan proses rilis yang ada.

Nonaktifkan versi secret sebelum menghancurkannya atau menghapus secret. Hal ini membantu mencegah gangguan dengan menempatkan secret dalam status yang tampak sama dengan destroy, tetapi dapat dibatalkan. Artinya, Anda dapat menonaktifkan dan menunggu selama seminggu agar Anda dapat memastikan tidak ada dependensi yang tersisa sebelum menghapus data secara permanen.

Jangan menetapkan masa berlaku pada secret produksi kecuali jika Anda yakin bahwa secret tersebut harus dihapus secara permanen. Fitur masa berlaku paling cocok untuk pembersihan otomatis lingkungan sementara. Pertimbangkan kondisi IAM berbasis waktu sebagai alternatif untuk mengakhiri masa berlaku secret.

Rotasi rahasia Anda secara berkala untuk melakukan hal berikut:

  • Membatasi dampak jika terjadi kebocoran secret.

  • Pastikan individu yang tidak lagi memerlukan akses ke secret tidak dapat terus menggunakan secret yang sebelumnya diakses.

  • Mengurangi kemungkinan terjadinya gangguan.

Pantau secret di seluruh organisasi Anda menggunakan Cloud Asset Inventory karena alasan berikut:

  • Membantu mengidentifikasi rahasia di seluruh organisasi Anda.

  • Mengidentifikasi ketidaksesuaian dengan persyaratan organisasi seperti rotasi, konfigurasi enkripsi, dan lokasi.

Aktifkan log akses data untuk mendapatkan dan menganalisis informasi permintaan AccessSecretVersion. Aktifkan opsi ini di tingkat folder atau organisasi untuk menerapkan logging tanpa harus mengonfigurasinya di setiap secret atau project.

Selain kontrol IAM, Anda dapat membatasi akses ke Secret Manager API dengan kontrol berbasis jaringan dengan menyiapkan perimeter Kontrol Layanan VPC untuk organisasi Anda.

Kebijakan organisasi constraints/iam.allowedPolicyMemberDomains dapat digunakan untuk membatasi identitas yang dapat ditambahkan ke kebijakan IAM untuk secret.

Perkirakan penggunaan rahasia puncak Anda (dengan mempertimbangkan lonjakan permintaan karena deployment aplikasi serentak atau penskalaan otomatis layanan Anda) dan pastikan project Anda memiliki kuota yang cukup untuk menangani peristiwa tersebut. Jika diperlukan lebih banyak kuota, minta penambahan.

Kepatuhan residensi data

Pilih secret regional jika Anda memiliki persyaratan residensi dan kedaulatan data yang ketat. Secret regional memungkinkan Anda menyimpan data sensitif dalam lokasi geografis tertentu, sehingga memberikan jaminan lengkap dalam penyimpanan, penggunaan, dan pengiriman, serta membantu Anda mematuhi persyaratan hukum, peraturan, atau organisasi terkait residensi data.