Neuigkeiten: Verbesserungen der Sicherheit

Letzte Änderung: Mittwoch, 14. April 2010

Gilt für: SharePoint Foundation 2010

Inhalt dieses Artikels
Anspruchsbasierte Identität und Authentifizierung
Automatische Kennwortänderung und verwaltete Konten
API mit effektiven Berechtigungen
Einmaliges Anmelden

In Microsoft SharePoint Foundation und Microsoft SharePoint Server 2010 wurden die Sicherheitsfeatures in Windows SharePoint Services 3.0 und Microsoft Office SharePoint Server 2007 weiterentwickelt und verbessert. In diesem Thema sind die neuen Features und Verbesserungen der Sicherheit in SharePoint Foundation und SharePoint Server 2010 zusammengefasst.

Anspruchsbasierte Identität und Authentifizierung

Die anspruchsbasierte Identität ist ein Identitätsmodell in SharePoint Foundation und SharePoint Server 2010. Dieses Identitätsmodell umfasst Features wie die Authentifizierung von Benutzern sowohl von Systemen, die auf Windows basieren, als auch von solchen, die nicht auf Windows basieren, mehrere Authentifizierungstypen, stärkere Authentifizierung in Echtzeit, eine größere Palette an Prinzipaltypen und die Delegierung von Benutzeridentitäten zwischen Anwendungen.

Wenn sich ein Benutzer an SharePoint Foundation und SharePoint Server 2010 anmeldet, wird das Benutzertoken überprüft und anschließend zum Anmelden an SharePoint verwendet. Das Benutzertoken ist ein von einem Forderungsanbieter ausgegebenes Sicherheitstoken. Es gibt fünf unterstützte Anmelde- oder Zugriffsmodi in SharePoint Foundation und SharePoint Server 2010:

  • Anmeldung im klassischen Windows-Modus

  • Anmeldung im Windows-Forderungsmodus

  • Passiver SAML-Anmeldemodus

  • Passive Anmeldung von Mitgliedern und Rollen in ASP.NET

  • Anonymer Zugriff

HinweisHinweis

Die passive SAML-Anmeldung beschreibt den Vorgang der Anmeldung. Wenn die Anmeldung für eine Webanwendung so konfiguriert ist, dass Token von einem vertrauenswürdigen Anmeldeanbieter akzeptiert werden, wird diese Art der Anmeldung als passive SAML-Anmeldung bezeichnet. Ein vertrauenswürdiger Anmeldeanbieter ist ein externer (extern für SharePoint) STS, dem SharePoint vertraut. Weitere Informationen zum Anmelden an SharePoint und zu den verschiedenen Anmeldemodi finden Sie unter Eingehende Ansprüche: Anmelden bei SharePoint.

Wenn Sie Ansprüche unterstützende Anwendungen erstellen, legt der Benutzer der Anwendung eine Identität als eine Gruppe von Ansprüchen vor. Ein Anspruch könnte zum Beispiel der Benutzername sein, ein anderer eine E-Mail-Adresse. Der Grundgedanke ist die Konfiguration eines externen Identitätssystems, damit die Anwendung alle benötigten Informationen erhält, um bei jeder Anfrage alles über den Benutzer zu wissen, sowie eine kryptografische Garantie dahingehend zu geben, dass die von der Anwendung empfangenen Identitätsdaten von einer vertrauenswürdigen Quelle stammen.

Bei diesem Modell ist eine einmalige Anmeldung viel leichter durchzusetzen, und die Anwendung ist nicht mehr für Folgendes verantwortlich:

  • Authentifizieren von Benutzern

  • Speichern von Benutzerkonten und Kennwörtern

  • Aufrufen von Unternehmensverzeichnissen zum Nachschlagen von Details zur Benutzeridentität

  • Integrieren in die Identitätssysteme anderer Plattformen oder Unternehmen

