Estrutura de segurança: autenticação | Atenuações

Produto/Serviço	Artigo
Aplicativo Web	Considere o uso de um mecanismo de autenticação padrão para autenticação no aplicativo Web Os aplicativos devem lidar com cenários de autenticação com falha com segurança Habilitar upgrade ou autenticação adaptável Verifique se as interfaces administrativas estão adequadamente bloqueadas Implemente funcionalidades de senha esquecida com segurança Verifique se as políticas de conta e senha são implementadas Implemente controles para impedir a enumeração de nome de usuário
Backup de banco 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 se conectar ao Banco de Dados SQL Quando o modo de autenticação do SQL for usado, verifique se as políticas de conta e senha são impostas no SQL server Não usar Autenticação SQL em bancos de dados independentes
Hub de Eventos do Azure	Use 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	Restrinja o acesso anônimo ao Cluster de Service Fabric Verifique se o certificado de cliente para o nó de Service Fabric serviço é diferente do certificado de nó para nó Usar o Microsoft Entra ID para autenticar clientes para clusters do Service Fabric Verifique se os certificados de service fabric são obtidos de uma CA (autoridade de certificação) aprovada
Servidor de identidade	Use cenários de autenticação padrão com suporte no Servidor de Identidade Substitua o cache de token de identidade de servidor padrão por uma alternativa escalonável
Limite de confiança de computador	Verifique se os binários do aplicativo implantado são assinados digitalmente
WCF	Habilite a autenticação ao se conectar às filas MSMQ do WCF WCF - não defina clientCredentialType de mensagem como none WCF - não defina clientCredentialType de transporte como none
API da Web	Verifique se técnicas de autenticação padrão são usadas para proteger as APIs Web
Microsoft Entra ID	Usar cenários de autenticação padrão com suporte no Microsoft Entra ID Substituir o cache de token padrão da MSAL por um cache distribuído Verifique se TokenReplayCache é usado para evitar a repetição de tokens de autenticação de entrada Usar bibliotecas MSAL para gerenciar solicitações de token de clientes OAuth2 ao Microsoft Entra ID (ou AD local)
Gateway de Campo de IoT	Autenticar dispositivos que se conectam ao Gateway de Campo
Gateway de Nuvem IoT	Verifique se os dispositivos conectados ao gateway de nuvem são autenticados Usar credenciais de autenticação por dispositivo
Armazenamento do Azure	Verifique se apenas os contêineres necessários e os blobs recebem acesso de leitura anônimo Conceda acesso limitado a objetos no armazenamento do Azure usando SAS ou SAP

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

Title	Detalhes
Componente	Aplicativo Web
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	N/D
Detalhes	A autenticação é o processo em que uma entidade comprova sua identidade, normalmente por meio de credenciais, como um nome de usuário e uma senha. Há vários protocolos de autenticação disponíveis que podem ser considerados. Alguns deles são listados abaixo: Certificados do cliente Baseado no Windows Baseado em formulários Federação - ADFS Federação – Microsoft Entra ID Federação - Servidor de Identidade Considere usar um mecanismo de autenticação padrão para identificar o processo de origem

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

Title	Detalhes
Componente	Aplicativo Web
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	N/D
Detalhes	Aplicativos que autenticam os usuários explicitamente devem controlar com segurança cenários de autenticação com falha. 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 falha na autenticação e acesso negado Teste de: Proteção de recursos privilegiados após logons com falha Será exibida uma mensagem de erro genérica em evento(s) de autenticação com falha e acesso negado As contas são desabilitadas após um número excessivo de tentativas com falha

Habilitar upgrade ou autenticação adaptável

Title	Detalhes
Componente	Aplicativo Web
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	N/D
Detalhes	Verifique se o aplicativo tem autorização adicional (como autenticação step up ou adaptável, por meio da autenticação multifator, como o envio de OTP por mensagem SMS, email etc. ou solicitação de reautenticação) para que o usuário receba um desafio antes de obter acesso a informações confidenciais. Essa regra também se aplica para fazer alterações importantes em uma conta ou uma ação Isso também significa que a adaptação de autenticação deve ser implementada de forma que o aplicativo imponha corretamente a autorização contextual para não permitir uma manipulação não autorizada por meio de violação de parâmetros, como no exemplo

