Курсовая работа: безопасность баз данных

Программа лояльности изнутри

Программа лояльности состоит из набора сервисов — это сайт и клиентское мобильное приложение, через которые можно делать заказы, а также интеграции с партнерами по доставке: Delivery Club, Яндекс.Еда и СберМегаМаркет.

Мобильные телефоны, ФИО и другие персональные данные с сайта, из мобильного приложения и от партнеров поступают в инфраструктуру ритейлера. СберМегаМаркет подключается напрямую к 1С, используя REST. Delivery Club и Яндекс.Еда отправляют их при помощи SOAP через отдельный шлюз.

Затем данные аккумулируются в базе Greenplum и по необходимости отправляются в Manzana. Это сервис для автоматизации и управления программами лояльности. Он нужен для подсчета баллов и выдачи скидок.

Решения по обеспечению безопасности БД

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

защита данных от неправомерного внешнего и внутреннего доступа;
предотвращение процессов удаления информации;
защита от программно-аппаратных ошибок, проблем с доступом к СУБД, из-за которых создается сложность или невозможность обработки данных, находящихся в БД.

Актуальность проблемы ИБ

В Российской Федерации ответственность за утечку данных планируют ужесточать. Уже принимаются меры по введению материальную ответственность для должностных лиц.

Вероятно, если по вине бизнеса в открытом доступе окажутся персональные данные клиентов или сотрудников, то руководство оштрафуют на 200–400 тысяч рублей, а то и больше.

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

Дмитрий Горлянский, руководитель направления технического сопровождения продаж компании «Гарда Технологии»:

Штатный аудит баз данных

Для проведения такого мониторинга многие организации пользуются «штатным аудитом» – средствами защиты баз данных, входящими в состав коммерческих СУБД. Штатный режим защиты включает ведение журнала подключения к СУБД и выполнения запросов теми или иными пользователями. Если коротко, принцип работы штатного аудита – это включение и настройка триггеров и создание специфичных функций – процедур, которые будут срабатывать при доступе к чувствительной информации и вносить данные о подобном доступе (кто, когда, какой запрос делал) в специальную таблицу аудита. Этого бывает достаточно для выполнения ряда отраслевых требований регуляторов, но не принесет практически никакой пользы для решения внутренних задач информационной безопасности, таких как расследование инцидентов.

Ключевые недостатки штатного аудита как защиты баз данных:

Дополнительная нагрузка на серверы баз данных (10-40% в зависимости от полноты аудита).
Вовлечение администраторов баз данных в настройку аудита (невозможность контроля администраторов – основных привилегированных пользователей).
Отсутствие удобного интерфейса продукта и возможности централизованной настройки правил аудита (особенно актуально для крупных распределенных компаний, в задачи защиты которых входит целый перечень СУБД).
Невозможность контроля действий пользователей в приложениях с трехзвенной архитектурой (наличие WEB и SQL-сегмента, что сейчас используется повсеместно из соображений безопасности).

Угрозы

Перед началом процесса формирования системы безопасности БД, специалисты должны оценить угрозы, учитывая ценность защищаемых данных, текущую практику неправомерного посягательства на БД. К наиболее актуальным угрозам можно отнести:

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

Основные принципы управления безопасностью БД

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

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

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

Решение Гарда БД

На российском рынке в классе DAM представлено решение «Гарда БД» от компании «Гарда Технологии».

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

Технические особенности продукта:

Возможность анализа трафика на скорости более 10 Гбит/с.
Возможность ретроспективного анализа по сохраненным данным объемом свыше 100 ТБ.
Полноценная работа с трехзвенной архитектурой взаимодействия с БД.
Интеграция со всеми популярными SIEM.
Минимальное влияние на производительность сети и серверов СУБД.
Встроенная система выявления аномалий и поведенческого анализа действий пользователей.
Возможность работы в территориально распределенных структурах из единой консоли управления.

Ключевые возможности Гарда БД:

Защита от утечек информации, хранящейся в БД.
Аудит всех операций с БД в режиме реального времени.
Контроль действий привилегированных пользователей.
Выявление и предотвращение попыток внешнего вторжения в СУБД.
Блокирование нежелательных запросов к БД и веб-приложениям.
Обнаружение всех БД в компании, их классификация и сканирование на уязвимости.
Обеспечение требований регуляторов в части безопасности данных СУБД.

Безопасность платформы и сети

Платформа для SQL Server включает в себя физическое оборудование и сетевые компьютеры, с помощью которых клиенты соединяются с серверами базы данных, а также двоичные файлы, применяемые для обработки запросов базы данных.

Физическая безопасность

