EC2'den özel RDS: aynı VPC, peering veya başka bir şey?

Geliştiricinin dizüstü bilgisayarı özel RDS örneğine personel VPN'i üzerinden erişir, ancak EC2'deki uygulama hiç bağlanamaz. Bu bozuk bir dağıtım değildir. Dizüstünde EC2 örneğinin asla devralmadığı bir tünel vardır ve RDS'de «özel», veritabanının genel bir uç noktası olmadığı anlamına gelir, insan VPN kullanıcılarının izin verilen tek çağıranlar olduğu anlamına değil. Uygulamanın kendi yetkili rotasına, güvenlik grubuyla kendi ilişkisine ve veritabanında kendi kimliğine ihtiyacı vardır ve bu üçünü seçme sırası hata ayıklamanın çoğunu kurtarır. Önce rotaya, sonra izinlere karar verin ve ardından masanızdan değil dağıtılmış ortamdan doğrulayın.

Dizüstü VPN'i uygulamanın rotası değildir

Personel VPN'i insanlar için ne yaparsa yapsın, o örnek açıkça aynı ağ yolunun parçası olmadıkça bir örnek için hiçbir şey yapmaz. Özel bir alt ağdaki EC2 örneği RDS'ye VPC yönlendirmesi, güvenlik grupları ve ağ ACL'leri üzerinden erişir. İnsan tünelini, insan oturumunu veya insan kimlik bilgilerini devralmaz ve devralmamalıdır: denetimsiz uygulama bağlantısı ve personelin uzaktan erişimi bağımsız olarak çalışabilmelidir.

Bu bağımsızlık bir avantajdır. VPN çöktüğünde uygulama çalışmaya devam eder. Uygulama yanlış davrandığında kimse uzaktan erişimini kaybetmez. İkisini tek rotada birleştiren tasarımlar genellikle bir olay sırasında, mümkün olan en kötü anda keşfedilir.

Karar 1: aynı VPC, doğrudan rota

Uygulama ve veritabanı aynı VPC'de doğrudan yönlendirmeyle ve aralarında herhangi bir inceleme ara kutusu olmadan bulunduğunda, rota basittir ve güvenlik grubu referansı mevcut en güçlü araçtır. Uygulamaya kendi grubunu verin, sonra veritabanı bağlantı noktasına adres aralığından değil o gruptan izin verin:

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}'

Bağlantı noktası örnektir ve motorla eşleşmelidir. Grup referansı uygulamanın örneklerinden gelen trafiği yetkilendirir; kurallarını kopyalamaz ve bir veritabanı oturumu açmaz. İki ayrı sorun, iki ayrı düzeltme.

Ardından yeni eklediğiniz kuralda durmak yerine rotanın geri kalanını kontrol edin. Uygulamanın giden ilkesi, veritabanına bağlı grupların tamamı, alt ağın yönlendirme tabloları ve herhangi bir ağ ACL'si hepsi uyuşmalıdır. Güvenlik grubu kuralları durum bilgilidir, oysa özel bir ağ ACL'si isteğe ve dönüş trafiğine ayrı kurallarda izin vermelidir, geçici bağlantı noktaları dahil. Yeni ve dar bir veritabanı kuralı, zaten bağlı olan daha eski ve geniş bir izni de iptal etmez.

Karar 2: başka bir VPC veya başka bir hesap

Uygulama başka bir VPC'deyse, ağ sahipleri desteklenen bir özel bağlantı seçer: peering, bir transit tasarımı veya paylaşılan VPC düzeni. Ardından yönlendirmenin her iki yönü de var olmalıdır, ad çözümlemesi RDS uç noktası için çalışmalıdır ve veritabanı ilkesinin değerlendirdiği kaynak gerçekten gelenle eşleşmelidir. Eşleşen hesap adları veya paylaşılan faturalandırma ilişkisi bunların hiçbirini sağlamaz.

Güvenlik grubu referansı değişen kısımdır. Birkaç özel bağlantı tasarımında çalışır, ancak bir ara kutu kaynağı yeniden yazdığında veya bağlantıyı sonlandırdığında çalışmayı bırakır, çünkü veritabanı o zaman uygulama grubunuz yerine ara kutuyu görür. RDS VPC senaryoları aynı VPC içindeki erişimi diğer düzenlemelerden ayırır ve bir kural stilinin aktarıldığını varsaymadan önce kendi topolojinizi bunlara karşı kontrol etmeye değer.

Eksik bir rotayı veritabanını herkese açık hale getirerek çözmeyin. Bu, başka bir sahibi olan başka bir maruz kalma kararıdır ve genellikle sonuçtan en uzakta olan kişi tarafından önerilir.

Karar 3: veritabanının kabul ettiği kimlik

Ağ erişimi ve veritabanı kimlik doğrulaması ayrı katmanlardır ve bunları karıştırmak en yanıltıcı hataları üretir. Örneğin rolü, AWS API'lerini çağırmak için bir AWS kimliğidir. Bu bir veritabanı kullanıcısı değildir. IAM veritabanı kimlik doğrulaması, motorun ve yapılandırmanın izin verdiği yerlerde desteklenen bir özelliktir ve hâlâ bir veritabanı kullanıcısına eşlemedir, onun yerine geçmez.

Uygulamanın yapılandırmasında tek bir aramadan alınan adres yerine RDS uç noktasının adını kullanın. Multi-AZ yük devri o adın arkasındaki adresi değiştirir ve bir IP'ye sabitlenmiş uygulama tam da ihtiyaç duyulduğu anda başarısız olur. Bir hatayı ortadan kaldırmak için motorun TLS doğrulamasını kapatmak yerine açık bırakın, çünkü doğrulama başarısızlığı ulaştığınız uç nokta hakkında size bir şey söyler.

Ardından veritabanı hesabına uygulamanın ihtiyaç duyduğu minimumu, gerçekten kullandığı şemada verin. Bu iş sıkıcıdır, denetlenebilir ve bir olay incelemesinin soracağı kısım budur.

Dağıtılmış ortamdan doğrulayın

Örnekten veya aynı grup, alt ağ ve rolle çalışan bir görevden test edin. Dört hata dizüstü bilgisayardan benzer görünür ve oradan kolayca ayırt edilir: çözülemeyen bir ad, zaman aşımına uğrayan bir bağlantı, TLS doğrulama hatası ve reddedilen bir veritabanı oturumu. Her biri farklı bir sınıra işaret eder ve hangisine sahip olduğunuzu bilmeden veritabanının maruz kalmasını değiştirmek tahmindir.

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

Bağlantı örnekten başarılı olup masanızdan başarısız olursa, uygulamanın rotası iyidir ve düzeltilmesi gereken sizin erişiminizdir. İkisinden de başarısız olursa, kimlik bilgileri yerine yukarıdaki grup ve rota kontrolleriyle başlayın. Bu tek karşılaştırma, bu biletlerin yarattığı karmaşanın çoğunu önler.