La seguridad en el centro de cada proyecto

Qué significa «asegurar» y qué no dice

En resumen: La seguridad es una propiedad del sistema entero, no una función que se activa. Un sitio puede cumplir todas las casillas técnicas y seguir siendo vulnerable por su organización.

La palabra abarca tres preguntas distintas que conviene separar. Quién puede acceder a qué: la autenticación y las autorizaciones. Qué ocurre si alguien accede de todos modos: el cifrado, el registro y la capacidad de restaurar. Y qué ocurre si nadie accede pero el servicio se detiene: la disponibilidad, a menudo ausente de las conversaciones sobre seguridad aunque forma parte de ella.

Una confusión habitual trata la seguridad como una capa añadida al final del proyecto. Se decide sobre todo en el diseño: qué datos se recogen, dónde viven, quién los ve, cuánto tiempo se conservan. Esas elecciones determinan la superficie que hay que defender. Las medidas técnicas posteriores solo protegen lo que ya se ha decidido.

Ninguna de estas medidas hace inviolable un sistema, y una página que lo diera a entender mentiría. Lo que hacen es encarecer el ataque, ralentizarlo y hacerlo más visible. Ese es el objetivo real: desplazar la relación entre el esfuerzo de un atacante y lo que obtiene.

Cifrado: en tránsito y en reposo

En resumen: El cifrado de transporte protege lo que circula; el cifrado en reposo protege lo que está almacenado. Responden a amenazas distintas y ninguno sustituye al otro.

HTTPS cifra el intercambio entre el navegador y el servidor: sin él, todo lo que atraviesa una red compartida es legible. Hoy es un requisito previo y no una opción, y los certificados se renuevan automáticamente, lo que eliminó las excusas del coste y del vencimiento olvidado.

El cifrado en reposo protege otra cosa: lo que queda en un disco, una copia de seguridad o una instantánea de base de datos. Aborda el caso en que alguien obtiene el soporte físico o una copia del almacenamiento. En cambio, no protege frente a una cuenta comprometida que tiene derecho a leer esos datos: eso corresponde al control de acceso, no al cifrado.

Acceso: demostrar quién se es y obtener solo lo que corresponde

En resumen: La autenticación establece una identidad; la autorización decide qué puede hacer esa identidad. La segunda se descuida más que la primera y sus fallos cuestan más.

Una contraseña sola es un factor único: quien la obtiene se convierte en el usuario. La autenticación de varios factores añade un elemento que el atacante debe conseguir por separado, lo que hace el phishing bastante menos rentable. En las cuentas que administran un sitio es la medida con mejor relación entre esfuerzo y efecto.

La autorización plantea otra pregunta: una vez dentro, ¿qué puede hacer cada cuenta? El principio útil es el de mínimo privilegio: una cuenta recibe solo los derechos que su tarea exige y los pierde cuando la tarea termina. Los incidentes que más tardan en contenerse suelen venir de cuentas que podían más de lo que su uso real requería.

Los tokens de sesión merecen la misma atención que las contraseñas: validez corta, posibilidad de revocación y rotación. Un token que nunca caduca es una contraseña permanente que su portador no puede cambiar.

La superficie expuesta: formularios, API y cabeceras

En resumen: Todo lo que un visitante puede enviar es una entrada no fiable. La regla cabe en una frase: validar en el servidor, escapar al mostrar, limitar el ritmo.

Una validación hecha solo en el navegador no protege de nada: mejora la comodidad al escribir, pero un atacante no usa el navegador. La validación que cuenta es la del servidor, expresada mediante un esquema explícito que describe lo que se acepta en lugar de lo que se rechaza: una lista de rechazos siempre olvida un caso.

El escapado aborda otro problema: el contenido enviado por un visitante y mostrado tal cual puede ejecutar código en el siguiente. La regla es escapar en el momento de mostrar, según el contexto, y nunca confiar en una limpieza hecha en la entrada.

La limitación de ritmo y los campos trampa responden a los envíos automatizados. No detienen a un atacante decidido, y conviene saberlo: apartan el ruido de fondo, lo que basta para un formulario de contacto y no basta para una página de acceso, que además necesita un bloqueo progresivo.

Las cabeceras de seguridad completan el conjunto indicando al navegador qué debe rechazar: qué fuentes de scripts aceptar, quién puede mostrar el sitio dentro de un marco, si debe adivinar el tipo de un archivo. Se comprueban sobre la respuesta real del servidor, nunca sobre la configuración.

Datos: conservación, copias de seguridad y obligaciones

En resumen: El dato mejor protegido es el que no se ha recogido. Después vienen los plazos de conservación, la restauración probada y las obligaciones del marco aplicable.

La minimización es la medida más eficaz y menos costosa: cada campo recogido es un campo que hay que proteger, conservar, borrar y justificar. Antes de asegurar un dato, vale la pena comprobar que sirve para algo.

Una copia de seguridad que nunca se ha restaurado es una hipótesis, no una garantía. Lo que se comprueba es la restauración: cuánto tarda, qué pierde y quién sabe ejecutarla. Una copia accesible desde el propio sistema al que protege tampoco ayuda mucho frente a un secuestro de datos.

Existen obligaciones en materia de datos personales: información a las personas, plazos de conservación, derechos de acceso y de supresión. Su contenido exacto depende del marco aplicable a la organización y debe precisarlo un profesional habilitado; lo que corresponde al proyecto es hacer que esas obligaciones sean técnicamente realizables en lugar de descubrirlas después.

Lo que la seguridad técnica no resuelve

En resumen: Las medidas descritas aquí protegen un sistema. No protegen ni frente a una organización que las esquiva, ni frente a un proveedor comprometido, ni frente a un error de diseño.

La mayor parte de las intrusiones no aprovecha ningún fallo de software: toma prestado un acceso legítimo obtenido por phishing o por reutilización de contraseña. Ninguna cabecera HTTP lo impide. Lo que lo impide es un segundo factor y personas que saben cómo es un intento.

Un proyecto depende de bibliotecas que no escribe y de servicios que no aloja. Vigilar esas dependencias y saber actualizarlas forma parte del trabajo; creer que la superficie termina en el código a medida es un error de apreciación.

Por último, la seguridad no compensa un error de diseño. Si un dato nunca debería haberse recogido, cifrarlo solo desplaza el problema. La primera pregunta no es cómo proteger ese dato, sino si debe existir.