Priimant nuotolinę prieigą prie VPC reikia neigiamų testų

Nuotolinės prieigos priėmimas yra numatomų rezultatų lentelė, o ne veikiančio puslapio ekrano kopija. Kiekvienai grupei užrašykite, kas turėtų pavykti ir kas turėtų nepavykti, tada abu atvejus paleiskite su specialiais testiniais tapatumais kontroliuojamame laiko intervale. Neigiami atsakymai yra ta dalis, kuri įrodo ribą; sėkmingas prisijungimas įrodo tik tai, kad tunelis egzistuoja. Visa tai veikia su jau pasirinktu VPN produktu.

Testams naudokite atskiras paskyras ir pažymėkite jas taip, kad niekas nesupainiotų testinio tapatumo su tikra išimtimi.

Užrašykite ribą kaip numatomus rezultatus

Pradėkite nuo vaidmenų, o ne nuo komponentų: kam reikia kokios paslaugos, iš kur ir su kokiu tapatumu. Paimkite iliustracinį VPC: vienai grupei reikia testavimo aplinkos per HTTPS, kitai reikia produkcinės duomenų bazės, o trečia ir mažesnė grupė administruoja patį šliuzą. Kiekviena eilutė gauna numatomą leidimą ir numatomą neigiamą atsakymą, įskaitant kaimyninę paslaugą ir kaimyninę paskyrą, kurios neturėtų veikti. Ta lentelė yra priėmimo kriterijus, ir ją gali peržiūrėti žmonės, kurie testų nevykdo.

Duomenų bazės prisijungimą testuokite atskirai nuo tinklo kelio. Pasiekiamas TCP prievadas neturėtų leisti sėkmingai prisijungti nepatvirtintai duomenų bazės paskyrai, o VPN narystė neturėtų sukurti debesijos IAM vaidmens ar suteikti administracinės API prieigos. Tai trys nepriklausomos kontrolės priemonės, ir jos nepavyksta nepriklausomai.

Maršrutas nėra autorizacija

Maršrutas padaro kelią įmanomą; jis nesuteikia leidimo. Maršruto sulaikymas yra silpnas pakaitalas apribojimui, vykdomam paskirties vietoje, nes klientas visada gali pridėti savo maršrutą. Saugos grupė, duomenų bazės suteikimas ir pačios programos autorizacija lieka sprendžiančios kontrolės priemonės. Kai testas netikėtai pavyksta, pirmiausia žiūrėkite į paskirties politiką, o ne į maršrutizavimo lentelę, kurią ketinote duoti klientui.

Štai kodėl neigiami testai nukreipti į serverio pusę: tų rezultatų negalima pakeisti redaguojant klientą.

Kokį šaltinį kontrolė iš tikrųjų mato?

Šaltinio adresas, kurį vertina kontrolė, priklauso nuo šliuzo architektūros. EC2 talpinamas šliuzas gali persiųsti maršrutizuotą telkinį, išversti jį į savo adresą arba po NAT pateikti kitą adresą; valdoma Client VPN prisijungia prie potinklio ir laikosi savo modelio. Saugos grupės ir tinklo ACL mato tai, kas atvyksta po šio apdorojimo. Taisyklės tikrinimas remiantis neteisinga šaltinio prielaida yra įprastas būdas sukurti ribą, kuri atrodo teisinga ir praleidžia netinkamą srautą.

Susiekite kiekvieną rezultatą su mažiausiu naudingu įvykiu: tapatumas ir sesija, išteklius, operacija, laikas ir sprendimas. CloudTrail API iškvietimas, VPC srauto įrašas ir VPN sesijos žurnalas atsako į skirtingus klausimus, ir nė vienas jų vienas negali būti laikomas programos auditu.

Panaikinkite tapatumą ir išbandykite dar kartą

Įtraukite panaikinimą į tą pačią lentelę. Pašalinkite testinį tapatumą, patvirtinkite, kad nauja sesija atmetama, tada atskirai patvirtinkite, kaip elgiamasi su esamomis sesijomis, nes tai skirtingas elgesys su skirtingais savininkais. Patikrinkite, kas nutinka po šliuzo paleidimo iš naujo ar pakeitimo, kad rankiniu būdu pridėta išimtis tyliai neišnyktų ar neatsirastų platesnė. Riba, kuri galioja tik iki kito diegimo, nėra riba.

Niekas iš to nepakeičia pataisymų, atkūrimo ar prisijungimo duomenų gyvavimo ciklo darbo. Tai padaro siauresnį pažadą išmatuojamą: tinkami žmonės pasiekia tinkamas paslaugas, o netoliese esantys maršrutai, paskyros ir valdymo paviršiai lieka už suteikimo ribų.

Laikykite lentelę kartu su diegimu ir paleiskite ją iš naujo, kai pasikeičia šliuzas. Testai pigūs; prielaidos už jų ne.