Herramientas de usuario
app:tema4
Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
| app:tema4 [2024/12/12 16:54] – thejuanvisu | app:tema4 [2024/12/12 17:17] (actual) – thejuanvisu | ||
|---|---|---|---|
| Línea 127: | Línea 127: | ||
| ===== Control de acceso ===== | ===== Control de acceso ===== | ||
| Impedir a otros usuarios que puedan acceder a funcionalidades como las de administrador. | Impedir a otros usuarios que puedan acceder a funcionalidades como las de administrador. | ||
| - | |||
| ==== Control de acceso basado en roles ==== | ==== Control de acceso basado en roles ==== | ||
| + | |||
| + | Basado en modelo RBAC Role Based Access Control, esta condicionado a que un usuario tenga un rol o un conjunto de roles. Funciona bien cuando aplicaciones y servicios están modelados. La idea es que un empleado solo pueda usar las aplicaciones y funcionalidades que necesite su departamento. El problema es que puede ser tedioso al ser necesario establecer todos los roles que debe tener un usuario, el problema de esto es que puede llegar a ser problemático si hay demasiados roles y usuarios. Es una solución perfecta para una empresa con pocos departamentos que igual necesita un rol por departamento más otros de administración. El problema es cuando la empresa es excesivamente grande y necesita cientos de roles diferentes. | ||
| + | |||
| + | RBAC es un modelo muy estático, por su solo no permite modelar de forma completa las reglas de control de acceso. Es necesario código adicional para ello. | ||
| ==== Control de acceso basado en atributos ==== | ==== Control de acceso basado en atributos ==== | ||
| + | Es el sistema más potente. Conocido como modelo ABAC: Attribute Based Access Control. Suele utilizar atributos (Tienen un nombre y un valor), curiosamente los roles pueden ser consideradas atributos. se tiene en cuenta lo siguiente: | ||
| + | * Sujeto: el que invoca la acción. Puede ser un usuario u otro tipo de entidad. Atributos como ID, nombre, roles, etc... | ||
| + | * Recurso: Objeto sobre el que se aplican las acciones. Atributos propios | ||
| + | * Entorno: Atributos como día, mes, etc... | ||
| + | * Políticas | ||
| + | |||
| + | El modelo ABAC pretende que las PRINCIPALES políticas de control de seguridad NO estén cableadas en las aplicaciones. De esta forma si se decide variar las reglas de control de acceso no es necesario tocar el código de las aplicaciones. La idea es que puedan ser editadas por alguien que no sea desarrollador (Poco realista, al final lo acaba haciendo un desarrollador por orden de alguien de negocio). | ||
| + | === Ejemplos de ABAC === | ||
| + | < | ||
| + | Eliminación de proyectos: | ||
| + | user.rol == ' | ||
| + | |||
| + | Edición de una nómina: | ||
| + | user.department == ' | ||
| + | </ | ||
| + | === Como funciona el modelo ABAC === | ||
| + | - La aplicación debe correr la librería PEP (Policy Enforcement Point) | ||
| + | - Cuando la aplicación recibe una petición de un usuario, la aplicación pregunta al PEP, que a su vez pregunta al Policy Decision Point (PDP) si dicho usuario puede realizar la acción | ||
| + | - El PDP recupera la política relacionada del Policy | ||
| + | - Si los atributos coinciden con aquellos permitidos se da permiso al usuario la realización de la acción en la aplicación. | ||
| + | === XACML === | ||
| + | eXtensible Acces Control Markage Laguguaje Ofrece un lenguaje XML para la definición de políticas. La idea es que este documento se editara desde una aplicación. También establece el formato de las peticiones que hace el PEP al PDP. | ||
app/tema4.1734022497.txt.gz · Última modificación: 2024/12/12 16:54 por thejuanvisu
Herramientas de la página
