Freigeben über

Erstellen sicherer Serviced Components

  • Artikel

* * *

Auf dieser Seite

Modulübersicht Modulübersicht
Zielsetzung Zielsetzung
Betrifft Betrifft
Verwendung dieses Moduls Verwendung dieses Moduls
Übersicht Übersicht
Risiken und Gegenmaßnahmen Risiken und Gegenmaßnahmen
Überlegungen zum Entwurf Überlegungen zum Entwurf
Authentifizierung Authentifizierung
Autorisierung Autorisierung
Konfigurationsverwaltung Konfigurationsverwaltung
Vertrauliche Daten Vertrauliche Daten
Überwachen und Protokollieren Überwachen und Protokollieren
Erstellen einer sicheren Serviced Component Erstellen einer sicheren Serviced Component
Überlegungen zur Codezugriffssicherheit Überlegungen zur Codezugriffssicherheit
Überlegungen zur Bereitstellung Überlegungen zur Bereitstellung
Zusammenfassung Zusammenfassung
Weitere Informationen Weitere Informationen

Modulübersicht

Serviced Components sind COM+-Infrastrukturdienste, die auch als Enterprise Services bezeichnet werden. Auf diese kann aus verwaltetem Code zugegriffen werden. Sie bestehen aus einer oder mehreren verwalteten Klassen, die von System.EnterpriseServices.ServicedComponent abgeleitet sind.

In diesem Modul wird beschrieben, wie die (COM+-)Sicherheit der Enterprise Services zur Authentifizierung und Autorisierung von Benutzern die Windows-Sicherheitsdienste verwendet. Außerdem lesen Sie, wie Sie mit bewährten Kodierungstechniken und geeigneter Katalogkonfiguration die Serviced Components sicher bereitstellen.

Dieses Modul ist an Entwickler gerichtet und enthält Beispiele für den Aufbau sicherer Serviced Components.

 

Zielsetzung

Themenbereiche:

  • Wichtige Punkte beim Entwerfen und Bereitstellen von COM+-Infrastrukturdiensten (Serviced Components).

  • Schutz vertraulicher Daten.

  • Autorisierung von Benutzern mit Enterprise Services-Rollen (COM+).

  • Verwendung von "Ausführen als"-Konten mit geringsten Berechtigungen.

  • Sichere geheime Informationen in Objektkonstruktor-Zeichenfolgen.

  • Überwachung von Serviced Components der mittleren Schicht.

  • Verfahren mit teilweiser Vertrauenswürdigkeit, da sichere Serviced Components eine vollständige Vertrauenswürdigkeit verlangen.

  • Wichtige Maßnahmen gegen allgemeine Bedrohungen der Enterprise Services wie Abhören des Netzwerks, nicht autorisierte Zugriffe, uneingeschränkte Delegierung, Offenlegung von Konfigurationsdaten und Abstreitbarkeit.

 

Betrifft

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

  • Microsoft® Windows® 2000 Server und Microsoft Windows Server™ 2003

  • Microsoft .NET Framework 1.1 und ASP.NET 1.1

 

Verwendung dieses Moduls

Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

  • Verwenden Sie dieses Modul in Verbindung mit dem Abschnitt über Enterprise Services in Modul 17, " Schützen des Anwendungsservers ". In diesem Abschnitt von Modul 17 wird beschrieben, wie Sie die Infrastruktur für Enterprise Services schützen und wie Sie Ihre Enterprise Services-Anwendung sperren können.

  • Verwenden Sie die Empfehlungen aus Modul 7, " Erstellen sicherer Assemblys ". In diesem Modul werden Verfahrensweisen zur Erstellung sicheren Codes erläutert, die Sie bei der Entwicklung von Serviced Components beachten sollten.

 

Übersicht

Auf COM+-Infrastrukturdienste (auch bekannt als Enterprise Services) kann aus verwaltetem Code zugegriffen werden. Enterprise Services-Anwendungen bestehen aus mindestens einer Serviced Component, die eine von System.EnterpriseServices.ServicedComponent verwaltete Klasse darstellt.

Serviced Components werden normalerweise zur Kapselung der Geschäfts- und Datenzugriffslogik einer Anwendung verwendet. Sie kommen ebenfalls zum Einsatz, wenn in der mittleren Schicht einer Anwendung Infrastrukturdienste wie verteilte Transaktionen, Object Pooling und Queued Components erforderlich sind. Häufig sind Enterprise Services-Anwendungen auf Anwendungsservern der mittleren Schicht zu finden (siehe Abbildung 11.1).

Serviced Components in einer Enterprise Services-Anwendung der mittleren Schicht

Abbildung 11.1
Serviced Components in einer Enterprise Services-Anwendung der mittleren Schicht

 

Risiken und Gegenmaßnahmen

Beachten Sie beim Erstellen von Serviced Components die folgenden Hauptbedrohungen:

  • Abhören des Netzwerks

  • Nicht autorisierter Zugriff

  • Uneingeschränkte Delegierung

  • Offenlegung von Konfigurationsdaten

  • "Tarnung"

In Abbildung 11.2 werden diese größten Bedrohungen und allgemeine Schwachstellen von Serviced Components dargestellt.

Enterprise Services-Bedrohungen

Abbildung 11.2
Enterprise Services-Bedrohungen

Abhören des Netzwerks

