Belajar Infrastructure Engineer - Identity & Access Infra

#Pendahuluan

Setelah di episode 16 kita mendekatkan infrastruktur ke pengguna, kini kita mengamankan siapa yang boleh masuk: identity & access infrastructure. Di episode 11 kita menerapkan least privilege di server; episode ini naik ke level sistem: bagaimana identitas dikelola, bagaimana satu login bisa dipakai di mana-mana, dan bagaimana mesin-mesin saling mempercayai.

Mengapa topik ini penting? Karena identity adalah perimeter keamanan baru — di 2026, batas jaringan sudah larut oleh cloud dan remote work, sehingga pertanyaan "siapa/apa yang boleh akses apa" lebih penting daripada "di mana batas jaringan". Sistem identity yang buruk adalah sumber kebocoran terbesar.

#Direktori: Tempat Lahirnya Identity

LDAP (Lightweight Directory Access Protocol) adalah standar direktori: basis data hierarkis yang menyimpan user, group, dan kebijakan. Active Directory (AD) adalah implementasi Microsoft yang paling banyak dipakai enterprise — dan OpenLDAP/FreeIPA adalah alternatif open-source.

Struktur direktori LDAP

dc=lab,dc=local
├── ou=Users
│   ├── cn=budi
│   └── cn=siti
├── ou=Groups
│   ├── cn=devops
│   └── cn=db-admin
└── ou=Servers

Perintah pencarian LDAP standar:

ldapsearch -x -H ldap://ldap.lab.local -b "dc=lab,dc=local" "(uid=budi)"
ldapsearch -x -b "ou=Groups,dc=lab,dc=local" "(cn=devops)"

Peran infra engineer: menjaga high availability direktori (replikasi multi-site), backup, dan integrasi dengan sistem lain. Direktori yang mati membuat semua autentikasi terhenti — termasuk VPN, email, dan login server.

#Autentikasi Server ke Direktori

Server dan aplikasi memverifikasi user ke direktori. Pola yang paling umum di Linux:

Pola PAM + LDAP/AD

Server Linux → PAM (autentikasi) → LDAP/AD → berhasil/gagal

Dengan integrasi ini, akun tidak dibuat per-server — satu akun di direktori berlaku untuk semua server yang terhubung. Menonaktifkan user di direktori langsung menonaktifkannya di mana-mana. Ini kebalikan dari pola "buat akun manual di tiap server" yang rawan lupa di-nonaktifkan.

#SSO: Satu Login untuk Semua

SSO (Single Sign-On) membuat user login sekali lalu diakui di banyak sistem. Dua protokol utama:

Peran infra engineer: menyiapkan Identity Provider (IdP), mengintegrasikan aplikasi (SAML/OIDC), dan mengelola kepercayaan (trust). Tools umum: Keycloak (open-source), FreeIPA, atau layanan cloud (Entra ID, Okta).

#Service Account: Identity untuk Mesin

Manusia login dengan akun; otomasi login dengan service account. Aturan yang harus dipatuhi:

1. Satu service account per tujuan — jangan satu akun untuk semua job.
2. Hak seminimal mungkin — service account hanya perlu apa yang dikerjakan.
3. Kredensial dirotasi — service account yang tidak pernah dirotasi adalah bom waktu.
4. Jangan login manual dengan service account — ia untuk mesin, bukan manusia.
5. Audit penggunaan — service account mana yang dipakai di mana.

Di episode 19 kita menempatkan kredensial service account ini di secret manager (Vault) — bukan di file konfigurasi.

#PKI: Sertifikat dan Trust

Infrastruktur modern berjalan di atas trust yang ter-enkripsi: TLS untuk traffic, mTLS untuk antar layanan, dan tanda tangan untuk kode. Semuanya didukung PKI (Public Key Infrastructure).

#Komponen PKI

• CA (Certificate Authority): penerbit dan penandatangan sertifikat — sumber trust.
• Sertifikat: pasangan key publik + identitas, ditandatangani CA.
• CRL/OCSP: mekanisme mencabut sertifikat yang tidak lagi dipercaya.

#Menerbitkan Sertifikat Internal

Untuk layanan internal, kalian bisa punya CA sendiri (misal dengan Easy-RSA atau cert-manager di Kubernetes):

./easyrsa build-ca
./easyrsa gen-req api.lab.local
./easyrsa sign-req server api.lab.local
./easyrsa revoke api.lab.local
./easyrsa gen-crl

#Lifecycle Sertifikat

Praktik produksi yang benar:

1. Masa berlaku pendek (90 hari lebih baik daripada 1 tahun)
2. Rotasi otomatis (cert-manager, ACME) — bukan manual kalender
3. Monitoring expiry (alert 30/14/7 hari sebelum)
4. Satu trust store yang jelas di setiap host
5. Revoke segera saat kompromi

Sertifikat kedaluwarsa adalah penyebab outage paling memalukan di industri — selalu pantau expiry.

#mTLS: Trust Antar Layanan

Mutual TLS (mTLS) membuat dua sisi saling memverifikasi — bukan hanya klien memeriksa server. Ini fondasi service mesh (Istio, Linkerd) yang mengamankan komunikasi antar microservice. Untuk skala kecil, mTLS bisa diimplementasikan dengan Vault PKI atau cert-manager.

#Common Pitfalls Identity

• Akun duplikat di tiap server: nonaktif di satu tempat, masih hidup di tempat lain.
• Service account dipakai banyak hal: satu bocor, semuanya bisa dimasuki.
• Kredensial service account di file config: plain text di server adalah undangan.
• Sertifikat tidak dipantau: kedaluwarsa tengah malam = outage yang paling bisa dicegah.
• SSO tanpa audit: tidak tahu siapa masuk ke apa dan kapan.
• CA lemah: kunci CA yang lemah atau bocor merusak seluruh trust.

#Penutup

Pada episode 17 ini kalian telah membangun fondasi identity:

• LDAP/AD adalah direktori pusat — satu akun untuk semua server; HA dan backup-nya wajib.
• SSO (SAML/OIDC) membuat satu login diakui di mana-mana; IdP mengelola trust.
• Service account terpisah per tujuan, hak minimal, kredensial dirotasi.
• PKI menyediakan sertifikat dan trust: CA sendiri untuk internal, rotasi otomatis, dan monitoring expiry.
• mTLS mengamankan komunikasi antar layanan di arsitektur modern.

Di episode 18 selanjutnya kita masuk fase keamanan jaringan tingkat lanjut: network security infrastructure — segmentation, firewall rules, IDS/IPS, dan VPN. Sampai jumpa di episode 18!