Privát RDS EC2-ről: ugyanaz a VPC, peering vagy valami más?

A fejlesztő laptopja a személyzeti VPN-en keresztül éri el a privát RDS-példányt, az EC2-n futó alkalmazás viszont egyáltalán nem tud csatlakozni. Ez nem hibás telepítés. A laptopnak van egy alagútja, amelyet az EC2-példány soha nem örököl, és a RDS-ben a „privát” azt jelenti, hogy az adatbázisnak nincs nyilvános végpontja, nem azt, hogy az emberi VPN-felhasználók az egyetlen engedélyezett hívók. Az alkalmazásnak saját engedélyezett útvonalra, saját biztonságicsoport-kapcsolatra és saját adatbázis-identitásra van szüksége, és annak a háromnak a kiválasztási sorrendje spórolja meg a hibakeresés nagy részét. Először az útvonalról döntsön, aztán az engedélyekről, majd ellenőrizze a telepített környezetből, ne az íróasztalától.

A laptop VPN-je nem az alkalmazás útvonala

Bármit is tesz a személyzeti VPN az emberekért, egy példányért semmit nem tesz, hacsak az a példány kifejezetten nem része ugyanannak a hálózati útvonalnak. Egy privát alhálózatban lévő EC2-példány VPC-útválasztáson, biztonsági csoportokon és hálózati ACL-eken keresztül éri el az RDS-t. Nem örökli egy ember alagútját, munkamenetét vagy hitelesítő adatait, és nem is kellene: a felügyelet nélküli alkalmazáskapcsolatnak és a személyzet távoli hozzáférésének egymástól függetlenül működőképesnek kell lennie.

Ez a függetlenség előny. Amikor a VPN leáll, az alkalmazás tovább működik. Amikor az alkalmazás rosszul viselkedik, senki nem veszíti el a távoli hozzáférését. Azok a tervek, amelyek a kettőt egy útvonallá olvasztják, általában egy incidens során derülnek ki, a lehető legrosszabb pillanatban.

1. döntés: ugyanaz a VPC, közvetlen útvonal

Amikor az alkalmazás és az adatbázis ugyanabban a VPC-ben van közvetlen útválasztással és köztük lévő ellenőrző eszköz nélkül, az útvonal egyszerű, és a biztonságicsoport-hivatkozás a legerősebb rendelkezésre álló eszköz. Adjon az alkalmazásnak saját csoportot, majd engedélyezze az adatbázis portját abból a csoportból, ne egy címből:

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

A port szemléltető, és meg kell felelnie a motornak. A csoporthivatkozás az alkalmazás példányaitól származó forgalmat engedélyezi; nem másolja a szabályaikat, és nem hoz létre adatbázis-bejelentkezést. Két külön probléma, két külön javítás.

Ezután ellenőrizze az útvonal többi részét, ne álljon meg az imént hozzáadott szabálynál. Az alkalmazás kimenő házirendjének, az adatbázishoz csatolt csoportok teljes készletének, az alhálózat útválasztási tábláinak és minden hálózati ACL-nek összhangban kell lennie. A biztonsági csoportok szabályai állapottal rendelkeznek, míg az egyéni hálózati ACL-nek külön szabályokban kell engedélyeznie a kérést és a visszforgalmat, beleértve az efemer portokat. Az új, szűk adatbázisszabály sem töröl egy korábban már csatolt széles engedélyt.

2. döntés: másik VPC vagy másik fiók

Ha az alkalmazás másik VPC-ben van, a hálózat tulajdonosai támogatott privát összeköttetést választanak: peering, tranzit kialakítás vagy megosztott VPC-megoldás. Ekkor az útválasztás mindkét irányának léteznie kell, a névfeloldásnak működnie kell az RDS-végpont számára, és az adatbázis-házirend által értékelt forrásnak meg kell felelnie annak, ami ténylegesen megérkezik. Az egyező fióknevek vagy a közös számlázási kapcsolat ezekből semmit nem ad.

A biztonságicsoport-hivatkozás az a rész, amely változik. Több privát összeköttetési tervben működik, de abban a pillanatban megszűnik működni, amikor egy köztes eszköz átírja a forrást vagy lezárja a kapcsolatot, mert akkor az adatbázis a köztes eszközt látja, nem az alkalmazáscsoportját. Az RDS VPC-forgatókönyvek elválasztják az ugyanazon VPC-n belüli hozzáférést a többi elrendezéstől, és érdemes a konkrét topológiáját ezekhez mérnie, mielőtt feltételezi, hogy egy szabálystílus átvihető.

Ne oldja meg a hiányzó útvonalat azzal, hogy az adatbázist nyilvánosan elérhetővé teszi. Az egy másik kitettségi döntés más tulajdonossal, és általában az javasolja, aki a következménytől a legtávolabb van.

3. döntés: milyen identitást fogad el az adatbázis

A hálózati hozzáférés és az adatbázis-hitelesítés külön rétegek, és összekeverésük a legfélrevezetőbb hibákat eredményezi. A példány szerepe AWS-identitás az AWS API-k hívásához. Nem adatbázis-felhasználó. Az IAM adatbázis-hitelesítés támogatott szolgáltatás ott, ahol a motor és a konfiguráció engedi, és továbbra is leképezés egy adatbázis-felhasználóra, nem annak helyettesítése.

Az alkalmazás konfigurációjában az RDS-végpont nevét használja egyetlen lekérdezésből származó cím helyett. A Multi-AZ átkapcsolás megváltoztatja a név mögötti címet, és az IP-hez rögzített alkalmazás pontosan akkor fog meghibásodni, amikor szükség van rá. Tartsa bekapcsolva a motor TLS-ellenőrzését ahelyett, hogy kikapcsolná egy hiba eltüntetéséhez, mert az ellenőrzés kudarca valamit elmond a végpontról, amelyet elért.

Ezután adja meg az adatbázisfióknak a minimumot, amelyre az alkalmazásnak szüksége van, abban a sémában, amelyet ténylegesen használ. Az a munka unalmas, auditálható, és ez az a rész, amelyről egy incidensvizsgálat kérdezni fog.

Ellenőrizze a telepített környezetből

Teszteljen a példányról vagy egy olyan feladatból, amely ugyanazzal a csoporttal, alhálózattal és szereppel fut. Négy hiba hasonlónak tűnik laptopról, és onnan könnyen megkülönböztethető: egy név, amely nem oldódik fel, egy kapcsolat, amely időtúllépésbe fut, egy TLS-érvényesítési hiba és egy elutasított adatbázis-bejelentkezés. Mindegyik más határra mutat, és az adatbázis kitettségének módosítása előtt, hogy tudná, melyik van Önnél, találgatás.

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

Ha a kapcsolat a példányról sikeres és az íróasztaláról sikertelen, az alkalmazás útvonala rendben van, és a hozzáférését kell javítani. Ha mindkettőből sikertelen, a hitelesítő adatok helyett a fenti csoport- és útvonal-ellenőrzésekkel kezdje. Ez az egyetlen összehasonlítás megakadályozza a jegyek okozta zűrzavar nagy részét.