Seguridad del servicio y la aplicación de Service Fabric
Una arquitectura de microservicios puede aportar muchas ventajas. Administrar la seguridad de los microservicios, sin embargo, es un desafío y no es lo mismo que administrar la seguridad de las aplicaciones tradicionales monolíticas.
Con un monolito, normalmente la aplicación se ejecuta en uno o varios servidores dentro de una red y resulta más fácil identificar las API, la dirección IP y los puertos expuestos. A menudo hay un perímetro o un límite, y una base de datos que proteger. Si ese sistema se ve en peligro debido a una infracción de seguridad o a un ataque, es probable que todo el contenido del sistema esté disponible para el atacante. Con microservicios, el sistema es más complejo. Los servicios se descentralizan y se distribuyen en varios hosts, y migran de un host a otro. Con la seguridad apropiada, se limitan los privilegios que un atacante puede obtener así como la cantidad de datos disponibles en un único ataque al poner en riesgo un servicio. La comunicación no es interna, pero se realiza a través de una red y hay muchos puertos expuestos e interacciones entre servicios. Saber qué son estas interacciones de servicio y cuándo se producen resulta fundamental para la seguridad de las aplicaciones.
Este artículo no es una guía de seguridad de microservicios, ya que muchos de estos recursos están disponibles en línea. Sin embargo, describe cómo pueden abordarse los diferentes aspectos de seguridad en Service Fabric.
Autenticación y autorización
A menudo es necesario para los recursos y las API expuestas por un servicio limitarse a determinados usuarios de confianza o clientes. La autenticación es el proceso de determinar la identidad de un usuario de forma confiable. La autorización es el proceso que pone las API o los servicios a disposición de algunos usuarios autenticados y no de otros.
Authentication
El primer paso para tomar decisiones de confianza sobre el nivel de API es la autenticación. La autenticación es el proceso de determinar la identidad de un usuario de forma confiable. Cuando hay microservicios, la autenticación normalmente se controla de forma centralizada. Si usa una API Gateway, puede descargar la autenticación a la puerta de enlace. Si utiliza este método, asegúrese de que no se pueda llegar directamente a los servicios individuales (sin la API Gateway) a menos que se implemente una seguridad adicional para autenticar si los mensajes proceden de la puerta de enlace o no.
Si se puede tener acceso directamente a los servicios, es posible emplear un servicio de autenticación como Microsoft Entra ID o un microservicio de autenticación dedicado que actúe como servicio de token de seguridad (STS) puede utilizarse para autenticar a los usuarios. Las decisiones de confianza se comparten entre los servicios con tokens de seguridad o cookies.
En ASP.NET Core, el mecanismo principal para autenticar a los usuarios es el sistema de pertenencia a Identity de ASP.NET Core. Identity de ASP.NET Core almacena información de usuario (incluida la información de inicio de sesión, roles y notificaciones) en un almacén de datos configurado por el desarrollador. Admite la autenticación en dos fases. También se admiten proveedores de autenticación externos, por lo que los usuarios pueden iniciar sesión con los procesos de autenticación existentes de proveedores como Microsoft, Google, Facebook o Twitter.
Authorization
Después de la autenticación, los servicios tienen que autorizar el acceso de usuario o determinar lo que un usuario es capaz de hacer. Este proceso permite que un servicio ponga las API a disposición de algunos usuarios autenticados, pero no de todos. La autorización es ortogonal e independiente de la autenticación, que es el proceso de determinar quién es un usuario. La autenticación puede crear una o varias identidades para el usuario actual.
La autorización de ASP.NET Core puede llevarse a cabo según los roles de los usuarios o según una directiva personalizada, lo que puede incluir inspeccionar las notificaciones u otra heurística.
Restricción y protección del acceso mediante una puerta de enlace de API
Las aplicaciones en la nube normalmente necesitan una puerta de enlace front-end para proporcionar un único punto de entrada para usuarios, dispositivos u otras aplicaciones. Una puerta de enlace de API se ubica entre los clientes y los servicios, y es el punto de entrada a todos los servicios que proporciona la aplicación. Actúa como un proxy inverso, enrutando las solicitudes de los clientes a los servicios. También puede realizar diversas tareas transversales como la autenticación, la autorización, la terminación TLS y la limitación de velocidad. Si no implementa una puerta de enlace, los clientes deben enviar las solicitudes directamente a los servicios front-end.
En Service Fabric, una puerta de enlace puede ser cualquier servicio sin estado como una aplicación ASP.NET Core u otro servicio designado para la entrada de tráfico, como Traefik, Event Hubs, IoT Hub o Azure API Management.
API Management se integra directamente con Service Fabric, lo que le permite publicar API con un amplio conjunto de reglas de enrutamiento para los servicios back-end de Service Fabric. Puede proteger el acceso a servicios back-end, evitar ataques DOS usando la limitación, o verificar las claves API, los tokens JWT, los certificados y otras credenciales. Para obtener más información, consulte Información general de Service Fabric con Azure API Management.
Administración de secretos de aplicación
Los secretos pueden ser cualquier información confidencial, como cadenas de conexión de almacenamiento, contraseñas u otros valores que no se deben administrar en texto sin formato. En esta guía se usa Azure Key Vault para administrar las claves y los secretos. Sin embargo, el uso de secretos en una aplicación es independiente de la plataforma de nube para permitir que las aplicaciones se implementen en un clúster hospedado en cualquier parte.
La forma recomendada de administrar las opciones de configuración de servicio es mediante los paquetes de configuración de servicio. Los paquetes de configuración se actualizan mediante actualizaciones acumulativas administradas con validación de estado y reversión automática. Esto es preferible a la configuración global ya que reduce las posibilidades de una interrupción del servicio global. Los secretos cifrados no son ninguna excepción. Service Fabric presenta características integradas para cifrar y descifrar valores en un archivo Settings.xml de paquete de configuración mediante cifrado de certificados.
En el diagrama siguiente se ilustra el flujo básico para la administración de secretos en una aplicación de Service Fabric:
Hay cuatro pasos principales en este flujo:
- Obtener un certificado de cifrado de datos.
- Instalar el certificado en el clúster.
- Cifrar los valores de secreto al implementar una aplicación con el certificado e insértelos en un archivo de configuración Settings.xml del servicio.
- Leer los valores cifrados de Settings.xml y usar el mismo certificado de cifrado para descifrarlos.
Azure Key Vault se usa aquí como ubicación de almacenamiento seguro para los certificados y como forma de obtener los certificados instalados en clústeres de Service Fabric en Azure. Si no va a implementar en Azure, no es necesario usar Key Vault para administrar secretos en aplicaciones de Service Fabric.
Para obtener un ejemplo, consulte Administración de los secretos de aplicación.
Seguridad para el entorno de hospedaje
Azure Service Fabric le permite proteger aplicaciones que se ejecutan en distintas cuentas de usuario en el clúster. Service Fabric también protege los recursos que usan las aplicaciones en el momento de la implementación con la cuenta de usuario; por ejemplo, archivos, directorios y certificados. Esto aumenta la seguridad entre aplicaciones en ejecución, incluso en un entorno hospedado compartido.
El manifiesto de aplicación declara las entidades de seguridad (usuarios y grupos) que requerían ejecutar los servicios y proteger los recursos. A estas entidades de seguridad se hace referencia en las directivas, por ejemplo en las directivas de acceso de seguridad, de ejecución, de enlace de puntos de conexión o de uso compartido de paquetes. Las directivas se aplican entonces a los recursos del servicio en la sección ServiceManifestImport del manifiesto de aplicación.
Al declarar los principios, también se pueden definir y crear grupos de usuarios, de modo que se puedan agregar uno o varios usuarios a cada grupo para poder administrarlos de forma conjunta. Esto es útil cuando hay varios usuarios para distintos puntos de entrada de servicio y es preciso que tengan ciertos privilegios comunes disponibles en el nivel de grupo.
De forma predeterminada, las aplicaciones de Service Fabric se ejecutan en la misma cuenta en que se ejecuta el proceso Fabric.exe. Service Fabric también permite ejecutar aplicaciones en una cuenta de usuario local o una cuenta de sistema local especificada en el manifiesto de la aplicación. Para obtener más información, consulte Ejecución de un servicio como cuenta de usuario local o cuenta de sistema local. También puede ejecutar un script de inicio de servicio como cuenta de usuario local o del sistema.
Si va a ejecutar Service Fabric en un clúster de Windows independiente, puede ejecutar un servicio en cuentas de dominio de Active Directory o en cuentas de servicio administradas de grupo.
Protección de contenedores
Service Fabric proporciona un mecanismo para los servicios dentro de un contenedor para acceder a un certificado que está instalado en los nodos de un clúster de Windows o Linux (versión 5.7 o superior). Este certificado PFX puede usarse para autenticar la aplicación o el servicio, o para proteger la comunicación con otros servicios. Para obtener más información, consulte Importación de un certificado en un contenedor.
Además, Service Fabric también admite gMSA (cuentas de servicio administradas de grupo) para los contenedores de Windows. Para obtener más información, consulte Configuración de gMSA para contenedores de Windows.
Comunicación segura del servicio
En Service Fabric, un servicio se ejecuta en algún lugar en un clúster de Service Fabric que normalmente se distribuye entre varias máquinas virtuales. Service Fabric ofrece varias opciones para proteger las comunicaciones de servicio.
Puede habilitar los puntos de conexión HTTPS en los servicios web ASP.NET Core o Java.
Puede establecer una conexión segura entre el proxy inverso y los servicios, lo que crea un canal seguro de un extremo a otro. La conexión a servicios seguros solo se admite cuando se configura el proxy inverso para escuchar en HTTPS. Para obtener información acerca de cómo configurar el proxy inverso, lea Proxy inverso en Azure Service Fabric. Conectarse a un servicio seguro describe cómo establecer una conexión segura entre el proxy inverso y los servicios.
El marco de trabajo de la aplicación de Reliable Services proporciona una serie de pilas de comunicación creadas previamente y herramientas que puede utilizar para mejorar la seguridad. Aprenda a mejorar la seguridad cuando se utiliza la comunicación remota de servicios (en C# o Java) o con WCF.
Incluir certificados de punto de conexión en aplicaciones de Service Fabric
Para configurar el certificado de punto de conexión de la aplicación, incluya el certificado añadiendo un elemento EndpointCertificate y un elemento User a la cuenta de entidad de seguridad del manifiesto de aplicación. Por defecto, la cuenta de entidad de seguridad es NetworkService. Esto proporcionará la administración de la ACL de clave privada del certificado de aplicación para la entidad de seguridad proporcionada.
<ApplicationManifest … >
...
<Principals>
<Users>
<User Name="Service1" AccountType="NetworkService" />
</Users>
</Principals>
<Certificates>
<EndpointCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
</Certificates>
</ApplicationManifest>
Cifrado de datos en reposo de la aplicación
Cada tipo de nodo de un clúster de Service Fabric que se ejecuta en Azure se encuentra respaldado por un conjunto de escalado de máquinas virtuales. Mediante una plantilla de Azure Resource Manager, puede asociar discos de datos a los conjuntos de escalado que componen el clúster de Service Fabric. Si los servicios guardan los datos en un disco de datos conectado, puede cifrar esos discos de datos para proteger los datos de aplicación.