Zabezpečené zprávy a zdroje

Important

Hlášení není bezpečnostní hranice. Udělení uživateli přístupu k reportu může také odhalit data ze zdroje dat reportu nad rámec toho, co je ve zprávě uvedeno. Vynuťte přístup k datům u zdroje dat – například použitím zabezpečení na úrovni řádku nebo objektu na modelu Analysis Services nebo oprávnění databáze u relačního zdroje – nikoli skrýváním položek reportu. Kontroly na úrovni reportu, jako jsou oprávnění k složkám, přiřazení rolí a skryté parametry, řídí přístup k reportu, nikoli k datům , která může vrátit.

Můžete nastavit bezpečnost pro jednotlivé reporty a zdroje, abyste mohli kontrolovat míru přístupu uživatelů k těmto položkám. Ve výchozím nastavení mohou spouštět reporty, zobrazovat zdroje, upravovat vlastnosti a mazat položky pouze uživatelé, kteří jsou členy vestavěné skupiny Administrátorů . Všichni ostatní uživatelé musí mít přiřazená role vytvořená pro sebe, která jim umožní přístup k reportu nebo zdroji.

Přístup k reportům a zdrojům založený na rolích

Pro udělení přístupu k reportům a zdrojům můžete uživatelům umožnit dědit stávající přiřazení rolí z nadřazené složky nebo vytvořit nové přiřazení role přímo na položce.

Ve většině případů pravděpodobně chcete použít oprávnění zděděná z nadřazené složky. Nastavení bezpečnosti jednotlivých reportů a zdrojů by mělo být nutné jen v několika situacích. Tyto scénáře jsou:

  • Pokud chcete skrýt zprávu nebo zdroj před uživateli, kteří nemusí vědět, že report nebo zdroj existuje
  • Zvýšit úroveň přístupu k reportu nebo položce.

Tyto cíle se navzájem nevylučují. Můžete omezit přístup k reportu na menší skupinu uživatelů a všem nebo některým z nich poskytnout další práva pro správu reportu.

Možná budete muset vytvořit více rolí, abyste dosáhli svých cílů. Například si představte, že máte report, který chcete zpřístupnit dvěma uživatelům, Ann a Fernando, a skupině manažerů lidských zdrojů. Ann a Fernando musí být schopni zprávu spravovat, ale členové HR manažerů ji musí pouze spustit. Aby se vyhovělo všem těmto uživatelům, vytvořili byste tři samostatné přiřazení rolí: jednu, která udělá z Ann manažerku obsahu reportu, jednu, aby Fernando byl správcem obsahu, a jednu pro podporu úloh pouze pro zobrazení pro skupinu manažerů lidských zdrojů.

Jakmile nastavíte zabezpečení na reportu nebo zdroji, tato nastavení zůstanou u položky i když ji přesunete na nové místo. Například pokud přesunete zprávu, ke které má oprávnění přistupovat jen několik lidí, zpráva zůstane dostupná pouze těmto uživatelům. Tento výsledek může nastat i v případě, že ho přesunete do složky s relativně otevřenou bezpečnostní politikou.

Zmírnění útoků na injekci HTML v publikované zprávě nebo dokumentu

V Reporting Services jsou zprávy a zdroje zpracovávány pod bezpečnostní identitou uživatele, který zprávu spravuje. Pokud report obsahuje výrazy, skripty, vlastní položky reportu nebo vlastní assemblery, kód běží pod uživatelovými přihlašovacími údaje. Pokud je zdroj HTML dokument obsahující skript, skript se spustí při otevření dokumentu uživatelem na serveru reportů. Možnost spouštět skripty nebo kód v rámci reportu je silná funkce, která s sebou nese určitou míru rizika. Pokud je kód škodlivý, server pro reporty a uživatel, který report spouští, jsou zranitelní vůči útokům.

Při udělování přístupu k reportům a zdrojům, které jsou zpracovávány jako HTML, je důležité si uvědomit, že reporty jsou zpracovávány s plnou důvěrou a že potenciálně škodlivý skript může být zaslán klientovi. V závislosti na nastavení prohlížeče klient vykonává HTML na úrovni důvěry, která je specifikována v prohlížeči.

Riziko spuštění škodlivých skriptů můžete snížit dodržováním následujících opatření:

  • Buďte selektivní při rozhodování, kdo může publikovat obsah na reportový server. Protože existuje možnost zveřejňování škodlivého obsahu, měli byste omezit uživatele, kteří mohou obsah publikovat, na několik důvěryhodných uživatelů.

  • Všichni vydavatelé by se měli vyhýbat publikování zpráv a zdrojů, které pocházejí z neznámých nebo nedůvěryhodných zdrojů. Pokud je to nutné, otevřete soubor v textovém editoru a hledejte podezřelé skripty a URL.

