Privatus RDS iš EC2: tas pats VPC, peering ar kažkas kita?

Kūrėjo nešiojamasis kompiuteris pasiekia privatų RDS egzempliorių per darbuotojų VPN, tačiau EC2 esanti programa visiškai negali prisijungti. Tai ne sugedęs diegimas. Nešiojamajame yra tunelis, kurio EC2 egzempliorius niekada nepaveldi, o „privatus“ RDS reiškia, kad duomenų bazė neturi viešojo galinio taško, o ne tai, kad žmogiški VPN naudotojai yra vieninteliai leidžiami skambintojai. Programai reikia savo leistino kelio, savo santykio su saugos grupe ir savo duomenų bazės tapatybės, o šių trijų pasirinkimo tvarka sutaupo didžiąją dalį derinimo. Pirmiausia nuspręskite maršrutą, tada leidimus, o tada patikrinkite iš įdiegtos aplinkos, o ne nuo savo stalo.

Nešiojamojo VPN nėra programos kelias

Kad ir ką darbuotojų VPN daro žmonėms, jis nieko nedaro egzemplioriui, nebent tas egzempliorius yra aiškiai to paties tinklo kelio dalis. EC2 egzempliorius privačiame potinklyje pasiekia RDS per VPC maršrutizavimą, saugos grupes ir tinklo ACL. Jis nepaveldi žmogaus tunelio, žmogaus sesijos ar žmogaus prisijungimo duomenų ir neturėtų to daryti: be priežiūros veikiančios programos ryšys ir darbuotojų nuotolinė prieiga turi veikti nepriklausomai.

Šis nepriklausomumas yra privalumas. Kai VPN neveikia, programa toliau dirba. Kai programa elgiasi netinkamai, niekas nepraranda nuotolinės prieigos. Projektai, kurie abu sujungia į vieną kelią, paprastai atskleidžiami incidento metu, blogiausiu įmanomu metu.

Sprendimas 1: tas pats VPC, tiesioginis kelias

Kai programa ir duomenų bazė yra tame pačiame VPC su tiesioginiu maršrutizavimu ir be jokio patikros įrenginio tarp jų, kelias yra paprastas, o saugos grupės nuoroda yra stipriausia turima priemonė. Suteikite programai savo grupę, tada leiskite duomenų bazės prievadą iš tos grupės, o ne iš adresų diapazono:

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

Prievadas yra iliustratyvus ir turi atitikti variklį. Grupės nuoroda leidžia srautą iš programos egzempliorių; ji nenukopijuoja jų taisyklių ir nesukuria prisijungimo prie duomenų bazės. Dvi atskiros problemos, du atskiri sprendimai.

Tada patikrinkite likusią kelio dalį, o ne sustokite ties taisykle, kurią ką tik pridėjote. Programos išėjimo politika, visas prie duomenų bazės prijungtų grupių rinkinys, potinklio maršruto lentelės ir visi tinklo ACL turi sutapti. Saugos grupių taisyklės yra būsenos, o tinkintas tinklo ACL turi leisti užklausą ir grįžtamąjį srautą atskirose taisyklėse, įskaitant laikinuosius prievadus. Nauja siaura duomenų bazės taisyklė taip pat nepanaikina anksčiau prijungto platesnio leidimo.

Sprendimas 2: kitas VPC arba kita paskyra

Jei programa yra kitame VPC, tinklo savininkai pasirenka palaikomą privačią jungtį: peering, tranzito dizainą ar bendro VPC susitarimą. Tada turi egzistuoti abi maršrutizavimo kryptys, vardų skaidymas turi veikti RDS galiniam taškui, o šaltinis, kurį vertina duomenų bazės politika, turi atitikti tai, kas iš tikrųjų atvyksta. Sutampantys paskyrų pavadinimai ar bendras atsiskaitymo santykis nieko iš to nesuteikia.

Saugos grupės nuoroda yra ta dalis, kuri skiriasi. Ji veikia keliuose privačių jungčių dizainuose, bet nustoja veikti tą akimirką, kai tarpinis įrenginys perrašo šaltinį arba užbaigia ryšį, nes tada duomenų bazė mato tarpinį įrenginį, o ne jūsų programos grupę. RDS VPC scenarijai atskiria prieigą tame pačiame VPC nuo kitų susitarimų, ir verta patikrinti savo konkrečią topologiją pagal juos prieš darant prielaidą, kad taisyklės stilius persikelia.

Neišspręskite trūkstamo maršruto padarydami duomenų bazę viešai prieinamą. Tai kitas atskleidimo sprendimas su kitu savininku, ir paprastai jį siūlo tas, kuris yra toliausiai nuo pasekmės.

Sprendimas 3: kokią tapatybę priima duomenų bazė

Tinklo prieiga ir duomenų bazės autentifikavimas yra atskiri sluoksniai, o jų sumaišymas sukuria labiausiai klaidinančias klaidas. Egzemplioriaus rolė yra AWS tapatybė AWS API iškvietimui. Tai nėra duomenų bazės naudotojas. IAM duomenų bazės autentifikavimas yra palaikoma funkcija ten, kur variklis ir konfigūracija leidžia, ir ji vis dar yra susiejimas su duomenų bazės naudotoju, o ne jo pakaitalas.

Programos konfigūracijoje naudokite RDS galinio taško pavadinimą, o ne adresą, paimtą iš vienos paieškos. Multi-AZ perjungimas pakeičia adresą už to pavadinimo, o prie IP pritvirtinta programa suges būtent tuo metu, kai jos reikia. Palikite variklio TLS tikrinimą įjungtą, o ne išjunkite, kad klaida išnyktų, nes tikrinimo nesėkmė ką nors pasako apie galinį tašką, kurį pasiekėte.

Tada suteikite duomenų bazės paskyrai minimumą, kurio programai reikia, toje schemoje, kurią ji iš tikrųjų naudoja. Tas darbas nuobodus, jį galima audituoti, ir būtent apie šią dalį klaus incidento apžvalga.

Patikrinkite iš įdiegtos aplinkos

Testuokite iš egzemplioriaus arba iš užduoties, veikiančios su ta pačia grupe, potinkliu ir role. Keturi gedimai atrodo panašiai iš nešiojamojo ir iš ten lengvai atskiriami: nevyrstomas vardas, pasibaigiantis ryšys, TLS validavimo gedimas ir atmestas prisijungimas prie duomenų bazės. Kiekvienas nurodo skirtingą ribą, o duomenų bazės atskleidimo keitimas prieš žinant, kurį turite, yra spėjimas.

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

Jei ryšys pavyksta iš egzemplioriaus ir nepavyksta nuo jūsų stalo, programos kelias yra tvarkingas, o taisyti reikia jūsų prieigą. Jei jis nepavyksta iš abiejų, pradėkite nuo aukščiau pateiktų grupės ir maršruto patikrų, o ne nuo prisijungimo duomenų. Tas vienas palyginimas užkerta kelią didžiajai daliai painiavos, kurią sukelia šie bilietai.