Пришлите мастера, у нас слив плохо работает!

Создавая СЗПДн, операторы и интеграторы сосредотачиваются главным образом на реализации требований, которые изложены в 58-м приказе ФСТЭК и методических документах 8 центра ФСБ. Это вполне логично: случись что, проверять правильность мер защиты будут именно с этими документами в руках.

Умышленно или нет, но во множестве таких проектов за кадром оставлена часть требований, приведенных в Положении об обеспечении безопасности ПДн при их обработке в ИСПДн (утверждено постановлением Правительства РФ № 781). Разумеется, большая часть пунктов документа, называемого в профессиональном сообществе «781-м постановлением», лежит в организационной плоскости и находит свое отражение в документации оператора по организации обработки ПДн.

Но есть в пресловутом 781-м пункт 15, который говорит о том, что:

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

Перевод с языка официального документа на язык ИТ прост: речь идет об аудите доступа к ПДн. А поскольку большинство ИСПДн – это системы, построенные с использованием различных СУБД, то можно дополнить: речь идет об аудите доступа к ПДн в базе данных.

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

Итак, цели определены, задачи ясны: за работу, товарищи. Даешь аудит доступа к ПДн в базе данных! Первым очевидным способом реализации требования является контроль с применением встроенных возможностей СУБД. Здесь обычно появляются проблемы, а именно:

• включение аудита приводит к резкому снижению производительности БД;
• включение аудита способно оказать влияние на работоспособность ИСПДн;
• «тонкая» настройка протоколирования затруднена или невозможна;
• у администратора БД сохраняется возможность вмешательства в процесс регистрации, а также возможность изменения (уничтожения) данных аудита.

Первые две проблемы решаются наращиванием мощностей, что связано с увеличением расходов на оборудование и ПО. Проблема с «тонкой» настройкой носит организационный характер – это вопрос рабочего времени и компетенции персонала. А вот проблему редактирования журналов администратором БД решать без применения дополнительных средств проблематично: данные аудита хранятся в сущности в той же базе.

Таким образом, выполнение пункта 15 «в лоб» перетекает в существенные затраты (деньги, рабочее время, обучение, контроль), а практическая реализация задачи в такой постановке связана с большими трудностями.

Для обеспечения простого и эффективного решения задач аудита доступа к ПДн компания «ИНФОРИОН» разработала решение DB Censor – инструмент администратора безопасности, предназначенный для проведения достоверного аудита доступа к БД. Важная особенность решения – полное отсутствие какого-либо влияния на функционирование СУБД. Это обеспечивается специальной технологией доступа к регистрируемым данным: для решения задач аудита проводится пассивный перехват сетевого трафика и его разбор для выделения и записи транзакций к контролируемой базе (см. рисунок).

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

ПО DB Censor обеспечивает аудит таких объектов БД, как таблицы, представления, хранимые процедуры и функции. Продукт способен отслеживать факты доступа к объектам БД, превышение пороговых значений интенсивности запросов («слив полной базы»), а также факты осуществления доступа к БД в нерабочее время.

Применение DB Censor позволяет исключить администратора БД из контура управления аудитом и заблокировать возможность влияния на журналы регистрации. Это повышает достоверность зафиксированной информации.

Решение DB Censor в составе СЗПДн способно стать мощным оружием против нарушений установленной политики доступа к персональным данным, инструментом повышения уровня ответственности и дисциплины пользователей, обеспечивая как реактивную, так и проактивную составляющую процесса защиты ПДн. Пресловутый «слив» перекрывается на уровне внутреннего «барьера» пользователя ИСПДн, понимающего, что некорректные действия в ИСПДн будут гарантированно и быстро выявлены, наказание станет неотвратимым и никакой «человеческий фактор» не поможет уладить проблему.