Verifique se as interfaces administrativas estão adequadamente bloqueadas

Title	Detalhes
Componente	Aplicativo Web
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	N/D
Detalhes	A primeira solução é conceder acesso apenas de determinado intervalo IP de origem para a interface administrativa. Se essa solução não for possível, sempre será recomendável impor uma autenticação step-up ou adaptável para fazer logon na interface administrativa

Implemente funcionalidades de senha esquecida com segurança

Title	Detalhes
Componente	Aplicativo Web
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	N/D
Detalhes	A primeira coisa é verificar se você esqueceu a senha, e outros caminhos de recuperação enviam um link com um token de ativação de tempo limitado, em vez da própria senha. A autenticação adicional com base em tokens de software (por exemplo, token de SMS, aplicativos móveis nativos etc.) também pode ser necessária antes que o link seja enviado. Em segundo lugar, você não deverá bloquear a conta de usuários enquanto o processo de obtenção de uma nova senha estiver em andamento. Isso poderá levar a um ataque de Negação de serviço sempre que um invasor decidir bloquear intencionalmente os usuários com um ataque automatizado. Em terceiro lugar, sempre que a nova solicitação de senha for definida em andamento, a mensagem que será exibida deverá ser generalizada para evitar a enumeração de nome de usuário. Em quarto lugar, sempre proíba o uso de senhas antigas e implemente uma política de senha forte.

Verifique se as políticas de conta e senha são implementadas

Title	Detalhes
Componente	Aplicativo Web
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	N/D
Detalhes	A política de conta e senha em conformidade com a política organizacional e as práticas recomendadas deve ser implementadas. Para proteção contra 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 especiais e alfanuméricos). As políticas de bloqueio de conta podem ser implementadas da seguinte maneira: Limite de bloqueio flexível: essa pode ser uma boa opção para proteger os usuários contra ataques de força bruta. Por exemplo, sempre que o usuário insere uma senha incorreta três vezes, o aplicativo pode bloquear a conta por um minuto para que o processo de obtenção de senha por força bruta fique mais lento, dificultando a continuação do ataque. Se você implementasse contramedidas de bloqueio rígidas nesse exemplo, ocorreria um "DoS" bloqueando as contas permanentemente. Como alternativa, o aplicativo poderá gerar uma OTP (senha única) e enviá-la fora de banda (por email, SMS etc.) ao usuário. Outra abordagem pode ser implementar o CAPTCHA depois que um número limite de tentativas com falha é atingido. Bloqueio rígido: esse tipo de bloqueio deverá ser aplicado sempre que você detectar que um usuário está atacando o aplicativo, impedindo-o por meio do bloqueio permanente da conta, até que uma equipe de resposta tenha tempo de fazer a análise forense. Após esse processo, você pode optar por 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 proteger contra ataques em contas previsíveis e padrão, verifique se todas as chaves e senhas são substituíveis e são geradas ou substituídas após a instalação. Se o aplicativo precisar gerar senhas automaticamente, verifique se as senhas geradas são aleatórias e têm alta entropia.

Implemente controles para impedir a enumeração de nome de usuário

Title	Detalhes
Componente	Aplicativo Web
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	N/D
Etapas	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

Title	Detalhes
Componente	Banco de dados
Fase do SDL	Build
Tecnologias aplicáveis	Local
Atributos	Versão do SQL - Todas
Referências	SQL Server - escolher um modo de autenticação
Etapas	A Autenticação do Windows usa o protocolo de segurança Kerberos, fornece imposição de política de senha em relação à validação de complexidade para senhas fortes, além de dar suporte ao bloqueio de contas e à expiração de senhas.

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

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

Quando o modo de autenticação do SQL for usado, verifique se as políticas de conta e senha são impostas no SQL server

Title	Detalhes
Componente	Banco de dados
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	Política de senha do SQL Server
Etapas	Ao usar a Autenticação do SQL Server, são criados logons 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 são armazenados no SQL Server. O SQL Server pode usar mecanismos de política de senha do Windows. Ele pode aplicar a mesma complexidade e as políticas de expiração usadas no Windows para senhas usadas no SQL Server.

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

