Quadro de segurança: Autenticação | Atenuações

Produto/Serviço	Artigo
Aplicação Web	Considere o uso de um mecanismo de autenticação padrão para autenticar no aplicativo Web Os aplicativos devem lidar com cenários de falha de autenticação com segurança Habilite a autenticação escalonada ou adaptável Garantir que as interfaces administrativas estejam adequadamente bloqueadas Implemente funcionalidades de senha esquecida com segurança Certifique-se de que a senha e a política de conta sejam implementadas Implementar controles para evitar a enumeração de nome de usuário
Base de dados	Quando possível, use a Autenticação do Windows para se conectar ao SQL Server Quando possível, use a autenticação do Microsoft Entra para conectar-se ao Banco de Dados SQL Quando o modo de autenticação SQL for usado, verifique se a política de conta e senha é imposta no SQL Server Não use a Autenticação SQL em bancos de dados contidos
Hub de Eventos do Azure	Usar credenciais de autenticação por dispositivo usando tokens SaS
Limite de Confiança do Azure	Habilitar a autenticação multifator do Microsoft Entra para administradores do Azure
Limite de confiança do Service Fabric	Restringir o acesso anônimo ao Cluster do Service Fabric Verifique se o certificado de cliente para nó do Service Fabric é diferente do certificado de nó para nó Usar o Microsoft Entra ID para autenticar clientes em clusters de malha de serviço Verifique se os certificados do service fabric são obtidos de uma autoridade de certificação (CA) aprovada
Servidor de identidade	Usar cenários de autenticação padrão suportados pelo Identity Server Substitua o cache de token padrão do Identity Server por uma alternativa escalável
Limite de confiança da máquina	Garantir que os binários do aplicativo implantado sejam assinados digitalmente
WCF	Habilite a autenticação ao se conectar a filas MSMQ no WCF WCF-Não defina Message clientCredentialType como none WCF-Não defina Transport clientCredentialType como none
API Web	Certifique-se de que as técnicas de autenticação padrão sejam usadas para proteger APIs da Web
Microsoft Entra ID	Usar cenários de autenticação padrão suportados pelo Microsoft Entra ID Substituir o cache de token MSAL padrão por um cache distribuído Certifique-se de que TokenReplayCache seja usado para impedir a repetição de tokens de autenticação de entrada Use bibliotecas MSAL para gerenciar solicitações de token de clientes OAuth2 para o Microsoft Entra ID (ou AD local)
Gateway de campo IoT	Autenticar dispositivos que se conectam ao Field Gateway
Gateway de nuvem IoT	Certifique-se de que os dispositivos que se conectam ao gateway de nuvem sejam autenticados Usar credenciais de autenticação por dispositivo
Armazenamento do Azure	Certifique-se de que apenas os contêineres e blobs necessários recebam acesso de leitura anônimo Conceder acesso limitado a objetos no armazenamento do Azure usando SAS ou SAP

Considere o uso de um mecanismo de autenticação padrão para autenticar no aplicativo Web

Título	Detalhes
Componente	Aplicação Web
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	N/A
Detalhes	A autenticação é o processo em que uma entidade prova a sua identidade, normalmente através de credenciais, como um nome de utilizador e uma palavra-passe. Existem vários protocolos de autenticação disponíveis que podem ser considerados. Alguns deles estão listados abaixo: Certificados de cliente Baseado em Windows Baseado em formulários Federação - ADFS Federação - Microsoft Entra ID Federação - Servidor de Identidade Considere o uso de um mecanismo de autenticação padrão para identificar o processo de origem

Os aplicativos devem lidar com cenários de falha de autenticação com segurança

Título	Detalhes
Componente	Aplicação Web
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	N/A
Detalhes	Os aplicativos que autenticam explicitamente os usuários devem lidar com cenários de falha de autenticação com segurança. O mecanismo de autenticação deve: Negar acesso a recursos privilegiados quando a autenticação falhar Exibir uma mensagem de erro genérica após a falha na autenticação e o acesso negado ocorrerem Teste para: Proteção de recursos privilegiados após logins com falha Uma mensagem de erro genérica é exibida no(s) evento(s) de autenticação com falha e acesso negado(s) As contas são desativadas após um número excessivo de tentativas falhadas

Habilite a autenticação escalonada ou adaptável

