Sichern von RDS-Anwendungen

Gilt für: Access 2013, Office 2013

Sicherheitsaspekte zu Microsoft Internet Explorer

Da Microsoft Internet Explorer neue Sicherheitsverbesserungen hinzugefügt wurden, sind einige ADO- und RDS-Objekte auf die Ausführung nur in einer Umgebung im sicheren Modus beschränkt. Dies erfordert, dass Sie sich dieser Probleme bewusst sind, einschließlich verschiedener Zonen, Sicherheitsstufen, restriktivem Verhalten, unsicheren Vorgängen und angepassten Sicherheitseinstellungen.

Weitere Informationen zu diesen Aspekten finden Sie unter den entsprechenden ADO- und RDS-Sicherheitsthemen zu Microsoft Internet Explorer in den technischen Artikeln zu ActiveX Data Objects (ADO).

Sicherheit und Ihr Webserver

Wenn Sie das RDSServer.DataFactory-Objekt auf Ihrem Internetwebserver verwenden, denken Sie daran, dass dadurch ein potenzielles Sicherheitsrisiko entsteht. External users who obtain valid data source name (DSN), user ID, and password information could write pages to send any query to that data source. If you want more restricted access to a data source, one option is to unregister and delete the RDSServer.DataFactory object (msadcf.dll), and instead use custom business objects with hard-coded queries.

Weitere Informationen zu den Sicherheitsauswirkungen der Verwendung des RDSServer.DataFactory-Objekts finden Sie im Microsoft Security Bulletin MS99-025 auf der Microsoft Security-Website.

Sicherheit beim Clientidentitätswechsel

Wenn die Kennwortauthentifizierungseigenschaft für Ihren IIS-Webserver auf Windows NT Challenge/Response-Authentifizierung (für Windows NT 4.0) oder integrierte Windows-Authentifizierung (für Windows 2000) festgelegt ist, werden Geschäftsobjekte unter dem Sicherheitskontext des Clients aufgerufen. Das ist ein neues Feature in RDS 1.5, das den Clientidentitätswechsel über HTTP zulässt. Wenn Sie in diesem Modus arbeiten, ist die Anmeldung beim Webserver (IIS) nicht anonym, sondern verwendet die Benutzer-ID und das Kennwort, unter denen der Clientcomputer ausgeführt wird. Wenn die ODBC-Datenquellennamen für die Verwendung der vertrauenswürdigen Verbindung eingerichtet sind, erfolgt der Zugriff auf Datenbanken (z. B. SQL Server) ebenfalls unter dem Sicherheitskontext des Clients. Das funktioniert jedoch nur, wenn sich die Datenbank auf demselben Computer wie IIS befindet, denn die Anmeldeinformationen des Clients können nicht auf einen weiteren Computer übertragen werden.

Beispielsweise wird ein Client, John Doe, mit userid="JohnD" und password="secret" auf einem Clientcomputer angemeldet. Er führt eine browserbasierte Anwendung aus, die auf das RDSServer.DataFactory-Objekt zugreifen muss, um ein Recordset zu erstellen, indem eine SQL-Abfrage auf dem Computer "MyServer" ausgeführt wird, auf dem IIS ausgeführt wird. MyServer, ein System unter Windows NT Server 4.0, ist für die Verwendung der Windows NT-Authentifizierung "Challenge/Response" eingerichtet, für den ODBC-DSN ist "Vertrauenswürdige Verbindung verwenden" ausgewählt, und der Server enthält auch die SQL Server Datenquelle. Wenn eine Anforderung auf dem Webserver empfangen wird, wird der Client zur Eingabe der Benutzer-ID und des Kennworts aufgefordert. Daher wird die Anforderung auf MyServer als von "JohnD"/"Secret" anstelle von IUSER_MyServer (dies ist die Standardeinstellung, wenn die anonyme Kennwortauthentifizierung aktiviert ist) protokolliert. Ebenso wird bei der Anmeldung bei SQL Server "JohnD"/"Secret" verwendet.

Folglich lässt der IIS-Abfrage/Rückmeldung-Authentifizierungsmodus von Windows NT das Erstellen von HTML-Seiten zu, ohne dass Benutzer ausdrücklich nach der für die Anmeldung an der Datenbank erforderlichen Benutzer-ID und dem Kennwort gefragt werden. Bei Verwendung der IIS-Standardauthentifizierung wäre dies ebenfalls erforderlich.

Kennwortauthentifizierung

RDS kann mit einem IIS-Webserver kommunizieren, der in einem der drei Kennwortauthentifizierungsmodi ausgeführt wird: Anonym, Basic oder NT Challenge/Response-Authentifizierung (unter Windows 2000 als integrierte Windows-Authentifizierung bezeichnet). Diese Einstellungen definieren, wie ein Webserver den Zugriff über ihn steuert, z. B. die Anforderung, dass ein Clientcomputer über explizite Zugriffsberechtigungen auf dem NT-Webserver verfügt.