Title	Detalhes
Componente	Banco de dados
Fase do SDL	Build
Tecnologias aplicáveis	No local, SQL Azure
Atributos	Versão do SQL - MSSQL2012, Versão do SQL - V12
Referências	Práticas recomendadas de segurança com bancos de dados independentes
Etapas	A ausência de uma política de senha imposta poderá aumentar a probabilidade de que uma credencial fraca seja estabelecida em um banco de dados independente. Aproveite a Autenticação do Windows.

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

Title	Detalhes
Componente	Hubs de eventos do Azure
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	Visão geral do modelo de autenticação e segurança dos Hubs de Eventos
Etapas	O modelo de segurança dos Hubs de Eventos se baseia em uma combinação de tokens SAS (Assinatura de Acesso Compartilhado) e de editores de eventos. O nome do publicador representa o DeviceID que recebe o token. Isso ajudaria a associar os tokens gerados aos respectivos dispositivos. Todas as mensagens são marcadas com o originador no lado do serviço, o que permite a detecção de tentativas de falsificação de origem na carga. Na autenticação de dispositivos, gere um token SaS por dispositivo com escopo para um publicador exclusivo.

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

Título	Detalhes
Componente	Limite de Confiança do Azure
Fase do SDL	Implantação
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	O que é a autenticação multifator do Microsoft Entra?
Etapas	a autenticação multifator (MFA) é um método de autenticação que exige mais de um método de verificação e adiciona uma segunda camada crítica a entradas e transações dos usuários. Ela funciona, exigindo dois ou mais dos métodos de verificação a seguir: Algo que você sabe (geralmente uma senha) Algo que você tem (um dispositivo de confiança que não é facilmente duplicado, como um telefone) Algo seu (biometria)

Restrinja o acesso anônimo ao Cluster de Service Fabric

Title	Detalhes
Componente	Limite de confiança do Service Fabric
Fase do SDL	Implantação
Tecnologias aplicáveis	Genérico
Atributos	Ambiente - Azure
Referências	Cenários de segurança do cluster do Service Fabric
Etapas	Os clusters sempre devem ser protegidos para evitar que usuários não autorizados se conectem ao cluster, especialmente quando ele tiver cargas de trabalho de produção em execução. Ao criar um cluster de service fabric, verifique se o modo de segurança está definido como "seguro" e configure o certificado de servidor X.509 necessário. Criar um cluster "inseguro" permitirá que qualquer usuário anônimo se conecte a ele se ele expuser pontos de extremidade de gerenciamento para a Internet pública.

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

Title	Detalhes
Componente	Limite de confiança do Service Fabric
Fase do SDL	Implantação
Tecnologias aplicáveis	Genérico
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 um certificado de cliente
Etapas	A segurança de certificado de cliente para nó é configurada durante a criação do cluster por meio do portal do Azure, dos modelos do Resource Manager ou de um modelo JSON autônomo, especificando um certificado de cliente do administrador e/ou um certificado de cliente do usuário. Os certificados de cliente administrador e certificados de cliente de usuário que você especificar devem ser diferentes dos certificados primários e secundários que você especifica para a Segurança de nó para nó.

Usar o Microsoft Entra ID para autenticar clientes para clusters do Service Fabric

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

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

Title	Detalhes
Componente	Limite de confiança do Service Fabric
Fase do SDL	Implantação
Tecnologias aplicáveis	Genérico
Atributos	Ambiente - Azure
Referências	Certificados X.509 e Service Fabric
Etapas	O Service Fabric usa certificados de servidor X.509 para autenticar clientes e nós. Alguns pontos importantes a considerar ao usar certificados em service fabrics: Os certificados usados em clusters que executam cargas de trabalho de produção devem ser criados por meio de um serviço de certificado do Windows Server configurado corretamente ou obtidos por meio de uma AC (Autoridade de Certificação) aprovada. A CA pode ser uma CA externa aprovada ou um PKI (Public Key Infrastructure) gerenciado adequadamente Nunca use nenhum certificado temporário ou de teste em produção criado com ferramentas como MakeCert.exe Você pode usar um certificado autoassinado, mas deve fazer isso somente para clusters de teste e não em produção

