Aturan AWS Client VPN ada pada resource, bukan subnet

Staf perlu mencapai satu aplikasi di VPC dan tidak boleh mencapai listener basis data pada instans yang sama, jadi seseorang menambahkan subnet publik kedua untuk endpoint VPN dan menyatakan persyaratan terpenuhi. Penempatan subnet mengubah perutean dan ketersediaan. Itu tidak memberi atau menahan satu port pun. Izin yang menyatakan persyaratan berada di tujuan, di grup keamanan resource, dan batas VPN menyediakan pegangan yang dirujuk aturan itu.

Penempatan subnet adalah perutean, bukan otorisasi

Di mana asosiasi jaringan endpoint berada menentukan tabel rute mana yang membawa lalu lintas klien dan zona ketersediaan mana yang bertahan saat kegagalan. Itu tidak mengatakan apa pun tentang port mana pada instans mana yang dapat dicapai lalu lintas tersebut. Dua klien yang terkait dengan subnet yang sama tetap datang dengan identitas sumber yang sama, dan resource tidak dapat membedakannya berdasarkan nama subnet.

Mulailah dari persyaratan: siapa yang memanggil, resource mana, port layanan mana, dan arah mana. Lalu pilih model aturan yang dapat menyatakan keempat hal itu di tujuan. Kerangka itu biasanya menghapus subnet tambahan sepenuhnya dari desain.

Grup asosiasi Client VPN adalah pegangannya

Untuk endpoint AWS Client VPN yang terkait subnet, susunan yang didokumentasikan bersifat spesifik. Terapkan grup keamanan yang dimaksud ke asosiasi jaringan target endpoint, lalu izinkan lalu lintas yang diperlukan di grup keamanan resource dengan menggunakan grup Client VPN itu sebagai sumber.

Secara konkret, grup instans aplikasi mengizinkan port aplikasi dari grup asosiasi, dan tidak ada yang lain. Prosedur akses resource AWS menjelaskan hubungan itu, dan sebaiknya pertahankan kebijakan grup yang sama di setiap subnet yang diasosiasikan endpoint, karena asosiasi lama dengan grup berbeda diam-diam memperlebar batas.

Aturan itu tidak mengautentikasi siapa pun. Login adalah kontrol terpisah, dan rute ke resource adalah yang ketiga. Ketiganya harus berlaku sebelum permintaan tiba. Mana yang gagal menentukan perbaikan mana yang benar, dan perubahan aturan hanyalah jawaban yang tepat untuk yang pertama.

Apa yang tidak dapat dibedakan satu grup asosiasi

Setiap klien di balik grup asosiasi yang sama mencapai resource sebagai sumber grup keamanan yang sama. Dua pengguna dengan peran berbeda tidak dapat dibedakan pada lapisan itu, apa pun nama atau tag grupnya. Otorisasi grup eksternal Client VPN membatasi akses berdasarkan prefiks tujuan untuk grup direktori atau SAML, yang lebih kasar daripada peran resource dan harus diperlakukan sebagai batas jaringan, bukan sistem identitas.

Perbedaan yang lebih halus menjadi milik aplikasi. Listener basis data yang harus tetap tertutup bagi sebagian besar staf lebih terlindungi dengan tidak dapat dijangkau sama sekali pada prefiks yang diizinkan daripada berharap keanggotaan grup tetap rapi.

Mengganti nama grup tidak menciptakan identitas, dan menduplikasinya per tim hanya melipatgandakan asosiasi yang harus diaudit.

Jangan menyalin aturan itu ke setiap desain VPN

Gateway EC2 VPN yang dikelola sendiri, perangkat inspeksi yang dirutekan, dan Client VPN terkelola adalah tiga jalur paket berbeda. Tetapkan alamat sumber mana yang benar-benar mencapai resource, apakah terjadi terjemahan di antaranya, dan mekanisme referensi mana yang didukung layanan pada jalur itu.

Meneruskan lalu lintas melalui perangkat perantara tidak mempertahankan referensi grup keamanan sumber seperti lalu lintas langsung antarinstans. AWS mendokumentasikan bahwa desain seperti itu mungkin memerlukan alamat sumber privat atau CIDR yang sesuai alih-alih referensi grup. Prosedur Client VPN terkelola bukan bukti bahwa grup terlampir setiap gateway berfungsi sebagai token identitas universal untuk paket yang diteruskan.

Satu lompatan NAT di jalur sudah cukup untuk mematahkan asumsi, dan kegagalannya tampak seperti aturan yang ada tetapi tidak pernah cocok.

Tinjau batas yang efektif

Baca setiap grup keamanan yang terlampir pada resource, karena aturan izin bergabung dan aturan sempit tidak membatalkan aturan yang lebih luas pada grup lain. Lalu periksa ACL jaringan, firewall host, dan otorisasi aplikasi itu sendiri, yang merupakan lapisan terpisah dengan kesalahan terpisah.

Akhiri dengan satu permintaan yang diizinkan dan satu permintaan yang sengaja dikecualikan terhadap resource yang sama. Pasangan itu membuktikan batas, sedangkan satu koneksi berhasil hanya membuktikan ada sesuatu yang terbuka. Konfirmasikan rute, sumber efektif, dan port layanan yang dimaksud, bukan subnet yang berisi endpoint.

Urutan kerja: tulis persyaratan empat bagian, lampirkan grup ke asosiasi, batasi aturan resource ke port, verifikasi satu izin dan satu penolakan, dan baru setelah itu pertimbangkan membagi subnet karena alasan perutean.