Настройка доступа к отчету SSRS, требующему входа в источник данных

Question

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

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

• Вход в систему с учетной записью db_owner, прошедшей проверку подлинности Windows. Создает ошибку «Невозможно создать соединение с источником данных» без какой-либо другой информации.
• Вход в систему с учетной записью, прошедшей проверку подлинности SQL, с разрешениями выбора для представления, используемого источником данных, с тем же результатом.
• Использование учетных данных текущих пользователей, тот же результат.
• Я включил удаленные ошибки на SSRS, но не могу найти журнал ошибок, и ошибки, созданные на портале SSRS, не изменились.
• Я прочитал почти каждый учебник о создании логинов и пользователей и о том, как настроить их для доступа к источникам данных.
• Voodoo
• Экстрасенсы
• Терапевты

Все пользователи имеют доступ к данным, когда я запускаю оператор выбора в SSMS, так что я в замешательстве. Я возился с предоставлением явных прав на подключение, выбор, проверку подлинности для сервера, базы данных, просмотр и все еще не повезло.

Answer 1

Ваши пользователи в Active Directory или вы используете аутентификацию SQL? Потому что, если ваши пользователи в AD, вы можете сделать это легко. Я думаю, что вам нужен SSRS в основном режиме, а не в режиме SharePoint, но я не уверен на 100% в этом.

1. Создайте группу AD для удержания привилегированных пользователей, я назову ее MyOU \SSRSViewers
2. Поместите всех пользователей, которые могут получить доступ к этим конфиденциальным данным, в эту группу
3. . В SSRS в настройках безопасности для отчетов, наборов данных и источников данных дайте этой группе чтение или чтение. / execute permissions
4. В базе данных создайте хранимые процедуры для доступа к вашим конфиденциальным данным (вместо этого вы можете предоставить доступ к data_reader, но если вы хотите заблокировать данные, тогда доступ через хранимые процедуры намного проще контролировать).
5. В базе данных создайте пользователя USER для группы MyOU \ SSRSViewers. На уровне сервера пользователям нужна роль PUBLIC, это позволяет им вообще видеть сервер. Вероятно, они уже наследуют это откуда-то еще, но если нет, то вы можете связать его и с этой группой.
6. Предоставьте разрешение EXECUTE для этих хранимых процедур пользователю MyOU \ SSRSViewers (это группа, но она выглядит какпользователь в SSMS, не беспокойтесь)
7. Создайте или измените источники данных своего отчета, чтобы использовать метод WINDOWS AUTHENTICATION и наборы данных для вызова хранимых процедур для получения данных вместо операторов SELECT.
8. Убедитесь, что у вас нет никаких явных запрещающих разрешений для рассматриваемых данных, или если вы хотя бы очень тщательно их проверяете, потому что они могут испортить этот доступ (отказывая в доступе кому-то, кто должен иметь его, а не утечка вашегоdata)

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

SSRS затем проверяет источник данных (у которого нет учетных данных). !) чтобы посмотреть, смогут ли они это использовать. Опять же, если в группе, да. У них все еще нет данных, но они могут получить данные о соединении. Если они могут, SSRS передаст токен из своего сеанса Windows в базу данных, чтобы посмотреть, смогут ли они действительно получить данные.

Если они зайдут так далеко, SQL позволит им только выполнить хранимую процедуру (иполучить данные), если они находятся в этой группе с разрешениями EXECUTE для этой хранимой процедуры.

Пользователи не видят эти учетные записи, браузер автоматически пересылает их токены для входа (не учетные данные), но авторизация проверяется на каждом этапе и является очень безопасной.

Несколько замечаний:Во-первых, ваш сервер SSRS должен находиться в доверенной зоне, чтобы это работало бесперебойно. Если это так, браузер без проблем передаст токены аутентификации в SSRS. Если нет, им придется каждый раз «входить» в SSRS, что быстро устареет. Установите это с помощью вашей групповой политики.

Во-вторых, некоторые конфигурации могут включать двухэтапную аутентификацию, что является проблемой для обычного NTLM. Возможно, вам придется настроить делегированные ограничения, чтобы сделать это гладко.

Я не делал ничего из этого сам, но мы должны были сделать оба в моей компании. Ни один не был особенно болезненным (или по крайней мере парень, который сделал это, не жаловался), но я не мог сказать Вам, как сделать, и я, возможно, не использую идеальные описания / термины.

Третийэто хорошо масштабируется, если у вас есть 3 разных типа отчетов, вы можете создать 3 разные группы, и ваши пользователи могут быть в любой комбинации групп, получая доступ только к данным, относящимся к группам, в которых они находятся.