Уровни безопасности

ASP.NET --- Безопасность в ASP.NET --- Уровни безопасности

В основном для большей части веб-приложений основные задачи для реализации защиты (помимо идентифицированных во время моделирования угроз) всегда одни и те же:

Аутентификация

Прежде всего, вы должны аутентифицировать пользователей. Аутентификация задает вопрос: кто идет? В конечном итоге она определяет, кто работает с вашим приложением на другой стороне.

Авторизация

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

Конфиденциальность

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

Целостность

И, наконец, вы должны гарантировать, что данные, передаваемые между клиентом и сервером, не изменяются в результате не авторизованного вмешательства. Снизить уровень этой угрозы позволяют цифровые подписи.

ASP.NET включает базовую инфраструктуру для выполнения аутентификации и авторизации. Библиотека базовых классов .NET Framework включает ряд классов в пространстве имен System.Security, которые предназначены для шифрования и подписи данных. Более того, SSL - стандартизированный способ обеспечения конфиденциальности и целостности данных, передаваемых между клиентским браузером и веб-сервером.

Аутентификация

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

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

В приложениях ASP.NET аутентификация реализуется одной из следующих возможных аутентифицирующих систем:

• аутентификация Windows;

• аутентификация с помощью форм;

• специальный процесс аутентификации.

В каждом случае пользователь предъявляет некоторое удостоверение при регистрации в системе. Идентичность пользователя отслеживается разными способами, в зависимости от типа аутентификации. Например, операционная система Windows использует 96-битное число, называемое SID (security identifier - идентификатор безопасности) для идентификации каждого входящего пользователя. При аутентификации с помощью форм ASP.NET пользователю выдается аутентифицирующий мандат формы, представляющий собой комбинацию значений, которые шифруются и помещаются в cookie-набор.

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

Заимствование прав

Заимствование прав (impersonation) - это процесс выполнения кода в контексте (или от имени) другого пользователя. По умолчанию код ASP.NET выполняется от имени фиксированной, специфичной для конкретной машины, пользовательской учетной записи (обычно Network Service в IIS 8). Чтобы выполнить код с применением другой идентичности, можно воспользоваться встроенными в ASP.NET возможностями заимствования прав. Можно применить предопределенную пользовательскую учетную запись либо предположить пользовательскую идентичность, если этот пользователь уже был аутентифицирован посредством учетной записи Windows.

Одна из причин, по которым может применяться заимствование, состоит в возможности использования существующих учетных записей Windows с их привилегиями. Например, рассмотрим приложение, которое извлекает информацию из различных файлов, уже имеющих специфические для пользователей или групп наборы прав. Вместо того чтобы кодировать логику авторизации в своем приложении ASP.NET, можно воспользоваться заимствованием, полагаясь на идентичность конечного пользователя. Таким образом, Windows может выполнить авторизацию за вас, проверяя привилегии при попытке обратиться к файлу. Можно даже включать заимствование только на краткий период времени вместо полного запроса.

Авторизация

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

Это значит, что если вы захотите посетить главное заседание "Конференции профессиональных разработчиков Microsoft", чтобы послушать, что скажет Билл Гейтс, то должны для этого иметь соответствующие права доступа. Как только вы войдете в зал заседаний, сотрудник службы безопасности проверит ваш бейдж участника конференции. На основании указанной на нем информации он либо пропустит вас, либо скажет, что вы не можете войти. Это пример авторизации. В зависимости от идентифицирующей информации, доступ к запрашиваемым ресурсам либо открывается, либо закрывается.

Пример с конференцией представляет собой случай авторизации на основе ролей - когда авторизация определяется правами группы, к которой принадлежит пользователь, а не на том, кто он такой. Другими словами, вы авторизуетесь для доступа в зал заседаний на основании роли (типа допуска), а не вашей специфичной идентифицирующей информации (имени и фамилии). Во многих случаях авторизация на основе ролей предпочтительнее, поскольку ее гораздо легче реализовать. Если сотрудник безопасности должен будет сверять имя каждого гостя со списком допущенных, то процесс авторизации существенно замедлится. То же самое верно и для веб-приложений, хотя более вероятно, что роли будут следующими: администраторы, модераторы, пользователи, гости и т.д.

