Freigeben über

ACS-Sicherheitsrichtlinien

  • Artikel

Aktualisiert: 19. Juni 2015

Gilt für: Azure

Gilt für

  • Microsoft Azure Active Directory-Zugriffssteuerung (auch als Zugriffssteuerungsdienst oder ACS bezeichnet)

  • Windows Identity Foundation (WIF)

Zusammenfassung

In diesem Thema werden die Sicherheitsrichtlinien für ACS konsolidiert. Verwenden Sie diese Richtlinien, um die Qualität Ihrer Implementierung aus Sicherheitsgründen zu verbessern. Sie können diese Richtlinien verwenden, wenn Sie die Architektur Ihrer Anwendung überprüfen, Code überprüfen und Sicherheitsfehler protokollieren und die Produktionsbereitstellung überprüfen. Diese Richtlinien beziehen sich auf weitere Informationen zu How To's mit präskriptiven Schritten zum Ausführen einer bestimmten Aufgabe und zu konzeptionellen Themen, um mehr über ein bestimmtes Feature oder eine bestimmte Funktion von ACS zu erfahren.

Ziele

  • Behandeln Sie Sicherheitsprobleme im Zusammenhang mit dem Code und der Konfiguration einer Anwendung im Kontext von ACS.

  • Beheben von Sicherheitsproblemen im Zusammenhang mit ACS-Konfigurationen.

  • Behandeln Sie Sicherheitsprobleme im Zusammenhang mit Azure-Bereitstellungen im Kontext von ACS.

Im Folgenden finden Sie Sicherheitsrichtlinien im Zusammenhang mit dem Code und der Konfiguration Ihrer Anwendung.

  • Erwägen Sie, das Feature zur Erkennung der Wiedergabe (DetectReplayedTokens) auf "true" festzulegen.

  • Legen Sie das attribut requireHttps von wsFederation auf "true" fest.

  • Legen Sie das requireSsl Attribut von cookieHandler auf "true" fest.

  • Legen Sie den aggressiven Wert für das Lebensdauer-Attribut von sessionTokenRequirementfest.

  • Auflisten der vertrauenswürdigen STS (Tokenherausgeber) in issuerNameRegistry.

  • Bereichstoken, die von Ihrer Anwendung mithilfe audienceUri-akzeptiert werden sollen.

Erwägen Sie, das Feature zur Erkennung der Wiedergabe (DetectReplayedTokens) auf "true" festzulegen.

WIF verfügt über einen Replay-Erkennungscache speziell für StS-Bearertoken (Security Token Service), bei dem es sich lediglich um einen Cache von zuvor verwendeten STS-Token handelt. Wenn sich der Client zuerst mit dem STS-Token bei der vertrauenden Seite authentifiziert, empfängt er ein Sitzungssicherheitstoken, das für die Authentifizierung bei der vertrauenden Seite für alle zusätzlichen Anforderungen verwendet wird. Dies erfolgt über SSL (Secure Sockets Layer), sodass das Sitzungssicherheitstoken nicht gestohlen werden kann. Wenn ein Client oder ein Angreifer versucht, sich bei der vertrauenden Seite mit einem STS-Token zu authentifizieren, das der Client bereits verwendet hat, kann die vertrauende Seite das STS-Token im Wiedergabecache nachschlagen und die Anforderung ablehnen.

Dieser Cache garantiert nicht, dass ein Token nie wiedergegeben werden kann. Die Erkennung mit bestem Aufwand erfolgt basierend auf der Größe des Caches, der Ablaufzeit des STS-Tokens und der Rate eindeutiger Authentifizierungsanforderungen, die von der vertrauenden Seite empfangen wurden. Es wird dringend empfohlen, die Cachegröße und die STS-Tokenablaufzeit für Ihre vertrauende Partei festzulegen, um das richtige Gleichgewicht zwischen Leistung und Sicherheit zu erzielen.

Beispiel:

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

Anmerkung

