Yksityinen RDS EC2:sta: sama VPC, peering vai jotain muuta?

Kehittäjän kannettava tietokone tavoittaa yksityisen RDS-instanssin henkilöstön VPN:n kautta, mutta EC2:ssa oleva sovellus ei saa yhteyttä lainkaan. Kyse ei ole rikkinäisestä käyttöönotosta. Kannettavassa on tunneli, jota EC2-instanssi ei koskaan peri, ja RDS:n „yksityinen“ tarkoittaa, että tietokannalla ei ole julkista päätepistettä, ei sitä, että ihmiskäyttäjät VPN:n kautta olisivat ainoat sallitut kutsujat. Sovellus tarvitsee oman valtuutetun reittinsä, oman suhteensa turvaryhmään ja oman tietokantaidentiteettinsä, ja järjestys, jossa valitset nämä kolme, säästää suurimman osan vianetsinnästä. Päätä reitti ensin, sitten käyttöoikeudet ja lopuksi varmista käyttöönotetusta ympäristöstä eikä työpöydältäsi.

Kannettavan VPN ei ole sovelluksen reitti

Mitä tahansa henkilöstön VPN tekeekin ihmisille, se ei tee mitään instanssille, ellei kyseinen instanssi ole nimenomaisesti osa samaa verkkoreittiä. Yksityisessä aliverkossa oleva EC2-instanssi tavoittaa RDS:n VPC-reitityksen, turvaryhmien ja verkon ACL:ien kautta. Se ei peri ihmisen tunnelia, ihmisen istuntoa tai ihmisen tunnistetietoja, eikä sen pitäisikään: valvomattoman sovelluksen yhteyden ja henkilöstön etäkäytön on oltava erikseen käytettävissä.

Tämä riippumattomuus on ominaisuus. Kun VPN on alhaalla, sovellus jatkaa toimintaansa. Kun sovellus käyttäytyy huonosti, kukaan ei menetä etäkäyttöään. Suunnittelut, jotka sulauttavat kaksi yhdeksi reitiksi, havaitaan yleensä tapahtuman aikana, kaikkein huonoimmalla hetkellä.

Päätös 1: sama VPC, suora reitti

Kun sovellus ja tietokanta ovat samassa VPC:ssä suoralla reitityksellä ja ilman niiden välistä tarkistuslaitetta, reitti on yksinkertainen ja turvaryhmäviittaus on tehokkain käytettävissä oleva työkalu. Anna sovellukselle oma ryhmä ja salli sitten tietokannan portti kyseisestä ryhmästä osoitealueen sijaan:

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

Portti on havainnollistava ja sen on vastattava moottoria. Ryhmäviittaus valtuuttaa liikennettä sovelluksen instansseista; se ei kopioi niiden sääntöjä eikä luo tietokantaan kirjautumista. Kaksi erillistä ongelmaa, kaksi erillistä ratkaisua.

Tarkista sitten reitin loppuosa sen sijaan, että pysähdyt juuri lisäämääsi sääntöön. Sovelluksen lähtevä käytäntö, tietokantaan liitettyjen ryhmien täydellinen joukko, aliverkon reititystaulut ja kaikki verkon ACL:t on saatava sopimaan yhteen. Turvaryhmien säännöt ovat tilallisia, kun taas mukautetun verkon ACL:n on sallittava pyyntö ja paluuliikenne erillisissä säännöissä, mukaan lukien hetkelliset portit. Kapea uusi tietokantasääntö ei myöskään kumoa aiemmin liitettyä laajaa sallintaa.

Päätös 2: toinen VPC tai toinen tili

Jos sovellus on toisessa VPC:ssä, verkon omistajat valitsevat tuetun yksityisen yhteyden: peering, transit-rakenne tai jaettu VPC-järjestely. Silloin molempien reitityssuuntien on oltava olemassa, nimien selvityksen on toimittava RDS:n päätepisteelle, ja lähteen, jonka tietokannan käytäntö arvioi, on vastattava sitä, mitä todella saapuu. Täsmäävät tilin nimet tai jaettu laskutussuhde eivät tarjoa mitään näistä.

Turvaryhmäviittaus on se osa, joka vaihtelee. Se toimii useissa yksityisen yhteyden rakenteissa, mutta lakkaa toimimasta heti, kun välissä oleva laite kirjoittaa lähteen uudelleen tai päättää yhteyden, koska silloin tietokanta näkee välissä olevan laitteen eikä sovelluksesi ryhmää. RDS:n VPC-skenaariot erottavat saman VPC:n sisäisen pääsyn muista järjestelyistä, ja kannattaa tarkistaa oma topologiasi niitä vasten ennen kuin oletat sääntötyylin siirtyvän.

Älä ratkaise puuttuvaa reittiä tekemällä tietokannasta julkisesti käytettävää. Se on toinen altistumispäätös, jolla on toinen omistaja, ja sitä ehdottaa yleensä se, joka on kauimpana seurauksesta.

Päätös 3: minkä identiteetin tietokanta hyväksyy

Verkkopääsy ja tietokannan todennus ovat erillisiä kerroksia, ja niiden sekoittaminen tuottaa harhaanjohtavimmat virheet. Instanssin rooli on AWS-identiteetti AWS:n API:en kutsumiseen. Se ei ole tietokantakäyttäjä. IAM-tietokantatodennus on tuettu ominaisuus silloin, kun moottori ja kokoonpano sen sallivat, ja se on edelleen kartoitus tietokantakäyttäjään eikä sen korvaaja.

Käytä sovelluksen kokoonpanossa RDS:n päätepisteen nimeä yhdestä hausta poimitun osoitteen sijaan. Multi-AZ-vikasieto muuttaa tuon nimen takana olevaa osoitetta, ja IP:hen kiinnitetty sovellus epäonnistuu juuri sillä hetkellä, kun sitä tarvitaan. Pidä moottorin TLS-varmennus käytössä sen sijaan, että kytket sen pois virheen poistamiseksi, koska varmennuksen epäonnistuminen kertoo jotain päätepisteestä, johon päädyit.

Myönnä sitten tietokantatilille vähimmäisoikeudet, jotka sovellus tarvitsee, siinä skeemassa, jota se todella käyttää. Se työ on tylsää, se on auditoitavissa, ja se on se osa, josta tapahtuman jälkikatselmus kysyy.

Varmista käyttöönotetusta ympäristöstä

Testaa instanssista tai tehtävästä, joka toimii samalla ryhmällä, aliverkolla ja roolilla. Neljä epäonnistumista näyttävät kannettavalta samanlaisilta ja ovat sieltä helposti erotettavissa: nimi, joka ei selviä, yhteys, joka aikakatkaistaan, TLS-validoinnin epäonnistuminen ja hylätty tietokantakirjautuminen. Jokainen osoittaa eri rajaan, ja tietokannan altistuksen muuttaminen ennen kuin tiedät, mikä niistä sinulla on, on arvailua.

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

Jos yhteys onnistuu instanssista ja epäonnistuu työpöydältäsi, sovelluksen reitti on kunnossa ja korjattava on sinun pääsysi. Jos se epäonnistuu molemmista, aloita yllä olevista ryhmä- ja reittitarkistuksista tunnistetietojen sijaan. Tämä yksi vertailu estää suurimman osan siitä säädöstä, jota nämä tiketit tuottavat.