Controles proactivos en el desarrollo seguro de software (Implementación de Control de Accesos (y como ser un developer «cuqui» y muy pro))

Introducción:

Control de Acceso es el proceso mediante el cual se conceden o deniegan las solicitudes de acceso a una característica o recurso en particular. Cabe señalar que la autorización no equivale a una autenticación (verificación de la identidad). Estos términos y sus definiciones se confunden con frecuencia y no debemos caer en ese error.

El diseño del Control de Acceso puede comenzar de forma sencilla, pero a menudo puede convertirse en un control de seguridad bastante complejo y pesado. Los siguientes requisitos de diseño de control de acceso «positivos» deben ser considerados en las etapas iniciales del desarrollo de la aplicación. Una vez que se ha elegido un patrón de diseño de control de acceso específico, a menudo es difícil y lento rediseñar el control de acceso en su aplicación con un nuevo patrón. El control de acceso es una de las principales áreas del diseño de seguridad de aplicaciones que debe ser muy meditado por adelantado, especialmente cuando se trata de requisitos como el multi-tenancy y el control de acceso horizontal (específico de datos).

Básicos de la implementación de Control de accesos

Forzar todas las solicitudes para que pasen por las verificaciones de control de acceso

La mayoría de los frameworks y lenguajes sólo comprueban una característica para el control de acceso si un programador la añade. Lo inverso es un diseño más centrado en la seguridad, donde se verifica primero todo el acceso. Considere la posibilidad de utilizar un filtro u otro mecanismo automático para garantizar que todas las solicitudes pasan por algún tipo de control de acceso.

Negar por defecto

En línea con la comprobación automática del control de acceso, debemos considerar negar todas las comprobaciones de control de acceso para características que no se hayan configurado para el control de acceso. Normalmente ocurre lo contrario en el caso de que las características recién creadas otorgan automáticamente a los usuarios acceso completo hasta que un desarrollador ha agregado esa verificación

Principio del menor privilegio

Al diseñar los controles de acceso, cada usuario o componente del sistema debe tener asignado el privilegio mínimo necesario para realizar una acción durante el menor tiempo posible.

Evitar las comprobaciones de control de acceso de codificación dura

Muy a menudo, demasiado a menudo a decir verdad, la política de control de acceso está codificada en profundidad en el código de aplicación. Esto hace que auditar o probar la seguridad de ese software sea muy difícil y requiera mucho tiempo. La política de control de acceso y el código de aplicación, cuando sea posible, deben estar separados. Otra manera de decir esto es que su capa de aplicación (controles en código) y su proceso de toma de decisiones de control de acceso (el «motor»de control de acceso) deben estar separados cuando sea posible.

Código de la actividad

La mayoría de los marcos web utilizan el control de acceso basado en roles como el método principal para codificar los puntos de aplicación del código. Si bien es aceptable utilizar roles en los mecanismos de control de acceso, la codificación específica del rol en el código de aplicación es un patrón antipatrón. Debemos plantearnos la posibilidad de verificar si el usuario tiene acceso a esa característica en código, en lugar de verificar qué rol tiene el usuario en código. Esta comprobación debe tomar en cuenta el contexto de la relación específica entre datos y usuario. Por ejemplo, un usuario puede ser capaz de modificar proyectos en general dado su rol, pero el acceso a un proyecto dado también debe ser verificado si las reglas de negocio/seguridad dictan permisos explícitos para hacerlo.

Así que en lugar de la función de codificación dura, que comprueba todo el código base:

if (user.hasRole(«ADMIN»)) || (user.hasRole(«MANAGER»)) {

deleteAccount();

}

Podría considerarse el siguiente código:

if (user.hasAccess(«DELETE_ACCOUNT»)) {

deleteAccount();

}

Los datos confiables del lado del servidor deben conducir el proceso de control de acceso

La gran mayoría de los datos que usted necesita para tomar una decisión de control de acceso (quién es el usuario y está conectado, qué derechos tiene el usuario, cuál es la política de control de acceso, qué característica y datos se está solicitando, qué hora es, qué geolocalización es, etc.) deben ser recuperados «del lado del servidor» en una aplicación estándar de servicio web o web. Los datos de política, como la función del usuario o una regla de control de acceso, nunca deben formar parte de la solicitud. En una aplicación web estándar, los únicos datos del lado del cliente que se necesitan para el control de acceso son los identificadores de los datos a los que se accede. La mayoría de todos los demás datos necesarios para tomar una decisión de control de acceso deben ser recuperados del lado del servidor.

Política de control de acceso

¿Por qué necesitamos una política de control de acceso para el desarrollo web?

