Freigeben über

Schützen des Anwendungsservers

  • Artikel

* * *

Auf dieser Seite

Modulübersicht Modulübersicht
Zielsetzung Zielsetzung
Betrifft Betrifft
Verwendung dieses Moduls Verwendung dieses Moduls
Übersicht Übersicht
Bedrohungen und Gegenmaßnahmen Bedrohungen und Gegenmaßnahmen
Verfahrensweise Verfahrensweise
Überlegungen zum Kommunikationskanal Überlegungen zum Kommunikationskanal
Überlegungen zur Firewall Überlegungen zur Firewall
Überlegungen zur .NET Remoting-Sicherheit Überlegungen zur .NET Remoting-Sicherheit
Überlegungen zur Enterprise Services (COM+)-Sicherheit Überlegungen zur Enterprise Services (COM+)-Sicherheit
Zusammenfassung Zusammenfassung
Weitere Links zum Thema Weitere Links zum Thema

Modulübersicht

Anwendungsserver der mittleren Schicht werden meist genutzt, um Geschäftslogik und Datenzugriffsdienste zu hosten. Diese Funktionen sind üblicherweise in Enterprise Services-Anwendungen zusammengefasst oder auf Front-End-Webservern öffentlich verfügbar, indem Webdienste der mittleren Schicht oder Microsoft® .NET Framework Remoting-Technologie verwendet wird.

In diesem Modul wird jede Technologie einzeln behandelt und dargestellt, wie die Anwendungsserver für jeden Fall zu schützen sind. Der Schwerpunkt liegt auf den verbundenen Kommunikationskanälen, die den Webserver mit dem Anwendungsserver und den Anwendungsserver mit dem Datenbankserver verbinden.

Vor der Vertiefung der technologiespezifischen Konfiguration werden in diesem Modul die wichtigsten Bedrohungen für einen Anwendungsserver erläutert. Diese Bedrohungen unterscheiden sich von denen, die für einen internetorientierten Webserver gelten, da Anwendungsserver der mittleren Schicht nicht über direkten Zugriff auf das Internet verfügen (bzw. verfügen sollten).

 

Zielsetzung

Themenbereiche:

  • Schützen der Kommunikationskanäle zum Anwendungsserver

  • Schützen der Webdienste, Enterprise Services und Remotelösungen auf Anwendungsservern der mittleren Schicht

  • Konfigurieren einer internen Firewall, die den Webserver vom Anwendungsserver trennt

  • Verwalten der dynamischen RPC-Portzuordnung

  • Sicheres Verwenden von .NET Remoting

  • Sperren einer Enterprise Services-Anwendung

  • Kenntnis über die wichtigsten Maßnahmen gegen häufig auftretende Anwendungs-Serverbedrohungen wie Abhören des Netzwerks, nicht autorisierten Zugriff, Viren, Trojaner und Würmer

 

Betrifft

Die Informationen in diesem Modul gelten für folgende Produkte und Technologien:

  • Microsoft Windows Server 2000 und 2003

  • Microsoft .NET Framework 1.1 und ASP.NET 1.1

  • Microsoft SQL Server

 

Verwendung dieses Moduls

Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

 

Übersicht

Um den Anwendungsserver zu schützen, ist eine inkrementelle Sicherheitskonfiguration notwendig, nachdem das Betriebssystem und der Webserver für die Internetinformationsdienste (IIS) sicher gesperrt wurden.

In Abbildung 17.1 wird der Schwerpunkt dieses Moduls gezeigt, einschließlich der Konfiguration interner Firewalls, die in vielen mehrschichtigen Bereitstellungsmodellen verwendet werden.

Bereitstellungsmodell eines Remoteanwendungsservers

Abbildung 17.1
Bereitstellungsmodell eines Remoteanwendungsservers

 

Bedrohungen und Gegenmaßnahmen

Viele Bedrohungen für einen Anwendungsserver treten innerhalb einer Organisation auf, da Anwendungsserver nicht auf das Internet zugreifen sollten. Im Folgenden sind die wichtigsten Bedrohungen für Anwendungsserver aufgeführt:

  • Abhören des Netzwerks

  • Nicht autorisierter Zugriff

  • Viren, Trojanische Pferde und Würmer

In Abbildung 17.2 sind die wichtigsten Bedrohungen für Anwendungsserver dargestellt.

Die wichtigsten Bedrohungen und Sicherheitslücken eines Anwendungsservers

Abbildung 17.2
Die wichtigsten Bedrohungen und Sicherheitslücken eines Anwendungsservers

Abhören des Netzwerks

Angreifer mit Software zur Netzwerküberwachung können einen Datenstrom vom Webserver zum Anwendungsserver sowie vom Anwendungsserver zu Downstreamsystemen und Datenbankservern abfangen. Der Angreifer kann diese Daten anzeigen und möglicherweise ändern.

Sicherheitslücken

Sicherheitslücken, die Ihren Anwendungsserver verwundbar gegen Abhören des Netzwerks machen können, beinhalten:

  • Vertrauliche Daten, die im Klartext durch die Anwendung übertragen werden

  • Verwendung der Microsoft SQL Server-Authentifizierung in der Datenbank, so dass Anmeldeinformationen im Klartext übertragen werden

  • Fehlen der Verschlüsselung auf Übertragungs- oder Anwendungsebene

  • Unsichere Verwaltungsschnittstellen für Netzwerkhardware

  • Verwendung des .NET-Remoting-TCP-Kanals zu Remotekomponenten

Angriffe

Der Angreifer platziert Paket-Sniffing-Programme im Netzwerk, um den Datenverkehr abzufangen.

Gegenmaßnahmen

Gegenmaßnahmen zum Verhindern des Abfangens von Paketen sind:

  • Verwenden Sie eine sichere Authentifizierung wie die Windows-Authentifizierung, die keine Kennwörter über das Netzwerk sendet.

  • Verschlüsseln Sie die Anmeldeinformationen für die SQL Server-Authentifizierung. Wenn Sie die SQL Server-Authentifizierung verwenden, können Sie die Anmeldeinformationen automatisch verschlüsseln, indem Sie ein Serverzertifikat auf dem Datenbankserver installieren.

  • Schützen Sie die Kommunikationskanäle durch Secure Sockets Layer (SSL) oder Internet Protocol Security (IPSec).

  • Verwenden Sie die Remote Procedure Call (RPC)-Verschlüsselung mit Enterprise Services-Anwendungen.

  • Verwenden Sie ein segmentiertes Netzwerk, welches das Abhören auf beeinträchtigte Segmente beschränken kann.

  • Verwenden Sie HttpChannel und SSL mit .NET Remoting.

Nicht autorisierter Zugriff

Wenn Sie die Ports, die von der Anwendung verwendet werden, nicht an der Perimeterfirewall blockieren, die auf dem Anwendungsserver ausgeführt wird, kann ein externer Angreifer direkt mit dem Anwendungsserver kommunizieren. Wenn Sie anderen Computern als den Front-End-Webservern ermöglichen, mit dem Anwendungsserver zu kommunizieren, erhöht sich das Angriffsprofil für den Anwendungsserver.

Sicherheitslücken

