Marco de seguridad: autenticación | Mitigaciones

Producto o servicio	Artículo
Aplicación web	Consideración sobre el uso de un mecanismo de autenticación estándar para autenticarse en la aplicación web Las aplicaciones deben administrar escenarios de errores de autenticación de forma segura Habilitación de la autenticación adicional o adaptable Asegurarse de que las interfaces administrativas estén correctamente bloqueadas Implementación de funcionalidades de contraseña olvidada de forma segura Asegurarse de que se implementen directivas de cuenta y contraseña Implementación de controles para impedir la enumeración de nombres de usuario
Base de datos	Cuando sea posible, usar la autenticación de Windows para conectarse a SQL Server Cuando sea posible, use la autenticación de Microsoft Entra para conectarse a SQL Database Cuando se use el modo de autenticación de SQL, asegurarse de que se apliquen directivas de cuenta y contraseña en SQL Server No usar la autenticación SQL en bases de datos independientes
Centro de eventos de Azure	Uso de credenciales de autenticación por dispositivo mediante tokens SaS
Límites de confianza de Azure	Habilitar la autenticación multifactor de Microsoft Entra para administradores de Azure
Límites de confianza de Service Fabric	Restricción del acceso anónimo al clúster de Service Fabric Asegurarse de que el certificado de cliente a nodo de Service Fabric sea diferente del certificado de nodo a nodo Uso de Microsoft Entra ID para autenticar a los clientes en los clústeres de service fabric Asegurarse de que los certificados de Service Fabric se obtienen de una entidad de certificación (CA) aprobada
Identity Server	Uso de escenarios de autenticación estándar admitidos por Identity Server Reemplazo de la caché de tokens predeterminada de Identity Server por una alternativa escalable
Límite de confianza de la máquina	Asegurarse de que los archivos binarios de la aplicación implementada están firmados digitalmente
WCF	Habilitación de la autenticación al conectarse a las colas de MSMQ en WCF No establecer clientCredentialType de WCF en Ninguno No establecer clientCredentialType de WCF en Ninguno
API web	Asegurarse de que se usan técnicas de autenticación estándar para proteger las API web
Microsoft Entra ID	Uso de escenarios de autenticación estándar admitidos por Microsoft Entra ID Reemplazo de la caché de tokens de MSAL predeterminada por una caché distribuida Garantía de que se usa TokenReplayCache para impedir la reproducción de tokens de autenticación entrantes Usar bibliotecas MSAL para administrar solicitudes de token de clientes de OAuth2 a Microsoft Entra ID (o AD local)
Puerta de enlace de campo de IoT	Autenticación de dispositivos que se conectan a la puerta de enlace de campo
Puerta de enlace de nube de IoT	Asegurarse de que se autentican los dispositivos que se conectan a la puerta de enlace de nube Uso de credenciales de autenticación por dispositivo
Almacenamiento de Azure	Asegurarse de que solo los contenedores y blobs requeridos reciben acceso anónimo de lectura Concesión de acceso limitado a objetos de Azure Storage mediante SAS o SAP

Consideración sobre el uso de un mecanismo de autenticación estándar para autenticarse en la aplicación web

Título	Detalles
Componente	Aplicación web
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	N/D
Detalles	La autenticación es el proceso donde una entidad demuestra su identidad, normalmente por medio de credenciales, como un nombre de usuario y una contraseña. Hay varios protocolos de autenticación disponibles que se pueden considerar. A continuación se enumeran algunos de ellos: Certificados de cliente Basado en Windows Basado en formularios Federación - ADFS Federación: Microsoft Entra ID Federación - Identity Server Considere el uso de un mecanismo de autenticación estándar para identificar el proceso de origen.

Las aplicaciones deben administrar escenarios de errores de autenticación de forma segura

Título	Detalles
Componente	Aplicación web
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	N/D
Detalles	Las aplicaciones que explícitamente autentican a los usuarios deben administrar los escenarios de errores de autenticación de forma segura El mecanismo de autenticación debe: Denegar el acceso a recursos con privilegios cuando se produzca un error de autenticación. Mostrar un mensaje de error genérico después de que se produzca el error de autenticación y la denegación del acceso. Deberá comprobar: La protección de recursos con privilegios después de errores de inicios de sesión. Se muestra un mensaje de error genérico en los eventos de error de autenticación y denegación del acceso. Las cuentas se deshabilitan después de un número excesivo de intentos erróneos.

Habilitación de la autenticación adicional o adaptable

