Share via

ACS-beveiligingsrichtlijnen

  • Artikel

Bijgewerkt: 19 juni 2015

Van toepassing op: Azure

Van toepassing op

  • Microsoft Azure Active Directory Access Control (ook wel Access Control Service of ACS genoemd)

  • Windows Identity Foundation (WIF)

Samenvatting

In dit onderwerp worden de beveiligingsrichtlijnen voor ACS geconsolideerd. Gebruik deze richtlijnen om de kwaliteit van uw implementatie vanuit een beveiligingsperspectief te verbeteren. U kunt deze richtlijnen gebruiken bij het controleren van de architectuur van uw toepassing, het controleren van beveiligingsfouten in code en het vastleggen van beveiligingsfouten en het controleren van de productie-implementatie. Deze richtlijnen verwijzen u naar meer informatie over procedures met beschrijvende stappen voor het uitvoeren van een specifieke taak en conceptuele onderwerpen voor meer informatie over een bepaalde functie of functie van ACS.

Doelen

  • Los beveiligingsproblemen op met betrekking tot de code en configuratie van een toepassing in de context van ACS.

  • Beveiligingsproblemen met betrekking tot ACS-configuraties oplossen.

  • Los beveiligingsproblemen met betrekking tot Azure-implementaties op in de context van ACS.

Hieronder vindt u beveiligingsrichtlijnen met betrekking tot de code en configuratie van uw toepassing.

  • Overweeg de functie replaydetectie (DetectReplayedTokens) in te stellen op waar.

  • Stel het kenmerk requireHttps van wsFederation in op true.

  • Stel het kenmerk requireSsl van cookieHandler in op true.

  • Stel de agressieve waarde in voor het levensduurkenmerk van sessionTokenRequirement.

  • Vermeld de vertrouwde STS (tokenverleners) in issuerNameRegistry.

  • Bereiktokens die door uw toepassing moeten worden geaccepteerd met behulp van audienceUri.

Overweeg de functie replaydetectie (DetectReplayedTokens) in te stellen op true

WIF heeft een cache voor replay-detectie specifiek voor STS-bearer-tokens (Security Token Service). Dit is slechts een cache van eerder gebruikte STS-tokens. Wanneer de client zich voor het eerst verifieert bij de relying party met behulp van het STS-token, ontvangt deze een sessiebeveiligingstoken dat wordt gebruikt voor verificatie bij de relying party voor eventuele aanvullende aanvragen. Dit doet u via SSL (Secure Sockets Layer), zodat het sessiebeveiligingstoken niet kan worden gestolen. Als een client of aanvaller probeert te verifiëren bij de relying party met een STS-token dat de client al heeft gebruikt, kan de relying party het STS-token opzoeken in de cache voor opnieuw afspelen en de aanvraag weigeren.

Deze cache garandeert niet dat een token nooit opnieuw kan worden afgespeeld. Het voert best effort detectie uit op basis van de grootte van de cache, de vervaltijd van het STS-token en de frequentie van unieke verificatieaanvragen die door de relying party zijn ontvangen. We raden u ten zeerste aan de cachegrootte en de verlooptijd van het STS-token in te stellen voor uw relying party om de juiste balans te vinden tussen prestaties en beveiliging.

Voorbeeld:

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

Notitie

Met deze functie maakt u kennis met serveraffiniteit die kan leiden tot schaalbaarheidsproblemen in omgevingen met gelijke taakverdeling, waaronder Azure. Om dit te verhelpen, kunt u overwegen om uw eigen tokenherplaydetectie te implementeren met behulp van een basisabstrische klasse Microsoft.IdentityModel.Tokens.TokenReplayCache en vervolgens te verwijzen naar het configuratiebestand, met code die vergelijkbaar is met het volgende.

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

Het kenmerk requireHttps van wsFederation instellen op true

Het kenmerk RequireHttps bepaalt of de module alleen een beveiligde URL voor de STS omleidt. De standaardwaarde is 'true'. Dit zorgt ervoor dat beveiligde communicatie met STS via wissen HTTPS/SSL-verkeer, waardoor referenties en token sniffing via de kabel worden beperkt.

Voorbeeld:

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

Stel het kenmerk requireSsl van cookieHandler in op true

Deze waarde is Booleaanse waarde; de standaardwaarde is onwaar. Het kenmerk requireSsl bepaalt of de vlag Secure wordt verzonden voor cookies die zijn geschreven. Als deze waarde is ingesteld, zijn de cookies voor de aanmeldingssessie alleen beschikbaar via HTTPS. Dit voorkomt het verzenden van sessiecookies via het duidelijke verkeer, waardoor de dreiging van het token dat via de draad wordt gesnuffeld, wordt beperkt.

Voorbeeld:

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

Stel de agressieve waarde in voor het levensduurkenmerk van sessionTokenRequirement

Overweeg tokens te vereisen die moeten worden uitgegeven met agressieve levensduurlimieten. Dit zou het tijdsbestek van een aanvaller beperken voor het opnieuw afspelen van het token voor het geval het werd gestolen.

Voorbeeld:

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

Vertrouwde STS(tokenverleners) vermelden in issuerNameRegistry