Häufig sind Enterprise Services-Anwendungen auf Anwendungsservern der mittleren Schicht zu finden, die sich nicht in der Nähe des Webservers befinden. Deshalb muss das entsprechende Netzwerk gegen das Abhören vertraulicher Anwendungsdaten geschützt werden. Sie können zwischen dem Web- und dem Anwendungsserver einen verschlüsselten IPSec-Kanal verwenden. Diese Lösung ist in Internet-Datenzentren weit verbreitet. Serviced Components unterstützen auch die Authentifizierung auf der RPC-Paketebene (Remote Procedure Call), die eine paketbasierte Verschlüsselung bietet. Dieses Verfahren wird meist zum Schutz der Kommunikation mit Desktopclients verwendet.

Nicht autorisierter Zugriff

Durch die Aktivierung der Autorisierung auf Grundlage von COM+-Rollen (unter Microsoft Windows 2000 in der Standardeinstellung deaktiviert) können Sie anonymen Zugriff verhindern und rollenbasierte Autorisierung bieten, um Zugriffe auf die eingeschränkten Operationen Ihrer Serviced Components zu steuern.

Uneingeschränkte Delegierung

Wenn Sie unter Windows 2000 Delegierung aktivieren, um einem Remoteserver mit dem Identitätswechseltoken des Clients den Zugriff auf Netzwerkressourcen zu gestatten, ist die Delegierung uneingeschränkt. Das heißt, es gibt keine Begrenzung für die Anzahl der zu durchlaufenden Netzwerkabschnitte. In Microsoft Windows Server 2003 steht erstmals die eingeschränkte Delegierung zur Verfügung.

Offenlegung von Konfigurationsdaten

Viele Anwendungen speichern vertrauliche Daten, wie die Zeichenfolgen zur Herstellung einer Verbindung zu einer Datenbank, mit Objektkonstruktor-Zeichenfolgen im COM+-Katalog. Diese Zeichenfolgen werden bei der Erstellung eines Objekts von COM+ abgerufen und an das Objekt weitergegeben. Deshalb sollten Sie vertrauliche Konfigurationsdaten vor der Speicherung im Katalog verschlüsseln.

"Tarnung"

Diese Bedrohung tritt auf, wenn ein Benutzer die Durchführung einer Operation oder Transaktion abstreitet und Sie Ihre Ansprüche nicht ausreichend beweisen können. Deshalb sollten Sie alle Anwendungsschichten überwachen. Serviced Components sollten auf der mittleren Schicht die Benutzeraktivitäten protokollieren. Serviced Components haben normalerweise Zugriff auf die Identität des ursprünglichen Benutzers, da Front-End-Webanwendungen in Enterprise Services-Szenarien im Normalfall einen Identitätswechsel durchführen.

 

Überlegungen zum Entwurf

Bevor Sie mit dem Programmieren beginnen, sind beim Entwurf einige wichtige Aspekte zu beachten. Es folgen die Hauptgesichtspunkte:

  • Rollenbasierte Autorisierung

  • Schutz vertraulicher Daten

  • Überwachungsanforderungen

  • Aktivierungstyp der Anwendung

  • Transaktionen

  • Codezugriffssicherheit

Rollenbasierte Autorisierung

Stellen Sie für eine wirksame rollenbasierte Autorisierung mit COM+-Rollen sicher, dass für den Aufruf der Serviced Component der Sicherheitskontext des ursprünglichen Benutzers verwendet wird. Dadurch können Sie eine besser abgestimmte rollenbasierte Autorisierung auf Grundlage der Gruppenmitgliedschaft des Benutzers durchführen. Wenn eine ASP.NET-Webanwendung Ihre Serviced Components aufruft, muss die Webanwendung vor dem Aufruf Ihrer Komponente für den Benutzer einen Identitätswechsel durchführen.

Schutz vertraulicher Daten

Wenn Ihre Serviced Components vertrauliche Daten verarbeiten wie Informationen über Ihre Mitarbeiter, finanzielle Transaktionen oder Krankenakten, schützen Sie die Daten, während sie über das Netzwerk übertragen werden. Wenn Ihre Anwendung nicht innerhalb einer sicheren Internet-Data-Center-Umgebung ausgeführt wird, in der die Verschlüsselung mit IPSec auf der Transportschicht stattfindet, können Sie auch RPC-Verschlüsselung verwenden. Verwenden Sie dafür die Authentifizierungsebene Paketsicherheit. Weitere Informationen finden Sie weiter unten in diesem Modul im Abschnitt über "Vertrauliche Daten".

Überwachungsanforderungen

Als Maßnahme gegen "Tarnung" sollten die entsprechenden von den Enterprise Service-Komponenten durchgeführten Transaktionen protokolliert werden. Planen Sie schon in der Entwurfsphase, welche Vorgangsarten überwacht und welche Detailinformationen für diese protokolliert werden sollen. Hierzu sollten mindestens die Identitäten zählen, unter denen die Transaktion ausgelöst beziehungsweise durchgeführt wurde. Diese stimmen nicht immer überein.

Aktivierungstyp der Anwendung

Entscheiden Sie in der Entwurfsphase, wie Ihre Serviced Component zu aktivieren ist. Sie können sie mit einer Prozessinstanz von Dllhost.exe aktivieren oder innerhalb des Clientprozesses ausführen. Serveranwendungen werden außerhalb des Prozesses in einer Instanz von Dllhost.exe ausgeführt. Bibliotheksanwendungen werden im Prozessadressbereich des Clients ausgeführt. Bibliotheksanwendungen sind aufgrund der fehlenden prozessübergreifenden Kommunikation effizienter. Jedoch sind sie weniger konfigurierbar und nicht durch Isolierung auf Prozessebene geschützt. Viele Sicherheitseinstellungen wie die Authentifizierungs- und Identitätswechselebenen werden vom Clientprozess geerbt.

