Privāts RDS no EC2: tas pats VPC, peering vai kas cits?

Izstrādātāja klēpjdators sasniedz privāto RDS instanci caur personāla VPN, bet lietojumprogramma EC2 vispār nevar izveidot savienojumu. Tā nav salauzta izvietošana. Klēpjdatoram ir tunelis, ko EC2 instance nekad nemanto, un „privāts“ RDS nozīmē, ka datubāzei nav publiska galapunkta, nevis to, ka cilvēki VPN lietotāji ir vienīgie atļautie zvanītāji. Lietojumprogrammai ir vajadzīgs savs atļautais ceļš, sava attiecība ar drošības grupu un sava datubāzes identitāte, un secība, kādā izvēlaties šos trīs, ietaupa lielāko daļu atkļūdošanas. Vispirms izlemiet maršrutu, pēc tam atļaujas, un pēc tam pārbaudiet izvietotajā vidē, nevis pie sava galda.

Klēpjdatora VPN nav lietojumprogrammas ceļš

Lai ko personāla VPN dara cilvēkiem, tas neko nedara instancei, ja vien šī instance nav skaidri daļa no tā paša tīkla ceļa. EC2 instance privātā apakštīklā sasniedz RDS, izmantojot VPC maršrutēšanu, drošības grupas un tīkla ACL. Tā nemanto cilvēka tuneli, cilvēka sesiju vai cilvēka akreditācijas datus, un tai arī nevajadzētu: nepārraudzīts lietojumprogrammu savienojums un personāla attālinātā piekļuve ir jādarbojas neatkarīgi.

Šī neatkarība ir priekšrocība. Kad VPN ir izslēgts, lietojumprogramma turpina darboties. Kad lietojumprogramma uzvedas slikti, neviens nezaudē attālināto piekļuvi. Dizaini, kas abus sapludina vienā ceļā, parasti tiek atklāti incidenta laikā, sliktākajā iespējamajā brīdī.

Lēmums 1: tas pats VPC, tiešs ceļš

Kad lietojumprogramma un datubāze atrodas vienā VPC ar tiešu maršrutēšanu un bez pārbaudes starpierīces starp tām, ceļš ir vienkāršs un drošības grupas atsauce ir visspēcīgākais pieejamais rīks. Piešķiriet lietojumprogrammai savu grupu un pēc tam atļaujiet datubāzes portu no šīs grupas, nevis no adrešu diapazona:

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

Ports ir ilustratīvs un tam jāatbilst dzinējam. Grupas atsauce atļauj trafiku no lietojumprogrammas instancēm; tā nekopē to noteikumus un neveido datubāzes pieteikšanos. Divas atsevišķas problēmas, divi atsevišķi labojumi.

Pēc tam pārbaudiet pārējo ceļu, nevis apstājieties pie noteikuma, ko tikko pievienojāt. Lietojumprogrammas izejošajai politikai, pilnajai datubāzei pievienoto grupu kopai, apakštīkla maršrutu tabulām un visiem tīkla ACL ir jāsakrīt. Drošības grupu noteikumi ir ar stāvokli, savukārt pielāgotam tīkla ACL ir jāatļauj pieprasījums un atgriezeniskais trafiks atsevišķos noteikumos, tostarp īslaicīgie porti. Jauns šaurs datubāzes noteikums arī neatceļ iepriekš pievienotu plašu atļauju.

Lēmums 2: cits VPC vai cits konts

Ja lietojumprogramma ir citā VPC, tīkla īpašnieki izvēlas atbalstītu privātu savienojumu: peering, tranzīta dizainu vai koplietota VPC vienošanos. Tad jābūt abiem maršrutēšanas virzieniem, vārdu izšķiršanai jādarbojas RDS galapunktam, un avotam, ko vērtē datubāzes politika, jāatbilst tam, kas faktiski ierodas. Atbilstoši kontu nosaukumi vai kopīga norēķinu attiecība neko no tā nesniedz.

Drošības grupas atsauce ir tā daļa, kas atšķiras. Tā darbojas vairākos privātu savienojumu dizainos, bet pārstāj darboties tajā brīdī, kad starpierīce pārraksta avotu vai izbeidz savienojumu, jo tad datubāze redz starpierīci, nevis jūsu lietojumprogrammas grupu. RDS VPC scenāriji atdala piekļuvi tajā pašā VPC no citiem izkārtojumiem, un ir vērts pārbaudīt savu konkrēto topoloģiju pret tiem, pirms pieņemat, ka noteikuma stils pārnesas.

Neatrisiniet trūkstošo maršrutu, padarot datubāzi publiski pieejamu. Tas ir cits atklāšanas lēmums ar citu īpašnieku, un to parasti ierosina tas, kurš ir vistālāk no sekām.

Lēmums 3: kādu identitāti pieņem datubāze

Tīkla piekļuve un datubāzes autentifikācija ir atsevišķi slāņi, un to sajaukšana rada maldinošākās kļūdas. Instances loma ir AWS identitāte AWS API izsaukšanai. Tā nav datubāzes lietotājs. IAM datubāzes autentifikācija ir atbalstīta funkcija tur, kur dzinējs un konfigurācija to pieļauj, un tā joprojām ir kartēšana uz datubāzes lietotāju, nevis tā aizstājējs.

Lietojumprogrammas konfigurācijā izmantojiet RDS galapunkta nosaukumu, nevis adresi, kas iegūta vienā meklēšanā. Multi-AZ pārslēgšanās maina adresi aiz šī nosaukuma, un lietojumprogramma, kas piesaistīta IP, neizdosies tieši tajā brīdī, kad tā ir vajadzīga. Atstājiet dzinēja TLS pārbaudi ieslēgtu, nevis izslēdziet to, lai kļūda pazustu, jo pārbaudes neveiksme jums kaut ko pasaka par galapunktu, kuru sasniedzāt.

Pēc tam piešķiriet datubāzes kontam minimumu, kas lietojumprogrammai nepieciešams, tajā shēmā, kuru tā faktiski izmanto. Šis darbs ir garlaicīgs, to var auditēt, un tieši par šo daļu jautās incidenta apskats.

Pārbaudiet izvietotajā vidē

Testējiet no instances vai no uzdevuma, kas darbojas ar to pašu grupu, apakštīklu un lomu. Četras neveiksmes no klēpjdatora izskatās līdzīgas un no turienes ir viegli atšķiramas: nosaukums, kas netiek atrisināts, savienojums, kas beidzas, TLS validācijas neveiksme un noraidīta pieteikšanās datubāzē. Katra norāda uz citu robežu, un datubāzes atklāšanas maiņa pirms zināšanas, kura jums ir, ir minējums.

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

Ja savienojums izdodas no instances un neizdodas no jūsu galda, lietojumprogrammas ceļš ir kārtībā, un labojama ir jūsu piekļuve. Ja tas neizdodas no abiem, sāciet ar iepriekš minētajām grupas un maršruta pārbaudēm, nevis ar akreditācijas datiem. Šis viens salīdzinājums novērš lielāko daļu jucekļa, ko rada šie pieteikumi.