La intención de tener una política de control de acceso es asegurar que los requisitos de seguridad sean descritos claramente a arquitectos, diseñadores, desarrolladores y equipo de soporte, de manera que la funcionalidad de control de acceso sea diseñada e implementada de manera consistente.

Roles de control de acceso

Acceso Basado en Funciones (RBAC)

En el Control de Acceso Basado en Funciones (RBAC), las decisiones de acceso se basan en los roles y responsabilidades del individuo dentro de la organización o base de usuarios.

El proceso de definición de roles suele basarse en el análisis de los objetivos y la estructura fundamental de una organización y suele estar ligado a la política de seguridad. Por ejemplo, en una organización médica, las diferentes funciones de los usuarios pueden incluir las de médicos, enfermeras, asistentes, enfermeras, pacientes, etc. Obviamente, estos miembros requieren diferentes niveles de acceso para realizar sus funciones, pero también los tipos de transacciones web y su contexto permitido varían enormemente dependiendo de la política de seguridad y cualquier regulación relevante (HIPAA, Gramm-Leach-Bliley, etc.).

Un marco de control de acceso RBAC debería proporcionar a los administradores de seguridad de aplicaciones web la capacidad de determinar quién puede realizar qué acciones, cuándo, desde dónde, en qué orden y, en algunos casos, bajo qué circunstancias relacionales.

Las ventajas de utilizar esta metodología son:

  • Los roles se asignan en base a la estructura organizacional con énfasis en la política de seguridad organizacional.
  • Fácil de usar
  • Fácil de administrar
  • Incorporado en la mayoría de las estructuras
  • Se ajusta a los principios de seguridad, como la separación de funciones y los privilegios mínimos.

Problemas que se pueden encontrar al utilizar esta metodología:

  • La documentación de las funciones y los accesos debe mantenerse rigurosamente.
  • Multi-tenancy no se puede implementar de manera efectiva a menos que exista una forma de asociar las funciones con los requisitos de capacidad multi-tenancy, por ejemplo, OU en Active Directory.

Existe una tendencia a que se produzca un desplazamiento de alcance, por ejemplo, se pueden conceder más accesos y privilegios de los previstos. O se puede incluir a un usuario en dos roles si no se realiza una revisión de acceso adecuada y una revocación posterior.

No soporta control de acceso basado en datos

Las áreas de precaución mientras se utiliza el PCRC son:

  • Los roles sólo deben ser transferidos o delegados usando estrictos procedimientos y firmas.
  • Cuando un usuario cambia su rol a otro, el administrador debe asegurarse de que el acceso anterior sea revocado de tal manera que en cualquier momento dado, un usuario sea asignado sólo a esos roles en base a la necesidad de conocerlos.
  • La garantía de la RBAC debe llevarse a cabo mediante revisiones estrictas de los controles de acceso.

Control de Acceso Discrecional (DCA)

El Control de Acceso Discrecional (DAC) es un medio de restringir el acceso a la información basada en la identidad de los usuarios y/o la pertenencia a ciertos grupos. Las decisiones de acceso suelen basarse en las autorizaciones concedidas a un usuario en función de las credenciales que éste haya presentado en el momento de la autenticación (nombre de usuario, contraseña, token de hardware/software, etc.). En la mayoría de los modelos DCA típicos, el propietario de la información o de cualquier recurso puede cambiar sus permisos a su discreción (por lo tanto, el nombre).

Un marco DAC puede proporcionar a los administradores de seguridad de aplicaciones web la capacidad de implementar un control de acceso de grano fino. Este modelo puede ser la base para la implementación del control de acceso basado en datos.

Las ventajas de utilizar este modelo son:

  • Fácil de usar
  • Fácil de administrar
  • Se alinea con el principio de los privilegios mínimos.
  • El propietario del objeto tiene control total sobre el acceso concedido

Problemas que se pueden encontrar al utilizar esta metodología:

  • La documentación de las funciones y los accesos debe mantenerse rigurosamente.
  • Multi-tenancy no se puede implementar de manera efectiva a menos que exista una forma de asociar las funciones con los requisitos de capacidad multi-tenancy, por ejemplo, OU en Active Directory.
  • Existe una tendencia a que se produzca un desplazamiento de alcance, por ejemplo, se pueden conceder más accesos y privilegios de los previstos.

Las áreas de precaución mientras se usa DAC son:

  • Al otorgar fideicomisos
  • La garantía del DAC debe llevarse a cabo mediante revisiones estrictas de control de acceso.

Control de Acceso Obligatorio (MAC)

