Belajar Backstage - Deployment Security & Hardening

#Pendahuluan

Di episode 14, kalian menghubungkan Backstage ke layanan eksternal dengan kredensial yang dijaga ketat. Episode 15 ini menutup celah yang tersisa: deployment itu sendiri. Aplikasi yang berjalan langsung di port 7007 tanpa proxy, tanpa HTTPS, dengan cookie tidak aman, adalah target empuk. Episode ini membahas deployment security & hardening — dari gerbang jaringan di depan sampai detail cookie di belakang.

#Reverse Proxy dan TLS

Backstage sebaiknya tidak berdiri sendiri di internet. Sebuah reverse proxy — nginx atau Caddy — diletakkan di depan, dan inilah satu-satunya titik yang terekspos publik. Tugas utamanya dua: meneruskan request ke backend, dan menghentikan TLS sehingga semua lalu lintas berjalan lewat HTTPS.

server {
    listen 443 ssl;
    server_name portal.example.com;
 
    ssl_certificate     /etc/letsencrypt/live/portal/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/portal/privkey.pem;
 
    location / {
        proxy_pass http://backstage-backend:7007;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Caddy adalah alternatif yang lebih sederhana karena sertifikat dikelola otomatis lewat Let's Encrypt. Apa pun pilihannya, prinsipnya sama: TLS berakhir di proxy, backend tetap berada di jaringan internal yang tidak terpapar langsung.

#Trusted Proxies

Saat proxy di depan, Backstage perlu tahu bahwa request yang datang memang lewat proxy yang dipercaya — bukan request palsu yang menyuntikkan header X-Forwarded-For seenaknya. Pastikan header X-Forwarded-Proto dan X-Forwarded-Host diteruskan dengan benar, dan konfigurasi di app-config.yaml menunjuk ke URL publik HTTPS:

app:
  baseUrl: https://portal.example.com
backend:
  listeningHost: 0.0.0.0

Dengan baseUrl yang benar, link yang dihasilkan Backstage (misalnya callback OAuth) selalu memakai URL publik, dan session tidak rusak hanya karena request berbelok lewat proxy.

#Membatasi Akses Admin

Semakin sedikit orang yang punya akses penuh, semakin kecil risiko. Kombinasi RBAC dari episode 13 dengan pembatasan di tingkat jaringan menghasilkan lapisan pertahanan: hanya group admin yang punya permission untuk mengubah konfigurasi, dan halaman admin hanya bisa diakses dari jaringan tertentu jika perlu.

Pola yang disarankan: role admin hanya untuk group kecil seperti platform-eng, akun human untuk aktivitas sehari-hari, dan akses darurat lewat mekanisme yang terdokumentasi. Akses admin yang tersebar ke banyak orang adalah salah satu penyebab utama kerusakan di produksi.

#Content Security Policy

Content Security Policy (CSP) memberi tahu browser sumber daya apa saja yang boleh dimuat halaman — skrip, style, frame, dan lainnya. Tanpa CSP, satu kerentanan XSS bisa langsung disalahgunakan. Backstage memuat banyak aset dari dirinya sendiri, dan TechDocs butuh iframe, jadi CSP perlu disusun hati-hati:

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; frame-src 'self' https://techdocs.example.com; img-src 'self' data:" always;

Aturan praktis: mulai dari yang paling ketat, lalu tambahkan sumber hanya saat fitur memang butuh — bukan menyalin header contoh secara membabi buta. Setiap penambahan sumber adalah permukaan serangan baru.

#Secure Cookies dan Sesi OAuth2

Sesi pengguna di Backstage disimpan di cookie, dan cookie yang tidak diamankan bisa dicuri lewat jaringan atau JavaScript. Pastikan cookie memakai flag secure sehingga hanya dikirim lewat HTTPS, dan sameSite untuk mempersempit permintaan lintas situs:

auth:
  session:
    secret: ${SESSION_SECRET}
  providers:
    github:
      production:
        clientId: ${GITHUB_CLIENT_ID}
        clientSecret: ${GITHUB_CLIENT_SECRET}
        callbackUrl: https://portal.example.com/api/auth/github/handler/frame

Session OAuth2 juga perlu dikonfigurasi dengan benar: secret session dijaga, callback URL konsisten dengan baseUrl, dan session di-refresh atau dihentikan saat tidak lagi dibutuhkan. Ingat pelajaran episode 14: token berumur pendek selalu lebih baik.

#Perbandingan Kontrol Keamanan

#Least Privilege untuk Integrasi

Terakhir, prinsip least privilege berlaku untuk semua integrasi: setiap token, service account, dan API key yang kalian sambungkan hanya diberi scope minimum yang dibutuhkan. Token CI yang bisa menghapus repo bukan untuk portal yang hanya membaca status. Kombinasikan dengan rotasi dari episode 14 — hak minimal dan umur pendek adalah dua kebiasaan yang saling memperkuat.

#Penutup

Episode 15 ini mengamankan deployment Backstage dari luar ke dalam: reverse proxy dengan TLS, trusted proxies, pembatasan akses admin, Content Security Policy, cookie dan sesi OAuth2 yang aman, serta prinsip least privilege untuk semua integrasi. Portal kalian kini tidak hanya berfungsi, tetapi juga layak dipakai di produksi.

Inti yang harus dibawa pulang:

• Proxy adalah pintu gerbangnya — TLS berakhir di nginx atau Caddy, backend tetap internal.
• Header dan cookie harus dipercaya — konfigurasi trusted proxies dan secure cookies adalah wajib, bukan opsional.
• CSP dimulai dari ketat — tambah sumber hanya saat fitur benar-benar butuh.
• Least privilege dan RBAC bekerja bersama — hak minimal, umur token pendek, akses admin sedikit.

Di episode 16 berikutnya, kalian memanfaatkan semua data dan akses yang sudah diamankan: search & discovery — bagaimana Backstage mengindeks entity, TechDocs, dan sumber lain, lalu mencarinya lewat satu query API.