В веб-приложениях разные типы авторизации происходят на разных уровнях. Например, на самом верхнем уровне код может проверять идентичность пользователя и решать, можно ли продолжать данную операцию. На нижнем уровне можно настроить ASP.NET так, чтобы запрещать доступ к определенным веб-страницам или каталогам для определенных пользователей или ролей. На еще более низком уровне, когда код выполняет различные задачи - такие как подключение к базе данных, открытие файла записи в журнал событий и т.п. - операционная система Windows проверяет права учетной записи Windows, от имени которой выполняется данный код. В большинстве ситуаций вы не захотите полагаться на этот самый нижний уровень, поскольку код всегда будет выполняться от имени фиксированной учетной записи. В IIS 8 это по умолчанию фиксированная учетная запись Network Service.

Существует несколько причин применения фиксированной учетной записи для запуска кода ASP.NET. Почти во всех приложениях права, выданные пользователю, не соответствуют правам, которые требуются приложению, работающему от имени пользователя. Как правило, код нуждается в более широком наборе привилегий, чтобы решать задачу идентификации, и вы не захотите выдавать такие права каждому пользователю, который может обращаться к вашему приложению.

Например, коду может понадобиться создавать журнальные записи о возможных сбоях, даже если данному пользователю не разрешено напрямую записывать в журнал событий Windows, в файл или в базу данных. Аналогично приложения ASP.NET всегда должны иметь право доступа в каталог C:\[Каталог Windows]\Microsoft .NET\Framework\[Версия]\Temporary ASP.NET Files, чтобы создавать и кэшировать скомпилированные версии веб-страниц на машинном языке.

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

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

Конфиденциальность и целостность

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

Целостность - это обеспечение невозможности изменения данных никем во время передачи по сети или сохранения в хранилище. И то, и другое основано на шифровании.

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

Как упоминалось ранее, шифровать веб-приложения может требоваться по двум причинам:

• Для защиты коммуникаций (передачи данных через сеть). Например, вы хотите сделать невозможной кражу номеров кредитных карт, используемых в системе электронной коммерции, по открытым каналам Интернета. Стандартный подход к решению этой проблемы предусматривает применение SSL. Кроме того, SSL реализует цифровые подписи для обеспечения гарантии целостности. SSL не реализован ASP.NET, а является средством, предоставляемым IIS. Код веб-страницы (или веб-службы) не зависит от того, используется SSL или нет.

• Для защиты постоянной информации (в базе данных или в файле). Например, может понадобиться сохранить номер кредитной карты пользователя в базе данных для будущего использования. Хранение таких данных в виде простого текста в надежде на то, что веб-сервер не будет взломан, является плохой идеей. Вместо этого следует применять классы шифрования, которые предлагает .NET и вручную шифровать данные перед их сохранением.

Не важно, что классы .NET, выполняющие шифрование, не связаны напрямую с ASP.NET. В действительности их можно использовать в любых приложениях .NET.

Связываем все вместе

Итак, каким образом заставить работать вместе аутентификацию, авторизацию и заимствование прав в рамках веб-приложения?

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

По умолчанию анонимные пользователи могут обращаться к любой странице ASP.NET. Но когда пользователь запрашивает веб-страницу, анонимный доступ к которой закрыт, выполняется несколько шагов (показанных на рисунке ниже):

1. Запрос отправляется веб-серверу. Поскольку идентичность пользователя в этот момент не известна, ему предлагается зарегистрироваться с использованием специальной веб-страницы или диалогового окна регистрации браузера. Специфические детали процесса регистрации зависят от типа применяемой аутентификации.

2. Пользователь предоставляет свое удостоверение, которое затем верифицируется - либо вашим приложением (в случае аутентификации с помощью форм), либо автоматически средствами IIS (в случае аутентификации Windows).

3. Если удостоверение пользователя подтверждается, ему предоставляется доступ к веб-странице. Если же оно оценивается как нелегитимное, ему предлагается повторить попытку регистрации, либо же выполняется переадресация на страницу с сообщением о закрытии доступа.

Когда пользователь запрашивает защищенную веб-страницу, которая открыта только для определенных пользователей или ролей, процесс аналогичен, но добавляется дополнительный шаг:

1. ...

2. ...

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

4. Пользователи, которым отказано в доступе, либо приглашаются на повторную регистрацию, либо перенаправляются на веб-страницу с сообщением о закрытии доступа.