Verhindern Sie, dass Datenquellen außerhalb des angegebenen Ordners bereitgestellt werden

7

Bevor ich einfach eine wirklich schreckliche Überprüfungsbeschränkung für die Katalogtabelle aufstelle, wollte ich zuerst einige bessere Ideen einholen.

Ich möchte sicherstellen, dass alle freigegebenen Datenquellen auf unserem Berichtsserver für "/ Data Sources" bereitgestellt werden. Hin und wieder wird ein Fehler fälschlicherweise in einem anderen Verzeichnis bereitgestellt (insbesondere, wenn es sich um einen Bericht handelt, der von SSRS 2000 aktualisiert wurde und bei dem kein anderer Speicherort für die Datenquellenangabe angegeben werden konnte).

Ich kann dem Katalog ( Type != 5 OR ParentID = 'GUID of /Data Sources directory'oder ähnlichem) eine hässliche Prüfbeschränkung auferlegen , wenn es darauf ankommt, aber wenn es eine bessere Option gibt, würde ich das lieber verwenden.

sql-server sql-server-2008 ssrs

— db2
quelle

2

+1 Persönlich habe ich in der Vergangenheit Einschränkungen verwendet und sie scheinen zu funktionieren, aber ich würde gerne sehen, was andere auch getan haben.

— OliverAsmus

4

Warum nicht die Berechtigungen ändern, damit Benutzer keine Datenquellen für etwas anderes als diesen Ordner bereitstellen können?

Entfernen Sie daher "Datenquellen verwalten" aus allen Ordnern mit Ausnahme von /Data Sources. Dies kann auf Stammebene erfolgen und anschließend benutzerdefinierte Berechtigungen festlegen/Data Sources

Möglicherweise müssen Sie hierfür eine benutzerdefinierte Rolle einrichten, wenn Sie die vorhandenen nicht ändern können.

— gbn
quelle

Verwenden Sie das integrierte Sicherheitsmanagement von Reporting Service.

— DForck42

Ah ha, ich vergesse immer, dass ich die Rollen anpassen kann, da Sie dies über SSMS tun und es im Berichts-Manager nicht direkt vor mir liegt. Ich habe "Datenquellen verwalten" aus der Rolle "Inhaltsmanager" entfernt und in eine neue Rolle "Datenquellenmanager" eingefügt. Dann habe ich diese Rolle nur im Datenquellenverzeichnis gewährt. Ich denke, das reicht aus ... ("Ressourcen verwalten" bedeutet nicht "Datenquellen verwalten", oder?)

— db2

@ db2: IIRC, "Ressourcen" sind Bilder und Dinge: keine Berichte und keine Datenquellen und keine Ordner (die ausdrücklich erwähnt werden)

— gbn

1

Ich glaube nicht, dass MS tatsächlich etwas über die zugrunde liegende SSRS-Datenbank garantiert, also betreten Sie nicht unterstütztes Gebiet, indem Sie tatsächlich damit friggen. Im Allgemeinen wird so etwas auf Produktionsservern am besten vermieden.

Sie können Datenquellen und andere Berichtsserver-Metadaten programmgesteuert über eine von SSRS bereitgestellte Webdienst-API abfragen. Mit der API können Sie die Ordner, die nach gemeinsam genutzten Datenquellen suchen, an Orten durchsuchen, an denen sie nicht sein sollen.

Jagd- und Ausnahmemeldungen sind wahrscheinlich der beste Weg, um damit umzugehen, anstatt zu versuchen, sie an der Quelle zu verhindern. Sie können auch die Berichtsmetadaten abfragen, um nach Berichten mit Verweisen auf Quellen außerhalb der angegebenen Bereiche zu suchen. Auf diese Weise können Sie die Autoren aufklären.

MS bietet ein Dienstprogramm namens rs.exe, mit dem Sie Skripts schreiben können, um dies in VB.NET zu tun. Spätere Versionen unterstützen möglicherweise auch C #, aber ich habe dies mit nichts Neuerem als SSRS 2005 getan. Im Wesentlichen wird Ihr Skript mit ein wenig Boilerplate über- und beendet, kompiliert und dann ausgeführt.

Einige Dokumentationen zum rs.exeDienstprogramm und zur SSRS-Webdienst-API finden Sie hier , hier und hier.

— ConcernedOfTunbridgeWells
quelle

1

Keine schlechte Idee, aber ich würde eher einen proaktiven als einen reaktiven Ansatz bevorzugen. Obwohl mir die Idee gefällt, nach Berichten mit fehlerhaften Datenquellenreferenzen zu suchen. Ich muss versuchen, das zu versuchen - ich habe gerade ein paar von Hand aufgeräumt.

— db2

@ db2 Sie könnten einen Job einrichten und jeden Abend ausführen, um diesen abzuholen. Beachten Sie, dass Sie eine Richtlinie erzwingen, keine Invariante mit fest codierten Abhängigkeiten.

— ConcernedOfTunbridgeWells

1

Nur um eine Idee zu veröffentlichen: In unserer Umgebung haben die Berichtsentwickler Zugriff auf die Quellendatenbank, die Berichtsbenutzer jedoch nicht. Alle unsere Datenquellen werden in einem einzigen Ordner bereitgestellt und ein Dienstkonto wird zur Authentifizierung dieser Datenquelle verwendet.

Die Berichtsentwickler kennen das Kennwort des Dienstkontos nicht.

Wenn ein Berichtsentwickler bei dieser Einrichtung eine Datenquelle an einer anderen Stelle bereitstellt, funktioniert der Bericht nicht für Berichtskonsumenten, sondern nur für andere Entwickler. (Technisch gesehen müssen sie immer "Datenquelle nicht überschreiben" verwenden, oder alle Berichte werden durcheinander gebracht, bis der Administrator die "neue" Datenquelle mit dem Dienstkonto ändert.)

Hoffe das hilft!

— JHFB
quelle

1

Das kommt unserem Setup eigentlich sehr nahe. Alle Produktionsdatenquellen verwenden ein vordefiniertes Konto (normalerweise "ReportingServicesData" mit sehr spezifischen schreibgeschützten Berechtigungen), während die Entwicklung mit Windows-Authentifizierung erfolgt. Dies schützt Sie vor Berichten über Trojaner, die von jemandem mit Administratorrechten bereitgestellt und dann ausgeführt werden. (Schlüpfen Sie CREATE LOGIN secret_admin ...in eine Berichtsabfrage und bringen Sie dann jemanden mit Systemadministrator dazu, sie

— auszuführen

Was ist also die Gefahr, wenn eine Datenquelle am falschen Ort bereitgestellt wird? Das heißt, warum muss man proaktiv statt reaktiv sein? Oder ist das nur eine natürliche Neigung zur "Best Practice"? :)

— JHFB

Meistens nur, um zu verhindern, dass der Berichtsserver zu einem schrecklichen Durcheinander wird. Im Laufe der Jahre habe ich eine starke Entropie festgestellt, wenn unser Server nicht aktiviert ist (insbesondere in Bezug auf Verzeichnis- und Berichtsberechtigungen). Die einzige Gefahr in diesem Fall wäre eine verringerte Handhabbarkeit.

— db2