Sicherheitslücken, die zu nicht autorisiertem Zugriff führen können, sind:

  • Unsichere Konfiguration von Perimeternetzwerk und Firewall

  • Nicht benötigte Ports sind in der internen Firewall geöffnet

  • Fehlen von IPSec-Richtlinien zur Beschränkung der Host-Verbindungsmöglichkeit

  • Unnötig aktivierte Dienste

  • Unnötige Protokolle

  • Unsichere Konto- und Kennwortrichtlinien

Angriffe

Allgemeine Angriffe zum Erlangen von nicht autorisiertem Zugriff beinhalten:

  • Scannen der Ports, um Abhördienste zu entdecken

  • Abfangen von Bannern, die vorhandene Dienste und mögliche Softwareversionen weitergeben

  • Böswillige Anwendungseingaben

  • Kennwortangriffe auf Standardkonten mit unsicheren Kennwörtern

Gegenmaßnahmen

Zu den Maßnahmen gegen einen nicht autorisierten Zugriff zählen:

  • Firewall-Richtlinien, die jeglichen Datenverkehr außer von erwarteten Kommunikationsports blockieren

  • TCP/IP-Filterung oder IPSec-Richtlinien, um zu verhindern, dass nicht autorisierte Hosts Verbindungen aufbauen können

  • Deaktivieren nicht verwendeter Dienste

  • Statisches DCOM-Endpunkt-Mapping, welches nur autorisierten Hosts Zugriff gewährt

Viren, Würmer und Trojaner

Diese Angriffe werden oftmals nicht bemerkt, bis sie beginnen, Systemressourcen zu beanspruchen, so dass die Ausführung von anderen Anwendungen verlangsamt oder angehalten wird. Anwendungsserver, die IIS hosten, sind anfällig für IIS-Angriffe.

Sicherheitslücken

  • Nicht gepatchte Server

  • Nicht erforderliche ausgeführte Dienste

  • Nicht benötigte ISAPI-Filter und ISAPI-Erweiterungen

Gegenmaßnahmen

Gegenmaßnahmen, die hilfreich sind, die Bedrohung durch Viren, Trojaner und Würmer zu verringern, beinhalten:

  • Umgehende Anwendung der aktuellen Softwarepatches

  • Deaktivieren nicht benötigter Funktionen wie nicht verwendete ISAPI-Filter und Erweiterungen

  • Verwenden von Prozessen mit Konten, die über die geringsten Berechtigungen verfügen, um den Umfang des Schadens im Fall einer Beeinträchtigung zu reduzieren

 

Verfahrensweise

Durch das Schützen der Kommunikationskanäle zum Anwendungsserver und das Verhindern des Zugriffs von jeglichen Hosts außer den autorisierten Webservern auf den Anwendungsserver sind Angreifer auf Angriffe auf Anwendungsebene beschränkt, die Sicherheitslücken in der Ausführung und Entwicklung der Webanwendung ausnutzen.

Um diese Risiken zu verringern, müssen Entwickler die Ansätze für sichere Ausführung und Entwicklung anwenden, die in Teil II und III dieses Handbuchs beschrieben sind.

Die Konfigurationslösungen in diesem Modul sind Anwendungsserverspezifisch und sollten nicht für sich angewendet werden. Wenden Sie diese zusammen mit den Lösungen an, die in Modul 15, "Schützen des Netzwerks", Modul 16, "Schützen des Webservers", und Modul 18, "Schützen des Datenbankservers", aufgeführt sind.

 

Überlegungen zum Kommunikationskanal

Vertrauliche Anwendungsdaten und Authentifizierungsinformationen, die zum Anwendungsserver und zurück gesendet werden, sollten verschlüsselt werden, um für Geheimhaltung und Integrität zu sorgen. Dies verringert die Risiken im Zusammenhang mit Abhören und Verfälschen.

Das Verschlüsseln des Netzwerkverkehrs zielt auf Bedrohungen durch Abhören des Netzwerks und Verfälschung ab. Wenn Sie davon ausgehen, dass diese Bedrohung in Ihrer Umgebung zu vernachlässigen ist, da sich zum Beispiel Ihre Anwendung in einem geschlossen und physikalisch geschützten Netzwerk befindet, müssen Sie den Datenverkehr nicht verschlüsseln. Wenn das Abhören des Netzwerks ein Problem darstellt, können Sie SSL verwenden, das einen sicheren Kommunikationskanal zur Anwendungsebene bietet, oder Sie verwenden IPSec, um eine Lösung auf Übertragungsebene zu erhalten. IPSec verschlüsselt den gesamten IP-Datenverkehr, der zwischen zwei Servern verläuft, während SSL es jeder Anwendung ermöglicht, auszuwählen, ob ein verschlüsselter Kommunikationskanal benötigt wird.

Enterprise Services

Enterprise Services (oder COM+)-Anwendungen kommunizieren über das Netzwerk unter Verwendung von DCOM über RPC. RPC verwendet Port 135, der Endpunkt-Mapping Dienste bietet, um es Clients zu ermöglichen, Parameter zu vereinbaren, die auch den Kommunikationsport enthalten, der in der Standardeinstellung dynamisch zugewiesen wird.

Der Enterprise Services-Kanal kann auf zwei Arten geschützt werden:

  • RPC-Verschlüsselung
    Sie können eine Enterprise Services-Anwendung für RPC Packet Privacy-Authentifizierung konfigurieren. Zusätzlich zur Authentifizierung bietet dies eine Verschlüsselung jedes Datenpakets, welches zur Enterprise Services-Anwendung und zurück gesendet wird.

  • IPSec
    Sie können eine IPSec-Richtlinie zwischen dem Webserver und dem Anwendungsserver verwenden, um den Kommunikationskanal zu verschlüsseln.

.NET Remoting

Es existieren zwei Implementierungsmodelle für Anwendungen, die .NET Remoting verwenden:

  • HTTP-Kanal über Port 80
    Dieses Modell verwendet ASP.NET als Hosting-Dienst.

  • TCP-Kanal über einen beliebigen Port
    In diesem Modell wird die Anwendung in einer benutzerdefinierten ausführbaren Datei gehostet, üblicherweise einem Windowsdienst.

Abhängig von den Anforderungen der Anwendung an Leistung und Sicherheit, können Sie eine der beiden Methoden verwenden, um den Remotekanal zu schützen.

  • Verwenden von SSL mit dem HTTP-Kanal
    Wenn Sie in ASP.NET hosten, können Sie die Vorteile der eingebauten HTTPS-Funktion nutzen, welche durch IIS zur Verfügung gestellt wird. HTTPS bietet eine Authentifizierung und eine sichere Datenkommunikation.

  • Verwenden von IPSec mit TCPChannel
    Mit dem TCP-Kanal können Sie eine IPSec-Richtlinie verwenden, um eine Verschlüsselung aller IP-Daten auf Transportebene zur Verfügung zu stellen. Beachten Sie bei der Verwendung des TCP-Kanals, dass Sie Ihren eigenen Authentifizierungsmechanismus zur Verfügung stellen müssen. Weitere Informationen finden Sie in Modul 13, "Erstellen sicherer Remotekomponenten".

