Seguridad, palabrita omnipresente en este mundo tecnológico pero que tantas confusiones trae a quienes de alguna manera tienen que lidiar con ella, ya sea estableciendo infraestructuras seguras, o desarrollando aplicaciones que no sean vulnerables a malos usos o ataques, y claro… con la nube hay cosas que toca revisitar, y … a eso vamos.

Este articulo no pretende ser una guía de como implementar la seguridad en Azure, pero si que espera contextualizar el entorno en que nos encontramos, como hemos llegado hasta el y una (entre otras) forma adecuada de gestionar la seguridad de nuestras aplicaciones en la nube.

En todo caso tenemos que partir de dos conceptos esenciales (otros son los relativos a la categorización de los recursos a proteger) en este rubro: Autenticación y Autorización.

Grosso modo, Autenticación es la capacidad de garantizar que quien quiere acceder a un recurso (sistema, dato, infraestructura) es quien dice ser, y esto se ha ido logrando mediante: contraseñas, biometría, tokens físicos, etc. Por otro lodo la Autorización se enfoca en la asignación correcta de los permisos respecto a que se puede hacer con el recurso en cuestión, dependiendo del rol o perfil de la persona ya Autenticada.

Hasta ahí todo claro, ahora reflexionemos como hemos trabajado con estos conceptos, supongamos que tenemos una BD llamada “Negocios” con dos tablas: “Productos” y “Ventas”, y supongamos que se necesita que Juan, pueda mantener el catálogo pero que solo pueda consultar las ventas realizadas, empecemos poco a poco.

Pues bien, para esto será necesario que Juan se autentique ante la BD, ya sea mediante usuario y password manejados por la BD, o que la BD “acepte” la autenticación que Juan ha hecho ante el Sistema Operativo, ya sea local o el de la organización, y por otro lado aplicar un GRANT al usuario “Juan” para que este solo puede hacer SELECT sobre la tabla “Ventas”, y además un GRANT para que este mismo usuario pueda hacer INSERT, SELECT, UPDATE y DELETE sobre “Productos”, pero no permisos para borrar la tabla o modificar su estructura, hasta aquí nada fuera de lo común, y con la misma lógica podríamos dar GRANT más generosos a Elena para que haga operaciones de mantenimiento sobre ambas tablas.

Esto de manera muy simplificada, en un entorno real y mas ordenado, lo usual es que se creen “roles” preestablecidos con las diversas combinaciones de permisos y de esta manera a Juan se le podría asignar un rol ya existente que tenga los permisos ya mencionados sobre “Ventas” y “Productos” (en este caso Rol1), siendo que luego a alguien nuevo se le asigne ese mismo Rol1, simplificando la administración en lugar de asignar los permisos de manera individual, como se ve aquí:

Perfecto, con eso cubrimos el escenario cuando Juan o Elena tienen que usar herramientas como el TOAD o SQL Server Management Studio, pero… ¿que pasa cuando son aplicaciones las que tienen que acceder a una BD a fin de mostrar resultados a sus usuarios? Pues en estos casos las opciones existentes son básicamente dos:

1. Usar una cadena de conexión en la que en una sección hay una parte que dice algo como “User ID=admin;Password=Miclavesupersecreta”.
2. Usar una cadena de conexión que invoque a Seguridad Integrada (en el caso de SQL Server) de esta forma: Integrated Security = True, para lo cual la aplicación deberá haber sido vinculada a un “usuario”, como ha sido habitual con el usuario ASP_NET en el IIS.

Bueno, esto es el escenario que ya conocemos del desarrollo de aplicaciones on premise, nada fuera de lo común, pero… y esto ¿cómo evoluciona en la nube?

Para empezar el esquema “1)” todavía sigue vigente, aun se puede usar, pero no es recomendable salvo caso extremo, debido a que gestionar una contraseña para una app nos obliga a saber donde guardarla, quienes la conocen, etc,  lo cual nos da para otra conversación, que proseguiremos en el siguiente post, así quedemonos con esa idea, no es bueno, no lo hagas, y mucho menos guardes una cadena de conexión con el codigo fuente de la aplicación, ok? pero eso ya lo sabiamos, no?

Ok… fin del paréntesis, regresamos a la nube.

El primer hecho que debemos entender cuando aplicamos los conceptos de autenticación y autorización la aplicación de estos va mas allá de los clásicos conceptos de Servidor, Usuario, Aplicación y adicionales, en la nube debemos tomar nota de que trabajamos con una diversidad de servicios categorizados e identificables: Bases de Datos, Contenedores, Almacenamiento, servicios serverless, colas, bus, etc, por lo que para que una aplicación funcione en la nube se hace necesario orquestar un conjunto de servicios y que estos se comuniquen y establezcan relaciones de confianza entre si, y claro, algunos de estos servicios son donde vamos a desplegar nuestras aplicaciones.

Con esto en claro, pasamos al siguiente hecho, en la nube es posible que a un recurso A se le de un permiso especifico para acceder a un recurso B, por ejemplo que un Logic App pueda leer los valores registrados en un App Configuration, pero no manipularlos, o que a un Web App le demos permisos para escribir y borrar objetos en un Storage, y si, sin guardar credenciales, esto debido a que ambos recursos están ya autenticados por pertenecer a Azure, o para ser mas preciso sus “identidades” son gestionadas por Azure AD (*).

Como podemos ver, estamos dejando tanto el esquema “1)” como el “2)” en que había que “hacer creer” a la BD que existía un usuario con cierto rol, y que este usuario era el que se conectaba, “artificio” para que hemos usado por años para que las aplicaciones (web generalmente) se conectaran a una BD.

Antes de entrar en detalles técnicos, debemos tomar conciencia de lo que implica este cambio para la seguridad en las organizaciones, de ahora en adelante ya no basta con regular los roles de las personas y la seguridad de gestión de las contraseñas, una política de seguridad ahora debe incluir una gestión de la identidad a nivel de los recursos en la nube y sus relaciones entre si, este cambio es irreversible y cuanto antes lo entiendan las organizaciones, mejor.

Bueno, es todo por hoy, en breve continuaremos con esta revisión y explicando como esto se aplica con recursos reales.

(*) Un esquema equivalente también funciona en AWS, solo que en este caso la gestión se gestiona mediante sus configuraciones de IAM.