El objetivo de este documento es proveer al lector una información útil sobre el diseño y la creación de un sistema de Control de Acceso Basado en Roles (RBAC).
Un sistema RBAC proporciona tres tipos de características: autenticación,
autorización y auditoría:
2.1 Autenticación
Confirma la identidad del usuario: la autenticación consiste en
comprobar la identidad del usuario que entra a su aplicación. Este
proceso se lleva a cabo en dos pasos: primero, la identificación,
donde el usuario declara quién es. El segundo paso consiste en
comprobar dicha identificación. Generalemente, este proceso se
realiza por medio de cuentas de usuario y contraseñas. Esta etapa
es el primer nivel de seguridad.
2.2 Autorización
Las autorizaciones definen lo que un usuario puede hacer en una aplicación:
básicamente, usted define lo que el usuario podrá ver, hacer
y modificar en la aplicación.
Existen dos métodos para definir las autorizaciones:
La etapa de autorización es el segundo nivel de seguridad y es,
en efecto, la parte más pesada del diseño de un sistema
RBAC, ya que usted tiene que codificar cada permiso/restricción.
2.3 Auditoría
Conserve un historial y un control de las transacciones sensibles en su
aplicación: usted podría necesitar esta información
para cumplir ciertas reglas de gestión de su empresa, con requerimientos
legales como SOX o para cumplir con procesos de certificación tipo
ISO.
La auditoría le permitirá saber quién hizo qué
en su aplicación, cuándo lo hizo y quién concedió
qué permiso a quién.
El sistema RBAC para aplicaciones corporativas se compone de los siguientes
elementos:
3.1 Un repositorio asegurado para almacenar los datos de RBAC
Usted necesita un lugar seguro donde almacenar los datos y las contraseñas
de los usuarios, sus roles y sus permisos.
3.2 Un componente integrado en la aplicación
Este componente se comunicará con el repositorio RBAC de modo que
la aplicación se ajustará a las autorizaciones de los usuarios.
3.3 Una consola de administración
Esta aplicación está diseñada para el personal no
técnico con el objetivo de que éstos puedan gestionar el
uso de las cuentas de usuario y conceder permisos. Esta consola se compone
de una interfaz amigable que permite el manejo de esta información
sin complicación alguna, liberando así al grupo de desarrolladores
de esta tarea.
3.4 Documentación para los desarrolladores y los administradores
En cualquier momento, usted puede necesitar documentación para
todo el personal que trabaje en el proceso de seguridad de sus aplicaciones.
Por ejemplo una guía de integración, un manual del usuario,
una FAQ (Preguntas y Respuestas Frecuentes), etc.
4.1 ¿Qué significa esto?
Para que los permisos sean independientes del código de la aplicación,
éstos no deben ser definidos dentro del mismo. Por lo tanto, usted
necesitará insertar una llamada en el código de su aplicación
para activar el sistema RBAC. Cabe resaltar que esta llamada no es un
permiso por sí mismo.
Si el código que define los permisos es mezclado con el código
de la aplicación, usted puede tener, en el largo plazo, problemas
con el mantenimiento de sus aplicaciones.
4.2 Permisos y aplicación: un ciclo de vida incompatible
La administración del control de acceso es requerida frecuentemente
(debido a la creación de nuevas cuentas, cambios en los permisos,
etc.). Los cambios en una aplicación son al contrario, no tan frecuentes.
De hecho, la versión final de una aplicación puede ser valida
por meses. Por lo general, la vida útil de un permiso tiende a
ser mucho más corta que la vida útil de la aplicación.
Si los permisos son mezclados con el código de la aplicación,
los usuarios finales tienen que esperar una nueva versión de la
misma para beneficiarse de los nuevos permisos.
Por lo tanto, la definición o la concesión de permisos no
deberían apoyarse en las nuevas versiones de la aplicación.
Usted debería ser capaz de añadir o conceder un permiso
sin cambiar el código de la aplicación (lo cual requiere
un ciclo de desarrollo completo: codificación, pruebas, eliminación
de bugs, despliegue …). Si los nuevos permisos son tomados en cuenta
de manera dinámica (sin tocar el código pesado en la aplicación),
usted será capaz de definir/conceder los permisos mientras su aplicación
se encuentra aún en producción. ¡De ser así,
ellos podrían ser utilizados inmediatamente!
4.3 Independencia de los administradores
Los administradores locales conocen a cada usuario final y las autorizaciones
del mismo (sobre todo en el caso de sitios remotos). Ellos necesitan un
instrumento de administración de fácil uso para manejar
las cuentas y los permisos de los usuarios sin necesidad de apoyarse en
el equipo de desarrollo. Esto sólo es posible si la creación
de permisos no implica un cambio en el código de la aplicación.
4.4 Libera al equipo de desarrollo
If end-users and administrators take care of the daily management of user
accounts and permissions, the development team can focus on development
itself.
Do you need to…
5.1 Necesita usted ... ¿Asegurar diversas aplicaciones en un repositorio
centralizado?
¿Necesita usted centralizar todas sus aplicaciones en un mismo
repositorio centralizado? ¿Sus administradores deberán tener
una vista general de todas las aplicaciones y de las cuentas usuario de
éstas?
5.2 …¿Gestionar roles compartidos?
Un rol compartido puede ser usado para varias aplicaciones, mientras que
un rol específico sólo es usado para uno solo. Los roles
compartidos son, en particular, útiles si sus empleados realizan
varias actividades: así, usted no tiene que gestionar un rol para
cada aplicación a la cual un usuario puede tener acceso.
5.3 …¿Soportar el Single Sign-On (autenticación
única)?
Un rol compartido puede ser usado para varias aplicaciones, mientras que
un rol específico sólo es usado para una sola. Los roles
compartidos son,en particular, útiles si sus empleados realizan
varias actividades: así, usted no tiene que gestionar un rol para
cada aplicación a la cual un usuario puede tener acceso.
5.4 …¿Soportar diversas tecnologías (Winforms,
Webforms, Webservices)?
En un futuro, ¿Necesitará usted que su sistema RBAC soporte
otras tecnologías? .Net proporciona una amplia gama de tecnologías
de desarrollo: Winform, Webforms, Webservices… Si su sistema toma
en cuenta solamente sus necesidades a corto plazo (aplicaciones Winform
por ejemplo) usted podría verse en la necesidad de desarrollar
otras soluciones para soportar otras tecnologías, y terminar asi
con varios sistemas RBAC y con costos mayores en desarrollo, mantenimiento
y capacitación.
5.5 …¿Generar reportes sobre las cuentas de usuario
y sus permisos?
Usted podría verse en la necesidad tener que proporcionar descripciones
detalladas de las cuentas de usuario existentes, así como de los
permisos concedidos a cada usuario.
5.6 …¿Cumplir con requerimientos de auditoría
(SOX…)?
Para cumplir con requerimentos legales o de una certificación (Sarbanes-Oxley
el Acto, ISO, CMMI, ITIL …) usted podría necesitar un seguimiento
de todas las acciones que los usuarios finales realizaron con la aplicación
(¿Quién entró en la aplicación?, ¿Quién
abrió un formulario? ¿Quién modificó un registro?).
En un futuro, usted podría necesitar este registro para monitorear
sus transacciones sensibles (finanzas).
5.7 ...¿Soportar un equipo de desarrolladores grande o
internacional?
¿Cuenta con un equipo de desarrollo grande? ¿Su equipo de
desarrollo está disperso en diferentes ubicaciones?. Si éste
es su caso, coordinar su equipo le requiere un esfuerzo importante. La
rotación de personal y el manejo del conocimiento pueden convertirse
en un verdadero problema.
5.8 ¿Tipo de permiso: qué tanto necesita asegurar
la aplicación?
Al definir el control de acceso, usted empieza generalemente deshabilitando
ciertas opciones del menú. En esta situación usted podría
necesitar una gama más amplia de acciones en sus aplicaciones,
desde la opción de deshabilitar ciertas opciones del menú
hasta filtrar informaciones de acuerdo a los permisos otorgados a los
usuarios.
¿Necesita usted hacer alguna de las actividades mencionadas anteriormente?
¿Esconder o deshabilitar campos u opciones del menú, tabs
o controles? ¿Filtrar una lista de información diferente
dependiendo el usuario final que utiliza la aplicación? ¿Modificar
las reglas de negocio?
Cuando escogemos una solución, por lo general sólo nos fijamos
en el costo inicial. ¿Cuánto me costaría desarrollar
o comprar la solución adecuada?
¡Muy pocas son las personas que se dan cuenta que el costo incial
sólo representa del 10 a 20 % del costo total!
La mayor parte del costo aparece en el largo plazo: es decir, al usar
y al mantener la solución.
Forrester Research estima que el 78 % del presupuesto de informática
es utilizado en los costos de mantenimiento. ¡Esta afirmación
no es solamente verdadera para aplicaciones de gestión, sino también
para el sistema RBAC!
Cuando diseñe su sistema, usted deberá prever los gastos
mayores que tendrá que pagar en los próximos 10 a 20 años.
6.1 Apoyar a los desarrolladores y a los administradores
Los desarrolladores deberán ser asistidos cuando integren un sistema
de seguridad a su aplicación: definir permisos, implementar procesos
de autenticación, usar las nuevas versiones del framework.Net…
Los administradores también necesitarán ayuda para gestionar
las cuentas de usuario, los roles y los permisos.
Por lo tanto, usted necesitará una solución para apoyar
a sus desarrolladores y administradores en el largo plazo. En el caso
de soluciones internas, usted tendrá que mantener un equipo de
soporte y gestionar, al mismo tiempo, la rotación de personal y
la transferencia de conocimientos dentro de éste a lo largo de
los años.
6.2 Mantener los permisos coherentes con el código
Cuando una aplicación evoluciona, es necesario asegurarse de que
los permisos permanezcan compatibles con el código de la aplicación.
Por ejemplo, si un control es modificado, usted tiene que comprobar que
todas las restricciones relacionadas con este control continúen
trabajando de manera correcta. Cada nueva versión de la aplicación
necesita una verificación completa de todos sus permisos. Algunos
sistemas RBAC proporcionan un proceso de verificación de permisos
automatizado, el cual podrá ser utilizado una vez que usted valide
su aplicación.
6.3 Desplegar nuevas versiones de la aplicación
Cada nueva versión de una aplicación viene con un nuevo
conjunto de permisos. Estos nuevos permisos deberían ser desplegados
con la nueva versión de la aplicación. Lamentablemente,
usted no puede solamente sustituir el viejo repositorio por el nuevo,
puesto que de esta forma todos los datos capturados por el administrador
cuando la aplicación estaba en producción (cuentas de usuario,
roles y permisos concedidos a estas cuentas) se perderían.
Por ello, usted tendrá que capturar con cuidado los nuevos permisos
en el repositorio existente. Esto también implica una importación/
exportación manual, a no ser que su sistema RBAC le proporcione
un instrumento de despliegue automatizado.
6.4 Realizar el control de versiones de los datos de seguridad
Mientras una nueva versión de una aplicación está
siendo desplegada, algunos usuarios pueden usar la nueva versión
mientras que otros pueden estar trabajando todavía en la versión
antigua. Tanto el nuevo repositorio de permisos como el ya existente,
deben estar disponibles durante el proceso de migración.
Usted deberá, por lo tanto, asegurarse de que las dos versiones
permanezcan disponibles y de que cada usuario tenga acceso solamente al
repositorio de la versión apropiada.
Las soluciones de seguridad desarrolladas internamente proporcionan algunas
características de seguridad sin embargo estas soluciones presentan
ciertos problemas, como :
7.1 El desarrollo y el mantenimiento dependen de los recursos
internos
Si usted tiene una solución interna, usted tendrá que ser
particularmente cuidadoso con su manejo. De hecho, usted no puede permitirse
perder el conocimiento de la misma mediante la rotación de personal
y así quedarse sin ningún miembro en su equipo capaz de
gestionar la seguridad de su aplicación. De hecho, lo ideal es
que usted mantenga un equipo que pueda manejar cualquier pregunta, cambio
o crisis que llegue a perturbar su sistema de seguridad.
7.2 Cuentas de usuario específicas a la aplicación
Implementar un sistema de autenticación única en una aplicación
.NET es complicado. Esta acción implica conectarse con el Directorio
Activo y así utilizar las cuentas de Windows para identificar a
los usuarios. Por consiguiente, la mayor parte de las aplicaciones utilizan
cuentas de usuario creadas especificamente para dicha aplicación
y son almacenadas en la base de datos de la misma. Esta solución
es probablemente la más fácil de desarrollar, sin embargo,
ella es también la más dificil de mantener: las cuentas
de usuario necesitan ser gestionadas por el equipo de desarrollo mientras
que las cuentas del Directorio Activo/Windows ya existen y son gestionadas
por administradores de sistema.
7.3 Acceso y permiso: baja granularidad
Adaptar una solución desarrollada internamente a todas las exigencias
de un negocio es, a menudo, una actividad complicada. Los gerentes tienden
a tomar en cuenta solamente la funcionalidad de una solución, dejando
a un lado las implicaciones técnicas de la misma. ¡Hacer
que las opciones de un menú estén disponibles es una cosa,
lograr que ellas trabajen es otra totalmente diferente!
7.4 Código específico en la aplicación
Generalemente, las soluciones hechas en casa codifican los permisos dentro
de la aplicación de manera directa. Por lo tanto, los desarrolladores
terminan con un sistema de seguridad complejo, costoso de mantener y difícil
de actualizar. Cuando los datos de seguridad necesitan ser capturados
o actualizados, el desarrollador debe referise al código, encontrar
la información anterior, cambiar el código, para después
volver a probarlo y desplegar la aplicación nuevamente. Todo este
proceso carece de reactividad y de flexibilidad.
Además, de manera general la gente se da cuenta de sus necesidades
de seguridad mucho después de la fase de diseño. A menudo,
es muy difícil o incluso imposible cumplir con esta exigencia de
seguridad durante la fase de desarrollo. Generalmente, los permisos complejos
son identificados cuando la aplicación está en producción,
requiriendo una modificación inmediata dentro de la aplicación.
7.5 Una solución separada para cada aplicación:
problemas de mantenimiento
En teoría, usted debe ser capaz de tener una visión clara
de lo que una empresa llegará a ser dentro de los próximos
5 a 10 años, sin embargo en la vida real esto es más que
imposible. Es probable que en un futuro usted necesite desarrollar una
nueva aplicación basada en una tecnología no soportada por
su sistema de seguridad antiguo. Por lo tanto, probablemente usted acabaría
creando un nuevo sistema de seguridad para esta nueva aplicación.
Eventualmente, usted tendría un sistema de seguridad para cada
aplicación o, dicho de otra manera, tendría enormes costos
de mantenimiento.
Novalys ha estado desarrollando soluciones de autenticación y de
permisos para aplicaciones corporativas durante más de 15 años.
Basados en esta experiencia, nosotros hemos diseñado Visual Guard,
una solución dirigida a asegurar las aplicaciones .Net, no importando
lo complejo del entorno.
8.1 Una sola solución para asegurar y centralizar todas
sus aplicaciones .Net
Visual Guard le permite asegurar cualquier tipo de aplicación Winform,
Webform y Webservices dentro de una misma herramienta. Usted puede centralizar
la gestión de todas sus aplicaciones con sus respectivas cuentas
de usuario en un único repositorio asegurado. Visual Guard lo provee
de un sistema de autenticación único y listo para usar,
el cual se apoya en las cuentas de Windows.
Para simplificar aún más la gestión de los permisos,
usted puede crear roles compartidos y autorizaciones para los usuarios
finales que se apliquen a varias aplicaciones.
8.2 Permisos independientes del código
Con Visual Guard, usted no necesita escribir código dentro de su
aplicación para definir los permisos. Esto significa que usted
puede definir e implementar los permisos sin tener que pasar por todo
el ciclo de codificación, pruebas, despliegue y retroalimentación.
Usted puede definir permisos en cualquier momento, incluso cuando la aplicación
está aún en producción. Los permisos toman efecto
inmediatamente.
8.3 Herramientas de administración diseñadas para
personas no técnicas
La consola de Visual Guard facilita la gestión cotidiana de la
seguridad para el personal no técnico. La gestión de las
cuentas de usuario, los roles y los permisos de los mismos no requiere,
en efecto, de una habilidad técnica en específico.
Por lo tanto, cuando usted elija la persona que estará a cargo
de la seguridad, usted no estará suspeditado a sus habilidades
técnicas, optimizando así su proceso de negocio y haciéndolo
más acertivo: sus administradores, sus jefes de sistemas así
como sus gerentes en sitios remotos, pueden encargarse de la seguridad.
Para una flexibilidad aún mayor, usted puede definir varios niveles
de privilegios para los administradores.
Usted puede crear también su propio formato de administrador -
e integrarlo en su aplicación – y así llamar al API
de Visual Guard para administrar cuentas de usuario y roles.
8.4 Desarrollar herramientas para gestionar permisos, versiones
y despliegues
Visual Guard ofrece una amplia gama de herramientas y asistentes para
desarrolladores: usted puede crear permisos en unos cuantos clics, verificar
la coherencia entre las aplicaciones y los permisos de manera automática,
desplegar nuevos permisos en repositorios ya existentes sin alterar la
seguridad de los datos en la producción, gestionar varias versiones
de un repositorio cuando la aplicación se despliegue, etc.
8.5 Herramientas de auditoría para generar reportes de
los permisos y revisar los logs (registros) de las aplicaciones
Los auditores tienen un acceso de sólo lectura en sus aplicaciones,
para explorar los permisos existentes, los roles y las cuentas de usuario
y pueden también generar informes detallados acerca de los mismos.
Ellos pueden revisar los registros de aplicación para supervisar
operaciones específicas, así como también, verificar
los registros de la consola de administración para inspeccionar
quién dió qué autorizaciones a quién.
8.6 Producto estándar con un soporte profesional y actualizaciones
frecuentes
¿Por qué re-inventar la rueda? Visual Guard le proporciona
funcionalidades listas para usar en la seguridad de sus aplicaciones.
Las mismas han sido desarrolladas durante los últimos 15 años
para así llegar a ser una solución estándar para
las empresas.
Implementar Visual Guard es fácil y rápido, de la misma
manera que lo es su curva de aprendizaje.
Novalys proporciona un apoyo internacional: usted podrá enfocarse
a su actividad principal y dejarnos solucionar la seguridad de sus aplicaciones.
Novalys está también comprometido en lograr un mejor uso
de todas las continuas innovaciones de Microsoft en el ambiente .Net,
Microsoft OS, etc.