Einkarekið RDS frá EC2: sama VPC, peering eða eitthvað annað?

Fartölva forritarans nær í einkarekna RDS-tilvikið gegnum VPN starfsfólksins, en forritið á EC2 getur alls ekki tengst. Þetta er ekki biluð uppsetning. Fartölvan hefur göng sem EC2-tilvikið erfar aldrei, og „einkarekið“ í RDS þýðir að gagnagrunnurinn hefur engan opinberan endapunkt, ekki að mannlegir VPN-notendur séu einu leyfðu hringjendurnir. Forritið þarf sína eigin leyfðu leið, sína eigin tengingu við öryggishópinn og sína eigin auðkenni í gagnagrunninum, og röðin sem þú velur þessi þrjú í sparar mestan hluta villuleitarinnar. Ákveddu leiðina fyrst, svo heimildirnar, og sannreyndu svo frá uppsettu umhverfinu frekar en frá skrifborðinu þínu.

VPN fartölvunnar er ekki leið forritsins

Hvað sem VPN starfsfólksins gerir fyrir fólk, þá gerir það ekkert fyrir tilvik nema það tilvik sé skýrlega hluti af sömu netleið. EC2-tilvik í einkareknu undirneti nær í RDS gegnum VPC-leiðsögu, öryggishópa og net-ACL. Það erfir ekki göng manneskju, lotu manneskju eða skilríki manneskju, og ætti ekki að gera það: tenging forrita án eftirlits og fjartenging starfsfólks verða að vera óháð.

Þessi sjálfstæði er kostur. Þegar VPN er niðri heldur forritið áfram að virka. Þegar forritið hegðar sér illa missir enginn fjartenginguna sína. Hönnun sem bræðir þetta tvennt í eina leið uppgötvast venjulega í atviki, á versta mögulega augnabliki.

Ákvörðun 1: sama VPC, bein leið

Þegar forritið og gagnagrunnurinn eru í sama VPC með beinni leiðsögu og engum skoðunarbúnaði á milli er leiðin einföld og tilvísunin í öryggishóp er öflugasta tólið sem völ er á. Gefðu forritinu sinn eigin hóp og leyfðu svo gagnagrunnsportið frá þeim hóp í stað þess að leyfa það frá tilteknu addressusviði:

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

Portið er dæmi og verður að passa við vélina. Hóptilvísun heimilar umferð frá tilvikum forritsins; hún afritar ekki reglur þeirra og býr ekki til innskráningu í gagnagrunninn. Tvö aðskilin vandamál, tvær aðskildar lagfæringar.

Athugaðu svo restina af leiðinni í stað þess að stöðva við regluna sem þú bættir við. Útleiðarstefna forritsins, heildarsafn hópa sem eru tengdir gagnagrunninum, leiðatöflur undirnetsins og allar net-ACL verða að stemma. Reglur öryggishópa eru stöðugar, en sérsniðin net-ACL verður að leyfa beiðnina og svörunina í aðskildum reglum, þar á meðal skammtímaport. Ný og þröng gagnagrunnsregla fellir heldur ekki úr gildi eldri víða heimild sem þegar var tengd.

Ákvörðun 2: annað VPC eða annar reikningur

Ef forritið er í öðru VPC velja neteigendurnir studda einkatengingu: peering, gegnumstreymishönnun eða sameiginlegt VPC-fyrirkomulag. Þá verða báðar leiðir leiðsögunnar að vera til staðar, nafnalausnin verður að virka fyrir RDS-endapunktinn, og uppruninn sem gagnagrunnsstefnan metur verður að passa við það sem raunverulega berst. Samhljóða reikningsheiti eða sameiginlegt reikningsviðskiptasamband veita ekkert af þessu.

Tilvísunin í öryggishóp er sá hluti sem er breytilegur. Hún virkar í nokkrum hönnunum einkatenginga, en hættir að virka á því augnabliki sem millibúnaður endurskrifar upprunann eða lýkur tengingunni, vegna þess að gagnagrunnurinn sér þá millibúnaðinn frekar en forritahópinn þinn. RDS VPC-sviðsmyndirnar aðgreina aðgang innan sama VPC frá öðrum fyrirkomulagi, og það er þess virði að bera sérstaka grannfræði þína saman við þær áður en þú gerir ráð fyrir að reglustaðall flytjist yfir.

Leystu ekki vantar leið með því að gera gagnagrunninn opinberlega aðgengilegan. Það er önnur útsetningarákvörðun með annan eiganda, og hana stingur venjulega upp á sá sem er fjærst afleiðingunni.

Ákvörðun 3: hvaða auðkenni gagnagrunnurinn samþykkir

Netaðgangur og auðkenning gagnagrunnsins eru aðskilin lög, og að rugla þeim saman framleiðir villandi villurnar. Hlutverk tilviksins er AWS-auðkenni til að kalla á AWS-API. Það er ekki gagnagrunnsnotandi. IAM auðkenning gagnagrunns er studd eiginleiki þar sem vélin og stillingin leyfa það, og hún er enn vörpun á gagnagrunnsnotanda frekar en staðgengill hans.

Notaðu heiti RDS-endapunktsins í stillingu forritsins í stað vistfangs sem fengið er úr einni leit. Multi-AZ yfirfærsla breytir vistfanginu á bak við það heiti, og forrit sem er fest við IP mun mistakast nákvæmlega á því augnabliki sem þörf er á. Hafðu TLS-sannprófun vélarinnar virka í stað þess að slökkva á henni til að láta villu hverfa, vegna þess að sannprófunarbilun segir þér eitthvað um endapunktinn sem þú náðir.

Veittu svo gagnagrunnsreikningnum það lágmark sem forritið þarf, í því skema sem það notar í raun. Sú vinna er leiðinleg, hún er endurskoðanleg, og það er hlutinn sem atvikayfirferð mun spyrja um.

Sannreyndu frá uppsettu umhverfinu

Prófaðu frá tilvikinu eða frá verkefni sem keyrir með sama hóp, undirnet og hlutverki. Fjórir mistök líta svipað út frá fartölvu og eru auðveld að greina þaðan: heiti sem leysist ekki, tenging sem rennur út, TLS-sannprófunarbilun og hafnuð innskráning í gagnagrunn. Hvert þeirra bendir á aðra mörk, og að breyta útsetningu gagnagrunnsins áður en vitað er hvert þú hefur er gisk.

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

Ef tengingin heppnast frá tilvikinu og mistekst frá skrifborðinu þínu er leið forritsins í lagi og aðgangurinn þinn er það sem þarf að laga. Ef hún mistekst frá báðum, byrjaðu á hóp- og leiðarathugununum hér að ofan frekar en skilríkjunum. Þessi eina samanburður kemur í veg fyrir mestan hluta þess ónæðis sem þessi mál skapa.