Udostępnij za pośrednictwem

  • Artykuł

Zabezpieczanie zasobów i raportów

zestaw zabezpieczenia dla poszczególnych raportów i zasobów do kontrolowania stopnia dostęp użytkowników do tych elementów.Domyślnie, tylko użytkownicy, którzy są członkami z Administratorzy wbudowanej grupy można uruchamiać raporty, przeglądać zasoby, modyfikować właściwości i usunąć elementy.Inni użytkownicy muszą mieć utworzone przypisania ról, zezwalające na dostęp do raportu lub zasób.

Na podstawie ról dostęp do raportów i zasobów

Aby udzielić dostępu do zasobów i raportów, można zezwolić użytkownikom na dziedziczą przypisania ról istniejącego folderu nadrzędnego lub utworzyć nowe przypisanie roli na element sobie.

W większości przypadków będzie prawdopodobnie ma uprawnienia, które są dziedziczone po folderze nadrzędnym.Ustawianie zabezpieczeń na poszczególne raporty i zasoby powinny być tylko niezbędne, jeśli chcesz ukryć raportu lub zasób od użytkowników, którzy nie muszą wiedzieć, że istnieje raport lub zasób lub zwiększyć poziom dostępu dla raportu lub element.Cele te nie wzajemnie się wykluczają.Można ograniczyć dostęp do raportu mniejszy zestaw użytkowników i dostarcza dodatkowych uprawnień do zarządzania raportu wszystkie lub niektóre z nich.

Może być konieczne utworzenie wielu przypisań ról, aby osiągnąć swoje cele.Załóżmy na przykład, raport, który chcesz udostępnić użytkownikom dwie pods i Fernando i do grupy Menedżerowie zasobów ludzkich.Pods i Fernando musi być w stanie zarządzać raportu, ale członkowie menedżerów zasobów ludzkich tylko trzeba go uruchomić.Aby uwzględnić wszystkich tych użytkowników, należy utworzyć trzy oddzielne roli przydziały: jeden pods Menedżer zawartości raportu, jeden Fernando Menedżer zawartości raportu i jedną do obsługi tylko do widoku zadań grupy Menedżerowie zasobów ludzkich.

Raz możesz zestaw zabezpieczeń na raport lub zasób, te zestawtings pozostają z elementem, nawet jeśli przenieść element do nowej lokalizacji.Na przykład, jeśli przeniesiesz raport zezwolono niewiele osób dostępu, do raportu nadal będzie dostępna tylko tym użytkownikom, nawet gdy zostaną przeniesione do folderu, który ma zasady zabezpieczeń stosunkowo otwarte.

Łagodzenia HTML iniekcji ataki w raporcie opublikowanym lub dokumentu

W Reporting Services, raporty i zasoby są przetwarzane z tożsamością zabezpieczeń użytkownika, który jest uruchomiony raport.Jeśli raport zawiera wyrażeń, skrypt, elementów raportu niestandardowego lub niestandardowe zestawy, kod jest uruchamiana poświadczenia użytkownika.Jeśli zasób jest dokument HTML, który zawiera skrypt, skrypt zostanie uruchomiony po otwarciu dokumentu serwer raportów.Możliwość uruchamiania skryptów lub kodu w raporcie jest niesłychanie pochodzi z niektórymi poziom ryzyka.W przypadku złośliwego kodu na ataki są serwer raportów i użytkownik, który jest uruchomiony raport.

Przyznania dostępu do raportów i zasoby, które są przetwarzane w formacie HTML, to trzeba pamiętać, że raporty są przetwarzane w pełne zaufanie i że potencjalnie niebezpiecznego skryptu może być wysłany do klient.W zależności od ustawień przeglądarki klient będzie wykonać HTML poziom zaufania, określonego w przeglądarce.

Można załagodzić ryzyko uruchomienia niebezpiecznego skryptu, wykonując następujące środki ostrożności:

  • Być selektywne, podejmując kto publikowanie zawartości serwer raportów.Ponieważ istnieje możliwość publikowania niebezpieczną zawartość, należy ograniczyć użytkowników, którzy publikowanie zawartości niewielką liczbę zaufanych użytkowników.

  • Wszystkich wydawców należy unikać publikowanie raportów i zasobów, które pochodzą z nieznanych lub niezaufanych źródeł.W razie potrzeby otworzyć plik w edytorze tekstów i odszukaj skrypt podejrzanych i adresów URL.

Parametry raportu i uruchomienie skryptu