Bei diesem Modell trifft die Anwendung Entscheidungen zur Identität basierend auf den vom Benutzer übermittelten Ansprüchen. Hierbei kann es sich von einer einfachen Anwendungspersonalisierung mit dem Vornamen des Benutzers bis zur Autorisierung des Benutzers für den Zugriff auf hochwertigere Features und Ressourcen in der Anwendung um alles Mögliche handeln.

Weitere Informationen zur anspruchsbasierten Identität und zu Forderungsanbietern finden Sie unter Anspruchsbasierte Identität – Übersicht und Konzepte und Anspruchsanbieter.

Benutzertoken der ASP.NET-Mitgliedschaft wird zum Forderungssicherheitstoken konvertiert

In SharePoint Foundation muss ein ASP.NET-Mitgliedschaftsanbieter die erforderliche System.Web.Security.Membership.ValidateUser-Methode implementieren. Wenn ein Benutzername angegeben wird, gibt das Rollenanbietersystem eine Liste der Rollen zurück, zu denen der Benutzer gehört. Der Mitgliedschaftsanbieter ist für die Überprüfung der Anmeldeinformationen mithilfe der System.Web.Security.Membership.ValidateUser-Methode (nun in SharePoint Foundation erforderlich) verantwortlich.

Das tatsächliche Benutzertoken wird jedoch von einem SharePoint Foundation-Sicherheitstokendienst (Security Token Service, STS) erstellt. Der SharePoint Foundation-STS erstellt das Forderungssicherheitstoken aus dem vom Mitgliedschaftsanbieter überprüften Benutzernamen und aus der Menge der dem Benutzernamen zugeordneten Gruppenmitgliedschaften, die vom Mitgliedschaftsanbieter bereitgestellt werden.

HinweisHinweis

Weitere Informationen zu STS finden Sie unter Anspruchsbasierte Identität – Übersicht und Konzepte. Weitere Informationen zum Anmelden an SharePoint finden Sie unter Eingehende Ansprüche: Anmelden bei SharePoint.

Automatische Kennwortänderung und verwaltete Konten

Das neue Feature für automatische Kennwortänderung in SharePoint Foundation ermöglicht Ihnen das Aktualisieren und Bereitstellen von Kennwörtern, ohne dass manuelle Aufgaben zur Kennwortaktualisierung in mehreren Konten, Diensten und Webanwendungen ausgeführt werden müssen. Dadurch wird das Verwalten von Kennwörtern in SharePoint Foundation einfacher. Mit dem Feature für automatische Kennwortänderung können Sie bestimmen, ob ein Kennwort bald abläuft, und das Kennwort zurücksetzen, indem Sie eine lange, kryptographisch starke, zufällige Zeichenfolge verwenden.

Sie müssen verwaltete Konten verwenden, um das Feature für automatische Kennwortänderung implementieren zu können. Verwaltete Konten in SharePoint Foundation verbessern die Sicherheit und stellen die Anwendungsisolierung sicher.

Weitere Informationen zur API mit verwalteten Konten finden Sie hier:

API mit effektiven Berechtigungen

In Windows SharePoint Services 3.0 ist es schwierig, die effektive Berechtigung eines Benutzers für sicherungsfähige Objekte abzurufen, z. B. SPWeb, SPList, SPListItem usw. Im Laufe der Zeit kann die Website über sehr komplexe Berechtigungseinstellungen verfügen, besonders dann, wenn zahlreiche Objekte die Berechtigungen nicht von übergeordneten Elementen erben (eindeutiger Umfang). Für Administratoren ist es schwierig, die effektive Berechtigung eines Benutzers und die Art und Weise zu ermitteln, mit der der Benutzer die Berechtigung für ein bestimmtes Objekt erhält. In SharePoint Foundation wurde ein neuer Menübandbefehl mit dem Namen Berechtigungen überprüfen und eine Gruppe von APIs für effektive Berechtigungen eingeführt, die eine rasche Enumeration aller Rollenzuweisungen für einen bestimmten Benutzer in einem spezifischen Bereich ermöglichen.

