Sichern von Hosting und Persistenz

Der Persistenzspeicher ist eine Schlüsselkomponente der Windows Server AppFabric-Architektur. Dieser Informationsspeicher unterstützt die Dauerhaftigkeit von WF (Windows Workflow Foundation)-Instanzen, wenn diese die verschiedenen Ausführungsphasen durchlaufen. Sie können persistente Workflowdienstinstanzen mithilfe von Verwaltungstools in AppFabric manipulieren. Sie müssen Benutzern von AppFabric, die die Verwaltungstools ausführen, sowie Anwendungen zur Laufzeit Berechtigungen für den Persistenzspeicher erteilen, damit diese Daten aus diesem Informationsspeicher lesen und in ihn schreiben können. Sie müssen außerdem den Zugriff auf den Persistenzspeicher auf den Verwaltungs- und Anwendungsbereichsebenen steuern.

Ein wichtige Überlegung zur Sicherheit betrifft den Hostingort einer Anwendung. Anwendungsisolierung schützt davor, dass Daten durch andere Anwendungen angezeigt werden oder dass ein Zugriff darauf erfolgt. Außerdem ist die Steuerung der Identität der Anwendung für den Downstreamzugriff auf Ressourcen ein Schlüsselaspekt des AppFabric-Sicherheitsmodells. Diese Identität betrifft den Sicherheitsprinizipal, den die Anwendung beim Zugriffsversuch auf den Persistenzspeicher verwendet.

Hosting und Persistenz fallen in die Anwendungs- und Verwaltungsbereiche und müssen in jedem Bereich unterschiedlich gesichert werden. Bestimmte Berechtigungen werden durch den Einschluss in verschiedene Sicherheitsgruppen vorgeschrieben. Der Anwendungssicherheitsbereich wirkt sich auf die Berechtigungen aus, über die eine Anwendung zur Laufzeit verfügt, und wird der Konzeptrolle Anwendungsserverbenutzer zugeordnet. Der Verwaltungssicherheitsbereich wirkt sich auf die Tools und die zugehörigen Vorgänge aus, die ein Administrator und Systemdienste ausführen können. Diese Berechtigungen werden den konzeptionellen Rollen Anwendungsserveradministratoren und Anwendungsserverbeobachter zugeordnet.

Sichern der Persistenzdaten

Wenn eine Instanz eines Dienst persistent gespeichert wird, wird ihr Systemstatus im Persistenzspeicher gespeichert. Anwendungen erfassen und übertragen häufig persönlich identifizierbare Informationen oder andere vertrauliche Daten. Wenn diese Daten beim persistenten Speichern eines Diensts im Anwendungsstatus enthalten sind, wird er im Persistenzspeicher gespeichert. Mehrere Server, Sites und Anwendungen können einen Persistenzspeicher gemeinsam verwenden. Entwurfsbedingt werden Persistenzdaten für Server und Sites aggregiert, die einen Informationsspeicher verwenden, um die Verwaltung des Aktivitätsstatus von möglicherweise Tausenden von Instanzen eines Diensts in einer großen Umgebung zu vereinfachen. Auf diese Weise kann eine Instanz eines Diensts während ihrer Ausführung auf einem AppFabric-Server persistent gespeichert werden und dann auf einem anderen Server fortgesetzt werden, wenn dies die Lastenausgleichskriterien verlangen.

Nachdem die Daten im Persistenzspeicher gespeichert wurden, sind sie für alle Mitglieder der Datenbankrolle AS_Administrators und alle Mitglieder der SQL Server-Rollen sysadmin und dbo sichtbar. Da Persistenzdaten für unbeabsichtigte oder zielgerichtete Angriffe anfällig sind, müssen Sie das Risiko sorgfältig verringern, indem Sie die Berechtigungen richtig verwalten.

