Блог

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

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

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

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

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

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

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

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

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

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

Кроме того, отчеты, вероятно, будут в основном одинаковыми для разных компаний (под компанией я подразумеваю клиента приложения), но каждая компания может захотеть настроить отчеты в разных папках. т.е. В финансовой папке компании A есть отчет A, отчет B и отчет C, но в финансовой папке компании B есть только отчет Aв нем. Предположительно, ссылки на отчеты не позволят мне иметь 2 физические копии отчета A в обеих папках?

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

… Безопасно ли это?

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

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

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

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

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

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

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