Parametry raportu zapewniają elastyczność Projekt raportu ogólnego i wykonanie.Jednakże tego samego elastyczność w niektórych przypadkach można przez osobę atakującą w zapewnienia ataków.Aby zmniejszyć ryzyko przypadkowego uruchomienia złośliwe skrypty, Otwórz tylko renderowane sprawozdania z zaufanych źródeł.Zalecane jest, należy rozważyć następujący scenariusz jest potencjalny atak iniekcji skryptu renderowania HTML:

  1. Raport zawiera pole tekstowe z akcją hiperłącza zestaw wartość parametru, który może zawierać złośliwy tekst.

  2. Raport jest opublikowane serwer raportów lub udostępnione w taki sposób, że wartość parametru raportu może być kontrolowane z adresu URL strona sieci web.

  3. Osoba atakująca utworzy łącze do strona sieci web lub serwer raportów określający wartość parametru w formularzu "javascript:<niebezpiecznego skryptu>"" i wysyła zawierające łącze do innej osoby w luring atak.

Ataki łagodzenia uruchomienie skryptu w hiperłączu w raporcie opublikowanym lub dokumentu

Raporty mogą zawierać hiperłącza osadzone w wartości Action Właściwość element element raportu lub część element raportu.Hiperłącza można powiązać dane pobierane z zewnętrznego źródło danych podczas przetwarzania raportu.Jeśli złośliwy użytkownik zmienia dane, hiperłącze może być zagrożony wykonywanie skryptów nadużyciom.Jeśli użytkownik kliknie łącze w raporcie opublikowanym lub wywożonych, może uruchomić niebezpieczny skrypt.

Aby zmniejszyć ryzyko łącza w raporcie przypadkowo uruchamianie złośliwych skryptów, powiązać tylko hiperłącza do danych ze źródeł zaufanych.Weryfikowanie, czy dane z wyniki kwerendy i wyrażenia, które powiązać dane hiperłącza nie twórz łączy, które można wykorzystać.Na przykład nie oprzeć hiperłącze wyrażenie łączy dane z wielu pól dataset.W razie potrzeby przejdź do raportu i użyć "Wyświetl źródło" Aby sprawdzić, czy skrypty podejrzanych i adresów URL.

Ataki ograniczające zagrożenie iniekcją SQL w raporcie sparametryzowana

W dowolnym raporcie, który zawiera parametr typu String, należy użyć listy dostępnych wartości (znany także jako lista prawidłowych wartości) i upewnij się, że każdy użytkownik uruchamiający raport ma tylko uprawnienia wymagane do wyświetlania danych w raporcie.Podczas definiowania parametru typu String, zostanie wyświetlone z polem tekstowym, można wykonać żadnych wartości.Lista dostępnych wartości ogranicza wartości, które można wprowadzić.Jeśli parametr raportu jest powiązany z parametrem zapytania i nie jest używana lista dostępnych wartości, możliwe jest, że użytkownik raportu wpisze w polu tekstowym kod w języku SQL, który potencjalnie może narazić raport oraz serwer na atak polegający na wprowadzeniu kodu SQL.Posiadanie przez użytkownika wystarczających uprawnień do wykonania nowej instrukcji SQL może spowodować powstanie niepożądanych wyników na serwerze.

Jeśli parametr raport nie jest związana z parametr kwerendy i wartości parametrów są uwzględnione w raporcie, jest możliwe raport użytkownikowi wpisywać wartości parametru składni wyrażenie lub adres URL i renderowania raportu do programu Excel lub HTML.Jeśli następnie inny użytkownik wyświetli raport i kliknie zawartość renderowanego parametru, może w niezamierzony sposób wykonać złośliwy skrypt lub łącze.

Aby zmniejszyć ryzyko niezamierzonego uruchamiania złośliwych skryptów, należy otwierać tylko te renderowane raporty, które pochodzą z zaufanych źródeł.

Ostrzeżenie

W poprzednich wersjach dokumentacji przykładem tworzenia dynamicznych kwerendy jako wyrażenie został dołączony.Ten typ kwerendy tworzy lukę do SQL iniekcji ataki i dlatego nie jest zalecane.

Zabezpieczanie poufne raporty

Raporty zawierające informacje poufne mają być zabezpieczone poziom dostępu do danych, wymagając od użytkowników podać poświadczenia dostępu do dane poufne.Aby uzyskać więcej informacji, zobacz Określanie poświadczeń i informacji o połączeniu dla źródeł danych raportu (SSRS).Można również zabezpieczyć folder, aby stał się niedostępny nieautoryzowanych użytkowników.Aby uzyskać więcej informacji, zobacz Zabezpieczanie folderów.