Título	Detalhes
Componente	Aplicação Web
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	N/A
Detalhes	Verifique se o aplicativo tem autorização adicional (como autenticação step-up ou adaptável, via autenticação multifator, como envio de OTP em SMS, e-mail, etc. ou solicitação de reautenticação) para que o usuário seja desafiado antes de ter acesso a informações confidenciais. Esta regra também se aplica para fazer alterações críticas em uma conta ou ação Isso também significa que a adaptação da autenticação deve ser implementada de tal forma que o aplicativo aplique corretamente a autorização sensível ao contexto, de modo a não permitir a manipulação não autorizada por meio de, por exemplo, adulteração de parâmetros

Garantir que as interfaces administrativas estejam adequadamente bloqueadas

Título	Detalhes
Componente	Aplicação Web
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	N/A
Detalhes	A primeira solução é conceder acesso apenas a partir de um determinado intervalo de IP de origem para a interface administrativa. Se essa solução não for possível, é sempre recomendável impor uma autenticação escalonada ou adaptável para fazer login na interface administrativa

Implemente funcionalidades de senha esquecida com segurança

Título	Detalhes
Componente	Aplicação Web
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	N/A
Detalhes	A primeira coisa é verificar se a senha esquecida e outros caminhos de recuperação enviam um link incluindo um token de ativação por tempo limitado, em vez da senha em si. Autenticação adicional baseada em soft-tokens (por exemplo, token SMS, aplicativos móveis nativos, etc.) também pode ser necessária antes que o link seja enviado. Em segundo lugar, você não deve bloquear a conta de usuários enquanto o processo de obtenção de uma nova senha estiver em andamento. Isso pode levar a um ataque de negação de serviço sempre que um invasor decide bloquear intencionalmente os usuários com um ataque automatizado. Em terceiro lugar, sempre que a nova solicitação de senha foi definida em andamento, a mensagem exibida deve ser generalizada para evitar a enumeração de nome de usuário. Em quarto lugar, sempre não permita o uso de senhas antigas e implemente uma política de senha forte.

Certifique-se de que a senha e a política de conta sejam implementadas

Título	Detalhes
Componente	Aplicação Web
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	N/A
Detalhes	Senha e política de conta em conformidade com a política organizacional e melhores práticas devem ser implementadas. Para se defender contra a força bruta e adivinhação baseada em dicionário: A política de senha forte deve ser implementada para garantir que os usuários criem senhas complexas (por exemplo, comprimento mínimo de 12 caracteres, caracteres alfanuméricos e especiais). As políticas de bloqueio de conta podem ser implementadas da seguinte maneira: Bloqueio suave: Esta pode ser uma boa opção para proteger seus usuários contra ataques de força bruta. Por exemplo, sempre que o usuário digita uma senha errada três vezes, o aplicativo pode bloquear a conta por um minuto, a fim de retardar o processo de forçar sua senha, tornando menos lucrativo para o invasor prosseguir. Se você implementasse contramedidas rígidas de bloqueio para este exemplo, conseguiria um "DoS" bloqueando permanentemente as contas. Alternativamente, o aplicativo pode gerar uma OTP (One Time Password) e enviá-la fora de banda (através de e-mail, sms etc.) para o usuário. Outra abordagem pode ser implementar o CAPTCHA depois que um número limite de tentativas fracassadas for atingido. Bloqueio rígido: Este tipo de bloqueio deve ser aplicado sempre que você detetar um usuário atacando seu aplicativo e combatê-lo por meio do bloqueio permanente de sua conta até que uma equipe de resposta tenha tempo de fazer sua perícia. Após este processo, você pode decidir devolver a conta ao usuário ou tomar outras medidas legais contra ele. Esse tipo de abordagem impede que o invasor penetre ainda mais em seu aplicativo e infraestrutura. Para se defender contra ataques a contas padrão e previsíveis, verifique se todas as chaves e senhas são substituíveis e são geradas ou substituídas após o tempo de instalação. Se o aplicativo tiver que gerar senhas automaticamente, certifique-se de que as senhas geradas sejam aleatórias e tenham alta entropia.

Implementar controles para evitar a enumeração de nome de usuário

