Articulo de referencia

Control de acceso informático

En seguridad informática , el control de acceso general incluye identificación , autorización , autenticación , aprobación de acceso y auditoría . Una definición más específica ...

En seguridad informática , el control de acceso general incluye identificación , autorización , autenticación , aprobación de acceso y auditoría . Una definición más específica de control de acceso abarcaría únicamente la aprobación de acceso, mediante la cual el sistema decide si concede o rechaza una solicitud de acceso de un usuario ya autenticado, en función de los recursos a los que está autorizado a acceder. La autenticación y el control de acceso suelen combinarse en una sola operación, de modo que el acceso se aprueba tras una autenticación exitosa o mediante un token de acceso anónimo. Los métodos y tokens de autenticación incluyen contraseñas , escaneos biométricos, claves físicas , claves y dispositivos electrónicos , rutas ocultas, barreras sociales y monitorización por parte de personas y sistemas automatizados.

Entidades de software

En cualquier modelo de control de acceso , las entidades que pueden realizar acciones en el sistema se denominan sujetos , y las entidades que representan recursos cuyo acceso puede requerir control se denominan objetos (véase también la Matriz de Control de Acceso ). Tanto los sujetos como los objetos deben considerarse entidades de software, y no usuarios humanos: los usuarios humanos solo pueden influir en el sistema a través de las entidades de software que controlan.

Aunque algunos sistemas equiparan a los sujetos con los ID de usuario , de modo que todos los procesos iniciados por un usuario tienen por defecto la misma autoridad, este nivel de control no es lo suficientemente preciso como para satisfacer el principio de mínimo privilegio y, posiblemente, sea responsable de la prevalencia del malware en dichos sistemas (véase inseguridad informática ).

En algunos modelos, como por ejemplo el modelo de capacidad de objeto , cualquier entidad de software puede actuar potencialmente como sujeto y como objeto.

En 2014, los modelos de control de acceso tendían a dividirse en dos clases: los basados ​​en capacidades y los basados ​​en listas de control de acceso (ACL).

  • En un modelo basado en capacidades, poseer una referencia o capacidad infalsificable a un objeto proporciona acceso a dicho objeto (de forma similar a como la posesión de la llave de la casa otorga acceso a la misma); el acceso se transmite a otra parte mediante la transmisión de dicha capacidad a través de un canal seguro.
  • En un modelo basado en ACL, el acceso de un sujeto a un objeto o grupo de objetos [ 1 ] depende de si su identidad aparece en una lista asociada al objeto (de forma similar a como un portero de una fiesta privada comprobaría la identificación de un invitado para ver si su nombre figura en la lista); el acceso se otorga mediante la edición de la lista. (Los distintos sistemas ACL tienen diversas convenciones respecto a quién o qué es responsable de editar la lista y cómo se edita).

Tanto los modelos basados ​​en capacidades como los basados ​​en ACL cuentan con mecanismos que permiten otorgar derechos de acceso a todos los miembros de un grupo de sujetos (a menudo, el grupo se modela como un sujeto).

Servicios

Los sistemas de control de acceso proporcionan los servicios esenciales de autorización , identificación y autenticación ( I&A ), aprobación de acceso y rendición de cuentas, donde:

  • La autorización especifica lo que un sujeto puede hacer.
  • La identificación y la autenticación garantizan que solo los sujetos legítimos puedan iniciar sesión en un sistema.
  • La aprobación de acceso otorga acceso durante las operaciones, mediante la asociación de usuarios con los recursos a los que tienen permitido acceder, según la política de autorización.
  • La rendición de cuentas identifica lo que hizo un sujeto (o todos los sujetos asociados a un usuario).

Autorización

La autorización implica definir los derechos de acceso de los usuarios. Una política de autorización especifica las operaciones que los usuarios pueden ejecutar dentro de un sistema.

La mayoría de los sistemas operativos modernos implementan políticas de autorización como conjuntos formales de permisos que son variaciones o extensiones de tres tipos básicos de acceso:

  • Leer (R): El sujeto puede:
    • Leer el contenido del archivo
    • Listar el contenido del directorio
  • Escritura (W): El sujeto puede cambiar el contenido de un archivo o directorio con las siguientes tareas:
    • Agregar
    • Actualizar
    • Borrar
    • Rebautizar
  • Ejecutar (X): Si el archivo es un programa, el usuario puede hacer que se ejecute. (En sistemas tipo Unix, el permiso "ejecutar" también funciona como permiso para "recorrer directorios" cuando se concede para un directorio).

Estos derechos y permisos se implementan de manera diferente en los sistemas basados ​​en el control de acceso discrecional ( DAC ) y el control de acceso obligatorio ( MAC ).

Identificación y autenticación

