Zusammenfassung: In diesem Artikel werden hauptsächlich die Arten von Sicherheitsmodellen für ASP.NET WEB-Anwendungen vorgestellt, ihre Vor- und Nachteile verglichen und ein Auswahlmechanismus vorgeschlagen.
Schlüsselwörter: Sicherheitsmodell, vertrauenswürdiges Untermodell, Simulation/Delegierung, Untermodell, ASP.NET-WEB-Anwendung
1.Vorwort
ASP.NET WEB-Anwendungen gehören normalerweise zu einer mehrschichtigen Architektur. Im Allgemeinen kann die logische Struktur in eine Präsentationsschicht, eine Geschäftslogikschicht und eine Datenzugriffsschicht unterteilt werden. Um auf Anwendungsressourcen zuzugreifen, muss die Identitätsauthentifizierung und Autorisierung des Clients mehrere Schichten umfassen. Ebene. In diesem Artikel wird hauptsächlich das Ressourcenzugriffssicherheitsmodell von SP.NET-Anwendungen erläutert.
2. Identifizierung des Ressourcenzugriffs
Zu den typischen Ressourcen, die Clients von WEB-Anwendungen extern bereitgestellt werden, gehören:
Webserver-Ressourcen wie Webseiten, Webdienste und statische Ressourcen (HTML-Seiten und Bilder).
Datenbankressourcen, z. B. Daten pro Benutzer oder Daten auf Anwendungsebene.
Netzwerkressourcen, wie Remote-Dateisystemressourcen usw.
Systemressourcen wie die Registrierung, Ereignisprotokolle und Konfigurationsdateien usw.
Clients greifen über Anwendungsebenen hinweg auf diese Ressourcen zu, wobei durch jede Ebene eine Identität fließt. Diese für den Ressourcenzugriff verwendete Identität besteht aus:
Der Identität des ursprünglichen Aufrufers. Die Identität des ursprünglichen Aufrufers wird erhalten und fließt anschließend durch jede Schicht des Systems.
Prozess-ID Der Zugriff auf lokale Ressourcen und Downstream-Aufrufe erfolgt über die aktuelle Prozess-ID. Die Machbarkeit dieses Ansatzes hängt von der zu überschreitenden Grenze ab, da die Prozessidentität vom Zielsystem erkannt werden muss. Dies muss auf eine von zwei Arten aufgerufen werden:
Übergreifen Sie Windows-Sicherheitsdomänen innerhalb derselben Windows-Sicherheitsdomäne – verwenden Sie Vertrauensstellungen und Domänenkonten oder verwenden Sie doppelte Benutzernamen und Kennwörter, wenn keine Vertrauensbeziehung besteht.
Dienstkonto Dieser Ansatz verwendet ein (festes) Dienstkonto. Für den Datenbankzugriff könnte das Dienstkonto beispielsweise durch einen festen SQL-Benutzernamen und ein festes SQL-Kennwort durch eine mit der Datenbank verbundene Komponente dargestellt werden.
Wenn eine feste Windows-Identität erforderlich ist, sollte die Enterprise Services-Serveranwendung verwendet werden.
Benutzerdefinierte Identität Wenn kein Windows-Konto verfügbar ist, können Sie Iprincipal und Iidentity verwenden, um Ihre eigene Identität zu erstellen, die Details zum Sicherheitskontext enthalten kann.
3. Ressourcenzugriffsmodell
3.1 Vertrauenswürdiges Subsystemmodell
Wie in Abbildung 1 dargestellt, fließt in diesem Modell der Sicherheitskontext des ursprünglichen Aufrufers nicht durch den Dienst auf Betriebssystemebene, sondern eine feste Identität wird in der Zwischendienstschicht verwendet, um auf nachgelagerte Dienste und Ressourcen zuzugreifen. Das vertrauenswürdige Subsystemmodell hat seinen Namen von der Tatsache, dass ein Downstream-Dienst (vielleicht eine Datenbank) einem Upstream-Dienst vertraut, um seine Aufrufer zu autorisieren. Im Beispiel in Abbildung 1 vertraut die Datenbank auf die Autorisierung des Anrufers durch die mittlere Schicht und erlaubt nur autorisierten Anrufern den Zugriff auf die Datenbank über vertrauenswürdige Identitäten.
3.1.1 Ressourcenzugriffsmodus
Im vertrauenswürdigen Subsystemmodell sieht das Ressourcenzugriffsmodell wie folgt aus:
Authentifizieren Sie Benutzer. Ordnen Sie Benutzer Rollen zu. Autorisieren Sie basierend auf der Rollenmitgliedschaft. Verwenden Sie eine feste vertrauenswürdige Identität, um auf nachgelagerte Ressourcen zuzugreifen
3.1.2 Feste Identifikation
Eine feste Identität für den Zugriff auf nachgelagerte Systeme und Ressourcenmanager, die über eine Prozessidentität oder ein voreingestelltes Windows-Konto-Dienstkonto bereitgestellt werden kann. Für den SQL Server Explorer bedeutet dies die Windows-Authentifizierung bei SQL Server.
Wenn Sie die Prozessidentität verwenden, verwenden Sie normalerweise die ASP.NET-Prozessidentität (der Standardwert ist das ASPNET-Konto). In praktischen Anwendungen ist es oft notwendig, das ASPNET-Konto auf ein sichereres Passwort zu ändern und auf dem SQL Server-Computer ein Windows-Konto zu erstellen, das dem ASP.NET-Prozesskonto entspricht. Die spezifische Methode ist wie folgt:
Bearbeiten Sie die Datei „Machine.config“ im Verzeichnis %windr%Microsoft.NETFrameworkv1.1.4322CONFIG und konfigurieren Sie das Kennwortattribut im Element <processModel> auf den Standardwert <!-UserName="machine" passwort = neu „AutoGenerate“ -->Ändern Sie zu <!-UserName="machine" password="NewPassword" --> oder verwenden Sie das Tool ASPNET_setreg.exe, um den Benutzernamen und das Kennwort in der Registrierung zu speichern, und ändern Sie die Konfiguration in: < !- enable="true" UserName="Registry:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,userName" passwort=" Registry:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,password " -->
Andere Anwendungen verwenden ein bestimmtes SQL-Konto (angegeben durch den Benutzernamen und das Kennwort in der Verbindungszeichenfolge), um auf SQL Server zuzugreifen. In diesem Fall muss die Datenbank für die SQL-Authentifizierung konfiguriert werden. Die in der Konfigurationsdatei gespeicherte Verbindungszeichenfolge muss durch Verschlüsselung geschützt werden.
3.2 Simulations-/Delegierungsmodell
Wie in Abbildung 2 dargestellt, verwendet ein Dienst oder eine Komponente (in der Regel in der logischen Geschäftsdienstschicht gelegen) bei Verwendung des Identitätswechsel-/Löschmodells die Identitätswechselfunktionen des Betriebssystems, um die Identität des Clients zu imitieren, bevor auf den nächsten nachgelagerten Dienst zugegriffen wird. Befindet sich der Dienst auf demselben Computer, reicht die Verwendung von Identitätswechsel aus. Wenn sich der Downstream-Dienst auf einem Remote-Computer befindet, müssen Sie auch die Delegation verwenden. Der Sicherheitskontext des Downstream-Ressourcenzugriffs ist der Kontext des Clients.
3.3 Ressourcenzugriffsmodell auswählen
Der Vergleich der beiden Ressourcenzugriffsmodelle ist in Tabelle 1 dargestellt.
Das Backend der vertrauenswürdigen Subsystemmodellsimulation/delegierten Modellprüfungsfunktion vertraut den Diensten der oberen Schicht. Wenn die mittlere Schicht gefährdet ist, sind die Back-End-Ressourcen anfällig für Angriffe. Der Back-End-Dienst kann jeden Anrufer mit guter Sicherheit authentifizieren und autorisieren.
Die Skalierbarkeit unterstützt das Verbindungspooling und weist eine gute Skalierbarkeit auf. Unterstützt kein Verbindungspooling und weist eine schlechte Skalierbarkeit auf.
Back-End-ACL-Verwaltung ACL wird für eine einzelne Entität konfiguriert und erfordert weniger Verwaltungsaufwand. Jedem Benutzer muss die entsprechende Zugriffsebene gewährt werden. Wenn die Anzahl der Back-End-Ressourcen und Benutzer zunimmt, wird die Verwaltungsarbeit umständlich.
Keine Notwendigkeit, technische Probleme zu delegieren. Delegation ist erforderlich. Die meisten Sicherheitsdienstleister unterstützen keine Delegation.
Das vertrauenswürdige Subsystemmodell wird in den meisten Internetanwendungen sowie großen Intranetanwendungen verwendet, hauptsächlich weil dieses Modell die Skalierbarkeit gut unterstützen kann. Das Simulations-/Delegiertenmodell wird tendenziell in kleineren Systemen verwendet. Bei diesen Anwendungen steht nicht die Skalierbarkeit im Vordergrund, sondern die Prüfung.