Título	Detalhes
Componente	Aplicação Web
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	N/A
Passos	Todas as mensagens de erro devem ser generalizadas para evitar a enumeração de nome de usuário. Além disso, às vezes, você não pode evitar o vazamento de informações em funcionalidades como uma página de registro. Aqui você precisa usar métodos de limitação de taxa como CAPTCHA para evitar um ataque automatizado por um invasor.

Quando possível, use a Autenticação do Windows para se conectar ao SQL Server

Título	Detalhes
Componente	Base de Dados
Fase SDL	Compilar
Tecnologias aplicáveis	No local
Atributos	Versão SQL - Todos
Referências	SQL Server - Escolha um modo de autenticação
Passos	A Autenticação do Windows usa o protocolo de segurança Kerberos, fornece imposição de diretiva de senha em relação à validação de complexidade para senhas fortes, fornece suporte para bloqueio de conta e oferece suporte à expiração de senha.

Quando possível, use a autenticação do Microsoft Entra para conectar-se ao Banco de Dados SQL

Título	Detalhes
Componente	Base de Dados
Fase SDL	Compilar
Tecnologias aplicáveis	SQL Azure
Atributos	Versão SQL - V12
Referências	Conectando-se ao Banco de Dados SQL usando a autenticação do Microsoft Entra
Passos	Versão mínima: Banco de Dados SQL do Azure V12 necessário para permitir que o Banco de Dados SQL do Azure use a autenticação do Microsoft Entra no Microsoft Directory

Quando o modo de autenticação SQL for usado, verifique se a política de conta e senha é imposta no SQL Server

Título	Detalhes
Componente	Base de Dados
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	Política de senha do SQL Server
Passos	Ao usar a Autenticação do SQL Server, logons são criados no SQL Server que não se baseiam em contas de usuário do Windows. O nome de usuário e a senha são criados usando o SQL Server e armazenados no SQL Server. O SQL Server pode utilizar mecanismos de política de palavras-passe do Windows. Ele pode aplicar a mesma complexidade e políticas de expiração usadas no Windows a senhas usadas dentro do SQL Server.

Não use a Autenticação SQL em bancos de dados contidos

Título	Detalhes
Componente	Base de Dados
Fase SDL	Compilar
Tecnologias aplicáveis	Local, SQL Azure
Atributos	Versão SQL - MSSQL2012, Versão SQL - V12
Referências	Práticas recomendadas de segurança com bancos de dados contidos
Passos	A ausência de uma política de senha imposta pode aumentar a probabilidade de uma credencial fraca ser estabelecida em um banco de dados contido. Aproveite a Autenticação do Windows.

Usar credenciais de autenticação por dispositivo usando tokens SaS

Título	Detalhes
Componente	Hubs de Eventos do Azure
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	Visão geral do modelo de autenticação e segurança dos Hubs de Eventos
Passos	O modelo de segurança dos Hubs de Eventos é baseado em uma combinação de tokens SAS (Assinatura de Acesso Compartilhado) e editores de eventos. O nome do editor representa o DeviceID que recebe o token. Isso ajudaria a associar os tokens gerados aos respetivos dispositivos. Todas as mensagens são marcadas com o originador no lado do serviço, permitindo a deteção de tentativas de falsificação de origem na carga útil. Ao autenticar dispositivos, gere um token SaS por dispositivo com escopo para um editor exclusivo.

Habilitar a autenticação multifator do Microsoft Entra para administradores do Azure

Título	Detalhes
Componente	Limite de Confiança do Azure
Fase SDL	Implementação
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	O que é a autenticação multifator Microsoft Entra?
Passos	A autenticação multifator (MFA) é um método de autenticação que requer mais de um método de verificação e adiciona uma segunda camada crítica de segurança aos logins e transações do usuário. Funciona exigindo dois ou mais dos seguintes métodos de verificação: Algo que sabe (normalmente uma palavra-passe) Algo que você tem (um dispositivo confiável que não é facilmente duplicado, como um telefone) Algo que você é (biometria)

Restringir o acesso anônimo ao Cluster do Service Fabric

Título	Detalhes
Componente	Limite de confiança do Service Fabric
Fase SDL	Implementação
Tecnologias aplicáveis	Genérica
Atributos	Ambiente - Azure
Referências	Cenários de segurança de cluster do Service Fabric
Passos	Os clusters devem estar sempre protegidos para impedir que usuários não autorizados se conectem ao cluster, especialmente quando ele tem cargas de trabalho de produção em execução. Ao criar um cluster de malha de serviço, verifique se o modo de segurança está definido como "seguro" e configure o certificado de servidor X.509 necessário. A criação de um cluster "inseguro" permitirá que qualquer usuário anônimo se conecte a ele se ele expor pontos de extremidade de gerenciamento à Internet pública.

