La capa a la que la mayoría de los equipos no llega.

• Accesos que se fueron acumulando: credenciales amplias y permanentes concedidas al arrancar porque acotarlas era más difícil.
• Un producto a punto de recibir por primera vez preguntas de seguridad del proceso de compras de un cliente.
• Un agente, tarea o integración cuyos permisos se heredaron en lugar de decidirse.
• Un comportamiento que los registros de la aplicación no pueden explicar, donde la respuesta está en el entorno de ejecución, el kernel, el sistema de archivos o la red.
• Un sistema que necesita endurecerse como decisión de diseño y no como una pasada antes del lanzamiento.

Una arquitectura de referencia, es decir, la forma sobre la que se diseña el trabajo y no un registro de sistemas entregados. Nombra capas y responsabilidades, nunca productos: lo que se ejecuta en una capa determinada es una decisión que se toma contigo durante el alcance, no aquí por adelantado.

• Un modelo de acceso: quién y qué puede llegar a qué sistema, con qué privilegio y durante cuánto tiempo.
• Gestión de credenciales y secretos, con los secretos en tu almacén e inyectados en tiempo de ejecución, sin subirlos al repositorio ni pegarlos en ningún sitio.
• Una revisión de amenazas hecha mientras se diseña el sistema, no aplicada después.
• Decisiones de endurecimiento registradas con su razonamiento, para que un control pueda revisarse en lugar de adivinarse.
• Depuración de bajo nivel y de sistemas: la causa rastreada y el cambio que la corrige.
• Una lista de verificación de accesos y seguridad, rellenada para el proyecto y devuelta al final.

• Accesos amplios y permanentes concedidos al arrancar porque acotarlos bien era más difícil.
• Credenciales en el código fuente, en un hilo de chat o en un ticket, donde sobreviven a la persona que las puso.
• Un radio de impacto heredado de una credencial cómoda y no decidido por nadie.
• Una comprobación que falla en modo abierto, de modo que una dependencia inalcanzable se convierte en una elusión inadvertida.
• Un fallo recurrente que nadie sabe explicar, donde la investigación se detiene en el límite de la aplicación.

• Certificación de cumplimiento. No se ofrece ni se tiene ninguna auditoría SOC 2 o ISO 27001, y una consultora que vende el certificado es otro negocio.
• Pruebas de penetración como entregable. Las pruebas independientes deben ser independientes; aquí se construye y se revisa el sistema en lugar de certificarlo.
• Una revisión de seguridad sin autoridad para cambiar nada, donde el informe es el producto y no se arregla nada.
• Contratos de respuesta a incidentes. No hay un equipo de guardia, y prometer un tiempo de respuesta que nadie puede cubrir sería peor que rechazarlo.
• Cualquier cosa que exija publicar una afirmación de seguridad antes de que sea cierta. Lo que se afirma es la práctica, y se puede comprobar en /security.

1. 01

   La lista de accesos, y su devolución

   Qué se concedió, a qué, con qué privilegio y cuándo se devolvió. El acceso se pide por sistema y no se concede de forma amplia al principio, lo que hace que devolverlo sea una lista de verificación y no un ejercicio de arqueología.

2. 02

   Secretos en tu almacén, nunca en el nuestro

   Las credenciales viven en tu gestor de secretos y se inyectan en tiempo de ejecución durante todo el proyecto. No hay paso de migración al final porque nunca estuvieron en otro sitio.

3. 03

   Las decisiones, con su razonamiento

   Cada control rastreado hasta el motivo por el que existe, para que tu equipo pueda revisarlo en lugar de heredarlo. Un límite cuyo motivo se ha perdido es un límite que acaba ampliando alguien con buena voluntad.

4. 04

   La causa, no solo el arreglo

   Cuando el trabajo fue una investigación, qué ocurría de verdad y cómo se estableció, para que la próxima vez se reconozca en lugar de volver a investigarse desde cero.

• PolíticaPrácticas de seguridadLa práctica de ingeniería declarada: accesos, credenciales, caminos de despliegue, límites de los datos, permisos de los agentes y entrega.
• ProyectoUn gestor de pantalla con separación de privilegiosEl desarrollo del sistema operativo, y la evidencia de que el trabajo continúa de verdad por debajo de la capa de aplicación.
• ArtículoCómo elegir un sistema de initUna decisión de sistemas argumentada por completo, incluido lo que costó, como muestra de cómo se hace este razonamiento.