La identificación y autenticación (I&A) es el proceso de verificar que una identidad está vinculada a la entidad que realiza la afirmación o reclamación de identidad. El proceso de I&A presupone que se realizó una validación inicial de la identidad, comúnmente denominada comprobación de identidad. Existen diversos métodos de comprobación de identidad, desde la validación presencial mediante una identificación oficial hasta métodos anónimos que permiten al solicitante permanecer anónimo, pero que el sistema lo reconoce si regresa. El método utilizado para la comprobación y validación de identidad debe proporcionar un nivel de seguridad acorde con el uso previsto de la identidad dentro del sistema. Posteriormente, la entidad afirma su identidad junto con un autenticador como medio de validación. El único requisito para el identificador es que debe ser único dentro de su dominio de seguridad.

Los autenticadores suelen basarse en al menos uno de los siguientes cuatro factores:

  • Algo que usted conoce , como una contraseña o un número de identificación personal (PIN). Esto supone que solo el titular de la cuenta conoce la contraseña o el PIN necesarios para acceder a ella.
  • Algo que usted posee , como una tarjeta inteligente o un token de seguridad . Esto supone que solo el titular de la cuenta tiene la tarjeta inteligente o el token necesarios para desbloquearla.
  • Algo que eres , como por ejemplo tus huellas dactilares, tu voz, tu retina o las características de tu iris.
  • Su ubicación , por ejemplo, dentro o fuera del cortafuegos de la empresa, o la proximidad de la ubicación de inicio de sesión a un dispositivo GPS personal.

Aprobación de acceso

La aprobación de acceso es la función que realmente otorga o rechaza el acceso durante las operaciones. [ 2 ]

Durante la aprobación del acceso, el sistema compara la representación formal de la política de autorización con la solicitud de acceso para determinar si se concede o se rechaza. Además, la evaluación del acceso puede realizarse en línea y de forma continua. [ 3 ]

Responsabilidad

La rendición de cuentas utiliza componentes del sistema como registros de auditoría (registros) y bitácoras para asociar a un sujeto con sus acciones. La información registrada debe ser suficiente para vincular al sujeto con un usuario controlador. Los registros de auditoría y las bitácoras son importantes para

  • Detección de violaciones de seguridad
  • Recrear incidentes de seguridad

Si nadie revisa sus registros periódicamente y estos no se mantienen de forma segura y coherente, es posible que no sean admisibles como prueba.

Muchos sistemas pueden generar informes automatizados, basados ​​en ciertos criterios o umbrales predefinidos, conocidos como niveles de recorte . Por ejemplo, se puede configurar un nivel de recorte para generar un informe para lo siguiente:

  • Más de tres intentos fallidos de inicio de sesión en un período determinado
  • Cualquier intento de utilizar una cuenta de usuario deshabilitada

Estos informes ayudan a un administrador de sistemas o de seguridad a identificar más fácilmente posibles intentos de intrusión. – Definición de nivel de recorte: [ 4 ] capacidad de un disco para mantener sus propiedades magnéticas y conservar su contenido. Un rango de nivel de alta calidad es del 65 al 70 %; la baja calidad es inferior al 55 %.

Controles de acceso

Los modelos de control de acceso se clasifican a veces en discrecionales o no discrecionales. Los tres modelos más reconocidos son el Control de Acceso Discrecional (DAC), el Control de Acceso Obligatorio (MAC) y el Control de Acceso Basado en Roles (RBAC). El MAC es no discrecional.

Control de acceso discrecional

El control de acceso discrecional (DAC) es una política determinada por el propietario de un objeto. El propietario decide quién tiene permiso para acceder al objeto y qué privilegios tiene.

Dos conceptos importantes en DAC son:

  • Propiedad de archivos y datos: Cada objeto del sistema tiene un propietario . En la mayoría de los sistemas DAC, el propietario inicial de cada objeto es el sujeto que lo creó. La política de acceso a un objeto la determina su propietario.
  • Derechos y permisos de acceso: Se trata de los controles que un propietario puede asignar a otros usuarios para acceder a recursos específicos.

Los controles de acceso pueden ser discrecionales en los sistemas de control de acceso basados ​​en listas de control de acceso (ACL) o en capacidades . (En los sistemas basados ​​en capacidades, normalmente no existe un concepto explícito de "propietario", pero el creador de un objeto tiene un grado similar de control sobre su política de acceso).

Control de acceso obligatorio

