Belajar Vault - Secrets Engine Tambahan (TOTP, SSH & AWS)

#Pendahuluan

Setelah di episode 7 sebelumnya kita membahas PKI Secrets Engine untuk otomatisasi sertifikat TLS, pada episode kali ini kita akan menuntaskan Fase 2 dari series ini dengan tiga secrets engine tambahan yang tidak kalah sering ditemui di dunia kerja: TOTP untuk autentikasi dua faktor terpusat, SSH untuk mengamankan akses server tanpa password permanen, dan AWS untuk membuat kredensial IAM dinamis yang berumur pendek.

Kenapa topik ini penting di dunia nyata? Karena tiga engine ini menyentuh persoalan sehari-hari yang berbeda: bagaimana tim mengamankan akun-akun yang menggunakan 2FA (TOTP), bagaimana admin mengelola ribuan akses SSH ke server tanpa harus menghafal atau menyimpan private key yang tak terkendali (SSH), dan bagaimana pipeline atau aplikasi mengakses cloud tanpa menyimpan access key AWS yang panjang umur (AWS). Ketiganya memakai prinsip yang sama yang sudah kita bangun sepanjang series ini: rahasia tidak disimpan permanen, melainkan dikelola dan berumur pendek.

Mari kita bedah satu per satu, lengkap dengan praktiknya.

#Pembahasan Utama

#TOTP Secrets Engine: 2FA Terpusat

TOTP (Time-based One-Time Password) adalah mekanisme 2FA yang paling populer — aplikasi seperti Google Authenticator memakainya. Biasanya, setiap orang meng-enroll akunnya ke aplikasi TOTP di ponsel masing-masing. Tapi di perusahaan, menyebarkan secret TOTP ke ponsel pribadi karyawan bisa jadi masalah keamanan dan operasional.

Vault TOTP secrets engine memungkinkan Vault menjadi pusat pembangkit dan validasi OTP. Alurnya:

1. Admin membuat key TOTP untuk sebuah akun di Vault.
2. Vault menghasilkan key + base32 seed yang bisa di-enroll ke aplikasi authenticator siapa pun (atau Vault sendiri yang memegangnya).
3. Saat login, kode OTP bisa di-generate dari Vault (vault read totp/code/my-account) atau divalidasi di Vault (vault write totp/code/my-account code=...).
4. Semua penggunaan ter-audit di Vault.

vault secrets enable totp

Output:

Success! Enabled the totp secrets engine at: totp/

Membuat key untuk sebuah akun:

vault write totp/keys/my-account \
    url="otpauth://totp/MyOrg:arman@devvnull.local?secret=MY2PRIVATE&issuer=MyOrg"

Output:

Key       Value
---       -----
url       otpauth://totp/MyOrg:arman@devvnull.local?secret=MY2PRIVATE&issuer=MyOrg

Generate kode OTP saat ini (misalnya untuk mengisi form login dari sisi server):

vault read totp/code/my-account

Output:

Key     Value
---     -----
code    482913

Validasi kode yang dimasukkan pengguna:

vault write totp/code/my-account code=482913

Output:

Key      Value
---      -----
valid    true

#SSH Secrets Engine: Mengamankan Akses Server

Masalah klasik akses SSH: admin menyimpan private key di laptop masing-masing, atau — lebih buruk — password SSH permanen yang dipakai semua orang. Ketika satu laptop hilang, seluruh infrastruktur berisiko. Vault SSH secrets engine menawarkan dua mode yang berbeda:

#Mode SSH OTP (One-Time Password)

vault secrets enable ssh

vault write ssh/roles/otp-role \
    key_type=otp \
    default_user=ubuntu \
    cidr_list=10.0.0.0/8

Ketika user ingin login, Vault memberikan kode OTP:

vault read ssh/creds/otp-role

Output:

Key                Value
---                -----
key               a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
key_type          otp
port              22
username          ubuntu

Dengan key OTP ini, user bisa login ke server: ssh ubuntu@10.0.0.5 lalu masukkan key OTP sebagai password. Setelah dipakai sekali, OTP tersebut tidak valid lagi.

#Mode SSH CA (Signing)

Mode CA lebih elegan untuk skala besar. Prinsipnya: Vault memiliki CA SSH, dan server-server dipercaya untuk menerima key yang ditandatangani Vault. User tidak perlu menyimpan secret di Vault — cukup public key-nya yang di-sign.

vault write ssh/roles/ca-role \
    key_type=ca \
    allowed_user_domains=dev,ops \
    default_extensions="permit-pty,permit-port-forwarding" \
    allowed_users=ubuntu

User menyerahkan public key-nya untuk ditandatangani:

vault write ssh/sign/ca-role \
    public_key=@/home/arman/.ssh/id_ed25519.pub \
    valid_principals="arman"

Output:

Key            Value
---            -----
key_type       ca
signed_key     ssh-ed25519-cert-v01@openssh.com AAAA... (sertifikat SSH, bukannya sekadar public key)

