Belajar Restic - Hardening & Multi-tenant

#Pendahuluan

Episode 14 mengamankan satu repository. Tapi di perusahaan, satu infrastruktur backup melayani banyak tim: tim payments, tim web, tim data. Bila semua berbagi satu repository dan satu kunci, satu insiden keamanan di satu tim bisa membocorkan semuanya — atau satu kesalahan menghapus riwayat tim lain.

Episode ini adalah hardening untuk skala tim: model multi-tenant yang membatasi ledakan dampak.

#Satu Repository per Tenant

Aturan emas: jangan pernah mencampur data dari tenant berbeda dalam satu repository. Alasan:

Blast radius: password bocor di tenant A tidak membuka data tenant B.
Retention terpisah: tim payments butuh riwayat 1 tahun, tim web cukup 30 hari — policy forget (episode 8) berjalan independen.
Performa: check dan prune satu tenant tidak memblokir tenant lain.

Pada rest-server, setiap tenant mendapat path sendiri:

Struktur repo per tenant di rest-server

/srv/restic/
├── payments/
├── web/
└── data-platform/

Client masing-masing menunjuk ke URL-nya:

Tenant memakai repo masing-masing

restic -r rest:https://backup.example.com/payments backup /data
restic -r rest:https://backup.example.com/web backup /data

#Satu Key per Repo

Selaras dengan aturan di atas, tiap repository punya repo key (password) sendiri — hasil alami karena setiap restic init menghasilkan master key baru. Jangan pernah memakai ulang passphrase antar tenant (kebijakan episode 13). Jika satu passphrase bocor, hanya satu tenant yang terdampak.

#Isolasi Credential

#Per Tenant di rest-server

Buat user htpasswd berbeda untuk tiap tenant:

User htpasswd per tenant

htpasswd -cb /etc/restic/htpasswd payments 'pass-payments'
htpasswd -cb /etc/restic/htpasswd web 'pass-web'

#Per Tenant di S3/MinIO

Siapkan IAM user + policy terpisah yang hanya mengizinkan akses ke bucket sendiri:

Policy IAM untuk bucket tenant

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::backup-web/*"
    }
  ]
}

Credential tiap tenant disimpan di secret manager masing-masing, bukan di satu tempat bersama.

#Least Privilege Storage

Prinsipnya: beri izin paling minimal yang dibutuhkan tugas.

Client backup: hanya perlu PutObject/GetObject/ListBucket untuk bucket-nya. Tidak butuh izin mengelola bucket (DeleteBucket, IAM).
rest-server: jalankan dengan user non-root (User=restic), direktori data chown ke user tersebut.
SFTP: gunakan Match User + ForceCommand (episode 14) agar user backup tidak bisa mengeksekusi shell umum.

Direktori rest-server dijamin user non-root

sudo chown -R restic:restic /srv/restic
sudo chmod 700 /srv/restic

#Audit Akses

Hardening tidak selesai tanpa observasi. Buat audit rutin:

Log server: pantau log rest-server/nginx untuk pola login mencurigakan.
CloudTrail / MinIO audit: lacak operasi DeleteObject — siapa yang menghapus, kapan.
Review kunci berkala: restic key list per repo; hapus kunci anggota yang keluar tim.

Review key per repo (berkala)

restic -r rest:https://backup.example.com/payments key list

Warning

Pemisahan repository memperbanyak jumlah password yang harus dikelola — jangan jadikan alasan untuk menyederhanakan ke "satu password semua repo". Gunakan secret manager dan naming yang jelas, bukan memendek proses keamanan.

#Penutup

Satu repository per tenant membatasi blast radius dan memisahkan retention.
Satu repo key per repo; jangan pakai ulang passphrase antar tenant.
Isolasi credential: htpasswd per tenant, IAM user + policy per bucket.
Least privilege: client cukup Put/Get/List bucket-nya; server jalan non-root.
Audit berkala: review restic key list, log akses, dan jejak DeleteObject.
Multi-tenant = isolasi + observasi; jangan kompromikan keduanya.

Di episode 16 selanjutnya kita memasuki ruang pemulihan: troubleshooting & recovery — debugging dengan RESTIC_DEBUG dan --verbose, kasus umum seperti repo lock, S3 timeout, dan password salah, simulasi bencana dengan restore, serta pemulihan dari repository corrupt.