# Memisahkan jaringan layanan dan membatasi koneksi keluar

Sumber diperiksa. Metode: https://kompli.id/metodologi/.

Segmentasi perlu diuji pada hubungan antar-layanan, termasuk koneksi keluar. Diagram, subnet dan gateway belum membuktikan semua jalur lain tertutup.

URL kanonis: https://kompli.id/panduan/keamanan/segmentasi-jaringan-layanan/
Sumber diakses: 2026-10-02
Diperbarui: 2026-10-02
Penulis: Kompli
Sumber diperiksa: 2026-10-02


## Alur mana yang memang dibutuhkan?

**Mulai dari daftar koneksi yang diperlukan, lalu buktikan bahwa koneksi lain ditolak.** Nama “jaringan internal” atau subnet terpisah belum menunjukkan layanan mana yang masih bisa dihubungi.

Segmentasi membatasi hubungan antar-bagian sistem. *Ingress* adalah koneksi masuk; *egress* adalah koneksi keluar dari layanan yang diperiksa. Tujuannya mengurangi jalur akses yang tidak diperlukan, bukan menggantikan autentikasi, izin aplikasi, patch atau enkripsi.

## Buat peta kecil yang bisa diuji

Contoh berikut untuk layanan pesanan fiktif. Port adalah contoh arsitektur, bukan aturan wajib bagi semua sistem.

| Alur | Keputusan dan bukti yang dibutuhkan |
| --- | --- |
| Frontend → API pesanan, TLS 443 | Izinkan jalur fitur; API tetap memeriksa akun dan tindakan. |
| API pesanan → database pesanan, TCP 5432 | Izinkan dari workload yang perlu; uji frontend dan layanan lain ditolak. |
| API → resolver DNS yang dipilih, UDP/TCP 53 | Uji resolusi nama; jangan menganggap UDP saja mencakup setiap respons DNS. |
| API → integrasi pembayaran, TLS 443 | Tetapkan tujuan dan pemilik; jangan membuka semua koneksi internet demi satu integrasi. |
| Pengelola → jalur admin | Akses melalui mekanisme admin yang disepakati, dengan identitas dan pencatatan. |

Tambahkan queue, log, monitoring, registry image dan tugas cadangan bila diperlukan. Catat sumber, tujuan, protokol, port, alasan, pemilik dan pengecualian. Pisahkan kebutuhan produksi dari lingkungan uji.

## Tempatkan pembatasan pada jalur yang digunakan

Tentukan titik pengendalian: firewall, aturan jaringan cloud, host atau plugin cluster. Periksa jalur yang melewati perantara maupun yang menuju layanan secara langsung. Gateway yang memeriksa permintaan belum membatasi akses langsung ke alamat backend.

Alamat dapat berubah; periksa cara memilih tujuan pada platform Anda. Pembatasan DNS saja tidak membuktikan koneksi ke IP langsung ditolak. Core NetworkPolicy Kubernetes memakai pilihan pod/namespace atau blok IP, bukan daftar nama domain tujuan. NAT dan cara plugin menegakkan aturan juga perlu diperiksa pada lingkungan yang digunakan.

Untuk Kubernetes, detail pemilihan pod, DNS dan beberapa workload ada di [panduan cluster](/panduan/keamanan/pemeriksaan-keamanan-kubernetes/). Policy bersifat aditif: aturan lain yang membuka akses tetap berpengaruh. Jika kedua sisi telah diisolasi, izin egress sumber dan ingress tujuan harus sama-sama mencakup koneksinya.

## Contoh lokal: gateway dengan dua tujuan

[Unduh lab operasi infrastruktur 1.0](/unduhan/lab-operasi-infrastruktur-v1.zip). `operations-lab.mjs` dijalankan **2 Oktober 2026** dengan Node **24.21.0**; bagian jaringan memuat **delapan kasus**. Dua layanan HTTP buatan dan gateway hanya mendengar di loopback komputer uji. Header khusus memasok identitas A/B; ini tidak menguji autentikasi.