El control de acceso obligatorio se refiere a permitir el acceso a un recurso solo si existen reglas que autorizan a un usuario determinado a acceder a él. Su gestión es compleja, pero su uso suele estar justificado para proteger información altamente sensible. Algunos ejemplos incluyen información gubernamental y militar. La gestión se simplifica (en cuanto a los requisitos) si la información se puede proteger mediante un control de acceso jerárquico o implementando etiquetas de confidencialidad. El uso de reglas o etiquetas de confidencialidad es lo que hace que este método sea obligatorio.

  • Etiquetas de sensibilidad: En un sistema de este tipo, los sujetos y objetos deben tener etiquetas asignadas. La etiqueta de sensibilidad de un sujeto especifica su nivel de confianza. La etiqueta de sensibilidad de un objeto especifica el nivel de confianza requerido para acceder a él. Para acceder a un objeto determinado, el sujeto debe tener un nivel de sensibilidad igual o superior al del objeto solicitado.
  • Importación y exportación de datos: Controlar la importación de información desde otros sistemas y la exportación a otros sistemas (incluidas las impresoras) es una función crítica de estos sistemas, que deben garantizar que las etiquetas de confidencialidad se mantengan e implementen correctamente para que la información confidencial esté protegida adecuadamente en todo momento.

Para aplicar el control de acceso obligatorio se suelen utilizar dos métodos:

  • Control de acceso basado en reglas (o etiquetas): Este tipo de control define además condiciones específicas para el acceso a un objeto solicitado. Un sistema de control de acceso obligatorio implementa una forma simple de control de acceso basado en reglas para determinar si se debe otorgar o denegar el acceso mediante la coincidencia de:
    • Etiqueta de sensibilidad de un objeto
    • Etiqueta de sensibilidad del sujeto
  • Control de acceso basado en retículos : Estos se pueden utilizar para decisiones complejas de control de acceso que involucren múltiples objetos y/o sujetos. Un modelo de retículo es una estructura matemática que define los valores máximo y mínimo del límite inferior para un par de elementos, como un sujeto y un objeto.

Pocos sistemas implementan MAC; XTS-400 y SELinux son ejemplos de sistemas que sí lo hacen.

Control de acceso basado en roles

El control de acceso basado en roles (RBAC) es una política de acceso determinada por el sistema, no por el propietario. RBAC se utiliza en aplicaciones comerciales y también en sistemas militares, donde pueden existir requisitos de seguridad multinivel. RBAC se diferencia de DAC en que DAC permite a los usuarios controlar el acceso a sus recursos, mientras que en RBAC, el acceso se controla a nivel del sistema, fuera del control del usuario. Aunque RBAC no es discrecional, se distingue de MAC principalmente por la forma en que se gestionan los permisos. MAC controla los permisos de lectura y escritura según el nivel de autorización del usuario y etiquetas adicionales. RBAC controla conjuntos de permisos que pueden incluir operaciones complejas, como una transacción de comercio electrónico, o ser tan simples como leer o escribir. Un rol en RBAC puede considerarse como un conjunto de permisos.

Se definen tres reglas principales para el RBAC:

  1. Asignación de roles: Un sujeto solo puede ejecutar una transacción si ha seleccionado o se le ha asignado un rol adecuado.
  2. Autorización de roles: El rol activo de un sujeto debe estar autorizado para dicho sujeto. Con la regla 1 anterior, esta regla garantiza que los usuarios solo puedan asumir los roles para los que están autorizados.
  3. Autorización de transacciones: Un usuario solo puede ejecutar una transacción si esta está autorizada para su rol activo. Con las reglas 1 y 2, esta regla garantiza que los usuarios solo puedan ejecutar las transacciones para las que estén autorizados.

También se pueden aplicar restricciones adicionales, y los roles se pueden combinar en una jerarquía donde los roles de nivel superior engloban los permisos que poseen los subroles de nivel inferior.

La mayoría de los proveedores de TI ofrecen control de acceso basado en roles (RBAC) en uno o más productos.

Control de acceso basado en atributos

En el control de acceso basado en atributos (ABAC), [ 5 ] [ 6 ] el acceso se concede no en función de los derechos del sujeto asociado a un usuario tras la autenticación, sino en función de los atributos del sujeto, el objeto, las operaciones solicitadas y las condiciones del entorno, en relación con políticas, reglas o relaciones que describen las operaciones permitidas para un conjunto dado de atributos. [ 7 ] El usuario debe demostrar las denominadas afirmaciones sobre sus atributos al motor de control de acceso. Una política de control de acceso basado en atributos especifica qué afirmaciones deben cumplirse para conceder acceso a un objeto. Por ejemplo, la afirmación podría ser "mayor de 18 años". Cualquier usuario que pueda demostrar esta afirmación obtiene acceso. Los usuarios pueden ser anónimos cuando la autenticación y la identificación no son estrictamente necesarias. Sin embargo, se requieren medios para demostrar las afirmaciones de forma anónima. Esto puede lograrse, por ejemplo, mediante credenciales anónimas . XACML (lenguaje de marcado de control de acceso extensible) es un estándar para el control de acceso basado en atributos. XACML 3.0 se estandarizó en enero de 2013. [ 8 ]