Die Verwendung dieses Features führt zur Serveraffinität, die zu Skalierbarkeitsproblemen in Umgebungen mit Lastenausgleich, einschließlich Azure, führen kann. Um dies zu überwinden, können Sie die Implementierung Ihrer eigenen Token-Replay-Erkennung mithilfe einer abstrakten Basisklasse Microsoft.IdentityModel.Tokens.TokenReplayCache implementieren und dann in der Konfigurationsdatei auf sie verweisen, mit Code ähnlich dem folgenden.

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

Festlegen des requireHttps-Attributs von wsFederation auf "true"

Die requireHttps Attribut steuert, ob das Modul nur eine sichere URL für den STS umleitet. Der Standardwert ist "true". Dadurch wird die sichere Kommunikation mit STS über klaren HTTPS/SSL-Datenverkehr sichergestellt, anmeldeinformationen und tokenschniffen über das Netzwerk gemildert.

Beispiel:

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

Festlegen des requireSsl-Attributs von cookieHandler auf "true"

Dieser Wert ist boolescher Wert; Der Standardwert ist "false". Die erfordertSsl Attribut steuert, ob das Flag "Secure" für alle geschriebenen Cookies ausgegeben wird. Wenn dieser Wert festgelegt ist, sind die Anmeldesitzungscookies nur über HTTPS verfügbar. Dadurch wird verhindert, dass Sitzungscookies über den klaren Datenverkehr gesendet werden, wodurch die Bedrohung des Tokens, das über das Netzwerk abgesiffen wird, abgemildert wird.

Beispiel:

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

Festlegen des aggressiven Werts für das Lebensdauer-Attribut von sessionTokenRequirement

Erwägen Sie, dass Token mit aggressiven Lebensdauerbeschränkungen ausgestellt werden müssen. Dies würde den Zeitrahmen eines Angreifers für die Wiedergabe des Tokens einschränken, falls es gestohlen wurde.

Beispiel:

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

Auflisten vertrauenswürdiger STS (Tokenherausgeber) in issuerNameRegistry

Alle Ausstellertoken werden mithilfe des IssuerNameRegistry überprüft. Der Zweck des IssuerNameRegistry besteht darin, das Ausstellertoken einem Zeichenfolgennamen zuzuordnen. Wenn die Überprüfung fehlschlägt, wird das Token nicht akzeptiert. Dadurch wird die Bedrohung der Annahme von Token verringert, die nicht vertrauenswürdig sind. Jeder benutzerdefinierte Typ kann mithilfe des Typs Attributs des <issuerNameRegistry>-Elements registriert werden. Die <issuerNameRegistry-> kann ein untergeordnetes Element aufweisen, das als benutzerdefinierte Konfiguration für "IssuerNameRegistry" dient. Ein IssuerNameRegistry-Typ wird sofort bereitgestellt – ConfigurationBasedIssuerNameRegistry –, der zum Konfigurieren einer Reihe vertrauenswürdiger Ausstellerzertifikate in der Konfiguration verwendet werden kann. Dieser Typ erfordert ein untergeordnetes Konfigurationselement <vertrauenswürdigenIssuers> wo vertrauenswürdige Ausstellerzertifikate konfiguriert sind. <vertrauenswürdigenIssuers> Konfiguration fügt vertrauenswürdige Zertifikate mithilfe der ASN.1-codierten Form des Zertifikatfingerabdrucks hinzu.

Beispiel:

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

Bereichstoken für Ihre Anwendung mit nur AudienceUri

<audienceUris> gibt den Satz von URIs an, die als Identifizierung dieser vertrauenden Seite akzeptabel sind. Token werden nicht akzeptiert, es sei denn, sie gelten für eine der zulässigen Benutzergruppen-URIs. Dadurch wird die Bedrohung der Wiedergabe gültiger Token verringert, die für andere vertrauende Parteien ausgegeben wurden. Standardmäßig werden der Auflistung keine URIs hinzugefügt. Der SecurityTokenHandler für die SAML 1.1- und SAML 2.0-Tokentypen verwenden die Werte in dieser Auflistung, um alle zulässigen Benutzergruppen-URI-Einschränkungen in SamlSecurityTokenRequirement-Objekten zu konfigurieren.

Beispiel:

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

