ACS-Sicherheitsrichtlinien

  • Artikel

Aktualisiert: 19. Juni 2015

Gilt für: Azure

Gilt für

  • Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS)

  • 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 unter Sicherheitsaspekten zu optimieren. Sie können diese Richtlinien verwenden, wenn Sie die Architektur Ihrer Anwendung oder den Code überprüfen und Sicherheitsfehler protokollieren oder die Produktionsbereitstellung überprüfen. Diese Richtlinien verweisen 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 werden die Sicherheitsrichtlinien vorgestellt, die sich auf den Code und die Konfiguration Ihrer Anwendung beziehen.

  • Ziehen Sie in Erwägung, die Wiedererkennungsfunktion (DetectReplayedTokens) auf WAHR festzulegen.

  • Legen Sie das Attribut requireHttps von wsFederation auf WAHR fest.

  • Legen Sie das Attribut requireSsl von cookieHandler auf WAHR fest.

  • Legen Sie den aggressiven Wert des Lebensdauerattributs auf sessionTokenRequirement fest.

  • Listen Sie die vertrauenswürdigen STS (Tokenaussteller) in issuerNameRegistry auf.

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

Ziehen Sie in Erwägung, die Wiedererkennungsfunktion (DetectReplayedTokens) auf WAHR festzulegen.

WIF verfügt über einen speziellen Wiedererkennungscache für Trägertoken des Sicherheitstokendiensts (STS). Dabei handelt es sich einfach um einen Cache für zuvor verwendete STS-Token. Wenn sich der Client erstmals bei der vertrauenden Seite mithilfe des STS-Tokens authentifiziert, empfängt er ein Sitzungssicherheitstoken, das er für die Authentifizierung bei der vertrauenden Seite für alle weiteren Anforderungen verwendet. Dies geschieht über SSL (Secure Sockets Layer), damit das Sitzungssicherheitstoken nicht abgefangen werden kann. Wenn ein Client oder ein Angreifer einen Authentifizierungsversuch bei der vertrauenden Seite mit einem STS-Token ausführt, das der Client bereits verwendet hat, kann die vertrauende Seite das STS-Token im Wiedergabecache nachschlagen und die Anforderung zurückweisen.

Dieser Cache garantiert nicht, dass ein Token niemals wiedergegeben werden kann. Er führt die bestmögliche Erkennung basierend auf der Größe des Caches, dem Ablaufzeitpunkt des STS-Tokens und der Rate eindeutiger Authentifizierungsanforderungen aus, die von der vertrauenden Seite empfangen wurden. Es wird dringend empfohlen, die Cachegröße und den Ablaufzeitpunkt des STS-Tokens für Ihre vertrauende Seite festzulegen, um das richtige Verhältnis zwischen Leistung und Sicherheit zu erzielen.

Beispiel:

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

Hinweis

Mithilfe dieser Funktion wird Serveraffinität implementiert, die ggf. zu Skalierungsproblemen in Umgebungen mit Lastenausgleich (einschließlich Azure) führen kann. Als Problemumgehung können Sie ggf. Ihre eigene Tokenwiedergabeerkennung mithilfe einer abstrakten Basisklasse Microsoft.IdentityModel.Tokens.TokenReplayCache implementieren und auf diese dann in der Konfigurationsdatei mit Code verweisen, der dem folgenden Code ähnelt.

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

Festlegen des Attributs "requireHttps" von "wsFederation" auf "WAHR"

Das Attribut requireHttps steuert, ob das Modul nur eine sichere URL für den STS weiterleitet. Der Standardwert ist WAHR. Dies stellt die sichere Kommunikation mit STS über unverschlüsselten HTTPS/SSL-Datenverkehr sicher und verringert die Möglichkeit von Snifferangriffen auf die Anmeldeinformationen und Token im Netzwerk.

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 Attributs "requireSsl" von "cookieHandler" auf "WAHR"

Dieser Wert ist ein boolescher Wert. Der Standardwert ist FALSCH. Das Attribut requireSsl steuert, ob das Kennzeichen "Secure" für Cookies ausgegeben wird, die geschrieben werden. Wenn dieser Wert festgelegt ist, sind die Anmeldesitzungscookies nur über HTTPS verfügbar. Auf diese Weise wird verhindert, dass Sitzungscookies über unverschlüsselten Datenverkehr gesendet werden und verringert die Möglichkeit von Snifferangriffen auf die Token im Netzwerk.

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 des Lebensdauerattributs auf "sessionTokenRequirement"

Ziehen Sie in Betracht, die Ausstellung von Token mit aggressiven Lebensdauergrenzwerten zu verlangen. Auf diese Weise wird der Zeitrahmen eines Angreifers für die Wiedergabe eines abgefangenen Tokens eingeschränkt.

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 der vertrauenswürdigen STS (Tokenaussteller) in "issuerNameRegistry"

Alle Ausstellertoken werden mithilfe von IssuerNameRegistry überprüft. Die Aufgabe von IssuerNameRegistry besteht im Zuordnen des Ausstellertokens zu einem Zeichenfolgennamen. Bei einem Überprüfungsfehler wird das Token nicht akzeptiert. Auf diese Weise wird eine Bedrohung durch die Annahme nicht vertrauenswürdiger Token verringert. Jeder benutzerdefinierte Typ kann mithilfe des Typattributes des <issuerNameRegistry-Elements> registriert werden. Die <issuerNameRegistry kann ein untergeordnetes Element haben, das als benutzerdefinierte Konfiguration für die IssuerNameRegistry> dient. Ein IssuerNameRegistry-Typ wird standardmäßig bereitgestellt: ConfigurationBasedIssuerNameRegistry. Dieser Typ kann zum Konfigurieren einer Sammlung vertrauenswürdiger Ausstellerzertifikate in der Konfiguration verwendet werden. Dieser Typ erfordert ein untergeordnetes Konfigurationselement <vertrauenswürdigIssuers> , bei dem vertrauenswürdige Ausstellerzertifikate konfiguriert sind. <vertrauenswürdigeIssuers-Konfiguration> fügt vertrauenswürdige Zertifikate mithilfe des ASN.1 codierten Formulars des Zertifikat-Fingerabdrucks 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 unter ausschließlicher Verwendung von "audienceUri"

