Pranimi i aksesit në distancë përmes VPC kërkon teste refuzimi

Pranimi i aksesit në distancë është një tabelë me rezultate të pritura, jo një pamje ekrani e një faqeje që funksionon. Për secilin grup, shkruani çfarë duhet të ketë sukses dhe çfarë duhet të dështojë, pastaj ekzekutoni të dyja me identitete testimi të dedikuara në një dritare të kontrolluar. Refuzimet janë pjesa që provon kufirin; një hyrje e suksesshme provon vetëm se tuneli ekziston. E gjithë kjo funksionon me produktin VPN të zgjedhur tashmë.

Përdorni llogari të veçanta për testet dhe etiketojini ato në mënyrë që askush të mos ngatërrojë një identitet testimi me një përjashtim të vërtetë.

Shkruani kufirin si rezultate të pritura

Filloni nga rolet dhe jo nga komponentët: kush ka nevojë për cilën shërbim, nga ku dhe me çfarë identiteti. Merrni një VPC ilustrues: një grup ka nevojë për mjedisin e provës përmes HTTPS, një tjetër për një bazë të dhënash prodhimi, dhe një grup i tretë e më i vogël administron vetë portën. Çdo rresht merr një leje të pritur dhe një refuzim të pritur, duke përfshirë shërbimin fqinj dhe llogarinë fqinje që nuk duhet të funksionojnë. Ajo tabelë është kriteri i pranimit, dhe njerëzit që nuk i ekzekutojnë testet mund ta rishikojnë atë.

Testoni hyrjen në bazën e të dhënave veçmas nga rruga e rrjetit. Një port TCP i arritshëm nuk duhet ta bëjë të suksesshme një llogari baze të dhënash të paaprovuar, dhe anëtarësimi në VPN nuk duhet të krijojë një rol IAM në re ose të japë akses administrativ në API. Këto janë tre kontrolle të pavarura, dhe dështojnë në mënyrë të pavarur.

Një rrugë nuk është autorizim

Një rrugë e bën të mundur një shteg; nuk jep leje. Mbajtja e një rrugë është një zëvendësues i dobët për një kufizim të zbatuar në destinacion, pasi një klient gjithmonë mund të shtojë rrugën e vet. Grupi i sigurisë, dhënia e bazës së të dhënave dhe autorizimi i vetë aplikacionit mbeten kontrollet që vendosin. Kur një test ka sukses të papritur, shikoni fillimisht politikën e destinacionit dhe jo tabelën e rrugëzimit që kishit menduar t'i jepnit klientit.

Kjo është arsyeja pse testet e refuzimit synojnë anën e serverit: ato rezultate nuk mund të ndryshohen duke redaktuar klientin.

Cilin burim sheh në të vërtetë kontrolli?

Adresa e burimit që vlerëson një kontroll varet nga arkitektura e portës. Një portë e strehuar në EC2 mund të përcjellë një grup të rrugëzuar, ta përkthejë në adresën e vet ose pas NAT të paraqesë një adresë tjetër; një Client VPN i menaxhuar lidhet me një nënrrjet dhe ndjek modelin e vet. Grupet e sigurisë dhe ACL-të e rrjetit shohin atë që vjen pas asaj përpunimi. Inspektimi i një rregulli me supozimin e gabuar të burimit është një mënyrë e zakonshme për të ndërtuar një kufi që duket i saktë dhe pranon trafikun e gabuar.

Ndërlidhni çdo rezultat me ngjarjen më të vogël të dobishme: identiteti dhe sesioni, burimi, operacioni, koha dhe vendimi. Një thirrje API në CloudTrail, një regjistrim fluksi VPC dhe një log sesioni VPN përgjigjen pyetjeve të ndryshme, dhe asnjëri prej tyre i vetëm nuk është auditim i aplikacionit.

Tërhiqni një identitet dhe testojeni përsëri

Përfshini tërheqjen në të njëjtën tabelë. Hiqni një identitet testimi, konfirmoni që një sesion i ri refuzohet, më pas konfirmoni veçmas si trajtohen sesionet ekzistuese, sepse janë sjellje të ndryshme me pronarë të ndryshëm. Kontrolloni çfarë ndodh pas rinisjes ose zëvendësimit të portës, në mënyrë që një përjashtim i shtuar me dorë të mos zhduket në heshtje ose të kthehet më i gjerë. Një kufi që zgjat vetëm deri në vendosjen tjetër nuk është kufi.

Asgjë nga kjo nuk zëvendëson punën me arnime, rikuperim ose ciklin e jetës së kredencialeve. E bën të matshme një premtim më të ngushtë: njerëzit e duhur arrijnë shërbimet e duhura, ndërsa rrugët, llogaritë dhe sipërfaqet e menaxhimit pranë mbeten jashtë dhënies.

Mbajeni tabelën me vendosjen dhe ekzekutojeni përsëri kur porta ndryshon. Testet janë të lira; supozimet pas tyre nuk janë.