Entrega de acceso para pruebas de seguridad: alcance, cuentas y revocación
Un probador que pide credenciales VPN necesita una entrega con alcance definido, no un inicio de sesión de repuesto. Verifique la autorización, nombre los objetivos, emita cuentas y luego revoque.
Un probador pide una dirección de puerta de enlace, datos de DNS interno y credenciales VPN, y la solicitud se le reenvía con el asunto «se necesita acceso». La solicitud por sí sola no le dice si se trata de una evaluación interna, una prueba de aplicación autenticada o un encargo sobre un sitio web público en el que alguien entendió mal el alcance. Ejecute la entrega como una secuencia con una puerta en cada paso y deténgase en la primera puerta que no se abra. Eso convierte una solicitud vaga en algo que puede autorizar, entregar y revocar después.
Empiece por la autorización, no por las credenciales
Antes de que ninguna dirección salga de su bandeja de entrada, establezca quién es dueño de los objetivos y quién puede aprobar pruebas sobre ellos. Verifique al probador mediante el contacto del encargo que su organización ya utiliza, no mediante la persona que reenvió el correo. Una relación con un cliente no es permiso para probar todos los sistemas accesibles desde una cuenta, y una orden de compra no es un documento de alcance.
Escriba el objetivo aprobado en una sola frase y téngala junto a la entrega. «Evalúe la autenticación del portal del cliente» y «evalúe la red interna» llevan a paquetes completamente distintos, y la diferencia debe resolverse antes del aprovisionamiento, no después de que llegue un hallazgo. La frase también le da algo a lo que señalar cuando la solicitud crece a mitad del encargo.
Si hay un proveedor de alojamiento u otro tercero en el camino, sus requisitos van antes que su comodidad. Probar la infraestructura de otra persona sin su permiso es un problema distinto de probar la aplicación que se ejecuta en ella.
Nombre el punto de vista y los objetivos
El punto de vista es la pregunta que la evaluación intenta responder, y determina el paquete de acceso más que cualquier herramienta que el probador planee usar. Una prueba pública no autenticada necesita una URL y una ventana temporal. Una prueba autenticada necesita cuentas dedicadas para los roles concretos dentro del alcance, y una evaluación interna necesita un punto de entrada definido con rangos de objetivos 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 |
Dónde entra un túnel no es el mismo hecho que qué aplicación está detrás, y desde luego no autoriza sondear el punto de entrada. Dígalo explícitamente en la entrega, porque la frase «me diste acceso a esa subred» llega rápido cuando se discute un hallazgo. Una lista escrita de objetivos es lo único que lo resuelve después.
Dé el nombre de host TLS junto con la URL. Una dirección IP desnuda obliga al probador a adivinar el nombre, y un nombre adivinado produce errores de certificado que se reportan como hallazgos en lugar de como un error de entrega.
Emita identidades dedicadas con una caducidad
Aprovisione cuentas que existan solo para este encargo; no preste el inicio de sesión diario de un empleado. Ajuste la alcanzabilidad de red y los permisos de la aplicación a las tareas acordadas, organice el enrolamiento de autenticación por una vía admitida, y adjunte una fecha de caducidad con una persona nombrada responsable de la revocación. Entregue las credenciales por un canal seguro acordado, por separado del 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
Registre quién recibió qué, y cuándo. Ese registro es la diferencia entre una entrega controlada y una contraseña compartida que nadie puede rastrear, y es lo primero que cualquiera pide tras un incidente. Guárdelo con el documento de alcance en lugar de en un hilo de chat, y anote el canal de entrega junto al destinatario. Una línea con marca de tiempo gana a un recuerdo todas las veces.
El campo de caducidad es una red de seguridad, no el plan. Alguien tiene que retirar todavía la ruta de red y el rol de aplicación al final, porque un inicio de sesión caducado en una red aún accesible no es acceso revocado.
Demuestre que la entrega funciona antes de que se abra la ventana
Ejecute usted mismo el primer salto del probador, desde una posición lo más cercana posible a la suya. Resuelva el nombre, compruebe la identidad del certificado y confirme que la ruta llega a la dirección prevista y no a una vecina.
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
Si la ruta no puede alcanzar un objetivo, deténgase y reconcilie la entrega en lugar de dejar que el probador descubra una ruta alternativa. La alcanzabilidad improvisada es como una evaluación se extiende en silencio más allá de su alcance, y casi nunca se documenta después.
Envíe el contacto operativo, las horas permitidas, las acciones excluidas y las condiciones de parada junto con las credenciales. Un probador que no puede localizar a nadie a las 02:00 tomará una decisión que usted no autorizó, y esa decisión se describirá en el informe como si estuviera dentro del alcance.
NIST SP 800-115 enmarca una evaluación técnica como pruebas planificadas seguidas de análisis y mitigación, que es la forma que sigue esta entrega. Las puertas anteriores son decisiones editoriales de diseño para un ingeniero de soporte, no una lista de verificación citada de esa publicación.
Cierre el encargo retirando el acceso
Revoque en el orden inverso al aprovisionamiento: roles de aplicación, después acceso de red y por último la identidad misma. Confirme cada paso en lugar de suponer que la consola hizo lo que prometió el botón. Bloquee la cuenta antes de matar sus sesiones, o la sesión simplemente se reautenticará por la ruta antigua. Después compruebe las conexiones establecidas una vez más antes de darlo por cerrado.
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
Resuelva los datos de prueba retenidos y luego siga la remediación mediante el proceso de informes acordado al principio. El informe debe indicar el entorno, el nivel de acceso, el alcance y las limitaciones, porque registra hallazgos de una evaluación y no es una declaración permanente de que el sitio sea seguro.
Guarde el registro de revocación con el registro de la entrega. Cuando se abra el siguiente encargo, querrá saber exactamente qué se retiró la última vez y quién lo aprobó, en lugar de reconstruir la imagen de memoria.