Akcepto de fora aliro tra VPC postulas testojn de rifuzo

Akcepto de fora aliro estas tabelo de atendataj rezultoj, ne ekrankopio de funkcianta paĝo. Por ĉiu grupo, skribu kio devus sukcesi kaj kio devus malsukcesi, kaj poste plenumu ambaŭ kontraŭ dediĉitaj testaj identecoj en kontrolita tempofenestro. La rifuzoj estas la parto, kiu pruvas la limon; sukcesa ensaluto pruvas nur, ke la tunelo ekzistas. Ĉio ĉi funkcias kun la jam elektita VPN-produkto.

Uzu apartajn kontojn por la testoj, kaj marku ilin tiel, ke neniu konfuzu testan identecon kun vera escepto.

Skribu la limon kiel atendatajn rezultojn

Komencu de la roloj anstataŭ de la komponantoj: kiu bezonas kiun servon, de kie, kaj kun kiu identeco. Prenu ilustran VPC: unu grupo bezonas la testan medion per HTTPS, alia bezonas produktan datumbazon, kaj tria kaj pli malgranda grupo administras la enirejon mem. Ĉiu vico ricevas atendatan permeson kaj atendatan rifuzon, inkluzive de la najbara servo kaj la najbara konto, kiuj ne devus funkcii. Tiu tabelo estas la akcepta kriterio, kaj homoj, kiuj ne plenumas la testojn, povas revizii ĝin.

Testu la datumbazan ensaluton aparte de la reta vojo. Atingebla TCP-pordo ne devus igi neaprobita datumbaza konto sukcesi, kaj VPN-membreco ne devus krei nuban IAM-rolon aŭ doni administran API-aliro. Tiuj estas tri sendependaj kontroloj, kaj ili malsukcesas sendepende.

Vojo ne estas rajtigo

Vojo ebligas irejon; ĝi ne donas permeson. Retenado de vojo estas malforta anstataŭaĵo por limigo trudita ĉe la celo, ĉar kliento ĉiam povas aldoni propran vojon. La sekureca grupo, la datumbaza permeso kaj la propra rajtigo de la aplikaĵo restas la kontroloj, kiuj decidas. Kiam testo neatendite sukcesas, rigardu unue la politikon de la celo, ne la enrutan tabelon, kiun vi intencis doni al la kliento.

Tial ankaŭ la rifuzaj testoj celas la servilan flankon: tiuj rezultoj ne ŝanĝeblas per redaktado de la kliento.

Kiun fonton la kontrolo fakte vidas?

La fonta adreso, kiun kontrolo taksas, dependas de la arkitekturo de la enirejo. Enirejo gastigata sur EC2 povas plusendi enrutan basenon, traduki al sia propra adreso aŭ prezenti alian adreson post NAT; administrata Client VPN asociiĝas kun subreto kaj sekvas sian propran modelon. Sekurecaj grupoj kaj retaj ACL vidas ĉion, kio alvenas post tiu prilaborado. Inspekti regulon kontraŭ malĝusta fonta supozo estas ofta maniero konstrui limon, kiu aspektas ĝusta kaj enlasas la malĝustan trafikon.

Kunligu ĉiun rezulton kun la plej malgranda utila evento: identeco kaj sesio, rimedo, operacio, tempo kaj la decido. Alvoko al API en CloudTrail, VPC-fluoregistro kaj VPN-sesia protokolo respondas al diversaj demandoj, kaj neniu sola estas revizio de la aplikaĵo.

Retiru identecon kaj testu ĝin denove

Inkluzivu la retiron en la sama tabelo. Forigu testan identecon, konfirmu, ke nova sesio estas rifuzata, kaj poste aparte konfirmu, kiel traktatas ekzistantaj sesioj, ĉar temas pri diversaj kondutoj kun diversaj posedantoj. Kontrolu, kio okazas post restartigo aŭ anstataŭigo de la enirejo, por ke permane aldonita escepto ne malaperu silente aŭ ne revenu pli larĝa. Limo, kiu daŭras nur ĝis la sekva deplojo, ne estas limo.

Nenio el tio anstataŭas flikadon, restarigon aŭ laboron pri la vivociklo de akreditaĵoj. Ĝi faras pli mallarĝan promeson mezurebla: la ĝustaj homoj atingas la ĝustajn servojn, dum proksimaj vojoj, kontoj kaj administraj surfacoj restas ekster la permeso.

Tenu la tabelon kun la deplojo kaj relanĉu ĝin, kiam la enirejo ŝanĝiĝas. La testoj estas malmultekostaj; la supozoj malantaŭ ili ne.