Diseño Confiable

Arquitectura y Principios de Diseño de Seguridad

Tres Elementos de Seguridad y Principios de Diseño de Seguridad

  • Integridad (Integrity)
  • Disponibilidad (Availability)
  • Confidencialidad (Confidentiality)

Principio de Diseño Abierto

Diseño Abierto (Open Design)

  • El diseño no debería ser un secreto; un diseño abierto es más seguro.
  • La seguridad no depende del secreto.

Principio de Falla-Seguridad por Defecto

Fallo-Seguridad por Defecto (Fail-safe defaults)

  • Las decisiones de acceso deben basarse en “permitir”, no en “denegar”.
  • Por defecto, no se permite el acceso; el mecanismo de protección solo identifica los casos en que se permite el acceso.
  • Seguridad ante fallos: cualquier sistema complejo debe tener un mecanismo de seguridad de emergencia cuando falle una función; además, se debe tener cuidado con los mensajes de error y los registros para evitar fugas de información.
  • Seguridad por defecto: en su estado inicial, el sistema tiene una configuración predeterminada segura, proporcionando la mayor seguridad mediante el uso del menor número posible de sistemas y servicios.

Principio de Separación de Privilegios

Separación de Privilegios (Separation of Privilege)

  • Un mecanismo de protección que requiere dos llaves para desbloquearse es más robusto y flexible que uno que solo necesita una llave.
  • Objetivo de la separación de privilegios:
    • Evitar conflictos de intereses y abusos de poder individuales.
    • Dividir un privilegio importante en múltiples permisos para que el objeto protegido sea más difícil de obtener ilegalmente, aumentando así la seguridad.
    • Separar las responsabilidades y autoridades de diferentes procesos.

El sistema puede establecer predeterminadamente 3 roles, con cuentas de usuario y permisos mutuamente independientes y funciones separadas:

  • Administrador del Sistema: responsable de la gestión diaria de usuarios y configuraciones del sistema.
  • Administrador de Seguridad: responsable de la activación y desactivación del estado de los usuarios y la configuración de seguridad.
  • Auditor de Seguridad: responsable de auditar las operaciones de los dos roles anteriores, con derechos de exportación de registros para garantizar la trazabilidad de todas las operaciones de los usuarios del sistema.

Principio del Mínimo Privilegio

Mínimo Privilegio (Least Privilege)

  • Cada usuario y programa del sistema debe usar el conjunto mínimo y necesario de privilegios para completar su trabajo.
  • Asegurar que las aplicaciones se ejecuten con los privilegios más bajos posibles.
  • Para cada usuario del sistema que ejecute diversos programas, como bases de datos y servidores web, prestar atención a usar cuentas con el menor privilegio posible, no la cuenta con el máximo privilegio del sistema.
  • Al crear nuevas cuentas, asignar por defecto el rol con el menor privilegio.

Principio de Mecanismo Económico

Mecanismo Económico (Economy of Mechanism)

  • Mantener el diseño del sistema y el código lo más simple y compacto posible.
  • Cuanto más complejo sea el diseño del software, mayor será la probabilidad de errores en el código; si el diseño es lo más elegante posible, la probabilidad de problemas de seguridad será menor.
  • Eliminar código y módulos de funciones innecesarios; conservar solo el código necesario para reducir la superficie de ataque del sistema.
  • Diseñar componentes reutilizables para reducir el código redundante.
  • Económico y adecuado: simple, elegante, modular.
  • No sobrediseñar.

Principio de Mínima Comunalidad

Mínima Comunalidad (Least Common Mechanism)

  • Evitar en la medida de lo posible escenarios donde múltiples objetos compartan el mismo recurso; el número de recursos compartidos y su uso deben ser minimizados.
  • Los objetos compartidos presentan canales potenciales peligrosos de flujo de información e interacción involuntaria; evitar en la medida de lo posible escenarios donde múltiples objetos compartan el mismo recurso.
  • Si uno o más objetos no están satisfechos con el servicio proporcionado por el mecanismo compartido, pueden optar por no usar el mecanismo compartido para evitar ser atacados indirectamente por los errores de otros objetos.
  • Minimizar la memoria compartida.
  • Minimizar la vinculación de puertos.
  • Reducir las conexiones para defenderse de ataques DoS.

Principio de Mediación Completa

Mediación Completa (Complete Mediation)

  • El principio de mediación completa exige que cada acceso a cada objeto sea verificado por un control de seguridad.
  • Cada vez que un sujeto intenta acceder a un objeto, el sistema verifica si el sujeto tiene los privilegios necesarios.
  • Siempre que sea posible, la decisión de control de acceso debe ser tomada por el propietario del recurso; por ejemplo, si se trata de una URL, el servidor backend debe realizar la verificación, no se debe juzgar en el frontend.
  • Prestar especial atención al uso y verificación de caché, ya que no se puede garantizar que la información en caché no haya sido manipulada por hackers en cada acceso. Por ejemplo, suplantación de caché DNS.

Principio de Aceptabilidad Psicológica

Aceptabilidad Psicológica (Psychological Acceptability)

  • Los mecanismos de seguridad pueden añadir una carga adicional a los usuarios, pero esta carga debe ser mínima y razonable.
  • Los mecanismos de seguridad deben ser lo más amigables posible para los usuarios del sistema, facilitando su uso y comprensión.
  • Si el método de configuración es demasiado complejo y tedioso, el administrador del sistema podría configurar accidentalmente una opción incorrecta, volviendo el sistema inseguro.
  • Este principio generalmente está relacionado con la interacción humano-ordenador y el diseño centrado en el usuario (UCD).

Principio de Defensa en Profundidad

Defensa en Profundidad (Defense in Depth)

La defensa en profundidad es un principio de defensa integral con requisitos muy altos. Generalmente requiere que los arquitectos del sistema combinen otros principios de diseño de seguridad, utilizando múltiples mecanismos de verificación de seguridad en varios puntos para observar de manera integral el mecanismo de defensa de seguridad del sistema desde el nivel de arquitectura, en lugar de depender de un solo mecanismo de seguridad.