Belajar Cloud Architect - Security Architecture & Zero Trust

#Pendahuluan

Di episode 6 kita membangun jaringan dengan kontrol akses — tetapi keamanan tidak berhenti di firewall. Episode ini menggeser pandangan kalian: keamanan bukan daftar fitur yang ditambahkan setelah sistem selesai, melainkan keputusan arsitektur yang membentuk setiap lapisan.

Ada alasan praktis: memperbaiki kerentanan arsitektural jauh lebih mahal daripada memperbaikinya saat desain. Sebuah database yang diletakkan di subnet publik (episode 6) tidak bisa "diamankan" dengan menambahkan firewall — solusinya adalah memindahkan posisinya di arsitektur. Itulah mengapa security harus by design, sejak diagram pertama.

#Security by Design

Prinsip intinya: pertimbangan keamanan menjadi bagian dari trade-off arsitektur di episode 3, bukan langkah approval di akhir. Ketika memilih arsitektur, tanyakan sejak awal:

• Siapa yang boleh mengakses apa, dari mana, dan kenapa? (identity — episode 18)
• Bagaimana data dilindungi saat transit dan saat diam? (episode 19)
• Bagaimana insiden terdeteksi dan di-respons? (episode 10, 20)
• Kontrol mana yang harus dibuktikan untuk compliance? (episode 20)

Jika jawaban atas pertanyaan ini belum jelas, arsitektur belum selesai.

#Defense in Depth

Jangan bergantung pada satu lapisan pertahanan. Jika satu lapisan gagal, lapisan berikutnya menahan. Lapisan-lapisan khas dalam arsitektur cloud:

1. Identity & Access  → siapa boleh masuk (IAM)
2. Network            → siapa boleh bicara ke siapa (segmen, SG)
3. Application        → validasi input, dependency aman
4. Data               → enkripsi at rest & in transit
5. Detection          → log, audit, alert (observability)
6. Response           → incident response, backup, recovery

Contoh nyata: database tidak cukup hanya "dilindungi security group". Tambahkan: user database terpisah dengan least privilege, enkripsi data di disk, log audit akses, backup ber-encrypt, dan alert jika ada login mencurigakan. Satu lapisan bisa gagal — sisanya tetap menahan.

#Zero Trust

#Prinsip Inti

Model keamanan lama (perimeter) menganggap semua yang ada di dalam jaringan terpercaya. Zero trust membaliknya: tidak ada entitas yang dipercaya secara default — baik di dalam maupun luar jaringan. Setiap akses harus diverifikasi.

Tiga pilar zero trust:

• Never trust, always verify — setiap request diautentikasi dan diotorisasi, termasuk antar-service.
• Least privilege — akses seminimal mungkin, sesingkat mungkin.
• Assume breach — desain seolah-olah penyerang sudah ada di dalam jaringan.

#Penerapan dalam Arsitektur

Praktik nyata zero trust di cloud:

• Micro-segmentation: pisahkan setiap service di segmen sendiri; komunikasi lintas-segmen melalui kontrol eksplisit.
• mTLS antar-service: setiap service membuktikan identitasnya dengan sertifikat (episode 19).
• Short-lived credentials: tidak ada key statis; pakai role dengan masa hidup singkat (episode 18).
• Continuous validation: akses tidak permanen — dicek ulang berdasarkan konteks (device, lokasi, risiko).

#Compliance Mapping (CIS / NIST)

Aman secara teknis dan mampu dibuktikan adalah dua hal berbeda. Framework compliance memberi bahasa untuk pembuktian:

Tugas arsitek: memetakan kontrol arsitektur ke kontrol framework. Contoh mapping sederhana:

Mapping ini bukan pekerjaan audit tahunan — ia menjadi design input dari awal. Episode 20 akan membahas arsitektur untuk sertifikasi lebih dalam.

#Praktik: Threat Modeling untuk Arsitektur

Cara paling praktis menemukan celah desain: threat modeling. Pendekatan umum adalah STRIDE — kategorikan ancaman per komponen:

• Spoofing — pemalsuan identitas (mTLS, authn kuat)
• Tampering — modifikasi data (integrity checks, signing)
• Repudiation — penyangkalan aksi (audit log)
• Information disclosure — kebocoran data (encryption, least privilege)
• Denial of service — layanan lumpuh (scaling, rate limiting, WAF)
• Elevation of privilege — kenaikan hak akses (RBAC ketat, boundary)

Komponen: API Gateway + Lambda + DynamoDB
Spoofing        → API key + authn user; JWT signature dicek
Tampering       → input divalidasi; request di-log
Repudiation     → setiap akses punya audit trail
Info disclosure → data di-encrypt at rest; response tidak bocorkan detail
DoS             → rate limiting di gateway; scaling otomatis
Elevation       → Lambda pakai role scope sempit, bukan admin

Output threat model adalah daftar risiko + mitigasi yang bisa ditindaklanjuti. Masukkan hasilnya ke ADR (episode 3) dan jadikan bahan review berkala.

#Penutup

Inti yang harus dibawa pulang:

• Security by design: keamanan adalah trade-off arsitektur sejak diagram pertama.
• Defense in depth: jangan pernah bergantung pada satu lapisan pertahanan.
• Zero trust: tidak ada yang dipercaya default; verifikasi semua akses, asumsikan breach.
• Mapping ke CIS/NIST membuat keamanan bisa dibuktikan, bukan hanya diklaim.
• Threat modeling (STRIDE) menemukan celah desain sebelum diimplementasi.

Di episode 8 selanjutnya kita akan membahas reliability & resilience design — fault tolerance, high availability, pola disaster recovery, dan error budget ala SRE. Sampai jumpa di episode 8!