Защита web-ресурсов с использованием ПАК СЗИ НСД семейства «Аккорд» и ПСКЗИ «ШИПКА»

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

В настоящий момент многие Интернет-сайты представляют собой не статический набор HTML-страниц, а динамически собираемое «на лету» содержимое. В качестве такого контент-генератора используются системы управления контентом - Content Management Systems или сокращенно CMS.

Блоки контента, из которых динамически строится итоговая страница, хранятся в базе данных web-ресурса. С одной стороны это облегчает работу с сайтом и его контентом, с другой стороны - создает множество проблем с точки зрения информационной безопасности.

Обеспечение ИБ web-ресурса - подразумевает не просто создание дополнительного функционального модуля для CMS. На самом деле это постоянный процесс, который должен сопровождать любой сайт с момента начала его проектирования и до завершения его жизненного цикла. Любые реализованные механизмы (в том числе механизмы обеспечения ИБ хостинга и протокола доступа к нему) требуют всестороннего тестирования на предмет защищенности.

Вариантов атак на web-ресурс большое множество. Рассмотрим цели наиболее популярные из них:

1. Deface - подмена главной страницы либо иных страниц сайта;

• подмена актуальной контактной информации с целью кражи клиентов;
• размещение вредоносного кода с целью принудительной переадресации, кражи персональных данных, дальнейшего распространения вредоносного ПО;

2. Удаление файловой системы и всех данных web-ресурса;

3. Рассылка спама средствами хостинга;

4. DOS/DDOS-атаки - создание большой нагрузки на сервер, выведение его из строя, затруднение доступа к web-ресурсу.

Следствием этих атак является не только прекращение или перебои работы web-ресурса, но и потеря доверия к web-ресурсу в глазах клиентов.

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

Именно поэтому вопросы обеспечения информационной безопасности web-ресурсов необходимо учесть на этапе проектирования архитектуры решения и создания CMS в рамках этого решения.

Рассмотрим составляющие web-проекта с точки зрения обеспечения его безопасности:

1. Информационная среда web-сервера:

• операционная система;
• web-сервер (apache, nginx);
• среда исполнения (интерпретатор - например PHP, ASP NET);
• СУБД;
• дополнительные средства защиты web-сервера.

2. Система управления контентом (CMS);

3. Информационная среда администратора web-ресурса:

• информационная система компании (ИС);
• система антивирусной защиты ИС;
• средства межсетевого экранирования ИС;
• средства защиты ИС от утечек информации;
• прочее.

4. Cторонние web-приложения.

Существует распространенное мнение, что основная проблема безопасности сайтов заключается в уязвимостях и ошибках в программных кодах CMS-системы, на которой функционирует сайт. Это совсем не так.

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

Именно из-за этого решение по защите web-ресурсов необходимо строить комплексно. Состояние защищенности каждой рассмотренной составляющей не гарантирует безопасности web-сайта.

Кроме этого каждый сайт необходимо рассматривать как отдельный проект и аудит безопасности должен проводиться для каждого такого отдельного проекта постоянно. Только в этом случае можно говорить о комплексной организации ИБ web-ресурса.

Предложим архитектуру, которая бы решала следующие основные задачи:

• доверенная загрузка ОС с контролем BIOS, контроль чувствительных файлов и конфигураций, контроль целостности файлов настроек web-сервера с помощью СЗИ НСД семейства «Аккорд», установленного на сервере хостинга;
• защита от модификации модулей CMS неавторизованным пользователем, контроль целостности файлов CMS (скрипты, статическое содержимое и пр.) с помощью статического и динамического контроля целостности;
• безопасная работа с БД (СУБД), с помощью модуля для защищенного взаимодействия с использованием токена авторизации[1], сгенерированного через средство сильной аутентификации;
• Разграничение доступа пользователей к данным web-ресурса.

В рамках обеспечения безопасной работы с web-сервером предлагается отойти от идеи защиты рабочих станций и предложить идею защищенной сессии:

1. Каждому пользователю выдается ПСКЗИ «ШИПКА» для доступа к панели администратора web-ресурса и возможности управления сервером по ssh. ПСКЗИ «ШИПКА» теоретически может предоставляться любому зарегистрированному пользователю ресурса (в случае Интернет-магазина);

2. Для организации доступа необходимо пройти процедуру сильной двусторонней аппаратной аутентификации, в ходе которой:

• программно-аппаратные комплексы семейств «ШИПКА» и «Аккорд» устанавливают между собой виртуальный канал для взаимодействия;
• со стороны клиента проверяется, что сервер именно тот, с которым должен работать данный пользователь;
• со стороны сервера проверяется клиент и его токен авторизации (схема token-based authentication) для предоставления соответствующих прав доступа.

3. Виртуальный канал между клиентом и сервером может организовываться в рамках SSL (с использованием российской криптографии) на базе TLS 1.0 (Addition of GOST Ciphersuites to Transport Layer Security).

Ключи SSL хранятся в защищенной памяти внутреннего процессора ПСКЗИ «ШИПКА» у клиента и в защищенной памяти ПАК СЗИ НСД «Аккорд» на стороне сервера. В данной схеме теоретически невозможно получить ключи или реализовать атаку man-in-the-middle.

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

Защиту же системы управления контентом (CMS) необходимо рассматривать с нескольких сторон:

1. Защита от SQL-инъекций и от XSS-атак;

2. Защита от несанкционированного изменения конфигурации CMS, данных в БД (например, построение подсистемы разграничения доступа пользователей на основе ACL-списков доступа).

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

• ACL, проверяющий клиентские IP-адреса;
• ACL, проверяющий запрашиваемые URL-адреса;
• ACL, проверяющие имя web-сервера и подлинность пользователя.

Общий вид предлагаемой архитектуры изображен на рис. 1.

Рисунок. Архитектура системы защиты web-ресурса с применением ПАК СЗИ НСД семейства «Аккорд»

В данном решении процесс подтверждения и получения доступа абсолютно «прозрачен» для пользователя, не требует никаких специализированных знаний и дополнительных действий, кроме подключения ПСКЗИ «ШИПКА». Вся ключевая информация со стороны клиента будет храниться в ПСКЗИ «ШИПКА», а на стороне сервера - в ПАК СЗИ НСД семейства «Аккорд».

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

---

[1] Токен авторизации (token-based authentication) - уникальный идентификатор сессии пользователя, в рамках которой осуществляется доступ. На основе этого идентификатора в дальнейшем пользователю предоставляются соответствующие права доступа в рамках отдельной сессии.

Автор: Каннер А. М.

Дата публикации: 01.01.2010

Библиографическая ссылка: Каннер А. М. Защита web-ресурсов с использованием ПАК СЗИ НСД семейства «Аккорд» и ПСКЗИ «ШИПКА» // Комплексная защита информации. Материалы XV международной научно-практической конференции (Иркутск (Россия), 1–4 июня 2010 г.). М., 2010. С. 82–86.