Es gibt die folgenden Möglichkeiten, die Daten im Persistenzspeicher zu sichern:

  • Verwenden verschiedener Persistenzspeicher. Die können einen Alternativpersistenzspeicher auf dem gleichen oder einem anderen Server mithilfe von AppFabric-Cmdlets erstellen und die Seite AppFabric Persistenzdatenbank-Konfiguration verwenden, um ihn dann zu konfigurieren. Anschließend können Sie bestimmte Anwendungen für die Verwendung dieses Informationsspeichers konfigurieren. Auf diese Weise erhalten die angegebenen Anwendungen einen privaten Persistenzdatenspeicher, auf den keine anderen Anwendungen zugreifen können.

  • Trennen des Persistenz- und Überwachungsspeichers in zwei separate Informationsspeicher. Standardmäßig werden die Tabelle und die Entitäten für die Persistenz- und Überwachungsspeicher während der Installation im Informationsspeicher DefaultApplicationServerExtensions erstellt. Sie können einen Informationsspeicher ausschließlich für Persistenz und den anderen ausschließlich für Überwachung reservieren. Auf diese Weise wird der Zugriff auf einen dualen Speicher durch Anwendungen und Benutzer in den Verwaltungs- und Anwendungsbereichen und folglich auch der Zugriff auf alle Tabellen für Persistenz und Überwachung verhindert.

  • Verwenden von Windows-Gruppen und SQL Server-Rollen. Der Zugriff auf den SQL Server-Persistenzspeicher wird durch die SQL Server-Datenbankrollen implementiert. Während der Initialisierung eines Instanzspeichers kann der Administrator Windows-Gruppen in die SQL-Rollen Instanzspeicherbenutzer, Instanzspeicherleser und Instanzspeicheradministratoren einfügen. Weitere Informationen zum Sichern von Daten in Persistenzspeichern mithilfe von Windows-Gruppen und SQL Server-Rollen finden Sie unter Sicherheitskonfiguration für Persistenzspeicher.

  • Manipulieren der Persistenzfeatures. Sie können die Erweiterungen verwenden, die IIS-Manager durch AppFabric hinzugefügt werden, um Persistenzfeatures für einen bestimmten Workflowdienst, für alle Workflowdienste in einer Anwendung, für alle Anwendungen in einer Website oder für alle Websites auf einem Server zu aktivieren bzw. zu deaktivieren. Sie können eine Persistenzrichtlinie auf einer höheren Ebene definieren und deren Einstellungen an alle niedrigeren Ebenen in der IIS- und WAS-Hierarchie vererben.

  • Verwenden verschiedener Anwendungspoolidentitäten. Indem verschiedene Identitäten für IIS-Anwendungspools verwendet werden, können Sie SQL Server-Berechtigungen für den gesamten Persistenzspeicher oder für einzelne darin enthaltene Entitäten einschränken oder erweitern. Dies ist eine detaillierte Sicherheitstechnik, die Sie auf IIS- und SQL Server-Ebene ausführen. Sie wird durch die AppFabric-Tools nicht direkt unterstützt.

Sichern des Hostings

Sie verwenden Prozessisolierung, um die AppFabric-Verwaltungsbereichsdienste mit hohen Berechtigungen (z. B. den Ereignisauflistungsdienst und den Workflowverwaltungsdienst) von Anwendungsarbeitsprozessen des Anwendungsbereichs mit geringen Berechtigungen zu trennen. Die AppFabric-Dienste werden im Verwaltungsbereich ausgeführt und besitzen Vollzugriff auf ihre zugehörigen Überwachungs- und Persistenzspeicher. Alle Anwendungsarbeitsprozesse und Benutzer werden im Anwendungsbereich ausgeführt, und zwar normalerweise im Kontext einer Anwendungspoolidentität.

Im Anwendungsbereich bietet weitere Hostingisolierung eine detailliertere Sicht der Sicherheit. Eine Anwendung enthält mindestens einen .NET Framework-Dienst. Diese Dienste werden alle im gleichen Prozess ausgeführt. Damit diese .NET Framework-Dienste voreinander gesichert werden, können sie im Kontext verschiedener Anwendungsdomänen ausgeführt werden. Ein .NET Framework-Prozess enthält mindestens eine .NET Framework-Anwendungsdomäne. Jede dieser Domänen stellt eine isolierte Umgebung dar, in der Anwendungen ausgeführt werden. In einem IIS-Anwendungspool können mehrere Anwendungen gleichzeitig ausgeführt werden, wenn diese für die gemeinsame Verwendung eines Anwendungspools konfiguriert sind. Daher sind Anwendungsdomänen eine einfache Methode zum Durchsetzen der Ausführungsisolierung, ohne dass Mehraufwand für einen weiteren Prozess mit allen seinen Ressourcen anfällt.

Wenn Sie ein isoliertere Hostinglösung benötigen, konfigurieren Sie jede Anwendung für die Ausführung in ihrem eigenen Anwendungspool mit ihrer eigenen Identität. Dies ist eine Möglichkeit, Anwendungen verschiedene Identitäten zuzuweisen, wenn sie auf den Persistenzspeicher zugreifen. IIS fügt alle diese Identitäten zur Laufzeit in die Windows-Sicherheitsgruppe IIS_IUSRS ein. Die Ausführung in einem separaten Prozessraum ist unter Sicherheitsaspekten fast identisch mit der Ausführung in einer separaten Anwendungsdomäne, da keine andere Anwendung auf den Code oder die Daten einer angegebenen Anwendung zugreifen kann. Bedenken Sie, dass mit zusätzlichen Prozessen ein Mehraufwand für zusätzliche Betriebssystemressourcen und Kontextwechsel für den Prozessor verbunden ist, weil jeder Prozess seinen eigenen Teil der CPU besitzt.

  2011-12-05