Verifique se o certificado de cliente para nó do Service Fabric é diferente do certificado de nó para nó

Título	Detalhes
Componente	Limite de confiança do Service Fabric
Fase SDL	Implementação
Tecnologias aplicáveis	Genérica
Atributos	Ambiente - Azure, Ambiente - Autónomo
Referências	Segurança de certificado de cliente para nó do Service Fabric, conectar-se a um cluster seguro usando o certificado de cliente
Passos	A segurança do certificado de cliente para nó é configurada durante a criação do cluster por meio do portal do Azure, modelos do Gerenciador de Recursos ou um modelo JSON autônomo, especificando um certificado de cliente administrador e/ou um certificado de cliente de usuário. Os certificados de cliente admin e cliente de usuário especificados devem ser diferentes dos certificados primários e secundários especificados para segurança de nó a nó.

Usar o Microsoft Entra ID para autenticar clientes em clusters de malha de serviço

Título	Detalhes
Componente	Limite de confiança do Service Fabric
Fase SDL	Implementação
Tecnologias aplicáveis	Genérica
Atributos	Ambiente - Azure
Referências	Cenários de segurança de cluster - Recomendações de segurança
Passos	Os clusters em execução no Azure também podem proteger o acesso aos pontos de extremidade de gerenciamento usando a ID do Microsoft Entra, além de certificados de cliente. Para clusters do Azure, é recomendável usar a segurança do Microsoft Entra para autenticar clientes e certificados para segurança nó a nó.

Verifique se os certificados do service fabric são obtidos de uma autoridade de certificação (CA) aprovada

Título	Detalhes
Componente	Limite de confiança do Service Fabric
Fase SDL	Implementação
Tecnologias aplicáveis	Genérica
Atributos	Ambiente - Azure
Referências	Certificados X.509 e Service Fabric
Passos	O Service Fabric usa certificados de servidor X.509 para autenticar nós e clientes. Algumas coisas importantes a considerar ao usar certificados em malhas de serviço: Os certificados usados em clusters que executam cargas de trabalho de produção devem ser criados usando um serviço de certificados do Windows Server configurado corretamente ou obtidos de uma Autoridade de Certificação (CA) aprovada. A autoridade de certificação pode ser uma autoridade de certificação externa aprovada ou uma PKI (infraestrutura de chave pública) interna gerenciada adequadamente Nunca use certificados temporários ou de teste em produção criados com ferramentas como MakeCert.exe Você pode usar um certificado autoassinado, mas só deve fazê-lo para clusters de teste e não em produção

Usar cenários de autenticação padrão suportados pelo Identity Server

Título	Detalhes
Componente	Servidor de identidade
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	IdentityServer3 - O panorama geral
Passos	Abaixo estão as interações típicas suportadas pelo Identity Server: Os browsers comunicam com aplicações Web Os aplicativos da Web se comunicam com APIs da Web (às vezes por conta própria, às vezes em nome de um usuário) Aplicativos baseados em navegador se comunicam com APIs da Web Aplicativos nativos se comunicam com APIs da Web Aplicativos baseados em servidor se comunicam com APIs da Web As APIs da Web se comunicam com as APIs da Web (às vezes por conta própria, às vezes em nome de um usuário)

Substitua o cache de token padrão do Identity Server por uma alternativa escalável

Título	Detalhes
Componente	Servidor de identidade
Fase SDL	Implementação
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	Implantação do servidor de identidade - Cache
Passos	O IdentityServer tem um cache interno na memória simples. Embora isso seja bom para aplicativos nativos de pequena escala, ele não é dimensionado para aplicativos de camada intermediária e back-end pelos seguintes motivos: Esses aplicativos são acessados por muitos usuários ao mesmo tempo. Salvar todos os tokens de acesso na mesma loja cria problemas de isolamento e apresenta desafios ao operar em escala: muitos usuários, cada um com tantos tokens quanto os recursos que o aplicativo acessa em seu nome, podem significar grandes números e operações de pesquisa muito caras Esses aplicativos geralmente são implantados em topologias distribuídas, onde vários nós devem ter acesso ao mesmo cache Os tokens armazenados em cache devem sobreviver às reciclagens e desativações do processo Por todos os motivos acima, ao implementar aplicativos Web, é recomendável substituir o cache de token padrão do Servidor de Identidade por uma alternativa escalável, como o Cache Redis do Azure

