SSRS 2005 Безопасность на основе параметров

Question

Я работаю в компании A. Компания A имеет дочернюю компанию B. Обе компании A и B используют одну и ту же базу данных ERP. Я создал отчет SSRS 2005, который может использоваться обеими компаниями. Он имеет параметр CompanyID, который определяет, следует ли отображать данные для компании A или компании B.

Для большинства отчетов это будет нормально, но для информации, чувствительной к компании (например, платежной ведомости), это будет проблемой, поскольку кто-либо в компании A может изменить параметр CompanyID на идентификатор компании B и наоборот.

Моя первоначальная идея - создать linked repor t для каждой компании в своих соответствующих папках A и B, где безопасность в папке A разрешает только пользователям A и папке B, разрешающим пользователям B. Затем я бы добавил параметр CompanyID по умолчанию для каждого связанного отчета и скрыть параметры от пользователя. Все идет нормально. Проблема заключается в том, что вы все равно можете изменить значения параметров, используя строку запроса URL. Например, пользователь в компании А может изменить отчет URL из:

http://server/ReportServer/ReportViewer.aspx?/Payroll/A & RS: Command = Рендер

к:

http://server/ReportServer/ReportViewer.aspx?/Payroll/A & RS: Command = Рендер & CompanyID = B

Теперь они полностью обошли скрытые дефа ult.

Что такое хороший подход для решения этой проблемы? Я хотел бы поделиться сообщениями между обеими компаниями, если это возможно.

Update: Мы также компания конкретной ASP.NET интранет, которые уже ограничивают доступ на основе компании через домен AD. Я полагаю, что я мог бы использовать элемент управления ReportViewer на странице интрасети, чтобы применить соответствующие параметры во время выполнения. Возможно, я мог бы включить эту логику в общую страницу отчета, которая могла бы использоваться для любого отчета, не так ли? (Пожалуйста, извините мое невежество, я - общая SSRS n00b)

Answer 1

Что здесь для вашей безопасности? Мне кажется, что надежным и безопасным решением будет управлять доступом к данным на основе учетной записи пользователя. Как собираются данные отчета? Является ли он SELECT непосредственно в вашем наборе данных? Вы называете процедуры? выбор против представления?

EDIT: Поскольку вы выбираете против VIEW, который объединяет соответствующие данные компании, если вы предоставляете права на представления пользователям или ролям, у которых есть доступ, вы можете создать сценарий, в котором данные будут возвращены в пользователь на основе своих прав.

Answer 2

Вы можете использовать Expression Based Connection Strings, чтобы не использовать связанные отчеты, но это все равно означает передачу информации в качестве параметра, который будет отображаться в запросе GET.

Нельзя обойти, что вы должны различать, для кого будет отображаться/выполняться отчет.