Transaktionen

Wenn Sie verteilte Transaktionen verwenden möchten, überlegen Sie sich, wo die Transaktion ausgelöst wird und welche Folgen sich daraus ergeben, dass Transaktionen zwischen durch Firewalls getrennten Komponenten und Ressourcenverwaltern ausgeführt werden. In diesem Szenario muss die Firewall dafür konfiguriert sein, den DTC-Datenverkehr (Microsoft Distributed Transaction Coordinator) zu unterstützen.

Wenn zu Ihrer physischen Bereitstellungsarchitektur ein Anwendungsserver der mittleren Schicht gehört, ist es im Allgemeinen vorzuziehen, Transaktionen von der Enterprise Services-Anwendung auf dem Anwendungsserver auslösen zu lassen, nicht von der Front-End-Webanwendung.

Codezugriffssicherheit

Normalerweise werden Anwendungen, die Serviced Components verwenden, als vollständig vertrauenswürdig eingestuft. Deshalb ist Codezugriffssicherheit für die Autorisierung des aufrufenden Codes nur eingeschränkt verwendbar. Jedoch ist es für Enterprise Services erforderlich, dass der aufrufende Code über die notwendigen Berechtigungen für den Aufruf von nicht verwaltetem Code verfügt. In erster Linie hat dies zur Folge, dass Sie aus einer nur teilweise vertrauenswürdigen Webanwendung eine Enterprise Services-Komponente nicht direkt aufrufen können. Auf den ASP.NET-Ebenen für teilweise Vertrauenswürdigkeit (Hoch, Mittel, Niedrig und Minimal) wird nicht die Berechtigung für nicht verwalteten Code erteilt. Wenn Sie eine Serviced Component aus einer teilweise vertrauenswürdigen Anwendung aufrufen müssen, muss der privilegierte Code, der Ihre Komponente aufruft, in einer Sandbox ausgeführt werden. Weitere Informationen finden Sie weiter unten in diesem Modul im Abschnitt über "Überlegungen zur Codezugriffssicherheit".

 

Authentifizierung

Enterprise Services-Anwendungen verwenden die Windows-Authentifizierung. Je nach Client- und Serverbetriebssystem ist das die NTLM- oder die Kerberos-Authentifizierung. In Windows 2000- oder Windows Server 2003-Umgebungen wird die Kerberos-Authentifizierung verwendet.

Beim Erstellen von Serviced Components müssen Sie in erster Linie sicherstellen, dass durch die Authentifizierung aller Aufrufe anonyme Benutzer daran gehindert werden, auf die Funktionalität Ihrer Komponente zuzugreifen.

Verwenden der Authentifizierung auf Aufrufebene

Lehnen Sie anonyme Benutzer ab, indem Sie mindestens Authentifizierung auf Aufrufebene verwenden. Konfigurieren Sie diese Einstellung, indem Sie Ihrer Serviced Component-Assembly das folgende Attribut hinzufügen:

[assembly: ApplicationAccessControl(
                Authentication = AuthenticationOption.Call)]

Hinweis: Gleichbedeutend hierzu können Sie auch in den Einstellungen für Komponentendienste im Dialogfeld Eigenschaften der entsprechenden Anwendung auf der Registerkarte Sicherheit die Option Authentifizierungsebene für Aufrufe auf Aufruf einstellen.

 

Autorisierung

In Enterprise Services werden für die Autorisierung COM+-Rollen verwendet. Sie können die Abstufung der Autorisierung für Anwendungen, Komponenten, Schnittstellen und Methoden steuern. Sie können mit folgenden Möglichkeiten verhindern, dass Benutzer eingeschränkte Vorgänge der Serviced Components Ihrer Anwendung durchführen können:

  • 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. Stellen Sie die automatische Aktivierung der rollenbasierten Sicherheit bei der Registrierung Ihrer Komponente sicher (normalerweise mit Regsvcs.exe), indem Sie Ihrer Serviced Component-Assembly die folgenden Attribute hinzufügen.

[assembly: ApplicationAccessControl(true)]

Hinweis: Gleichbedeutend hierzu können Sie auch in den Einstellungen für Komponentendienste im Dialogfeld Eigenschaften der entsprechenden Anwendung auf der Registerkarte Sicherheit die Option Zugriffsüberprüfungen für diese Anwendung erzwingen aktivieren.

Aktivieren von Zugriffsüberprüfungen auf Komponentenebene

Um Rollenüberprüfungen auf Komponenten-, Schnittstellen- oder Methodenebene zu unterstützen, müssen Zugriffsüberprüfungen auf Komponentenebene aktiviert sein. Stellen Sie die automatische Aktivierung der Zugriffsüberprüfungen auf Komponentenebene bei der Registrierung Ihrer Komponente sicher, indem Sie Ihrer Serviced Component-Assembly die folgenden Attribute hinzufügen.

[assembly: ApplicationAccessControl(AccessChecksLevel= 
               AccessChecksLevelOption.ApplicationComponent)]

