Обеспечение безопасности ролей
Обновлен: Ноябрь 2007
Управление ролями позволяет управлять авторизацией приложений с помощью создаваемых категорий, которые называются "ролями". Назначая пользователям роли, можно управлять доступом к различным частям или возможностям веб-приложений на основе ролей вместо имен пользователей или комбинировать эти два способа. Например, приложение сотрудников может иметь такие роли, как "Руководитель", "Сотрудники", "Директора" и т. д., где для каждой роли указаны различные привилегии.
Пользователи могут принадлежать к нескольким ролям. Например, если узел является форумом, то некоторым пользователям можно присвоить роли как членов, так и модераторов. Можно определить для каждой роли различные привилегии на веб-узле, и пользователь, имеющий обе роли, будет иметь оба набора привилегий.
Хотя дальнейшие рекомендации по кодированию и настройке могут повысить безопасность приложений, крайне важно своевременно устанавливать на сервере приложений последние исправления безопасности для Microsoft Windows и служб IIS, а также все исправления для Microsoft SQL Server, Active Directory или других источников данных.
Более подробные рекомендациях по написанию безопасного кода и обеспечению безопасности приложений см. в книге "Writing Secure Code" (Защищенный код) Майкла Ховарда (Michael Howard) и Дэвида Леблана (David LeBlanc) и в руководстве, предоставляемом на веб-узле шаблонов и методик Microsoft (https://www.microsoft.com/resources/Practices/default.mspx).
Безопасная настройка диспетчера ролей
По умолчанию диспетчер ролей отключен для приложений ASP.NET для повышения безопасности приложений, которые не используют диспетчер ролей. При включении функции диспетчера ролей для параметров конфигурации по умолчанию задаются наиболее безопасные значения. Сведения о параметрах конфигурации диспетчера ролей и их значения по умолчанию см. в разделе Элемент roleManager (схема параметров ASP.NET).
Значения конфигурации безопасности
При сохранении конфиденциальных сведений в файле конфигурации приложения следует зашифровать конфиденциальные значения, используя защищенную конфигурацию. К особо конфиденциальным сведениям относятся ключи шифрования, хранящиеся в элементе конфигурации machineKey, и строки подключений к источнику данных, хранящиеся в элементе конфигурации connectionStrings. Дополнительные сведения см. в разделе Шифрование сведений о конфигурации с помощью функции защищенной конфигурации.
Обеспечение безопасности ключей шифрования и хеширование
Настоятельно рекомендуется обеспечить безопасность имен ролей, кэшированных в файле Cookie, присвоив атрибуту cookieProtection элемента roleManager значение All. Значения ключа шифрования для определенного алгоритма шифрования хранятся в элементе конфигурации machineKey. Для надежного шифрования укажите ключ шифрования, который является случайно сгенерированным значением соответствующей длины для выбранного алгоритма шифрования.
На сервере, где размещены несколько приложений, следует определить уникальные ключи шифрования для каждого приложения. Менее безопасной альтернативой является определение одного ключа шифрования и указание для ключа параметра IsolateApps.
Кроме того, на сервере можно ограничить возможность переопределения параметров конфигурации компьютера, запретив переопределение прав. Сюда относится запрет на переопределение ключей шифрования в файле Web.config для приложения.
Обеспечение безопасности подключений к источнику данных роли
Строки подключения
Как упоминалось ранее, важно защитить строку подключения, используемую для доступа к SQL Server, Active Directory или другим источником данных приложения. Для обеспечения безопасности подключения к серверу базы данных следует зашифровать сведения о строке подключения в конфигурации, используя защищенную конфигурацию. Дополнительные сведения см. в разделе Шифрование сведений о конфигурации с помощью функции защищенной конфигурации.
Подключение к SQL Server с помощью встроенной защиты
Для подключения к компьютерам с SQL Server следует использовать встроенную защиту с целью устранения риска нарушения конфиденциальности строки подключения, идентификатора пользователя и пароля. При указании подключения, использующего встроенную защиту для подключения к компьютеру, работающему под управлением SQL Server, функция диспетчера ролей обращается к идентификации процесса. Следует убедиться, что идентификация процесса (например, пула приложений), на котором выполняется ASP.NET, является учетной записью процесса по умолчанию или учетной записью пользователя с ограниченными правами. Дополнительные сведения см. в разделе Олицетворение ASP.NET.
Разрешения базы данных SQL Server
База данных SQL Server, используемая для хранения сведений пользователя для ролей, содержит роли базы данных и представления, позволяющие ограничить доступ пользователей только до необходимого уровня возможностей и видимости. Идентификатору пользователя, используемому для подключения к базе данных ролей SQL Server, необходимо назначить минимальный уровень привилегий. Дополнительные сведения см. в разделе Роли и представления в Application Services Database для SQL Server.
Идентификация рабочего процесса SQL Server, экспресс-выпуск
SQL Server 2005, экспресс-выпуск предлагает новый режим работы, позволяющий SQL Server запустить рабочий процесс, работающий как идентификатор подключающегося пользователя. Эту возможность называют режимом "запуск от имени". Хотя этот режим работы подходит при работе на настольном компьютере при использовании IIS, запуск рабочих процессов не допускается на веб-серверах, размещающих несколько ненадежных баз пользовательского кода. На общих размещающих серверах, содержащих приложения, которые не доверяют друг другу, необходимо явно отключить функцию "запуск от имени". Эту функцию можно отключить, подключившись к экземпляру SQL, экспресс-выпуск (например, osql –E –S .\sqlexpress) и выполнив следующую команду Transact-SQL.
EXEC sp_configure 'show advanced option', '1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure 'user instances enabled', 0
GO
RECONFIGURE WITH OVERRIDE
GO
Обеспечение безопасности хранилища проверки подлинности
Для повышения безопасности источника данных при использовании AuthorizationStoreRoleProvider следует хранить данные ролей на сервере Active Directory. Использование хранилища проверки подлинности на основе файла не рекомендуется. Это позволит обеспечить сохранность файлового хранилища политик при нарушении безопасности веб-сервера.
Функция диспетчера ролей возвращает к удостоверению процесса при подключении к серверу Active Directory. Следует убедиться, что удостоверение процесса (например, пула приложений), на котором выполняется ASP.NET, является учетной записью процесса по умолчанию или ограниченной учетной записью пользователя. Дополнительные сведения см. в разделе Олицетворение ASP.NET. Кроме того, следует назначать разрешения учетной записи в хранилище проверки подлинности Active Directory, обеспечивающие доступ только к определенному приложению диспетчера авторизации или области, необходимой для приложения ASP.NET.
Следует использовать средство сетевого шифрования (например, протокол IP IPSec) для защиты подключения к серверу Active Directory.
Обеспечение безопасности файла Cookie роли
Можно указать необходимость кэширования имен ролей в сеансовом файле Cookie для повышения производительности, присвоив атрибуту cacheRolesInCookie элемента roleManager значение true. По умолчанию имена ролей хранятся в зашифрованном формате, но необходимо обеспечить дополнительную безопасность файлов Cookie ролей, присвоив атрибуту cookieRequireSSL значение true, кэшировать только роли в файле Cookie сеанса при включении протокола SSL. Это позволяет предотвратить сетевой доступ к файлу Cookie роли и его использование для атаки воспроизведения на приложение.
Предотвращение общего доступа приложений к файлам Cookie
Если атрибуту cacheRolesInCookie элемента roleManager присвоено значение true, а в качестве значения атрибута cookiePath указан путь, содержащий несколько приложений, то один и тот же файл Cookie роли передается нескольким приложениям. Можно задать совместное использование файла Cookie роли несколькими приложениями, указав одинаковые сведения шифрования в элементе конфигурации machineKey для каждого приложения.
Чтобы избежать совместного использования файлов Cookie имен ролей несколькими приложениями, укажите разные ключи шифрования в элементе конфигурации machineKey для каждого приложения, в качестве значения атрибута cookiePath для каждого приложения укажите определенный путь к приложению и присвойте свойству ApplicationName уникальное значение для каждого приложения.
Обеспечение безопасности веб-страниц, использующих роли
Следует обеспечить безопасность страниц приложений, работающих с конфиденциальными данными (например, страниц входа в систему) с помощью стандартных механизмов веб-безопасности. К ним относится использование протокола SSL и требование, чтобы для выполнения конфиденциальных операций, таких как обновление сведений о пользователях или удаление пользователей, пользователи входили в систему.
Кроме того, на страницах не должны открыто отображаться конфиденциальные данные, такие как пароли и, в некоторых случаях, имена пользователей. Убедитесь, что на страницах, где отображаются такие сведения, используется протокол SSL. Кроме того, они должны быть доступны только для пользователей, прошедших проверку подлинности. Избегайте хранения конфиденциальных данных в файлах Cookie или передачи их через небезопасные подключения.
Обеспечение безопасности при атаках отказа в обслуживании
Методы, выполняющие обновления или объемные операции поиска, могут снизить время реакции источника данных роли при одновременном вызове большим числом клиентов. Для снижения риска атаки отказа в обслуживании ограничьте доступ к страницам ASP.NET, что позволит выполнять обновление баз данных или поиск только пользователям с правами администратора и отображать только те страницы ASP.NET, которые обеспечивают проверку членства роли для общего использования.
Сообщения об ошибках и события
Исключения
Для предотвращения отображения конфиденциальных сведений нежелательным источникам настройте приложение таким образом, чтобы оно либо не отображало подробные сообщения об ошибках, либо отображало подробные сообщения об ошибках, только если клиентом является сам веб-сервер. Дополнительные сведения см. в разделе Элемент customErrors (схема параметров ASP.NET).
Журнал событий
Если сервер работает под управлением Windows Server 2003, то можно повысить безопасность приложения, обеспечив безопасность журнала событий и настроив параметры журнала событий, связанные с размером, хранением и т. д, чтобы предотвратить косвенные атаки отказа в обслуживании на него.
Данные трассировки
Веб-сервер можно настроить для отслеживания выполнения определенных действий, связанных с функцией диспетчера ролей, и сохранения данных трассировки в файле журнала. Поскольку конфиденциальные сведения, такие как имена пользователей и имена ролей, могут храниться в файле журнала трассировки, то доступ к возможностям включения трассировки, а также к возможности настройки расположения файла журнала трассировки и доступа к нему должен быть ограничен и предоставлен только администраторам.
Пользовательские поставщики ролей
При создании пользовательского поставщика роли убедитесь, что выполнены все рекомендации по обеспечению безопасности, чтобы при работе с базой данных избежать таких атак, как атака путем внедрения кода SQL. При использовании пользовательского поставщика ролей убедитесь, что поставщик следует рекомендациям по обеспечению безопасности.
Работа с символами, зависящими от языка и региональных параметров
При использовании поставщика ролей SQL Server или пользовательского поставщика ролей источник данных можно настроить для хранения данных ролей в формате с учетом языка и региональных параметров. Однако ASP.NET всегда оценивает имена ролей, указанные в элементе конфигурации авторизация, и имена ролей в источнике данных, как независящие от языка и региональных параметров. В результате неавторизованные пользователи могут получить нежелательные разрешения, так как их несанкционированные имена ролей рассматриваются как независящие от языка и региональных параметров и совпадают с именами авторизованных ролей. Во избежание несанкционированного доступа убедитесь, что имена ролей являются уникальными, когда они оцениваются как независящие от языка и региональных параметров.