VPC attālās piekļuves pieņemšanai nepieciešami atteikuma testi

Attālās piekļuves pieņemšana ir gaidāmo rezultātu tabula, nevis strādājošas lapas ekrānuzņēmums. Katrai grupai pierakstiet, kam jāizdodas un kam jāneizdodas, un tad abus izpildiet ar īpašām testa identitātēm kontrolētā laika logā. Atteikumi ir tā daļa, kas pierāda robežu; veiksmīga pieteikšanās pierāda tikai to, ka tunelis pastāv. Tas viss darbojas ar jau izvēlēto VPN produktu.

Testiem izmantojiet atsevišķus kontus un atzīmējiet tos tā, lai neviens testa identitāti nesajauktu ar īstu izņēmumu.

Pierakstiet robežu kā gaidāmos rezultātus

Sāciet ar lomām, nevis komponentiem: kam vajadzīgs kurš pakalpojums, no kurienes un ar kādu identitāti. Ņemiet ilustratīvu VPC: vienai grupai vajadzīga testa vide caur HTTPS, citai vajadzīga ražošanas datubāze, un trešā, mazākā grupa pārvalda pašu vārteju. Katra rinda iegūst gaidāmo atļauju un gaidāmo atteikumu, tostarp kaimiņu pakalpojumu un kaimiņu kontu, kuriem nevajadzētu darboties. Šī tabula ir pieņemšanas kritērijs, un cilvēki, kuri testus neizpilda, to var pārskatīt.

Pārbaudiet datubāzes pieteikšanos atsevišķi no tīkla ceļa. Sasniedzams TCP ports nedrīkst padarīt veiksmīgu neapstiprinātu datubāzes kontu, un VPN dalība nedrīkst radīt mākoņa IAM lomu vai piešķirt administratīvu API piekļuvi. Tie ir trīs neatkarīgi kontroles līdzekļi, un tie neizdodas neatkarīgi.

Maršruts nav autorizācija

Maršruts padara ceļu iespējamu; tas nepiešķir atļauju. Maršruta aizturēšana ir vājš aizstājējs ierobežojumam, kas tiek izpildīts galamērķī, jo klients vienmēr var pievienot savu maršrutu. Drošības grupa, datubāzes piešķīrums un pašas lietojumprogrammas autorizācija paliek izšķirošie kontroles līdzekļi. Kad tests negaidīti izdodas, vispirms skatieties galamērķa politiku, nevis maršrutēšanas tabulu, kuru bijāt paredzējis klientam.

Tāpēc atteikuma testi vērsti uz servera pusi: šos rezultātus nevar mainīt, rediģējot klientu.

Kādu avotu kontrole patiešām redz?

Avota adrese, ko kontrole izvērtē, ir atkarīga no vārtejas arhitektūras. EC2 mitināta vārteja var pārsūtīt maršrutētu kopu, pārtulkot to savā adresē vai pēc NAT uzrādīt citu adresi; pārvaldītais Client VPN piesaistās apakštīklam un seko savam modelim. Drošības grupas un tīkla ACL redz to, kas ierodas pēc šīs apstrādes. Noteikuma pārbaude, balstoties uz nepareizu avota pieņēmumu, ir izplatīts veids, kā izveidot robežu, kas izskatās pareiza un ielaiž nepareizo trafiku.

Saistiet katru rezultātu ar mazāko lietderīgo notikumu: identitāte un sesija, resurss, darbība, laiks un lēmums. CloudTrail API izsaukums, VPC plūsmas ieraksts un VPN sesijas žurnāls atbild uz dažādiem jautājumiem, un neviens no tiem viens pats nav lietojumprogrammas audits.

Atsauciet identitāti un pārbaudiet to vēlreiz

Iekļaujiet atsaukšanu tajā pašā tabulā. Noņemiet testa identitāti, apstipriniet, ka jauna sesija tiek atteikta, un tad atsevišķi apstipriniet, kā tiek apstrādātas esošās sesijas, jo tā ir atšķirīga uzvedība ar atšķirīgiem īpašniekiem. Pārbaudiet, kas notiek pēc vārtejas restartēšanas vai nomaiņas, lai manuāli pievienots izņēmums klusi neizzustu vai neatgrieztos plašāks. Robeža, kas pastāv tikai līdz nākamajai izvietošanai, nav robeža.

Nekas no tā neaizstāj ielāpu, atjaunošanas vai akreditācijas datu dzīves cikla darbu. Tas padara šaurāku solījumu izmērāmu: pareizie cilvēki sasniedz pareizos pakalpojumus, kamēr tuvējie maršruti, konti un pārvaldības virsmas paliek ārpus piešķīruma.

Glabājiet tabulu kopā ar izvietošanu un izpildiet to vēlreiz, kad vārteja mainās. Testi ir lēti; aiz tiem esošie pieņēmumi nav.