Sicherheitsempfehlungen für SSO

Mit dem Enterprise Single Sign-On -System (SSO) können Benutzer eine Verbindung mit verschiedenen Systemen herstellen, indem sie nur einen Satz Anmeldeinformationen verwenden. BizTalk Server nutzt das SSO-System als Speicher für vertrauliche Informationen. Obwohl BizTalk Server automatisch installiert wird, wenn Sie die BizTalk Server Runtime installieren, können Sie auch Enterprise Single Sign-On als eigenständige Komponente installieren, unabhängig von Ihrer BizTalk Server Umgebung. Weitere Informationen zum einmaligen Anmelden für Unternehmen finden Sie unter Verwenden des einmaligen Anmeldens. Sie sollten die folgenden Empfehlungen für das Sichern und Bereitstellen von Diensten und Ressourcen für Einmaliges Anmelden für Unternehmen (SSO) in Ihrer Umgebung beachten:

Allgemeine Bereitstellungsempfehlungen für SSO

  • In der gesamten Umgebung darf es nur einen Server für den geheimen Hauptschlüssel und nur eine SSO-Datenbank geben, selbst wenn die Umgebung mehrere BizTalk-Gruppen umfasst. Diese beiden Server müssen vor allen anderen BizTalk- und SSO-Servern konfiguriert werden.

  • In der Umgebung muss es einen Zeitserver geben, damit die Synchronisierung aller SSO-Server sichergestellt ist. Sind die Uhren der SSO-Server nicht synchronisiert, ist die Sicherheit der Umgebung eventuell gefährdet.

  • Angesichts der Tatsache, dass Ihre gesamte Umgebung nur einen Server für den geheimen Hauptschlüssel umfasst, empfiehlt es sich, eine Aktiv/Passiv-Clusterkonfiguration für diesen Server zu verwenden. Weitere Informationen zum Clustern des master Geheimservers finden Sie unter Clustern für den Master Secret Server.

  • Der Server für den geheimen Hauptschlüssel speichert den Verschlüsselungsschlüssel, den das SSO-System zum Verschlüsseln der Informationen in der SSO-Datenbank verwendet. Auf diesem Computer sollten keine anderen Produkte installiert oder konfiguriert werden.

    Hinweis

    Der Computer, auf dem Sie den Server für den geheimen Hauptschlüssel installieren und konfigurieren, muss kein Server sein.

  • Der Server für den geheimen Hauptschlüssel sollte Zugriff auf einen Ordner auf einem Wechseldatenträger oder im NTFS-Dateisystem haben, um den geheimen Hauptschlüssel sichern und wiederherstellen zu können. Ergreifen Sie bei der Verwendung von Wechseldatenträgern geeignete Schutzmaßnahmen. Schützen Sie die Datei und den Ordner, wenn Sie den geheimen Hauptschlüssel auf einem NTFS-Dateisystem sichern. Nur der SSO-Administrator sollte Zugriff auf diese Datei haben.

  • Sie sollten sofort nach der Erstellung des geheimen Hauptschlüssels durch den Server eine Sicherungskopie des Schlüssels anlegen. Damit stellen Sie sicher, dass Sie die Daten in der SSO-Datenbank beim Ausfall des Servers für den geheimen Hauptschlüssel wiederherstellen können. Weitere Informationen zum Sichern des master Geheimnisses finden Sie unter Verwalten des Geheimen Hauptschlüssels.

  • Es wird empfohlen, den aktuellen geheimen Hauptschlüssel regelmäßig, z. B. ein Mal im Monat, zu sichern oder neu zu generieren. Ohne den geheimen Hauptschlüssel können Sie keine Informationen aus der SSO-Datenbank abrufen. Weitere Informationen zum Sichern und Wiederherstellen des master Geheimnisses finden Sie unter Verwalten des Geheimen Hauptschlüssels.