Webdienste

Webdienste werden von ASP.NET und IIS gehostet und verwenden das HTTP-Protokoll für die Kommunikation über das Netzwerk.

SSL oder IPSec können verwendet werden, um den Kommunikationskanal zu schützen. Wahlweise können Sie die Verschlüsselung auf Anwendungsebene behandeln, indem Sie den Dateninhalt der Meldung oder die vertraulichen Teile des Dateninhalts verschlüsseln. Um dies mittels offenen Standards zu gewährleisten, laden Sie die WSE (Web Services Enhancements) herunter, die für Webdienste zur Verfügung stehen. Weitere Informationen finden Sie in Modul 12, "Erstellen sicherer Webdienste".

SQL Server

Der Anwendungsserver kommuniziert mit dem SQL Server in der Standardeinstellung über den TCP-Port 1433. Wenn nicht anders angegeben, wird der UDP-Port 1434 ebenfalls für Verhandlungen verwendet.

Um den Kanal vom Anwendungsserver zum SQL-Server zu schützen, ist IPSec oder SSL zu verwenden. SSL erfordert ein Serverzertifikat, um auf dem Datenbankserver installiert zu werden.

Weitere Informationen über die Verwendung von SSL mit SQL Server finden Sie im Microsoft Knowledge Base-Artikel 276553, "How To: Enable SSL Encryption for SQL Server 2000 with Certificate Server".

 

Überlegungen zur Firewall

Ihre Sicherheitsinfrastruktur kann interne Firewalls auf beiden Seiten des Anwendungsservers beinhalten. Dieser Abschnitt behandelt die Ports, die Sie an dieser Firewall öffnen, um die Funktionen Ihrer Anwendung zu unterstützen.

Enterprise Services

Wenn Enterprise Services der mittleren Schicht verwendet werden, ist eine interne Firewall zu konfigurieren, die Webserver und Anwendungsserver trennt, um DCOM- und RPC-Datenverkehr zu ermöglichen. Bei der Verwendung von Enterprise Services nutzen Anwendungen oft verteilte Transaktionen und Dienste des Distributed Transaction Coordinator (DTC). In diesem Fall sind die DTC-Ports an jeder Firewall zu öffnen, die den Anwendungsserver von Remote-Ressourcen-Managern trennen. In Abbildung 17.3 wird eine typische Portkonfiguration für Enterprise Services dargestellt.

Typische Portkonfiguration für Enterprise Services

Abbildung 17.3
Typische Firewallportkonfiguration für Enterprise Services

Hinweis: Abbildung 17.3 enthält keine zusätzlichen Ports, die für den Authentifizierungsmechanismus zwischen einem Client und einer Enterprise Services-Anwendung und möglicherweise zwischen der Enterprise Services-Anwendung und dem Datenbankserver notwendig sind. Im Allgemeinen ist für Netzwerke, die nicht Active Directory verwenden, der TCP-Port 139 für die Windows-Authentifizierung notwendig. Weitere Informationen über Port-Anforderungen finden Sie in den TechNet-Artikeln "TCP and UDP Port Assignments" unter https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/tcpip/part4/tcpappc.asp und "Security Considerations for Administrative Authority" unter https://www.microsoft.com/technet/security/bestprac/bpent/sec2/seconaa.asp.

Standardmäßig verwendet DCOM die dynamische RPC-Portzuordnung, die zufällige Portnummern über 1024 auswählt. Zusätzlich wird von der RPC-Endpunktzuordnung Port 135 verwendet.

Es gibt zwei Wege, über die Sie die für DCOM erforderlichen Ports in der internen Firewall beschränken können:

  • Definition von Portbereichen.
    Auf diese Weise können Sie die dynamisch von RPC zugeordneten Ports steuern. Weitere Informationen über dynamische Port-Beschränkungen finden Sie im Microsoft Knowledge Base-Artikel 300083, "How To: Restrict TCP/IP Ports on Windows 2000 and Windows XP".

  • Verwenden Sie eine statische Endpunktzuordnung.
    Windows 2000 mit SP3 (oder QFE ab Version 18.1) oder Windows Server 2003 bieten Ihnen die Einstellung, dass Enterprise Services-Anwendungen einen statischen Endpunkt verwenden. Statische Endpunktzuordnung bedeutet, dass Sie auf der Firewall nur zwei Ports öffnen müssen: Port 135 für RPC und einen festgelegten Port für Ihre Enterprise Services-Anwendung.

    Weitere Informationen über statische Endpunktzuordnung finden Sie im Microsoft Knowledge Base-Artikel 312960, "Cannot Set a Fixed Endpoint for a COM+ Application".

Webdienste

Wenn das Öffnen von Ports auf der internen Firewall nicht möglich ist, können Sie auf dem Anwendungsserver vor den Serviced Components eine Fassadenschicht für Webdienste einführen. Das bedeutet, dass lediglich Port 80 für HTTP-Datenverkehr (insbesondere SOAP-Meldungen) für eine Übertragung in beide Richtungen geöffnet werden muss.

Dieser Ansatz ermöglicht es Ihnen nicht, Transaktionskontext vom Client zum Server zu leiten, obwohl es in vielen Fällen, wenn Ihre Bereitstellungsarchitektur einen Anwendungsserver mit mittlerer Schicht beinhaltet, richtig ist, Transaktionen in der Remotekomponente auf dem Anwendungsserver zu initiieren.

Weitere Informationen über physikalische Bereitstellungsanforderungen für Dienstagenten und Dienstschnittstellen, wie die Fassadenschicht für Webdienste, finden Sie unter "Physical Deployment and Operational Requirements" im Abschnitt "Reference" des MSDN-Artikels "Application Architecture for .NET: Designing Applications and Services" unter https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp.

DTC-Anforderungen

Wenn Ihre Anwendung über COM+ verteilte Transaktionen verwendet und diese über Remoteserver ausgeführt werden, die durch eine interne Firewall getrennt sind, muss die Firewall die notwendigen Ports öffnen, um DTC-Datenverkehr zu unterstützen. DTC verwendet eine dynamische Portzuordnung mit RPC. Zusätzlich zu Port 135 für RPC erfordert die DTC-Kommunikation mindestens einen weiteren Port.

Wenn Ihre Bereitstellungsarchitektur eine Remoteanwendungsschicht beinhaltet, werden Transaktionen normalerweise dort innerhalb der Enterprise Services-Anwendung initiiert und zum Datenbankserver übertragen. Bei Fehlen eines Anwendungsservers initiiert die Enterprise Services-Anwendung auf dem Webserver die Transaktion und überträgt sie zum Ressourcen-Manager des SQL-Servers.

Weitere Informationen über die Firewall-Konfiguration zur Unterstützung von DTC-Datenverkehr finden Sie unter:

.NET Remoting

Wenn Sie den HTTP-Kanal verwenden und Ihre Remotekomponenten in ASP.NET hosten, öffnen Sie nur Port 80 auf der internen Firewall, um HTTP-Datenverkehr zu ermöglichen. Wenn Ihre Anwendung auch SSL verwendet, öffnen Sie Port 443.

