Compartilhar via

Diretrizes de segurança do ACS

  • Artigo

Atualizado: 19 de junho de 2015

Aplica-se a: Azure

Aplica-se a

  • Controle de Acesso do Microsoft Azure Active Directory (também conhecido como ACS ou Serviço de Controle de Acesso)

  • Windows Identity Foundation (WIF)

Resumo

Este tópico consolida as diretrizes de segurança para ACS. Use essas diretrizes para melhorar a qualidade da implementação de uma perspectiva de segurança. Você pode usar essas diretrizes ao revisar a arquitetura do aplicativo, examinar o código e registrar bugs de segurança em log e revisar a implantação de produção. Essas diretrizes referem-se a você para obter mais informações sobre como usar etapas prescritivas para realizar uma tarefa específica e tópicos conceituais para saber mais sobre um recurso ou função específico do ACS.

Objectivos

  • Resolva problemas de segurança relacionados ao código e à configuração de um aplicativo no contexto do ACS.

  • Resolva problemas de segurança relacionados às configurações do ACS.

  • Resolva problemas de segurança relacionados às implantações do Azure no contexto do ACS.

A seguir estão as diretrizes de segurança relacionadas ao código e à configuração do aplicativo.

  • Considere definir o recurso de detecção de reprodução (DetectReplayedTokens) como true.

  • Defina o atributo requireHttps de wsFederation como true.

  • Defina o atributo requireSsl de cookieHandler como true.

  • Defina o valor agressivo para o atributo de tempo de vida de sessionTokenRequirement.

  • Liste o STS confiável (emissores de token) no issuerNameRegistry.

  • Tokens de escopo que devem ser aceitos pelo aplicativo usando audienceUri.

Considere definir o recurso de detecção de reprodução (DetectReplayedTokens) como true

O WIF tem um cache de detecção de reprodução especificamente para tokens de portador sts (serviço de token de segurança), que é apenas um cache de tokens STS usados anteriormente. Quando o cliente se autentica pela primeira vez na terceira parte confiável usando o token STS, ele recebe um token de segurança de sessão que ele usa para autenticar na terceira parte confiável para quaisquer solicitações adicionais. Ele faz isso por SSL (Secure Sockets Layer) para que o token de segurança de sessão não possa ser roubado. Se um cliente ou um invasor tentar autenticar na terceira parte confiável com um token STS que o cliente já usou, a terceira parte confiável poderá pesquisar o token STS no cache de reprodução e recusar a solicitação.

Esse cache não garante que um token nunca possa ser reproduzido. Ele executa a detecção de melhor esforço com base no tamanho do cache, no tempo de expiração do token STS e na taxa de solicitações de autenticação exclusivas recebidas pela terceira parte confiável. É altamente recomendável que você defina o tamanho do cache e o tempo de expiração do token STS para sua terceira parte confiável obter o equilíbrio certo entre desempenho e segurança.

Exemplo:

<securityTokenHandlers>
  <securityTokenHandlerConfiguration>
    <tokenReplayDetection enabled="true" capacity="1000" expirationPeriod="500"/>
  </securityTokenHandlerConfiguration>
</securityTokenHandlers>

Nota

O uso desse recurso apresenta afinidade de servidor que pode levar a problemas de escalabilidade em ambientes com balanceamento de carga, incluindo o Azure. Para superar isso, você pode considerar implementar sua própria detecção de reprodução de token usando uma classe abstrata base Microsoft.IdentityModel.Tokens.TokenReplayCache e, em seguida, referenciá-la no arquivo de configuração, com código semelhante ao seguinte.

<system.identityModel>
  <identityConfiguration>
    <tokenReplayDetection>
      <replayCache type='FQTN of your type' />
    </tokenReplayDetection>
  </identityConfiguration>
</system.identityModel>

Definir o atributo requireHttps de wsFederation como true

O requireHttps controles de atributo se o módulo redirecionará apenas uma URL segura para o STS. O padrão é "true". Isso garante uma comunicação segura com o STS sobre o tráfego HTTPS/SSL claro, mitigando as credenciais e o token que está detectando a transmissão.

Exemplo:

<federatedAuthentication>
  <wsFederation
        passiveRedirectEnabled="true"
        issuer="http://STS URL GOES HERE/"
        realm="http://RP REALM GOES HERE/"
        requireHttps="ture" />
  <cookieHandler requireSsl="true" />