Parametry hlášení a skriptové vstřikování

Parametry reportu poskytují flexibilitu pro celkový návrh a realizaci reportu. Tuto stejnou flexibilitu však může v některých případech útočník využít při návnadových útocích. Aby se snížilo riziko nechtěného spuštění škodlivých skriptů, otevírejte pouze vykreslované zprávy z důvěryhodných zdrojů. Měli byste zvážit následující scénář, který je možným útokem na injekční skripty HTML Rendereru:

  1. Zpráva obsahuje textové pole s hypertextovou akcí nastavenou na hodnotu parametru, který může obsahovat škodlivý text.

  2. Zpráva je publikována na serveru pro zprávy nebo jinak zpřístupněna tak, aby hodnota parametru zprávy mohla být ovládána z URL webové stránky.

  3. Útočník vytvoří odkaz na webovou stránku nebo server pro reporty. Tento odkaz specifikuje hodnotu parametru ve formuláři javascript:<malicious script here> a odesílá tento odkaz někomu jinému v rámci návnadového útoku.

Reporty mohou obsahovat vložené hypertextové odkazy v hodnotě vlastnosti Akce na reportové položce nebo části reportové položky. Hypertextové odkazy lze navázat na data, která jsou získána z externího datového zdroje při zpracování zprávy. Pokud škodlivý uživatel upraví základní data, může být hypertextový odkaz ohrožen skriptováním. Pokud uživatel vybere odkaz v publikované nebo exportované zprávě, může se spustit škodlivý skript.

Aby se minimalizovalo riziko zahrnutí odkazů do zprávy, která neúmyslně spustí škodlivé skripty, vážejte hypertextové odkazy pouze na data z důvěryhodných zdrojů. Ověřte, že data z výsledků dotazu a výrazy, které data vážou k hypertextovým odkazům, nevytvářejí odkazy, které lze zneužít. Například nestavte hypertextový odkaz na výrazu, který spojuje data z více polí datové sady. Pokud je to nutné, přejděte do hlášení a použijte "Zobrazit zdroj" pro kontrolu podezřelých skriptů a URL.

Zmírnění útoků na injekci SQL v parametrizovaném reportu

V každé zprávě, která obsahuje parametr typu String, se ujistěte, že používáte seznam dostupných hodnot (také známý jako seznam platných hodnot) a ujistěte se, že každý uživatel spouštějící zprávu má pouze oprávnění potřebná k zobrazení dat v reportu. Když definujete parametr typu String, zobrazí se uživateli textové pole, které může převzít libovolnou hodnotu. Seznam dostupných hodnot omezuje hodnoty, které lze zadat. Pokud spojíte parametr reportu s parametrem dotazu a nepoužijete seznam dostupných hodnot, je možné, že uživatel reportu zadá SQL syntaxi do textového pole. Tato akce by mohla vystavit sestavu i váš server útoku typu SQL injection. Pokud má uživatel dostatečná oprávnění k vykonání nového SQL příkazu, může to na serveru způsobit nežádoucí výsledky.

Parametr reportu nemusí být vázán na dotazovací parametr a hodnoty parametrů jsou zahrnuty v reportu. Pokud je to tak, je možné, aby uživatel reportu zadal expression syntax nebo URL do hodnoty parametru a vykreslil report do Excelu nebo HTML. Pokud si sestavu zobrazí jiný uživatel a vybere obsah vykresleného parametru, může uživatel neúmyslně spustit škodlivý skript nebo odkaz.

Pokud chcete zmírnit riziko neúmyslného spouštění škodlivých skriptů, otevřete vykreslované sestavy pouze z důvěryhodných zdrojů.

Note

V předchozích verzích dokumentace byl zahrnut příklad vytvoření dynamického dotazu jako výrazu. Tento typ dotazu vytváří zranitelnost vůči SQL injection útokům, a proto se nedoporučuje.

Zajištění důvěrných zpráv

Zprávy obsahující důvěrné informace by měly být zabezpečeny na úrovni přístupu k datům, přičemž uživatelé musí poskytnout přihlašovací údaje pro přístup k citlivým údajům. Další informace naleznete v tématu Zadání přihlašovacích údajů a informací o připojení pro zdroje dat sestavy. Můžete také zajistit složku, aby byla nepřístupná neoprávněným uživatelům. Pro více informací viz Zabezpečené složky.

Související obsah

  • Poslední aktualizace v