Modelo de mandato de control de acceso (MAC): descripción general y aplicaciones de aplicación

Modelo de control de acceso obligatorio (MAC): un método de control de acceso con un conjunto fijo de permisos. Por lo general, este MAC se usa en sistemas con requisitos de alta seguridad y está al servicio de varias agencias de aplicación de la ley y organizaciones asociadas con secretos estatales u oficiales.

Modelo MAC

El MAC, a pesar de estar contenido en muchos artículos y materiales, se menciona con mayor frecuencia casualmente y en forma de salsa picante a algo así como una breve mención de MLS en SELinux. Dado que muchos limitan su amistad con SELinux utilizando la receta de " cómo deshabilitar SELinux ", el MAC a menudo también lo respeta. Por lo tanto, primero brevemente sobre MAC.

Si está familiarizado con el modelo, puede pasar a la siguiente sección de inmediato.

Idea principal

El modelo de seguridad abstracto implementado en el MAC clásico (como lo saben los agentes del orden) es el siguiente (imagen clásica que ilustra el modelo de Bell-Lapadula ):


El modelo MAC es inherentemente una implementación "electrónica" de un flujo de trabajo "secreto" en papel. El MAC tiene los siguientes "actores":

• La jerarquía de niveles de acceso que se procesan en el sistema (generalmente registrados en el sistema operativo). Por conveniencia, a menudo se especifica en forma de números sin signo (de 0 a un valor limitado por la implementación). En este caso, para comparar los niveles de acceso (mayor / menor / igual), se utilizan las operaciones aritméticas más simples (igual, menor, mayor).
• Objeto con un nivel de privacidad. Cualquier archivo, directorio en el sistema de archivos, celda o registro en la tabla de la base de datos, tabla en la base de datos, la base de datos en sí, paquete de red, etc. Al objeto se le asigna cualquier valor de la jerarquía de niveles de acceso. Para el objeto, se permite aumentar el nivel de secreto (cambiar a un valor de nivel más alto que el actual). No se permite categóricamente una disminución en el nivel de secreto (aunque es bastante factible con la ayuda de ciertos trucos).
• Asunto con nivel de acceso. El proceso de una aplicación o una sesión de usuario (esencialmente también el proceso de la aplicación). La etiqueta de nivel de acceso es heredada del sujeto por todos los objetos creados por este sujeto.

El valor del nivel de acceso del sujeto o el nivel de secreto del objeto generalmente se denomina "nivel de credencial", "etiqueta de credencial" o simplemente "etiqueta" (en STCSEC este término se denomina "nivel de clasificación jerárquica"). Simple, espacioso y casi inequívoco.

La verificación de autorización se lleva a cabo en cada hecho del acceso del sujeto al objeto protegido por el MAC. En este caso, el modelo de control de acceso de credenciales generalmente se usa junto con otros mecanismos de control de acceso, por ejemplo, el DAC (modelo UNIX y POSIX ACL). En este caso, el MAC se verifica en último lugar. Primero, DAC verifica el acceso (como el menos seguro) y luego MAC.

Al verificar la elegibilidad del acceso del sujeto al objeto de acuerdo con el modelo obligatorio, son posibles las siguientes combinaciones:

1. La etiqueta de credencial del sujeto es igual a la etiqueta de credencial del objeto. En este caso, el sujeto puede leer y modificar el objeto.
2. La etiqueta de credencial del sujeto es más alta que la etiqueta de credencial del objeto. El sujeto solo puede leer el objeto: lo ve, pero no puede cambiarlo.
3. La etiqueta de credencial del sujeto es más baja que la etiqueta de credencial del objeto. El sujeto tiene permitido formalmente crear un objeto con una marca de credencial más alta (el llamado "aumentar el nivel de secreto del objeto"). En la práctica, el sujeto no tiene la capacidad técnica para realizar esta operación (simplemente "no ve" el objeto variable, por ejemplo, un archivo o un directorio con archivos).