<audienceUris> gibt den Satz von URIs an, die als Identifizierung dieser vertrauenden Partei zulässig sind. Token werden nur akzeptiert, wenn sie im Bereich einer der zulässigen "Audience"-URIs liegen. Auf diese Weise werden Bedrohungen durch die Wiedergabe gültiger Token verringert, die für andere vertrauende Seiten ausgestellt wurden. Standardmäßig werden der Sammlung keine URIs hinzugefügt. Der SecurityTokenHandler für SAML 1.1- und SAML 2.0-Tokentypen verwendet die Werte in dieser Sammlung zum Konfigurieren aller zulässigen "Audience"-URI-Einschränkungen in SamlSecurityTokenRequirement-Objekten.

Beispiel:

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

Nachfolgend sind Sicherheitsrichtlinien im Zusammenhang mit der ACS-Verwaltungsportalkonfiguration aufgeführt.

  • Festlegen aggressiver Ablaufdaten für STS-Token

  • Bereitstellen adäquater Datenüberprüfung beim Verwenden der Fehler-URL-Funktion

  • Inbetrachtziehen der Verschlüsselung von Token in streng vertraulichen Szenarien

Festlegen aggressiver Ablaufdaten für STS-Token

Das Attribut für die Tokengültigkeitsdauer steuert die Gültigkeitsdauer des Tokens. Es wird angegeben, wenn Sie die vertrauende Partei mithilfe des ACS-Portals oder Verwaltungsdiensts erstellen oder konfigurieren. Sie können die Token-Lebensdauereigenschaft verwenden, um die Zeit für ein von ACS ausgestelltes Sicherheitstoken für die vertrauende Parteianwendung anzugeben, um gültig zu bleiben. Standardmäßig wird dieser Wert in ACS auf 10 Minuten festgelegt (600 Sekunden). In ACS muss dieser Wert größer als null sein, aber kleiner als oder gleich 24 Stunden (86400 Sekunden).

Bereitstellen adäquater Datenüberprüfung beim Verwenden der Fehler-URL-Funktion

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 eine benutzerdefinierte Seite sein, die auf der vertrauenden Parteianwendung gehostet wird, z http://www.fabrikam.com/billing/error.aspx. B. . Im Rahmen der Umleitung liefert ACS Details zum Fehler der vertrauenden Parteianwendung als JSON-codierten HTTP-URL-Parameter. Die benutzerdefinierte Fehlerseite kann so konzipiert werden, dass sie die JSON-codierten Fehlerinformationen zum Rendern der tatsächlichen Fehlermeldung verwendet, die empfangen wird, oder zum Anzeigen statischen Hilfetexts. Wenn die Seite Autorisierung erfordert, ist das Ergebnis eine unendliche Umleitungsschleife in einem Fall, in dem ACS versucht, darauf zuzugreifen und den JSON-codierten Fehler zu senden. Aus diesem Grund sollte sie für anonymen Zugriff konfiguriert werden. Da auf die Seite anonym zugegriffen werden kann und diese ggf. Code enthält, der HTML zurücksendet oder Daten in Ihre Datenbank schreibt, sollten Maßnahmen vorsehen, die siteübergreifende Skriptingangriffe und die Einschleusung von SQL-Code verhindern.

Inbetrachtziehen der Verschlüsselung von Token in streng vertraulichen Szenarien

Erwägen Sie für streng vertrauliche Szenarien für den passiven Verbund die Verschlüsselung von Token. Weitere Informationen zum Verschlüsseln und Entschlüsseln von Token finden Sie im Thema "Zertifikate und Schlüssel ".

Nachfolgend sind Sicherheitsüberlegungen im Zusammenhang mit Anwendungen, die ACS verwenden und für Azure bereitgestellt werden.

  • Verschlüsseln von Cookies mit RSA

Verschlüsseln von Cookies mit RSA

In Azure ist der Standardverschlüsselungsmechanismus für Cookies (der DPAPI, Data Protection Application Programming Interfaces) verwendet, ungeeignet, weil jede Instanz einen anderen Schlüssel besitzt. Dies würde bedeuten, dass ein von einer Webrolleninstanz erstelltes Cookie von einer anderen Webrolleninstanz gelesen werden kann. Dies kann zu Dienstfehlern führen und schlussendlich Denial-of-Service bewirken. Nachfolgend sehen Sie eine Fehlermeldung, die auftritt, wenn Sie den Standardverschlüsselungsmechanismus für Cookies verwenden:

[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

Verwenden Sie einen Cookieverschlüsselungsmechanismus, der einen Schlüssel verwendet, der von allen Webrolleninstanzen gemeinsam verwendet wird, um dieses Problem zu beheben. Der folgende Code zeigt, wie das SessionSecurityHandler-Standardobjekt ersetzt und für die Verwendung der Klasse RsaEncryptionCookieTransform 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;
}

Weitere Ressourcen