Título	Detalles
Componente	Aplicación web
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	N/D
Detalles	Compruebe que la aplicación tiene autorización adicional (por ejemplo, la autenticación paso a paso o adaptable, a través de la autenticación multifactor, como enviar OTP en SMS, correo electrónico, etc. o solicitar una nueva autenticación), por lo que el usuario se desafía antes de conceder acceso a la información confidencial. Esta regla también se aplica a la hora de realizar cambios críticos en una cuenta o acción. También significa que la adaptación de la autenticación se tiene que implementar de forma tal que la aplicación exija correctamente autorización contextual hasta el punto de no permitir la manipulación sin autorización de, por ejemplo, parámetros.

Asegurarse de que las interfaces administrativas estén correctamente bloqueadas

Título	Detalles
Componente	Aplicación web
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	N/D
Detalles	La primera solución es conceder acceso únicamente desde un determinado intervalo de direcciones IP de origen a la interfaz administrativa. Si esta solución no es posible, siempre se recomienda exigir autenticación adicional o adaptable para iniciar sesión en la interfaz administrativa.

Implementación de funcionalidades de contraseña olvidada de forma segura

Título	Detalles
Componente	Aplicación web
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	N/D
Detalles	Lo primero es comprobar que las rutas de recuperación de contraseñas olvidadas y otras rutas de recuperación, envían un vínculo que incluye un token de activación por tiempo limitado en lugar de la contraseña en sí. También puede exigirse autenticación adicional basada en tokens temporales (por ejemplo, token de SMS, aplicaciones móviles nativas, etc.) antes de que se envíe el vínculo. En segundo lugar, no debe bloquear la cuenta de los usuarios mientras el proceso de obtención de una nueva contraseña está en marcha. Podría dar lugar a un ataque de denegación de servicio cada vez que un atacante decidiera bloquear intencionadamente a los usuarios con un ataque automatizado. En tercer lugar, siempre que la nueva solicitud de contraseña esté en marcha, el mensaje que se muestra debe generalizarse con el fin de evitar la enumeración de nombres de usuario. En cuarto lugar, nunca permita el uso de contraseñas anteriores e implemente una directiva de contraseñas seguras.

Asegurarse de que se implementen directivas de cuenta y contraseña

Título	Detalles
Componente	Aplicación web
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	N/D
Detalles	Se deben implementar directivas de cuenta y contraseña en conformidad con la política de la organización y los procedimientos recomendados. Para defenderse contra ataques por fuerza bruta y adivinación por diccionario, se debe implementar una directiva de contraseñas seguras que garantice que los usuarios crean contraseñas complejas (por ejemplo, con una longitud mínima de doce caracteres, que incluyan alfanuméricos y especiales). Se pueden implementar directivas de bloqueo de la cuenta de la siguiente manera: Bloqueo temporal: puede ser una buena opción para proteger a los usuarios contra ataques por fuerza bruta. Por ejemplo, cada vez que el usuario escribe una contraseña errónea tres veces, la aplicación puede bloquear la cuenta durante un minuto con el fin de ralentizar el proceso de forzar su contraseña de forma que el atacante ceje en su empeño y abandone. Si fuera a implementar contramedidas de bloqueo permanente, en este ejemplo conseguiría un "DoS" al bloquear las cuentas de forma permanente. Como alternativa, puede generar una contraseña de un solo uso (OTP) y enviarla al usuario fuera de banda (por correo electrónico, SMS, etc.). Otro enfoque podría ser implementar CAPTCHA después de alcanzar un umbral de intentos erróneos. Bloqueo permanente: este tipo de bloqueo se debe aplicar cada vez que detecte que un usuario ataca su aplicación. El contraataque consiste en el bloqueo permanente de su cuenta hasta que el equipo de respuesta tenga tiempo de realizar el análisis forense. Después de este proceso, puede decidir devolver la cuenta al usuario o tomar medidas legales contra él. Este tipo de enfoque impide que el atacante penetre aún más en la aplicación y la infraestructura. Para defenderse contra ataques en cuentas predeterminadas y predecibles, compruebe que todas las claves y contraseñas sean reemplazables y que se generen o reemplacen después del tiempo de instalación. Si la aplicación tiene que generar automáticamente contraseñas, asegúrese de que las contraseñas generadas sean aleatorias y tengan una alta entropía.

Implementación de controles para impedir la enumeración de nombres de usuario

Título	Detalles
Componente	Aplicación web
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	N/D
Pasos	Todos los mensajes de error deben estar generalizados con el fin de evitar la enumeración de nombres de usuario. También, no podrá evitar a veces la pérdida de información en funcionalidades tales como una página de registro. Aquí debe usar métodos de limitación de velocidad, como CAPTCHA, para impedir ataques automatizados.

Cuando sea posible, usar la autenticación de Windows para conectarse a SQL Server

