Transdono de aliro por sekureca testado: amplekso, kontoj kaj revoko

Testanto petas pordegan adreson, detalojn de interna DNS kaj VPN-legitimaĵojn, kaj la peto plusendatas al vi kun la temo „aliro bezonatas“. La peto sole ne diras al vi, ĉu temas pri interna takso, pri testo de aŭtentigita aplikaĵo, aŭ pri laboro ĉe publika retejo, kie iu miskomprenis la amplekson. Plenumu la transdonon kiel sinsekvon kun pordego ĉe ĉiu paŝo, kaj haltu ĉe la unua pordego, kiu ne malfermiĝas. Tio ŝanĝas neklaran peton en ion, kion vi povas rajtigi, liveri kaj poste revoki.

Komencu per la rajtigo, ne per la legitimaĵoj

Antaŭ ol iu adreso forlasas vian retpoŝton, determini, kiu posedas la celojn kaj kiu rajtas aprobi testadon sur ili. Kontrolu la testanton per la kontakto de la engaĝiĝo, kiun via organizo jam uzas, ne per la persono, kiu plusendis la retpoŝton. Klienta rilato ne estas permeso testi ĉiun sistemon atingeblan el konto, kaj aĉetmendo ne estas dokumento pri amplekso.

Skribu la aprobitan celon en unu frazo kaj tenu ĝin apud la transdono. „Takseri la aŭtentigon de la klienta portalo“ kaj „takseri la internan reton“ kondukas al tute malsamaj pakaĵoj, kaj la diferencon oni devas solvi antaŭ la provizado, ne post kiam trovo alvenas. La frazo ankaŭ donas al vi ion, al kiu montri, kiam la peto kreskas meze de la engaĝiĝo.

Se gastiga provizanto aŭ alia tria partio estas sur la vojo, iliaj postuloj venas antaŭ via komforto. Testi la infrastrukturon de iu alia sen ilia permeso estas aparta problemo disde testado de la aplikaĵo, kiu funkcias sur ĝi.

Nomu la vidpunkton kaj la celojn

La vidpunkto estas la demando, kiun la takso provas respondi, kaj ĝi determinas la alirpakaĵon pli ol iu ajn ilo, kiun la testanto planas uzi. Publika neaŭtentigita testo bezonas URL kaj tempofenestron. Aŭtentigita testo bezonas dediĉitajn kontojn por la koncernaj roloj en la amplekso, kaj interna takso bezonas difinitan enirpunkton kun eksplicitaj celintervaloj.

Kie tunelo eniras, ne estas la sama fakto kiel kiu aplikaĵo staras malantaŭ ĝi, kaj ĝi certe ne rajtigas sondi la enirpunkton. Diru tion eksplicite en la transdono, ĉar la frazo „vi donis al mi aliron al tiu subreto“ venas rapide, kiam trovo estas disputata. Skriba cellisto estas la sola afero, kiu solvas tion poste.

Donu la TLS-gastigantnomon kune kun la URL. Nuda IP-adreso devigas la testanton diveni la nomon, kaj divenita nomo produktas atestilajn erarojn, kiuj raportiĝas kiel trovaĵoj anstataŭ kiel eraro de transdono.

Eldonu dediĉitajn identecojn kun findato

Provizu kontojn, kiuj ekzistas nur por ĉi tiu engaĝiĝo; ne pruntu la ĉiutagan saluton de oficisto. Agordu retan atingeblon kaj aplikaĵajn permesojn al la interkonsentitaj taskoj, aranĝu aŭtentigan aliĝon tra subtenata vojo, kaj aldonu findaton kun nomita persono respondeca pri revoko. Transdonu la legitimaĵojn per interkonsentita sekura kanalo, aparte de la ampleksa dokumento, kiu plusendatas ĉirkaŭe.

sudo useradd -m -e 2026-12-31 tester01
sudo passwd -S tester01
id tester01
lastlog -u tester01

Registru, kiu ricevis kion, kaj kiam. Tiu registro estas la diferenco inter kontrolita transdono kaj komuna pasvorto, kiun neniu povas spuri, kaj ĝi estas la unua afero, kiun iu ajn petas post incidento. Konservu ĝin kun la ampleksa dokumento anstataŭ en babileja fadeno, kaj notu la liveran kanalon apud la ricevanto. Linio kun tempindiko ĉiam venkas memoron.

La findato-kampo estas sekurreta reto, ne la plano. Iu ankoraŭ devas forigi la retan vojon kaj la aplikaĵan rolon ĉe la fino, ĉar eksdata saluto en reto ankoraŭ atingebla ne estas revokita aliro.

Pruvu, ke la transdono funkcias antaŭ ol malfermiĝos la fenestro

Plenumu la unuan salton de la testanto mem, el pozicio kiel eble plej proksima al la lia. Solvu la nomon, kontrolu la atestilan identecon, kaj konfirmu, ke la vojo atingas la celitan adreson anstataŭ najbaran.

dig +short app.example.com
openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates
ip route get 10.60.0.25

Se la vojo ne povas atingi celon, haltu kaj akordu la transdonon anstataŭ lasi la testanton malkovri alternativan itineron. Improvizita atingeblo estas kiel takso silente etendiĝas preter sia amplekso, kaj ĝi preskaŭ neniam dokumentiĝas poste.

Sendu la operacian kontakton, permesitajn horojn, ekskluditajn agojn kaj haltigajn kondiĉojn kune kun la legitimaĵoj. Testanto, kiu ne povas atingi iun ajn je 02:00, faros decidon, kiun vi ne rajtigis, kaj tiu decido estos priskribita en la raporto kvazaŭ ĝi estus en la amplekso.

NIST SP 800-115 kadrigas teknikan takson kiel planita testado sekvata de analizo kaj mildigo, kaj ĝuste tiun formon sekvas ĉi tiu transdono. La pordegoj supre estas redaktaj dezajnaj elektoj por subtena inĝeniero, ne kontrol-listeto citita el tiu publikaĵo.

Fermu la engaĝiĝon forigante la aliron

Revoku en la inversa ordo de la provizado: aplikaĵaj roloj, poste reta aliro, poste la identeco mem. Konfirmu ĉiun paŝon anstataŭ supozi, ke la konzolo faris tion, kion promesis la butono. Ŝlosu la konton antaŭ ol mortigi ĝiajn sesiojn, alie la sesio simple reaŭtentiĝas tra la malnova vojo. Poste kontrolu la establitajn konektojn ankoraŭfoje antaŭ ol nomi ĝin fermita.

sudo passwd -l tester01
sudo pkill -u tester01
ss -tn state established '( sport = :443 )'

Solvu iujn retenitajn testajn datumojn, poste spuru la riparon tra la raporta procezo interkonsentita komence. La raporto devus indiki la medion, la alirnivelon, la amplekson kaj la limigojn, ĉar ĝi registras trovaĵojn de unu takso kaj ne estas daŭra aserto, ke la retejo estas sekura.

Konservu la revokan registron kun la transdona registro. Kiam la sekva engaĝiĝo malfermiĝos, vi volas scii precize, kio estis forigita lastfoje kaj kiu aprobis ĝin, anstataŭ rekonstrui la bildon el memoro.