Envía los detalles en privado por correo electrónico. Incluye el componente o la URL afectados, los pasos para reproducirlo y lo que observaste.
security@tdacorp.inSeguridad
La seguridad es el punto de partida.
Buena parte del riesgo de un producto está alrededor del código y no dentro de él: quién tiene los accesos, dónde viven las credenciales, qué permite la ruta de despliegue, dónde los datos cruzan un límite y qué puede tocar un agente o una integración. Ahí es donde se diseña la seguridad, desde el primer commit y no antes del lanzamiento. Esta página explica cómo se protege el trabajo y cómo informar de un problema.
Prácticas
Cómo se protege el trabajo
Cada fila es una práctica de trabajo, publicada como la política en la que se apoya el trabajo, para poder comprobarla en un encargo en lugar de aceptarla por fe.
- Acceso
Mínimo privilegio, solicitado sistema por sistema
Cada persona, proceso, token e integración recibe el alcance más estrecho que aún permita hacer el trabajo. El acceso se solicita sistema por sistema en lugar de concederse de forma amplia al inicio, y se limita en el tiempo cuando la plataforma lo permite.
- Secretos
Las credenciales se quedan en tu almacén
Las credenciales viven en tu gestor de secretos y se inyectan en tiempo de ejecución. Nunca se incluyen en el código fuente, se pegan en una conversación ni se envían por correo electrónico.
- Despliegue
El camino a producción es reversible
Las publicaciones siguen una ruta definida, con comprobaciones en cada paso, y una reversión que se ha ensayado y no se da por supuesta. Los entornos se reconstruyen a partir del código fuente, de modo que la recuperación es un procedimiento y no una improvisación.
- Límites
Los agentes y las integraciones reciben permisos explícitos
Lo que un agente, una tarea o una integración de terceros puede leer, escribir y llamar se decide y se deja por escrito, y no se hereda de la credencial que ya estuviera disponible. Los datos que cruzan un límite lo cruzan de forma deliberada.
- Diseño
La seguridad empieza en el diseño
El modelado de amenazas se hace mientras se diseña el sistema, no como una pasada de endurecimiento añadida antes del lanzamiento. La forma segura es la primera forma.
- Entradas
La entrada hostil es la suposición por defecto
Todo lo que cruza un límite de confianza se trata como adversario: se valida contra un esquema explícito, se acota y se rechaza cuando no encaja.
- Modo de fallo
Fallar en modo cerrado
Cuando una comprobación no puede completarse o una dependencia no responde, se deniega el acceso, no se deja pasar. Apagado es el valor seguro por defecto.
- Procedencia
Las decisiones quedan por escrito
Las decisiones de seguridad se registran con su razonamiento, de modo que un control puede rastrearse hasta el porqué de su existencia y revisarse en lugar de adivinarse.
- Entrega
El acceso se devuelve al final
La infraestructura se ejecuta en tus cuentas y el código fuente vive en tus repositorios todo el tiempo, de modo que revocar el acceso es algo que puedes hacer sin pedirlo. Lo que se emitió se devuelve al cerrar el encargo, contra la lista a partir de la cual se emitió.
Divulgación
Informar de una vulnerabilidad
¿Has encontrado un problema de seguridad en algo que TDACorp construye o gestiona? Infórmalo primero en privado. Aquí tienes adónde enviarlo, qué ayuda y qué puedes esperar a cambio.
Lo que pedimos
- Informa en privado antes de divulgar en ningún sitio público, y concede un tiempo razonable para investigar y publicar una corrección.
- Envía lo suficiente para reproducirlo: el componente o la URL afectados, los pasos y lo que viste.
- Actúa de buena fe: no accedas a datos que no son tuyos, ni los cambies ni los borres.
- No hagas pruebas que degraden el servicio para otras personas, como denegación de servicio o spam.
Lo que puedes esperar
- Un acuse de recibo que confirme que el informe llegó a una persona.
- Una respuesta clara sobre si se va a corregir, y una idea aproximada de los plazos.
- Un aviso cuando se publique una corrección, y reconocimiento por el hallazgo si lo quieres.
- Ningún problema legal por una investigación de buena fe que siga esta política.
El acuse de recibo es un objetivo y no un acuerdo de nivel de servicio: no hay ningún equipo de seguridad de guardia, por lo que no se promete un tiempo de respuesta fijo. No hay recompensa económica. No se afirma ninguna certificación SOC 2 ni ISO 27001 y no se posee ninguna: lo que se publica en esta página es la práctica en sí, que es aquello de lo que un certificado es un sustituto. La investigación de buena fe que respete esta política es bienvenida, no penalizada.
Sigue leyendo
Dónde queda por escrito la postura.
Esta página explica cómo se protege el trabajo. Estas son las páginas donde la misma postura aparece como cláusula de contrato, como un documento que recibes y como la propia ingeniería.
- PáginaConfianza y datosLa otra mitad de la pregunta: los subencargados del tratamiento detrás de este sitio, qué conserva cada uno, cuánto tiempo se guarda un envío y los datos de la entidad que pide una ficha de proveedor.
- ProcesoEl marco comercialLas reglas de acceso y credenciales de arriba, formuladas como cláusulas de contrato: acuerdo de confidencialidad, propiedad intelectual, mínimo privilegio solicitado sistema por sistema y accesos devueltos al final.
- DocumentosEjemplos de entregablesLa lista de verificación de accesos y seguridad es uno de los ocho formatos, mostrado con lo que registra y el riesgo que elimina.
- ServicioSeguridad y profundidad de sistemasDonde esto deja de ser política y se convierte en el encargo: límites de acceso, endurecimiento y la depuración que empieza donde terminan los registros de la aplicación.
La seguridad es parte del desarrollo, no una partida aparte.
Se diseña desde el primer commit, en cada encargo. Reserva una llamada para hablar de lo que eso significa para tu sistema.