Entrega de acceso para probas de seguridade: alcance, contas e revogación
Un probador que pide credenciais VPN necesita unha entrega con alcance definido, non un inicio de sesión de reposto. Valide a autorización, nomee os obxectivos, emita contas e logo revogue.
Un probador pide un enderezo de pasarela, detalles de DNS interno e credenciais VPN, e a solicitude remítese co asunto «necesítase acceso». A solicitude por si soa non lle di se é unha avaliación interna, unha proba de aplicación autenticada ou un traballo nun sitio web público onde alguén entendeu mal o alcance. Execute a entrega como unha secuencia cunha porta en cada paso e detéñase na primeira porta que non abra. Iso converte unha solicitude vaga en algo que pode autorizar, entregar e revogar despois.
Empece pola autorización, non polas credenciais
Antes de que ningún enderezo saia da súa caixa de entrada, estableza quen posúe os obxectivos e quen pode aprobar probas sobre eles. Verifique o probador mediante o contacto do traballo que a súa organización xa usa, non mediante a persoa que reenviou o correo. Unha relación con cliente non é permiso para probar todos os sistemas accesibles desde unha conta, e unha orde de compra non é un documento de alcance.
Escriba o obxectivo aprobado nunha soa frase e téñaa xunto á entrega. «Avalíe a autenticación do portal do cliente» e «avalíe a rede interna» levan a paquetes completamente distintos, e a diferenza debe resolverse antes do aprovisionamento, non despois de que chegue un achado. A frase tamén lle dá algo ao que sinalar cando a solicitude medra a metade do traballo.
Se hai un provedor de aloxamento ou outro terceiro no camiño, os seus requisitos van antes que a súa comodidade. Probar a infraestrutura doutra persoa sen o seu permiso é un problema distinto de probar a aplicación que se executa nela.
Nomee o punto de vista e os obxectivos
O punto de vista é a pregunta que a avaliación tenta responder, e determina o paquete de acceso máis que calquera ferramenta que o probador planee usar. Unha proba pública non autenticada necesita un URL e unha xanela temporal. Unha proba autenticada necesita contas dedicadas para os roles concretos dentro do alcance, e unha avaliación interna necesita un punto de entrada definido con rangos de obxectivos explícitos.
| Viewpoint | What you hand over | What it does not authorize |
|---|---|---|
| Public website | Approved URL, TLS hostname, testing window | Internal network entry, adjacent hosts |
| Authenticated app | URL plus per-role test accounts | Other tenants, admin consoles outside scope |
| Private staging | Named private path and test accounts | Production systems behind the same gateway |
| Internal network | Entry point and written target ranges | Anything outside those ranges, including the gateway itself |
Onde entra un túnel non é o mesmo feito que que aplicación está detrás, e desde logo non autoriza sondar o punto de entrada. Dígao explicitamente na entrega, porque a frase «dechesme acceso a esa subrede» chega rápido cando se discute un achado. Unha lista escrita de obxectivos é o único que o resolve despois.
Dea o nome de host TLS xunto co URL. Un enderezo IP espido obriga o probador a adiviñar o nome, e un nome adiviñado produce erros de certificado que se informan como achados en lugar de como un erro de entrega.
Emita identidades dedicadas cunha caducidade
Aprovisione contas que só existan para este traballo; non preste o inicio de sesión diario dun empregado. Axuste a alcanzabilidade de rede e os permisos da aplicación ás tarefas acordadas, organice o rexistro de autenticación por unha vía admitida, e anexe unha data de caducidade cunha persoa nomeada responsable da revogación. Entregue as credenciais por unha canle segura acordada, por separado do documento de alcance que se reenvía por todas partes.
sudo useradd -m -e 2026-12-31 tester01 sudo passwd -S tester01 id tester01 lastlog -u tester01
Rexistre quen recibiu que, e cando. Ese rexistro é a diferenza entre unha entrega controlada e un contrasinal compartido que ninguén pode rastrexar, e é o primeiro que calquera pide tras un incidente. Gárdeo co documento de alcance en lugar de nun fío de chat, e anote a canle de entrega xunto ao destinatario. Unha liña con marca de tempo gaña a un recordo todas as veces.
O campo de caducidade é unha rede de seguridade, non o plan. Alguén ten que retirar aínda a ruta de rede e o rol de aplicación ao final, porque un inicio de sesión caducado nunha rede aínda accesible non é acceso revogado.
Demostre que a entrega funciona antes de que se abra a xanela
Execute vostede mesmo o primeiro salto do probador, desde unha posición o máis próxima posible á súa. Resolva o nome, comprobe a identidade do certificado e confirme que a ruta chega ao enderezo previsto e non a un veciño.
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 a ruta non pode alcanzar un obxectivo, detéñase e reconcilie a entrega en lugar de deixar que o probador descubra unha ruta alternativa. A alcanzabilidade improvisada é como unha avaliación se estende en silencio máis alá do seu alcance, e case nunca se documenta despois.
Envie o contacto operativo, as horas permitidas, as accións excluídas e as condicións de parada coas credenciais. Un probador que non pode localizar a ninguén ás 02:00 tomará unha decisión que vostede non autorizou, e esa decisión describirase no informe coma se estivese dentro do alcance.
NIST SP 800-115 enmarca unha avaliación técnica como probas planificadas seguidas de análise e mitigación, que é a forma que segue esta entrega. As portas anteriores son decisións editoriais de deseño para un enxeñeiro de soporte, non unha lista de verificación citada desa publicación.
Pecha o traballo retirando o acceso
Revogue na orde inversa ao aprovisionamento: roles de aplicación, despois acceso de rede e por último a propia identidade. Confirme cada paso en lugar de supor que a consola fixo o que prometeu o botón. Bloquee a conta antes de matar as súas sesións, ou a sesión simplemente reautenticarase pola ruta antiga. Despois comprobe as conexións establecidas unha vez máis antes de dalo por pechado.
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
Resolva os datos de proba retidos e logo siga a remediación mediante o proceso de informes acordado ao principio. O informe debe indicar a contorna, o nivel de acceso, o alcance e as limitacións, porque rexistra achados dunha avaliación e non é unha declaración permanente de que o sitio sexa seguro.
Garde o rexistro de revogación co rexistro da entrega. Cando se abra o seguinte traballo, querrá saber exactamente que se retirou a última vez e quen o aprobou, en lugar de reconstruír a imaxe de memoria.