Modelos de control de acceso con rotura de cristal

Tradicionalmente, el control de acceso tiene como objetivo restringir el acceso, por lo que la mayoría de los modelos de control de acceso siguen el principio de "denegación por defecto", es decir, si una solicitud de acceso específica no está explícitamente permitida, se denegará. Este comportamiento puede entrar en conflicto con el funcionamiento normal de un sistema. En ciertas situaciones, las personas están dispuestas a asumir el riesgo que implica infringir una política de control de acceso si el beneficio potencial compensa dicho riesgo. Esta necesidad es especialmente evidente en el ámbito sanitario, donde la denegación de acceso a los historiales clínicos puede provocar la muerte del paciente. El mecanismo Break-Glass (también llamado "romper el cristal") intenta mitigar este problema permitiendo a los usuarios anular la decisión del control de acceso. Break-Glass puede implementarse de forma específica para un control de acceso (por ejemplo, en un control de acceso basado en roles [ 9 ] ) o de forma genérica (es decir, independientemente del modelo de control de acceso subyacente) [ 10 ] .

Control de acceso basado en el host (HBAC)

Las siglas HBAC significan "control de acceso basado en el host". [ 11 ]

Véase también

Referencias

  1. ^ Feio, Rui; et al. (12 de agosto de 2014). ABC de la programación de sistemas IBM Z/OS Volumen 6 (2.ª ed.). IBM Corporation. pág. 24. ISBN 9780738439808. Consultado el 17 de diciembre de 2024 .
  2. ^ Dieter Gollmann. Seguridad informática , 3.ª ed. Wiley Publishing, 2011, pág. 387, abajo
  3. ^ Marcon, AL; Olivo Santin, A.; Stihler, M.; Bachtold, J., "Una evaluación de autorización resiliente de UCONabc para computación en la nube", Transacciones IEEE sobre sistemas paralelos y distribuidos , vol. 25, n.° 2, págs. 457–467, febrero de 2014 doi : 10.1109/TPDS.2013.113 , abajo
  4. ^ "Definición de: nivel de recorte" . PC Magazine . Archivado del original el 16 de abril de 2010. Consultado el 26 de agosto de 2017 .
  5. ^ Jin, Xin, Ram Krishnan y Ravi Sandhu. «Un modelo unificado de control de acceso basado en atributos que abarca DAC, MAC y RBAC». Seguridad y privacidad de datos y aplicaciones XXVI. Springer Berlin Heidelberg, 2012. 41–55.
  6. ^ Hu, Vincent C.; Ferraiolo, David; Kuhn, Rick; Schnitzer, Adam; Sandlin, Kenneth; Miller, Robert; Scarfone, Karen. "Guía para la definición y consideraciones del control de acceso basado en atributos (ABAC)" (PDF) .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  7. ^ Hu, Vincent C. (2013). "Guía para la definición y consideraciones del control de acceso basado en atributos (ABAC) (borrador)" . Instituto Nacional de Estándares y Tecnología . 800 (162): 54.
  8. ^ El lenguaje de marcado de control de acceso extensible ( XACML ) V3.0 fue aprobado como estándar OASIS, el lenguaje de marcado de control de acceso extensible (XACML) V3.0 fue aprobado como estándar OASIS.
  9. ^ Ferreira, Ana; Chadwick, David; Farinha, Pedro; Correia, Ricardo; Zao, Gansen; Chiro, Rui; Antunes, Luis (2009). "Cómo ingresar de forma segura a RBAC: el modelo BTG-RBAC". Jornada de Aplicaciones de Seguridad Informática (ACSAC) . IEEE. págs.  23– 31. doi : 10.1109/ACSAC.2009.12 . hdl : 10216/21676 .
  10. ^ Brucker, Achim D.; Petritsch, Helmut (2009). "Ampliando los modelos de control de acceso con sistema de ruptura de cristal". Simposio de la ACM sobre modelos y tecnologías de control de acceso (SACMAT) . ACM Press. pp.  197–206 . doi : 10.1145/1542207.1542239 .
  11. ^ Ballard, Ella Deon (2013). "Guía de administración de identidades: administración de políticas de identidad y autorización para infraestructuras basadas en Linux" . Red Hat . Recuperado el 6 de enero de 2014. Cualquier servicio PAM puede identificarse como el sistema de control de acceso basado en host (HBAC) en IdM.
Obtenido de " https://en.wikipedia.org/w/index.php?title=Computer_access_control&oldid=1296704739 "