Hinweis: Gleichbedeutend hierzu können Sie auch in den Einstellungen für Komponentendienste im Dialogfeld Eigenschaften der entsprechenden Anwendung auf der Registerkarte Sicherheit die Option Zugriffsüberprüfungen auf der Prozess- und Komponentenebene durchführen auswählen.

Erzwingen von Zugriffsüberprüfungen auf Komponentenebene

Um einzelnen Komponenten Zugriffsüberprüfungen zu gestatten, müssen Sie diese auf Komponentenebene erzwingen. Diese Einstellung ist nur wirksam, wenn die anwendungsweite Sicherheitsebene auf die Prozess- und die Komponentenebene eingestellt ist (siehe oben). Stellen Sie die automatische Aktivierung der Zugriffsüberprüfungen auf Komponentenebene bei der Registrierung Ihrer Komponente sicher, indem Sie Ihren Serviced Component-Klassen die folgenden Attribute hinzufügen.

[ComponentAccessControl(true)]
public class YourServicedComponent : ServicedComponent
{
}

Hinweis: Gleichbedeutend hierzu können Sie auch in den Einstellungen für Komponentendienste im Dialogfeld Eigenschaften der entsprechenden Komponente auf der Registerkarte Sicherheit die Option Zugriffsüberprüfungen auf Komponentenebene erzwingen aktivieren.

 

Konfigurationsverwaltung

Neben den konfigurierbaren Einstellungen, die COM+ Administratoren im Tool für Komponentendienste bietet, führen Entwickler konfigurationsbezogene Funktionen häufig im Code durch. Beispielsweise könnten die Funktionen im COM+-Katalog gespeicherte Zeichenfolgen für die Objekterzeugung abrufen. Beachten Sie bei der Konfigurationsverwaltung mit Enterprise Services die folgenden Hauptthemen:

  • Verwendung von "Ausführen als"-Konten mit geringsten Berechtigungen.

  • Vermeiden der Speicherung von geheimen Informationen in Objektkonstruktor-Zeichenfolgen.

  • Vermeiden uneingeschränkter Delegierung.

Verwendung von "Ausführen als"-Konten mit geringsten Berechtigungen

Beim Entwickeln sollten Sie Ihre Dienstkomponenten unter einem lokalen Konto mit geringsten Berechtigungen ausführen und testen, nicht mit Ihrem interaktiven Benutzerkonto. Die Konfiguration des Kontos sollte dem des "Ausführen als"-Kontos möglichst genau entsprechen, das der Administrator in der Produktionsumgebung wahrscheinlich verwendet.

Vermeiden der Speicherung von geheimen Informationen in Objektkonstruktor-Zeichenfolgen

Wenn Sie geheime Informationen wie Zeichenfolgen zur Herstellung einer Verbindung zu einer Datenbank oder Kennworte im COM+-Katalog in Objektkonstruktor-Zeichenfolgen speichern, kann jedes Mitglied der lokalen Administratorengruppe auf diese Klartextdaten zugreifen. Vermeiden Sie die Speicherung von geheimen Informationen. Wenn Sie geheime Informationen speichern müssen, verschlüsseln Sie die Daten. DPAPI ist eine gute Implementierungsvariante, da es Probleme im Zusammenhang mit der Schlüsselverwaltung vermeidet.

Rufen Sie zur Laufzeit die Zeichenfolge für die Objekterzeugung ab, und entschlüsseln Sie die Daten mit DPAPI. Weitere Informationen über die Verwendung von DPAPI aus verwaltetem Code finden Sie auf https://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp im MSDN-Artikel "Building Secure ASP.NET Applications" unter "How to create a DPAPI library".

[ConstructionEnabled(Default="")]
public class YourServicedComponent : ServicedComponent, ISomeInterface
{
  // Zuerst wird der Objektkonstruktor aufgerufen.
  public YourServicedComponent() {}
  // Dann wird die Zeichenfolge für die Objekterzeugung an die Methode "Construct" übergeben.
  protected override void Construct(string constructString)
  {
    // Entschlüsseln Sie die Konfigurationsdaten mit DPAPI.
  }
}

Vermeiden uneingeschränkter Delegierung

Serviced Component-Clients werden, je nach Umgebung, mit NTLM- oder Kerberos-Authentifizierung authentifiziert. Kerberos unterstützt in Windows 2000 eine uneingeschränkte Delegierung, das heißt, dass die Anzahl der mit den Anmeldeinformationen des Clients zu durchlaufenden Netzwerkabschnitte unbegrenzt ist.

Wenn der Client ASP.NET ist, können Sie die Identitätswechselebene in Machine.config mit dem Attribut comImpersonation auf das Element <processModel> konfigurieren:

comImpersonationLevel="[Default|Anonymous|Identify|Impersonate|Delegate]"

Mit der für eine Enterprise Services-Serveranwendung definierten Identitätswechselebene werden die Identitätswechselfunktionen der Remoteserver festgelegt, mit denen die Serviced Components kommunizieren können. In diesem Fall sind die Serviced Components die Clients. Mit dem folgenden Attribute können Sie die Identitätswechselebene für eine Serviced Component angeben, die angewendet wird, wenn die Service Component ein Client ist:

[assembly: ApplicationAccessControl(
                ImpersonationLevel=ImpersonationLevelOption.Identify)]

Hinweis: Gleichbedeutend hierzu können Sie auch in den Einstellungen für Komponentendienste im Dialogfeld Eigenschaften der entsprechenden Anwendung auf der Registerkarte Sicherheit den Wert Identitätswechselebene einstellen.