Sicherheitsempfehlungen für SSO-Gruppen und -Konten

  • Besonders für die SSO-Administrator- und SSO-Partneradministratorgruppen wird empfohlen, Windows-Gruppen statt einzelner Benutzerkonten zu verwenden. Diesen Gruppen müssen immer mindestens zwei Benutzerkonten als Gruppenmitglieder zugeordnet sein.

  • Die SSO-Laufzeitdienst-Konten und die SSO-Administratorkonten sollten unterschiedliche Konten sein, selbst wenn sie Mitglieder derselben Gruppe SSO-Administratoren sind. Die SSO-Administratoren, die administrative Tasks wie das Erstellen und Sichern des geheimen Hauptschlüssels durchführen, müssen Windows-Administratoren sein. Bei den SSO-Laufzeitdienst-Konten muss es sich dagegen nicht um Windows-Administratoren handeln.

    Wichtig

    Die Benutzerrechte von Windows-Administratoren haben keinen Vorrang vor den Benutzerrechten des SSO-Administrators. Zur Durchführung von SSO-Aufgaben auf Administratorebene müssen Sie Mitglied der SSO-Administratorengruppe sein, selbst wenn Sie bereits Windows-Administrator sind.

  • Bei Verwendung von SSO-Tickets müssen Domänenkonten verwendet werden, die von den Computer in der Verarbeitungsdomäne (der Domäne, in der sich die SSO-Servers befinden) erkannt werden.

  • Es wird empfohlen ein eindeutiges Dienstkonto für den SSO-Dienst zu verwenden, der dem Server für den geheimen Hauptschlüssel entspricht.

  • Das SSO-Administratorkonto ist ein Konto mit weit reichenden Berechtigungen im SSO-System und gleichzeitig das SQL Server-Administratorkonto für den SQL Server mit der SSO-Datenbank. Sie sollten dedizierte Konten für SSO-Administratoren anlegen und diese Konten nicht für andere Zwecke verwenden. Sie sollten die Anzahl der Mitglieder in der SSO-Administratorengruppe auf die Konten beschränken, die für Betrieb und Wartung des SSO-Systems verantwortlich sind.

  • Sie müssen die BizTalk-Administratorengruppe manuell zur SSO-Partneradministratorengruppe hinzufügen, damit die BizTalk-Administratoren das SSO-System zum Speichern der Konfigurationsinformationen für die Adapter in der SSO-Datenbank nutzen können. Nur die für die Adapterverwaltung zuständigen BizTalk-Administratoren müssen Mitglieder der SSO-Partneradministratorengruppe sein. BizTalk-Administratoren müssen keine SSO-Administratoren sein.

Sicherheitsempfehlungen für SSO-Bereitstellungen

  • Wenn Ihr Netzwerk die Kerberos-Authentifizierung unterstützt, sollten Sie alle SSO-Server registrieren. Wird die Kerberos-Authentifizierung zwischen dem Server für den geheimen Hauptschlüssel und der SSO-Datenbank verwendet, müssen Sie Dienstprinzipalnamen (SPNs) auf dem Computer mit SQL Server konfigurieren, auf dem sich die SSO-Datenbank befindet. Weitere Informationen zum Konfigurieren von Dienstprinzipalnamen finden Sie unter Dienstprinzipalnamen (Service Principal Names, SPN).

  • Wenn sich der master Geheimserver bei der Ausführung von Windows Server 2008 SP2 oder Windows Server 2008 R2 in einer anderen Domäne befindet als die anderen SSO-Server und die SSO-Datenbank, müssen Sie die RPC-Sicherheit (wie sie für die DTC-Authentifizierung zwischen Computern verwendet wird) auf dem master geheimen Server auf den SSO-Servern (Verarbeitungscomputer in der Verarbeitungsdomäne) deaktivieren. und in der SSO-Datenbank. RPC-Sicherheit ist ein DTC-Feature in Windows Server 2008 SP2 und Windows Server 2008 R2. Wenn Sie die RPC-Sicherheit deaktivieren, wird die Sicherheitsstufe der DTC-Authentifizierung für RPC-Aufrufe auf eine in Microsoft Windows Server 2003 verfügbare Stufe herabgesetzt.

  • SSO-Administratoren sollten regelmäßig das Ereignisprotokoll des Servers für den geheimen Hauptschlüssel und des SSO-Servers auf SSO-Überwachungsereignisse prüfen.

  • Zusätzlich zu Firewalls sollten Sie IPSec (Internet Protocol Security) oder SSL (Secure Sockets Layer) zwischen allen SSO-Servern und der SSO-Datenbank verwenden. Weitere Informationen zur Verwendung von SSL findest du unter Aktivieren von verschlüsselten Verbindungen mit der Datenbank-Engine. Weitere Informationen zur Verwendung von SSL zwischen allen SSO-Servern und der SSO-Datenbank finden Sie unter Aktivieren von SSL für einmaliges Anmelden.

