Sichern von Berichten und Ressourcen

Aktualisiert: 14. April 2006

Die Sicherheit kann für einzelne Berichte und Ressourcen festgelegt werden, um die Zugriffsebene der Benutzer für diese Objekte zu steuern. In der Standardeinstellung können nur Benutzer, die Mitglieder der integrierten Gruppe Administratoren sind, Berichte ausführen, Ressourcen anzeigen, Eigenschaften ändern und Elemente löschen. Für alle anderen Benutzer müssen Rollenzuweisungen erstellt werden, die den Zugriff auf einen Bericht oder eine Ressource zulassen.

Rollenbasierter Zugriff auf Berichte und Ressourcen

Wenn Sie den Zugriff auf Berichte und Ressourcen gewähren möchten, können Sie es den Benutzern ermöglichen, vorhandene Rollenzuweisungen von einem übergeordneten Ordner zu erben oder selbst eine neue Rollenzuweisung für das Element zu erstellen.

In den meisten Fällen möchten Sie wahrscheinlich die Berechtigungen verwenden, die von einem übergeordneten Ordner geerbt werden. Das Festlegen der Sicherheit für einzelne Berichte und Ressourcen ist normalerweise nur dann erforderlich, wenn Sie den Bericht oder die Ressource für die Benutzer ausblenden möchten, die nicht über das Vorhandensein des Berichts oder der Ressource informiert sein müssen, oder wenn Sie die Zugriffsstufe für einen Bericht oder ein Element erhöhen möchten. Diese Zielsetzungen schließen sich nicht gegenseitig aus. Sie können den Zugriff auf einen Bericht auf eine kleinere Benutzergruppe beschränken und allen oder einigen Benutzern zusätzliche Privilegien zur Verwaltung des Berichts gewähren.

Möglicherweise müssen Sie zu diesem Zweck mehrere Rollenzuweisungen erstellen. Angenommen, Sie möchten den Benutzern Anna und Fernando sowie der Gruppe der leitenden Mitarbeiter der Personalabteilung einen Bericht zur Verfügung stellen. Anna und Fernando müssen den Bericht verwalten können; die leitenden Mitarbeiter der Personalabteilung müssen ihn jedoch nur ausführen können. Um alle diese Benutzer zu berücksichtigen, würden Sie drei separate Rollenzuweisungen erstellen: je eine Rollenzuweisung, um Anna bzw. Fernando als Inhalts-Manager des Berichts festzulegen, sowie eine Rollenzuweisung, die ausschließlich Anzeigeaufgaben für die Gruppe der leitenden Mitarbeiter der Personalabteilung unterstützt.

Die Sicherheitseinstellungen eines Berichts oder einer Ressource bleiben dem Element zugeordnet, selbst wenn Sie es an einen neuen Speicherort verschieben. Wenn Sie z. B. einen Bericht verschieben, auf den nur ein paar wenige Personen Zugriff haben, ist dieser Bericht auch weiterhin nur für diese Benutzer verfügbar, auch wenn Sie ihn in einen Ordner mit einer relativ offenen Sicherheitsrichtlinie verschieben.

Verhindern von HTML-Injection-Angriffen in einem veröffentlichten Bericht oder Dokument

In Reporting Services werden Berichte und Ressourcen unter der Sicherheitsidentität des Benutzers verarbeitet, der den Bericht aktuell ausführt. Wenn der Bericht Ausdrücke, Skripts, benutzerdefinierte Berichtselemente oder benutzerdefinierte Assemblys enthält, wird der Code mit den Anmeldeinformationen des Benutzers ausgeführt. Wenn eine Ressource ein HTML-Dokument darstellt, das Skript enthält, wird das Skript ausgeführt, wenn der Benutzer das Dokument auf dem Berichtsserver öffnet. Die Möglichkeit, Skript oder Code in einem Bericht auszuführen, ist ein leistungsstarkes Feature, das ein gewisses Risiko mit sich bringt. Wenn der Code bösartig ist, sind der Berichtsserver und der den Bericht ausführende Benutzer potenziellen Angriffen ausgesetzt.

Wenn der Zugriff auf Berichte und Ressourcen gewährt wird, die als HTML verarbeitet werden, sollte unbedingt bedacht werden, dass die Berichte mit voller Vertrauenswürdigkeit verarbeitet werden und dass potenziell bösartige Skripts möglicherweise an den Client gesendet werden. In Abhängigkeit von den Browsereinstellungen führt der Client den HTML-Code auf der Vertrauensebene aus, die im Browser angegeben ist.

Sie können das Risiko, bösartige Skripts auszuführen, reduzieren. Treffen Sie dazu die folgenden Vorkehrungen:

• Überlegen Sie sich genau, wem Sie die Möglichkeit geben, Inhalte auf einem Berichtsserver zu veröffentlichen. Da das Potenzial der Veröffentlichung von bösartigen Inhalten besteht, sollten Sie die Gruppe der Personen, die Inhalte veröffentlichen können, auf eine kleine Anzahl vertrauenswürdiger Benutzer begrenzen.
• Alle Verleger sollten es vermeiden, Berichte und Ressourcen zu veröffentlichen, die aus unbekannten oder nicht vertrauenswürdigen Quellen stammen. Öffnen Sie die Datei gegebenenfalls in einem Text-Editor, und prüfen Sie sie auf verdächtige Skripts und URLs.

Verhindern von SQL-Injection-Angriffen in einem parametrisierten Bericht

Verwenden Sie in einem Bericht, der einen Parameter vom Typ String enthält, eine Liste der verfügbaren Werte (wird auch als Liste der gültigen Werte bezeichnet), und stellen Sie sicher, dass Benutzer, die den Bericht ausführen, nur über die Berechtigungen verfügen, die zum Anzeigen der Daten im Bericht erforderlich sind. Wenn Sie einen Parameter vom Typ String definieren, wird für den Benutzer ein Textfeld bereitgestellt, das jeden beliebigen Wert annehmen kann. Mit einer Liste der verfügbaren Werte werden die Werte eingeschränkt, die eingegeben werden können. Wenn der Berichtsparameter an einen Abfrageparameter gebunden ist und Sie keine Liste mit verfügbaren Werten verwenden, kann ein Benutzer des Berichts SQL-Syntax in das Textfeld eingeben. Damit öffnet er den Bericht und Ihren Server potenziell für einen SQL-Injection-Angriff. Wenn der Benutzer über Berechtigungen zum Ausführen der neuen SQL-Anweisung verfügt, können daraus unerwünschte Ergebnisse auf dem Server resultieren.

Wenn ein Berichtsparameter nicht an einen Abfrageparameter gebunden ist und die Parameterwerte im Bericht enthalten sind, können die Benutzer des Berichts Ausdruckssyntax oder einen URL in den Parameterwert eingeben und den Bericht für Excel oder HTML rendern. Wenn anschließend ein anderer Benutzer den Bericht anzeigt und auf die gerenderten Parameterinhalte klickt, führt der Benutzer möglicherweise unbeabsichtigt das bösartige Skript bzw. die bösartige Verknüpfung aus.

Wenn Sie das Risiko des unbeabsichtigten Ausführens von böswilligen Skripts minimieren möchten, öffnen Sie gerenderte Berichte nur über vertrauenswürdige Quellen.

Weitere Informationen zu SQL-Injection-Angriffen und deren Verhinderung finden Sie unter Integrierte Sicherheit und erhöhte Berechtigungen.

Hinweis:
In früheren Versionen der Dokumentation war ein Beispiel zum Erstellen einer dynamischen Abfrage als Ausdruck enthalten. Durch diese Art der Abfrage entsteht eine Angriffsfläche für SQL-Injection-Angriffe; daher wird dies nicht empfohlen.

Sichern vertraulicher Berichte

Berichte mit vertraulichen Informationen sollten auf der Datenzugriffsebene geschützt werden. Benutzer müssen in diesem Fall Anmeldeinformationen angeben, um auf die vertraulichen Daten zugreifen zu können. Weitere Informationen finden Sie unter Angeben von Anmelde- und Verbindungsinformationen. Darüber hinaus können Sie einen Ordner für unbefugte Benutzer sperren. Weitere Informationen finden Sie unter Sichern von Ordnern.

Siehe auch

Aufgaben

Vorgehensweise: Angeben gespeicherter Anmeldeinformationen für eine Datenquelle (Management Studio)

Konzepte

Integrierte Sicherheit und erhöhte Berechtigungen
Erstellen, Ändern und Löschen von Rollenzuweisungen
Verleger-Rolle
Rollenzuweisungen für den Zugriff auf den Berichts-Generator
Verwalten von Berechtigungen und Sicherheit für Reporting Services
Sichern freigegebener Datenquellenelemente

Andere Ressourcen

Verwenden von Parametern in Reporting Services

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf

Version	Verlauf
14. April 2006	Neuer Inhalt: Verhindern von SQL-Injection-Angriffen Verhindern von HTML-Injection-Angriffen