In der folgenden Tabelle werden die Auswirkungen der einzelnen Identitätswechselebenen beschrieben:

Tabelle 11.1: Identitätswechselebenen

Identitätswechselebene

Beschreibung

Anonym

Der Server kann den Client nicht identifizieren.

Identifizieren

Der Server kann den Client identifizieren und mit dem Zugriffstoken des Clients Zugriffsüberprüfungen durchführen.

Identität wechseln

Der Server kann mit den Anmeldeinformationen des Clients auf lokale Ressourcen zugreifen.

Delegieren

Der Server kann mit den Anmeldeinformationen des Clients auf Remoteressourcen zugreifen (hierfür ist Kerberos und eine bestimmte Kontokonfiguration erforderlich).

Weitere Informationen finden Sie in Modul 17, "Schützen des Anwendungsservers", im Abschnitt über Identitätswechsel, unter https://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp sowie im MSDN-Artikel "Building Secure ASP.NET Applications" im Abschnitt "References" unter "How to Enable Kerberos Delegation in Windows 2000".

 

Vertrauliche Daten

Wenn Ihre Anwendung vertrauliche Daten von und zu einer Serviced Component über ein Netzwerk überträgt und somit von Lauschangriffen auf das Netzwerk bedroht ist, sollten Sie mit Verschlüsselung sicherstellen, dass die Daten vertraulich und unverändert bleiben. Sie können den Schutz mit IPSec auf der Transportebene einrichten oder auf der Anwendungsebene, indem Sie Ihre Enterprise Services-Anwendung so konfigurieren, dass als Authentifizierungsebene die RPC-Paketsicherheit verwendet wird. Dies gewährleistet Datenschutz und Integrität, indem jedes zu oder von der Serviced Component gesendete Datenpaket verschlüsselt wird.

Sie können die Authentifizierungsebene Paketsicherheit mit dem Tool für Komponentendienste einrichten oder indem Sie die folgenden Attribute Ihrer Serviced Component-Assembly hinzufügen:

[assembly: ApplicationAccessControl(
                   Authentication = AuthenticationOption.Privacy)]

Weitere Informationen über die Verwendung von IPSec zur Verschlüsselung der Datenübertragung zwischen zwei Computern finden Sie unter https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT00.asp im Artikel "Microsoft patterns & practices Volume I, Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication" im Abschnitt "How To" unter "How To: Use IPSec to Provide Secure Communication Between Two Servers".

 

Überwachen und Protokollieren

Sie können die potenzielle Bedrohung der "Tarnung" (bei der Benutzer die Durchführung bestimmter Transaktionen oder wichtiger Vorgänge abstreiten) vermeiden, indem Sie Vorgänge auf allen Ebenen Ihrer Anwendung überwachen und protokollieren.

Überwachen von Benutzertransaktionen

Wenn Ihre Webanwendung oder Ihr Webdienst für Identitätswechsel eingerichtet ist, wird die Identität des ursprünglichen Benutzers automatisch an eine Enterprise Services-Anwendung übertragen und steht in SecurityCallContext.OriginalCaller zur Verfügung. Dies ist für eine Überwachung auf der mittleren Schicht nützlich. Im folgenden Code wird dargestellt, wie Sie auf diese Informationen zugreifen können:

[ComponentAccessControl]
public class YourServicedComponent : ServicedComponent
{
  public void ShowCallers()
  {
    SecurityCallers callers = SecurityCallContext.CurrentCall.Callers;
    foreach(SecurityIdentity id in callers)
    {
      LogEvent(id.AccountName);
    }
  }
  private void LogEvent(string message)
  {
    try
    {
      if (!EventLog.SourceExists(appName))
      {
        EventLog.CreateEventSource(appName, eventLog);
      }
      EventLog.WriteEntry(appName, message, EventLogEntryType.Information );
    }
    catch (SecurityException secex)
    {
      throw new SecurityException(
            "Event source does not exist and cannot be created.", secex);
    }
  }
}

Um ein Ereignis in das Ereignisprotokoll schreiben zu können, muss eine Ereignisquelle vorhanden sein, die die Enterprise Services-Anwendung einem bestimmten Ereignisprotokoll zuordnet. In dem Codebeispiel oben wird die Ereignisquelle zur Laufzeit erstellt, das heißt, das Prozesskonto der Serviced Component muss über die entsprechenden Berechtigungen in der Registrierung verfügen.

  • So gestatten Sie der Prozessidentität der Serviced Component das Erstellen von Ereignisquellen

    • Gestatten Sie dem Prozesskonto der Serviced Component den entsprechenden Zugriff, indem Sie mit regedit32.exe die Berechtigungen unter dem folgenden Registrierungsschlüssel anpassen:

      HKLM\SYSTEM\CurrentControlSet\Services\Eventlog

      Die entsprechenden Konten müssen mindestens über die folgenden Berechtigungen verfügen:

      • Query key value (Schlüsselwert abfragen)

      • Set key value (Schlüsselwert festlegen)

      • Create subkey (Teilschlüssel erstellen)

      • Enumerate subkeys (Teilschlüssel auflisten)

      • Notify (Benachrichtigen)

      • Read (Lesen)

