Существуют несколько методов защиты баз данных. Но наверняка, с точки зрения соотношения суммы совокупной стоимости владения и уровня снижения рисков утечки конфиденциальной информации, самый эффективный из них – это сочетание шифрования данных и многофакторной аутентификации пользователей.
Это сочетание в среде экспертов называется «композитным методом защиты»: один вид защиты усиливается за счет другого в противовес наслаиванию элементов ИБ друг на друга.
Достоинства композитного метода
Что дает такой подход? Во-первых, вся конфиденциальная информация в СУБД надежно зашифрована. Причем при работе с данными расшифровывание происходит не на стороне сервера, а строго на стороне пользователя, т.е. клиентским программным обеспечением пользовательской рабочей станции. Это существенно упрощает защиту информации при передаче ее по сети и снимает необходимость создания VPN-соединения между пользователем и сервером СУБД. Передача данных в зашифрованном виде исключает потерю конфиденциальности информации при ее возможном перехвате в сети.
Во-вторых, читать и изменять защищаемую информацию внутри СУБД могут только те пользователи, у которых есть соответствующие на то полномочия. Для них весь процесс работы с зашифрованными данными выглядит абсолютно «прозрачно». И, наконец, проблема «суперпользователя» – системного администратора – решается разделением полномочий с администратором безопасности на основе административных регламентов и технических средств.
Сегодня существует множество угроз информационной безопасности, применимых к СУБД в целом. Наиболее актуальные и критичные угрозы и способы противодействия этим угрозам приведены в таблице.
Методы противодействия типовым рискам
| Риски | Противодействие | |
|---|---|---|
| 1 | Хищение информации из СУБД неавторизованным пользователем | Шифрование базы данных и ролевое управление доступом: установка системы управления доступом по цифровым сертификатам, шифрование критических сегментов базы |
| 2 | Хищение или использование чужой учетной записи путем кражи или перебора пары логин-пароль | Аутентификация по цифровому сертификату |
| 3 | Хищение или копирование ключевого контейнера или его резервной копии | Закрытый ключ хранится как неэкспортируемый в защищенной памяти интеллектуальной смарт-карты или токена |
| 4 | Перехват закрытого ключа (в момент его использования с помощью специального ПО) | Аппаратная реализация криптографических операций в смарт-карте или токене: использование технологий для аппаратного выполнения криптографических операций (SSL) в процессоре токена без «выхода» закрытых ключей наружу |
| 5 | Дублирование смарт-карты (копирование закрытых ключей в другой токен) | Доступ к защищенной памяти смарт-карты, в которой хранятся закрытые ключи, защищен PIN-кодом. Экспорт закрытых ключей из смарт-карты исключен: закрытые ключи, сгенерированные смарт-картой или импортированные в нее, хранятся в закрытой памяти смарт-карты и не могут быть из нее извлечены |
| 6 | Перехват передаваемых по сети данных | Использование закрытых протоколов для шифрования передаваемых по сети данных с помощью встроенных в СУБД алгоритмов симметричного шифрования |
Источник: «Аладдин Р.Д.», 2016
Особые подходы
Как на практике реализовать защиту СУБД от утечек данных, опираясь на список рисков и методов их снижения, представленных в таблице выше? И как инсталлировать подобное решение?
Логическая схема защиты СУБД
Источник: «Аладдин Р.Д.», 2016
Учитывая сложность современных СУБД, их высокую нагруженность и внушительные объемы обрабатываемой/хранимой информации, применение наложенных (встраиваемых в базу данных) средств защиты достаточно болезненно. Анатолий Лебедев, доцент кафедры информационной безопасности МГТУ им. Н.Э. Баумана, объясняет: «Дело в том, что любое изменение технической среды функционирования СУБД, находящейся «под высокой нагрузкой», почти всегда влечет сбои в работе, длительную отладку возникших ошибок и исключительных ситуаций. Сам же процесс устранения аварийных сбоев требует еще большей квалификации администраторов СУДБ, чем штатное техническое сопровождение».
Таким образом, защита информации в базе данных – это высокотехнологичная, экспертная задача. Решения, реализующие этот функционал, должны учитывать вышеперечисленные особенности. Встраивание таких решений должно исключать любое нарушение логики работы СУБД. Техническое окружение базы данных должно оставаться неизменным.
Вторым, не менее важным требованием к средству защиты СУБД является контроль целостности собственных процедур. «Последнее – крайне важное свойство средств защиты. Дело в том, что все процедуры, выполняющие криптографические операции с данными, теоретически могут быть модифицированы администратором БД таким образом, что он может получить возможность копирования защищаемых данных в открытом виде. Чтобы этого не произошло, при запуске системы выполняется проверка целостности соответствующих процедур», – подтверждает Александр Додохов, руководитель направления защиты баз данных компании «Аладдин Р.Д.».
Разумеется, разработчик обязан предусмотреть предоставление всех необходимых возможностей для аудита и мониторинга действий пользователей при работе с защищаемыми данными. Все операции, связанные с обработкой зашифрованных данных, должны фиксироваться в соответствующих журналах. Журналы должны быть защищены от возможной модификации информации.
Как это работает?
Итак, у компании есть: база данных (или набор таблиц), авторизованные и неавторизованные пользователи, имеющие возможность подключаться через клиентское ПО системы защиты, а также администратор базы данных и администратор безопасности. Сама СУБД может находиться как внутри организации, так и у стороннего провайдера и быть доступной в качестве «облачного» хранилища.
Схемы подключения пользователей к СУБД
Источник: «Аладдин Р.Д.», 2016
С использованием собственного АРМ администратор безопасности генерирует ключи шифрования данных (КШД, симметричные) и, получив от администратора базы данных временные полномочия, шифрует на этих ключах избранные столбцы соответствующих таблиц. Этих ключей может быть в общем случае от одного до количества, равного количеству столбцов таблицы. Существует возможность зашифровать все столбцы на одном ключе, каждый столбец на собственном или комбинировать. В каждом конкретном случае для этого могут быть свои причины, определяемые политиками безопасности.
Администратор безопасности шифрует соответствующие КШД на открытых ключах пользователей. Для хранения ключевого материала используются USB-токены сотрудников. Для зашифрования КШД под каждого пользователя администратор безопасности использует ассиметричное шифрование. При этом копии всех КШД в зашифрованном виде хранятся на АРМе администратора безопасности.
Сами же КШД, зашифрованные на открытых ключах пользователей, хранятся в специальной таблице на сервере БД. Администратор СУБД никаких ключей не получает и не имеет к ним доступа. Администратор безопасности также лишается своих временных полномочий и не имеет более доступа к КШД. Так элегантно решается пресловутая проблема «суперпользователей».
Как же работают обычные пользователи? После их аутентификации происходит защищенный обмен между клиентской и серверной частью. В его процессе зашифрованный на открытом ключе пользователя и хранящийся в специальной таблице на сервере СУБД КШД направляется пользователю. Там он расшифровывается с помощью его личного ключа, зашифровывается на открытом ключе сервера и направляется на сервер, где используется для зашифрования/расшифрования данных до тех пор, пока инициированная пользователем сессия не завершится. Повторимся, для авторизованных пользователей доступ к информации абсолютно прозрачен и не требует никаких дополнительных действий. Важно понимать, что КШД в открытом виде никогда не передается и хранится только в оперативной памяти процесса – пользовательской сессии на сервере.
Делая выводы, приходится признать, что утечки информации из корпоративных баз данных способны погубить любой бизнес. Похитителями конфиденциальной информации могут быть и хакеры, и сотрудники компании. Сама же СУБД предоставляет ограниченный набор инструментов безопасности, поэтому приходится прибегать к помощи наложенных средств защиты информации от сторонних вендоров.
При этом важно найти такой баланс между работой этих средств защиты и удобством выполнения сотрудниками своих функциональных обязанностей, чтобы бизнес и персонал чувствовали, что делают общее дело и обременены общей ответственностью за безопасность информации.
Татьяна Ведешкина
Источник: CNEWS
