EC2-dən özəl RDS: eyni VPC, peering və ya başqa bir yol?

Tərtibatçının noutbuku özəl RDS instansına işçi VPN-i vasitəsilə çatır, EC2-dəki tətbiq isə ümumiyyətlə qoşula bilmir. Bu, pozulmuş yerləşdirmə deyil. Noutbukda tunel var, EC2 instansı onu heç vaxt miras almır və RDS-də «özəl» o deməkdir ki, verilənlər bazasının açıq endpoint-i yoxdur, insan VPN istifadəçilərinin yeganə icazəli zəng edənlər olması deyil. Tətbiqin öz icazəli yolu, öz təhlükəsizlik qrupu əlaqəsi və öz verilənlər bazası kimliyi lazımdır və bu üçünü seçdiyiniz sıra sazlama işinin çoxunu qənaət edir. Əvvəlcə marşrutu, sonra icazələri qərar verin, sonra masanızdan deyil, yerləşdirilmiş mühitdən yoxlayın.

Noutbuk VPN-i tətbiqin yolu deyil

İşçi VPN-i insanlar üçün nə edirsə etsin, instansiya üçün heç nə etmir, məgər həmin instansiya eyni şəbəkə yolunun açıq hissəsi deyilsə. Özəl subnet-dəki EC2 instansı RDS-ə VPC marşrutlaşdırması, təhlükəsizlik qrupları və şəbəkə ACL-ləri vasitəsilə çatır. O, insanın tunelini, insanın sessiyasını və ya insanın etimadnamələrini miras almır və almamalıdır: nəzarətsiz tətbiq bağlantısı və işçilərin uzaqdan girişi ayrı-ayrı işlək olmalıdır.

Bu müstəqillik bir xüsusiyyətdir. VPN işləməyəndə tətbiq işləməyə davam edir. Tətbiq səhv davrandıqda heç kim uzaqdan girişini itirmir. İkisini bir yolə birləşdirən dizaynlar adətən hadisə zamanı, ən pis anda aşkar edilir.

Qərar 1: eyni VPC, birbaşa yol

Tətbiq və verilənlər bazası eyni VPC-də birbaşa marşrutlaşdırma ilə və aralarında yoxlama cihazı olmadan olduqda yol sadədir və təhlükəsizlik qrupu istinadı mövcud ən güclü vasitədir. Tətbiqə öz qrupunu verin, sonra verilənlər bazası portuna ünvan aralığından deyil, həmin qrupdan icazə 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}'

Port nümunədir və mühərrikə uyğun olmalıdır. Qrup istinadı tətbiq instansiyalarından trafikə icazə verir; onların qaydalarını kopyalamır və verilənlər bazası girişi yaratmır. İki ayrı problem, iki ayrı həll.

Sonra yalnız əlavə etdiyiniz qaydada dayanmayın, yolun qalanını yoxlayın. Tətbiqin çıxan siyasəti, verilənlər bazasına bağlanmış qrupların tam dəsti, subnet marşrut cədvəlləri və hər hansı şəbəkə ACL-ləri hamısı uyğun olmalıdır. Təhlükəsizlik qrupu qaydaları vəziyyət saxlayır, xüsusi şəbəkə ACL isə sorğuya və cavab trafikinə ayrı-ayrı qaydalarda, efemer portlar daxil olmaqla, icazə verməlidir. Yeni dar verilənlər bazası qaydası əvvəlcədən bağlanmış köhnə geniş icazəni də ləğv etmir.

Qərar 2: fərqli VPC və ya başqa hesab

Tətbiq başqa VPC-dədirsə, şəbəkə sahibləri dəstəklənən özəl əlaqə seçir: peering, transit dizaynı və ya ortaq VPC tənzimləməsi. Sonra marşrutlaşdırmanın hər iki istiqaməti mövcud olmalıdır, ad həlli RDS endpoint-i üçün işləməlidir və verilənlər bazası siyasətinin qiymətləndirdiyi mənbə həqiqətən gələnlə uyğun olmalıdır. Hesab adlarının uyğunluğu və ya ortaq faktura əlaqəsi bunların heç birini təmin etmir.

Təhlükəsizlik qrupu istinadı dəyişən hissədir. O, bir neçə özəl əlaqə dizaynında işləyir, lakin ara cihaz mənbəni yenidən yazdığı və ya bağlantını sonlandırdığı anda işləməyi dayandırır, çünki verilənlər bazası artıq tətbiq qrupunuzu deyil, ara cihazı görür. RDS VPC ssenariləri eyni VPC daxilində girişi digər tənzimləmələrdən ayırır və qayda üslubunun keçəcəyini fərz etməzdən əvvəl konkret topologiyanızı onlarla müqayisə etməyə dəyər.

Çatışmayan marşrutu verilənlər bazasını açıq əlçatan etməklə həll etməyin. Bu, fərqli sahibi olan fərqli bir məruz qalma qərarıdır və adətən nəticədən ən uzaq olan şəxs tərəfindən təklif olunur.

Qərar 3: verilənlər bazası hansı kimliyi qəbul edir

Şəbəkə girişi və verilənlər bazası autentifikasiyası ayrı təbəqələrdir və onları qarışdırmaq ən yanıltıcı xətaları yaradır. Instansiya rolu AWS API-lərini çağırmaq üçün AWS kimliyidir. O, verilənlər bazası istifadəçisi deyil. IAM verilənlər bazası autentifikasiyası mühərrik və konfiqurasiya imkan verdiyi yerdə dəstəklənən xüsusiyyətdir və yenə də verilənlər bazası istifadəçisinə xəritələmədir, onun əvəzi deyil.

Tətbiqin konfiqurasiyasında bir dəfə axtarışdan götürülmüş ünvan yerinə RDS endpoint adını istifadə edin. Multi-AZ yerdəyişməsi həmin adın arxasındakı ünvanı dəyişir və IP-yə bərkidilmiş tətbiq məhz lazım olduğu anda uğursuz olacaq. Xətanı yox etmək üçün mühərrikin TLS yoxlamasını söndürmək yerinə onu aktiv saxlayın, çünki yoxlama uğursuzluğu çatdığınız endpoint haqqında sizə nəsə deyir.

Sonra verilənlər bazası hesabına tətbiqin ehtiyac duyduğu minimumu, həqiqətən istifadə etdiyi sxemdə verin. Bu iş darıxdırıcıdır, audit edilə biləndir və hadisə araşdırmasının soruşacağı hissə məhz budur.

Yerləşdirilmiş mühitdən yoxlayın

Instansiyadan və ya eyni qrup, subnet və rolla işləyən tapşırıqdan test edin. Dörd uğursuzluq noutbukdan oxşar görünür və oradan asanlıqla fərqləndirilir: həll olunmayan ad, vaxtı bitən bağlantı, TLS doğrulama uğursuzluğu və rədd edilən verilənlər bazası girişi. Hər biri fərqli sərhədə işarə edir və hansının sizdə olduğunu bilməzdən əvvəl verilənlər bazasının məruz qalmasını dəyişmək təxmindir.

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

Bağlantı instansiyadan uğurlu, masanızdan uğursuzdursa, tətbiqin yolu qaydasındadır və düzəltməli olduğunuz şey sizin girişinizdir. Hər ikisindən uğursuzdursa, etimadnamələrlə deyil, yuxarıdakı qrup və marşrut yoxlamaları ilə başlayın. Bu tək müqayisə bu biletlərin yaratdığı narahatlığın çoxunu qarşısını alır.