RDS privat dari EC2: VPC yang sama, peering, atau yang lain?

Laptop pengembang menjangkau instans RDS privat melalui VPN staf, tetapi aplikasi di EC2 sama sekali tidak dapat terhubung. Ini bukan penerapan yang rusak. Laptop memiliki terowongan yang tidak pernah diwarisi oleh instans EC2, dan «privat» di RDS berarti basis data tidak memiliki titik akhir publik, bukan berarti pengguna VPN manusia adalah satu-satunya pemanggil yang diizinkan. Aplikasi memerlukan jalur resminya sendiri, hubungannya sendiri dengan grup keamanan, dan identitas basis datanya sendiri, dan urutan pemilihan ketiganya menghemat sebagian besar proses debug. Tentukan rutenya lebih dulu, lalu izinnya, lalu verifikasi dari lingkungan yang diterapkan, bukan dari meja Anda.

VPN laptop bukan jalur aplikasi

Apa pun yang dilakukan VPN staf untuk manusia, ia tidak melakukan apa pun untuk sebuah instans kecuali instans tersebut secara eksplisit menjadi bagian dari jalur jaringan yang sama. Instans EC2 di subnet privat menjangkau RDS melalui perutean VPC, grup keamanan, dan ACL jaringan. Ia tidak mewarisi terowongan, sesi, atau kredensial manusia, dan seharusnya tidak: konektivitas aplikasi tanpa pengawasan dan akses jarak jauh staf harus dapat dioperasikan secara independen.

Kemandirian itu adalah fitur. Saat VPN mati, aplikasi tetap berjalan. Saat aplikasi berperilaku buruk, tidak ada yang kehilangan akses jarak jauhnya. Desain yang menggabungkan keduanya menjadi satu jalur biasanya ditemukan saat insiden, pada momen terburuk yang mungkin.

Keputusan 1: VPC yang sama, jalur langsung

Ketika aplikasi dan basis data berada di VPC yang sama dengan perutean langsung dan tanpa kotak inspeksi di antaranya, jalurnya sederhana dan referensi grup keamanan adalah alat terkuat yang tersedia. Beri aplikasi grupnya sendiri, lalu izinkan porta basis data dari grup itu alih-alih dari rentang alamat:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

Porta hanya ilustrasi dan harus cocok dengan mesinnya. Referensi grup mengizinkan lalu lintas dari instans aplikasi; ia tidak menyalin aturannya dan tidak membuat login basis data. Dua masalah terpisah, dua perbaikan terpisah.

Lalu periksa sisa jalurnya alih-alih berhenti pada aturan yang baru saja Anda tambahkan. Kebijakan keluar aplikasi, kumpulan lengkap grup yang terpasang pada basis data, tabel rute subnet, dan ACL jaringan apa pun harus semuanya selaras. Aturan grup keamanan bersifat stateful, sedangkan ACL jaringan kustom harus mengizinkan permintaan dan lalu lintas balasan dalam aturan terpisah, termasuk porta efemeral. Aturan basis data baru yang sempit juga tidak membatalkan izin luas lama yang sudah terpasang.

Keputusan 2: VPC lain atau akun lain

Jika aplikasi berada di VPC lain, pemilik jaringan memilih interkoneksi privat yang didukung: peering, desain transit, atau pengaturan VPC bersama. Kemudian kedua arah perutean harus ada, resolusi nama harus berfungsi untuk titik akhir RDS, dan sumber yang dievaluasi kebijakan basis data harus cocok dengan apa yang benar-benar tiba. Nama akun yang serasi atau hubungan penagihan bersama tidak menyediakan semua itu.

Referensi grup keamanan adalah bagian yang bervariasi. Ia berfungsi di beberapa desain interkoneksi privat, tetapi berhenti berfungsi saat kotak perantara menulis ulang sumber atau mengakhiri koneksi, karena basis data kemudian melihat kotak perantara, bukan grup aplikasi Anda. Skenario VPC RDS memisahkan akses dalam VPC yang sama dari pengaturan lain, dan ada baiknya memeriksa topologi spesifik Anda terhadapnya sebelum mengasumsikan gaya aturan ikut terbawa.

Jangan menyelesaikan rute yang hilang dengan membuat basis data dapat diakses publik. Itu keputusan paparan yang berbeda dengan pemilik yang berbeda, dan biasanya diusulkan oleh pihak yang paling jauh dari konsekuensinya.

Keputusan 3: identitas apa yang diterima basis data

Akses jaringan dan autentikasi basis data adalah lapisan terpisah, dan mencampurnya menghasilkan kesalahan yang paling menyesatkan. Peran instans adalah identitas AWS untuk memanggil API AWS. Itu bukan pengguna basis data. Autentikasi basis data IAM adalah fitur yang didukung jika mesin dan konfigurasi mengizinkannya, dan itu tetap pemetaan ke pengguna basis data, bukan pengganti.

Gunakan nama titik akhir RDS dalam konfigurasi aplikasi alih-alih alamat yang ditangkap dari satu pencarian. Failover Multi-AZ mengubah alamat di balik nama itu, dan aplikasi yang dipatok ke IP akan gagal tepat pada saat dibutuhkan. Biarkan verifikasi TLS mesin tetap aktif alih-alih mematikannya agar kesalahan hilang, karena kegagalan verifikasi memberi tahu Anda sesuatu tentang titik akhir yang Anda capai.

Lalu berikan akun basis data minimum yang dibutuhkan aplikasi, dalam skema yang benar-benar digunakannya. Pekerjaan itu membosankan, dapat diaudit, dan itulah bagian yang akan ditanyakan tinjauan insiden.

Verifikasi dari lingkungan yang diterapkan

Uji dari instans atau dari tugas yang berjalan dengan grup, subnet, dan peran yang sama. Empat kegagalan terlihat serupa dari laptop dan mudah dibedakan dari sana: nama yang tidak terurai, koneksi yang kehabisan waktu, kegagalan validasi TLS, dan login basis data yang ditolak. Masing-masing menunjuk ke batas yang berbeda, dan mengubah paparan basis data sebelum mengetahui mana yang Anda miliki adalah dugaan.

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

Jika koneksi berhasil dari instans dan gagal dari meja Anda, jalur aplikasi baik-baik saja dan akses Andalah yang perlu diperbaiki. Jika gagal dari keduanya, mulailah dengan pemeriksaan grup dan rute di atas alih-alih kredensial. Perbandingan tunggal itu mencegah sebagian besar kerumitan yang dihasilkan tiket-tiket ini.