Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieses Thema enthält bewährte Informationen, die Ihnen beim Planen und Auswerten der Sicherheit beim Entwerfen Ihrer Active Directory-Verbunddienste (AD FS)-Bereitstellung helfen. Dieses Thema ist ein Ausgangspunkt für die Überprüfung und Bewertung von Überlegungen, die sich auf die Gesamtsicherheit Ihrer Verwendung von AD FS auswirken. Die Informationen in diesem Thema sollen Ihre vorhandene Sicherheitsplanung und andere bewährte Methoden ergänzen und erweitern.
Kernbewährte Sicherheitspraktiken für AD FS
Die folgenden bewährten Methoden gelten für alle AD FS-Installationen, bei denen Sie die Sicherheit Ihres Designs oder Ihrer Bereitstellung verbessern oder erweitern möchten:
Sicheres AD FS als "Tier 0"-System
Da AD FS grundsätzlich ein Authentifizierungssystem ist, sollte es als "Tier 0"-System wie andere Identitätssysteme in Ihrem Netzwerk behandelt werden. Weitere Informationen finden Sie im Active Directory-Verwaltungsebenenmodell.
Verwenden Sie den Sicherheitskonfigurations-Assistenten, um AD FS-spezifische Sicherheitsbest-Practices auf Verbundserver und Verbundserver-Proxies anzuwenden
Der Sicherheitskonfigurations-Assistent (SCW) ist ein Tool, das auf allen Computern unter Windows Server 2008, Windows Server 2008 R2 und Windows Server 2012 vorinstalliert ist. Sie können sie verwenden, um bewährte Methoden für die Sicherheit anzuwenden, die dazu beitragen können, die Angriffsfläche für einen Server basierend auf den Serverrollen zu verringern, die Sie installieren.
Wenn Sie AD FS installieren, erstellt das Setupprogramm Rollenerweiterungsdateien, die Sie mit dem SCW verwenden können, um eine Sicherheitsrichtlinie zu erstellen, die für die spezifische AD FS-Serverrolle (verbundserver oder Verbundserverproxy) gilt, die Sie während des Setups auswählen.
Jede installierte Rollenerweiterungsdatei stellt den Typ der Rolle und Unterrole dar, für die jeder Computer konfiguriert ist. Die folgenden Rollenerweiterungsdateien werden im Verzeichnis C:WindowsADFSScw installiert:
Farm.xml
SQLFarm.xml
StandAlone.xml
Proxy.xml (Diese Datei ist nur vorhanden, wenn Sie den Computer in der Verbundserverproxyrolle konfiguriert haben.)
Führen Sie die folgenden Schritte aus, um die AD FS-Rollenerweiterungen im SCW anzuwenden:
Installieren Sie AD FS, und wählen Sie die entsprechende Serverrolle für diesen Computer aus. Weitere Informationen finden Sie unter Installieren des Verbunddienstproxy-Rollendiensts im AD FS-Bereitstellungshandbuch.
Registrieren Sie die entsprechende Rollenerweiterungsdatei mithilfe des Befehlszeilentools Scwcmd. Ausführliche Informationen zur Verwendung dieses Tools in der Rolle, für die Ihr Computer konfiguriert ist, finden Sie in der folgenden Tabelle.
Stellen Sie sicher, dass der Befehl erfolgreich abgeschlossen wurde, indem Sie die SCWRegister_log.xml Datei untersuchen, die sich im Verzeichnis "WindowssecurityMsscwLogs" befindet.
Sie müssen alle diese Schritte auf jedem Verbundserver- oder Verbundserverproxycomputer ausführen, auf den Sie AD FS-basierte SCW-Sicherheitsrichtlinien anwenden möchten.
In der folgenden Tabelle wird erläutert, wie Sie die entsprechende SCW-Rollenerweiterung basierend auf der AD FS-Serverrolle registrieren, die Sie auf dem Computer ausgewählt haben, auf dem Sie AD FS installiert haben.
AD FS-Serverrolle Verwendete AD FS-Konfigurationsdatenbank Geben Sie an einer Eingabeaufforderung den folgenden Befehl ein: Eigenständiger Verbundserver Interne Windows-Datenbank scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwStandAlone.xml"Einer Farm angehöriger Verbundserver Interne Windows-Datenbank scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwFarm.xml"Einer Farm angehöriger Verbundserver SQL Server scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwSQLFarm.xml"Verbundserverproxy Nicht verfügbar scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwProxy.xml"Weitere Informationen zu den Datenbanken, die Sie mit AD FS verwenden können, finden Sie in der Rolle der AD FS-Konfigurationsdatenbank.
Verwenden Sie die Erkennung der Tokenwiedergabe in Situationen, in denen Sicherheit ein sehr wichtiges Anliegen ist, z. B. wenn Kioske verwendet werden. Die Token-Wiederholungserkennung ist eine Funktion von AD FS, die sicherstellt, dass jeder Versuch, eine Token-Anforderung an die Verbundzentrale erneut abzuspielen, erkannt und die Anforderung verworfen wird. Die Erkennung von Token-Wiederholungen ist standardmäßig aktiviert. Es funktioniert sowohl für das WS-Federation passives Profil als auch für das SAML-WebSSO-Profil (Security Assertion Markup Language), indem sichergestellt wird, dass dasselbe Token nie mehr als einmal verwendet wird.
Wenn der Verbunddienst gestartet wird, beginnt er, einen Cache aller tokenanforderungen zu erstellen, die er erfüllt. Mit der Zeit, wenn nachfolgende Tokenanforderungen dem Cache hinzugefügt werden, erhöht sich für den Verbunddienst die Fähigkeit, Versuche zu erkennen, eine Tokenanforderung mehrfach wiederzuverwenden. Wenn Sie die Erkennung der Token-Wiedergabe deaktivieren und später erneut aktivieren, denken Sie daran, dass der Verbunddienst Tokens noch für einen bestimmten Zeitraum akzeptiert, in dem sie zuvor verwendet wurden, bis der Wiedergabecache genügend Zeit hatte, seine Inhalte wieder aufzubauen. Weitere Informationen hierzu finden Sie unter The Role of the AD FS Configuration Database (Die Rolle der AD FS-Konfigurationsdatenbank).
Verwenden Sie die Tokenverschlüsselung, insbesondere wenn Sie die SAML-Artefaktauflösung unterstützen.
Die Verschlüsselung von Token wird dringend empfohlen, die Sicherheit und den Schutz vor potenziellen Man-in-the-Middle-Angriffen (MITM) zu erhöhen, die möglicherweise gegen Ihre AD FS-Bereitstellung versucht werden. Die Verwendung von Verschlüsselung kann möglicherweise einen leichten Einfluss auf den Durchsatz haben, aber im Allgemeinen sollte dies normalerweise nicht bemerkt werden, und in vielen Bereitstellungen überwiegen die Vorteile für größere Sicherheit die Kosten bezüglich der Serverleistung.
Zum Aktivieren der Tokenverschlüsselung fügen Sie zuerst ein Verschlüsselungszertifikat für die Vertrauensstellungen der vertrauenden Seite hinzu. Sie können ein Verschlüsselungszertifikat entweder beim Erstellen einer Vertrauensstellung der vertrauenden Seite oder später konfigurieren. Wenn Sie einem vorhandenen Vertrauensmodell später ein Verschlüsselungszertifikat hinzufügen möchten, können Sie ein Zertifikat für die Verwendung auf der Registerkarte "Verschlüsselung " innerhalb von Vertrauenseigenschaften festlegen, während Sie das AD FS-Snap-In verwenden. Verwenden Sie zum Angeben eines Zertifikats für eine vorhandene Vertrauensstellung mithilfe der AD FS-Cmdlets den Parameter EncryptionCertificate der Cmdlets Set-ClaimsProviderTrust oder Set-RelyingPartyTrust . Verwenden Sie das Cmdlet Set-ADFSCertificate , und geben Sie "
Token-Encryption" für den Parameter "CertificateType " an, um ein Zertifikat für den Verbunddienst festzulegen, das beim Entschlüsseln von Token verwendet werden soll. Das Aktivieren und Deaktivieren der Verschlüsselung für eine bestimmte Vertrauensstellung der vertrauenden Seite kann mithilfe des Parameters EncryptClaims des Cmdlets Set-RelyingPartyTrust erfolgen.Nutzen des erweiterten Schutzes für die Authentifizierung
Um Ihre Bereitstellungen zu schützen, können Sie den erweiterten Schutz für die Authentifizierungsfunktion mit AD FS festlegen und verwenden. Diese Einstellung gibt die Ebene des erweiterten Schutzes für die Authentifizierung an, die von einem Verbundserver unterstützt wird.
Erweiterter Schutz für die Authentifizierung trägt zum Schutz vor Man-in-the-Middle-Angriffen (MITM) bei, bei denen ein Angreifer Clientanmeldeinformationen abfangen und an einen Server weiterleitet. Der Schutz gegen solche Angriffe wird über ein Kanalbindungstoken (Channel Binding Token, CBT) ermöglicht, das entweder erforderlich, zugelassen oder nicht vom Server benötigt werden kann, wenn die Kommunikation mit Clients hergestellt wird.
Verwenden Sie zum Aktivieren des erweiterten Schutzfeatures den Parameter ExtendedProtectionTokenCheck für das Cmdlet Set-ADFSProperties . Mögliche Werte für diese Einstellung und die Sicherheitsstufe, die die Werte bereitstellen, werden in der folgenden Tabelle beschrieben.
Parameterwert Sicherheitsstufe Schutzeinstellung Erforderlich Der Server ist vollständig abgesichert. Erweiterter Schutz wird erzwungen und ist immer erforderlich. Zulassen Der Server ist teilweise gehärtet. Erweiterter Schutz wird erzwungen, wenn die beteiligten Systeme gepatcht wurden, um ihn zu unterstützen. Nichts Server ist anfällig. Erweiterter Schutz wird nicht erzwungen. Wenn Sie Protokollierung und Ablaufverfolgung verwenden, stellen Sie sicher, dass vertrauliche Informationen geschützt sind.
AD FS bietet standardmäßig keine direkte Verfügbarmachung oder Verfolgung von personenbezogenen Informationen als Teil des Verbunddiensts oder normaler Abläufe. Wenn die Ereignisprotokollierung und die Debug-Ablaufverfolgungsprotokollierung in AD FS aktiviert sind, kann die von Ihnen konfigurierte Anspruchsrichtlinie dazu führen, dass einige Anspruchstypen und ihre zugehörigen Werte personenbezogene Daten enthalten, die in den AD FS-Ereignis- oder Ablaufverfolgungsprotokollen protokolliert werden könnten.
Daher wird dringend empfohlen, die Zugriffssteuerung für die AD FS-Konfiguration und deren Protokolldateien zu erzwingen. Wenn solche Informationen nicht sichtbar sein sollen, sollten Sie den Anmeldeprozess deaktivieren oder personenbezogene oder vertrauliche Daten in Ihren Protokollen herausfiltern, bevor Sie sie mit anderen teilen.
Mit den folgenden Tipps können Sie verhindern, dass der Inhalt einer Protokolldatei unbeabsichtigt verfügbar gemacht wird:
Stellen Sie sicher, dass die AD FS-Ereignisprotokoll- und Ablaufverfolgungsprotokolldateien durch Zugriffssteuerungslisten (Access Control Lists, ACL) geschützt sind, die den Zugriff nur auf vertrauenswürdige Administratoren beschränken, die Zugriff auf sie benötigen.
Kopieren oder archivieren Sie Protokolldateien nicht mithilfe von Dateierweiterungen oder Pfaden, die mit einer Webanforderung problemlos bereitgestellt werden können. Die Dateinamenerweiterung .xml ist beispielsweise keine sichere Wahl. Sie können im Verwaltungshandbuch für Internetinformationsdienste (IIS) nachschlagen, um eine Liste der Erweiterungen anzuzeigen, die unterstützt werden können.
Wenn Sie den Pfad zur Protokolldatei ändern, müssen Sie unbedingt einen absoluten Pfad für den Speicherort der Protokolldatei angeben, der sich außerhalb des virtuellen Stammverzeichnisses (vroot) des Webhosts befinden sollte, damit von außen über einen Webbrowser nicht darauf zugegriffen werden kann.
AD FS Extranet Soft Lockout und AD FS Extranet Smart Lockout Protection
Im Falle eines Angriffs in Form von Authentifizierungsanforderungen mit ungültigen(ungültigen) Kennwörtern, die über den Webanwendungsproxy stammen, können Sie mit ad FS-Extranetsperrung Ihre Benutzer vor einer AD FS-Kontosperrung schützen. Zusätzlich zum Schutz Ihrer Benutzer vor einer AD FS-Kontosperrung schützt die AD FS-Extranetsperre auch vor Brute-Force-Angriffen zum Erraten von Kennwörtern.
Informationen zu Extranet Soft Lockout für AD FS unter Windows Server 2012 R2 finden Sie unter AD FS Extranet Soft Lockout Protection.
Informationen zum Extranet-Smart Lockout für AD FS unter Windows Server 2016 finden Sie unter AD FS Extranet Smart Lockout Protection.
SQL Server–spezifische Bewährte Methoden für sicherheit für AD FS
Die folgenden bewährten Sicherheitsmethoden gelten speziell für die Verwendung von Microsoft SQL Server® oder wiD (Windows Internal Database), wenn diese Datenbanktechnologien zum Verwalten von Daten im AD FS-Entwurf und -Bereitstellung verwendet werden.
Hinweis
Diese Empfehlungen sollen die SQL Server-Produktsicherheitsanleitungen erweitern, aber nicht ersetzen. Weitere Informationen zum Planen einer sicheren SQL Server-Installation finden Sie unter Sicherheitsüberlegungen für eine sichere SQL-Installation (https://go.microsoft.com/fwlink/?LinkID=139831).
Stellen Sie SQL Server immer hinter einer Firewall in einer physisch sicheren Netzwerkumgebung bereit.
Eine SQL Server-Installation sollte niemals direkt im Internet verfügbar gemacht werden. Nur Computer, die sich in Ihrem Rechenzentrum befinden, sollten ihre SQL Server-Installation erreichen können, die AD FS unterstützt. Weitere Informationen finden Sie in der Checkliste zu bewährten Sicherheitsmethoden (https://go.microsoft.com/fwlink/?LinkID=189229).
Führen Sie SQL Server unter einem Dienstkonto aus, anstatt die integrierten Standardsystemdienstkonten zu verwenden.
Sql Server wird standardmäßig häufig installiert und für die Verwendung eines der unterstützten integrierten Systemkonten konfiguriert, z. B. die Konten "LocalSystem" oder "NetworkService". Um die Sicherheit Ihrer SQL Server-Installation für AD FS zu verbessern, verwenden Sie nach Möglichkeit ein separates Dienstkonto für den Zugriff auf Ihren SQL Server-Dienst und aktivieren die Kerberos-Authentifizierung, indem Sie den Sicherheitsprinzipalnamen (SPN) dieses Kontos in Ihrer Active Directory-Bereitstellung registrieren. Dies ermöglicht die gegenseitige Authentifizierung zwischen Client und Server. Ohne Registrierung eines separaten Dienstkontos für SPN nutzt SQL Server NTLM für die Windows-basierte Authentifizierung, bei der nur der Client authentifiziert wird.
Minimieren Sie den Oberflächenbereich von SQL Server.
Aktivieren Sie nur die SQL Server-Endpunkte, die erforderlich sind. Sql Server stellt standardmäßig einen einzelnen integrierten TCP-Endpunkt bereit, der nicht entfernt werden kann. Für AD FS sollten Sie diesen TCP-Endpunkt für die Kerberos-Authentifizierung aktivieren. Um die aktuellen TCP-Endpunkte zu überprüfen, um festzustellen, ob zusätzliche benutzerdefinierte TCP-Ports einer SQL-Installation hinzugefügt werden, können Sie die Abfrageanweisungen "SELECT * FROM sys.tcp_endpoints" in einer Transact-SQL -Sitzung (T-SQL) verwenden. Weitere Informationen zur SQL Server-Endpunktkonfiguration finden Sie unter How To: Configure the Database Engine to Listen on Multiple TCP Ports (https://go.microsoft.com/fwlink/?LinkID=189231).
Vermeiden Sie die Verwendung der SQL-basierten Authentifizierung.
Verwenden Sie nur die Windows-Authentifizierung mit Ihrer SQL Server-Installation, um zu vermeiden, dass Kennwörter als Klartext über Ihr Netzwerk übertragen oder in Konfigurationseinstellungen gespeichert werden. Die SQL Server-Authentifizierung ist ein älteren Authentifizierungsmodus. Das Speichern von SQL-Anmeldeinformationen (SQL-Benutzernamen und -Kennwörter) bei Verwendung der SQL Server-Authentifizierung wird nicht empfohlen. Weitere Informationen finden Sie unter Authentifizierungsmodi (https://go.microsoft.com/fwlink/?LinkID=189232).
Bewerten Sie die Notwendigkeit einer zusätzlichen Kanalsicherheit in Ihrer SQL-Installation sorgfältig.
Auch wenn die Kerberos-Authentifizierung wirksam ist, bietet das SQL Server Security Support Provider Interface (SSPI) keine Sicherheit auf Kanalebene. Für Installationen, bei denen sich Server sicher in einem firewallgeschützten Netzwerk befinden, ist die Verschlüsselung der SQL-Kommunikation möglicherweise nicht erforderlich.
Obwohl die Verschlüsselung ein wertvolles Tool ist, um die Sicherheit zu gewährleisten, sollte sie nicht für alle Daten oder Verbindungen berücksichtigt werden. Wenn Sie entscheiden, ob Verschlüsselung implementiert werden soll, überlegen Sie, wie Benutzer auf Daten zugreifen. Wenn Benutzer über ein öffentliches Netzwerk auf Daten zugreifen, ist möglicherweise eine Datenverschlüsselung erforderlich, um die Sicherheit zu erhöhen. Wenn jedoch der gesamte Zugriff auf SQL-Daten von AD FS eine sichere Intranetkonfiguration umfasst, ist möglicherweise keine Verschlüsselung erforderlich. Jede Verwendung der Verschlüsselung sollte auch eine Wartungsstrategie für Kennwörter, Schlüssel und Zertifikate enthalten.
Wenn es ein Problem gibt, dass SQL-Daten möglicherweise über Ihr Netzwerk erkannt oder manipuliert werden, verwenden Sie die Internetprotokollsicherheit (Internet Protocol Security, IPsec) oder SSL (Secure Sockets Layer), um Ihre SQL-Verbindungen zu sichern. Dies kann jedoch negative Auswirkungen auf die SQL Server-Leistung haben, was sich in einigen Situationen auf die AD FS-Leistung auswirken oder einschränken kann. Beispielsweise kann die AD FS-Leistung bei der Tokenausstellung beeinträchtigt werden, wenn Attributsuchvorgänge aus einem SQL-basierten Attributspeicher für die Tokenausstellung wichtig sind. Sie können eine BEDROHUNG für SQL-Manipulationen besser beseitigen, indem Sie eine starke Umkreissicherheitskonfiguration verwenden. Eine bessere Lösung für die Sicherung Ihrer SQL Server-Installation besteht beispielsweise darin, sicherzustellen, dass sie für Internetbenutzer und -computer nicht zugänglich bleibt und nur von Benutzern oder Computern in Ihrer Rechenzentrumsumgebung zugänglich bleibt.
Weitere Informationen finden Sie unter Verschlüsseln von Verbindungen mit SQL Server oder SQL Server-Verschlüsselung.
Konfigurieren Sie den sicher gestalteten Zugriff mithilfe von gespeicherten Prozeduren, um alle SQL-basierten Nachschlagevorgänge von AD FS von SQL-gespeicherten Daten auszuführen.
Um eine bessere Dienst- und Datenisolation bereitzustellen, können Sie gespeicherte Prozeduren für alle Attributspeicher-Nachschlagebefehle erstellen. Sie können eine Datenbankrolle erstellen, für die Sie dann die Berechtigung zum Ausführen der gespeicherten Prozeduren erteilen. Weisen Sie dieser Datenbankrolle die Dienstidentität des AD FS-Windows-Diensts zu. Der AD FS-Windows-Dienst sollte keine andere SQL-Anweisung ausführen können, außer den entsprechenden gespeicherten Prozeduren, die für die Attributsuche verwendet werden. Durch das Sperren des Zugriffs auf die SQL Server-Datenbank auf diese Weise wird das Risiko eines Angriffs auf Rechteerweiterungen reduziert.