También en MAC existe una “categoría” (en la terminología STCSEC este término se llama “categorías no jerárquicas”). Las categorías en MAC son opcionales. En la práctica, la implementación de categorías MAC se utiliza para el control de acceso "horizontal" entre diferentes departamentos de la organización. En este caso, los empleados, a pesar de un nivel obligatorio, solo tendrán acceso a aquellas categorías de objetos a las que tienen acceso de acuerdo con su etiqueta.

Limitaciones y Vulnerabilidades

MAC tiene sus limitaciones y características:

1. Los usuarios del sistema no pueden determinar de forma independiente el acceso de los sujetos a los objetos. De todo el arsenal de control de acceso a objetos en el MAC, solo hay una etiqueta de credencial y una categoría de credencial que están asociadas con este objeto. La gestión del acceso de los sujetos a los objetos solo la realizan los administradores.
2. Si el usuario desea cambiar la etiqueta de credencial del objeto cuyo autor es, entonces debe ir a la sesión de etiqueta de destino. Esto se debe al hecho de que el usuario no puede especificar la etiqueta a voluntad, sino que solo puede pasar la etiqueta al objeto "por herencia". Al mismo tiempo, el usuario solo puede trabajar en una sesión de una etiqueta de credencial.
3. Dado que el MAC se usa junto con otros modelos de control de acceso, surgen colisiones: a veces no es tan fácil descubrir en qué "capa" del acceso al sistema de seguridad se denegó. Se requiere una "sintonización" fina de todas las capas de protección.
4. Además de la configuración de acceso a través del kit de herramientas MAC, se requiere una política de seguridad. Debe describir qué significan los valores específicos de las credenciales (esto está fuera del MAC), qué objetos están protegidos, a qué sujetos tienen derecho de acceso. Sin una regulación acordada, el MAC por sí solo no proporcionará mejoras de seguridad.
5. Uso de MAC en una infraestructura de red distribuida. El enfoque tradicional para configurar el MAC es local, manual, con la ayuda de un administrador de acuerdo con las instrucciones. Existen soluciones que le permiten implementar un almacenamiento MAC administrado centralmente (como ALD), pero tienen sus propias características y dificultades de construcción.

Diseñando una Aplicación MAC

A pesar de todas las limitaciones del modelo, para quienes trabajan con el sector público, y especialmente con las agencias de aplicación de la ley, el tema de crear aplicaciones con soporte para un modelo de control de acceso obligatorio es más relevante que nunca. ¿De repente, mañana tendrás que soportar el MAC en tu producto?

A primera vista, parece que el modelo es primitivo y su implementación es tan simple como cinco centavos, pero hay una advertencia: el cliente que establece el requisito para el uso del modelo de credenciales tiene en mente, en primer lugar, una herramienta de seguridad de la información certificada. La información verdaderamente secreta, hasta los secretos de estado, se procesará en una IP de este tipo, y será muy difícil certificar el desarrollo propio al nivel requerido. La solución a esta situación es utilizar una infraestructura certificada que admita MAC.

Entonces, lo que tenemos en el set:

Ahora, veamos cómo puede usar esta infraestructura al desarrollar una aplicación para preservar las funciones de control de acceso a nivel de infraestructura.

Para que la aplicación aproveche el mecanismo de etiquetado obligatorio del sistema operativo, se deben cumplir las siguientes condiciones:

• Los usuarios de la aplicación deben estar registrados en el repositorio de usuarios del sistema operativo. Como mínimo, debe haber algún identificador que le permita asignar de forma exclusiva el usuario de la aplicación al usuario del sistema operativo (por lo general, este es el inicio de sesión).
• Los usuarios de la aplicación en el nivel del mecanismo MAC del sistema operativo deben configurarse con permisos de credenciales para credenciales específicas (rangos de credenciales).

Desde el punto de vista de la aplicación de escritorio, el escenario del usuario es el siguiente:

1. El usuario ingresa al sistema operativo bajo su ultrasonido personal en el modo de la etiqueta que necesita. Inicia la aplicación. El proceso de solicitud hereda la etiqueta de credencial.
2. La aplicación interactúa con la base de datos en PostgreSQL, mostrando, por ejemplo, solo registros de tablas de bases de datos con la etiqueta de credencial actual.

Desde el punto de vista de la aplicación del servidor que proporciona servicios web, el escenario del usuario es conceptualmente cercano, aunque parece un poco más complicado:

1. El usuario ingresa al sistema operativo bajo su ultrasonido personal en el modo de la etiqueta que necesita. Lanza un navegador con soporte MAC, en nuestro ejemplo, Mozilla Firefox (un navegador "normal" no funcionará para estos fines). El proceso del navegador hereda la credencial.
2. El usuario solicita la dirección de recursos de la aplicación con soporte de credenciales. El navegador forma una solicitud agregando una marca de credencial.
3. La solicitud es procesada por un servidor web con soporte para credenciales, en nuestro ejemplo, Servidor Apache Http. El servidor web (cuyo proceso opera en el modo de credencial mínimo) lee la etiqueta de credencial de la solicitud, encuentra la aplicación del controlador e inicia su proceso con la etiqueta de credencial pasada.
4. La aplicación interactúa con la base de datos PostgreSQL, retransmitiendo la etiqueta de credencial en las consultas.

La presencia de MAC en el sistema operativo impone restricciones bastante serias en la arquitectura de la aplicación. El hecho de que en un sistema operativo sin un modelo de control de acceso de credenciales parezca trivial en un sistema operativo con un MAC puede traer muchas sorpresas a todo el equipo de desarrollo. Especialmente para el gerente del proyecto. Por lo tanto, la arquitectura de una aplicación habilitada para MAC debe construirse antes de que comience el desarrollo. El gerente de proyecto con el MAC debe insistir en que el diseño sea realizado por el equipo de arquitectura antes de cualquier movimiento hacia la implementación.

Por supuesto, para el desarrollo de aplicaciones simples (utilidades o aplicaciones, debido a su especificidad neutral para MAC), muchos consejos simplemente no son útiles. Si la aplicación es algo más complejo que una aplicación local de un solo usuario que lee un archivo y escribe el resultado de su trabajo en un archivo, es recomendable comprender claramente los "escollos".

Hemos compilado recetas para diseñar una aplicación con soporte MAC, formuladas en base a nuestra propia experiencia. Detrás de ellos hay noches de insomnio, un flujo continuo de tickets de pruebas, miles de horas de depuración de una aplicación que, por sentido común, debería funcionar correctamente, pero por alguna razón no funciona así. Las recetas se describen en la forma más simple y neutral para la tecnología y las herramientas, y si es posible están equipadas con esquemas para mejorar la percepción. Vamos!

Cómo evitar un MAC cuando ya no es posible

Al diseñar una aplicación con MAC, puede usar una solución arquitectónica muy simple, que al final le ahorrará muchos nervios y tiempo. Se debe agregar un parámetro a la configuración de la aplicación que le indique si el modelo de control de acceso de credenciales para esta instalación está habilitado o no. En todos los lugares de la aplicación donde tiene lugar la interacción con la infraestructura MAC, o la función comercial de la aplicación requiere la verificación de la etiqueta, primero debe verificar el valor de este parámetro. Si el MAC está deshabilitado de acuerdo con él, la aplicación ignora todas las reglas de lógica de negocios diseñadas para probar funciones compatibles con MAC.

En términos de costos laborales, tendrá que dedicar más tiempo a la implementación de cada función de la aplicación con soporte MAC. Deberá depurar y probar la misma funcionalidad en el modo sin una etiqueta de credencial, por lo que el costo de la prueba aumentará.

Debido a esta solución, es posible proporcionar a la aplicación (y a todo el equipo de desarrollo), que se ve obligada a funcionar en el entorno MAC, las siguientes ventajas:

• Aplicación multiplataforma (limitada solo por las capacidades de los lenguajes de programación) y su independencia del tiempo de ejecución.
• La capacidad de usar herramientas de virtualización modernas (por ejemplo, Docker) para la automatización.
• Facilidad de pruebas y características de depuración que no están directamente relacionadas con el MAC.

Recomendaciones :

Agregue la opción para habilitar / deshabilitar la compatibilidad con credenciales en la aplicación.

En todos los lugares que requieren interacción con el MAC, en primer lugar, verifique el valor del parámetro.

Al depurar y probar, es necesario depurar (del lado del equipo de desarrollo) y probar (del lado del equipo de prueba) ambos modos de la aplicación.

Divide y vencerás

Otro paso de diseño importante que debe completarse antes del inicio del desarrollo es la separación de los módulos en los que se requiere soporte MAC de los módulos en los que no se requiere este mecanismo de control de acceso. El uso de un modelo de control de acceso de credenciales casi siempre complica la lógica empresarial de una aplicación.

Esta es la misma infraestructura, abstraerse de lo cual es muy difícil y, a veces, imposible. Por lo tanto, la aplicación debe dividirse en módulos y, para cada módulo, analizar la necesidad de compatibilidad con MAC. ¿Quizás es en su caso que es suficiente para admitir el MAC en un solo módulo, y no tiene sentido que este módulo complique toda la aplicación?
Si estamos considerando cierto módulo abstracto (o la aplicación completa, si no se requiere la división de la aplicación en módulos), son posibles los siguientes paradigmas:

• La etiqueta mínima. El módulo procesa datos en el modo de etiqueta obligatoria mínima (la etiqueta mínima en la que operan los procesos del sistema operativo, por ejemplo, 0 etiqueta obligatoria) o sin una etiqueta obligatoria.
• Una etiqueta El módulo funciona con los datos de una sola etiqueta obligatoria por encima de la etiqueta obligatoria mínima (cualquier etiqueta que no sea aquella en la que operan los procesos del sistema operativo).
• Varias etiquetas El módulo funciona con los datos de varias etiquetas obligatorias a la vez (tanto la etiqueta en la que operan los procesos del sistema operativo como otras etiquetas que no sean la etiqueta del proceso del sistema operativo).

Los módulos de aplicación con diferentes paradigmas de procesamiento de credenciales no deberían saber demasiado el uno del otro. De lo contrario, está plagado de la aparición de problemas grandes e impredecibles con respecto a los conflictos de acceso a varios objetos, etc. La idea de una conectividad mínima para los módulos es obvia. En el caso de trabajar con MAC, debe estar especialmente atento y controlar todas las "conexiones" de los módulos.
A continuación, consideramos con más detalle las características de diseño con tres paradigmas para el procesamiento de credenciales. Para hacer esto, esbozamos la clasificación de simple a compleja. Esta clasificación es puramente práctica y aplicada. Procede de diferencias intuitivamente tangibles en el desarrollo de varios módulos, y en la práctica ha demostrado su eficacia.

Clasificación de módulos por modos de procesamiento MAC

"LLEVARLO": funcionamiento del módulo en modo de credencial mínima

Motivación para implementar este mecanismo en el módulo:

• El módulo procesa información que, en principio, no puede procesarse en el sistema con otras credenciales, y no requiere privilegios especiales de lectura / escritura.
• El módulo está estrechamente conectado con la infraestructura del sistema operativo, lo que limita su funcionamiento en el modo de etiqueta obligatoria, que es diferente del mínimo.

El módulo que funciona en este modo debe verificar la credencial del proceso. Si la etiqueta del proceso en el que se ejecuta este módulo es diferente del mínimo (por ejemplo, no es igual a la etiqueta obligatoria 0), todas las operaciones (excepto la visualización) deberían estar prohibidas en el nivel de lógica de negocios de la aplicación. Es decir, simplemente no podemos permitir que el usuario use este módulo si vino a nosotros en una sesión de una etiqueta de credencial que no sea cero.

Ejemplos de casos prácticos para los que es adecuado el uso del modo de etiqueta obligatoria mínima:

• Gestionar cuentas de usuario en la tienda de aplicaciones. Por ejemplo, si la aplicación mantiene su propio registro de ultrasonido en un archivo o base de datos. Todos los datos relacionados con la seguridad y el control de acceso de la aplicación deben almacenarse en el modo de credencial mínima, de lo contrario, el modelo de seguridad de la aplicación simplemente se "desmoronará" cuando la aplicación se ejecute en el modo de credencial aumentada. Por esta razón, todas las aplicaciones del sistema se ejecutan estrictamente bajo la credencial mínima.
• Gestión de derechos de acceso. Por ejemplo, si la aplicación implementa su propio modelo de control de acceso a nivel de lógica empresarial.
• Administre los ajustes de configuración de la aplicación que deberían estar disponibles con todas las credenciales.
• Gestión de cuentas en SO. Si la aplicación necesita administrar cualquier atributo del KM en el sistema operativo, todas las operaciones deben realizarse estrictamente bajo la marca de credencial mínima.

"HURT ME PLENTY": operación del módulo en modo de credencial única

Este caso es un poco más complicado, pero en muchos aspectos similar al caso con una marca de credencial mínima. Desde el punto de vista del usuario, trabajar con la aplicación no cambia mucho: las mismas listas familiares de registros, tarjetas y operaciones "Ver", "Editar" y "Guardar". La única diferencia es que en este modo el usuario solo ve aquellos registros que corresponden a la marca de credencial de su sesión actual.

También se puede desarrollar una opción limitada: el módulo captura el valor del parámetro "etiqueta de credencial predeterminada". En este caso, la operación del módulo solo es posible con la etiqueta de credencial especificada, pero esta opción es más fácil de implementar.

Este caso puede ser útil en los siguientes casos:

• Hubo un error en la arquitectura al diseñar el módulo (no se establecieron las características de procesamiento de registros en el MAC), y no hay tiempo ni recursos para reescribir todo.
• El soporte para el modelo de control de acceso de credenciales se introduce en una aplicación que ya funciona y, de acuerdo con los requisitos, es necesario garantizar el trabajo con una etiqueta superior al mínimo en el sistema operativo. ¡Sí, este es el caso cuando el jefe viene a usted y le informa con gusto que ganamos el concurso e implementaremos nuestra decisión en el "nombre del departamento secreto" !
• . .
• .

C , :

• , , – , .
• - . , , .

. , .

, :

• . , ( , ..). , . .
• . , , ( ) . «» , « », «» .

«NIGHTMARE!»:

, , .

, ( « »). - . .

:

• (, ) ( ). , .
• / / , .
• / ( ).

- - . , . .

, . - -. , . , , ..

:

• ( ).
• ( ) ( ).
• / .

, :

1. . , .
2. . , .

MAC . :

• Sistema operativo:
  
  • :
    
    • ;
    • ( , ) .
  • ;
  • ( );
  • ( POSIX ACL, UNIX ..);
  • ;
  • ;
  • ;
• MAC;
• MAC:
  
  • (, PostgreSQL):
    
    • (, , , , , , , , ..).
• .

.

MAC-

MAC «» . , MAC , , ( ).

MAC?

, , . . . , , .

:

MAC- MAC

, MAC, MAC.

. «» , . , , . «» MAC , .

MAC , MAC, , , .

MAC- MAC

MAC , , . , , / .

— PostgresSQL. MAC MAC, :

• Astra Linux: PostgreSQL, SE.
• SELinux: sepgsql.

PostgreSQL ( , ) :

• .
• .
• .
• .
• .
• .

MAC «»: «» «» . MAC . .

MAC-

, . MAC, ?

MAC MAC , .

- :

Conclusiones

MAC. , , . , .

MAC — «» . , . «» MAC- :

• ( , , );
• MAC (, );
• MAC- .

Eso es todo por ahora! ¡Adiciones, experiencia personal y comentarios sobre el artículo son bienvenidos!