Die SPSecurableObject-Klasse legt eine neue GetUserEffectivePermissionsInfo()-Methode offen. Mit dieser Methode wird ein Objekt mit ausführlichen Informationen zu den effektiven Berechtigungen, die ein bestimmter Benutzer im aktuellen Bereich besitzt, sowie zu den mit diesem Benutzer in diesem Bereich verbundenen Rollenzuweisungen abgerufen. Diese Methode schließt keine Informationen zu der Sicherheitsrichtlinie der Webanwendung in die Berechtigungsmaske ein, falls der angegebene Benutzer zu einer Richtlinien gehört, die als Konto fungiert als System gekennzeichnet ist. Diese Methode steht Benutzern zur Verfügung, die die Berechtigung EnumeratePermissions besitzen. Weitere Informationen zu EnumeratePermissions finden Sie in der SPBasePermissions-Enumeration.

Von der SPSecurableObject-Klasse wird auch eine neue GetUserEffectivePermissions()-Methode offen gelegt. Für den aktuellen Bereich gibt diese Methode ein SPBasePermissions-Objekt zurück, das die effektive Berechtigungsmaske des Benutzers darstellt.

Die SPWeb-Klasse enthält eine neue Methode mit dem Namen GetWebsAndListsWithUniquePermissions(), mit der Websitesammlungsadministratoren eine Sammlung von Webseiten und Listen abrufen können, die selbst eindeutige Berechtigungen besitzen oder Elemente mit eindeutigen Berechtigungen enthalten.

Die API zeigt folgendes Verhalten: Sie gibt von der Start-URL eine Liste der URLs von Containern zurück (z. B. SPWeb oder SPList), in denen ein eindeutiger Sicherheitsbereich vorhanden ist (in dem ein Unterbrechen der Vererbung von Rollen auftritt), einschließlich aller Container, die keinen eindeutigen Sicherheitsbereich besitzen, die jedoch mindestens ein untergeordnetes Element mit eindeutigen Sicherheitsbereichen enthalten.

Die SPList-Klasse enthält eine neue GetItemsWithUniquePermissions()-Methode, mit der Websitesammlungsadministratoren alle Listenelemente mit eindeutigen Berechtigungen abrufen können.

Weitere Informationen zu diesen APIs finden Sie unter Microsoft.SharePoint.

HinweisHinweis

In diesem Thema werden nur einige der neuen APIs vorgestellt. Es werden nicht alle neuen sicherheitsrelevanten APIs aufgeführt, die SharePoint Foundation hinzugefügt wurden.

Einmaliges Anmelden

Die Funktion Einmaliges Anmelden ersetzt das Feature für einmaliges Anmelden von Microsoft Office SharePoint Server 2007. Einmaliges Anmelden ist ein Dienst, der Speicherung und Zuordnung von Anmeldeinformationen wie Kontonamen und Kennwörtern bereitstellt. Er ermöglicht die sichere Speicherung von Daten, die Anmeldeinformationen für die Verbindung mit externen Systemen enthalten, und die Zuordnung dieser Anmeldeinformationen zu einer bestimmten Identität oder Gruppe von Identitäten. Häufig wird in Lösungen die Authentifizierung bei einem externen System versucht, in dem der aktuelle Benutzer anders bekannt ist oder ein anderes Konto zur Authentifizierung besitzt. In diesen Fällen kann Einmaliges Anmelden verwendet werden, um die vom externen System benötigten Anmeldeinformationen zu speichern und zuzuordnen. Der Dienst Einmaliges Anmelden kann so konfiguriert werden, dass mehrere Benutzer über einen einzigen Satz von Anmeldeinformationen auf ein externes System zugreifen können.

Weitere Informationen zu Einmaliges Anmelden finden Sie unter Secure Store Service.

Siehe auch

Konzepte

Erste Schritte mit dem sicherheits- und anspruchsbasierten Identitätsmodell