Рекомендуется строго ограничивать доступ к физическим серверам и компонентам оборудования. Например, оборудование сервера базы данных и сетевые устройства должны находиться в закрытых охраняемых помещениях. Доступ к резервным носителям также следует ограничить. Для этого их рекомендуется хранить в отдельных охраняемых помещениях.

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

Сведения о	См.
SQL Server Compact и сетевой доступ к другим выпускам SQL Server	Раздел «Настройка и обеспечение безопасности среды сервера» в электронной документации по SQL Server Compact

Безопасность операционной системы

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

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

Сведения о	См.
Настройка брандмауэра для работы со службами SQL Server	Настройка брандмауэра Windows для доступа к компоненту Database Engine
Настройка брандмауэра для работы со службами Службы Integration Services	Службы Integration Services (службы SSIS)
Настройка брандмауэра для работы со службами Службы Analysis Services	Настройка брандмауэра Windows на разрешение доступа к службам Analysis Services
Открытие конкретных портов брандмауэра, чтобы предоставить доступ к SQL Server	Настройка брандмауэра Windows для разрешения доступа к SQL Server
Настройка поддержки расширенной защиты для проверки подлинности с помощью привязки каналов и привязки служб	Соединение с компонентом Database Engine с использованием расширенной защиты

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

Сведения о	См.
Службы, необходимые для SQL Server	Настройка учетных записей службы Windows и разрешений

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

Сведения о	См.
Безопасность служб IIS в SQL Server Compact	«Безопасность служб IIS» в электронной документации по SQL Server Compact
Службы Reporting Services Проверка подлинности	Проверка подлинности в службах Reporting Services
SQL Server Compact и доступ к службам IIS	«Блок-схема безопасности служб IIS» в электронной документации по SQL Server Compact

Безопасность файлов операционной системы SQL Server

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

Сведения о	См.
SQL Server программные файлы	Расположение файлов для экземпляра по умолчанию и именованных экземпляров SQL Server

SQL Server позволяют повысить безопасность. Для определения новейшего доступного пакета обновления для SQL Serverперейдите на веб-сайт SQL Server .

С помощью приведенного ниже скрипта можно определить установленный в системе пакет обновления.

Основные требования к безопасности БД

Уязвимости мы разделили (независящие и зависящие от данных). Теперь выделим независящие и зависящие от данных меры по обеспечения безопасности хранилищ.

Требования по безопасности к системе БД, не зависящей от данных:
1. Работа в доверенной среде. Доверенная среда — инфраструктура предприятия с её защитными механизмами, обусловленными политикой безопасности.
2. Обеспечение физической безопасности файлов данных. Здесь требования не отличаются от тех, которые применимы к любым другим файлам приложений и пользователей.

Требования к целостности информации для систем, зависящим от данных:
1. Безопасность пользовательского программного обеспечения. Речь идёт о задачах построения безопасных механизмов доступа и интерфейсов.
2. Безопасная организация работы с данными. Организация данных и управление ими — ключевой вопрос для системы хранения информации. Сюда входит и задача по организации данных с контролем целостности, и другие задачи, порой специфичные для СУБД.

Каковы особенности защиты БД?

Современные хранилища данных состоят из двух компонентов: хранимых данных (собственно, БД) и программ для управления (СУБД).

Обеспечить безопасность нельзя, не организовав безопасное управление данными. А значит, все уязвимости и вопросы защиты СУБД можно поделить на 2 категории: независящие и зависящие от данных.

Те уязвимости, которые от данных не зависят, характерны и для других видов программного обеспечения. Причина проблем тут разная — это и несвоевременное обновление, и недостаточная квалификация админа, и наличие неиспользуемых функций.

Однако практика показывает, что большая часть аспектов безопасности СУБД как раз-таки зависит от данных. К примеру, многие СУБД поддерживают запросы через некоторый язык, содержащий наборы функций, доступных пользователю. А архитектура используемых языков связана с моделью данных, которая применяется для хранения информации. В результате можно сказать, что модель отчасти определяет особенности языка, а особенности языка определяют наличие в нём определённых уязвимостей. При этом такие общие уязвимости, допустим, как инъекции, выполняются по-разному (Java-инъекция, SQL-инъекция) с учётом синтаксиса языка.

Методы оценки уязвимости

Уровень уязвимости БД к внешним и внутренним атакам, воздействиям оценивается с применением различных методов, чтобы установить степень обеспечения безопасности данных. Может использоваться ручное или автоматическое сканирование, основная цель которого – нахождение ошибок в программном коде, с помощью которых третьи лица могут неправомерно получить доступ к защищенной информации, скомпрометировать сеть.