Wenn Sie den TCP-Kanal verwenden und in einem Windowsdienst hosten, öffnen Sie den spezifischen TCP-Port oder Ports, für deren Verwendung Ihre Remotinganwendung konfiguriert wurde. Die Anwendung könnte einen zusätzlichen Port erfordern, um Callbacks zu unterstützen.

In Abbildung 17.4 wird eine typische Port-Konfiguration für eine .NET Remoting-Firewall dargestellt. Beachten Sie, dass die Portnummern, die für das TCP-Kanal-Szenario gezeigt werden (5555 und 5557), nur zur Veranschaulichung dienen. Die tatsächlichen Portnummern sind in den Konfigurationsdateien web.config auf den Client- und Servercomputern angegeben. Weitere Informationen finden Sie in Modul 13, "Erstellen sicherer Remotekomponenten".

Typische Remoting-Firewall-Port-Konfiguration für HTTP und TCP-Kanal-Szenarios

Abbildung 17.4
Typische Remoting-Firewall-Port-Konfiguration für HTTP und TCP-Kanal-Szenarios

Webdienste

Webdienste kommunizieren mittels SOAP über HTTP. Öffnen Sie aus diesem Grund nur Port 80 auf der internen Firewall.

SQL Server

Wenn eine Firewall den Anwendungsserver vom Datenbankserver trennt, erfordert die Verbindung durch eine Firewall zu einem SQL-Server, den Client mit der SQL Server-Clientkonfiguration und den Datenbankserver mit der SQL Server-Netzwerkkonfiguration zu konfigurieren. In der Standardeinstellung überwacht SQL Server den TCP-Port 1433, auch wenn dies geändert werden kann. Der gewählte Port muss in der Firewall geöffnet sein.

Abhängig vom gewählten SQL Server Authentifizierungsmodus und der Verwendung von verteilten Transaktionen durch die Anwendung, kann es auch notwendig sein, mehrere zusätzliche Ports in der Firewall zu öffnen.

  • Wenn die Anwendung die Windows-Authentifizierung verwendet, um mit SQL-Server zu verbinden, sind die notwendigen Ports zu öffnen, welche das Kerberos-Protokoll oder die NTLM-Authentifizierung unterstützen.

  • Wenn die Anwendung verteilte Transaktionen verwendet, beispielsweise automatisierte COM+-Transaktionen, konfigurieren Sie die Firewall so, dass dieser DTC-Datenverkehr zwischen einzelnen DTC-Instanzen und dem DTC sowie Ressourcen-Managern zulässt, wie SQL Server.

Weitere Informationen über die SQL Server Port-Anforderungen finden Sie in Modul 18 "Schützen des Datenbankservers".

 

Überlegungen zur .NET Remoting-Sicherheit

Die .NET Remoting-Infrastruktur ermöglicht Anwendungen, untereinander auf demselben Computer oder über Computer im Netzwerk zu kommunizieren. Die Remoting-Infrastruktur kann die HTTP- oder TCP-Transporte zur Kommunikation verwenden und Meldungen in vielen Formaten senden, wovon die bekanntesten SOAP oder das binäre Format sind.

Hosting in einem Windowsdienst (TCP-Kanal)

Da die Remoting-Infrastruktur keine Standardauthentifizierung und keinen Authentifizierungsmechanismus bietet, ist diese für eine Verwendung bei internetorientierten Anwendungen nicht empfehlenswert. Diese Infrastruktur wurde für Anwendungen entwickelt, die in einer vertrauenswürdigen Umgebung ausgeführt werden, und ist besonders für die Webserverkommunikation mit Remoteanwendungen geeignet, wie in Abbildung 17.5 dargestellt.

Remoting mit dem TCP-Kanal und einem Windowsdiensthost

Abbildung 17.5
Remoting mit dem TCP-Kanal und einem Windowsdiensthost

In diesem Szenario hostet ein Windowsdienst die Remotingobjekte und die Kommunikation findet durch einen TCP-Kanal statt. Dieser Ansatz bietet gute Leistungen, ist jedoch nicht unbedingt sicher. Für zusätzliche Sicherheit ist IPSec zwischen dem Webserver und dem Anwendungsserver zu verwenden und es nur dem Webserver zu erlauben, Verbindungen mit dem Anwendungsserver aufzubauen.

Hosting in IIS (HTTP-Kanal)

Um aus den Sicherheitsfunktionen, die von ASP.NET und IIS zur Verfügung gestellt werden, Nutzen zu ziehen, sind die Remotekomponenten in ASP.NET zu hosten und der HTTP-Kanal für die Kommunikation zu verwenden, wie in Abbildung 17.6 gezeigt.

Remoting mit dem HTTP-Kanal und einem ASP.NET-Host

Abbildung 17.6
Remoting mit dem HTTP-Kanal und einem ASP.NET-Host

In diesem Szenario kann die in Windows integrierte Authentifizierung verwendet werden, um die Prozessidentität der ASP.NET-Webanwendung zu authentifizieren. SSL kann auch für sichere Kommunikation und die Gatekeeper, die von IIS und ASP.NET zur Verfügung gestellt werden, können für die Autorisierung verwendet werden.

 

Überlegungen zur Enterprise Services (COM+)-Sicherheit

COM+ bietet die grundlegende Infrastruktur für Enterprise Services. Aus diesem Grund ist COM+ zu schützen, wenn das Programm auf dem Anwendungsserver für die mittlere Schicht verwendet wird. Zwei hauptsächliche Schritte sind Teil der Sicherung eines Anwendungsservers, der die Enterprise Services verwendet:

  • Schützen Sie die Infrastruktur der Komponentendienste.
    Sie müssen das Betriebssystem und die Infrastruktur der Enterprise Services schützen. Dies beinhaltet grundlegende Sicherheitsmaßnahmen wie die Anwendung von Patches und Updates sowie das Deaktivieren nicht verwendeter Dienste, Blockieren nicht verwendeter Ports und so weiter.

  • Konfigurieren Sie die Sicherheit der Enterprise Services-Anwendung.
    Sie müssen die Enterprise Services-Anwendung, die auf Ihrem Server eingesetzt wird, unter Berücksichtigung der anwendungsspezifischen Sicherheitsanforderungen schützen.

Der Entwickler kann viele der Sicherheitseinstellungen der Anwendung und der Komponentenebene angeben, indem er Metadaten verwendet, die in die eingesetzte Assembly eingebettet sind. Diese regeln die anfänglichen Katalogsicherheitseinstellungen, die auf die Anwendung angewendet werden, wenn sie bei den Enterprise Services registriert wird. Dann kann der Administrator diese anzeigen und wenn nötig ergänzen, indem er das Tool für die Komponentendienste verwendet.

Schützen der Infrastruktur der Komponentendienste

Enterprise Services sind keine optionale Komponente, sondern ein wesentlicher Bestandteil von Windows 2000. In Bezug auf die Sicherheit hilft es, die geeigneten Sicherheitsmaßnahmen zu ergreifen, wenn bekannt ist, welche Komponenten des Betriebssystems installiert sind, um die Enterprise Services zu unterstützen.

Was wird durch das Betriebssystem installiert?

