Sicherheit beim Remoting

Im Allgemeinen werfen Anwendungen, die .NET Framework Remoting verwenden, komplexere Sicherheitsprobleme auf als lokale Anwendungen.

Das Sichern von verteilten Anwendungen stellt ein Problem dar, das ohne die Leistung beeinträchtigende Maßnahmen kaum zu lösen ist. Wenn ein Ende einer Verbindung auf einen Aufruf überwacht wird, kann jeder nicht autorisierte Client, dem dieser überwachende Endpunkt bekannt ist, serialisierte Informationen übergeben, sodass die Informationen am anderen Endpunkt deserialisiert und aufgerufen werden können. Nur über eine gegenseitige Authentifizierung und anschließende Verschlüsselung der Inhalte können Sie einigermaßen sichergehen, dass die Kommunikation zwischen vertrauenswürdigen Komponenten stattfindet. Demzufolge sollten sie zuerst die Sicherheitsanforderungen Ihrer Remoteanwendungen auswerten, bevor Sie die Leistungsanforderungen auswerten. Sie sollten Daten und Endpunkte in dem Umfang ohne Authentifizierung und unverschlüsselt verfügbar machen, wie Sie es für die Datenintegrität Ihrer Anwendung für nötig halten.

Das Remoting von Delegaten veranschaulicht das Problem. Da Delegaten die Typinformationen statischer Methoden (die nie remote ausgeführt werden) umfassen können, müssen die Serveranwendungen immer einen benutzerdefinierten Delegattyp deklarieren, der benutzerdefinierte Parameter annimmt, die zusammen nie einer auf dem Servercomputer aufrufbaren statischen Methode entsprechen. Schließen Sie aus, dass ein Client einen Typ definiert und an die Anwendung übergibt, der auf dem Server deserialisiert werden kann.

Beim Entwerfen sicherer verteilter Anwendungen, die die .NET Framework Remoting-Infrastruktur verwenden, sollten Sie überlegen, welches Maß an Sicherheit Sie anstreben und wo diese Sicherheit greifen soll. In diesem Abschnitt werden verschiedene Ansätze für eine auf bestimmten Entwurfsentscheidungen basierende Sicherheit beleuchtet. Obwohl nicht alle denkbaren Szenarios besprochen werden, bieten diese Themen eine guten Ausgangspunkt für die Entscheidungsfindung.

Codezugriffssicherheit

Über die Codezugriffssicherheit wird gesteuert, welchen Zugriff ausführbarer Code entsprechend der vom Administrator des betreffenden Computers festgelegten Sicherheitsrichtlinie auf Ressourcen und Vorgänge hat. Da jedoch die Codezugriffssicherheit keinen Stackwalk über eine Remoteverbindung ausführt, müssen sich Entwickler von Remotinganwendung stets bewusst sein, dass in einer Remoteinfrastruktur für die Ausführung auf dem Client und auf dem Server volle Vertrauenswürdigkeit erforderlich ist. Eine nicht autorisierte Verwendung einer Remoteanwendung bietet nicht autorisierten Zugriff für die Berechtigung FullTrust.

Warnung

Versuchen Sie nie, einen remotefähigen Wrapper für ein AppDomain-Objekt zu erstellen. Andernfalls kann ein solcher Verweis auf AppDomain u. U. remote veröffentlicht werden. Dadurch wird die AppDomain.CreateInstance-Methode (oder andere Methoden) remote verfügbar gemacht, wodurch die Codezugriffssicherheit für AppDomain faktisch aufgehoben wird. Nicht autorisierte Clients, die remote eine Verbindung mit AppDomain herstellen, sind u. U. in der Lage, auf Ressourcen zuzugreifen, auf die auch AppDomain selbst zugreifen kann. Im Grunde sollten Sie für keinen Typ einen remotefähigen Wrapper erstellen, der MarshalByRefObject erweitert und Methoden implementiert, mit denen nicht autorisierte Clients das Sicherheitssystem umgehen könnten.

Hinweis

Einige Systemtypen erweitern zwar MarshalByRefObject, führen jedoch Sicherheitsüberprüfungen zur Laufzeit aus, um tatsächliche Remoteaufrufe eines Objekt des MarshalByRefObject-Typs von außerhalb der Anwendungsdomäne zu verhindern. AppDomain und System.Windows.Forms.Form sind zwei Beispiele für solche Systemtypen. Obwohl es scheinbar möglich sein sollte, MarshalByRefObject zu erweitern und einen entsprechenden Verweis remote abzurufen, ist dies bei diesen besonderen Typen nicht der Fall. Möglicherweise möchten Sie den prozessinternen Verweis in einem anderen remotefähigen Typ einschließen, jedoch wird dadurch unbeabsichtigt die Codezugriffssicherheit umgangen. Die sollte in jedem Fall vermieden werden.

Überlegungen zur Sicherheit von Remotinganwendungen

Grundsätzlich gibt es zwei Sicherheitsbereiche, auf die Sie je nach Szenario in einer verteilten Anwendung das Augenmerk richten sollten. Sie können den Kommunikationschannel und die Nachricht selbst sichern oder die Anwendung vor unbefugter Verwendung schützen. Bis zu einem gewissen Grad ist auch eine Kombination aus beidem möglich.

In der Regel bedeutet Sichern des Kommunikationschannels das Verschlüsseln des Channels selbst, das Verschlüsseln des Nachrichteninhalts auf der einen Seite des Streams und das Entschlüsseln auf der anderen Seite oder beides. Für den Inhalt der Nachricht kann eine Integritätsprüfung erforderlich sein, um zu ermitteln, ob die Nachricht manipuliert wurde. Möglicherweise muss auch die Identität des Clients und/oder des Servers bestätigt werden.

Zuerst sollten Sie immer Clients authentifizieren, um zu bestätigen, dass sie zur Verwendung der Ressource berechtigt sind. Als zweites sollten Sie die gesamte Verbindung verschlüsseln, um die Daten während der Übertragung zu schützen. Beide Schritte werden sowohl von HttpChannel als auch von TcpChannel unterstützt. (Da der IPC-Channel nur auf ein und demselben Computer funktioniert, wird keine Verschlüsselung, sondern eine Windows-Authentifizierung unterstützt.)

Es gibt Szenarios, die eine Ausnahme von diesen beiden Regeln bilden. Eine Verschlüsselung könnte entfernt werden, fall die Leistungsanforderungen hoch genug und der Wert der Daten gering ist, sodass die Beobachtung oder Änderung der Daten relativ unwichtig wird. Eine Verschlüsselung kann außerdem deaktiviert werden, sobald eine Kommunikation auf einem verschlüsselten Netzwerk stattfindet, wie z. B. ein Netzwerk, das über IPsec gesichert ist.

Sie können die Anwendung auch dahingehend vor unerlaubter Verwendung schützen, indem Sie das Verhalten des Benutzers protokollieren, um die Verwendungsmuster später zu rekonstruieren.

Warnung

.NET Framework Remoting führt standardmäßig keine Authentifizierung oder Verschlüsselung aus. Daher empfiehlt es sich, alle erforderlichen Schritte auszuführen, um die Identität von Clients und Servern vor der Remoteinteraktion eindeutig zu bestimmen. Da für die Ausführung von .NET Framework Remoting-Anwendungen die Berechtigung FullTrust erforderlich ist, könnte ein nicht autorisierter Client, dem der Zugriff auf den Server gewährt wurde, Code so ausführen, als ob er vollständig vertrauenswürdig wäre. Authentifizieren Sie immer Ihre Endpunkte, und verschlüsseln Sie die Kommunikationsstreams. Hierfür können Sie entweder die Remotetypen in Internetinformationsdienste (Internet Information Services, IIS) hosten oder für diese Aufgabe ein benutzerdefiniertes Channelempfängerpaar erstellen. In .NET Framework, Version 2.0, müssen Sie keinen benutzerdefinierten Empfänger zur Sicherung der Kommunikation erstellen. Über die Authentifizierungs- und Verschlüsselungsfeatures (die durch Einstellen von secure = true für den TCP-Channel aktiviert werden) wird eine sichere Kommunikation ermöglicht. Über den TCP-Channel können Sie jetzt den verbundenen Benutzer authentifizieren, Daten verschlüsseln und die Identität sowie die IP-Adresse eines verbundenen Client ermitteln.

Siehe auch

Referenz

RemotingConfiguration
ChannelServices
Context
MethodCall
RemotingServices

Konzepte

Authentifizierung mit dem HTTP-Channel

Weitere Ressourcen

Übersicht über .NET Framework Remoting
Rollenbasierte Sicherheit
Codezugriffssicherheit