Помимо сканирования, требуется постоянно мониторить инциденты кибербезопасности или изменение содержимого СУБД. Без системы эффективного мониторинга и сканирования организация не сможет пройти процедуру сертификации по ISO.

Работа решения Гарда БД

Анализ сетевого трафика с возможностью мониторинга или блокировки нелегитимных запросов пользователей и получаемых данных из СУБД.
Долгосрочное хранение всех запросов и ответов для ретроспективного анализа и проведения расследований.
Обнаружение неучтенных баз данных в сети.
Сканирование баз данных, находящихся под контролем и выявление мест хранения критической информации.
Автоматизированные отчеты.
Профилирование и поведенческий анализ (UBA).
Интеграция с SIEM-системами и другие способы оповещения.

Cloud Networks предлагает специальные условия по сотрудничеству для реализации защиты с нашим партнером «Гарда Технологии». Оставьте свою заявку для бесплатной консультации.

Как защищаются компании

Первое, что приходит в голову — обезличить данные. Их все равно придется защищать, но, по крайней мере, не придется беспокоиться о Роскомнадзоре.

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

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

Второй подход — раздельное хранение и обработка данных. Есть мнение, что если хранить, например, ФИО на одном сервере, а номера телефонов на другом, то можно выйти из-под действия 152-го Федерального закона и обойтись без оформления документации и установки дополнительных СЗИ. Так вот, это плохая идея.

Раздельная обработка данных делает архитектуру сложнее, дороже и уязвимее. Но главное — не защищает от требований Роскомнадзора.

С точки зрения регулятора, достаточно, чтобы хотя бы где-то в цепочке передачи данных встретились, например, имя и телефон

Неважно, что они разложены по разным базам и датацентрам. Если их можно сопоставить, значит, в информационной системе обрабатываются персональные данные

А иногда персональными данными могут признать и отдельные ФИО без какой-либо дополнительной информации.

Централизованная архитектура и грамотная система безопасности будут и проще, и надежнее.

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

Установка Гарды БД

Гарда БД — коробочное решение. Ее можно установить и настроить за неделю, но это в теории. На практике много времени уходит на сопутствующие работы: сбор сведений об инфраструктуре, согласование общего технического решения, оформление документации. Обычно на установку системы уходит около месяца. Так получилось и в этот раз.

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

К тому времени, как закончилось функциональное тестирование системы, мы как раз успели подготовить все остальное: обновили уже готовые документы, написали проектную документацию на систему, подобрали конфигурации ОС и СУБД, внедрили средства антивирусной защиты, которые необходимы по закону. Теперь и данные клиентов в безопасности, и Роскомнадзор носа не подточит.

Аспекты создания защищённых БД

Чтобы решить обозначенные проблемы и обеспечить информационную безопасность СУБД, надо перейти от практики закрытия уязвимостей к комплексному подходу, призванному обеспечить более эффективную безопасность хранилищ данных. Вот основные этапы перехода к этому:
1. Разработка комплексных методик, обеспечивающих безопасность хранилищ данных. Комплексные методики применяются как при разработке, так и при внедрении хранилищ данных и программного обеспечения. Следование такому подходу избавит от множества ошибок управления СУБД, поможет защитить данные от распространённых уязвимостей.
2. Оценка и классификация угроз СУБД. После классификации появляется возможность упорядочить угрозы и уязвимости с целью последующего анализа и обеспечения защиты. Специалисты по безопасности установят зависимость между проблемами и причинами их возникновения. Таким образом, после введения конкретного механизма в СУБД, администраторы и разработчики смогут спрогнозировать связанные с новым механизмом угрозы, а значит, заранее подготовят соответствующие средства по обеспечению безопасности.
3. Разработка стандартизированных механизмов обеспечения безопасности. С случае стандартизации языков работы с данными и подходов к защите появляется возможность создания средств безопасности, применимых к разным СУБД. На момент написания материала, к сожалению, речь идёт лишь о методических и теоретических средствах, так как появление уже готовых комплексных программных средств зависит лишь от разработчиков СУБД и производителей, точнее, от их желания следовать стандартам.

Материал подготовлен на основании статьи Полтавцевой М.А. «Безопасность баз данных: проблемы и перспективы».

Железо

За фильтрацию запросов в режиме реального времени приходится платить высокими требованиями к железу.

Анализатор трафика, рассчитанный на 2 гигабита/с — это пара процессоров по 16 ядер, например Intel Xeon Gold 6226R, 256 ГБ оперативной памяти и, обязательно, сетевая карта на Intel i350. Требования к чипсету объясняются тем, что для работы анализатора необходима поддержка DPDK.

