Apa bedanya secrets dan configuration?

Secrets adalah data sensitif seperti API key, password, token, dan private key. Configuration adalah pengaturan aplikasi seperti nama environment, endpoint, feature flag, dan batasan operasional yang tidak semestinya bersifat rahasia.

Mengapa secrets tidak boleh disimpan bersama konfigurasi biasa?

Karena konfigurasi sering lebih mudah diakses oleh banyak orang dan sistem. Jika secrets ikut tersimpan di sana, risiko kebocoran meningkat dan kontrol audit menjadi lebih lemah.

Apakah pemisahan secrets dan configuration membantu ISO readiness?

Ya, karena pemisahan ini mendukung kontrol akses, jejak audit, dan pengelolaan perubahan yang lebih jelas. Namun, hasil audit tetap bergantung pada implementasi menyeluruh dan penilaian auditor profesional.

Apa praktik minimal yang sebaiknya diterapkan startup SaaS di Indonesia?

Gunakan secret manager, enkripsi saat transit dan saat tersimpan, rotasi credential, pembatasan akses berbasis peran, serta review perubahan konfigurasi melalui proses yang terdokumentasi.

Secrets vs Configuration: Fondasi SaaS Patuh

Informasi waktu: Artikel ini dibuat otomatis pada 10 Juni 2026 pukul 09.21 (Asia/Jakarta, 2026-06-10T02:21:38.026Z).

Mengapa pemisahan secrets dan konfigurasi penting?

Banyak tim SaaS di Indonesia masih menyimpan API key, password database, dan token integrasi di file konfigurasi yang sama dengan pengaturan aplikasi. Secara praktis, ini terasa cepat saat tim masih kecil. Namun, saat produk tumbuh, pendekatan tersebut menjadi sumber risiko: kebocoran credential, akses berlebihan, perubahan yang sulit dilacak, dan audit yang lebih rumit.

Pemisahan secrets dan configuration adalah langkah dasar yang sering diremehkan, padahal dampaknya besar. Dengan memisahkan keduanya, tim engineering bisa mengelola perubahan operasional tanpa membuka akses ke data sensitif. Ini juga membantu perusahaan yang sedang menyiapkan kontrol keamanan dan compliance, termasuk ISO readiness, untuk menunjukkan bahwa data rahasia dikelola dengan disiplin.

Apa yang termasuk secrets dan apa yang termasuk configuration?

Cara paling sederhana untuk membedakannya adalah dengan bertanya: apakah nilai ini jika bocor bisa langsung dipakai untuk mengakses sistem atau data? Jika ya, itu secrets.

Contoh secrets:

API key untuk layanan pihak ketiga
Password database
Token akses OAuth
Private key dan sertifikat tertentu
Webhook secret
Credential service account

Contoh configuration:

Nama environment: production, staging, development
URL endpoint aplikasi
Port service
Feature flag
Timeout request
Limit rate atau quota operasional

Di lapangan, batasnya kadang tidak selalu hitam-putih. Ada nilai yang terlihat seperti konfigurasi, tetapi sebenarnya sensitif karena bisa membuka akses tidak langsung. Karena itu, tim di Jakarta maupun kota lain di Indonesia sebaiknya membuat klasifikasi internal yang jelas dan mudah dipahami developer, DevOps, dan security reviewer.

Kesalahan umum yang sering terjadi di tim SaaS

Salah satu pola yang paling sering ditemui adalah menyimpan secrets di .env lalu file itu ikut masuk ke repository, backup, atau artifact build. Pola lain adalah menyalin konfigurasi produksi ke laptop engineer untuk debugging, lalu credential tersebar tanpa kontrol yang memadai.

Kesalahan umum lainnya:

Menaruh secrets di file YAML atau JSON yang dibagikan lintas tim
Menggunakan satu credential untuk banyak environment
Tidak melakukan rotasi saat ada pergantian personel atau insiden
Memberi akses baca penuh ke terlalu banyak orang
Menganggap secret yang sudah di-encode sama dengan terenkripsi

Encoding bukan security control. Base64, misalnya, hanya mengubah format data, bukan melindunginya. Untuk SaaS yang ingin lebih siap diaudit, perlakuan terhadap secrets harus jauh lebih ketat daripada konfigurasi biasa.

Bagaimana cara memisahkan secrets dan configuration dengan benar?

Pendekatan yang baik dimulai dari desain sistem, bukan hanya tooling. Berikut prinsip yang bisa diterapkan oleh startup maupun enterprise.

1. Simpan secrets di secret manager

Gunakan secret manager atau vault yang memang dirancang untuk menyimpan credential secara aman. Aksesnya harus dibatasi, tercatat, dan bisa dirotasi. Untuk tim yang menjalankan workload di cloud maupun self-hosted, prinsipnya tetap sama: secrets tidak boleh menjadi bagian dari source code.

2. Simpan configuration di tempat yang mudah dikelola

Configuration non-sensitif bisa disimpan di environment variables, config service, atau file konfigurasi yang dikelola dengan kontrol perubahan. Yang penting, struktur dan kepemilikannya jelas. Tim produk harus bisa mengubah konfigurasi tanpa harus menyentuh secrets.