Título	Detalles
Componente	Base de datos
Fase de SDL	Build
Tecnologías aplicables	Local
Atributos	Versión de SQL: todas
Referencias	SQL Server: elegir un modo de autenticación
Pasos	La autenticación de Windows usa el protocolo de seguridad de Kerberos, proporciona la aplicación de directivas de contraseñas en cuanto a la validación de la complejidad de las contraseñas seguras, ofrece compatibilidad para el bloqueo de cuentas y admite la expiración de las contraseñas.

Cuando sea posible, use la autenticación de Microsoft Entra para conectarse a SQL Database

Título	Detalles
Componente	Base de datos
Fase de SDL	Build
Tecnologías aplicables	SQL Azure
Atributos	Versión de SQL: V12
Referencias	Conexión a SQL Database mediante la autenticación de Microsoft Entra
Pasos	Versión mínima: se requiere Azure SQL Database V12 para permitir que Azure SQL Database use la autenticación Microsoft Entra en el Directorio Microsoft

Cuando se use el modo de autenticación de SQL, asegurarse de que se apliquen directivas de cuenta y contraseña en SQL Server

Título	Detalles
Componente	Base de datos
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	Directiva de contraseñas de SQL Server
Pasos	Cuando se usa la autenticación de SQL Server, se crean inicios de sesión en SQL Server que no se basan en cuentas de usuario de Windows. El nombre de usuario y la contraseña se crean mediante SQL Server y se almacenan en SQL Server. SQL Server puede emplear mecanismos de directiva de contraseñas de Windows. En este sentido, puede aplicar las mismas directivas de complejidad y expiración usadas en Windows a las contraseñas utilizadas dentro de SQL Server.

No usar la autenticación SQL en bases de datos independientes

Título	Detalles
Componente	Base de datos
Fase de SDL	Build
Tecnologías aplicables	Local, SQL Azure
Atributos	Versión de SQL: MSSQL2012, Versión de SQL: V12
Referencias	Prácticas recomendadas de seguridad con bases de datos independientes
Pasos	La ausencia de una directiva de contraseña exigida puede aumentar la probabilidad de que se establezca una credencial no segura en una base de datos independiente. Aproveche la autenticación de Windows.

Uso de las credenciales de autenticación por dispositivo mediante tokens SaS

Título	Detalles
Componente	Azure Event Hubs
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	Introducción al modelo de autenticación y seguridad de Event Hubs
Pasos	El modelo de seguridad de Event Hubs se basa en una combinación de tokens de firma de acceso compartido (SAS) y publicadores de eventos. El nombre del publicador representa el valor de DeviceID que recibe el token. Esto ayudaría a asociar los tokens generados con los dispositivos correspondientes. Todos los mensajes se etiquetan con el originador en el lado del servicio, lo que permite la detección de los intentos de suplantación de origen en la carga. Al autenticar a los dispositivos, genere un token de SaS por dispositivo cuyo ámbito sea un único publicador.

Habilitar la autenticación multifactor de Microsoft Entra para administradores de Azure

Título	Detalles
Componente	Límites de confianza de Azure
Fase de SDL	Implementación
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	¿Qué es la autenticación multifactor de Microsoft Entra?
Pasos	la autenticación multifactor (MFA) es un método de autenticación que requiere más de un método de verificación y agrega una segunda capa crítica de seguridad a los inicios de sesión y transacciones del usuario. Funciona mediante la solicitud de dos o más de los siguientes métodos de verificación: Un elemento que conoce (normalmente una contraseña). Algo que usted tiene (un dispositivo de confianza que no se puede duplicar fácilmente, como un teléfono). Un elemento físico que le identifica (biométrica).

Restricción del acceso anónimo al clúster de Service Fabric

Título	Detalles
Componente	Límites de confianza de Service Fabric
Fase de SDL	Implementación
Tecnologías aplicables	Genérico
Atributos	Entorno: Azure
Referencias	Escenarios de seguridad de los clústeres de Service Fabric
Pasos	Los clústeres siempre deben estar protegidos para evitar que usuarios no autorizados se conecten a su clúster, especialmente cuando en él se están ejecutando cargas de trabajo de producción. Al crear un clúster de Service Fabric, asegúrese de que el modo de seguridad esté establecido en "seguro" y configure el certificado de servidor X.509 necesario. La creación de un clúster "poco seguro" que expone puntos de conexión de administración en la red pública de Internet permitirá que cualquier usuario anónimo se conecte a él.

Asegurarse de que el certificado de cliente a nodo de Service Fabric sea diferente del certificado de nodo a nodo