Центр управления загружает работой 24 процессорных ядра, 256 ГБ оперативки и внушительный дисковый массив, никак не меньше RAID6 емкостью 20 ТБ. Там разворачивается графовая база данных, разработанная специально под эту систему.

При входящем трафике в 2 гигабита/с этого хватает на год хранения данных. Дело в том, что TCP-поток записывается по правилам и не в сыром виде. Анализатор очищает трафик. Даже если активировать политику тотального перехвата, в хранилище центра управления поступает около 30% того, что приходит на анализатор.

Для проекта с ритейлером хватило всего пары серверов. По меркам 2021 года это ниже среднего. Обычно требуется обрабатывать 5–8 гигабит/с, а самый крупный заказчик, у которого ставили эту систему, прогоняет через Гарду БД 20 с лишним гигабит трафика в секунду.

К счастью, и центр управления, и анализатор кластеризуются. Нужно обработать 20 гигабит — ставим 10 анализаторов, перевязываем ленточкой. То же самое с центром управления. При этом данные мониторинга попадают в единый веб-интерфейс и для пользователей системы ничего не меняется. Так что, когда программа лояльности вырастет, проблем с масштабированием не будет.

Проблемы безопасности БД

Киберпреступность развивается одновременно с базами данных и средствами защиты. Но, несмотря на это, за последние годы список главных уязвимостей СУБД мало изменился

Выполнив анализ архитектуры БД, известных уязвимостей, имеющихся средств обеспечения безопасности СУБД и прецедентов нарушения безопасности, можно отметить следующие причины появления проблем:
— разработчики баз данных, администраторы и программисты уделяют недостаточное внимание вопросам безопасности баз;
— разные СУБД применяют различные языковые конструкции доступа к данным, однако они организованы на основе той же модели;
— всерьёз занимаются проблемами безопасности лишь крупные производители СУБД;
— возникают новые модели хранения данных и их виды, сразу попадая в зону риска

Кроме того, ряд уязвимостей потенциально опасны из-за банального невнимания, а иногда даже и незнания администраторами систем БД вопросов безопасности

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

Для предприятий финансовым компромиссом является использование разных средств обеспечения информационной защиты, ведь внедрение продуктов повышенной защищённости и подбор высококвалифицированного персонала — это очень большие затраты. Однако стоит понимать, что компоненты безопасности могут оказывать на производительность СУБД негативное влияние.

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

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

Безопасность приложений

Клиентские программы

SQL Server рекомендуется разрабатывать защищенные клиентские приложения. Дополнительные сведения об обеспечении безопасности клиентских приложений на сетевом уровне см. в разделе Client Network Configuration.

Управление приложениями в Защитнике Windows (WDAC)

Управление приложениями в Защитнике Windows (WDAC) предотвращает попытки несанкционированного выполнения кода. WDAC является эффективным способом устранения угрозы со стороны вредоносных программ с исполняемыми файлами. Дополнительные сведения см. в подразделе документации Управление приложениями в Защитнике Windows.

Автоматизированные системы защиты баз данных

Более эффективный подход – использование специализированных систем информационной безопасности в области защиты бд – решений классов DAM и DBF.

Классификации – определение местонахождения критичной для компании информации. Опция позволяет, просканировав СУБД, увидеть названия таблиц и полей, в которых могут содержаться персональные данные клиентов

Это крайне важно для упрощения последующей настройки политик безопасности.

Проверки на уязвимости – соответствие конфигурации и настройки СУБД лучшим практикам.

Получение матрицы доступа к данным – задача решается для выявления расширенных привилегий доступа, неиспользуемым правам, и наличие так называемых «мертвых» учетных записей, которые могли остаться после увольнения сотрудника из компании.

Преимущество систем такого класса – гибкая система отчетности и интеграции с SIEM-системами большинства вендоров, для более глубокого корреляционного анализа выполняемых запросов.

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

В следующей статье мы более подробно рассмотрим задачи, которые часто стоят перед DAM-системами, расскажем, почему для DAM так важно умение работы с http/http’s трафиком и как обеспечить защиту от SQL инъекций.

Понятие базы данных

База данных – совокупность информационных материалов, которая представлена в объективной форме, систематизирована для упрощения поиска необходимых данных, обработана с использованием компьютерных технологий. Взаимодействие с базами данных происходит с помощью специализированных систем управления – СУБД. Содержимое баз данных описывается с использованием метаданных. Для БД обязательно наличие программной оболочки (наиболее востребованные: Access, MySQL, MS SQL Server, Oracle.

Выделяются следующие разновидности баз данных:

фактографическая;
документальная;
распределенная;
централизованная;
реляционная;
неструктурированная.