Основные способы защиты приложений ASP.NET с внутренним сервером SQL Server

Защита приложений ASP.NET с внутренним сервером SQL Server — чрезвычайно сложная задача. .

Безопасная отправная точка

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

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

Я предполагаю, что вы уже укрепили защиту приложения ASP.NET, экземпляра SQL Server и всех промежуточных уровней, в том числе сервера, на котором они выполняются. Другими словами, будем исходить из того, что уровень защиты серверов соответствует конфиденциальности и ценности данных в системе, действуют политики и процедуры для непрерывного пересмотра и анализа мер безопасности в условиях изменений окружающей среды и новых угроз. Компания Microsoft опубликовала огромное количество бесплатных материалов по этой тематике в сетях MSDN и TechNet, а на независимых веб-узлах содержится еще больше информации. Если вы пока не приняли необходимые меры, сделайте это немедленно, поскольку ваши данные и серверы, вероятно, уже подверглись атаке. Вот несколько сайтов, которые послужат хорошей отправной точкой:

• Microsoft Safety & Security Center;
• SQL Server Database Security & Compliance;
• ASP.NET Security Tutorials;
• SQLSecurity.com.

Безопасные связь и соединения

Существует много способов защитить связь и соединения приложения ASP.NET с SQL Server, чтобы сервер базы данных было сложнее обнаружить и установить с ним контакт. Один из способов — использовать порт с номером, отличным от выбираемого по умолчанию порта 1433, или порт, определяемый при запуске системы для именованных экземпляров. С помощью диспетчера SQL Server Configuration Manager можно назначить порт для всех IP-адресов, перечисленных в окне TCP/IP Properties, как показано на экране 1. Обязательно удалите любые значения свойства TCP Dynamic Ports для каждого IP-адреса. Полезно отключить службу SQL Server Browser, а также отключить или, по крайней мере, скрыть экземпляр SQL Server, чтобы служба Browser не открывала его каждому приложению, которое запрашивает сведения о портах, прослушиваемых сервером. Одна из причин отказаться от отключения — наличие нескольких экземпляров SQL Server на узле, так как соединения сопоставляются экземплярам. Экземпляры можно спрятать на странице свойств протоколов экземпляра, как показано на экране 2, хотя в результате SQL Server лишь перестанет отвечать на запросы клиентских приложений, интересующихся списком систем SQL Server. Такие изменения обеспечивают защиту неизвестностью, которая не отличается высокой надежностью и не должна быть единственным средством. Однако таким образом формируются барьеры на пути злоумышленников, пытающихся отыскать экземпляр SQL Server.

Экран 1. Настройка порта TCP/IP, по которому SQL Server прослушивает подключения

Экран 2. Сокрытие экземпляра SQL Server от службы SQL Server Browser

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

В листинге 1 показан образец исходного текста T-SQL, который создает конечную точку для приложения и назначает разрешения для подключения. Перед его запуском необходимо настроить экземпляр SQL Server на прослушивание порта 9450, заменить Puppy на имя компьютера и ввести имена входа User1 и User2. Затем следует запустить код в среде SQL Server Management Studio (SSMS) как User1 и User2, чтобы посмотреть, как каждый из них может подключиться к экземпляру. User1 будет подключаться как Puppy,9450, чтобы задействовать этот порт, и не сможет подключаться к Puppy напрямую (Puppy — имя компьютера или экземпляра). User2, наоборот, может подключиться к Puppy через роль Public и не может использовать номер порта. Как показано в этом примере, благодаря конечной точке можно задействовать несколько портов и ограничить круг пользователей, имеющих право подключаться через определенные порты.

Данные в процессе перемещения между приложением и SQL Server при использовании протокола HTTP можно защитить с помощью IPsec или SSL. IPsec оптимален для связей внутри сети, но это вполне приемлемо для приложений ASP.NET, так как веб-сервер и сервер базы данных компании, скорее всего, локальны друг для друга. Если данные требуется передавать вне компании через Интернет, следует настроить сеть на использование SSL. В любом случае данные, передаваемые по сети, шифруются. Можно создать сертификат или ключ в SQL Server либо использовать внешний сертификат или ключ от доверенного центра сертификации (CA).

