Вопросы безопасности ASP.NET интегрированная аутентификация

Question

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

Мой вопрос: есть ли проблемы с безопасностью при таком подходе?Что касается удаления учетных данных БД из строки подключения, есть ли лучший (более простой или простой) подход, который мы должны / могли бы использовать?

Answer 1

Если вам необходимо обеспечить безопасность и аудит доступа к производственной базе данных, то проверка подлинности Windows является лучшим выбором, чем проверка подлинности Sql, по ряду причин:

1. Вы можете точно контролировать, кто может получить доступ к базе данных через группы NT и разрешения, что означает, что вы знаете, кто конкретно имеет доступ к базе данных. Пул доступа с аутентификацией sql ограничен только тем, кто знает пароль. Учитывая n людей, которые знают пароль, отслеживать, кто что сделал в определенный момент времени, сложнее (но не невозможно), учитывая это.

2. Только ваши системные администраторы должны знать пароль для идентификации nt с доступом к базе данных; на самом деле, большая часть конфигурации может быть выполнена только зная имя пользователя

3. Логины и доступ можно отслеживать на уровне домена гораздо проще, чем при входе в SQL Server.

То, что он не даст вам, это:

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

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

Проблемы с этим подходом уже обсуждались в других постах; в частности, с приложениями ASP.Net вы должны решить, собираетесь ли вы использовать олицетворение / делегирование (веб-сервер может выступать в роли пользователя NT, обращающегося к нему) или модель доверенного пользователя (где вы настраиваете фиксированный идентификатор для доступа к определенному Ресурсы).

Это усложняется используемой версией IIS.

Answer 2

Использование идентификатора пула приложений может быть довольно сложным в настройке, рассмотрим проблему trust и Delegation . Лучшим вариантом может быть защита строк соединения с использованием шифрования.

Answer 3

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

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