Безопасность веб-службы SSRS

Question

У меня есть веб-приложение ASP.NET, которое использует вызовы веб-служб SSRS ReportService2005.asmx и ReportExecution2005.asmx.

Используется технология ASP.NET 3.5, Visual Studio 2008 и SQL Server 2008 R2 (я использую ReportService2005, поскольку использую библиотеку кода, которая использует это, а не ReportService2010)

Пользователь входит в систему, используя проверку подлинности с помощью форм. Затем пользователь переходит на страницу отчетности. Пользователь может принадлежать к любому количеству групп отчетов (каждая группа может содержать любое количество отчетов). Группы отчетов, связанные с ними отчеты и пользователи, назначенные группам отчетов, управляются страницей в веб-приложении и хранятся в виде ряда таблиц в базе данных веб-приложения (НЕ в базе данных SSRS).

В настоящее время доступ к ReportService2005.asmx и ReportExecution2005.asmx осуществляется с использованием учетных данных по умолчанию для сервера. Это безопасно? Все отчеты на сервере будут доступны через эти учетные данные по умолчанию. Единственное ограничение на отчеты, которые может видеть пользователь, будет применено приложением внешнего интерфейса, которое предположительно может быть взломано с помощью, например, Javascript?

Мне нужен метод, позволяющий покончить с серией таблиц отчетов / пользователей / групп в базе данных веб-приложения и использовать схему SSRS. Например:

Пользователь A (сотрудник компании A) принадлежит к группе финансовых отчетов и группе маркетинговых отчетов. Финансовая группа содержит Финансовый отчет 1 и Финансовый отчет 2. Маркетинговая группа содержит Маркетинговый отчет 1.

Вышеуказанные отчеты будут помещаться в папки «Финансы» и «Маркетинг» на сервере отчетов (с помощью диспетчера отчетов).

Затем я мог бы создать пользователя Windows (назовем его MarketingFinance) на сервере отчетов и дать этому пользователю соответствующие разрешения для папок Marketing и Finance. В этом случае пользователь А должен будет иметь своего рода флаг в своем профиле .net membershipprovider для связи с пользователем MarketingFinance.

Однако проблема заключается в том, что я предполагаю, что новый пользователь Windows должен создаваться на сервере отчетов каждый раз, когда создается или изменяется пользовательская группа отчетов. Используя приведенный выше пример, скажем, что создана группа отчетов о продажах и к ней добавлен пользователь B. Теперь на сервере отчетов должен быть пользователь Windows (Sales) с соответствующими правами доступа к папке Sales. Кроме того, многим клиентам веб-приложения потребуются собственные версии групп по продажам / маркетингу и т. Д., Которые потенциально могут увеличить количество пользователей Windows на многие тысячи!

Я новичок в SSRS, поэтому, возможно, смотрю на это неправильно - могу ли я использовать роли для упрощения этой проблемы?

Кроме того, отчеты, вероятно, будут в основном одинаковыми в разных компаниях (под компанией я имею в виду клиента приложения), но каждая компания может захотеть настроить отчеты в разных папках. Т.е. в папке «Компания А Финансы» есть Отчет А, Отчет В и Отчет С, но в папке «Компания Б Финансы» есть только Отчет А. Предположительно ссылки на отчеты не позволят мне иметь 2 физические копии отчета A в обеих папках?

Answer 1

У вас есть несколько разных вопросов в одном, но я попытаюсь ответить на фундаментальный вопрос «Будет ли настройка доступа SSRS с несколькими различными учетными записями повысить мою безопасность?»

... Это безопасно?

Безопасность не является бинарной вещью: вопрос должен быть перефразирован как «Достаточно ли это безопасно?» И ответ на этот вопрос зависит от данных, которые вы держите, воздействия приложения и других соображений. (Данные по продажам во внутреннем приложении компании должны получить ответ, отличный от результатов исследований крупной фирмы, опубликованных в Интернете.)

Единственное ограничение на отчеты, которые может видеть пользователь, будет применено приложением внешнего интерфейса, которое предположительно может быть взломано с помощью, например, Javascript?

Похоже, что включение пользователей служб Reporting Services в разные учетные записи мало что дает для решения этой проблемы. Если кто-то сможет перейти на страницу другого пользователя, что изменится при изменении учетных данных SSRS? Если вы полагаетесь на клиентский Javascript для предоставления отчета SSRS, к которому они должны получить доступ, то вы должны проверить это на стороне сервера, чтобы убедиться, что они не запрашивают что-либо неподобающее.

Я бы сосредоточился на том, чтобы сервер SSRS не был напрямую доступен из Интернета, а затем я бы занялся защитой вашего приложения. Если у вас есть основания полагать, что ваш сайт уязвим из-за того, что кто-то изменяет ваш Javascript, устраните эту проблему.

Размещение пользовательского доступа к SSRS в таких хранилищах не имеет для меня особого смысла в качестве меры безопасности, если только ваше приложение не имеет очень отдельных хранилищ. Это может сделать вещи управляемыми и избежать ошибок, но я не вижу особой дополнительной безопасности.

(Кроме того, предлагаемое вами решение добавит больше паролей, хранящихся где-то, и они, как правило, заслуживают немного дополнительной защиты, так что вы можете создать большую проблему.)

Это мнение одного гика; ваш пробег может отличаться; мои два цента ...