При использовании SSL данные шифруются внутри уровня протокола и доступны большинству клиентов, за исключением клиентов, в которых применяется DB-Library или Microsoft Data Access Components (MDAC) 2.53. SSL также можно использовать для проверки сервера, если клиент запрашивает шифрование. Для этого необходимо настроить веб-сервер на доверительное отношение с корневым удостоверяющим центром, используемым сервером с экземпляром SQL Server. После того как сертификат установлен на сервере, настройте экземпляр SQL Server для его использования на странице свойств протоколов экземпляра, как показано на экране 3. Впоследствии можно установить свойство Force Encryption на вкладке Flags, чтобы принудительно шифровать соединения для всех клиентов (значение Yes) или сделать шифрование необязательным (No). В электронной документации SQL Server Books Online (BOL) обязательно убедитесь в соответствии требованиям сертификата, который предполагается использовать для SSL.

Экран 3. Настройка SSL для экземпляра SQL Server

IPsec — еще один способ шифрования перемещаемых данных. Это набор протоколов безопасности для передачи пакетов через сеть. Он обеспечивает глубокую защиту от различных сетевых атак, порчи и кражи данных, в том числе учетных данных пользователей. IPsec предоставляется операционной системой Windows как на клиентской, так и на серверной стороне соединения, и для его использования не требуется никакой настройки со стороны администратора базы данных. Как правило, системные администраторы Windows настраивают IPsec через оснастку Windows Firewall with Advanced Security консоли Microsoft Management Console (MMC), доступную из раздела Administrative Tools панели управления. Для правильной настройки IPsec требуется определенный опыт, но в сети TechNet опубликованы документы, где описаны факторы, которые нужно учитывать, и необходимые действия.

Если для хранения данных вне сервера используется сеть хранения данных (SAN), полезно зашифровать данные, передаваемые по сети. Их можно передавать открыто, что связано с риском потери конфиденциальной информации из-за возможности отслеживать и анализировать в реальном времени пакеты в сети SAN.

Защита Extended Protection от атак с передачей учетных данных

В SQL Server 2008 R2 появилось расширение безопасности, Extended Protection, для одного специфического типа атак. В действительности Extended Protection — не компонент SQL Server; в нем используются возможности технологии Extended Protection, реализованной в Windows 7 и Windows Server 2008 R2.

Цель Extended Protection — предотвратить трансляцию учетных данных (credential forwarding) в ходе атак типа man-in-the-middle (MITM), когда злоумышленник находится между клиентом и сервером, представляя каждого из них друг для друга. У данного метода есть и другие названия, например credential relaying. Трансляция учетных данных — не атака как таковая, а прием, позволяющий воспользоваться успехом атак других типов, например спуфинга и «заманивания» (luring). Трансляция учетных данных часто используется в ходе фишинга, после того как жертвы откликаются на приманку и щелкают по ссылке в сообщении электронной почты, полагая, что оно пришло, например, от банка.

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

Разработчики сайта банка с достаточным вниманием отнеслись к его безопасности, поэтому он отвечает злоумышленнику заголовком WWW-Authenticate, в сущности требуя идентифицировать себя и предоставить доказательства подлинности — как правило, имя пользователя и пароль. У злоумышленника нет законной учетной записи в банке, поэтому он пересылает заголовок запроса клиенту. Пользователь, полагающий, что находится на веб-узле банка, вводит имя пользователя и пароль. Злоумышленник пересылает учетные данные на сайт банка и может выполнять любые действия, разрешенные пользователю, в этом интернет-банке. Банк полагает, что имеет дело напрямую с пользователем, когда тот переводит свой вклад в какую-то другую страну. На приведенном рисунке показана упрощенная версия взаимодействия.

Рисунок. Схема трансляции учетных данных

Пример из Web взят потому, что так проще всего объяснить механизм трансляции учетных данных. Но подобная MITM-атака может быть проведена, когда вы используете какую-либо программу для доступа к серверу почти любого типа, в том числе базы данных SQL Server. Атаки этого типа еще опаснее, потому что весь процесс автоматизирован. Жертва может даже не участвовать в нем.