Hasil signed_key adalah sertifikat SSH (bukan sekadar public key) yang memiliki masa berlaku. Server yang mempercayai Vault CA akan otomatis menerima key ini hingga TTL-nya habis — setelah itu user harus meminta tanda tangan baru.

Vault juga bisa menandatangani host keys (identitas server itu sendiri), sehingga client bisa memverifikasi bahwa server yang dituju benar-benar server milik perusahaan — mencegah serangan man-in-the-middle:

vault write ssh/sign/host-signer \
    public_key=@/etc/ssh/ssh_host_ed25519_key.pub \
    valid_principals="dev-server-01"

Output:

Key            Value
---            -----
key_type       ca
signed_key     ssh-ed25519-cert-v01@openssh.com AAAA... (sertifikat host server)

Kombinasi user CA + host CA inilah yang membentuk zero-trust SSH: user terverifikasi lewat sertifikat, server terverifikasi lewat sertifikat, dan keduanya berumur pendek. Tidak ada lagi password permanen atau host key yang dibiarkan begitu saja.

#AWS Secrets Engine: Dynamic IAM Credentials

Masalah klasik cloud: access key AWS yang dibuat sekali dan hidup bertahun-tahun, disimpan di laptop, environment variable, atau — tidak jarang — di commit Git. Jika bocor, attacker punya akses penuh ke akun AWS.

AWS secrets engine memakai prinsip dynamic secrets yang sama dengan database engine di episode 5: Vault membuat IAM credentials temporary yang otomatis kedaluwarsa.

vault secrets enable aws

Output:

Success! Enabled the aws secrets engine at: aws/

Konfigurasi kredensial AWS yang dipakai Vault untuk mengelola IAM (membuat user / menandatangani token STS):

vault write aws/config/root \
    access_key="AKIAIOSFODNN7EXAMPLE" \
    secret_key="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" \
    region="ap-southeast-1"

Buat role yang mendefinisikan kebijakan IAM untuk kredensial dinamis:

vault write aws/roles/my-role \
    credential_type=iam_user \
    policy_document=-<<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": "*"
    }
  ]
}
EOF

Sekarang, setiap kali pipeline atau aplikasi butuh akses AWS:

vault read aws/creds/my-role

Output:

Key                Value
---                -----
lease_id           aws/creds/my-role/1h2VzQ6xW9pLcN4mB7kR5sT0dF8jK3y
lease_duration     768h
lease_renewable    true
 
access_key         AKIAVPQEXAMPLEDYNAMICKEY
secret_key         5hS9mZcQwE3rTgY2uNvB6lK7xDfC0jJp
security_token     <nil>

Contoh command lain yang sering dipakai:

vault read aws/creds/my-sts-role

Output:

Key                Value
---                -----
access_key         ASIAVPQEXAMPLESHORTLIVED
secret_key         pQn1sLvXc3rTgY5uNhB7jK9mZdF2wA6y
security_token     IQoJb3JpZ2luX2Vj... (token sesi STS panjang)
lease_id           aws/creds/my-sts-role/6sR4tG8vY2mC5xH7bN9kQ3wL0zF1jD8
lease_duration     1h

#Skenario Gabungan: Ketiga Engine dalam Satu Alur

Agar gambaran ketiga engine semakin nyata, mari rangkai dalam satu skenario: sebuah perusahaan yang mengelola platform data internal.

Satu Vault cluster yang sama melayani ketiganya — masing-masing dengan mount, role, dan policy-nya sendiri. Inilah keindahan Vault: satu kontrol plane untuk semua jenis rahasia, dari kode OTP sampai kredensial cloud, dengan satu model audit dan satu model akses.

#Kapan Memakai Engine yang Mana?

Ketiga engine ini melayani kebutuhan yang berbeda — jangan sampai tertukar:

#Kesalahan Umum TOTP, SSH & AWS

#Penutup

Pada episode 8 ini kita telah melengkapi pemahaman tentang secrets engine dengan tiga engine tambahan: TOTP untuk pembangkit dan validasi OTP 2FA yang terpusat, SSH dengan dua mode (OTP sekali pakai vs CA signing) untuk mengamankan akses server, serta AWS untuk dynamic IAM credentials yang berumur pendek. Kita juga melihat perbandingan kapan memakai engine yang mana, dan jebakan-jebakan umum di masing-masing engine.

Inti episode ini: semua secrets engine Vault mengikuti pola yang sama — konfigurasi sekali, lalu kredensial dikelola dan berumur pendek, dengan akses terpusat, terpolicy, dan teraudit. Apa pun teknologi yang kalian amankan — database, data, sertifikat, login, atau cloud — pola pikirnya konsisten.

Dengan selesainya Fase 2, kalian sudah menguasai seluruh secrets engine inti Vault. Di episode 9 selanjutnya kita akan masuk ke Fase 3: Vault Policies — bagaimana mengontrol siapa yang boleh mengakses apa, dengan bahasa HCL dan konsep capabilities yang menentukan keamanan seluruh sistem. Pastikan tetap semangat!