VPC-etäkäytön hyväksyntä vaatii hylkäystestit
Toimiva VPN-kirjautuminen on hyväksyntätaulukon ensimmäinen rivi, ei viimeinen. Kirjoita kunkin roolin odotetut hylkäykset ja testaa kontrollit, jotka niistä päättävät.
Etäkäytön hyväksyntä on taulukko odotetuista tuloksista, ei kuvakaappaus toimivasta sivusta. Kirjoita jokaiselle ryhmälle, minkä pitäisi onnistua ja minkä pitäisi epäonnistua, ja aja sitten molemmat omistetuilla testi-identiteeteillä valvotussa ikkunassa. Hylkäykset ovat se osa, joka todistaa rajan; onnistunut kirjautuminen todistaa vain, että tunneli on olemassa. Kaikki tämä toimii jo valitulla VPN-tuotteella.
Käytä testeissä erillisiä tilejä ja merkitse ne niin, ettei kukaan sekoita testi-identiteettiä todelliseen poikkeukseen.
Kirjoita raja odotettuina tuloksina
Aloita rooleista, älä komponenteista: kuka tarvitsee mitä palvelua, mistä ja millä identiteetillä. Ota esimerkinomainen VPC: yksi ryhmä tarvitsee testiympäristön HTTPS:n kautta, toinen tarvitsee tuotantotietokannan ja kolmas, pienempi ryhmä hallinnoi itse yhdyskäytävää. Jokainen rivi saa odotetun sallinnan ja odotetun hylkäyksen, mukaan lukien naapuripalvelu ja naapuritili, joiden ei pitäisi toimia. Tuo taulukko on hyväksymiskriteeri, ja ihmiset, jotka eivät aja testejä, voivat tarkistaa sen.
Testaa tietokantakirjautuminen erikseen verkkopolusta. Tavoitettavissa oleva TCP-portti ei saisi tehdä hyväksymättömästä tietokantatilistä onnistunutta, eikä VPN-jäsenyys saisi luoda pilven IAM-roolia tai myöntää hallinnollista API-käyttöä. Nämä ovat kolme riippumatonta kontrollia, ja ne epäonnistuvat toisistaan riippumatta.
Reitti ei ole valtuutus
Reitti tekee polusta mahdollisen; se ei myönnä lupaa. Reitin pidättäminen on heikko korvike kohteessa toteutetulle rajoitukselle, koska asiakas voi aina lisätä oman reittinsä. Tietoturvaryhmä, tietokannan myönnytys ja sovelluksen oma valtuutus ovat edelleen ratkaisevat kontrollit. Kun testi onnistuu odottamatta, katso ensin kohteen käytäntöä, älä reititystaulukkoa, jonka tarkoitit asiakkaalla olevan.
Siksi hylkäystestit kohdistuvat palvelinpuoleen: niitä tuloksia ei voi muuttaa asiakasta muokkaamalla.
Minkä lähteen kontrolli todella näkee?
Lähdeosoite, jonka kontrolli arvioi, riippuu yhdyskäytävän arkkitehtuurista. EC2:ssa isännöity yhdyskäytävä voi välittää reititetyn altaan, kääntää sen omaksi osoitteekseen tai esittää eri osoitteen NAT:n jälkeen; hallittu Client VPN liittyy aliverkkoon ja noudattaa omaa malliaan. Tietoturvaryhmät ja verkon ACL:t näkevät sen, mikä saapuu tämän käsittelyn jälkeen. Säännön tarkastelu väärällä lähdeolettamalla on tavallinen tapa rakentaa raja, joka näyttää oikealta ja päästää läpi väärää liikennettä.
Korreloi jokainen tulos pienimpään hyödylliseen tapahtumaan: identiteetti ja istunto, resurssi, toimenpide, aika ja päätös. CloudTrail API-kutsu, VPC-virtatietue ja VPN-istuntoloki vastaavat eri kysymyksiin, eikä mikään niistä yksin ole sovelluksen auditointi.
Poista identiteetti ja testaa se uudelleen
Sisällytä poisto samaan taulukkoon. Poista testi-identiteetti, vahvista, että uusi istunto hylätään, ja vahvista sitten erikseen, miten olemassa olevia istuntoja kohdellaan, koska ne ovat erilaisia toimintatapoja eri omistajilla. Tarkista, mitä tapahtuu yhdyskäytävän uudelleenkäynnistyksen tai vaihdon jälkeen, jotta käsin lisätty poikkeus ei katoa hiljaa tai palaa laajempana. Raja, joka kestää vain seuraavaan käyttöönottoon, ei ole raja.
Mikään tästä ei korvaa paikkaustyötä, palautusta tai tunnistetietojen elinkaarityötä. Se tekee kapeammasta lupauksesta mitattavan: oikeat ihmiset saavuttavat oikeat palvelut, kun taas lähellä olevat reitit, tilit ja hallintapinnat pysyvät myönnytyksen ulkopuolella.
Pidä taulukko käyttöönoton yhteydessä ja aja se uudelleen, kun yhdyskäytävä muuttuu. Testit ovat halpoja; niiden takana olevat olettamukset eivät.