Когда клиентское приложение (часто браузер) проходит проверку подлинности на сервере с использованием SSL, сервер формирует канал Transport Level Security (TLS) и использует его для проверки подлинности. Результатом процесса становятся два ключа сеанса: один формируется SSL для защиты пересылок между клиентом и сервером, а другой ключ используется процессом проверки подлинности. Между ключами двух типов нет привязки. Из-за этого отсутствия привязки и возможен процесс трансляции.

Взгляните вновь на рисунок и обратите внимание, что создано два SSL-канала: один между клиентом и злоумышленником, другой — между злоумышленником и банком. Учетные данные клиента передаются по первому SSL-каналу, а злоумышленник ретранслирует их по второму. Серверу банка, проверяющему учетные данные, неизвестно, что канал, по которому поступают данные, исходит от злоумышленника, а не от клиента. И вновь между ключами двух типов нет привязки, поэтому сервер банка не может знать, что учетные данные передает злоумышленник, а не законный владелец счета в банке. Поэтому один только SSL положения не спасет.

Решение Microsoft — расширенная защита (Extended Protection), используемая для идентификации через проверку подлинности Windows. Extended Protection формирует внешний канал с защитой TLS и подтверждаемый клиентом внутренний канал, передающий маркер Channel Binding Token (CBT) от клиента к серверу. Этот маркер привязывает внешний канал к подтвержденному клиентом внутреннему каналу, объединяя CBT канала между клиентом и злоумышленником с информацией о проверке подлинности, которая в конечном итоге передается серверу. Сервер с включенной расширенной защитой (в этом случае законный сервер банка) сравнивает CBT внутреннего канала и CBT в информации о проверке подлинности во внешнем канале. CBT специфичен для назначения канала, поэтому маркер, полученный сервером от злоумышленника, не совпадет с маркером в учетных данных клиента. Если они не совпадают, сервер банка отказывается подтвердить подлинность.

Метод защиты на основе привязки каналов описан в документе RFC 5056 рабочей группы Internet Engineering Task Force (EITF), опубликованном по адресу tools.ietf.org/search/rfc5056. Для использования Extended Protection не обязательно глубоко понимать механизмы протокола, но желающие могут найти всю информацию.

Одно из достоинств расширенной защиты в том, что основную часть сложной работы выполняет Windows. Нужно лишь использовать ту Windows, в которой реализована расширенная защита: Windows 7 или более новую версию и Server 2008 R2 или более новую версию. Для предыдущих версий Windows необходимо установить обновление Windows Update и включить расширенную защиту, изменив параметр реестра. Подробные сведения можно найти в статье Microsoft «Extended Protection for Authentication».

Проверка подлинности

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

SQL Server обеспечивает два способа: встроенная проверка подлинности Windows и проверка подлинности SQL Server. В случае встроенной проверки подлинности Windows контроль удостоверений пользователей осуществляется при входе в Windows. Затем разрешения для доступа к объектам SQL Server назначаются именам входа и группам Windows. Этот тип проверки подлинности возможен только при запуске SQL Server с версией Windows, обеспечивающей проверку подлинности Windows NTLM или Kerberos. Данное условие выполняется во всех версиях, начиная с Windows 2000.

При использовании проверки подлинности SQL Server идентификация производится исключительно средствами SQL Server. В этом случае можно создать уникальные имена пользователя и пароли. Пользователь или приложение подключается к SQL Server и представляет эти учетные данные для доступа. Затем SQL Server назначает разрешения этому имени входа напрямую или через членство в роли.

Если требуется надежно защитить базу данных и приложение, следует применять встроенную проверку подлинности Windows с использованием Kerberos. Этот метод надежнее проверки подлинности SQL Server, даже после улучшений, внесенных в SQL Server 2008 для реализации политик паролей Windows. Встроенная проверка подлинности Windows гораздо безопаснее, так как Windows передает учетные данные через сеть только в хэшированной форме. Если предполагается задействовать встроенную проверку подлинности Windows, убедитесь, что экземпляр SQL Server настроен для работы в режиме Windows Authentication, как показано на экране 4. Помимо применения Windows для проверки подлинности, в пользу этого режима есть еще один довод — всесильное имя входа sa.