</federatedAuthentication>

Definir o atributo requireSsl de cookieHandler como true

Esse valor é booliano; o padrão é false. O requer controles de atributo SSSL se o sinalizador "Seguro" é emitido para cookies gravados. Se esse valor for definido, os cookies de sessão de entrada estarão disponíveis somente por HTTPS. Isso impede o envio de cookies de sessão sobre o tráfego limpo, mitigando a ameaça do token ser detectado sobre o fio.

Exemplo:

<federatedAuthentication>
  <wsFederation
        passiveRedirectEnabled="true"
        issuer="http://STS URL GOES HERE/"
        realm="http://RP REALM GOES HERE/"
        requireHttps="ture" />
  <cookieHandler requireSsl="true" />
</federatedAuthentication>

Definir o valor agressivo para o atributo de tempo de vida de sessionTokenRequirement

Considere exigir que os tokens sejam emitidos com limites de tempo de vida agressivos. Isso limitaria o período de tempo de um invasor para reproduzir o token caso ele fosse roubado.

Exemplo:

<add type="Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler, Microsoft.IdentityModel">
  <sessionTokenRequirement securityTokenCacheType="Microsoft.IdentityModel.MruSecurityTokenCache, Microsoft.IdentityModel"
                           saveBootstrapTokens="true"
                           securityTokenCacheSize="500"
                           useWindowsTokenService="false"
                           lifetime="10:00" />
</add>

Listar STS confiável (emissores de token) em issuerNameRegistry

Todos os tokens emissores são validados usando o IssuerNameRegistry. A finalidade do IssuerNameRegistry é mapear o token do emissor para um nome de cadeia de caracteres. Se a validação falhar, o token não será aceito. Isso atenua a ameaça de aceitar tokens que não são confiáveis. Qualquer tipo personalizado pode ser registrado usando o tipo atributo do elemento <issuerNameRegistry>. O> issuerNameRegistry <pode ter um elemento filho que servirá como configuração personalizada para o IssuerNameRegistry. Um tipo IssuerNameRegistry é fornecido pronto para uso — ConfigurationBasedIssuerNameRegistry — que pode ser usado para configurar um conjunto de certificados de emissor confiáveis na configuração. Esse tipo requer um elemento de configuração filho <trustedIssuers> em que os certificados de emissor confiáveis foram configurados. <trustedIssuers> configuração adiciona certificados confiáveis usando o formulário codificado em ASN.1 da impressão digital do certificado.

Exemplo:

<issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel">
  <trustedIssuers>
    <add thumbprint="97249e1a5fa6bee5e515b82111ef524a4c9158de" name="contoso.com" />
    <remove thumbprint="97249e1a5fa6bee5e515b82111ef524a4c9158de" />
    <clear/>
  </trustedIssuers>
</issuerNameRegistry>

Tokens de escopo para seu aplicativo usando apenas audienceUri

<audienceUris> especifica o conjunto de URIs aceitáveis como a identificação dessa terceira parte confiável. Os tokens não serão aceitos, a menos que estejam no escopo de uma das URIs de audiência permitidas. Isso atenua a ameaça de reproduzir tokens válidos que foram emitidos para outras partes confiáveis. Por padrão, nenhuma URIs será adicionada à coleção. Os tipos de token SecurityTokenHandler para os tipos de token SAML 1.1 e SAML 2.0 usam os valores nesta coleção para configurar quaisquer restrições de uri de audiência permitidas em objetos SamlSecurityTokenRequirement.

Exemplo:

<audienceUris>
  <clear/>
  <add value="http://www.example.com/myapp/" />
  <remove value="http://www.example.com/myapp/" />
</audienceUris>

A seguir estão as diretrizes de segurança relacionadas à configuração do Portal de Gerenciamento do ACS.

  • Definir expiração agressiva para tokens STS

  • Fornecer validação de dados adequada ao usar o recurso url de erro

  • Considere criptografar tokens para cenários altamente confidenciais

Definir expiração agressiva para tokens STS

O atributo de tempo de vida do token controla o tempo de vida do token. Ele é especificado quando você está criando ou configurando a terceira parte confiável usando o portal do ACS ou o Serviço de Gerenciamento. Você pode usar a propriedade Tempo de Vida do Token para especificar a quantidade de tempo para que um token de segurança emitido pelo ACS para o aplicativo de terceira parte confiável permaneça válido. Por padrão, no ACS, esse valor é definido como 10 minutos (600 segundos). No ACS, esse valor deve ser maior que zero, mas menor ou igual a 24 horas (86400 segundos).

