10.5 Security: Bukan Tambahan, Tapi Bagian dari Rancangan

Data yang mengalir perlu diamankan, dan itu membawa kita ke security view. Saya pernah melihat sebuah tim membangun sistem rekomendasi yang bekerja dengan baik di lingkungan development. Semua fitur berfungsi, model memberikan prediksi yang akurat, dan integrasi dengan CRM berjalan mulus. Lalu ketika sistem akan diluncurkan ke produksi, tim security datang dengan pertanyaan yang membuat semua orang terdiam: “Siapa yang bisa mengakses API ini? Bagaimana data customer diamankan? Apa yang terjadi kalau ada yang menyalahgunakan sistem ini?”

Tim itu tidak punya jawaban. Security tidak pernah dibahas dalam rancangan awal. Mereka menganggap security adalah urusan tim infrastruktur yang akan mengurus nanti. Akibatnya, peluncuran tertunda dua bulan karena mereka harus membongkar arsitektur yang sudah jadi dan menambahkan lapisan keamanan dari belakang.

Inilah mengapa security harus menjadi bagian dari rancangan sejak awal, bukan tempelan di akhir. Dalam solution architecture, security view bukan sekadar daftar checklist tentang password dan firewall. Ini adalah cara berpikir yang menjawab pertanyaan: siapa yang boleh melakukan apa, bagaimana kita melindungi data, dan apa yang terjadi jika ada yang mencoba menyalahgunakan sistem.

Mulailah dengan identity dan permission. Setiap pengguna atau sistem yang mengakses solusi Anda harus memiliki identitas yang jelas. Apakah user adalah customer, sales, atau admin? Apakah sistem lain yang terintegrasi memiliki service account sendiri? Dari situ, Anda merancang permission: siapa yang boleh membaca data, siapa yang boleh menulis, dan siapa yang boleh mengubah konfigurasi. Jangan membuat satu pintu masuk untuk semua orang dengan akses yang sama.

Berikut contoh sederhana policy akses berbasis peran (RBAC) dalam YAML yang bisa menjadi acuan awal.

roles:
  - name: customer
    permissions:
      - action: GET
        resource: /api/recommendations/{userId}
        condition: request.userId == resource.userId
  - name: sales
    permissions:
      - action: GET
        resource: /api/recommendations/*
      - action: POST
        resource: /api/feedback
  - name: admin
    permissions:
      - action: GET
        resource: /api/*
      - action: POST
        resource: /api/*
      - action: PUT
        resource: /api/*
      - action: DELETE
        resource: /api/*

Bayangkan alur berikut sebagai panduan visual untuk merancang keamanan sejak awal.

flowchart TD A[Identitas Pengguna/Sistem] --> B{Permission} B --> C[Read] B --> D[Write] B --> E[Config] C --> F[Secret Management] D --> F E --> F F --> G[Enkripsi in-transit] F --> H[Enkripsi at-rest] G --> I[Audit Log] H --> I I --> J{Skenario} J --> K[Normal: Akses Sah] J --> L[Penyalahgunaan: Deteksi Anomali] L --> M[Blokir & Alert]

Selanjutnya, secret management. Setiap sistem yang berkomunikasi membutuhkan kredensial: API key, token, password database, atau sertifikat. Jangan pernah menyimpan secret ini di dalam kode atau file konfigurasi yang ikut di-commit ke repository. Gunakan vault atau secret store yang terpisah, dan pastikan hanya sistem yang berwenang yang bisa mengaksesnya.

Encryption harus ada di dua tempat: saat data bergerak (in transit) dan saat data disimpan (at rest). Data customer yang Anda ambil dari CRM harus dienkripsi saat dikirim melalui jaringan, dan juga saat disimpan di database sistem rekomendasi. Jangan berasumsi bahwa jaringan internal sudah aman.

Yang sering terlewat adalah threat model. Ini adalah latihan sistematis untuk membayangkan bagaimana seseorang bisa menyalahgunakan sistem Anda. Siapa yang mungkin menjadi penyerang? Apa motifnya? Jalur mana yang bisa mereka gunakan? Misalnya, dalam sistem rekomendasi, abuse case bisa berupa seseorang yang sengaja mengirim data palsu untuk memanipulasi hasil rekomendasi, atau user yang mencoba mengakses rekomendasi customer lain dengan memodifikasi parameter API. Dengan membayangkan skenario ini di awal, Anda bisa merancang mitigasi sebelum kode ditulis.

Di sinilah AI bisa membantu. Anda bisa meminta AI assistant untuk menyusun threat model awal berdasarkan deskripsi arsitektur Anda. Beri prompt seperti: “Ini adalah sistem rekomendasi yang mengambil data dari CRM dan sistem transaksi, lalu menampilkan hasil ke aplikasi mobile sales. Bantu saya menyusun daftar potensi ancaman dan abuse case.” AI akan memberikan daftar yang bisa Anda gunakan sebagai titik awal, lalu Anda dan tim security bisa memperdalamnya.

Terakhir, compliance. Setiap industri punya aturan yang berbeda. Jika Anda menangani data keuangan, ada regulasi perbankan. Jika data kesehatan, ada kerahasiaan medis. Jika data customer lintas negara, ada perlindungan data pribadi. Arsitek harus tahu aturan mana yang berlaku dan memastikan rancangan sudah memenuhinya sejak awal.

Security bukan penghalang. Security adalah fondasi yang membuat solusi Anda layak berjalan di dunia nyata. Setelah Anda memastikan data aman dan akses terkontrol, langkah selanjutnya adalah memastikan solusi Anda bisa dioperasikan dengan efisien. Itu membawa kita ke operability view.