AWS Client VPN -säännöt kuuluvat resurssiin, eivät aliverkkoon

Henkilöstön on päästävä VPC:n yhteen sovellukseen eikä päästävä saman instanssin tietokantakuuntelijaan, joten joku lisää toisen julkisen aliverkon VPN-päätepisteelle ja katsoo vaatimuksen täytetyksi. Aliverkon sijoitus muuttaa reititystä ja käytettävyyttä. Se ei myönnä eikä kiellä yhtäkään porttia. Vaatimuksen ilmaiseva lupa asuu kohteessa, resurssin tietoturvaryhmässä, ja VPN:n raja antaa kahvan, johon sääntö viittaa.

Aliverkon sijoitus on reititystä, ei valtuutusta

Missä päätepisteen verkkoliitos sijaitsee, ratkaisee mikä reititystaulu kuljettaa asiakasliikennettä ja mitkä käytettävyysvyöhykkeet selviävät vauriosta. Se ei kerro mitään siitä, mihin porttiin missäkin instanssissa liikenne voi päästä. Kaksi samaan aliverkkoon liitettyä asiakasta saapuvat silti samalla lähdeidentiteetillä, eikä resurssi voi erottaa niitä aliverkon nimen perusteella.

Aloita sen sijaan vaatimuksesta: kuka kutsuu, mikä resurssi, mikä palveluportti ja mikä suunta. Valitse sitten sääntömalli, joka voi ilmaista nuo neljä asiaa kohteessa. Tämä kehys poistaa ylimääräisen aliverkon yleensä kokonaan suunnitelmasta.

Client VPN -liitosryhmä on se kahva

Aliverkkoon liitetylle AWS Client VPN -päätepisteelle dokumentoitu järjestely on konkreettinen. Sovi aiottu tietoturvaryhmä päätepisteen kohdeverkon liitoksiin ja salli sitten tarvittava liikenne resurssin tietoturvaryhmässä käyttäen tuota Client VPN -ryhmää lähteenä.

Konkreettisesti sovellusinstanssin ryhmä sallii sovellusportin liitosryhmästä eikä mitään muuta. AWS:n resurssin käyttömenettely kuvaa tämän suhteen, ja samaa ryhmäkäytäntöä kannattaa pitää jokaisessa aliverkossa, johon päätepiste liittyy, koska vanhentunut liitos toiseen ryhmään laajentaa rajaa hiljaa.

Tuo sääntö ei todista ketään. Kirjautuminen on erillinen kontrolli, ja reitti resurssiin on kolmas. Kaikkien kolmen on pidettävä ennen kuin pyyntö saapuu. Se, mikä niistä pettää, ratkaisee mikä korjaus on oikea, ja säännön muuttaminen on oikea vastaus vain ensimmäiselle.

Mitä yksi liitosryhmä ei pysty erottamaan

Jokainen saman liitosryhmän takana oleva asiakas saavuttaa resurssin samana tietoturvaryhmän lähteenä. Kaksi eri roolissa olevaa käyttäjää ovat erottamattomia sillä kerroksella, riippumatta siitä miten ryhmä on nimetty tai merkitty. Client VPN:n ulkoisten ryhmien valtuutus rajaa pääsyn kohdeprefiksin mukaan hakemisto- tai SAML-ryhmälle, mikä on karkeampaa kuin resurssin rooli ja pitää käsitellä verkkorajana eikä identiteettijärjestelmänä.

Hienommat erot kuuluvat sovellukselle. Tietokantakuuntelija, jonka on pysyttävä suljettuna useimmilta työntekijöiltä, on paremmin suojattu, kun se ei ole lainkaan tavoitettavissa sallitulla prefiksillä, kuin toivomalla, että ryhmän jäsenyys pysyy siistinä.

Ryhmän uudelleennimeäminen ei luo identiteettiä, ja sen kopioiminen tiimeittäin vain moninkertaistaa tarkistettavat liitokset.

Älä kopioi tuota sääntöä jokaiseen VPN-suunnitelmaan

Itse hallittu EC2 VPN -yhdyskäytävä, reititetty tarkastuslaite ja hallittu Client VPN ovat kolme eri pakettipolkua. Selvitä mikä lähdeosoite todella saavuttaa resurssin, tapahtuuko matkalla käännöstä ja mitä viitemekanismeja palvelu tukee tuolla polulla.

Liikenteen välittäminen välikappaleen kautta ei säilytä lähde-tietoturvaryhmän viitettä kuten suora instanssien välinen liikenne. AWS dokumentoi, että tällaiset suunnitelmat voivat tarvita asianmukaiset yksityiset lähdeosoitteet tai CIDR:t ryhmäviitteen sijaan. Hallitun Client VPN:n menettely ei ole todiste siitä, että jokaisen yhdyskäytävän liitetty ryhmä toimii yleisenä identiteettitunnuksena välitetyille paketeille.

Yksi NAT-hyppy polulla riittää rikkomaan oletuksen, ja vika näyttää säännöltä, joka on olemassa mutta ei koskaan täsmää.

Tarkista tehokas raja

Lue jokainen resurssiin liitetty tietoturvaryhmä, koska sallintasäännöt yhdistyvät eikä kapea sääntö kumoa toisen ryhmän laajempaa. Tarkista sitten verkon ACL, isännän palomuuri ja sovelluksen oma valtuutus, jotka ovat erillisiä kerroksia erillisine virheineen.

Lopeta yhteen sallittuun ja yhteen tarkoituksella suljettuun pyyntöön samaa resurssia vastaan. Pari todistaa rajan, kun taas yksittäinen onnistunut yhteys todistaa vain, että jotain on auki. Vahvista reitti, tehokas lähde ja aiottu palveluportti eikä aliverkkoa, joka sisältää päätepisteen.

Työjärjestys: kirjoita neliosainen vaatimus, liitä ryhmä liitoksiin, rajaa resurssin sääntö porttiin, varmista yksi sallinta ja yksi hylkäys, ja vasta sitten harkitse aliverkkojen jakamista reitityssyistä.