Экран 4. Настройка экземпляра SQL Server для использования режима Windows Authentication

Имя входа sa (system administrator) задействовано в основном для обратной совместимости со старыми версиями SQL Server. Учетная запись sa сопоставляется предопределенной роли сервера sysadmin, поэтому каждый, кто использует имя sa, — полноценный системный администратор с безотзывными правами во всем экземпляре сервера и всех базах данных в нем.

Никогда не следует использовать имя входа sa для доступа к базе данных в приложении. В результате взломщики, которым удастся овладеть приложением, смогут получить контроль на административном уровне над сервером базы данных. Это удобный способ нападения на серверы, поэтому не следует задействовать проверку подлинности SQL Server. Если вы предпочитаете не следовать этому совету, по крайней мере, назначьте для sa особенно длинный и сложный пароль и переименуйте и отключите имя входа с помощью программного кода, как показано в листинге 2. Но гораздо лучше вообще не задействовать sa. В случае со встроенной проверкой подлинности Windows работа с приложениями становится более трудоемкой, но выигрыш в безопасности очевиден.

Принцип наименьших прав доступа

Начиная с SQL Server 2005, разрешения стали гораздо более детальными, чем в предшествующих версиях. Администратору часто приходилось назначать пользователю предопределенную роль сервера или базы данных, чтобы позволить ему выполнять единственный тип действия на конкретных объектах. В результате пользователи обычно получали слишком широкий набор разрешений. Таким образом, нарушался принцип наименьших прав доступа, в соответствии с которым пользователю назначаются только разрешения, необходимые для выполнения задачи, не больше и не меньше.

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

Определяя разрешения приложения, следует ответить на вопрос: какие действия сможет произвести взломщик, когда (а не если) получит контроль над любым аспектом приложения или SQL Server? Если приложению назначена роль владельца базы данных, то взломщик становится владельцем данных. Если приложение может лишь прочитать таблицу продуктов (и только названия и цены продуктов), то атака приносит злоумышленнику не так уж много, особенно если учесть, что информация доступна всем на сайте компании. Назначать явные разрешения различным объектам базы данных — кропотливая работа, но это, пожалуй, самая важная мера, которую можно применить для защиты данных.

Постоянно отслеживайте состояние защиты

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

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

-- Создание имен входа в SQL Server.
CREATE LOGIN [Puppy\User1] FROM WINDOWS;
CREATE LOGIN [Puppy\User2] FROM WINDOWS;

-- Создание конечной точки.
CREATE ENDPOINT AppEndPoint1 STATE = STARTED AS TCP (
  LISTENER_PORT = 9450,
  LISTENER_IP = ALL
) FOR TSQL();
-- Результирующее сообщение: создание конечной точки T-SQL приведет к отзыву
-- любых разрешений подключения ‘Public’ на конечной точке ‘T-SQL Default TCP’.
-- Если для этой конечной точки желателен доступ ‘Public’, повторно примените это разрешение с использованием
-- 'GRANT CONNECT ON ENDPOINT::[TSQL Default TCP] to [public]'.

-- Установить разрешения подключения для Public.
GRANT CONNECT ON ENDPOINT::[TSQL Default TCP] to Public;
REVOKE CONNECT ON ENDPOINT::AppEndPoint1 TO Public;

-- Установить разрешения подключения для User1.
GRANT CONNECT ON ENDPOINT::AppEndPoint1 TO [Puppy\User1];
DENY CONNECT ON ENDPOINT::[TSQL Default TCP] TO [Puppy\User1];
DENY CONNECT ON ENDPOINT::[TSQL Named Pipes] TO [Puppy\User1];
DENY CONNECT ON ENDPOINT::[TSQL Local Machine] TO [Puppy\User1];

-- Переименование имени входа sa.
ALTER LOGIN sa WITH NAME = Floyd;
-- Отключение переименованного имени входа sa.
ALTER LOGIN Floyd DISABLE;

Дон Кайли (donkiely@computer.org) — старший консультант по технологиям разработки безопасных настольных и веб-приложений для баз данных, имеет звания MVP, MSCD