Privaatne RDS EC2-st: sama VPC, peering või midagi muud?

Arendaja sülearvuti jõuab privaatse RDS-i eksemplarini personali VPN-i kaudu, kuid EC2-l olev rakendus ei suuda üldse ühendust luua. See ei ole katkine juurutus. Sülearvutil on tunnel, mida EC2 eksemplar kunagi ei päri, ja „privaatne“ RDS-i puhul tähendab, et andmebaasil puudub avalik lõpp-punkt, mitte seda, et inimlikud VPN-i kasutajad on ainsad lubatud kutsujad. Rakendus vajab oma volitatud teekonda, oma turvagrupi suhet ja oma andmebaasi identiteeti ning nende kolme valimise järjekord hoiab kokku suurema osa silumisest. Otsustage esmalt marsruut, seejärel õigused ja seejärel kontrollige juurutatud keskkonnast, mitte oma töölaualt.

Sülearvuti VPN ei ole rakenduse teekond

Mida iganes personali VPN inimeste jaoks teeb, ei tee see eksemplari jaoks midagi, kui see eksemplar ei ole selgesõnaliselt sama võrguteekonna osa. Privaatses alamsõlmes olev EC2 eksemplar jõuab RDS-ini VPC marsruutimise, turvagruppide ja võrgu-ACL-ide kaudu. See ei päri inimese tunnelit, inimese seanssi ega inimese mandaate ning ei peaks: mehitamata rakenduste ühenduvus ja personali kaugjuurdepääs peavad toimima sõltumatult.

See sõltumatus on eelis. Kui VPN on maas, töötab rakendus edasi. Kui rakendus käitub valesti, ei kaota keegi oma kaugjuurdepääsu. Kujundused, mis sulatavad mõlemad üheks teekonnaks, avastatakse tavaliselt juhtumi ajal, halvimal võimalikul hetkel.

Otsus 1: sama VPC, otsene teekond

Kui rakendus ja andmebaas on samas VPC-s otsese marsruutimisega ja ilma nende vahelise kontrollseadmeta, on teekond lihtne ja turvagrupi viide on tugevaim saadaolev vahend. Andke rakendusele oma grupp ja seejärel lubage andmebaasi port sellelt grupilt, mitte aadressivahemikult:

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 on illustratiivne ja peab vastama mootorile. Grupi viide volitab liiklust rakenduse eksemplaridelt; see ei kopeeri nende reegleid ega loo andmebaasi sisselogimist. Kaks eraldi probleemi, kaks eraldi lahendust.

Seejärel kontrollige ülejäänud teekonda, selle asemel et peatuda äsja lisatud reeglil. Rakenduse väljuv poliitika, andmebaasiga seotud gruppide täielik kogum, alamsõlme marsruutimistabelid ja kõik võrgu-ACL-id peavad kokku sobima. Turvagruppide reeglid on olekupõhised, samas kui kohandatud võrgu-ACL peab lubama päringut ja tagasiliiklust eraldi reeglites, sealhulgas efemeersed pordid. Kitsas uus andmebaasireegel ei tühista ka varem lisatud laia luba.

Otsus 2: teine VPC või teine konto

Kui rakendus on teises VPC-s, valivad võrguomanikud toetatud privaatse ühenduse: peering, transit-kujundus või jagatud VPC korraldus. Siis peavad olema mõlemad marsruutimissuunad, nimede lahendamine peab RDS-i lõpp-punkti jaoks toimima ja allikas, mida andmebaasi poliitika hindab, peab vastama sellele, mis tegelikult saabub. Kattuvad konto nimed või jagatud arveldussuhe ei anna neist midagi.

Turvagrupi viide on osa, mis varieerub. See töötab mitmes privaatse ühenduse kujunduses, kuid lakkab töötamast hetkel, kui vahendav seade allika ümber kirjutab või ühenduse lõpetab, sest siis näeb andmebaas vahendavat seadet, mitte teie rakenduse gruppi. RDS-i VPC stsenaariumid eristavad sama VPC sees toimuvat juurdepääsu teistest korraldustest ja tasub kontrollida oma konkreetset topoloogiat nende vastu enne, kui eeldate, et reeglistiil kandub üle.

Ärge lahendage puuduvat marsruuti andmebaasi avalikult juurdepääsetavaks muutmisega. See on teistsugune avatuse otsus teise omanikuga ja seda pakub tavaliselt see, kes on tagajärjest kõige kaugemal.

Otsus 3: millist identiteeti andmebaas aktsepteerib

Võrgu juurdepääs ja andmebaasi autentimine on eraldi kihid ning nende segamine tekitab kõige eksitavamaid vigu. Eksemplari roll on AWS-i identiteet AWS-i API-de kutsumiseks. See ei ole andmebaasi kasutaja. IAM-i andmebaasi autentimine on toetatud funktsioon seal, kus mootor ja konfiguratsioon seda lubavad, ja see on endiselt vastendus andmebaasi kasutajale, mitte selle asendus.

Kasutage rakenduse konfiguratsioonis RDS-i lõpp-punkti nime, mitte ühest otsingust saadud aadressi. Multi-AZ ümberlülitus muudab selle nime taga olevat aadressi ja IP külge kinnitatud rakendus ebaõnnestub täpselt hetkel, kui seda vajatakse. Jätke mootori TLS-kontroll sisse, selle asemel et see välja lülitada, et viga kaoks, sest kontrolli ebaõnnestumine ütleb teile midagi lõpp-punkti kohta, kuhu jõudsite.

Seejärel andke andmebaasi kontole rakenduse jaoks vajalik miinimum, selles skeemis, mida see tegelikult kasutab. See töö on igav, seda saab auditeerida ja just selle osa kohta küsib juhtumi ülevaade.

Kontrollige juurutatud keskkonnast

Testige eksemplarilt või samast grupist, alamsõlmest ja rollist töötavalt ülesandelt. Neli tõrget näevad sülearvutist sarnased välja ja on sealt lihtsalt eristatavad: nimi, mis ei lahene, ühendus, mis aegub, TLS-i valideerimise tõrge ja tagasi lükatud andmebaasi sisselogimine. Igaüks neist osutab erinevale piirile ja andmebaasi avatuse muutmine enne, kui teate, milline neist teil on, on oletus.

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

Kui ühendus õnnestub eksemplarilt ja ebaõnnestub teie töölaualt, on rakenduse teekond korras ja parandada tuleb teie juurdepääsu. Kui see ebaõnnestub mõlemalt, alustage ülaltoodud grupi- ja marsruudikontrollidest, mitte mandaatidest. See üks võrdlus hoiab ära suurema osa segadusest, mida need piletid tekitavad.