Garantir que os binários do aplicativo implantado sejam assinados digitalmente

Título	Detalhes
Componente	Limite de confiança da máquina
Fase SDL	Implementação
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	N/A
Passos	Certifique-se de que os binários do aplicativo implantado sejam assinados digitalmente para que a integridade dos binários possa ser verificada

Habilite a autenticação ao se conectar a filas MSMQ no WCF

Título	Detalhes
Componente	WCF
Fase SDL	Compilar
Tecnologias aplicáveis	Genérico, NET Framework 3
Atributos	N/A
Referências	MSDN
Passos	O programa não consegue habilitar a autenticação ao se conectar a filas MSMQ, um invasor pode enviar mensagens anonimamente para a fila para processamento. Se a autenticação não for usada para se conectar a uma fila MSMQ usada para entregar uma mensagem a outro programa, um invasor poderá enviar uma mensagem anônima mal-intencionada.

Exemplo

O <netMsmqBinding/> elemento do arquivo de configuração do WCF abaixo instrui o WCF a desabilitar a autenticação ao se conectar a uma fila MSMQ para entrega de mensagens.

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

Configure o MSMQ para exigir autenticação de Domínio ou Certificado do Windows em todos os momentos para quaisquer mensagens de entrada ou saída.

Exemplo

O <netMsmqBinding/> elemento do arquivo de configuração do WCF abaixo instrui o WCF a habilitar a autenticação de certificado ao se conectar a uma fila MSMQ. O cliente é autenticado usando certificados X.509. O certificado do cliente deve estar presente no armazenamento de certificados do servidor.

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

WCF-Não defina Message clientCredentialType como none

Título	Detalhes
Componente	WCF
Fase SDL	Compilar
Tecnologias aplicáveis	.NET Framework 3
Atributos	Tipo de credencial do cliente - Nenhum
Referências	MSDN, Fortify
Passos	A ausência de autenticação significa que todos podem aceder a este serviço. Um serviço que não autentica seus clientes permite o acesso a todos os usuários. Configure o aplicativo para autenticar com base nas credenciais do cliente. Isso pode ser feito definindo a mensagem clientCredentialType como Windows ou Certificate.

Exemplo

<message clientCredentialType=""Certificate""/>

WCF-Não defina Transport clientCredentialType como none

Título	Detalhes
Componente	WCF
Fase SDL	Compilar
Tecnologias aplicáveis	Genérico, .NET Framework 3
Atributos	Tipo de credencial do cliente - Nenhum
Referências	MSDN, Fortify
Passos	A ausência de autenticação significa que todos podem aceder a este serviço. Um serviço que não autentica os seus clientes permite que todos os utilizadores acedam à sua funcionalidade. Configure o aplicativo para autenticar com base nas credenciais do cliente. Isso pode ser feito definindo o clientCredentialType de transporte como Windows ou Certificate.

Exemplo

<transport clientCredentialType=""Certificate""/>

Certifique-se de que as técnicas de autenticação padrão sejam usadas para proteger APIs da Web