Wahlweise können Sie auch eine Klasse Installer verwenden und die Ereignisquelle für die Anwendung bei der Installation erstellen, wenn Administratorrechte verfügbar sind. Weitere Informationen über dieses Vorgehen finden Sie in Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente", unter "Überwachen und Protokollieren".

 

Erstellen einer sicheren Serviced Component

Nach den Bedrohungen und verfügbaren Gegenmaßnahmen für Serviced Components und Enterprise Services-Anwendungen werden in den folgenden Codeausschnitten die Hauptmerkmale einer sicheren Serviced Component-Implementierung anhand der einfachen Klasse Customer dargestellt. Aus Gründen der Übersichtlichkeit sind die Details der Methodenimplementierung nicht enthalten.

Implementierung der Assembly

Im folgenden Codeausschnitt aus assemblyinfo.cs werden die Metadaten der Assemblysebene gezeigt, mit denen der COM+-Katalog konfiguriert wird, wenn die Serviced Component-Assembly mit regsvcs.exe bei den Enterprise Services registriert wird.

// (1) Assembly hat einen starken Namen.
[assembly: AssemblyKeyFile(@"..\..\Customer.snk")]

// Konfiguration der Enterprise Services 
[assembly: ApplicationName("CustomerService")]
[assembly: Description("Customer Services Application")]
// (2) Serveranwendung, wird in der Prozessinstanz von "dllhost.exe" ausgeführt.
[assembly: ApplicationActivation(ActivationOption.Server)]
// (3) Aktivieren der Zugriffsüberprüfungen auf Komponentenebene.
// (4) Angeben der Authentifizierung auf Aufrufebene.
// (5) Festlegen der Identitätswechselebene für nachgeschaltete Aufrufe auf "Identify".
[assembly: ApplicationAccessControl(
              AccessChecksLevel=AccessChecksLevelOption.ApplicationComponent,
              Authentication=AuthenticationOption.Call,
              ImpersonationLevel=ImpersonationLevelOption.Identify)]

Im Codebeispiel oben werden die folgenden Sicherheitsmerkmale verdeutlicht (die Nummern entsprechen den in den Kommentarzeilen).

  1. Die Assembly hat einen starken Namen. Serviced Components müssen eindeutig benannt sein. In Bezug auf die Sicherheit hat dies den zusätzlichen Vorteil, dass die Assembly digital signiert ist. Dadurch ist jede Änderung durch einen Angreifer zu erkennen und die Assembly wird nicht geladen.

  2. Die Anwendung ist so konfiguriert, dass sie in einer ausgewiesenen Instanz von dllhost.exe als Serveranwendung ausgeführt wird. Dadurch können Sie für die Bereitstellung die "Ausführen als"-Identität mit geringster Berechtigung angeben.

  3. Die Anwendung ist so konfiguriert, dass Zugriffsüberprüfungen auf Komponentenebene unterstützt werden. Dadurch können Sie Benutzer anhand der Rollenmitgliedschaft auf Ebene der Klassen, Schnittstellen und Methoden autorisieren.

  4. Die Authentifizierung erfolgt auf Benutzerebene. Das bedeutet, dass für jeden Methodenaufruf von einem Client eine Authentifizierung stattfindet.

  5. Für ausgehende Aufrufe von dieser Serviced Component an andere Komponenten auf Remoteservern ist die Identitätswechselebene auf Identify gesetzt. Das bedeutet, dass die nachgeschaltete Komponente den Benutzer identifizieren, jedoch keinen Identitätswechsel durchführen kann.

    Hinweis: Die Identitätswechselebene für einen aufrufenden Client, der eine ASP.NET-Webanwendung oder einen ASP.NET-Webdienst ausführt, wird auf dem Clientwebserver in Machine.config im Element <processModel> angegeben.

Klassenimplementierung der Serviced Component

Im folgenden Codeausschnitt wird die Sicherheitskonfiguration der teilweise implementierten Klasse Customer verdeutlicht.

namespace busCustomer
{
  // (1) Explizite Schnittstellendefinition zur Unterstützung der Autorisierung auf Methodenebene
  public interface ICustomerAdmin
  {
    void CreditAccountBalance(string customerID, double amount);
  }
  // (2) Erzwingen der Zugriffsüberprüfungen auf Komponentenebene.
  [ComponentAccessControl]
  public sealed class Customer : ServicedComponent, ICustomerAdmin
  {
    private string appName = "Customer";
    private string eventLog = "Application";
    // Implementierung von "Icustomer"
    // (3) Zugriff auf "CreditAccountBalance" wird eingeschränkt auf Mitglieder der
    //     Rollen "Manager" und "Senior Manager".
    [SecurityRole("Manager")]
    [SecurityRole("Senior Manager")]
    public void CreditAccountBalance(string customerID, double amount)
    {
      // (4) Strukturierte Ausnahmebehandlung zum Schutz der Implementierung.
      try
      {
        // (5) Überprüfen, ob Sicherheit aktiviert ist.
        if (ContextUtil.IsSecurityEnabled)
        {
          // Nur Manager können Kredite von über 
          // 1.000 $ bewilligen.
          if (amount &#62; 1000) {
            // (6) Überprüfen der Rollen zur Autorisierung von Kreditbewilligungen
            if (ContextUtil.IsCallerInRole("Senior Manager")) {
              // Aufrufen der Datenzugriffskomponente zur Aktualisierung der Datenbank.
              . . .
              // (7) Überwachen der Transaktion.
              AuditTransaction(customerID, amount);
            }
            else {
              throw new SecurityException("Caller not authorized");
            }
          }
        } 
        else {
          throw new SecurityException("Security is not enabled");
        }
      }
      catch( Exception ex)
      {
        // Protokollieren der Ausnahmedetails.
        throw new Exception("Failed to credit account balance for customer: " +
                             customerID, ex);
      }
    }
    private void AuditTransaction(string customerID, double amount)
    {
      // (8) Zur Protokollierung wird die ursprüngliche Identität des Benutzers 
      //     aus dem Aufrufkontext abgerufen.
      SecurityIdentity caller = SecurityCallContext.CurrentCall.OriginalCaller;
      try
      {
        if (!EventLog.SourceExists(appName))
        {
          EventLog.CreateEventSource(appName,eventLog);
        }
        StringBuilder logmessage = new StringBuilder();
        logmessage.AppendFormat("{0}User {1} performed the following transaction" 
                               + "{2} Account balance for customer {3} "
                               + "credited by {4}",
                                Environment.NewLine, caller.AccountName, 
                                Environment.NewLine, customerID, amount);
        EventLog.WriteEntry(appName, logmessage.ToString(), 
                            EventLogEntryType.Information);
      }
      catch(SecurityException secex)
      {
        throw new SecurityException(
                   "Event source does not exist and cannot be created", secex);
      }
    }
  }
}

