Belajar Infrastructure Engineer - Security Infrastructure

#Pendahuluan

Setelah di episode 10 kita memastikan data bisa dipulihkan, kini kita mengamankan fondasinya: security infrastructure. Di 2026, security-by-default adalah standar mutlak — bukan fitur opsional yang ditambahkan belakangan. Tim infra adalah lini pertahanan pertama: jika jaringan, server, dan identity tidak dikelola aman, seluruh sistem yang dibangun di atasnya hidup dalam bahaya.

Mengapa topik ini penting? Karena mayoritas serangan tidak menembus ciphertext canggih — mereka menembus konfigurasi yang ceroboh: port terbuka, default password, SSH tanpa key, dan privilege yang terlalu lebar. Episode ini membekali kalian defense-in-depth dan praktik hardening yang paling berdampak.

#Defense-in-Depth: Pertahanan Berlapis

Prinsip dasarnya: jangan pernah bergantung pada satu lapisan keamanan. Jika firewall ditembus, masih ada segmentasi. Jika segmentasi gagal, masih ada hardening OS. Jika itu pun gagal, masih ada monitoring dan backup.

Pola pikir yang benar: setiap lapisan diasumsikan bisa gagal — lapisan berikutnya yang menangkap.

#Hardening Server

#Meminimalkan Permukaan Serangan

Prinsip pertama hardening: semakin sedikit yang berjalan, semakin sedikit yang bisa diserang. Audit service yang aktif dan nonaktifkan yang tidak perlu:

Audit service yang berjalan

systemctl list-units --type=service --state=running
systemctl disable --now bluetooth
ss -tulpn | grep LISTEN

Setiap port yang mendengarkan adalah pintu — tanyakan pada setiap port: "Apakah ini benar-benar perlu?"

#SSH Hardening

SSH adalah pintu utama ke server kalian. Konfigurasi yang benar di /etc/ssh/sshd_config:

/etc/ssh/sshd_config (hardened)

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Protocol 2
MaxAuthTries 3
LoginGraceTime 30

Baris paling penting: PermitRootLogin no (jangan izinkan root login langsung) dan PasswordAuthentication no (hanya key). Password bisa ditebak dan dibruteforce; key tidak.

Terapkan perubahan SSH

sudo sshd -t          # validasi konfigurasi
sudo systemctl reload sshd

#Autentikasi: Key atau Fail2ban

Kombinasi yang benar:

1. Key authentication untuk semua akses.
2. User non-root + sudo untuk administrasi harian.
3. fail2ban untuk memblokir brute-force:
4. MFA untuk akses yang paling sensitif.

sudo apt install fail2ban
sudo systemctl enable --now fail2ban
fail2ban-client status sshd

#Firewall: Gerbang Utama

Firewall menentukan siapa yang boleh masuk ke port mana. Di Linux, standar modern adalah nftables (pengganti iptables) dan frontend-nya UFW atau firewalld.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp            # SSH (dibatasi IP jika bisa)
sudo ufw allow 80,443/tcp        # web
sudo ufw enable
sudo ufw status verbose

Pola deny-by-default ini penting: semua masuk diblokir kecuali yang eksplisit diizinkan. Contoh kebijakan yang lebih ketat — batasi SSH hanya dari IP tertentu:

sudo ufw allow from 10.0.0.0/8 to any port 22 proto tcp

#Identity dan Akses

#Least Privilege

Setiap user dan service mendapat akses seminimal mungkin untuk bekerja. Prinsip ini menyelamatkan dari dua arah: membatasi kerusakan jika akun diretas, dan membatasi kesalahan jika terjadi typo.

sudo useradd -m -s /bin/bash devops
echo "devops ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/devops

Perhatikan NOPASSWD — praktik baik untuk lab, tetapi di produksi sebaiknya wajib password untuk sudo (ALL=(ALL:ALL) ALL tanpa NOPASSWD) agar ada jejak dan verifikasi.

#Audit Akses Berkala

Akses yang diberikan harus ditinjau rutin: siapa yang masih punya akses, siapa yang sudah pindah tim, dan akun mana yang tidak pernah dipakai:

1. Daftar semua user server & hak sudo-nya
2. Tandai akun yang tidak dipakai > 90 hari
3. Nonaktifkan akun orang yang sudah keluar
4. Tinjau key SSH yang terpasang di authorized_keys

Akun menganggur adalah waktu yang menunggu disalahgunakan.

#Service Accounts

Otomasi butuh identitas juga — service account terpisah dari akun manusia. Aturannya: satu service account per tujuan, hak seminimal mungkin, dan kredensial dirotasi (episode 19).

#Patching: Keamanan yang Berulang

Hardening sekali tidak cukup — keamanan adalah proses berkelanjutan. Patching berkala menutup lubang yang baru ditemukan. Praktik yang benar:

1. Uji di staging dulu — jangan patch produksi langsung tanpa uji.
2. Patch window terjadwal — bulanan untuk umum, segera untuk kritikal.
3. Otomasi — Ansible untuk patch massal (episode 8).
4. Pantau CVE untuk stack yang dipakai.

Setiap Minggu: apt upgrade di staging
Akhir bulan : patch produksi (dari staging yang teruji)
Segera     : security patch kritikal

#Common Pitfalls Security

• Default password dibiarkan: database, router, dashboards dengan admin/admin adalah pintu terbuka.
• SSH dengan password: brute-force menjadi taruhan waktu — matikan sejak hari pertama.
• Port terbuka tanpa alasan: setiap port tanpa pemilik jelas harus ditutup.
• Privilege terlalu lebar: semua orang sudo = satu kebocoran menjadi kendali penuh.
• Patch menunda-nunda: lubang yang sudah punya CVE adalah kompetisi — penyerang tahu, tim belum.
• Keamanan hanya di satu lapisan: firewall kuat, tapi SSH default dan password lemah — percuma.

#Penutup

Pada episode 11 ini kalian telah menerapkan keamanan infrastruktur:

• Defense-in-depth: banyak lapisan, masing-masing diasumsikan bisa gagal.
• Hardening server: minimalkan service, matikan root login, SSH key-only, patch berkala.
• Firewall deny-by-default dengan kebijakan yang terdokumentasi.
• Least privilege untuk user, service account, dan akses yang diaudit berkala.
• Keamanan adalah proses berkelanjutan, bukan checklist sekali jalan.

Dengan ini fase kedua — basic operational & core concepts — selesai. Di episode 12 selanjutnya kita mulai fase cloud: cloud infrastructure — VPC, compute, dan storage di AWS/GCP/Azure dengan pendekatan IaC. Sampai jumpa di episode 12!