Título	Detalhes
Componente	API da Web
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	Autenticação e Autorização em ASP.NET API Web, Serviços de Autenticação Externa com ASP.NET API Web (C#)
Passos	A autenticação é o processo em que uma entidade prova a sua identidade, normalmente através de credenciais, como um nome de utilizador e uma palavra-passe. Existem vários protocolos de autenticação disponíveis que podem ser considerados. Alguns deles estão listados abaixo: Certificados de cliente Baseado em Windows Baseado em formulários Federação - ADFS Federação - Microsoft Entra ID Federação - Servidor de Identidade Os links na seção de referências fornecem detalhes de baixo nível sobre como cada um dos esquemas de autenticação pode ser implementado para proteger uma API da Web.

Usar cenários de autenticação padrão suportados pelo Microsoft Entra ID

Título	Detalhes
Componente	Microsoft Entra ID
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	Cenários de autenticação para Microsoft Entra ID, exemplos de código do Microsoft Entra, guia do desenvolvedor do Microsoft Entra
Passos	O Microsoft Entra ID simplifica a autenticação para desenvolvedores fornecendo identidade como um serviço, com suporte para protocolos padrão do setor, como OAuth 2.0 e OpenID Connect. Abaixo estão os cinco principais cenários de aplicativos suportados pelo Microsoft Entra ID: Navegador da Web para Aplicativo Web: um usuário precisa entrar em um aplicativo Web protegido pelo ID do Microsoft Entra Aplicativo de página única (SPA): um usuário precisa entrar em um aplicativo de página única protegido pelo ID do Microsoft Entra Aplicativo nativo para API Web: um aplicativo nativo executado em um telefone, tablet ou PC precisa autenticar um usuário para obter recursos de uma API da Web protegida pelo Microsoft Entra ID Aplicativo Web para API Web: um aplicativo Web precisa obter recursos de uma API Web protegida pelo ID do Microsoft Entra Daemon ou Aplicativo de Servidor para API Web: Um aplicativo daemon ou um aplicativo de servidor sem interface de usuário da Web precisa obter recursos de uma API da Web protegida pelo ID do Microsoft Entra Por favor, consulte os links na seção de referências para obter detalhes de implementação de baixo nível

Substituir o cache de token MSAL padrão por um cache distribuído

Título	Detalhes
Componente	Microsoft Entra ID
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	Serialização de cache de token no MSAL.NET
Passos	O cache padrão que a MSAL (Biblioteca de Autenticação da Microsoft) usa é um cache na memória e é escalável. No entanto, há diferentes opções disponíveis que você pode usar como alternativa, como um cache de token distribuído. Estes têm mecanismos L1/L2, onde L1 está na memória e L2 é a implementação de cache distribuído. Estes podem ser configurados de acordo para limitar a memória L1, encriptar ou definir políticas de remoção. Outras alternativas incluem caches de banco de dados Redis, SQL Server ou Azure Comsos. Uma implementação de um cache de token distribuído pode ser encontrada no seguinte Tutorial: Introdução ao ASP.NET Core MVC.

Certifique-se de que TokenReplayCache seja usado para impedir a repetição de tokens de autenticação MSAL

Título	Detalhes
Componente	Microsoft Entra ID
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	Autenticação moderna com o Microsoft Entra ID para aplicativos Web
Passos	A propriedade TokenReplayCache permite que os desenvolvedores definam um cache de repetição de token, um repositório que pode ser usado para salvar tokens com a finalidade de verificar se nenhum token pode ser usado mais de uma vez. Esta é uma medida contra um ataque comum, o apropriadamente chamado ataque de repetição de token: um invasor intercetando o token enviado no login pode tentar enviá-lo para o aplicativo novamente ("replay" it) para estabelecer uma nova sessão. Por exemplo, no fluxo de concessão de código OIDC, após a autenticação bem-sucedida do usuário, uma solicitação para o ponto de extremidade "/signin-oidc" da terceira parte confiável é feita com os parâmetros "id_token", "code" e "state". A terceira parte confiável valida essa solicitação e estabelece uma nova sessão. Se um adversário capturar essa solicitação e reproduzi-la, ele / ela pode estabelecer uma sessão bem-sucedida e falsificar o usuário. A presença do nonce no OpenID Connect pode limitar, mas não eliminar totalmente, as circunstâncias em que o ataque pode ser executado com sucesso. Para proteger seus aplicativos, os desenvolvedores podem fornecer uma implementação de ITokenReplayCache e atribuir uma instância a TokenReplayCache.

Exemplo

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

Exemplo

Aqui está um exemplo de implementação da interface ITokenReplayCache. (Personalize e implemente sua estrutura de cache específica do projeto)

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;
    }
}

O cache implementado deve ser referenciado nas opções OIDC através da propriedade "TokenValidationParameters" da seguinte maneira.

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

Observe que, para testar a eficácia dessa configuração, entre em seu aplicativo local protegido por OIDC e capture a solicitação para o "/signin-oidc" ponto de extremidade no fiddler. Quando a proteção não estiver em vigor, reproduzir esta solicitação no fiddler definirá um novo cookie de sessão. Quando a solicitação é repetida depois que a proteção TokenReplayCache é adicionada, o aplicativo lançará uma exceção da seguinte maneira: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