Alle tokens voor verleners worden gevalideerd met behulp van issuerNameRegistry. Het doel van issuerNameRegistry is het toewijzen van het verlenertoken aan een tekenreeksnaam. Als de validatie mislukt, wordt het token niet geaccepteerd. Dit beperkt de dreiging van het accepteren van tokens die niet worden vertrouwd. Elk aangepast type kan worden geregistreerd met het typekenmerk van het <element issuerNameRegistry> . De <issuerNameRegistry> kan één onderliggend element hebben dat fungeert als aangepaste configuratie voor issuerNameRegistry. Er is een type IssuerNameRegistry beschikbaar( ConfigurationBasedIssuerNameRegistry) dat kan worden gebruikt voor het configureren van een set vertrouwde certificaten voor verleners in de configuratie. Voor dit type is een onderliggend configuratie-element <trustedIssuers> vereist waarbij certificaten van vertrouwde verleners zijn geconfigureerd. <de configuratie van trustedIssuers> voegt vertrouwde certificaten toe met behulp van de gecodeerde asn.1-vorm van de vingerafdruk van het certificaat.

Voorbeeld:

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

Bereiktokens voor uw toepassing met alleen audienceUri

<audienceUris> geeft de set URI's op die acceptabel zijn als het identificeren van deze relying party. Tokens worden niet geaccepteerd, tenzij ze zijn afgestemd op een van de toegestane doelgroep-URI's. Dit beperkt de dreiging van het opnieuw afspelen van geldige tokens die zijn uitgegeven voor andere relying party's. Standaard worden er geen URI's toegevoegd aan de verzameling. De typen SecurityTokenHandler voor de typen SAML 1.1 en SAML 2.0 gebruiken de waarden in deze verzameling om eventuele toegestane doelgroep-URI-beperkingen in SamlSecurityTokenRequirement-objecten te configureren.

Voorbeeld:

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

Hieronder volgen beveiligingsrichtlijnen met betrekking tot de configuratie van acs-beheerportal.

  • Agressieve vervaldatum instellen voor STS-tokens

  • Geef voldoende gegevensvalidatie op bij het gebruik van de functie Fout-URL

  • Overweeg tokens te versleutelen voor zeer gevoelige scenario's

Agressieve vervaldatum instellen voor STS-tokens

Het kenmerk levensduur van tokens bepaalt de levensduur van het token. Deze wordt opgegeven wanneer u de relying party maakt of configureert met behulp van de ACS-portal of managementservice. U kunt de eigenschap Levensduur van token gebruiken om de hoeveelheid tijd op te geven voor een beveiligingstoken dat door ACS is uitgegeven aan de relying party-toepassing om geldig te blijven. In ACS is deze waarde standaard ingesteld op 10 minuten (600 seconden). In ACS moet deze waarde groter zijn dan nul, maar kleiner dan of gelijk aan 24 uur (86400 seconden).

Geef voldoende gegevensvalidatie op bij het gebruik van de functie Fout-URL

U kunt de fout-URL gebruiken om een URL op te geven waarnaar ACS gebruikers omleidt als er een fout optreedt tijdens het aanmeldingsproces. Het kan een aangepaste pagina zijn die wordt gehost op de relying party-toepassing, bijvoorbeeld http://www.fabrikam.com/billing/error.aspx. Als onderdeel van de omleiding levert ACS details over de fout aan de relying party-toepassing als een met JSON gecodeerde HTTP-URL-parameter. De aangepaste foutpagina kan worden gemaakt om de JSON-gecodeerde foutgegevens te gebruiken om het werkelijke foutbericht weer te geven dat is ontvangen of statische Help-tekst weer te geven. Als voor de pagina autorisatie is vereist, is het resultaat een oneindige omleidingslus in een geval waarin ACS probeert toegang te krijgen tot de pagina en de JSON-gecodeerde fout verzendt. Daarom moet deze worden geconfigureerd voor anonieme toegang. Omdat de pagina anoniem kan worden geopend en omdat deze mogelijk code bevat die HTML weergeeft of gegevens naar de database schrijft, moet u stappen ondernemen om scripting op meerdere sites en SQL injectieaanvallen te voorkomen.

Overweeg tokens te versleutelen voor zeer gevoelige scenario's

Voor uiterst gevoelige scenario's voor passieve federatie kunt u overwegen tokens te versleutelen. Lees meer over het versleutelen en ontsleutelen van token in het onderwerp Certificaten en sleutels .

Hieronder volgen beveiligingsoverwegingen met betrekking tot toepassingen die ACS gebruiken en die zijn geïmplementeerd in Azure.

  • Cookies versleutelen met RSA

Cookies versleutelen met RSA

In Azure is het standaardmechanisme voor cookieversleuteling (dat gebruikmaakt van DPAPI (Data Protection Application Programming Interfaces) niet geschikt omdat elk exemplaar een andere sleutel heeft. Dit betekent dat een cookie die door één exemplaar van de webrol is gemaakt, niet kan worden gelezen door een ander exemplaar van een webrol. Dit kan leiden tot servicefouten, waardoor denial of the service effectief wordt veroorzaakt. Hier volgt het foutbericht dat u tegenkomt als u het standaardmechanisme voor cookieversleuteling gebruikt:

[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

Gebruik een mechanisme voor cookieversleuteling dat gebruikmaakt van een sleutel die wordt gedeeld door alle webrolinstanties om dit probleem op te lossen. De volgende code laat zien hoe u het standaard SessionSecurityHandler-object vervangt en configureert voor het gebruik van de klasse 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;
}

Aanvullende resources