Título	Detalles
Componente	Límites de confianza de Service Fabric
Fase de SDL	Implementación
Tecnologías aplicables	Genérico
Atributos	Entorno: Azure, Entorno: independiente
Referencias	Seguridad de certificado de cliente a nodo de Service Fabric, Conexión a un clúster seguro mediante certificados de cliente
Pasos	La seguridad basada en certificados de cliente a nodo se configura al crear el clúster mediante Azure Portal, las plantillas de Resource Manager o una plantilla JSON independiente, especificando un certificado de cliente de administración y uno de cliente de usuario. Los certificados de cliente de administración y de cliente de usuario que especifique deben ser diferentes de los certificados principales y secundarios que determine para la seguridad de nodo a nodo.

Uso de Microsoft Entra ID para autenticar clientes en clústeres de Service Fabric

Título	Detalles
Componente	Límites de confianza de Service Fabric
Fase de SDL	Implementación
Tecnologías aplicables	Genérico
Atributos	Entorno: Azure
Referencias	Escenarios de seguridad de los clústeres de Service Fabric
Pasos	Los clústeres que se ejecutan en Azure también pueden proteger el acceso a los puntos de conexión de administración con Microsoft Entra ID, aparte de los certificados de cliente. En el caso de los clústeres de Azure, se recomienda usar la seguridad de Microsoft Entra para autenticar clientes y certificados para la seguridad de nodo a nodo.

Asegurarse de que los certificados de Service Fabric se obtienen de una entidad de certificación (CA) aprobada

Título	Detalles
Componente	Límites de confianza de Service Fabric
Fase de SDL	Implementación
Tecnologías aplicables	Genérico
Atributos	Entorno: Azure
Referencias	Certificados X.509 y Service Fabric
Pasos	Service Fabric usa certificados de servidor X.509 para autenticar nodos y clientes. Algunos aspectos a tener en cuenta al usar certificados en Service Fabric: Los certificados usados en clústeres que ejecutan cargas de trabajo de producción deberán crearse mediante un servicio de certificados de Windows Server correctamente configurado u obtenerse de una entidad de certificación (CA) autorizada. La entidad de certificación puede ser una CA externa aprobada o una infraestructura de clave pública (PKI) interna administrada correctamente. No use nunca certificados temporales o de pruebas en producción creados con herramientas como MakeCert.exe. Puede usar un certificado autofirmado, pero solo para clústeres de prueba y no para los que se encuentran en fase de producción.

Uso de escenarios de autenticación estándar admitidos por Identity Server

Título	Detalles
Componente	Identity Server
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	IdentityServer3: The Big Picture (IdentityServer3: el panorama global)
Pasos	A continuación se muestran las interacciones habituales admitidas por Identity Server: Los exploradores se comunican con las aplicaciones web. Las aplicaciones web se comunican con las API web (unas veces por sí mismas y otras en nombre de un usuario). Las aplicaciones basadas en explorador se comunican con las API web. Las aplicaciones nativas se comunican con las API web. Las aplicaciones basadas en servidor se comunican con las API web. Las API web se comunican con las API web (una veces por sí mismas y otras en nombre del usuario).

Reemplazo de la caché de tokens predeterminada de Identity Server por una alternativa escalable

Título	Detalles
Componente	Identity Server
Fase de SDL	Implementación
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	Identity Server Deployment - Caching (Identity Server: implementación y almacenamiento en caché)
Pasos	IdentityServer incorpora una caché en memoria sencilla. Aunque esta caché es buena para aplicaciones nativas a pequeña escala, no se amplía para aplicaciones de back-end y nivel intermedio por los siguientes motivos: Muchos usuarios acceden a la vez a estas aplicaciones. Como todos los tokens de acceso se guardan en el mismo almacén, se crean problemas de aislamiento y surgen dificultades al funcionar a escala: un número elevado de usuarios, cada uno con tantos tokens como recursos a los que la aplicación accede en su nombre, puede traducirse en cifras enormes y operaciones de búsqueda costosas. Estas aplicaciones se implementan normalmente en topologías distribuidas, donde varios nodos deben tener acceso a la misma caché Los tokens almacenados en caché deben sobrevivir a los reciclajes y las desactivaciones de los procesos. Por todas estas razones, al implementar aplicaciones web, se recomienda reemplazar la memoria caché de tokens predeterminada de Identity Server por una alternativa escalable, como Azure Cache for Redis.

Asegurarse de que los archivos binarios de la aplicación implementada están firmados digitalmente

Título	Detalles
Componente	Límite de confianza de la máquina
Fase de SDL	Implementación
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	N/D
Pasos	Asegúrese de que los archivos binarios de la aplicación implementada estén firmados digitalmente para que se pueda comprobar su integridad.

Habilitación de la autenticación al conectarse a las colas MSMQ en WCF