Use bibliotecas MSAL para gerenciar solicitações de token de clientes OAuth2 para o Microsoft Entra ID (ou AD local)

Título	Detalhes
Componente	Microsoft Entra ID
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	MSAL
Passos	A Biblioteca de Autenticação da Microsoft (MSAL) permite que os desenvolvedores adquiram tokens de segurança da plataforma de identidade da Microsoft para autenticar usuários e acessar APIs da Web seguras. Ele pode ser usado para fornecer acesso seguro ao Microsoft Graph, outras APIs da Microsoft, APIs da Web de terceiros ou sua própria API da Web. O MSAL suporta muitas arquiteturas e plataformas de aplicativos diferentes, incluindo .NET, JavaScript, Java, Python, Android e iOS.

O MSAL oferece muitas maneiras de obter tokens, com uma API consistente para muitas plataformas. Não há necessidade de usar diretamente as bibliotecas OAuth ou código contra o protocolo em seu aplicativo, e pode adquirir tokens em nome de um usuário ou aplicativo (quando aplicável à plataforma).

O MSAL também mantém um cache de tokens e atualiza os tokens para você quando eles estão perto de expirar. O MSAL também pode ajudá-lo a especificar em qual público você deseja que seu aplicativo entre, ajudá-lo a configurar seu aplicativo a partir de arquivos de configuração e solucionar problemas de seu aplicativo.

Autenticar dispositivos que se conectam ao Field Gateway

Título	Detalhes
Componente	Gateway de campo IoT
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	N/A
Passos	Certifique-se de que cada dispositivo é autenticado pelo Field Gateway antes de aceitar dados deles e antes de facilitar as comunicações upstream com o Cloud Gateway. Além disso, certifique-se de que os dispositivos se conectam com uma credencial por dispositivo para que os dispositivos individuais possam ser identificados exclusivamente.

Certifique-se de que os dispositivos que se conectam ao gateway de nuvem sejam autenticados

Título	Detalhes
Componente	Gateway de nuvem IoT
Fase SDL	Compilar
Tecnologias aplicáveis	Genérico, C#, Node.js,
Atributos	N/D, opção de gateway - Hub IoT do Azure
Referências	N/A, Hub IoT do Azure com .NET, Introdução ao hub IoT e ao nó JS, Proteção da IoT com SAS e certificados, repositório Git
Passos	Genérico: autentique o dispositivo usando TLS (Transport Layer Security) ou IPSec. A infraestrutura deve suportar o uso de chave pré-compartilhada (PSK) nos dispositivos que não podem lidar com criptografia assimétrica total. Aproveite o Microsoft Entra ID, OAuth. C#: Ao criar uma instância DeviceClient, por padrão, o método Create cria uma instância DeviceClient que usa o protocolo AMQP para se comunicar com o Hub IoT. Para utilizar o protocolo HTTPS, substitua o método Criar que lhe permite especificar o protocolo. Se você usar o protocolo HTTPS, também deverá adicionar o Microsoft.AspNet.WebApi.Client pacote NuGet ao seu projeto para incluir o System.Net.Http.Formatting namespace.

Exemplo

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);

Exemplo

Node.js: Autenticação

Chave simétrica

• Criar um hub IoT no Azure
• Criar uma entrada no registo de identidade do dispositivo

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

• Criar um 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);
  

  SAS Token

• É gerado internamente ao usar a chave simétrica, mas também podemos gerá-la e usá-la explicitamente
• Definir um protocolo : var Http = require('azure-iot-device-http').Http;
• Crie um token 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;
  

• Conecte-se usando o token sas:

  Client.fromSharedAccessSignature(sas, Http);
  

  Certificados

• Gere um certificado X509 auto-assinado usando qualquer ferramenta como OpenSSL para gerar arquivos .cert e .key para armazenar o certificado e a chave, respectivamente
• Provisione um dispositivo que aceite conexão segura usando 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) {});
  

• Conectar um dispositivo usando um 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);
  

Usar credenciais de autenticação por dispositivo

