Sichere Berichte und Ressourcen
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 die 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 sollte nur in einigen Szenarien erforderlich sein. Dabei handelt es sich um folgende Szenarien:
- Wenn Sie den Bericht oder die Ressource für Benutzer ausblenden möchten, die nicht wissen müssen, dass es den Bericht oder die Ressource gibt
- Zum Erhöhen der Zugriffsebene für einen Bericht oder ein Element.
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 weitere 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. Das kann auch dann der Fall sein, 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 Serviceswerden 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 wenige vertrauenswürdige 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:
Ein Bericht enthält ein Textfeld, bei dem die Linkaktion auf den Wert eines Parameters festgelegt wurde, der böswilligen Text enthalten könnte.
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.
Ein Angreifer erstellt einen Link zur Webseite oder zum Berichtsserver. Dieser Link gibt den Wert des Parameters im Formular
javascript:<malicious script here>an und sendet diesen Link in Form eines Lockangriffs an eine andere Person.
Abwehren von Script-Injection-Angriffen in einem Link in einem veröffentlichten Bericht oder Dokument
Berichte können eingebettete Links im Wert der Action-Eigenschaft in einem Berichtselement oder einem Teil eines Berichtselements enthalten. Links 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 Link für Skriptexploits eingesetzt werden. Wenn ein Benutzer im veröffentlichten oder exportierten Bericht den Link auswählt, 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 Links nur an Daten von vertrauenswürdigen Quellen. Stellen Sie sicher, dass Daten von den Abfrageergebnissen und den Ausdrücken, die Daten an Links 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 Stringenthä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(Zeichenfolge) 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 Sie den Berichtsparameter an einen Abfrageparameter binden und keine Liste mit verfügbaren Werten verwenden, kann ein Benutzer des Berichts SQL-Syntax in das Textfeld eingeben. Dadurch könnten der Bericht und Ihr Server potenziell offen werden 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.
Ein Berichtsparameter ist eventuell nicht an einen Abfrageparameter gebunden, und die Parameterwerte sind im Bericht enthalten. Wenn dies der Fall ist, kann ein Benutzer des Berichts Ausdruckssyntax oder eine URL in den Parameterwert eingeben und den Bericht für Excel oder HTML rendern. Wenn anschließend ein*e andere*r Benutzer*in den Bericht anzeigt und die gerenderten Parameterinhalte auswählt, führt der*die Benutzer*in möglicherweise unbeabsichtigt das bösartige Skript bzw. den bösartigen Link aus.
Um das Risiko der versehentlichen Ausführung schädlicher Skripts zu minimieren, sollten gerenderte Berichte nur aus vertrauenswürdigen Quellen geöffnet werden.
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 Sichere Ordner.