Título	Detalles
Componente	WCF
Fase de SDL	Build
Tecnologías aplicables	Genérico, .NET Framework 3
Atributos	N/D
Referencias	MSDN
Pasos	Si un programa no puede habilitar la autenticación al conectarse a colas MSMQ, un atacante podría enviar mensajes de forma anónima a la cola para procesarlos. Si no se usa autenticación para conectarse a una cola MSMQ que se utiliza para entregar un mensaje a otro programa, un atacante podría enviar un mensaje anónimo malintencionado.

Ejemplo

El elemento <netMsmqBinding/> del archivo de configuración de WCF siguiente indica a WCF que deshabilite la autenticación al conectarse a una cola MSMQ para la entrega de mensajes.

<bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""None"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

Configure MSMQ para que exija la autenticación de dominios o certificados de Windows cada vez que entre o salga algún mensaje.

Ejemplo

El elemento <netMsmqBinding/> del archivo de configuración de WCF siguiente indica a WCF que habilite la autenticación mediante certificado al conectarse a una cola MSMQ. El cliente se autentica mediante certificados X.509. El certificado de cliente debe estar presente en el almacén de certificados del servidor.

<bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""Certificate"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

No establecer clientCredentialType de WCF en Ninguno

Título	Detalles
Componente	WCF
Fase de SDL	Build
Tecnologías aplicables	.NET Framework 3
Atributos	ClientCredentialType: Ninguno
Referencias	MSDN, Fortify
Pasos	La ausencia de autenticación significa que todo el mundo puede acceder a este servicio. Un servicio que no autentica a sus clientes permite el acceso a todos los usuarios. Configure la aplicación para autenticarse con credenciales de cliente. Para ello, establezca el mensaje clientCredentialType en Windows o Certificado.

Ejemplo

<message clientCredentialType=""Certificate""/>

No establecer Transport clientCredentialType de WCF en Ninguno

Título	Detalles
Componente	WCF
Fase de SDL	Build
Tecnologías aplicables	Genérico, .NET Framework 3
Atributos	ClientCredentialType: Ninguno
Referencias	MSDN, Fortify
Pasos	La ausencia de autenticación significa que todo el mundo puede acceder a este servicio. Un servicio que no se autentica a sus clientes permite que todos los usuarios accedan a su funcionalidad. Configure la aplicación para autenticarse con credenciales de cliente. Para ello, establezca el valor de clientCredentialType de transporte en Windows o Certificado.

Ejemplo

<transport clientCredentialType=""Certificate""/>

Asegurarse de que se usan técnicas de autenticación estándar para proteger las API web