Im Codebeispiel oben werden die folgenden Sicherheitsmerkmale verdeutlicht (die Nummern entsprechen den in den Kommentarzeilen):

  1. Eine Schnittstelle wird explizit für die Unterstützung der Autorisierung mit COM+-Rollen auf Schnittstellen- und Methodenebene definiert und implementiert.

  2. Für die Klasse werden Zugriffsüberprüfungen auf Komponentenebene auf Klassenebene mit dem Attribute [ComponentAccessControl] aktiviert.

  3. Mit dem Attribut [SecurityRole] wird der Zugriff auf die Methode CreditAccountBalance auf Mitglieder der Rollen Manager und Senior Managers eingeschränkt.

  4. Die Implementierung wird durch eine strukturierte Ausnahmebehandlung geschützt. Ausnahmen werden aufgefangen, protokolliert und eine entsprechende Ausnahme wird an den Benutzer übertragen.

  5. Durch den Code wird zuerst überprüft, ob Sicherheit aktiviert ist, erst anschließend erfolgt die explizite Rollenüberprüfung. Dadurch ist gewährleistet, dass Transaktionen nicht durchgeführt werden können, wenn die Sicherheitskonfiguration der Anwendung versehentlich oder absichtlich von einem Administrator deaktiviert wurde.

    Hinweis: Wenn die Sicherheit deaktiviert ist, gibt die Methode IsCallerInRole immer "wahr" zurück.

  6. Aufgrund der in der Methode vereinbarten Sicherheit müssen Benutzer Mitglieder der Rollen Manager oder Senior Manager sein. Für eine fein abgestufte Autorisierung wird die Rollenmitgliedschaft des Benutzers im Code explizit überprüft.

  7. Die Transaktion wird überwacht.

  8. In der Implementierung der Überprüfung wird die Identität des ursprünglichen Benutzers mit dem Objekt SecurityCallContext abgerufen.

 

Überlegungen zur Codezugriffssicherheit

Anwendungen, die Serviced Components verwenden, werden normalerweise als vollständig vertrauenswürdig eingestuft. Deshalb ist für die Autorisierung des aufrufenden Codes die Codezugriffssicherheit nur eingeschränkt verwendbar. Im aufrufenden Code sollten die folgenden Punkte beachtet werden:

  • Zur Aktivierung und Durchführung von kontextübergreifenden Aufrufen auf Serviced Components ist die Berechtigung für nicht verwalteten Code erforderlich.

  • Wenn der Client einer Serviced Component eine ASP.NET-Webanwendung ist, muss deren Vertrauensstufe auf Full gesetzt sein (siehe unten).

    <trust level="Full" />

    Wenn die Vertrauensebene Ihrer Webanwendung nicht auf Vollständig eingestellt ist, hat sie keine Berechtigung für nicht verwalteten Code. In diesem Fall müssen Sie eine Wrapperassembly erstellen, die in einer Sandbox ausgeführt wird, um die Kommunikation mit der Serviced Component zu kapseln. Außerdem müssen Sie die Sicherheitsrichtlinie für den Codezugriff konfigurieren, um der Wrapperassembly die Berechtigung für nicht verwalteten Code zu erteilen. Weitere Informationen über die Sandbox-Technik zur Kapselung von hoch privilegiertem Code finden Sie in Modul 9, "Verwenden der Codezugriffssicherheit mit ASP.NET".

  • Wenn eine Referenz auf eine Serviced Component an nicht vertrauenswürdigen Code übergeben wird, können die auf der Serviced Component definierten Methoden aus dem nicht vertrauenswürdigen Code nicht aufgerufen werden. Eine Ausnahme dieser Regel sind Methoden, die keine Kontextumschaltungs- oder Übernahmedienste erfordern und keine Mitglieder von System.EnterpriseServices aufrufen. Solche Methoden können von nicht vertrauenswürdigem Code aufgerufen werden.

 

Überlegungen zur Bereitstellung