Die folgende Tabelle zeigt die Kernelemente der Komponentendienste, die bei einer Standard-Betriebssysteminstallation installiert werden.

Tabelle 17.1 Enterprise Services-Komponenten

Element

Informationen

Administration

Komponentendienste-Explorer
Dieser bietet eine konfigurierbare Administration der COM+ Anwendungen und wird unter \WINNT\system32\Com\comexp.msc gefunden.
COM+ Katalog
Der COM+ Katalog unterhält die Konfigurationsinformationen für jede COM+ Anwendung.

Systemanwendung
(eine COM+ Serveranwendung)

Systemanwendung
Diese Anwendung verwaltet die Konfiguration und das Protokollieren von COM+ Komponenten. Sie kann aus der Microsoft Management Console (MMC) für Komponentendienste angezeigt werden. Sie hat zwei zugeordnete Rollen: Administrator und Leser. Standardmäßig sind die Administratoren Bestandteil der Administrator-Rolle, die den COM+ Katalog ändern kann, während jeder Bestandteil der Leser-Rolle ist, welche nur die COM+ Katalogwerte lesen kann.

Dienste

COM+ Ereignissystem
Dieser Dienst ist notwendig, um das COM+ Loosely Coupled Event (LCE)-System. Das LCE-System wird von Diensten des Betriebssystems verwendet, wie dem Systemereignisbenachrichtigungsdienst (SENS) und optional durch Ihre Anwendungen.
Distributed Transaction Coordinator (DTC)
Dieser Dienst ist notwendig, wenn Ihre Enterprise Services-Lösung automatische COM+ Transaktionen verwendet.

Konten

Enterprise Services erstellen keine Konten. Bibliotheksanwendungen fungieren als Identität des Prozesses, in dem sie ausgeführt werden. Serveranwendungen können so konfiguriert werden, dass sie als interaktiver oder als bestimmter Benutzer ausgeführt werden. (Sie können das Benutzerkonto in den Komponentendiensten im Dialogfeld Eigenschaften der COM+-Anwendung auf der Registerkarte Identität konfigurieren).

Protokolldateien

DTC-Protokolldatei: %windir%\system32\DTCLog
CRM Protokolldatei: %windir%\registration

Registrierungsschlüssel

HKEY_CLASSES_ROOT\CLSID
HKEY_CLASSES_ROOT\AppID
Was wird von .NET Framework installiert?

Wenn Sie das .NET Framework installieren, werden die folgenden Komponenten installiert, die in Verbindung mit den Enterprise Services stehen.

Tabelle 17.2 .NET Framework Enterprise Services-Werkzeuge und Konfigurationseinstellungen

Element

Beschreibung

Regsvcs.exe

Kommandozeilenwerkzeug, welches zur Registrierung der Enterprise Services-Koponenten an COM+ verwendet wird

Bibliotheken

System.EnterpriseServices.dll
System.EnterpriseServices.Thunk.dll
System.EnterpriseServices.tlb

Machine.config
Konfigurationselemente

Wenn Sie die Enterprise Services von ASP.NET aus aufrufen, sind die folgenden Einträge in Machine.config von Bedeutung:
<assemblies>
Lädt die Assembly System.EnterpriseServices für ASP.NET.
<processModel>
Das Attribut comAuthentication konfiguriert die Authentifizierungsebenen von ASP.NET. Die DCOM Authentifizierungsebenen werden zwischen dem Client(zum Beispiel die Webanwendung) und dem Server (die Enterprise Services-Anwendung) vereinbart. Die höhere der beiden Sicherheitseinstellungen wird verwendet.
Das Attribut comImpersonationLevel konfiguriert die Personifizierungsebenen von ASP.NET (für alle ausgehenden DCOM-Aufrufe). Der Client legt die Personifizierungsfähigkeiten fest, die dem Server gewährt werden.

Die folgenden Punkte sind bei der Sicherung der Komponentendiensteinfrastruktur zu berücksichtigen:

  • Patches und Updates

  • Dienste

  • Ports

  • COM+ Katalog

Patches und Updates

Aktualisieren Sie den Anwendungsserver mit den neuesten Service Packs und Patches, um die Risiken, die von Viren, Würmern und Trojanern ausgehen, zu mildern. Die Software, welche regelmäßig zu aktualisieren ist, beinhaltet das Betriebssystem, welches IIS und das .NET Framework beinhaltet.

Aktualisierungen der COM+ Runtime werden möglicherweise auch als QFE-Version veröffentlicht. Verwenden Sie die folgenden Quellen bei der Behandlung der Patches und Updates:

  • Windows-Aktualisierungen und -Patches
    Verwenden Sie den Microsoft Baseline Security Analyzer (MBSA), um fehlende Sicherheitsaktualisierungen auf Anwendungsservern zu entdecken. Weitere Informationen über die Verwendung des MBSA auf einem einzelnen Computer und das Aufrechterhalten der aktuellen Standes einer Gruppe von Servern finden Sie unter "Verwenden von Microsoft Baseline Security Analyzer" im entsprechenden Abschnitt dieses Handbuchs.

    Weitere Informationen über Umgebungen, die eine Aktualisierung vieler Server von einem zentralisierten Administrationspunkt aus erfordern, finden Sie unter "Implementieren der Patchverwaltung" im entsprechenden Abschnitt dieses Handbuchs.

  • .NET Framework-Aktualisierungen und -Patches
    Zum Zeitpunkt des Erscheinens dieses Schriftstücks (Mai 2003) ist MBSA nicht in der Lage, das .NET Framework zu identifizieren. Aus diesem Grund müssen Sie das .NET Framework manuell aktualisieren.

  • Manuelles Aktualisieren von .NET Framework

    1. Stellen Sie fest, welches .NET Framework Service Pack auf Ihrem Webserver installiert ist.
      Informationen dazu finden Sie im Microsoft Knowledge Base-Artikel 318785, "INFO: Determining Whether Service Packs Are Installed on .NET Framework".

    2. Vergleichen Sie die installierte Version des .NET Framework mit dem aktuellen Service Pack.
      Verwenden Sie dazu die .NET Framework-Versionen, die im Microsoft Knowledge Base-Artikel 318836, "INFO: How to Obtain the Latest .NET Framework Service Pack" aufgeführt sind.

      • COM+ Aktualisierungen und Patches
        Die neuesten Windows Service Packs beinhalten die aktuellen Patches für COM+. Jedoch werden Aktualisierungen der COM+ Runtime manchmal als QFE-Version veröffentlicht. Ein automatischer Benachrichtigungsdienst für COM+ Aktualisierungen existiert derzeit nicht. Verfolgen Sie aus diesem Grund die Microsoft Knowledge Base unter https://support.microsoft.com. Verwenden Sie "kbQFE" als Suchwort, um Ihre Suchergebnisse zu verbessern.
Dienste

Um das Angriffsoberflächenprofil zu verkleinern, sollten alle nicht notwendigen Dienste deaktiviert werden. Die notwendigen Dienste beinhalten Microsoft DTC und den COM+ Ereignissystemdienst, der notwendig ist, um die LCE COM+ Funktion zu unterstützen.