Título	Detalles
Componente	API Web
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	Authentication and Authorization in ASP.NET Web API, (Autenticación y autorización en la API web de ASP.NET) External Authentication Services with ASP.NET Web API (C#) (Servicios de autenticación externos con la API web de ASP.NET [C#])
Pasos	La autenticación es el proceso donde una entidad demuestra su identidad, normalmente por medio de credenciales, como un nombre de usuario y una contraseña. Hay varios protocolos de autenticación disponibles que se pueden considerar. A continuación se enumeran algunos de ellos: Certificados de cliente Basado en Windows Basado en formularios Federación - ADFS Federación: Microsoft Entra ID Federación - Identity Server Los vínculos de la sección de referencias proporcionan detalles de bajo nivel sobre cómo se puede implementar cada uno de los esquemas de autenticación para proteger una API web.

Uso de escenarios de autenticación estándar admitidos por Microsoft Entra ID

Título	Detalles
Componente	Microsoft Entra ID
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	Escenarios de autenticación de Microsoft Entra ID, ejemplos de código de Microsoft Entra, guía del desarrollador de Microsoft Entra
Pasos	Microsoft Entra ID simplifica la autenticación para los desarrolladores al proporcionar identidad como servicio, con soporte para protocolos estándar de la industria como OAuth 2.0 y OpenID Connect. A continuación se describen los cinco escenarios de aplicación principales admitidos por Microsoft Entra ID: Navegador Web a Aplicación Web: Un usuario necesita iniciar sesión en una aplicación web protegida por Microsoft Entra ID Aplicación de página única (SPA): un usuario necesita iniciar sesión en una aplicación de página única protegida por Microsoft Entra ID una aplicación nativa que se ejecuta en un teléfono, tableta o equipo necesita autenticar a un usuario para obtener recursos de una API web protegida por Microsoft Entra ID Aplicación web para API web: una aplicación web tiene que obtener recursos de una API web protegida por Microsoft Entra ID Aplicación de servidor o demonio para API web: una aplicación de demonio o de servidor sin interfaz de usuario web tiene que obtener recursos de una API web protegida por Microsoft Entra ID Consulte los vínculos de la sección de referencias para obtener detalles de implementación de bajo nivel.

Reemplazo de la caché de tokens de MSAL predeterminada por una caché distribuida

Título	Detalles
Componente	Microsoft Entra ID
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	Serialización de la caché de tokens en MSAL.NET
Pasos	La caché predeterminada que usa MSAL (Biblioteca de autenticación de Microsoft) es una caché escalable en memoria. Sin embargo, se puede usar diferentes opciones como alternativa, como por ejemplo, una caché de tokens distribuidos. Estos tienen mecanismos L1/L2, donde L1 está en memoria y L2 es la implementación de caché distribuida. Se pueden configurar en consecuencia para limitar la memoria L1, cifrar o establecer directivas de expulsión. Otras alternativas incluyen las cachés de Redis, SQL Server o Azure Cosmos DB. Puede encontrar una implementación de una caché de tokens distribuida en Tutorial: Introducción a ASP.NET Core MVC.

Garantía de que TokenReplayCache se usa para impedir la reproducción de tokens de autenticación de MSAL

Título	Detalles
Componente	Microsoft Entra ID
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	Autenticación moderna con Microsoft Entra ID para aplicaciones web
Pasos	La propiedad TokenReplayCache permite a los desarrolladores definir una caché de reproducción de tokens, un almacén que se puede usar para guardar tokens con el fin de comprobar que ningún token se pueda usar más de una vez. Esta es una medida contra un ataque habitual, el llamado acertadamente ataque de reproducción de tokens: un atacante que intercepta el token enviado al inicio de sesión podría enviarlo de nuevo a la aplicación ("reproducirlo") para establecer una nueva sesión. Por ejemplo, en el flujo de concesión de código de OIDC, tras la autenticación correcta del usuario, se realiza una solicitud al punto de conexión "/signin-oidc" del usuario de confianza con los parámetros "id_token", "code" y "state". El usuario de confianza valida esta solicitud y establece una nueva sesión. Si un adversario captura esta solicitud y la reproduce, podría establecer correctamente una sesión y suplantar al usuario. La presencia del valor de seguridad nonce de OpenID Connect puede limitar, pero no eliminar totalmente, las circunstancias en las que el ataque se puede aprobar correctamente. Para proteger sus aplicaciones, los desarrolladores pueden proporcionar una implementación de ITokenReplayCache y asignar una instancia a TokenReplayCache.

Ejemplo

// ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}

Ejemplo

Este es un ejemplo de implementación de la interfaz ITokenReplayCache. (Personalice e implemente el marco de almacenamiento en caché específico del proyecto).

public class TokenReplayCache : ITokenReplayCache
{
    private readonly ICacheProvider cache; // Your project-specific cache provider
    public TokenReplayCache(ICacheProvider cache)
    {
        this.cache = cache;
    }
    public bool TryAdd(string securityToken, DateTime expiresOn)
    {
        if (this.cache.Get<string>(securityToken) == null)
        {
            this.cache.Set(securityToken, securityToken);
            return true;
        }
        return false;
    }
    public bool TryFind(string securityToken)
    {
        return this.cache.Get<string>(securityToken) != null;
    }
}

Se debe hacer referencia a la caché implementada en las opciones de OIDC mediante la propiedad "TokenValidationParameters", como se indica a continuación.

OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
    AutomaticAuthenticate = true,
    ... // other configuration properties follow..
    TokenValidationParameters = new TokenValidationParameters
    {
        TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
    }
}

Tenga en cuenta que para probar la eficacia de esta configuración, debe iniciar sesión en la aplicación local protegida por OIDC y capturar la solicitud al punto de conexión "/signin-oidc" en Fiddler. Cuando la protección no está implementada, la reproducción de esta solicitud en Fiddler establecerá una nueva cookie de sesión. Cuando la solicitud se reproduce después de agregar la protección de TokenReplayCache, la aplicación producirá una excepción de la manera siguiente:SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1.......

Usar bibliotecas de MSAL para administrar solicitudes de token de clientes de OAuth2 a Microsoft Entra ID (o AD local)

Título	Detalles
Componente	Microsoft Entra ID
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	MSAL
Pasos	La Biblioteca de autenticación de Microsoft (MSAL) permite que los desarrolladores adquieran tokens de seguridad desde la Plataforma de identidad de Microsoft para autenticar usuarios y acceder a API web protegidas. Se puede usar para ofrecer acceso seguro a Microsoft Graph, otras API de Microsoft, API web de terceros o su propia API web. MSAL es compatible con muchas arquitecturas y plataformas de aplicación distintas, incluidas .NET, JavaScript, Java, Python, Android e iOS.

MSAL ofrece varias formas de obtener tokens, con una API coherente para muchas plataformas. No es necesario usar directamente las bibliotecas o el código de OAuth en el protocolo de la aplicación y puede adquirir tokens en nombre de un usuario o aplicación (cuando sea aplicable a la plataforma).