Im Folgenden sind Sicherheitsrichtlinien für die Konfiguration des ACS-Verwaltungsportals aufgeführt.

  • Festlegen des aggressiven Ablaufs für STS-Token

  • Bereitstellen einer angemessenen Datenüberprüfung bei Verwendung des Fehler-URL-Features

  • Erwägen Sie das Verschlüsseln von Token für streng vertrauliche Szenarien.

Festlegen des aggressiven Ablaufs für STS-Token

Das Attribut für die Tokenlebensdauer steuert die Lebensdauer des Tokens. Es wird angegeben, wenn Sie die vertrauende Seite mithilfe des ACS-Portals oder des Verwaltungsdiensts erstellen oder konfigurieren. Mit der Token Lifetime-Eigenschaft können Sie den Zeitraum für ein sicherheitstoken angeben, das von ACS an die Anwendung der vertrauenden Seite ausgegeben wird, um gültig zu bleiben. In ACS ist dieser Wert standardmäßig auf 10 Minuten (600 Sekunden) festgelegt. In ACS muss dieser Wert größer als Null sein, aber kleiner als oder gleich 24 Stunden (86400 Sekunden).

Bereitstellen einer angemessenen Datenüberprüfung bei Verwendung des Fehler-URL-Features

Sie können die Fehler-URL verwenden, um eine URL anzugeben, zu der ACS Benutzer umleitet, wenn während des Anmeldevorgangs ein Fehler auftritt. Es kann sich um eine benutzerdefinierte Seite handeln, die in der Anwendung der vertrauenden Seite gehostet wird, z. B. http://www.fabrikam.com/billing/error.aspx. Im Rahmen der Umleitung liefert ACS Details zum Fehler an die Anwendung der vertrauenden Seite als JSON-codierten HTTP-URL-Parameter. Die benutzerdefinierte Fehlerseite kann so gestaltet werden, dass die JSON-codierten Fehlerinformationen verwendet werden, um die tatsächliche empfangene Fehlermeldung zu rendern oder statische Hilfetext anzuzeigen. Wenn die Seite eine Autorisierung erfordert, ist das Ergebnis eine endlose Umleitungsschleife in einem Fall, in dem ACS versucht, darauf zuzugreifen und den JSON-codierten Fehler zu senden. Daher sollte sie für anonymen Zugriff konfiguriert werden. Da auf die Seite anonym zugegriffen werden kann und sie Möglicherweise Code enthält, der HTML-Code zurückgibt oder Daten in die Datenbank schreibt, sollten Sie Schritte ausführen, um websiteübergreifende Skripting- und SQL Injection-Angriffe zu verhindern.

Erwägen Sie das Verschlüsseln von Token für streng vertrauliche Szenarien.

Für hochsensible Szenarien für passive Partnerverbunde sollten Token verschlüsselt werden. Weitere Informationen zum Verschlüsseln und Entschlüsseln von Token finden Sie im Thema Zertifikate und Schlüssel Thema.

Im Folgenden finden Sie Sicherheitsüberlegungen im Zusammenhang mit Anwendungen, die ACS verwenden und für Azure bereitgestellt werden.

  • Verschlüsseln von Cookies mithilfe von RSA

Verschlüsseln von Cookies mithilfe von RSA

In Azure ist der standardmäßige Cookieverschlüsselungsmechanismus (der Data Protection Application Programming Interfaces (DPAPI) verwendet, nicht geeignet, da jede Instanz über einen anderen Schlüssel verfügt. Dies würde bedeuten, dass ein von einer Webrolleninstanz erstelltes Cookie nicht von einer anderen Webrolleninstanz gelesen werden kann. Dies kann zu Dienstfehlern führen, was effektiv zu Denial-of-the-Service führt. Im Folgenden sehen Sie die Fehlermeldung, die beim Verwenden des standardmäßigen Cookie-Verschlüsselungsmechanismus auftritt:

[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

Um dieses Problem zu lösen, verwenden Sie einen Cookie-Verschlüsselungsmechanismus, der einen Schlüssel verwendet, der von allen Webrolleninstanzen freigegeben wird. Der folgende Code zeigt, wie das Standardmäßige SessionSecurityHandler-Objekt ersetzt und für die Verwendung der RsaEncryptionCookieTransform-Klasse konfiguriert wird.

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

Zusätzliche Ressourcen