Enterprise Services-Anwendungen werden normalerweise auf dem Webserver oder einem Remoteanwendungsserver installiert. In Abbildung  11.3 werden die beiden typischen Bereitstellungsszenarien für Enterprise Services dargestellt. In Bezug auf die Sicherheit ist der entscheidende Unterschied im Remotebereitstellungsszenario, dass die Daten von und zu der Serviced Component über das Netzwerk übertragen werden, häufig durch eine interne Firewall zwischen dem internen und dem Perimeternetzwerk.

Typische Bereitstellungskonfigurationen für Enterprise Services

Abbildung 11.3
Typische Bereitstellungskonfigurationen für Enterprise Services

Entwickler und Administratoren müssen im Zusammenhang mit der Bereitstellung die folgenden Aspekte beachten:

  • Firewallbeschränkungen, einschließlich der Ports für DCOM und DTC

  • "Ausführen als"-Konfiguration

  • Speichern von geheimen Informationen in Objektkonstruktor-Zeichenfolgen

Weitere Informationen über die Anwendung sicherer Konfiguration bei der Bereitstellung finden Sie in Modul 17, "Schützen des Anwendungsservers".

Firewallbeschränkungen

Wenn der Client und die Enterprise Services-Anwendung durch eine interne Firewall getrennt sind, müssen die entsprechenden Ports für DCOM und möglicherweise für DTC (wenn Ihre Anwendung verteilte Transaktionen verwendet) geöffnet sein.

DCOM verwendet die dynamische RPC-Portzuordnung, die in der Standardeinstellung 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 auf der internen Firewall beschränken können:

  • Definieren Sie Portbereiche.

    Auf diese Weise können Sie die dynamisch von RPC zugeordneten Ports steuern.

  • Verwenden Sie die statische Endpunktzuordnung.

    Windows 2000 mit SP3 (oder Quick Fix Engineering [QFE] ab Version 18.1) beziehungsweise 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. Im Besonderen müssen Sie für RPC Port 135 und für Ihre Enterprise Services-Anwendung einen festgelegten Port öffnen.

Weitere Informationen über die Definition von Portbereichen und die statische Endpunktzuordnung finden Sie in Modul 17, "Schützen des Anwendungsservers".

Verwenden von Webdiensten

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. Dadurch müssen Sie nur für den HTTP-Datenverkehr und für die in beide Richtungen fließenden SOAP-Nachrichten (Simple Object Access Protocol) Port 80 öffnen, wie in Abbildung 11.4 dargestellt.

Kommunikation mit Enterprise Services über HTTP unter Verwendung einer Fassadenschicht für Webdienste

Abbildung 11.4
Kommunikation mit Enterprise Services über HTTP unter Verwendung einer Fassadenschicht für Webdienste

Durch diesen Ansatz können Sie den Kontext einer Transaktion nicht vom Client zum Server übertragen, obwohl es sich in vielen Fällen anbietet, in denen Ihre Bereitstellungsarchitektur einen Anwendungsserver der mittleren Schicht enthält, Transaktionen in der Remote-Serviced Component auf dem Anwendungsserver zu initiieren.

Weitere Informationen über die physischen Anforderungen für die Bereitstellung von Dienstagenten und Dienstschnittstellen wie die Fassadenschicht für Webdienste finden Sie im MSDN-Artikel "Application Architecture for .NET: Designing Applications and Services" im Abschnitt "Reference" unter "Physical Deployment and Operational Requirements".

DTC-Anforderungen

Wenn Ihre Anwendung zwischen Remoteservern, die durch eine interne Firewall getrennt sind, verteilte COM+-Transaktionen verwendet, müssen für den DTC-Datenverkehr auf dem Firewall die erforderlichen Ports geöffnet sein.

Wenn in Ihrer Bereitstellungsarchitektur eine Remote-Anwendungsschicht enthalten ist, werden Transaktionen normalerweise in 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 Konfiguration eines Firewalls für den DTC-Datenverkehr finden Sie in Modul 18, "Schützen des Datenbankservers".

 

Zusammenfassung

Die (COM+)-Sicherheit von Enterprise Services verwendet für die Authentifizierung und Autorisierung der Benutzer die Windows-Sicherheitsmechanismen. Die Autorisierung wird mit COM+-Rollen konfiguriert und gesteuert, die Windows-Gruppen- oder Benutzerkonten enthalten. Der Mehrheit der Bedrohungen im Zusammenhang mit Enterprise Services-Anwendungen und Serviced Components können Sie mit bewährten Kodierungstechniken und geeigneter Katalogkonfiguration entgegen treten.

Der Entwickler sollte die Sicherheitskonfiguration der Serviced Component mit deklarativen Attributen setzen. Mit diesen Attributen wird die Anfangskonfiguration der Anwendung für die Enterprise Services-Registrierung (normalerweise mit Regsvcs.exe) festgelegt.

Jedoch können Sie nicht alle Sicherheitskonfigurationseinstellungen mit Attributen setzen. Die "Ausführen als"-Identität einer Serveranwendung muss von einem Administrator angegeben werden. Außerdem muss der Administrator bei der Bereitstellung die Rollen mit Windows-Gruppen- oder Benutzerkonten füllen.

Verwenden Sie bei der Entwicklung von Serviced Components oder bei der Überprüfung der Sicherheitslösung Ihres Unternehmens die "Prüfliste: Schützen von Enterprise Services" im Abschnitt "Prüflisten" dieses Handbuchs.

 

Weitere Informationen

Weitere Informationen finden Sie in den folgenden Quellen.