3. Terapkan prinsip least privilege

Tidak semua engineer perlu akses ke semua secrets. Pisahkan akses berdasarkan fungsi kerja: developer, SRE, security, dan admin. Untuk organisasi remote-first seperti APLINDO di Jakarta, kontrol akses yang rapi sangat membantu menjaga disiplin lintas lokasi dan lintas tim.

4. Audit perubahan secara konsisten

Perubahan konfigurasi harus bisa ditelusuri: siapa mengubah, kapan, apa yang berubah, dan mengapa. Untuk secrets, rotasi dan akses juga perlu log yang memadai. Ini penting bukan hanya untuk keamanan, tetapi juga untuk kesiapan audit.

5. Gunakan environment separation

Production, staging, dan development harus punya secrets terpisah. Jangan gunakan credential yang sama lintas environment. Jika satu environment terganggu, dampaknya tidak langsung menjalar ke seluruh sistem.

Apa dampaknya terhadap compliance dan ISO readiness?

Pemisahan secrets dan configuration membantu membangun fondasi kontrol yang sering dicari dalam audit keamanan dan compliance. Auditor biasanya ingin melihat bahwa organisasi memahami klasifikasi informasi, pembatasan akses, pengelolaan perubahan, dan perlindungan data sensitif.

Namun, penting untuk dicatat: pemisahan ini saja tidak otomatis membuat perusahaan lolos audit atau mendapatkan sertifikasi ISO. ISO readiness adalah hasil dari serangkaian kontrol yang saling mendukung, termasuk kebijakan, proses, bukti implementasi, pelatihan, dan evaluasi berkala. Karena itu, jika perusahaan sedang menargetkan ISO 27001 atau standar lain, sebaiknya libatkan auditor atau konsultan profesional untuk menilai kesenjangan secara menyeluruh.

Bagi startup yang sedang tumbuh cepat, praktik ini sering menjadi pembeda antara sistem yang “berfungsi” dan sistem yang “siap dipertanggungjawabkan”. Di Indonesia, terutama untuk bisnis B2B yang melayani enterprise, pertanyaan tentang keamanan dan tata kelola biasanya muncul lebih awal daripada yang diperkirakan.

Key takeaways

Secrets dan configuration harus diperlakukan berbeda karena tingkat risikonya berbeda.
Simpan secrets di secret manager, bukan di source code atau file konfigurasi biasa.
Terapkan least privilege, rotasi credential, dan audit perubahan yang jelas.
Pisahkan environment production, staging, dan development dengan credential terpisah.
Praktik ini membantu ISO readiness, tetapi tidak menjamin sertifikasi atau hasil legal tanpa audit profesional.

Bagaimana memulai dari minggu ini?

Mulailah dari inventaris sederhana. Daftar semua tempat di mana secrets mungkin tersimpan: repository, CI/CD, environment variables, server, dokumentasi, dan laptop engineer. Setelah itu, klasifikasikan mana yang benar-benar secrets dan mana yang hanya configuration.

Langkah berikutnya adalah memindahkan secrets paling kritis ke secret manager, lalu menghapus salinan yang tidak perlu. Setelah itu, rapikan proses deploy agar aplikasi mengambil secrets secara aman saat runtime, bukan saat source code dibangun.

Jika tim Anda belum punya standar internal, buat aturan singkat yang mudah dipatuhi: tidak boleh commit secrets, tidak boleh berbagi credential lewat chat, dan setiap akses harus punya alasan bisnis yang jelas. Aturan sederhana seperti ini sering lebih efektif daripada dokumen panjang yang jarang dibaca.

Untuk organisasi di Jakarta dan seluruh Indonesia yang sedang membangun SaaS skala serius, disiplin kecil ini akan sangat berpengaruh pada keamanan, operasional, dan kesiapan compliance. APLINDO sering melihat bahwa fondasi yang rapi di area secrets dan configuration mempercepat banyak pekerjaan lain, mulai dari hardening sistem sampai persiapan audit.

Kapan perlu bantuan eksternal?

Jika sistem Anda sudah memiliki banyak environment, banyak integrasi pihak ketiga, atau tuntutan audit dari pelanggan enterprise, bantuan eksternal bisa mempercepat penataan kontrol. Tim seperti APLINDO dapat membantu dari sisi SaaS engineering, applied AI, Fractional CTO, hingga ISO/compliance consulting, termasuk merapikan praktik pengelolaan secrets dan configuration secara bertahap.

Bantuan eksternal juga berguna saat organisasi perlu menilai apakah kontrol yang ada sudah cukup, atau masih ada celah yang harus ditutup sebelum audit formal. Pendekatan ini lebih aman daripada menebak-nebak sendiri.

Penutup

Pemisahan secrets dan configuration bukan sekadar praktik DevOps yang rapi. Ini adalah fondasi keamanan dan tata kelola yang memengaruhi cara tim membangun, mengoperasikan, dan membuktikan kontrol atas sistem mereka. Untuk SaaS di Indonesia, terutama yang sedang menyiapkan diri menghadapi pelanggan enterprise atau proses compliance, langkah ini sebaiknya diperlakukan sebagai prioritas, bukan pekerjaan sampingan.