Durante mi trabajo como arquitecto en proyectos de implementación de IdM, analicé docenas de implementaciones de mecanismos de autorización tanto en soluciones internas de empresas como en productos comerciales, y puedo decir que casi en todas partes con requisitos relativamente complejos no se realizan correctamente o, al menos, no de manera óptima. La razón, en mi opinión, es la poca atención tanto del cliente como de los desarrolladores a este aspecto en las etapas iniciales y la evaluación insuficiente del impacto de los requisitos. Esto confirma indirectamente el mal uso generalizado del término: cuando veo la frase "autorización de dos factores", empiezo a sentir dolor justo debajo de la espalda. En aras del interés, analizamos los primeros 100 artículos sobre Habré en los resultados de búsqueda de "autorización", el resultado fue decepcionante, hubo mucho dolor:
En más del 80% de los casos, el término se usa incorrectamente, la palabra "autenticación" debería usarse en su lugar. A continuación, trataré de explicar qué es y por qué es extremadamente importante prestar especial atención a este tema.
Que es esto
Para citar Wikipedia:
Desde el punto de vista de cualquier sistema de información, este es el proceso de toma de decisiones para proporcionar acceso al sujeto para realizar la operación en función de cualquier conocimiento sobre el tema. En este punto, el sujeto, por regla general, ya debería estar
identificado (necesitamos saber quién es) y
autenticado (se confirma su identidad).
La implementación de la autorización en el desarrollo de un sistema o producto de información corporativa enfocado en el sector corporativo es una tarea muy difícil y responsable, que a menudo recibe una atención insuficiente en la etapa de diseño y la etapa de desarrollo inicial, lo que en el futuro conduce a una implementación "muleta".
Problema
Veamos qué requisitos de autorización se cumplen y por qué es extremadamente importante considerarlos inicialmente al diseñar un sistema, y no posponerlo para el futuro. Por lo general, existen dos fuentes de requisitos de autorización en un sistema de información corporativo: estos son los negocios y la seguridad de la información. En general, una empresa desea mantener secretos confidenciales y otorgar autoridad a los usuarios de acuerdo con su función en el proceso comercial, y la seguridad quiere garantizar la suficiencia mínima de autoridad para cada usuario y acceso de auditoría.
Tomemos, por ejemplo, un sistema hipotético para negociar contratos de grandes empresas, una típica empresa sangrienta. Es probable que surjan los siguientes
requisitos de autorización comercial :
- Un usuario que no está relacionado con un contrato específico no debería verlo en el sistema
- El autor del contrato debe verlo en todas las etapas.
- Un usuario con una calificación de al menos 10 tiene derecho a crear un contrato.
- El visitante debe ver el contrato, comenzando con la recepción en el escenario y más adelante.
- Los jefes de departamento deberían ver los contratos de sus unidades en la jerarquía.
- El autor del contrato y el jefe de la unidad tienen derecho a rescindir el contrato en cualquier etapa de aprobación.
- La dirección y la secretaría de la oficina central deben ver los documentos de todas las sucursales.
- El usuario que creó el contrato no debe tener el derecho de respaldarlo.
Por seguridad, podríamos obtener los siguientes requisitos :
- Sepa quién tiene acceso a un contrato específico.
- Sepa quién tuvo acceso a un contrato específico en un momento dado.
- Privar al usuario del acceso a documentos previamente disponibles al cambiar sus tareas laborales.
Creo que los desarrolladores ya estaban asustados :). Un dolor adicional es la alta variabilidad de estos requisitos. Por cierto, según las estadísticas de una gran franquicia 1C, los requisitos de autorización adicionales son una de las tareas más comunes para personalizar configuraciones típicas.
Entonces, indicamos por qué estos requisitos son problemáticos:
- No son estables. La probabilidad de su cambio, incluso a corto plazo, tiende a 1.
- Son transversales. Su implementación afecta a todas las capas, desde el diseño de la base de datos hasta la interfaz de usuario.
- Se encuentran en el plano del área temática. Esto conduce a una fuerte conectividad del mecanismo de autorización con una capa de lógica empresarial.
- Afectan el rendimiento.
Soluciones
Los modelos de control de acceso desarrollados nos ayudan a resolver este problema:
MAC es un modelo de control de acceso de credenciales. El acceso del sujeto al objeto está determinado por su nivel de acceso: el nivel de acceso del sujeto no debe ser inferior al nivel de secreto del objeto.
DAC - control de acceso directo. El acceso del sujeto al objeto está determinado por la presencia del sujeto en la lista de acceso
(ACL) del objeto.
RBAC es un modelo a seguir de control de acceso. El acceso del sujeto al objeto está determinado por la presencia del rol del sujeto que contiene los poderes correspondientes al acceso solicitado.
ABAC es un modelo de atributo de control de acceso. El acceso del sujeto al objeto se determina dinámicamente en función de un análisis de políticas que tienen en cuenta los valores de los atributos del sujeto, objeto y entorno. Esto también incluye
PBAC, RAdAC, CBAC , con algunos matices (
revisión elegante de CUSTIS ).
Se recomienda su uso en su forma original sin reinventar la rueda. Muy a menudo en sistemas de información complejos se usa una combinación de modelos. Por ejemplo, la combinación ACL + RBAC es popular cuando se incluye un rol en una lista de acceso. Sin embargo, el uso correcto de modelos confeccionados tampoco es una tarea fácil. No todos pueden elegir el modelo correcto, separarlo de la lógica empresarial y lograr un rendimiento aceptable del mecanismo de autorización.
Para implementar los requisitos establecidos anteriormente en la sección "Problemas", a primera vista, elegiría la combinación PBAC + ACL. Los requisitos podrían implementarse de la siguiente manera:
Los requisitos de IS enumerados se implementan sin problemas usando ACL, pero implementamos los requisitos comerciales 5 y 7 usando PBAC. Por lo tanto, para implementar los requisitos de IS 1 y 2, deberá agregar un diario o un mecanismo similar a ellos, porque a pesar de su belleza, las reglas dinámicas están mal auditadas:
Total
La autorización es un tema inmerecidamente descuidado, tanto en publicaciones como directamente en el proceso de desarrollo. El niño atornillará la autenticación de dos factores por SMS al sitio. Implementar correctamente la autorización en el sistema corporativo sin hacer muletas es una tarea difícil de la que los señores y arquitectos rompen las lanzas, y muchos productos comerciales populares (por ejemplo, Atlassian Jira) se colocan en muletas debido a la complejidad de los requisitos.
Estamos planeando una serie de artículos sobre modelos de autorización y el tema en su conjunto. Agradecemos preguntas y sugerencias sobre temas para su consideración.