El Control de Acceso Obligatorio (MAC) asegura que el cumplimiento de la política de seguridad organizacional no se base en el cumplimiento voluntario del usuario de la aplicación web. MAC asegura la información asignando etiquetas de sensibilidad a la información y comparándola con el nivel de sensibilidad en el que opera un usuario. El MAC suele ser apropiado para sistemas extremadamente seguros, incluyendo aplicaciones militares seguras de varios niveles o aplicaciones de datos de misión crítica.

Las ventajas de utilizar esta metodología son:

  • El acceso a un objeto se basa en la sensibilidad del mismo.
  • El acceso basado en la necesidad de saber se cumple estrictamente y el avance del alcance tiene una posibilidad mínima.
  • Sólo un administrador puede conceder el acceso

Problemas que se pueden encontrar al utilizar esta metodología:

  • Difícil y costoso de implementar
  • No es ágil

Las áreas de precaución mientras se usa MAC son:

  • Clasificación y asignación de la sensibilidad a un nivel apropiado y pragmático
  • Debe garantizarse el cumplimiento de las normas MAC para garantizar que la clasificación de los objetos se realiza al nivel adecuado.

Control de acceso basado en permisos

El concepto clave del control de acceso basado en permisos es la abstracción de las acciones de la aplicación en un conjunto de permisos. Un permiso puede ser representado simplemente como un nombre basado en una cadena, por ejemplo «READ». Las decisiones de acceso se toman comprobando si el usuario actual tiene el permiso asociado con la acción de aplicación solicitada.

La relación entre el usuario y el permiso puede ser satisfecha mediante la creación de una relación directa entre el usuario y el permiso (llamado una concesión), o indirecta. En el modelo indirecto, la concesión de permisos se otorga a una entidad intermedia, como un grupo de usuarios. Un usuario se considera miembro de un grupo de usuarios si y sólo si el usuario hereda los permisos del grupo de usuarios. El modelo indirecto facilita la gestión de los permisos para un gran número de usuarios, ya que cambiar los permisos asignados al grupo de usuarios afecta a todos los miembros del grupo de usuarios.

En algunos sistemas de control de acceso basado en permisos que proporcionan un control de acceso a nivel de objeto de dominio de grano fino, los permisos pueden agruparse en clases. En este modelo se asume que cada objeto de dominio en el sistema puede estar asociado a una clase que determina los permisos aplicables al objeto de dominio respectivo. En tal sistema se puede definir una clase «DOCUMENTO» con los permisos «READ»,»WRITE» y «DELETE»; una clase «SERVIDOR» se puede definir con los permisos «START»,»STOP» y «REBOOT».

2 respuesta a “Controles proactivos en el desarrollo seguro de software (Implementación de Control de Accesos (y como ser un developer «cuqui» y muy pro))”

  1. Amigo Itzala74,

    Lo primero, el post tiene la firma de tu experiencia. Eso se agradece 😉

    Para aportar un poco más, yo hablaría sobre el control de acceso de doble sentido (no se su nombre tecnico anglosajon chupiguay jaja). Hay dos sentidos:

    – El usuario X puede acceder (leer, escribir, borrar, etc) al recurso Y?
    – El recurso Y puede ser accedido por el usuario X?

    Creo que un buen control de acceso debería hacer esas dos comprobaciones. Los usuarios tienen niveles de acceso, pero los recursos tambien deben tener niveles de confidencialidad.

    Siguiendo esa premisa se pueden evitar escenarios como que un atacante Fulanito consiga incluirse a si mismo en un grupo (rol) que tiene permiso para leer el recurso Y, ya que después se comprobaría si el recurso Y puede ser leido por Fulanito debido a su nivel de acceso.

    En más detalle:

    Fulanito ha conseguido meterse en el grupo «Administradores» explotando una vulnerabilidad. Pero Fulanito aun siendo admin, tiene un nivel de acceso igual a 5.

    El recurso Y tiene un nivel de confidencialidad igual a 7. Cuando Fulanito intenta acceder al recurso Y no va a poder leerlo, porque aunque tiene el rol de Administrador, no tiene el nivel de acceso requerido.

    Ese escenario solamente es válido si y solo si los administradores de la aplicacion se dividen en dos:

    – Administradores de usuarios y grupos.
    – Administradores de recursos.

    Si esto no fuera asi, Fulanito podría subirse a si mismo su nivel de acceso a 7 para poder leer el recurso Y.

    Implementar este mecanismo de control de acceso de doble sentido es costoso, pero realmente eficaz, por lo que es util para ciertas aplicaciones del mundo real que requieran un gran nivel de seguridad (bancos, fuerzas armadas y seguridad, infraestructuras criticas, etc).

    Un abrazo!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.