Um die Dienste auf dem Anwendungsserver zu schützen, ist der MS DTC zu deaktivieren, wenn er nicht notwendig ist.

Deaktivieren des Microsoft DTC, wenn er nicht notwendig ist

Der DTC-Dienst ist fest mit COM+ verbunden. Er koordiniert Transaktionen, die über zwei oder mehr Datenbanken, Meldungswarteschlangen, Dateisystemen oder andere Ressourcen-Manager verteilt sind. Wenn die Anwendungen die automatisierten COM+-Transaktionsdienste nicht verwenden, sollte der DTC mit dem Dienste-MMC-Snap-In deaktiviert werden.

Ports

Bediente Komponenten kommunizieren mittels DCOM, das wiederum über den RPC-Transport kommuniziert.

In der Standardeinstellung ordnet DCOM dynamisch Ports zu. Dies ist in Bezug auf die Sicherheit und die Firewall nicht wünschenswert. DCOM-Ports sollten beschränkt werden, um das Angriffsoberflächenprofil zu verkleinern und um sicherzustellen, dass keine unnötigen Ports in der internen Firewall geöffnet werden müssen. Zwei Optionen existieren für die Beschränkung der von DCOM verwendeten Ports:

  • Verwendung von Portbereichen.

  • Verwendung von statischer Endpunktzuordnung.

Portbereiche

Für eingehende Kommunikation kann die dynamische RPC Portzuordnung konfiguriert werden, um Ports innerhalb eines beschränkten Bereichs über 1024 zu wählen. Konfigurieren Sie dann die Firewall so, dass sie eingehende externe Kommunikation nur auf diese Ports und Port 135, den RPC-Endpunktzuordnungsport, einschränkt.

  • Steuerung der dynamischen RPC Portzuordnung

    1. Starten Sie das Tool für die Komponentendienste.

    2. Erweitern Sie die Knoten Komponentendienste und Computer, klicken Sie mit der rechten Maustaste auf Arbeitsplatz und wählen Sie dann Eigenschaften.

    3. Klicken Sie auf die Registerkarte Standardprotokolle und wählen Sie dann im Listenfeld DCOM-Protokolle die Option Verbindungsorientiertes TCP/IP aus.

    4. Wählen Sie Eigenschaften.

    5. Wählen Sie im Dialogfeld Eigenschaften der COM-Internetdienste die Option Hinzufügen.

    6. Geben Sie im Textfeld Portbereich einen Portbereich ein, wie 5000 - 5020, und klicken Sie dann auf OK.

    7. Lassen Sie die Optionen Anschlussbereichszuweisung und Standardmäßige dynamische Anschlussbereichszuweisung auf Internetbereich eingestellt.

    8. Klicken Sie zum Schließen aller Dialogfelder zweimal auf OK.

    9. Starten Sie Ihren Computer neu, um die Änderungen in Kraft zu setzen.

Statische Endpunktzuordnung

Windows 2000 (SP3 oder QFE 18.1) oder Windows Server 2003 ermöglicht Ihnen die Einstellung, dass Enterprise Services-Anwendungen einen statischen Endpunkt verwenden. Wenn eine Firewall den Client vom Server trennt, müssen dort nur zwei Ports geöffnet werden. Im Besonderen müssen Sie für RPC Port 135 und für Ihre Enterprise Services-Anwendung einen Port öffnen.

  • Konfiguration eines statischen Endpunkts für DCOM

    1. Besorgen Sie sich die Anwendungs-ID für Ihre Enterprise Services-Anwendung aus dem COM+ Katalog. Gehen Sie dazu folgendermaßen vor:

      • Starten Sie das Tool für die Komponentendienste.

      • Zeigen Sie das Dialogfeld Eigenschaften der Anwendung an und entnehmen Sie die Anwendungs-ID der Seite Allgemein.

    2. Starten Sie den Registrierungseditor (Regedt32.exe).

    3. Wählen Sie den folgenden Registrierungsschlüssel:

      HKEY_CLASSES_ROOT\AppID

    4. Wählen Sie im Menü Bearbeiten den Eintrag Wert hinzufügen und fügen Sie den folgenden Registrierungswert hinzu, wobei {Ihre AppID} die Anwendungs-ID der COM+ Anwendung ist, die Sie in Schritt 1 erhalten haben:

      Name: {Ihre AppID}
Wertname: Endpoints
Datentyp: REG_MULTI_SZ
Datenwert: ncacn_ip_tcp,0,<port number>

      Die Portnummer, die Sie im Textfeld Datenwert angeben, muss größer als 1024 sein und darf nicht mit allgemein bekannten Ports in Konflikt geraten, die andere Anwendungen auf dem Computer verwenden. Der Teil ncacn_ip_tcp,0 dieses Schlüssels kann nicht geändert werden.

    5. Schließen Sie den Registrierungs-Editor.

COM+-Katalog

Die Konfigurationseinstellungen der Enterprise Services-Anwendung werden im COM+ Katalog unterhalten. Die Mehrheit der Konfigurationselemente ist in der Registrierungsdatenbank (RegDB) enthalten, die aus Dateien besteht, die sich im folgenden Verzeichnis befinden:

%windir%\registration

Standardmäßig hat die Gruppe Jeder die Berechtigung, aus der Datenbank zu lesen. Modifizieren Sie die Zugriffssteuerungsliste (ACL) für dieses Verzeichnis, um den Lese- und Schreibzugriff auf Administratoren und das lokale Systemkonto zu beschränken. Gewähren Sie auch den Konten Lesezugriff, die verwendet werden, um die Enterprise Services-Anwendungen auszuführen. Hier ist die erforderliche ACL:

Administratoren: Lesen, Schreiben
System: Lesen, Schreiben
Enterprise Services-Konto <formatting role="bold">Ausführen als</formatting>: Lesen

Schützen von Enterprise Services-Anwendungen

Individuelle Anwendungskonfigurationseinstellungen werden im COM+ Katalog aufrechterhalten und können mit dem Komponentendienstwerkzeug oder durch Verwendung eines Scripts konfiguriert werden. Viele der unten besprochenen Einstellungen können auch durch Anwendungsentwickler spezifiziert werden, indem Sie die richtigen Daten auf Assemblyebene in der Assembly der bedienten Komponente verwenden. Wenn Sie die Dienstkomponente registrieren, beispielsweise mit Regsvcs.exe, wird der COM+ Katalog automatisch mit diesen Metadaten konfiguriert, auch wenn die Identität Ausführen als der Identität administrativ konfiguriert werden.

Um eine Enterprise Services-Anwendung zu schützen, müssen die folgenden Elemente konfiguriert werden:

  • Identität (Ausführen als)

  • Authentifizierungsebene

  • Rollenbasierte Sicherheit für COM+

  • Personifizierung

  • CRM Protokolldateien

  • Anwendungsassemblys

Identität (Ausführen als)

Konfigurieren Sie die Enterprise Services-Serveranwendungen, so dass diese in den Konten mit den geringsten Berechtigungen ausgeführt werden. Dies reduziert den möglichen Schaden, der auftreten könnte, wenn ein Serverprozess durch einen Angreifer beeinträchtigt wird, der die Ausführung von Code mit seinem eigenen Sicherheitskontext bedient.

