Аннотация: В этой статье в основном представлены типы моделей безопасности для WEB-приложений ASP.NET, сравниваются их преимущества и недостатки, а также предлагается механизм выбора.
Ключевые слова: модель безопасности, доверенная подмодель, имитация/подмодель делегирования, веб-приложение ASP.NET.
1.Предисловие
Веб-приложения ASP.NET обычно имеют многоуровневую архитектуру. Как правило, логическую структуру можно разделить на уровень представления, уровень бизнес-логики и уровень доступа к данным. Для доступа к ресурсам приложения аутентификация и авторизация личности клиента должны охватывать несколько уровней. уровень. В этой статье в основном обсуждается модель безопасности доступа к ресурсам приложений SP.NET.
2. Идентификация доступа к ресурсам.
Типичные ресурсы, предоставляемые клиентам извне веб-приложениями, включают:
Ресурсы веб-сервера, такие как веб-страницы, веб-службы и статические ресурсы (страницы и изображения HTML).
Ресурсы базы данных, такие как данные каждого пользователя или данные уровня приложения.
Сетевые ресурсы, такие как ресурсы удаленной файловой системы и т. д.
Системные ресурсы, такие как реестр, журналы событий, файлы конфигурации и т. д.
Клиенты получают доступ к этим ресурсам на всех уровнях приложения, при этом идентификатор проходит через каждый уровень. Этот идентификатор, используемый для доступа к ресурсу, состоит из:
Идентификатор исходного вызывающего абонента. Идентификатор исходного вызывающего абонента получается и впоследствии проходит через каждый уровень системы.
Идентификатор процесса. Доступ к локальным ресурсам и нисходящие вызовы выполняются с использованием текущего идентификатора процесса. Осуществимость этого подхода зависит от границы, которую необходимо пересечь, поскольку идентичность процесса должна распознаваться целевой системой. Это необходимо вызвать одним из двух способов:
Пересеките домены безопасности Windows в одном домене безопасности Windows — используйте доверительные отношения и учетные записи домена или используйте повторяющиеся имена пользователей и пароли там, где не существует доверительных отношений.
Учетная запись службы. При этом подходе используется (фиксированная) учетная запись службы. Например, для доступа к базе данных учетная запись службы может быть представлена фиксированным именем пользователя и паролем SQL компонента, подключенного к базе данных.
Если требуется фиксированное удостоверение Windows, следует использовать серверное приложение Enterprise Services.
Пользовательское удостоверение Если учетная запись Windows недоступна, вы можете использовать Iprincipal и Identity для создания собственного удостоверения, которое может включать сведения о контексте безопасности.
3. Модель доступа к ресурсам
3.1 Модель доверенной подсистемы
Как показано на рисунке 1, в этой модели контекст безопасности исходного вызывающего абонента не проходит через службу на уровне операционной системы, а фиксированный идентификатор используется на промежуточном уровне службы для доступа к нижестоящим службам и ресурсам. Модель доверенной подсистемы получила свое название от того факта, что нижестоящая служба (возможно, база данных) доверяет вышестоящей службе авторизацию своих вызывающих сторон. В примере на рисунке 1 база данных доверяет авторизации вызывающего абонента на среднем уровне и разрешает доступ к базе данных только авторизованным вызывающим абонентам, используя доверенные идентификаторы.
3.1.1 Режим доступа к ресурсу
В модели доверенной подсистемы модель доступа к ресурсам выглядит следующим образом:
Аутентификация пользователей. Сопоставление пользователей с ролями. Авторизация на основе членства в роли. Использование фиксированного доверенного удостоверения для доступа к нижестоящим ресурсам.
3.1.2 Фиксированная идентификация
Фиксированный идентификатор, используемый для доступа к нижестоящим системам и менеджерам ресурсов, который может быть предоставлен с использованием идентификатора процесса или предустановленной учетной записи службы учетных записей Windows. Для SQL Server Explorer это означает проверку подлинности Windows на SQL Server.
При использовании удостоверения процесса вы обычно используете удостоверение процесса ASP.NET (по умолчанию используется учетная запись ASPNET). В практических приложениях часто необходимо изменить учетную запись ASPNET на более безопасный пароль и создать учетную запись Windows на компьютере SQL Server, соответствующую учетной записи процесса ASP.NET. Конкретный метод заключается в следующем:
Отредактируйте файл Machine.config, расположенный в каталоге %windr%Microsoft.NETFrameworkv1.1.4322CONFIG, и измените настройку атрибута пароля в элементе <processModel> на значение по умолчанию <!-UserName="machine" пароль = «AutoGenerate» --> Измените на <!-UserName="machine" пароль="NewPassword" --> или используйте инструмент ASPNET_setreg.exe, чтобы сохранить имя пользователя и пароль в реестре, и измените конфигурацию на: < -->
Другие приложения используют назначенную учетную запись SQL (указанную именем пользователя и паролем в строке подключения) для доступа к SQL Server. В этом случае база данных должна быть настроена для аутентификации SQL. Строка подключения, сохраненная в файле конфигурации, должна быть защищена шифрованием.
3.2 Моделирование/модель делегирования
Как показано на рисунке 2, при использовании модели олицетворения/удаления служба или компонент (обычно расположенный на уровне логического бизнес-сервиса) использует возможности олицетворения операционной системы для олицетворения личности клиента перед доступом к следующей нижестоящей службе. Если служба находится на той же машине, достаточно использовать олицетворение, если нижестоящая служба находится на удаленной машине, вам также необходимо использовать делегирование, контекстом безопасности доступа к нижестоящим ресурсам является контекст клиента.
3.3 Выбор модели доступа к ресурсам
Сравнение двух моделей доступа к ресурсам показано в таблице 1.
Серверная часть функции моделирования доверенной модели подсистемы/делегированной модели доверяет службам верхнего уровня. Если средний уровень скомпрометирован, внутренние ресурсы становятся уязвимыми для атак. Внутренняя служба может аутентифицировать и авторизовать каждого вызывающего абонента с хорошей безопасностью.
Масштабируемость поддерживает пул соединений и обладает хорошей масштабируемостью. Не поддерживает пул соединений и имеет плохую масштабируемость.
Внутренний ACL-список управления ACL настраивается для одного объекта, что требует меньше усилий по управлению. Каждому пользователю должен быть предоставлен соответствующий уровень доступа. Когда количество серверных ресурсов и пользователей увеличивается, работа по управлению становится обременительной.
Не нужно делегировать технические вопросы. Требуется делегирование. Большинство поставщиков услуг безопасности не поддерживают делегирование.
Модель доверенной подсистемы используется в большинстве интернет-приложений, а также в крупных приложениях интрасети, главным образом потому, что эта модель хорошо поддерживает масштабируемость. Имитационная/делегированная модель обычно используется в небольших системах. Для этих приложений масштабируемость не является основным фактором; основным фактором является аудит;