MSAL también mantiene una caché de tokens y actualiza los tokens de forma automática cuando se acerca su expiración. MSAL también puede ayudarle a especificar qué audiencia quiere que la aplicación inicie sesión, así como a configurar la aplicación a partir de archivos de configuración y solucionar problemas de la aplicación.

Autenticación de los dispositivos que se conectan a la puerta de enlace de campo

Título	Detalles
Componente	Puerta de enlace de campo de IoT
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	N/D
Pasos	Asegúrese de que cada dispositivo se autentica en la puerta de enlace de campo antes de aceptar datos de ellos y antes de facilitar las comunicaciones ascendentes con la puerta de enlace de nube. Además, asegúrese de que los dispositivos se conectan con una credencial cada uno de forma que cada dispositivo se pueda identificar de manera unívoca.

Asegurarse de que se autentican los dispositivos que se conectan a la puerta de enlace de nube

Título	Detalles
Componente	Puerta de enlace de la nube de IoT
Fase de SDL	Build
Tecnologías aplicables	Genérico, C#, Node.js,
Atributos	N/D, opción de puerta de enlace: Azure IoT Hub
Referencias	N/D, Introducción a Azure IoT Hub (.NET), Introducción a Azure IoT Hub (Node), Protección de IoT con SAS y certificados, Repositorio de GIT
Pasos	Genérico: autenticación del dispositivo mediante Seguridad de la capa de transporte (TLS) o IPSec. La infraestructura debe admitir el uso de una clave precompartida (PSK) en los dispositivos que no pueden controlar la criptografía asimétrica completa. Aproveche Microsoft Entra ID, OAuth. C#: al crear una instancia de DeviceClient, el método Create crea de forma predeterminada una instancia de DeviceClient que usa el protocolo AMQP para comunicarse con IoT Hub. Para usar el protocolo HTTPS, utilice la invalidación del método Create que permite especificar el protocolo. Si usa el protocolo HTTPS, también debe agregar el paquete NuGet Microsoft.AspNet.WebApi.Client al proyecto para incluir el espacio de nombres System.Net.Http.Formatting.

Ejemplo

static DeviceClient deviceClient;

static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";

var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));

deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));

await deviceClient.SendEventAsync(message);

Ejemplo

Node.js: autenticación

Clave simétrica

• Cree un centro de IoT en Azure.
• Cree una entrada en el Registro de identidad de dispositivo:

  var device = new iothub.Device(null);
  device.deviceId = <DeviceId >
  registry.create(device, function(err, deviceInfo, res) {})
  

• Cree un dispositivo simulado:

  var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
  var Message = require('azure-iot-device').Message;
  var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>';
  var client = clientFromConnectionString(connectionString);
  

  Token de SAS

• Se genera internamente cuando se usa la clave simétrica pero también se puede generar y usar explícitamente.
• Defina un protocolo:var Http = require('azure-iot-device-http').Http;
• Cree un token de SAS:

  resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
  var deviceName = "<deviceName >";
  var expires = (Date.now() / 1000) + expiresInMins * 60;
  var toSign = resourceUri + '\n' + expires;
  // using crypto
  var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
  const hmac = crypto.createHmac('sha256', decodedPassword);
  hmac.update(toSign);
  var base64signature = hmac.digest('base64');
  var base64UriEncoded = encodeURIComponent(base64signature);
  // construct authorization string
  var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
  + base64UriEncoded + "&se=" + expires;
  if (policyName) token += "&skn="+policyName;
  return token;
  

• Conéctese mediante el token de SAS:

  Client.fromSharedAccessSignature(sas, Http);
  

  Certificados

• Genere un certificado X509 autofirmado con cualquier herramienta como OpenSSL, para generar archivos .cert y .key a fin de almacenar el certificado y la clave respectivamente.
• Aprovisione un dispositivo que acepte conexiones seguras mediante certificados.

  var connectionString = '<connectionString>';
  var registry = iothub.Registry.fromConnectionString(connectionString);
  var deviceJSON = {deviceId:"<deviceId>",
  authentication: {
      x509Thumbprint: {
      primaryThumbprint: "<PrimaryThumbprint>",
      secondaryThumbprint: "<SecondaryThumbprint>"
      }
  }}
  var device = deviceJSON;
  registry.create(device, function (err) {});
  

• Conecte un dispositivo mediante un certificado.

  var Protocol = require('azure-iot-device-http').Http;
  var Client = require('azure-iot-device').Client;
  var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>x509=true';
  var client = Client.fromConnectionString(connectionString, Protocol);
  var options = {
      key: fs.readFileSync('./key.pem', 'utf8'),
      cert: fs.readFileSync('./server.crt', 'utf8')
  };
  // Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
  client.setOptions(options);
  //call fn to execute after the connection is set up
  client.open(fn);
  

