Buenas tardes, en este quinto capítulo de la serie Arquitectura de Sistemas Seguros para Aplicaciones Web en Salud Digital continuaré con la explicación de 5 principios para la Administración Segura de Credenciales. En esta segunda parte se aplicarán estos principios a la administración de credenciales de aplicaciones. Sin una correcta administración de credenciales una entidad desconocida podrá tomar control de su aplicación y de la información de sus pacientes.
Principios
1. Principio del menor privilegio
Aplicado a la administración de Credenciales de Aplicaciones implica que las credenciales o permisos empleados por una aplicación para acceder a servicios distintos deben ser distintas. Por ejemplo, las credenciales para acceder a la base de datos deben ser distintas que las credenciales para acceder al servidor de emails. De esta manera cada credencial puede ser administrada de manera diferenciada y reaccionar más efectivamente en caso de fallas de seguridad.
En el caso de una aplicación desplegada en Amazon Web Services, cada acción requiere un permiso para que un recurso pueda realizarla, los que pueden ser desasociados o reasociados cuando se considere adecuado.
2. Principio de defensa en profundidad
Las credenciales deben tener mecanismos por medio de los cuales se verifique que son empleadas y mantenidas de forma segura en la mayor cantidad de dimensiones disponibles. Particularmente las credenciales de aplicación pueden sufrir filtraciones debido a las distintas maneras en que éstas son empleadas. Luego, las credenciales de aplicación deben ser rotadas regularmente con un periodo máximo de 3 meses.
En el caso de Amazon Web Services, cada recurso posee por defecto credenciales que lo identifican como tal (las que le permiten hacer uso de los permisos que tiene asociados) las que rotan cada 6 minutos.
3. Principio de Fallar de Manera Segura
Cada credencial debe poseer un procedimiento asociado en caso de que ésta se vea sustraída, y un respaldo de la información respectiva en caso de que corresponda. Es posible que el fallo provoque muchos daños de todos modos, pero si se está preparado estos pueden mitigarse en su mayor parte. Por ejemplo, en caso de que las credenciales de la base de datos sean sustraídas, pero estas pueden modificarse fácilmente, es posible que no toda la información haya alcanzado a ser copiada y el respaldo puede reponer la información perdida.
En el caso de Amazon Web Services, el servicio de base de datos RDS respalda continuamente toda la información de manera que todo dato escrito es simultáneamente respaldado y está bien documentado cómo implementar la rotación automática y manual de sus credenciales.
4. Principio de Diseño Abierto
La manera en que las credenciales son administradas por la aplicación debe ser estandarizada, estar adecuadamente documentada, fácil de entender y de usar e idealmente, ser la más usada en el mercado. De este modo será más difícil olvidar su funcionamiento, implementar sus distintas medidas de seguridad disponibles, y mejorarlas en caso de que sea necesario.
En el caso de Amazon Web Services, la implementación y el uso tanto del servicio de permisos IAM como el servicio de credenciales Secrets Manager están estandarizados, bien documentados y son empleados por miles de aplicaciones.
5. Principio de minimizar la Superficie de Ataque
Las credenciales de la aplicación deben ser administradas y almacenadas por la menor cantidad de servicios posibles, idealmente por sólo uno. En el caso de Amazon Web Services, es posible emplear Secrets Manager para administrar credenciales, el System Manager Parameter Store o los permisos de IAM (Identity and Access Management).
Particularmente IAM funciona mediante la asignación de roles con permisos de grano fino, para cada acción posible respecto de los distintos servicios disponibles en la plataforma de AWS. Adicionalmente en el caso de que se emplee un servicio de administración de credenciales, los permisos de IAM deben estar presentes de todos modos para permitir que los recursos se comuniquen entre sí. Por tanto se recomienda emplear Secrets Manager, mientras que se aprende a configurar adecuadamente los permisos de IAM para cumplir esta funcionalidad (el uso de IAM es más complejo que Secrets Manager).
Administradores de credenciales
Aquí trataremos 3 administradores de credenciales específicos de Amazon Web Services, sin embargo en los demás proveedores de computación en la nube existen unos con funcionalidades muy similares. Los servicios dedicados a la administración de credenciales en AWS son System Manager Parameter Store, Secrets Manager y IAM.
Arquitectura que permite enviar una notificación a un Workspace de Slack, almacenando su URL en System Manager Parameter Store, cuando el uso de una instancia de cómputo supera un umbral predefinido. Obtenida desde morioh.com
Tanto System Manager Parameter Store como Secrets Manager permiten el almacenamiento prácticamente ilimitado de texto encriptado y una obtención programática de estos a través del AWS SDK, de manera que las aplicaciones pueden obtenerlos dinámicamente en tiempo de ejecución. Secrets Manager tiene la ventaja de que provee facilidades de rotación automática de credenciales con un periodo configurable de entre 1 y 365 días.
Arquitectura que muestra que representa la creación de credenciales de acceso con valores aleatorios, de manera que éstas sean accesible por los recursos que lo requieran. La creación es especificada en un template de Cloudformation, el que también debe asignar permisos a los recurso (e.g. una instancia de cómputo) que necesiten acceder a ellas. Obtenida desde aws
Por otro lado, una instancia desplegada en AWS obtiene automáticamente credenciales de acceso a los servicios para los que su IAM Rol asociado tiene permisos asignados, cada vez que emplee el AWS SDK para acceder a ellos. Estas credenciales rotan cada 6 minutos y no es necesario almacenarlas explícitamente, por lo que cuentan con una clara ventaja de seguridad por las otras opciones. Sin embargo AWS IAM representa un paradigma nuevo en la administración de credenciales de aplicaciones, por lo que se recomienda partir con Secrets Manager y paulatinamente reemplazarlo por IAM.
IAM define distintos tipos de identidades para administrar permisos existentes en una cuenta de AWS. Toda persona que tenga acceso a la cuenta debe poseer un IAM User distinto, y éste puede ser asignado a un IAM Group. Además un IAM User puede poseer distintos tipos de credenciales, mientras que los recursos creados pueden ser asignados un IAM Role. Tanto a los IAM Users, como los Groups y los Roles se les pueden asignar IAM Policies, cada una de las que posee Statements que especifican los permisos que adquiere la identidad que tenga asociada aquella Policy. Obtenida desde msp360.com
→ Link al Capítulo anterior
→ Link al Capítulo siguiente
Referencias
-
Principio del mínimo privilegio: Principio del menor privilegio: la estrategia de limitar el acceso a lo que es imprescindible | WeLiveSecurity
-
¿Qué es la defensa en profundidad? Defensa en profundidad y su relación con la seguridad por capas
-
Principio de Fallar de Manera Segura: https://launchdarkly.com/blog/if-youre-going-to-fail-fail-safely/
-
Principio de Diseño Abierto: https://www.coursera.org/lecture/secure-coding-principles/principle-of-open-design-FQFqL
-
Principio de menor superficie de ataque: What is an attack surface – Reducing it and what it is | Avast
-
Amazon Web Services IAM: Administración de identidades | IAM | AWS
-
Amazon Web Services Secrets Manager: AWS Secrets Manager | Alterne, administre y recupere datos confidenciales | Amazon Web Services (AWS)
-
Amazon Web Services System Manager Parameter Store: AWS Systems Manager Parameter Store - AWS Systems Manager
-
Amazon Web Services RDS: Amazon RDS | Cloud Relational Database | Amazon Web Services