Umkreisnetzwerk

Befolgen Sie die folgenden Empfehlungen, wenn Sie Internetinformationsdienste (Internet Information Services, IIS) und Einmaliges Anmelden (SSO) für Unternehmen ausführen:

  • Befindet sich IIS in einem Umkreisnetzwerk (auch als DMZ, Demilitarized Zone oder überwachtes Subnetz bezeichnet), stellen Sie hinter der Firewall einen weiteren IIS-Server zum Herstellen einer Verbindung mit dem SSO-System bereit.

  • Öffnen Sie den Port für Remoteprozeduraufrufe (RPC) nicht in IIS.

SQL Server-Zugriff

Alle SSO-Server greifen auf die vom SQL-Server gehostete SSO-Datenbank zu. Weitere Informationen zum Schützen SQL Server Datenbanken finden Sie unter Schützen SQL Server.

Es empfiehlt sich, die Datenübertragung zwischen den SSO-Servern und der SSO-Datenbank durch SSL (Secure Sockets Layer) und/oder IPSec (Internet Protocol Security) zu sichern. Weitere Informationen zur Verwendung von SSL findest du unter Aktivieren von verschlüsselten Verbindungen mit der Datenbank-Engine.

Wenn Sie SSL nur für die Verbindung zwischen dem SSO-Server und der SSO-Datenbank aktivieren möchten, können Sie mit dem Dienstprogramm „ssoconfig“ die SSL-Unterstützung auf jedem SSO-Server festlegen. Durch diese Option kann SSL beim Einmaligen Anmelden (SSO) immer beim Zugriff auf die SSO-Datenbank verwendet werden. Weitere Informationen finden Sie unter Aktivieren von SSL für einmaliges Anmelden.

Sichere Kennwörter

Es ist sehr wichtig, dass Sie sichere Kennwörter für alle Konten verwenden. Dies gilt besonders für die Konten, die Mitglieder der Gruppe SSO-Administratoren sind, da diese Benutzer Kontrolle über das gesamte SSO-System haben.

SSO-Administratorkonten

Es empfiehlt sich, unterschiedliche Dienstkonten für die SSO-Dienste zu verwenden, die auf verschiedenen Computern ausgeführt werden. Sie sollten nicht das SSO-Administratorkonto verwenden, das Verwaltungsaufgaben wie das Erstellen und Sichern des geheimen Hauptschlüssels für den SSO-Dienst durchführt. Während die SSO-Dienstkonten keine lokalen Administratoren auf dem Computer sein sollten, muss der SSO-Administrator, der die Verwaltungsaufgaben durchführt, bei manchen Vorgängen ein lokaler Administrator auf dem Computer sein.

Server für den geheimen Hauptschlüssel

Sie sollten den Server für den geheimen Hauptschlüssel unbedingt sichern und sperren. Sie sollten diesen Server nicht als Verarbeitungsserver verwenden. Der einzige Zweck dieses Servers sollte es sein, den geheimen Hauptschlüssel zu speichern. Gewährleisten Sie die physische Sicherheit dieses Computers, und geben Sie nur SSO-Administratoren Zugriff darauf.

Kerberos

Kerberos wird von SSO unterstützt und sollte dafür eingerichtet werden. Wenn Sie Kerberos für SSO einrichten möchten, müssen Sie einen Dienstprinzipalnamen (Service Principal Name, SPN) für den SSO-Dienst registrieren. Beim Einrichten von Kerberos verwendet SSO diesen SPN standardmäßig für die Authentifizierung der Komponenten, die den SSO-Dienst nutzen. Sie sollten die Kerberos-Authentifizierung zwischen den administrativen SSO-Subdiensten und dem SSO-Server einrichten. Sie können die Kerberos-Authentifizierung auch unter den SSO-Servern sowie zwischen den SSO-Servern und dem SQL-Server mit der SSO-Datenbank verwenden.

Weitere Informationen finden Sie unter:

Delegierung

Bei Verwendung von Windows Server 2008 SP2 oder Windows Server 2008 R2 ist es möglich, die eingeschränkte Delegierung zu verwenden, es wird jedoch empfohlen, die Delegierung nicht zu verwenden, um die Aufgaben des Einzel-Sign-On-Administrators auszuführen. Ebenso wird vom Delegieren zusätzlicher Aufgaben oder Benutzerrechte an den SSO-Administrator abgeraten.

Überwachung

