Partilhar via

Diretrizes de segurança do ACS

  • Artigo

Atualizado: June 19, 2015

Aplica-se a: Azure

Aplica-se a

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

  • Windows Identity Foundation (WIF)

Resumo

Este tópico consolida as diretrizes de segurança para o ACS. Use estas diretrizes para melhorar a qualidade da sua implementação do ponto de vista da segurança. Você pode usar essas diretrizes ao revisar a arquitetura do seu aplicativo, revisar bugs de segurança de código e registro e revisar a implantação de produção. Estas diretrizes encaminham você para obter mais informações sobre Como fazer com etapas prescritivas para realizar uma tarefa específica e tópicos conceituais para saber mais sobre um recurso ou função específica do ACS.

Objetivos

  • 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 a 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 seu aplicativo.

  • Considere definir o recurso de deteção de repetiçã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 lifetime de sessionTokenRequirement.

  • Liste os STS (emissores de token) confiáveis em issuerNameRegistry.

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

Considere definir o recurso de deteção de repetição (DetectReplayedTokens) como true

O WIF tem um cache de deteção de repetição especificamente para tokens de portador do serviço de token de segurança (STS), 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 da sessão não possa ser roubado. Se um cliente ou invasor tentar autenticar na terceira parte confiável com um token STS que o cliente já usou, a terceira parte confiável poderá procurar 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 deteçã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 para obter o equilíbrio certo entre desempenho e segurança.

Exemplo:

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

Observação

O uso desse recurso introduz 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 deteção de repetição de token usando uma classe abstrata base Microsoft.IdentityModel.Tokens.TokenReplayCache e, em seguida, fazer referência a ele 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>

Defina o atributo requireHttps de wsFederation como true

O atributo requireHttps controla se o módulo redirecionará apenas uma URL segura para o STS. O padrão é "true". Isso garante comunicações seguras com o STS por meio de tráfego HTTPS/SSL claro, mitigando credenciais e deteção de tokens por fio.

Exemplo:

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

Defina o atributo requireSsl de cookieHandler como true

Este valor é booleano; o padrão é false. O atributo requireSsl controla se o sinalizador "Seguro" é emitido para quaisquer cookies escritos. Se este valor for definido, os cookies de sessão de início de sessão estarão disponíveis apenas através de HTTPS. Isso evita o envio de cookies de sessão sobre o tráfego limpo, mitigando a ameaça de o token ser detetado pelo 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 lifetime de sessionTokenRequirement

Considere exigir que os tokens sejam emitidos com limites de vida agressivos. Isso limitaria o prazo de um atacante 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áveis (emissores de token) em issuerNameRegistry

Todos os tokens de emissor são validados usando o IssuerNameRegistry. O objetivo 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 reduz a ameaça de aceitar tokens que não são confiáveis. Qualquer tipo personalizado pode ser registrado usando o tipo atributo do <issuerNameRegistry> elemento. O <issuerNameRegistry> pode ter um elemento filho que servirá como configuração personalizada para o IssuerNameRegistry. Um tipo IssuerNameRegistry é fornecido imediatamente — 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> onde os certificados de emissor confiáveis foram configurados. <configuração de> trustedIssuers adiciona certificados confiáveis usando a forma codificada 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 que são aceitáveis como identificando essa terceira parte confiável. Os tokens não serão aceitos a menos que tenham escopo para um dos URIs de público permitidos. Isso reduz a ameaça de reproduzir tokens válidos que foram emitidos para outras partes confiáveis. Por padrão, nenhum URI será adicionado à coleção. O SecurityTokenHandler para os tipos de token SAML 1.1 e SAML 2.0 usa 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 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 token lifetime controla o tempo de vida do token. Ele é especificado quando você está criando ou configurando a terceira parte confiável usando o portal ACS ou o Serviço de Gerenciamento. Você pode usar a propriedade Token Lifetime 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 os usuários se ocorrer um erro durante o processo de login. 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á-la e enviar o erro codificado JSON. Portanto, ele deve ser configurado para acesso anônimo. Como a página pode ser acessada anonimamente e como pode incluir código que ecoa HTML ou grava 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 do .

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 interfaces de programação de aplicativos de proteção de dados (DPAPI)) 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 Web. Isso pode levar a falhas de serviço, efetivamente causando negação do serviço. A seguir está 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 que é compartilhada por todas as instâncias de função 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