В текущей обстановке в условиях мирового карантина и сопряженных с ним событий можно долго рассуждать о новых способах и подходах атаковать компьютеры и другие устройства пользователей. Однако одно остается неизменным: конечная цель хакеров — это данные организаций, самое ценное.
Не стоит делать выводы, что, если в вашей базе данных не хранится никаких персональных данных пользователей или данных банковских карт, то она не представляет интереса для злоумышленников. Любая информация несет ценность, и, соответственно, ее утечка приведет к убыткам для организации.
Примеров может быть много: скомпрометированные данные программ лояльности, систем обработки заказов, пусть даже и обезличенные, в руках конкурентов — это мощное оружие. Не говоря уже о данных, похищенных из банковских систем.
Важно отметить, что потеря данных для бизнеса опасна не только потому что из полученных сведений можно сделать какие-либо выводы касаемо ведения бизнеса, но и потому что сам факт хищения данных у компании наносит ущерб ее авторитету.
В последнее время фиксируется всплеск утечек данных, предпосылкой к которым выступает банальная незащищенность СУБД от уязвимостей; растет число инсайдерских атак, другими словами — хищений данных сотрудниками, в основном с целью дальнейшей перепродажи. По данным аналитического центра «Гарда Технологии», в 2019 году на черный рынок баз данных в России попали данные 70 млн. клиентов более чем 40 банков. 91% всех похищенных баз данных выставлялись на продажу сотрудниками банков, 8% — посредниками, например, сторонними командами. И лишь 1% данных стали доступны благодаря уязвимостям в банковских системах. (источник http://www.tadviser.ru/index.php/Статья:Расценки_пользовательских_данных_на_рынке_киберпреступников)
Почему так происходит?
Казалось бы, база данных должна быть максимально защищена всеми возможными силами. Однако, лишь 15% всех затрат на безопасность направляются на защиту баз данных, в то время как на сетевую безопасность идет 67%. Увы, основная проблема халатного отношения к вопросу защищенности данных — человеческий фактор: либо ответственные лица уверены, что данные компании никому не интересны и поэтому не могут стать конечной целью злоумышленников, либо чересчур полагаются на средства информационной безопасности компании (кстати, часто они ограничиваются лишь антивирусами и файрволлами). Излишнее доверие работодателей и невнимательность к разграничению прав доступа также открывают возможности для хищения данных собственными сотрудниками.
Какие действия стоит предпринять организации, чтобы защитить свои данные, хранящиеся в БД?
Средства защиты можно разделить на несколько уровней:
- предположение (аудит, обследование)
- позволяет выявить слабые места в защите данных
- предотвращение (недопущение нелегитимного доступа)
- запрещает технически совершить намеренные или ненамеренные действия, которые могут скомпрометировать данные
- определение (максимально быстрое выявление мошенничества) и расследование (возможности выявить нарушителя, когда факт мошенничества зафиксирован)
- оперативно позволяет определить факт совершения подозрительного действия позволяет отследить все действия с данными, чтобы понять кто и каким образом произвел незаконные действия
Предположение
Первый шаг — понять и оценить реальный уровень защищенности базы, построить детальные отчеты, включающие в себя:
- анализ параметров конфигурации СУБД
Первоочередная задача в аудите баз данных.
В первую очередь проверяются настройки безопасности, длительность жизненных циклов паролей и другие параметры.
Такой аудит может проводиться утилитами, предоставляемыми вендорами, программными продуктами от независимых производителей либо скриптами, заранее подготовленными специалистами
- анализ привилегий и ролей, выданных пользователям
Это та часть настроек, о которой традиционно часто забывают.
Важно полностью контролировать привилегии доступа и, по возможности, согласовывать выдачу прав на изменение и удаление объектов с представителями службы ИБ.
Тем не менее, даже жесткие регламенты не могут гарантировать полного отсутствия прецедентов выдачи избыточного доступа к данным.
Таким образом, мы рекомендуем периодически формировать отчеты о текущих привилегиях пользователей.
- анализ поведения пользователей
Например, статистика по неудавшимся попыткам входа или факты доступа к определенным объектам БД.
Такая статистика помогает наглядно отобразить количество нежелательных действий и, если необходимо, провести расследование и принять меры.
После формирования отчетов, в зависимости от результатов аудита, следующим шагом идут уже принятия решений по внедрению конкретных инструментов и систем безопасности. Одного универсального “рецепта” нет, однако, можно перечислить наиболее эффективные подходы.
Предотвращение
К вариантам по предотвращению можно отнести несколько технологий:
- ограничения для администраторов баз данных
Возвращаясь к теме инсайдерских атак: подавляющее большинство хищения данных происходит руками пользователей с правами администраторов баз данных, или DBA, так как данная роль предоставляет техническую возможность для просмотра всех таблиц и для любых манипуляций с данными. Привилегии DBA в ходе проекта могут получить разработчики, администраторы, аналитики, даже менеджеры проектов. Помогают в данной ситуации специальные программные инструменты для ограничения возможностей доступа к данным администраторами БД. Программные продукты такого класса обычно разрабатываются вендорами-производителями СУБД. При попытке обратиться к таблицам, защищенными такими утилитами, DBA получает ошибку доступа, а сам факт такой попытки будет занесен в журнал. Такой подход не только убережет данные от инсайдерских атак, но и позволит выявить ненадежных сотрудников.
- скрытие данных от пользователей
Все встречались с ситуацией, когда вы видите только четыре последние цифры банковской карты. Это типичный способ скрытия данных. В зависимости от роли пользователя в компании или вне ее, данные должны отображаться в соответствующем виде. Уже эта функция позволяет существенно снизить “соблазн” что-то сделать с данными.
Подобный функционал можно реализовать несколькими способами: это трансформация данных при передачи их для отображения, ведение отдельных таблиц, или же встроенные функции СУБД, где могут задаваться соответствующие настройки.
- маскирование и изменение способа отображения данных
Еще ряд уязвимостей может возникнуть в результате передачи доступа к данным сторонним командам разработчиков, например, для тестирования каких-либо систем. Организация доступа к БД посредникам, несмотря даже на подписанные документы о неразглашении информации, несет в себе определенные риски.
Однако и реальные данные для отладки, однозначно, нужны, поэтому оптимальный вариант — замаскировать данные для определенных пользователей, поменять их отображение, чтобы записи в таком виде просто не были интересны для похитителей. На примере номера банковской карты: маскирование может быть реализовано как замещение символами 12 цифр из 16 в номере (например, “звездочкой”); другой способ изменения отображения — целенаправленная фальсификация, замена всех 16 цифр другими.
В отличие от функции, описанной выше, есть возможность маскирования данных без какой либо возможности восстановления. Такую “маскированную” базу можно спокойно передать разработчикам, подрядчикам, даже выложить в публичный доступ — никакого смысла данные не будут иметь.
Однако тут важно понимать, что при маскировании может быть нарушена целостность данных, поэтому сам процесс маскирования не так прост, как может показаться на первый взгляд.
Для реализации такого подхода стоит присмотреться к различным встроенным или внешним утилитам, которые позволят автоматизировать процесс маскирования.
- шифрование данных
Шифрование данных СУБД — еще одна возможность избежать утечек. Даже если зашифрованная база будет доступна извне, а в последствии будет украдена, без ключа данные нельзя расшифровать.
У шифрования данных есть обратная сторона — шифрование и дешифрование может негативно сказаться на производительности базы данных и связанных с ней приложений. Поэтому данный вопрос часто становится камнем преткновения между службой безопасности и разработчиками.
Мониторинг трафика, анализ запросов к БД
Очень часто злоумышленники пытаются получить доступ к БД через приложения, которые постоянно обращаются к базе. Наиболее популярный подход — так называемые SQL-инъекции: внедрение в обращения приложения к базе данных произвольного SQL-кода. Чаще всего такой код содержит запросы на выдачу прав или на получение набора данных. В качестве “лекарства” от внедрения неконтролируемого кода можно посоветовать закладывать защиту от SQL-инъекций в архитектуру приложений. Однако более надежным и эффективным подходом видится постоянный контроль трафика и мониторинг запросов к базе. Такой мониторинг, как правило, производится на стороне СУБД специальными инструментами семантического разбора обращений к БД и уведомляющими о появлении возможных SQL-инъекций.
За выявление SQL-инъекций отвечают программные продукты класса Database Firewall. Они накапливают статистику запросов, создавая “белые списки”, а также формируют “черные списки” (часто производители предлагают уже готовые варианты). Все подозрительные запросы в этом случае помещаются в карантинную зону и уже обрабатываются отдельно.
Расследование
Какими бы ни были средства защиты СУБД, всегда есть риск, что злоумышленник обойдет их, например, через “дыру” в защите приложения. Для сбора, хранения и анализа таких случаев в организации может использоваться отдельная база данных, в которой будут консолидироваться данные о всех действиях в целевой, защищаемой базе (т.н. Audit Vault). В случае возникновения инцидента, офицер безопасности сможет восстановить последовательность событий и расследовать происшествие, основываясь на журналах, хранящихся в базе Audit Vault.
Вывод
В данной статье мы описали лишь некоторые возможности защиты данных. Конечно же есть и другие способы, и мы будем рады вашим комментариям, а также если вы укажете на какие-то неточности с нашей стороны, и далее — мы сможем также описать другие способы защиты информации.
Главное, на что хочется обратить внимание: защиту данных нужно осуществлять на каждом контуре: и на внешнем (VPN, Антивирус, межсетевые экраны и пр.), и на среднем (распределение прав и контроль доступа), и на внутреннем — непосредственно на уровне базы данных!
Захаров Алексей, Директор по региональному развитию компания DBI (Россия)