Uso de credenciales de autenticación por dispositivo

Título	Detalles
Componente	Puerta de enlace de la nube de IoT
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	Elección de puerta de enlace: Azure IoT Hub
Referencias	Tokens de seguridad de Azure IoT Hub
Pasos	Use credenciales de autenticación por dispositivo mediante tokens de SaS basados en la clave de dispositivo y el certificado de cliente, en lugar de directivas de acceso compartido de nivel de IoT Hub. Así evitará la reutilización de tokens de autenticación entre dispositivos o puertas de enlace de campo.

Asegurarse de que solo los contenedores y blobs requeridos reciben acceso anónimo de lectura

Título	Detalles
Componente	Azure Storage
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	StorageType: blob
Referencias	Administración del acceso de lectura anónimo a contenedores y blobs, Firmas de acceso compartido, Parte 1: Descripción del modelo SAS
Pasos	De manera predeterminada, solamente el dueño de la cuenta de almacenamiento puede obtener acceso a un contenedor y a todos los blobs en su interior. Para dar a los usuarios anónimos permisos de lectura para un contenedor y sus blobs, puede establecer los permisos del contenedor de forma que se permita el acceso público. Los usuarios anónimos pueden leer los blobs que estén en un contenedor con acceso público sin necesidad de tener que autenticar la solicitud. Los contenedores ofrecen las siguientes opciones para administrar el acceso al contenedor: Acceso total de lectura público: los datos del contenedor y de los blobs se pueden leer mediante una solicitud anónima. Los clientes pueden enumerar los blobs del contenedor a través de una solicitud anónima, pero no pueden enumerar los contenedores que están en la cuenta de almacenamiento. Acceso de lectura público solo para blobs: Los datos de blob dentro de este contenedor pueden leerse a través de una solicitud anónima, pero los datos del contenedor no están disponibles. Los clientes no pueden enumerar los blobs incluidos en el contenedor mediante una solicitud anónima. Acceso de lectura no público: el propietario de la cuenta es el único que puede leer los datos del contenedor y de los blobs El acceso anónimo es mejor para escenarios donde ciertos blobs deben estar siempre disponibles para el acceso de lectura anónimo. Para un control más específico, puede crear una firma de acceso compartido, que permite delegar el acceso restringido mediante permisos diferentes y en un intervalo de tiempo especificado. Asegúrese de que los contenedores y los blobs, que podrían contener datos confidenciales, no tengan acceso anónimo por accidente.

Concesión de acceso limitado a objetos de Azure Storage mediante SAS o SAP

Título	Detalles
Componente	Azure Storage
Fase de SDL	Build
Tecnologías aplicables	Genérico
Atributos	N/D
Referencias	Firmas de acceso compartido, Parte 1: Comprender el modelo SAS, Firmas de acceso compartido, Parte 2: Creación y uso de una SAS con Blob Storage, Delegación del acceso a objetos en la cuenta mediante Firmas de acceso compartido y Directivas de acceso almacenadas
Pasos	El uso de una firma de acceso compartido (SAS) es una manera eficaz de conceder acceso limitado a los objetos de una cuenta de almacenamiento a otros clientes sin tener que exponer la clave de acceso de la cuenta. La SAS es un URI que incluye en sus parámetros de consulta toda la información necesaria para el acceso autenticado a un recurso de almacenamiento. Para obtener acceso a los recursos de almacenamiento con la SAS, el cliente solo tiene que pasar la SAS al método o constructor adecuados. Puede usar una SAS cuando desee proporcionar acceso a los recursos en la cuenta de almacenamiento a un cliente al que no se puede confiar la clave de cuenta. Las claves de cuenta de almacenamiento incluyen una clave primaria y secundaria, que conceden acceso administrativo a la cuenta y a todos los recursos contenidos en ella. La exposición de alguna de las claves de cuenta hace que exista la posibilidad de que se haga un uso negligente o malintencionado de la cuenta. Las firmas de acceso compartido ofrecen una alternativa segura que permite a los demás clientes leer, escribir y eliminar datos en la cuenta de almacenamiento según los permisos que se le hayan concedido y sin que sea necesaria la clave de cuenta. Si tiene un conjunto lógico de parámetros que son siempre parecidos, es mejor usar una directiva de acceso almacenado (SAP). Dado que el uso de una Firma de acceso compartido derivada de una Directiva de acceso almacenada ofrece la posibilidad de revocar esa firma de acceso compartido de inmediato, se recomienda usar siempre las Directivas de acceso almacenadas cuando sea posible.