Die Überwachung ist ein wichtiger Mechanismus für die Nachverfolgung von Informationen in einer Umgebung. Einmaliges Anmelden (SSO) für Unternehmen überwacht alle in der SSO-Datenbank durchgeführten Vorgänge. Dabei werden die Ereignis- und Überwachungsprotokolle der Datenbank verwendet. SSO bietet zwei Überwachungsebenen für die SSO-Server:

  • Positive Überwachungsebenen dienen zur Überwachung erfolgreicher Vorgänge.

  • Negative Überwachungsebenen dienen zur Überwachung fehlgeschlagener Vorgänge.

    SSO-Administratoren können die positiven und negativen Überwachungsebenen festlegen, die ihren Unternehmensrichtlinien entsprechen.

    Sie können positive und negative Überwachungen auf eine der folgenden Ebenen festlegen:

    0 = Keine: Diese Ebene sendet keine Überwachungsnachrichten.

    1 = Niedrig

    2 = Mittel

    3 = Hoch Diese Ebene sendet so viele Überwachungsnachrichten wie möglich.

    Der Standardwert für die positive Überwachung ist 0 (keine), und der Standardwert für die negative Überwachung ist 1 (niedrig). Abhängig von der Überwachungsebene, die Sie für Ihr SSO-System wünschen, müssen Sie diese Werte eventuell ändern.

Wichtig

Bei der Überwachung von Einmaliges Anmelden (SSO) für Unternehmen werden vom SSO-Dienst generierte Nachrichten gesendet. Es handelt sich nicht um eine Sicherheitsüberwachung, und daher speichert das SSO-System die Informationen nicht im Sicherheitsprotokoll des Ereignisprotokolls. Das SSO-System speichert die SSO-Überwachungsnachrichten vielmehr direkt im Anwendungsereignisprotokoll.

Überwachung auf Datenbankebene

Bei der Überwachung auf Datenbankebene verfolgt das SSO-System die für die SSO-Datenbank durchgeführten Vorgänge in den Überwachungstabellen der Datenbank nach. Die Größe dieser Überwachungstabellen wird auf der SSO-Systemebene definiert. Sie können die Überwachung für gelöschte Partneranwendungen, für gelöschte Zuordnungen und für durchgeführte Suchen nach Anmeldeinformationen festlegen. Standardmäßig ist die Größe der Überwachungen auf 1.000 Einträge festgelegt. SSO-Administratoren können diese Größe an ihre Unternehmensrichtlinien anpassen.

Verwenden von SSO-Konten

In diesem Abschnitt werden bewährte Methoden bei der Verwendung von Domänen- und lokalen Gruppen sowie Einzelkonten im System für Einmaliges Anmelden für Unternehmen (SSO) beschrieben.

Windows-Domänengruppen und -Domänenkonten

Bei der Verwendung von Windows-Domänengruppen gelten folgende Empfehlungen:

  • Verwenden Sie Domänengruppen und Domänenkonten.

  • Bei Verwendung von Windows Server 2008 SP2 oder Windows Server 2008 R2 kann das ENTSSO-Dienstkonto für die Ausführung unter dem Netzwerkdienstkonto konfiguriert werden. Dies wird jedoch aus Sicherheitsgründen nicht empfohlen, da dem Netzwerkdienstkonto dann die SSO-Administratorrechte zugewiesen werden müssen. Verwenden Sie stattdessen ein eindeutiges Domänendienstkonto als ENTSSO-Dienstkonto.

  • Verwenden Sie eine Domänengruppe für SSO-Administratoren. Sie sollten kein einzelnes Domänenkonto als SSO-Administrator festlegen, da Sie dieses Konto nicht in ein anderes Einzelkonto ändern können.

  • Sie können zwar ein einzelnes Domänenkonto als SSO-Partneradministrator festlegen, sollten aber eine Domänengruppe verwenden.

  • Sie können zwar ein einzelnes Domänenkonto als Anwendungsadministrator festlegen, sollten aber eine Domänengruppe verwenden.

  • Sie müssen Domänengruppen für das Anwendungsbenutzerkonto verwenden. Das SSO-Anwendungsbenutzerkonto unterstützt Einzelkonten nicht.

  • Für jedes dieser SSO-Zugriffskonten können mehrere Konten angegeben werden.

Weitere Informationen

Ports für enterprise Single Sign-On Servers– Benutzerberechtigungen für mindeste Sicherheit