Hispanopedia Wiki
Articulo de referencia

Control de acceso obligatorio

En seguridad informática , el control de acceso obligatorio ( MAC ) se refiere a un tipo de control de acceso mediante el cual un entorno seguro (por ejemplo, un sistema operati...

Hispanopedia WikiContenido en espanolLectura gratuita

En seguridad informática , el control de acceso obligatorio ( MAC ) se refiere a un tipo de control de acceso mediante el cual un entorno seguro (por ejemplo, un sistema operativo o una base de datos) restringe la capacidad de un sujeto o iniciador para acceder o modificar un objeto o destino . [ 1 ] En el caso de los sistemas operativos, el sujeto es un proceso o hilo, mientras que los objetos son archivos, directorios, puertos TCP / UDP , segmentos de memoria compartida o dispositivos de E/S. Tanto los sujetos como los objetos tienen un conjunto de atributos de seguridad. Siempre que un sujeto intenta acceder a un objeto, el núcleo del sistema operativo examina estos atributos de seguridad, examina las reglas de autorización (también conocidas como políticas ) establecidas y decide si concede el acceso. Un sistema de gestión de bases de datos , en su mecanismo de control de acceso, también puede aplicar el control de acceso obligatorio; en este caso, los objetos son tablas, vistas, procedimientos, etc.

En el control de acceso obligatorio, la política de seguridad es controlada centralmente por un administrador de políticas y se garantiza (en principio) su aplicación a todos los usuarios. Los usuarios no pueden eludir la política ni, por ejemplo, otorgar acceso a archivos que de otro modo estarían restringidos. Por el contrario, el control de acceso discrecional (CAD), que también regula la capacidad de los sujetos para acceder a los objetos, permite a los usuarios tomar decisiones sobre la política o asignar atributos de seguridad.

Históricamente, MAC se ha asociado estrechamente con la seguridad multinivel (MLS) y los sistemas militares especializados. En este contexto, MAC implica un alto grado de rigor para cumplir con las restricciones de los sistemas MLS. Sin embargo, más recientemente, MAC se ha desvinculado del ámbito MLS y ha comenzado a generalizarse. Las implementaciones más recientes de MAC, como SELinux y AppArmor para Linux y el Control de Integridad Obligatorio para Windows, permiten a los administradores centrarse en problemas como los ataques a la red y el malware sin el rigor ni las restricciones de MLS.

Historia y antecedentes

Históricamente, MAC estuvo fuertemente asociado con la seguridad multinivel (MLS) como un medio para proteger la información clasificada de los Estados Unidos . Los Criterios de Evaluación de Sistemas Informáticos Confiables (TCSEC), el trabajo seminal sobre el tema y a menudo conocido como el Libro Naranja, proporcionó la definición original de MAC como "un medio para restringir el acceso a objetos basado en la sensibilidad (como se representa por una etiqueta) de la información contenida en los objetos y la autorización formal (es decir, autorización) de sujetos para acceder a información de dicha sensibilidad". [ 2 ] Las primeras implementaciones de MAC como SCOMP de Honeywell , SACDIN de la USAF , Blacker de la NSA y MLS LAN de Boeing [ 3 ] [ 4 ] se centraron en MLS para proteger los niveles de clasificación de seguridad orientados a lo militar con una aplicación sólida.

El término «obligatorio» en MAC ha adquirido un significado especial derivado de su uso en sistemas militares. En este contexto, MAC implica un grado de robustez extremadamente alto que garantiza que los mecanismos de control puedan resistir cualquier tipo de subversión, lo que les permite aplicar los controles de acceso exigidos por orden gubernamental, como la Orden Ejecutiva 12958. Se supone que la aplicación es más imperativa que en aplicaciones comerciales. Esto excluye la aplicación mediante mecanismos de mejor esfuerzo. Solo son aceptables para MAC los mecanismos que pueden proporcionar una aplicación absoluta o casi absoluta del mandato. Esto es un reto considerable y, a veces, lo consideran poco realista quienes no están familiarizados con las estrategias de alta seguridad, y muy difícil incluso para quienes sí lo están.

En algunos sistemas, los usuarios tienen la autoridad para decidir si otorgan acceso a cualquier otro usuario. Para permitir esto, todos los usuarios tienen autorizaciones para todos los datos. Esto no es necesariamente cierto en un sistema MLS. Si existen individuos o procesos a los que se les puede negar el acceso a cualquiera de los datos en el entorno del sistema, entonces se debe confiar en que el sistema aplique MAC. Dado que puede haber varios niveles de clasificación de datos y autorizaciones de usuario, esto implica una escala cuantificada para la robustez. Por ejemplo, se indica mayor robustez para entornos de sistema que contienen información clasificada "Alto Secreto" y usuarios sin autorización que para uno con información "Secreto" y usuarios autorizados al menos a "Confidencial". Para promover la coherencia y eliminar la subjetividad en los grados de robustez, un extenso análisis científico y una evaluación de riesgos del tema produjeron una estandarización de referencia histórica que cuantifica las capacidades de robustez de seguridad de los sistemas y las asigna a los grados de confianza justificados para varios entornos de seguridad. El resultado se documentó en CSC-STD-004-85. [ 5 ] Se definieron dos componentes relativamente independientes de robustez: Nivel de garantía y funcionalidad . Ambos aspectos se especificaron con un grado de precisión que justificaba una confianza significativa en las certificaciones basadas en estos criterios.

El estándar Common Criteria [ 6 ] se basa en esta ciencia y pretendía preservar el nivel de garantía como niveles EAL y las especificaciones de funcionalidad como perfiles de protección . De estos dos componentes esenciales de los puntos de referencia de robustez objetiva, solo los niveles EAL se conservaron fielmente. En un caso, el nivel C2 de TCSEC [ 7 ] (una categoría no compatible con MAC) se conservó bastante fielmente en Common Criteria, como el Perfil de Protección de Acceso Controlado (CAPP). [ 8 ] Los perfiles de protección MLS (como MLSOSPP, similar a B2) [ 9 ] son ​​más generales que B2. Se ajustan a MLS, pero carecen de los requisitos de implementación detallados de sus predecesores del Libro Naranja , centrándose más en los objetivos. Esto otorga a los certificadores mayor flexibilidad subjetiva para decidir si las características técnicas del producto evaluado cumplen adecuadamente el objetivo, lo que podría erosionar la consistencia de los productos evaluados y facilitar la obtención de la certificación para productos menos fiables. Por estas razones, la importancia de los detalles técnicos del Perfil de Protección es fundamental para determinar la idoneidad de un producto.

Esta arquitectura impide que un usuario o proceso autenticado, con un nivel de clasificación o confianza específico, acceda a información, procesos o dispositivos de un nivel diferente. Esto proporciona un mecanismo de contención para usuarios y procesos, tanto conocidos como desconocidos. Un programa desconocido podría ser una aplicación no confiable, cuyo acceso a dispositivos y archivos el sistema debe supervisar o controlar.

Algunas implementaciones de MAC, como el proyecto Blacker de Unisys , fueron certificadas con la suficiente solidez como para separar la información clasificada como Alto Secreto de la no clasificada a finales del siglo pasado. Sin embargo, su tecnología subyacente quedó obsoleta y no se actualizaron. Actualmente, no existen implementaciones certificadas por TCSEC con ese nivel de solidez. No obstante, existen algunos productos menos robustos.

En los sistemas operativos

Microsoft

A partir de Windows Vista y Server 2008 , Microsoft incorporó el Control de Integridad Obligatorio (MIC) en el sistema operativo Windows, que agrega niveles de integridad (IL) a los procesos en ejecución. El objetivo es restringir el acceso de procesos menos confiables a información confidencial. MIC define cuatro niveles de integridad: Bajo, medio, alto y sistema. [ 10 ] Por defecto, los procesos se inician con IL medio. Los procesos elevados reciben IL alto. [ 11 ] Los procesos secundarios, por defecto, heredan la integridad de su proceso padre, aunque el proceso padre puede iniciarlos con un IL inferior. Por ejemplo, Internet Explorer 7 inicia sus subprocesos con IL bajo. Windows controla el acceso a los objetos en función de los IL. Los objetos con nombre , incluidos archivos , claves de registro u otros procesos e hilos , tienen una entrada en su ACL que indica el IL mínimo del proceso que puede usar el objeto. MIC garantiza que un proceso solo puede escribir o eliminar un objeto cuando su IL es igual o superior al IL del objeto. Además, para evitar el acceso a datos sensibles en la memoria, los procesos no pueden abrir procesos con un IL más alto para acceso de lectura . [ 12 ]

Manzana

Apple Inc. ha incorporado una implementación del marco TrustedBSD en sus sistemas operativos iOS y macOS . [ 13 ] (La palabra "mac" en "macOS" es la abreviatura de " Macintosh " y no tiene nada que ver con la abreviatura de "control de acceso obligatorio"). La función de línea de comandos sandbox_initproporciona una interfaz de sandboxing de alto nivel limitada. [ 14 ]

Google

La versión 5.0 y posteriores del sistema operativo Android , desarrollado por Google , utilizan SELinux (como SEAndroid) para aplicar un modelo de seguridad MAC sobre su enfoque DAC original basado en UID. [ 15 ]

Familia Linux

Linux y muchas otras distribuciones Unix cuentan con MAC para CPU (multianillo), disco y memoria. Si bien el software del sistema operativo puede no gestionar bien los privilegios, Linux se hizo famoso durante la década de 1990 por ser más seguro y mucho más estable que las alternativas que no son Unix. Los tres principales módulos de seguridad de Linux que implementan MAC son SELinux , AppArmor y TOMOYO Linux . [ 16 ]

Security-Enhanced Linux (SELinux) fue desarrollado originalmente por la NSA y lanzado a la comunidad de código abierto en 2000. [ 17 ] Es una de las primeras implementaciones de MAC para Linux y también una de las más populares. [ 18 ] Se ha incorporado a los núcleos de Linux desde la versión 2.4 y está habilitado por defecto en Android 5.0+, Red Hat Enterprise Linux / Fedora Linux y SUSE Linux Enterprise / openSUSE . [ 19 ] SELinux proporciona un control potente y granular, lo que lo hace adecuado para entornos de alta seguridad, pero muchos usuarios encuentran que su potencia y granularidad vienen con un alto grado de complejidad y una curva de aprendizaje pronunciada. [ 16 ]

TOMOYO Linux es una implementación MAC ligera para Linux y Linux embebido , desarrollada por NTT Data Corporation . Se fusionó en la versión principal del kernel de Linux 2.6.30 en junio de 2009. [ 20 ] A diferencia del enfoque basado en etiquetas utilizado por SELinux , TOMOYO Linux realiza un Control de Acceso Obligatorio basado en nombres de ruta , separando los dominios de seguridad según el historial de invocación de procesos, que describe el comportamiento del sistema. Las políticas se describen en términos de nombres de ruta. Un dominio de seguridad se define simplemente por una cadena de llamadas de procesos y se representa mediante una cadena. Hay 4 modos: deshabilitado, aprendizaje , permisivo, aplicación. Los administradores pueden asignar diferentes modos para diferentes dominios. TOMOYO Linux introdujo el modo "aprendizaje", en el que los accesos ocurridos en el kernel se analizan y almacenan automáticamente para generar la política MAC: este modo podría ser el primer paso para escribir políticas, lo que facilita su personalización posterior.

AppArmor es una implementación MAC que utiliza la interfaz de Módulos de Seguridad de Linux (LSM) de Linux 2.6 y está incorporada en SUSE Linux y Ubuntu 7.10. LSM proporciona una API del kernel que permite que los módulos de código del kernel gestionen las ACL (DAC ACL, listas de control de acceso). AppArmor no es capaz de restringir todos los programas y es opcional en el kernel de Linux desde la versión 2.6.36. [ 21 ] SUSE migró a SELinux para nuevas instalaciones desde 2025, Ubuntu usa AppArmor por defecto, junto con Debian y Solus . [ 19 ] [ 22 ] [ 23 ]

RSBAC (Control de Acceso Basado en Conjuntos de Reglas) de Amon Ott proporciona un marco para los núcleos de Linux que permite varios módulos de política/decisión de seguridad diferentes. Uno de los modelos implementados es el modelo de Control de Acceso Obligatorio. Un objetivo general del diseño de RSBAC era intentar alcanzar el nivel B1 (obsoleto) del Libro Naranja (TCSEC). El modelo de control de acceso obligatorio utilizado en RSBAC es prácticamente el mismo que en Unix System V/MLS, versión 1.2.1 (desarrollado en 1989 por el Centro Nacional de Seguridad Informática de EE. UU. con clasificación B1/TCSEC). RSBAC requiere un conjunto de parches para el núcleo estándar, que son mantenidos bastante bien por el propietario del proyecto .

Smack (Simplified Mandatory Access Control Kernel) es un módulo de seguridad del kernel de Linux que protege la interacción de datos y procesos contra manipulaciones maliciosas mediante un conjunto de reglas de control de acceso obligatorio personalizadas, con la simplicidad como su principal objetivo de diseño. [ 24 ] Se integró oficialmente desde la versión Linux 2.6.25. [ 25 ]

grsecurityes un parche para el kernel de Linux que proporciona una implementación MAC (precisamente, es una implementación RBAC ). grsecurityno está implementado a través de la API LSM . [ 26 ]

El sistema operativo Astra Linux , desarrollado para el ejército ruso, tiene su propio control de acceso obligatorio. [ 27 ]

Otros sistemas operativos

FreeBSD admite el Control de Acceso Obligatorio (MAC ), implementado como parte del proyecto TrustedBSD. Se introdujo en FreeBSD 5.0. Desde FreeBSD 7.2, el soporte para MAC está habilitado por defecto. El marco es extensible; varios módulos MAC implementan políticas como Biba y seguridad multinivel .

Sun Trusted Solaris utiliza un mecanismo de control de acceso (MAC) obligatorio y aplicado por el sistema, donde se utilizan autorizaciones y etiquetas para aplicar una política de seguridad. Sin embargo, cabe señalar que la capacidad de gestionar etiquetas no implica que el kernel tenga la capacidad de operar en modo de seguridad multinivel . El acceso a las etiquetas y a los mecanismos de control no está protegido de forma robusta contra la corrupción en el dominio protegido mantenido por el kernel. Las aplicaciones que ejecuta un usuario se asocian con la etiqueta de seguridad con la que trabaja en la sesión. El acceso a la información, los programas y los dispositivos está controlado de forma débil .

Véase también

Control de acceso

Otros temas

Notas a pie de página

  1. ↑ Belim, SV; Belim, S. Yu. (diciembre de 2018). "Implementación del control de acceso obligatorio en sistemas distribuidos" . Automatic Control and Computer Sciences . 52 (8): 1124– 1126. doi : 10.3103/S0146411618080357 . ISSN 0146-4116 . S2CID 73725128 .  
  2. ↑ "Criterios de evaluación de computadoras confiables" (PDF) . Instituto Nacional de Estándares y Tecnología . 15 de agosto de 1983. Archivado (PDF) del original el 13 de abril de 2023. Recuperado el 25 de junio de 2023 .
  3. ↑ Boletín de evaluación de productos: Boeing MLS LAN (PDF) (Informe). Centro Nacional de Seguridad Informática (NCSC). 14 de septiembre de 1988. Informe n.° CSC-PB-003-88. Identifica al Servidor de Red Segura (SNS) como candidato para la calificación A1-MI, aplicando MAC con 8 niveles jerárquicos y 256 categorías.Véase también el folleto del producto (1988) .
  4. ↑ Stover, Philip C. (febrero de 1987). "Diseño de redes seguras multinivel" . Estrategias tecnológicas ISEC del Ejército de EE. UU. '87 . Alexandria, VA: Boeing Aerospace Company.
  5. ↑ "Fundamentos técnicos de la norma CSC-STD-003-85: Requisitos de seguridad informática" . 25 de junio de 1985. Archivado del original el 15 de julio de 2007. Consultado el 15 de marzo de 2008 .
  6. ↑ "El portal de Criterios Comunes" . Archivado del original el 18 de julio de 2006. Consultado el 15 de marzo de 2008 .
  7. ↑ Departamento de Defensa de EE. UU. (diciembre de 1985). "DoD 5200.28-STD: Criterios de evaluación de sistemas informáticos confiables" . Consultado el 15 de marzo de 2008 .
  8. ↑ "Perfil de protección de acceso controlado, versión 1.d" . Agencia de Seguridad Nacional. 8 de octubre de 1999. Archivado del original el 7 de febrero de 2012. Consultado el 15 de marzo de 2008 .
  9. ↑ "Perfil de protección para sistemas operativos multinivel en entornos que requieren robustez media, versión 1.22" (PDF) . Agencia de Seguridad Nacional. 23 de mayo de 2001. Consultado el 6 de octubre de 2018 .
  10. ↑ Microsoft. "Mecanismo de control de integridad obligatorio" . Consultado el 29 de noviembre de 2025 .
  11. ↑ Steve Riley. "Control de integridad obligatorio en Windows Vista" . Consultado el 8 de octubre de 2007 .
  12. ↑ Mark Russinovich . "PsExec, control de cuentas de usuario y límites de seguridad" . Consultado el 8 de octubre de 2007 .
  13. ↑ Proyecto TrustedBSD. "Marco de control de acceso obligatorio (MAC) de TrustedBSD" . Consultado el 15 de marzo de 2008 .
  14. ↑ "página man sandbox_init(3)" . 07/07/2007. Archivado del original el 25/07/2008 . Consultado el 15/03/2008 .
  15. ↑ "Security-Enhanced Linux in Android" . Proyecto de código abierto de Android. Archivado del original el 19 de junio de 2023. Consultado el 25 de junio de 2023 .
  16. 1 2 "Descripción general de los módulos de seguridad de Linux: comparación de SELinux, AppArmor y TOMOYO" . 24 de septiembre de 2024. Consultado el 5 de mayo de 2025 .
  17. ↑ "La Agencia de Seguridad Nacional comparte mejoras de seguridad para Linux" . Comunicado de prensa de la NSA . Fort George G. Meade, Maryland: Servicio Central de Seguridad de la Agencia de Seguridad Nacional. 2 de enero de 2001. Archivado del original el 18 de septiembre de 2018. Consultado el 5 de mayo de 2025 .
  18. ↑ "Introducción a SELinux" . 5 de julio de 2023. Consultado el 5 de mayo de 2025 .
  19. 1 2 Gompa, Neal (13 de febrero de 2025). "Re: Anuncio: SELinux como sistema MAC predeterminado en nuevas instalaciones de Tumbleweed - openSUSE Factory" . Listas de correo de openSUSE . Archivado del original el 18 de febrero de 2025. Recuperado el 14 de febrero de 2025 .
  20. ↑ "TOMOYO Linux, un control de acceso obligatorio alternativo" . Linux 2 6 30. Linux Kernel Newbies.
  21. ↑ "Linux 2.6.36 lanzado el 20 de octubre de 2010" . Linux 2.6.36 . Linux Kernel Newbies.
  22. ↑ "Se lanza la distribución Linux Solus 3 para entusiastas" . Phoronix . Consultado el 23 de enero de 2026 .
  23. ↑ "NewInBuster" . Wiki de Debian . Consultado el 23 de enero de 2026 .
  24. ↑ "Documentación oficial de SMACK del código fuente de Linux" . Archivado del original el 1 de mayo de 2013.
  25. ↑ Jonathan Corbet. "Más cosas para el 2.6.25" . Archivado del original el 2 de noviembre de 2012.
  26. ↑ "¿Por qué grsecurity no utiliza LSM?" .
  27. ^ (en ruso) Ключевые особенности Astra Linux Special Edition по реализации требований безопасности информации Archivado el 16 de julio de 2014 en Wayback Machine .

Referencias

  • PA Loscocco, SD Smalley, PA Muckelbauer, RC Taylor, SJ Turner y JF Farrell. La inevitabilidad del fallo: la errónea suposición de seguridad en los entornos informáticos modernos . En Actas de la 21.ª Conferencia Nacional sobre Seguridad de los Sistemas de Información, páginas 303-314, octubre de 1998.
  • PA Loscocco, SD Smalley, Cumplimiento de objetivos de seguridad críticos con Linux con seguridad mejorada. Archivado el 8 de julio de 2017 en Wayback Machine. Actas del Simposio Linux de Ottawa de 2001.
  • ISO/IEC DIS 10181-3, Tecnología de la Información, Modelo de Seguridad OSI, Marcos de Seguridad, Parte 3: Control de Acceso, 1993
  • Robert NM Watson. " Una década de extensibilidad del control de acceso de los sistemas operativos ". Commun. ACM 56, 2 (febrero de 2013), 52–63.
  • Entrada de blog sobre cómo se puede utilizar la virtualización para implementar el control de acceso obligatorio.
  • Entrada de blog de un empleado de Microsoft que detalla el Control de Integridad Obligatorio y en qué se diferencia de las implementaciones MAC.
  • Modelo de política de seguridad formal GWV: una política de seguridad formal con núcleo de separación, David Greve, Matthew Wilding y W. Mark Vanfleet.