| Percobaan aktual | Hasil |
| --- | --- |
| A meminta katalog melalui gateway | HTTP 200 dan penanda layanan yang benar. |
| B meminta katalog; A meminta admin atau tujuan tak dikenal | HTTP 403 pada gateway. |
| Aturan diubah agar B boleh membaca katalog | HTTP 200; akses berubah mengikuti policy contoh. |
| Aturan dikembalikan, memakai permintaan baru | B kembali 403; A tetap 200. |
| Client menghubungi layanan admin langsung | HTTP 200: gateway saja tidak mengisolasi jaringan. |

HTTP hanya untuk penanda buatan di lab. Contoh ini menguji keputusan gateway dan alur lokal, **bukan firewall, NetworkPolicy, DNS atau jaringan cloud**. Kasus akses langsung sengaja tetap terbuka untuk memperlihatkan batasnya; jangan menyalin arsitektur tersebut sebagai pembatasan produksi.

## Bagaimana memeriksa pembatasan sebenarnya?

Di lingkungan uji yang telah diizinkan, jalankan koneksi yang dibutuhkan dan yang dilarang dari sumber yang berbeda. Gunakan koneksi baru setelah perubahan; sesi lama dapat mempunyai perilaku berbeda. Periksa tujuan benar-benar hidup melalui kontrol positif, agar timeout tidak keliru dianggap bukti penolakan.

Rencana yang belum dijalankan pada batch ini: DNS UDP/TCP, egress tujuan diizinkan/ditolak, perubahan IP tujuan, beberapa node/workload, bypass langsung, serta jalur admin dan cadangan. Simpan versi platform/plugin, aturan efektif, waktu, sumber/tujuan, hasil dan bukti. Tidak ada cluster, VM atau firewall komputer kerja yang diubah.

## Terapkan bertahap dan periksa ulang

Pilih satu alur, tinjau kebutuhan tim terkait, uji, lalu siapkan langkah pemulihan yang disetujui. Pengecualian perlu pemilik dan waktu peninjauan; jangan membiarkan aturan “izinkan semua” tanpa tindak lanjut.

Pantau perubahan izin melalui [pemeriksaan konfigurasi produksi](/panduan/keamanan/pemantauan-perubahan-konfigurasi/). Pengantar perangkat kerja tetap di [panduan jaringan dan perangkat](/panduan/keamanan/keamanan-jaringan-dan-perangkat-kerja/); artikel ini berfokus pada alur layanan yang bisa dibuktikan.

Bagian panduan yang diringkas dari OWASP mengikuti [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/), dengan perubahan bahasa dan contoh. Kode, worksheet dan hasil contoh orisinal Kompli memakai CC0 1.0.
## Sumber rujukan

- [OWASP Network Segmentation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) — Zona layanan, interaksi antar-sistem dan kebijakan jaringan; bukan jaminan mencegah seluruh serangan.
- [Kubernetes — Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) — NetworkPolicy: ingress/egress, kebutuhan plugin enforcement, policy aditif dan batas API.

## Perlu membahas kebutuhan tim Anda?

Ceritakan sistem yang dikelola dan kebutuhan pengamanan tim Anda.

[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=keamanan)

## Bacaan terkait

- [Keamanan jaringan dan perangkat kerja: mulai dari akses](https://kompli.id/panduan/keamanan/keamanan-jaringan-dan-perangkat-kerja/)
- [Keamanan cloud dan infrastruktur: siapa mengurus apa?](https://kompli.id/panduan/keamanan/keamanan-cloud-dan-infrastruktur/)
- [Pemeriksaan keamanan Kubernetes: akses, workload, dan jaringan](https://kompli.id/panduan/keamanan/pemeriksaan-keamanan-kubernetes/)
- [Memantau perubahan konfigurasi dan penyimpangan di produksi](https://kompli.id/panduan/keamanan/pemantauan-perubahan-konfigurasi/)