Fornecer validação de dados adequada ao usar o recurso url de erro

Você pode usar a URL de Erro para especificar uma URL para a qual o ACS redireciona usuários se ocorrer um erro durante o processo de logon. Pode ser uma página personalizada hospedada no aplicativo de terceira parte confiável, por exemplo, http://www.fabrikam.com/billing/error.aspx. Como parte do redirecionamento, o ACS fornece detalhes sobre o erro para o aplicativo de terceira parte confiável como um parâmetro de URL HTTP codificado em JSON. A página de erro personalizada pode ser criada para consumir as informações de erro codificadas em JSON para renderizar a mensagem de erro real recebida ou exibir texto de ajuda estático. Se a página exigir autorização, o resultado será um loop de redirecionamento infinito em um caso em que o ACS tentará acessá-lo e enviará o erro codificado em JSON. Portanto, ele deve ser configurado para acesso anônimo. Como a página pode ser acessada anonimamente e, como ela pode incluir código que ecoa html de volta ou gravar dados no banco de dados, você deve tomar medidas para evitar scripts entre sites e ataques de Injeção de SQL.

Considere criptografar tokens para cenários altamente confidenciais

Para cenários altamente sensíveis para federação passiva, considere criptografar tokens. Leia mais sobre como criptografar e descriptografar token no tópico Certificados e Chaves.

A seguir estão as considerações de segurança relacionadas a aplicativos que estão usando o ACS e que são implantados no Azure.

  • Criptografar cookies usando RSA

Criptografar cookies usando RSA

No Azure, o mecanismo de criptografia de cookie padrão (que usa DPAPI (interfaces de programação de aplicativos de proteção de dados)) não é apropriado porque cada instância tem uma chave diferente. Isso significaria que um cookie criado por uma instância de função web não seria legível por outra instância de função da Web. Isso pode levar a falhas de serviço, causando efetivamente a negação do serviço. Veja a seguir a mensagem de erro que você encontrará se usar o mecanismo de criptografia de cookie padrão:

[CryptographicException: Key not valid for use in specified state.
]
System.Security.Cryptography.ProtectedData.Unprotect(Byte[] encryptedData, Byte[] optionalEntropy, DataProtectionScope scope) +577
Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Decode(Byte[] encoded) +80
[InvalidOperationException: ID1073: A CryptographicException occurred when attempting to decrypt the cookie using the ProtectedData API (see inner exception for details). If you are using IIS 7.5, this could be due to the loadUserProfile setting on the Application Pool being set to false. ]
Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Decode(Byte[] encoded) +433
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[] cookie, Boolean outbound) +189
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver) +862
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(Byte[] token, SecurityTokenResolver tokenResolver) +109
Microsoft.IdentityModel.Web.SessionAuthenticationModule.ReadSessionTokenFromCookie(Byte[] sessionCookie) +356
Microsoft.IdentityModel.Web.SessionAuthenticationModule.TryReadSessionTokenFromCookie(SessionSecurityToken& sessionToken) +123
Microsoft.IdentityModel.Web.SessionAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs) +61
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +270

Para resolver esse problema, use um mecanismo de criptografia de cookie que usa uma chave compartilhada por todas as instâncias de função da Web. O código a seguir mostra como substituir o objeto SessionSecurityHandler padrão e configurá-lo para usar a classe RsaEncryptionCookieTransform.

private void OnServiceConfigurationCreated(object sender, 
    ServiceConfigurationCreatedEventArgs e)
{
    List<CookieTransform> sessionTransforms =
        new List<CookieTransform>(
            new CookieTransform[] 
            {
                new DeflateCookieTransform(), 
                new RsaEncryptionCookieTransform(
                    e.ServiceConfiguration.ServiceCertificate),
                new RsaSignatureCookieTransform(
                    e.ServiceConfiguration.ServiceCertificate)  
            });
   SessionSecurityTokenHandler sessionHandler = 
    new
     SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());

    e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(
        sessionHandler);
}

void Application_Start(object sender, EventArgs e)
{
    FederatedAuthentication.ServiceConfigurationCreated += OnServiceConfigurationCreated;
}

Recursos adicionais