Use cenários de autenticação padrão com suporte no Servidor de Identidade

Title	Detalhes
Componente	Servidor de identidade
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	IdentityServer3 - visão geral
Etapas	Abaixo estão as interações típicas com suporte no Servidor de Identidade: Os navegadores se comunicam com aplicativos Web Os aplicativos Web se comunicam com APIs Web (às vezes, por conta própria e, às vezes, em nome do usuário) Aplicativos baseados em navegador se comunicam com APIs Web Aplicativos nativos se comunicam com APIs Web Aplicativos baseados em servidor se comunicam com APIs Web As APIs Web se comunicam com as APIs Web (às vezes, por conta própria e, às vezes, em nome do usuário)

Substitua o cache de token de identidade de servidor padrão por uma alternativa escalonável

Title	Detalhes
Componente	Servidor de identidade
Fase do SDL	Implantação
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	Implantação de Servidor de Identidade - cache
Etapas	IdentityServer tem um cache na memória interno simples. Embora seja adequado 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 vários usuários simultaneamente. Salvar todos os tokens de acesso no mesmo repositório cria problemas de isolamento e apresenta desafios ao operar em grande escala: vários usuários, cada um com o mesmo número de tokens que os recursos que o aplicativo acessa em seu nome, podem significar numerosas operações de pesquisa muito caras Esses aplicativos normalmente são implantados em topologias distribuídas, em que vários nós devem ter acesso ao mesmo cache Os tokens em cache devem sobreviver a desativações e reciclagem de processo Por todos os motivos acima, durante a implementação de aplicativos Web, é recomendável substituir o cache de token padrão do Identity Server por uma alternativa escalonável como o Cache do Azure para Redis

Verifique se os binários do aplicativo implantado são assinados digitalmente

Title	Detalhes
Componente	Limite de confiança de máquina
Fase do SDL	Implantação
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	N/D
Etapas	Verifique se os binários do aplicativo implantado são assinados digitalmente para que seja possível verificar a integridade dos binários

Habilite a autenticação ao se conectar às filas MSMQ do WCF

Title	Detalhes
Componente	WCF
Fase do SDL	Build
Tecnologias aplicáveis	Genérico, NET Framework 3
Atributos	N/D
Referências	MSDN
Etapas	O programa não habilita a autenticação ao conectar-se às filas do MSMQ. Um invasor anônimo pode enviar mensagens à fila para processamento. Se a autenticação não for usada para se conectar a uma fila do MSMQ usada para enviar uma mensagem a outro programa, um invasor poderá enviar uma mensagem anônima mal-intencionada.

Exemplo

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

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

Configure o MSMQ para exigir sempre autenticação de Domínio do Windows ou de Certificado para todas as mensagens de entrada ou saída.

Exemplo

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

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

WCF - não defina clientCredentialType de mensagem como none

Title	Detalhes
Componente	WCF
Fase do SDL	Build
Tecnologias aplicáveis	.NET Framework 3
Atributos	Tipo de Credencial de Cliente - Nenhuma
Referências	MSDN, Fortalecer
Etapas	A ausência de autenticação significa que todos podem acessar o serviço. Um serviço que não autentica seus clientes permite acesso a todos os usuários. Configure o aplicativo para autenticação em relação às credenciais do cliente. Isso pode ser feito definindo a mensagem clientCredentialType para Windows ou Certificado.

Exemplo

<message clientCredentialType=""Certificate""/>

WCF - não defina clientCredentialType de transporte como none

Title	Detalhes
Componente	WCF
Fase do SDL	Build
Tecnologias aplicáveis	Genérico, .NET Framework 3
Atributos	Tipo de Credencial de Cliente - Nenhuma
Referências	MSDN, Fortalecer
Etapas	A ausência de autenticação significa que todos podem acessar o serviço. Um serviço que não autentica seus clientes permite que todos os usuários acessem sua funcionalidade. Configure o aplicativo para autenticação em relação às credenciais do cliente. Isso pode ser feito definindo o transporte clientCredentialType para Windows ou Certificado.

