Workflowsicherheit
Windows Workflow Foundation (WF) ist in verschiedene Technologien integriert, z. B. Microsoft SQL Server und Windows Communication Foundation (WCF). Die Interaktion mit diesen Technologien kann zu Sicherheitsproblemen für den Workflow führen, falls diese nicht ordnungsgemäß durchgeführt wird.
Hinweis
Workflows beschreiben die Reihenfolge der Ausführung und Abhängigkeiten zwischen kurz- oder lang ausgeführten Aufgaben. Als Codeausführungsmechanismus sollte nur vertrauenswürdiger Code geladen und ausgeführt werden. Entwickler müssen sicherstellen, dass nur vertrauenswürdige Workflows mit Anwendungen mit WF verwendet werden.
Sicherheitsaspekte der Persistenz
Workflows, die eine Delay-Aktivität und Persistenz verwenden, müssen von einem Dienst erneut aktiviert werden. Windows AppFabric verwendet den Workflowverwaltungsdienst (WMS), um Workflows mit abgelaufenen Zeitgebern erneut zu aktivieren. WMS erstellt einen WorkflowServiceHost zum Hosten des erneut aktivierten Workflows. Wenn der WMS-Dienst beendet wird, werden beibehaltene Workflows nicht erneut aktiviert, wenn deren Timer ablaufen.
Die permanente Instanziierung sollte vor dem Zugriff durch böswillige Entitäten außerhalb der Anwendungsdomäne geschützt werden. Darüber hinaus sollten Entwickler sicherstellen, dass schädlicher Code nicht in derselben Anwendungsdomäne wie der Code für die permanente Instanziierung ausgeführt werden kann.
Die permanente Instanziierung sollte nicht mit erweiterten Berechtigungen (Administrator) ausgeführt werden.
Die Daten, die außerhalb der Anwendungsdomäne verarbeitet werden, sollten geschützt werden.
Anwendungen, die eine Sicherheitsisolation erfordern, sollten nicht dieselbe Instanz wie die Schemaabstraktion verwenden. Derartige Anwendungen sollten verschiedene Speicheranbieter oder Speicheranbieter verwenden, die für die Verwendung unterschiedlicher Speicherinstanziierungen konfiguriert wurden.
SQL Server-Sicherheitsaspekte
Wenn eine hohe Zahl an untergeordneten Aktivitäten, Speicherorten, Lesezeichen, Hosterweiterungen oder Bereichen verwendet wird oder wenn Lesezeichen mit sehr großen Nutzlasten verwendet werden, kann es zu einer Überlastung des Arbeitsspeichers kommen. Außerdem kann während des Persistenzvorgangs eine unangemessen hohe Menge an Datenbankspeicherplatz zugeordnet werden. Sie können dieses Risiko reduzieren, indem Sie die Sicherheit auf Objekt- und Datenbankebene verwenden.
Bei der Verwendung von SqlWorkflowInstanceStore muss der Instanzspeicher gesichert werden.
Vertrauliche Daten im Instanzspeicher sollten verschlüsselt werden. Weitere Informationen finden Sie unter SQL Server Encryption.
Da die Datenbank-Verbindungszeichenfolge häufig in einer Konfigurationsdatei enthalten ist, sollte Sicherheit auf Windows-Ebene (ACL) verwendet werden, um sicherzustellen, dass die Konfigurationsdatei (normalerweise "Web.Config") sicher ist und dass keine Anmelde- und Kennwortdaten in der Verbindungszeichenfolge enthalten sind. Die Windows-Authentifizierung sollte stattdessen zwischen der Datenbank und dem Webserver verwendet werden.
Überlegungen zu WorkflowServiceHost
In Workflows verwendete WCF-Endpunkte (Windows Communication Foundation) sollten geschützt werden. Weitere Informationen finden Sie unter WCF-Sicherheitsübersicht.
Sie können die Autorisierung auf Hostebene mit ServiceAuthorizationManager implementieren. Ausführliche Informationen finden Sie unter Vorgehensweise: Erstellen eines benutzerdefinierten Autorisierungs-Managers für einen Dienst.
Der ServiceSecurityContext für die eingehende Nachricht ist über den Zugriff auf OperationContext auch im Workflow verfügbar.
WF-Sicherheitspaket CTP
Das Microsoft WF-Sicherheitspaket CTP 1 (Community Technology Preview)-Vorschauversion bietet eine Reihe von Aktivitäten und deren Implementierung auf Basis von Windows Workflow Foundation in .NET Framework 4 (WF 4) und Windows Identity Foundation (WIF). Das Microsoft WF-Sicherheitspaket CTP 1 enthält beide Aktivitäten und deren Designer, die veranschaulichen, wie einfach verschiedene sicherheitsrelevante Szenarien mithilfe von Workflows aktiviert werden können, darunter:
Wechseln zu einer Clientidentität im Workflow
Workflowinterne Autorisierung, z. B. PrincipalPermission und Validierung von Ansprüchen
Authentifiziertes Messaging mit im Workflow angegebenen ClientCredentials, z. B. Benutzername/Kennwort oder ein Token, das von einem Sicherheitstokendienst (STS) abgerufen wurde
Übertragen eines Clientsicherheitstokens an einen Back-End-Dienst (anspruchsbasierte Delegierung) mithilfe von WS-Trust ActAs
