Diez Principios para Diseño Seguro APIs

• Save

Diez Principios para la Seguridad por Diseño:

A continuación, se detallan los diez principios de diseño seguro presentados en la fuente, incluyendo citas relevantes cuando apropiado:

1. Principio de Menor Privilegio (Principle of Least Privilege):

• Significa otorgar a cada usuario o proceso solo el acceso absolutamente necesario para realizar su función.
• Ejemplo: Un usuario general puede tener acceso solo a información de «uso interno», mientras que un administrador tiene acceso a información «confidencial» y «las llaves del reino».
• Se enfatiza la importancia de revocar el acceso temporal una vez que ya no es necesario.
• Este principio reduce la superficie de ataque.

1. Defensa en Profundidad (Defense in Depth):

• Implica no depender de un único mecanismo de seguridad, sino implementar múltiples capas de defensas interrelacionadas.
• Ejemplo: En una arquitectura típica (usuario, endpoint, red, aplicación, base de datos), se deben aplicar medidas de seguridad en cada capa (gestión de identidad y acceso, seguridad del endpoint, firewalls, controles de acceso a la aplicación, escaneo de vulnerabilidades, cifrado de datos, backup y recuperación).
• El objetivo es que múltiples defensas deban fallar para que un atacante tenga éxito. «I never want to rely on any single security mechanism to secure the entire system. I want to have a system of interrelated uh defenses and make sure that they all would have to fail in order for someone to actually get into the system.»

1. Principio de Fallo Seguro (Fail Safe):

• Asume que cualquier sistema eventualmente fallará debido a la ley de Murphy.
• El principio dicta que, en caso de fallo, el sistema debe hacerlo en un estado seguro.
• Ejemplo: Un firewall que falla debería bloquear todo el tráfico (incluso el legítimo) en lugar de permitir el paso indiscriminado. «the condition is it fails but it fails in a secure position that’s what we want.»

1. Principio KISS (Keep It Simple Stupid) / Economía de Mecanismo:

• Aboga por la simplicidad en el diseño del sistema.
• La complejidad es considerada enemiga de la seguridad, ya que introduce más posibles vulnerabilidades y dificulta la verificación de su correcto funcionamiento. «complexity is the enemy of security. The more complex a system is the harder it is to ensure that it’s going to do in fact what we want it to do.»
• Un diseño simple reduce las vulnerabilidades adicionales.

1. Separación de Deberes (Separation of Duties):

• Implica dividir tareas críticas entre diferentes individuos para evitar que una sola persona tenga control total sobre un proceso sensible.
• Ejemplo: Una puerta con dos cerraduras, donde cada cerradura requiere una llave diferente en posesión de personas distintas. «nobody is opening this door unless both keys have been used to unlock it so in other words I’ve spread the ability to open the door across two people why would I do that because now it makes it harder for one single bad actor to do something bad to the system it requires collusion in order to break into this system.»

1. Diseño Abierto (Open Design) / Principio de Kerckhoffs:

• Favorece la transparencia y la claridad en el diseño del sistema, especialmente en algoritmos de seguridad como la criptografía.
• Se opone a la «seguridad por oscuridad», donde la seguridad se basa en mantener el funcionamiento interno del sistema en secreto.
• El Principio de Kerckhoffs establece que la seguridad de un criptosistema debe residir únicamente en la clave secreta, no en el secreto del algoritmo en sí. «…the only thing that someone should should really keep as a secret would be the key… the way the system works is visible by anyone and that’s how the best crypto systems in the world work it’s not security by obscurity it’s security through openness.»

1. Segmentación:

• Consiste en dividir el sistema en componentes aislados para limitar el impacto de una brecha de seguridad.
• Ejemplo: Los cortafuegos físicos en edificios evitan la propagación de incendios entre unidades. Esto se aplica también a redes para aislar componentes con diferentes niveles de sensibilidad. «we take components that are of one level of security and put them in one area isolated from other areas that may have different levels of sensitivity.»

1. Usabilidad (Usability) / Factores Humanos:

• Reconoce que los humanos son a menudo el eslabón más débil en la cadena de seguridad.
• Los sistemas deben ser diseñados para ser fáciles de usar, ya que si son demasiado complejos, los usuarios encontrarán formas de eludir las medidas de seguridad para realizar su trabajo.
• Ejemplo de contraseñas extremadamente complejas que llevan a los usuarios a escribirlas en lugares inseguros. «…if we make a system too hard to use well then people will find ways to get around the security because not because they’re evil just because they need to get their jobs done and they don’t understand the reason for all that complexity…»

1. Minimización de la Superficie de Ataque (Minimize Attack Surface):

• Busca reducir la cantidad de puntos a través de los cuales un atacante podría intentar acceder o comprometer el sistema.
• Esto se logra limitando interfaces externas, el acceso remoto y el número de componentes del sistema. «if you’re trying to secure an infrastructure you want to present this to the outside world you want to in fact minimize the attack surface you want to make it so that it’s really hard for somebody to thread the needle and get right to where your sensitive stuff is.»

1. Seguridad por Defecto (Secure by Default):

• Establece que la configuración predeterminada del sistema debe ser lo más segura posible.
• Ejemplos de prácticas inseguras por defecto incluyen tener todas las funciones activadas innecesariamente o usar contraseñas predeterminadas comunes.
• Las mejores prácticas incluyen activar solo las capacidades necesarias, requerir que los usuarios establezcan contraseñas únicas durante la configuración y forzar la creación de identificadores únicos para cuentas administrativas. «…secure by default would say only the required uh capabilities are turned on… it’s much better if you make people Supply a password something that’s determined during the configuration and set up the system that way you end up with uniqueness…»

Conclusión:

La fuente concluye enfatizando que, si bien lograr una seguridad adecuada no es tarea fácil, la adopción de estos diez principios de diseño seguro permite «hornear» la seguridad en los sistemas desde el inicio. Esto no solo resulta en sistemas más seguros, sino que también es más rentable a largo plazo al evitar costosas correcciones posteriores.