Wenn die bedienten Komponenten innerhalb der Enterprise Services-Anwendung keinen Identitätswechsel für den Sicherheitskontext des aufrufenden Benutzers ausführen, wird die Identität der Prozessebene, die durch das Konto Ausführen als angegeben wird, für Downstream-Lokal- und Remotezugriff auf die Ressource verwendet. Um die Netzwerkauthentifizierung zu einem Remote-Datenbankserver zu unterstützen, kann ein "gespiegeltes" lokales Konto erstellt werden, welches ein lokales Konto auf dem Remoteserver ist, das einen gleichen Benutzernamen und ein gleiches Kennwort hat.

Hinweis: Wenn Sie mit den Enterprise Services die Einstellung zum Ausführen als Identität auswählen, wird dem Konto automatisch die Berechtigung Anmelden als Stapelverarbeitungsauftrag gewährt.

Authentifizierungsebene

Enterprise Services-Anwendungen authentifizieren Aufrufer mittels RPC, welches wiederum die zugrunde liegenden Authentifizierungsdienste des Betriebssystems verwendet, die durch die Ebene Security Service Provider Interface (SSPI) zur Verfügung gestellt werden. Dies bedeutet, dass Anwendungen die Aufrufer mittels der Windows-Authentifizierung, entweder Kerberos oder NTLM, authentifizieren.

RPC definiert die Authentifizierungsebenen, die feststellen, dass eine Authentifizierung eintritt, und ob die authentifizierte Kommunikation auf Integrität geprüft oder verschlüsselt werden soll. Sie sollten mindestens die Authentifizierung auf Aufrufebene verwenden, um sicherzustellen, dass jeder Methodenaufruf an eine bediente Komponentenmethode authentifiziert wird.

Hinweis: Eine Authentifizierung auf Aufruferebene führt nicht zur Verschlüsselung von Meldungsdaten. Folglich sollte die Authentifizierungsebene Paketsicherheit oder Authentifizierung auf Aufruferebene über einen mit IPSec geschützten Kanal verwendet werden, wenn das Abhören des Netzwerks eine ernsthafte Sorge bereitet.

In Tabelle 17.3 werden die verschiedenen Authentifizierungsebenen dargestellt:

Tabelle 17.3: Authentifizierungsebenen der Enterprise Services-Anwendung

Authentifizierungsebene

Beschreibung

Standard

Wählen Sie die Authentifizierungsebene mittels normaler Vereinbarungsregeln

Keine

Keine Authentifizierung

Verbinden

Authentifiziert die Anmeldeinformationen lediglich bei der ersten Verbindung vom Client mit dem Server

Aufruf

Authentifiziert zu Beginn jedes RPC-Aufrufs

Paket

Authentifiziert alle vom Client erhaltenen Daten

Paketintegrität

Authentifiziert alle Daten und verifiziert, dass keine der übertragenen Daten modifiziert wurden

Paketsicherheit

Authentifiziert alle Daten und verschlüsselt alle übertragenen Pakete mittels RPC-Verschlüsselung

  • Einstellen einer Authentifizierung auf Aufruferebene

    1. Starten Sie die Komponentendienste und öffnen Sie das Dialogfeld Eigenschaften der Anwendung.

    2. Klicken Sie auf die Registerkarte Sicherheit.

    3. Wählen Sie in der Dropdownliste Authentifizierungsebene für Aufrufe die Option Aufruf aus.

Rollenbasierte Sicherheit für COM+

Eine Autorisierung in Enterprise Services-Anwendungen wird durch die Enterprise Services (COM+)-Rollen zur Verfügung gestellt. COM+ Rollen enthalten Windows Benutzer- und Gruppenkonten und werden verwendet, um den Zugriff auf Anwendung, Komponente, Schnittstellen und Methode zu beschränken. Die Enterprise Services-Anwendungen sollten für Autorisierung auf Komponentenebene konfiguriert werden. Dadurch können Aufrufer für einzelne Dienstkomponenten autorisiert werden.

So konfigurieren Sie die Sicherheit auf der Grundlage von Rollen

  • Aktivieren von rollenbasierter Sicherheit.

  • Aktivieren von Zugriffsüberprüfungen auf Komponentenebene.

  • Erzwingen von Zugriffsüberprüfungen auf Komponentenebene.

Aktivieren von rollenbasierter Sicherheit

In Windows 2000 ist die rollenbasierte Sicherheit in der Standardeinstellung deaktiviert. In Windows Server 2003 ist sie standardmäßig aktiviert.

  • Aktivieren von rollenbasierter Sicherheit

    1. Starten Sie das Komponentendienstwerkzeug und öffnen Sie das Dialogfeld Eigenschaften der Anwendung.

    2. Klicken Sie auf die Registerkarte Sicherheit.

    3. Wählen Sie Zugriffsüberprüfungen für diese Anwendung erzwingen.

      Aktivieren von rollenbasierter Sicherheit

Abbildung 17.7
Aktivieren von rollenbasierter Sicherheit

Aktivieren von Zugriffsüberprüfungen auf Komponentenebene

Ohne Zugriffsüberprüfungen auf Komponentenebene wird jedem Konto, das für die Verbindung zu irgendwelchen Anwendungskomponenten verwendet wird, Zugriff gewährt, wenn es Mitglied einer Rolle innerhalb der Anwendung ist. Zugriffsüberprüfungen auf Komponentenebene ermöglichen es einzelnen Komponenten, ihre eigene Autorisierung anzuwenden. Dies ist der empfohlene Körnungsgrad.

  • Aktivieren von Zugriffsüberprüfungen auf Komponentenebene

    1. Starten Sie das Komponentendienstwerkzeug und öffnen Sie das Dialogfeld Eigenschaften der Anwendung.

    2. Klicken Sie auf die Registerkarte Sicherheit.

    3. Klicken Sie auf Zugriffsüberprüfungen auf der Prozess- und Komponentenebene durchführen.

      Aktivieren von Zugriffsüberprüfungen auf Komponentenebene

Abbildung 17.8
Aktivieren von Zugriffsüberprüfungen auf Komponentenebene

Erzwingen von Zugriffsüberprüfungen auf Komponentenebene

Um es einzelnen Komponenten innerhalb der Enterprise Services-Anwendung zu erlauben, Zugriffsüberprüfungen durchzuführen und Aufrufer zu autorisieren, müssen Sie Zugriffsüberprüfungen auf Koponentenebene aktivieren.

  • Erzwingen von Zugriffsüberprüfungen auf Komponentenebene

    1. Starten Sie das Tool für die Komponentendienste und erweitern Sie Ihre Anwendung in der Strukturansicht.

    2. Wählen Sie den Ordner Komponenten, klicken Sie mit der rechten Maustaste darauf und wählen Eigenschaften.

    3. Klicken Sie auf die Registerkarte Sicherheit.

    4. Klicken Sie auf Zugriffsüberprüfungen auf Komponentenebene erzwingen.