Título	Detalhes
Componente	Gateway de nuvem IoT
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	Escolha de gateway - Hub IoT do Azure
Referências	Tokens de Segurança do Hub IoT do Azure
Passos	Use credenciais de autenticação por dispositivo usando tokens SaS com base na chave do dispositivo ou no certificado do cliente, em vez de políticas de acesso compartilhado no nível do Hub IoT. Isso impede a reutilização de tokens de autenticação de um dispositivo ou gateway de campo por outro

Certifique-se de que apenas os contêineres e blobs necessários recebam acesso de leitura anônimo

Título	Detalhes
Componente	Armazenamento do Azure
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	StorageType - Blob
Referências	Gerenciar acesso de leitura anônimo a contêineres e blobs, Assinaturas de acesso compartilhado, Parte 1: Noções básicas sobre o modelo SAS
Passos	Por padrão, um contêiner e quaisquer blobs dentro dele podem ser acessados apenas pelo proprietário da conta de armazenamento. Para dar aos usuários anônimos permissões de leitura para um contêiner e seus blobs, pode-se definir as permissões de contêiner para permitir o acesso público. Os usuários anônimos podem ler blobs em um contêiner acessível publicamente sem autenticar a solicitação. Os contêineres fornecem as seguintes opções para gerenciar o acesso ao contêiner: Acesso público completo de leitura: Os dados de contêiner e blob podem ser lidos por meio de solicitação anônima. Os clientes podem enumerar blobs dentro do contêiner por meio de solicitação anônima, mas não podem enumerar contêineres dentro da conta de armazenamento. Acesso público de leitura apenas para blobs: os dados de Blob dentro desse contêiner podem ser lidos por meio de solicitação anônima, mas os dados do contêiner não estão disponíveis. Os clientes não podem enumerar blobs dentro do contêiner por meio de solicitação anônima Sem acesso público de leitura: os dados de contêiner e blob podem ser lidos apenas pelo proprietário da conta O acesso anônimo é melhor para cenários em que determinados blobs devem estar sempre disponíveis para acesso de leitura anônimo. Para um controle mais refinado, pode-se criar uma assinatura de acesso compartilhado, que permite delegar acesso restrito usando permissões diferentes e em um intervalo de tempo especificado. Certifique-se de que contêineres e blobs, que podem potencialmente conter dados confidenciais, não recebam acesso anônimo acidentalmente

Conceder acesso limitado a objetos no armazenamento do Azure usando SAS ou SAP

Título	Detalhes
Componente	Armazenamento do Azure
Fase SDL	Compilar
Tecnologias aplicáveis	Genérica
Atributos	N/A
Referências	Assinaturas de Acesso Compartilhado, Parte 1: Noções básicas sobre o modelo SAS, Assinaturas de acesso compartilhado, Parte 2: Criar e usar uma SAS com armazenamento de Blob, Como delegar acesso a objetos em sua conta usando assinaturas de acesso compartilhado e políticas de acesso armazenado
Passos	Usar uma assinatura de acesso compartilhado (SAS) é uma maneira poderosa de conceder acesso limitado a objetos em uma conta de armazenamento para outros clientes, sem ter que expor a chave de acesso da conta. O SAS é um URI que engloba em seus parâmetros de consulta todas as informações necessárias para o acesso autenticado a um recurso de armazenamento. Para acessar recursos de armazenamento com o SAS, o cliente só precisa passar o SAS para o construtor ou método apropriado. Você pode usar uma SAS quando quiser fornecer acesso a recursos em sua conta de armazenamento para um cliente que não pode ser confiável com a chave da conta. As chaves da sua conta de armazenamento incluem uma chave primária e uma chave secundária, que concedem acesso administrativo à sua conta e a todos os recursos nela contidos. Expor qualquer uma das chaves da sua conta abre a sua conta para a possibilidade de uso malicioso ou negligente. As assinaturas de acesso compartilhado fornecem uma alternativa segura que permite que outros clientes leiam, gravem e excluam dados em sua conta de armazenamento de acordo com as permissões concedidas e sem a necessidade da chave da conta. Se você tiver um conjunto lógico de parâmetros semelhantes a cada vez, usar uma Política de Acesso Armazenado (SAP) é uma ideia melhor. Como o uso de uma SAS derivada de uma Política de Acesso Armazenado oferece a capacidade de revogar essa SAS imediatamente, é a prática recomendada usar sempre as Políticas de Acesso Armazenado quando possível.