Exemplo

<transport clientCredentialType=""Certificate""/>

Verifique se técnicas de autenticação padrão são usadas para proteger as APIs Web

Title	Detalhes
Componente	API Web
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	Autenticação e Autorização na ASP.NET Web API, Serviços de Autenticação Externa com a API Web do ASP.NET (C#)
Etapas	A autenticação é o processo em que uma entidade comprova sua identidade, normalmente por meio de credenciais, como um nome de usuário e uma senha. Há vários protocolos de autenticação disponíveis que podem ser considerados. Alguns deles são listados abaixo: Certificados do cliente Baseado no 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 Web.

Usar cenários de autenticação padrão com suporte no Microsoft Entra ID

Título	Detalhes
Componente	ID do Microsoft Entra
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	Cenários de autenticação para o Microsoft Entra ID, Exemplos de código do Microsoft Entra, Guia do desenvolvedor do Microsoft Entra
Etapas	O Microsoft Entra ID simplifica a autenticação para os 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 aplicativo com suporte no Microsoft Entra ID: Navegador da Web para Aplicativo Web: um usuário precisa entrar em um aplicativo Web protegido pelo Microsoft Entra ID SPA (aplicativo de página única): um usuário precisa entrar em um aplicativo de página única protegido pelo Microsoft Entra ID 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 Web protegida pelo Microsoft Entra ID Aplicativo Web para API Web: um aplicativo Web precisa obter recursos de uma API Web protegida pelo Microsoft Entra ID Aplicativo de servidor ou daemon para API Web: um aplicativo daemon ou um aplicativo de servidor sem interface do usuário da Web precisa obter recursos de uma API Web protegida pelo Microsoft Entra ID Confira os links na seção de referências para obter detalhes sobre a implementação de nível baixo

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

Title	Detalhes
Componente	ID do Microsoft Entra
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	Serialização do cache de token na MSAL.NET
Etapas	O cache padrão que a MSAL (Biblioteca de Autenticação da Microsoft) usa é um cache na memória e é escalonável. No entanto, há diferentes opções disponíveis que podem ser usadas como alternativa, como um cache de token distribuído. Eles têm mecanismos L1/L2, onde L1 está na memória e L2 é a implementação de cache distribuído. Eles podem ser configurados adequadamente para limitar a memória L1, criptografar ou definir políticas de remoção. Outras alternativas incluem caches Redis, SQL Server ou Azure Comsos DB. Uma implementação de um cache de token distribuído pode ser encontrada no Tutorial: Introdução ao ASP.NET Core MVC.

Verifique se TokenReplayCache é usado para evitar a repetição de tokens de autenticação MSAL

Title	Detalhes
Componente	ID do Microsoft Entra
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	Autenticação moderna com o Microsoft Entra ID para aplicativos Web
Etapas	A propriedade TokenReplayCache permite aos desenvolvedores definir um cache de reprodução de token, um repositório que pode ser usado para salvar os tokens com a finalidade de verificar se nenhum token pode ser usado mais de uma vez. Essa é uma medida contra um ataque comum, o ataque de reprodução de token, cujo nome é bastante apropriado: um invasor que intercepta o token enviado na entrada pode tentar enviá-la novamente ao aplicativo ("repeti-lo") para estabelecer uma nova sessão. Por exemplo, no fluxo de concessão de código do OIDC, após a autenticação bem-sucedida do usuário, uma solicitação para "/signin-oidc" do ponto de extremidade da terceira parte confiável é feita com os parâmetros "id_token", "code" e "state". A terceira parte confiável valida a solicitação e estabelece uma nova sessão. Se um adversário capturar essa solicitação e a repetir, poderá estabelecer uma sessão bem-sucedida e falsificar o usuário. A presença de nonce em OpenID Connect pode limitar, mas não elimina totalmente as circunstâncias em que o ataque pode ser realizado com êxito. Para proteger os aplicativos, os desenvolvedores podem fornecer uma implementação de ITokenReplayCache e atribuir uma instância de TokenReplayCache.

Exemplo

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

Exemplo

Aqui está uma implementação de exemplo 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 precisa ser referenciado em opções de OIDC por meio da propriedade "TokenValidationParameters" da maneira a seguir.

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

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

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

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

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

A MSAL também mantém um cache de token e atualiza tokens para você quando estão perto de expirar. A MSAL também pode ajudá-lo a especificar qual público-alvo desejável para entrar no aplicativo e ajudá-lo a configurar seu aplicativo a partir de arquivos de configuração e solucionar problemas do aplicativo.

Autenticar dispositivos que se conectam ao Gateway de Campo

Title	Detalhes
Componente	Gateway de Campo de IoT
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	N/D
Etapas	Verifique se cada dispositivo é autenticado pelo Gateway de Campo antes de aceitar dados deles e antes de facilitar as comunicações upstream com o Gateway de Nuvem. Além disso, verifique se os dispositivos se conectam com uma credencial por dispositivo, para que dispositivos individuais possam ser identificados exclusivamente.

Verifique se os dispositivos conectados ao gateway de nuvem são autenticados

Title	Detalhes
Componente	Gateway de Nuvem IoT
Fase do SDL	Build
Tecnologias aplicáveis	Genérico, C#, Node.JS,
Atributos	N/A, 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 Node JS, Como proteger a IoT com SAS e certificados, Repositório do Git
Etapas	Genérico: autentique o dispositivo usando o protocolo TLS ou IPSec. A infraestrutura deve dar suporte ao uso da PSK (chave pré-compartilhada) nos dispositivos que não conseguem lidar com a criptografia assimétrica completa. Aproveitar o Microsoft Entra ID, Oauth. C#: ao criar uma instância de DeviceClient, por padrão, o método Create cria uma instância de DeviceClient que usa o protocolo AMQP para se comunicar com o Hub IoT. Para usar o protocolo HTTPS, use a substituição do método Create que permite especificar o protocolo. Se usar o protocolo HTTPS, você também deverá adicionar o pacote do NuGet Microsoft.AspNet.WebApi.Client ao projeto para incluir o namespace System.Net.Http.Formatting.

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 registro de identidade de 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);
  

  Token SAS