Hinweis: Diese Einstellung ist nur wirksam, wenn die Zugriffsüberprüfung auf Komponentenebene aktiviert ist und die Zugriffsüberprüfung auf Prozess- und Komponentenebene konfiguriert wurde (siehe oben).

Personifizierung

DCOM-Clients stellen die Personifizierungsebene ein, um die Personifizierungsfähigkeiten des Servers festzulegen, mit dem sie kommunizieren. Wenn sich eine Enterprise Services-Anwendung auf einem Anwendungsserver der mittleren Schicht befindet, betrifft die konfigurierte Personifizierungsebene alle Remoteaufrufe, die zu Downstream-Komponenten erfolgen, einschließlich dem Datenbankserver. Die Personifizierungsebene wird auf der Seite Sicherheit des Dialogfelds Eigenschaften der Anwendung in den Komponentendiensten eingestellt, dies wird in Abbildung 17.9 gezeigt.

DCOM-Personifizierungsebenen

Abbildung 17.9
DCOM-Personifizierungsebenen

Die entsprechende Ebene ist abhängig von der gewünschten Funktionalität der Anwendungsebene, obgleich die folgenden Richtlinien verwendet werden sollten, um die entsprechende Ebene zu bestimmen.

  • Vermeiden Sie einen anonymen Identitätswechsel. Die Downstream-Komponente kann Ihre Anwendung für Authentifizierungs- oder Autorisierungszwecke nicht identifizieren.

  • Verwenden Sie Identifizieren, um der Downstream-Komponente die Authentifizierung und Autorisierung Ihrer Anwendung zu ermöglichen. Sie wird jedoch nicht in der Lage sein, auf lokale oder remote Ressourcen über den personifizierten Sicherheitskontext Ihrer Anwendung zuzugreifen.

  • Verwenden Sie Identität annehmen, wenn Sie der Downstream-Komponente ermöglichen möchten, die Identität Ihrer Anwendung anzunehmen, so dass sie auf lokale Ressourcen auf dem Downstream-Server zugreifen kann.

  • Verwenden Sie Delegieren, wenn Sie der Downstream-Komponente ermöglichen möchten, die Identität Ihrer Anwendung anzunehmen, so dass sie auf lokale Ressourcen und Remoteressourcen zugreifen kann. Dies erfordert, dass Konten für die Delegierung im aktiven Verzeichnis konfiguriert werden.

Jeglicher Downstream-Ressourcenzugriff, der durch bediente Komponenten auf dem Anwendungsserver der mittleren Schicht durchgeführt wird, verwendet normalerweise die Identität der Serveranwendung. Wenn jedoch die bedienten Komponenten eine Personifizierung per Programm durchführen und die Clientanwendung (üblicherweise eine ASP.NET Webanwendung oder ein Webdienst auf dem Webserver) konfiguriert wurde, um Kerberos-Delegierung zu unterstützen, wird die Identität des Clients verwendet.

Weitere Informationen finden Sie unter "How To: Enable Kerberos Delegation in Windows 2000" im Abschnitt "How To" der "Microsoft patterns & practices Volume I, Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication" unter https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp.

CRM Protokolldateien

Wenn Ihre Enterprise Services-Anwendung CRM verwendet, sollten Sie sicherstellen, dass die CRM-Protokolldateien geschützt werden, um eine mögliche Veröffentlichung von Informationen zu verhindern. Abhängig von der Natur der Anwendung können die Dateien sicherheitsrelevante Anwendungsdaten enthalten. Die CRM-Protokolldateien werden im folgenden Verzeichnis erstellt:

%windir%\system32\dtclog

CRM-Protokolldateien werden von der Anwendungs-ID der Enterprise Services abgeleitet und haben die Dateinamenerweiterung .crmlog. CRM-Protokolldateien werden geschützt, wenn diese von den Enterprise Services erstellt werden und die Datei mit einer ACL konfiguriert ist, durch die vollständiger Zugriff auf das Konto Ausführen als der Anwendung gewährleistet wird. Kein anderes Konto hat Zugriff.

Wenn die Identität der Anwendung geändert wird, nachdem die Protokolldatei erstellt wurde, muss die ACL auf der Datei manuell geändert werden. Vergewissern Sie sich, dass die neue Ausführen als-Identität der Anwendung vollständigen Zugriff hat.

Anwendungsassemblys

Um die eingesetzten Anwendungsassemblys zu schützen, welche die bedienten Komponenten der Anwendung enthalten, sollte die ACL, die mit den DLL-Dateien der Assembly verbunden sind, gestärkt werden, um sicherzustellen, dass diese nicht von nicht berechtigten Benutzern ersetzt oder gelöscht werden können.

Wenden Sie die folgende ACL auf das DLL-Verzeichnis Ihrer Anwendung an:

Benutzer: Ausführen
Anwendungskonto <formatting role="bold">Ausführen als</formatting>: Ausführen
Administratoren: Lesen, Schreiben und Ausführen

Der Speicherort der Assembly-DLLs einer Anwendung wird bei der Einsetzung angegeben und kann daher von Installation zu Installation variieren. Das Dialogfeld Eigenschaften im Tool für die Komponentendienste zeigt nicht den Speicherort der Assembly-DLLs an. Stattdessen verweist es auf die Datei %windir%\System32\mscoree.dll, die die Übernahmedienste für die Komponente zur Verfügung stellt.

  • Prüfen des Speicherorts der Anwendungs-DLLs

    1. Starten Sie das Tool für die Komponentendienste und erweitern Sie Ihre Anwendung in der Strukturansicht.

    2. Erweitern Sie den Ordner Komponenten, klicken Sie mit der rechten Maustaste darauf und wählen Sie Eigenschaften.

    3. Entnehmen Sie dem Dialogfeld Eigenschaften die Klassen-ID (CLSID) der Komponente.

    4. Starten Sie Regedt32.exe und suchen Sie die erhaltene CLSID unter HKEY_CLASSES_ROOT\CLSID.

    5. Wählen Sie den Schlüssel InprocServer32 .

      Der Speicherort der DLL wird durch den Wert mit dem Namen CodeBase angezeigt.

 

Zusammenfassung

Wenn ausreichende Perimeternetzwerkverteidigungen angeordnet sind, kommen viele der Bedrohungen, die Anwendungsserver der mittleren Schicht betreffen, aus der Organisation selbst. Eine sichere Infrastruktur, die aus IPSec-Richtlinien besteht, den Zugriff auf den Anwendungsserver nur auf ausgewählte Webserver begrenzt sowie sichere Kommunikationskanäle bietet, mildert die Risiken.

Dieses Modul hat Ihnen zusätzliche Sicherheitsmaßnahmen gezeigt. Diese Maßnahmen unterscheiden sich abhängig von der verwendeten Technologie, die am Anwendungsserver verwendet wird.

Interne Firewalls auf jeder Seite des Anwendungsservers zeigen andere Probleme. Die Ports, die geöffnet werden müssen, sind abhängig von Elementen wie Transportprotokolle oder verteilte Transaktionen.

 

Weitere Informationen über die Probleme, denen sich dieses Modul zuwendet, finden Sie in den folgenden Artikeln in der Microsoft Knowledge Base unter https://support.microsoft.com: