Sichern von Berichten und Ressourcen

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, müssen 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 eine leistungsstarke Funktion, die 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.

Berichtsparameter und Script-Injection

Berichtsparameter stellen Flexibilität zum Gesamtberichtsentwurf und der Ausführung bereit. Dieselbe Flexibilität kann jedoch in einigen Fällen von einem Angreifer in Lockangriffen verwendet werden. Um das Risiko der versehentlichen Ausführung schädlicher Skripts zu minimieren, sollten gerenderte Berichte nur aus vertrauenswürdigen Quellen geöffnet werden. Sie sollten das folgende Szenario, das ein potenzieller HTML-Renderer-Script-Injection-Angriff ist, berücksichtigen:

1. Ein Bericht enthält ein Textfeld, bei dem die Hyperlinkaktion auf den Wert eines Parameters festgelegt wurde, der böswilligen Text enthalten könnte.

2. Der Bericht wird auf einem Berichtsserver veröffentlicht oder auf eine andere Weise verfügbar gemacht, sodass der Berichtsparameterwert von der URL einer Webseite gesteuert werden kann.

3. Ein Angreifer erstellt einen Link zur Webseite oder zum Berichtsserver, gibt dabei den Wert des Parameters in der Form "javascript angibt:<bösartiges Skript hier>" an und sendet diesen Link in einem Lockangriff an eine andere Person.

Abwehren von Script-Injection-Angriffen in einem Hyperlink in einem veröffentlichten Bericht oder Dokument

Berichte können eingebettete Hyperlinks im Wert der Action-Eigenschaft in einem Berichtselement oder einem Teil eines Berichtselements enthalten. Hyperlinks können an Daten gebunden werden, die aus einer externen Datenquelle abgerufen werden, wenn der Bericht verarbeitet wird. Wenn ein böswilliger Benutzer die zugrunde liegenden Daten ändert, könnte der Hyperlink für Skriptexploits eingesetzt werden. Wenn ein Benutzer im veröffentlichten oder exportierten Bericht auf den Link klickt, könnte bösartiges Skript ausgeführt werden.

Um das Risiko des Einschließen von Links in einem Bericht, der versehentlich bösartige Skripts ausführt, zu verringern, binden Sie Hyperlinks nur an Daten von vertrauenswürdigen Quellen. Stellen Sie sicher, dass Daten von den Abfrageergebnissen und den Ausdrücken, die Daten an Hyperlinks binden, keine Links erstellen, die missbraucht werden können. Verwenden Sie z. B. keinen Link als Grundlage für einen Ausdruck, der Daten aus mehreren Datasetfeldern verkettet. Wechseln Sie ggf. zum Bericht, und suchen Sie nach verdächtigen Skripts und URLs mithilfe von "Quelle anzeigen".

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 eine 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. den bösartigen Link 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.

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 der Anmeldeinformationen und Verbindungsinformationen für Berichtsdatenquellen. Darüber hinaus können Sie einen Ordner für unbefugte Benutzer sperren. Weitere Informationen finden Sie unter Sichern von Ordnern.

Siehe auch

Aufgaben

Konzepte