• É gerado internamente ao usar a chave simétrica, mas também pode gerá-la e usá-la explicitamente
• Defina 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 um token sas:

  Client.fromSharedAccessSignature(sas, Http);
  

  Certificados

• Gerar um certificado X509 autoassinado usando qualquer ferramenta, como OpenSSL, para gerar arquivos .cert e .key para armazenar o certificado e a chave, respectivamente
• Provisione um dispositivo que aceite a 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

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

Verifique se apenas os contêineres necessários e os blobs recebem acesso de leitura anônimo

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

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

Title	Detalhes
Componente	Armazenamento do Azure
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
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 SAS com o armazenamento de Blobs, Como delegar acesso a objetos em sua conta usando assinaturas de acesso compartilhado e políticas de acesso armazenado
Etapas	O uso de SAS (assinatura de acesso compartilhado) é uma maneira eficiente de conceder acesso limitado a objetos na conta de armazenamento a outros clientes, sem precisar expor a chave de acesso da conta. A 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 a SAS, o cliente só precisa passar a SAS ao construtor apropriado ou ao método apropriado. Você pode usar uma SAS quando desejar fornecer acesso aos recursos de sua conta de armazenamento a um cliente não confiável com a chave de conta. As chaves de conta de armazenamento incluem uma chave primária e uma chave secundária, que concedem acesso administrativo à sua conta e a todos os recursos que ela contém. A exposição de qualquer uma de suas chaves de conta torna sua conta vulnerável a um possível uso mal-intencionado ou negligente. As assinaturas de acesso compartilhado são uma alternativa segura que permite que outros clientes leiam, gravem e excluam dados da sua conta de armazenamento de acordo com as permissões que você tiver concedido a eles e sem que eles precisem da chave de conta. Se você tiver um conjunto lógico de parâmetros que são sempre semelhantes, o uso de SAP (política de acesso armazenada) será uma ideia melhor. Como usar uma SAS derivada de uma Política de Acesso Armazenado dá a possibilidade de revogar essa SAS imediatamente, a prática recomendada é, sempre que possível, usar Políticas de Acesso Armazenado.