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

Одна из причин кроется в том, что редко когда защите БД уделяется должное внимание. Согласно данным IDC, из 27 миллиардов долларов, выделяемых на корпоративную безопасность, менее 5% уходит на меры защиты центра хранения данных.

Хакеры и злоумышленники-инсайдеры, получив доступ к важной информации, могут ей воспользоваться для обогащения, нанести ущерб компании или повлиять на ведение бизнеса. Помимо финансовых убытков и урона репутации, взлом базы данных может повлечь за собой санкции регуляторов, штрафы и т.д. Однако согласно исследованиям, проведенным в 2013 году Online Trust Alliance (OTA), более 97% инцидентов можно было предотвратить, следуя следующим рекомендациям и мерам внутреннего контроля.

Угрозы, которые рассматриваются в данной статье, актуальны не только для традиционных БД, но и для решений Big Data. Несмотря на то, что в Big Data не используется язык запросов SQL, для этой сферы остаются актуальными классические точки внедрения SQL-инъекций, такие как поля ввода. Эксплуатируя эти уязвимости, хакеры получают доступ к компонентам Big Data. В подразделе данной статьи, посвященном инъекциям в поле ввода (Input-инъекциям), описаны основные понятия об этом способе атаки на Big Data.



Десятка важнейших угроз безопасности баз данных по итогам 2015 года


1. Чрезмерные и неиспользуемые пользовательские привилегии

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

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


2. Злоупотребление привилегиями

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


3. Input-инъекции (инъекции в поле ввода)

Существует два основных способа взлома баз данных при помощи инъекций кода:

  1. SQL-инъекции, применяемые для взлома традиционных СУБД;
  2. NoSQL-инъекции, которые используются для взлома платформ Big Data. SQL-инъекции обычно представляют собой внедрение (инъекцию) неразрешенного или вредоносного кода в поля ввода веб-приложений. Инъекции типа NoSQL подразумевают внедрение вредоносного кода в компоненты Big Data (например, в Hive или MapReduce).

В обоих случаях успешно проведенная инъекция может дать хакеру неограниченный доступ ко всему содержимому базы данных. Важный момент: несмотря на то, что технически решения Big Data являются неуязвимыми для SQL-инъекций, потому что в них не применяется язык SQL, они подвержены атакам, основанным на аналогичных принципах (т.е. input-¬инъекциям).


4. Хакерские программы

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


5. Недостаточные меры по аудиту данных.

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

Организации, располагающие слаборазвитыми механизмами аудита баз данных (или не имеющие их вовсе), в конце концов, обнаруживают, что их система безопасности не соответствует отраслевым и государственным требованиям по безопасности данных. Например, закон Сарбейнса-Оксли (SOX), определяющий меры, направленные на предотвращение ошибок и махинаций в сфере финансовой отчетности, и медицинские стандарты HIPAA – это наиболее очевидные примеры регуляторных актов, устанавливающих четкие требования по аудиту баз данных.

Многие организации используют встроенные в СУБД средства аудита, полагаются на узкоспециализированные решения или проводят аудит в ручном режиме. Однако возможности таких инструментов ограничены – они не позволяют проводить полноценный аудит, выявлять попытки взлома и проводить расследования. Более того, встроенные в СУБД средства часто оказывают излишнюю нагрузку на процессор и жесткий диск сервера, поэтому во многих случаях функция аудита просто отключается. Наконец, большинство встроенных решений работают лишь на одной, предназначенной для них, платформе. Так, логи Oracle отличаются от логов MS-SQL, а логи MS-SQL отличаются от логов DB2. Это значительно осложняет внедрение однородного, масштабируемого механизма аудита в организациях, оперирующих СУБД различного типа.

Когда для работы с базой данных используются корпоративные веб-приложения (такие как SAP, Oracle E-Business Suite или PeopleSoft), сложно связать конкретные операции в отношении БД с конкретными сотрудниками. Большинство встроенных инструментов аудита не способны определить конечного пользователя, поскольку ассоциируют активность БД с учетными записями клиентских приложений. Отсутствие связи с пользователем, совершившим ту или иную операцию, препятствует ведению отчетности, возможности наблюдения и проведению расследований. К тому же, пользователи, обладающие правами администратора БД (легитимными или полученными в результате взлома), могут отключить встроенный аудит, чтобы скрыть свою вредоносную активность. Именно поэтому необходимо разграничивать функции управления аудитом и администрирование БД и серверной платформы, чтобы добиться четкого разделения зон ответственности.


6. Незащищенность носителей информации.

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

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


7. Эксплуатация уязвимых, неверно сконфигурированных баз данных.

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

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

Согласно исследованию по защите корпоративных данных, проведенному Independent Oracle User Group (IOUG) в 2014 году, 36% пользователей СУБД Oracle в течение более полугода не устанавливают патчи, а 8% вообще этого не делают.


8. Неуправляемая конфиденциальная информация

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


9. Отказ в обслуживании (DoS).

DoS – это способ атаки информационной системы, в результате которой легитимные пользователи теряют доступ к сетевым приложениям или информации. Существуют различные способы создания DoS-условий. Наиболее популярным способом проведения DoS-атаки на базу данных является провокация перегрузки аппаратных ресурсов сервера, таких как память и процессор, путем его бомбардировки чрезмерно большим количеством запросов или меньшим по количеству запросов, но на обработку которых требуется непропорционально много системных ресурсов (например, если эти запросы направлены на проведение рекурсивных операций или операций с таблицами). В обоих случаях DoS-атака приводит к одному результату: сервер, столкнувшись с недостатком системных ресурсов, отказывает своим пользователям в обслуживании и в некоторых случаях даже «падает».

Мотивом DoS-атак часто является вымогательство: злоумышленник вызывает «падение» серверов до тех пор, пока жертва не удовлетворит его требования. Какими бы ни были причины нападения, DoS-атаки представляют собой серьезную угрозу для многих организаций.


10. Недостаток знаний и опыта в сфере информационной безопасности.

Развитие средств внутренней безопасности не успевает за ростом объемов данных, при этом многие организации слишком плохо оснащены и подготовлены для противодействия угрозам. Причиной этого часто является недостаток опыта и квалификации сотрудников в применении решений, улучшении политик или реагировании на инциденты в сфере безопасности. Так, согласно отчету Ponemon Institute за 2014 год, посвящённому экономическому эффекту утечек данных, в 30% случаев основной причиной утечки данных являлся «человеческий фактор», иными словами, халатный сотрудник или подрядчик.



Классификация решений для защиты баз данных

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

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

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


1. Средства обнаружения и оценки.


1.1 Проводите поиск уязвимостей.

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

Слабые механизмы аутентификации позволяют хакерам проводить DoS-атаки на уровне приложений, поскольку открывают беспарольный доступ к БД. Используйте специализированные программы для выявления уязвимостей, ошибок в конфигурациях и отсутствующих патчей. Оценка должна основываться на существующих отраслевых стандартах безопасности, таких как DISA STIG и CIS.


1.2 Определяйте степень риска.

Величина риска зависит от степени критичности уязвимостей для базы данных и конфиденциальности информации. При оценке критичности следует использовать известные алгоритмы расчета, такие как Common Vulnerability Scoring System (CVSS).

Знание величины риска помогает выделять приоритетные риски и исследовать вызывающие их уязвимости. В данном случае высокие степени риска обусловлены уязвимостью к input-инъекциям.


1.3 Снижайте критичность уязвимостей.

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

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


1.4 Идентифицируйте уязвимые БД.

Проводите анализ рисков и выделяйте приоритетные действия по устранению угроз. Отчеты и аналитические данные помогают оценить риски и выделить приоритетные направления работы по устранению уязвимостей.


1.5 Проводите поиск серверов БД.

Для того чтобы построить, обслуживать ваши системы хранения данных и изолировать содержащуюся в них конфиденциальную информацию, необходимо в первую очередь создать каталог доступных БД. Используйте специальные решения по поиску и обнаружению для сканирования корпоративной сети и идентификации активных БД. Отдавайте предпочтение решениям, снижающим время сканирования благодаря применению фильтрации по IP-адресам и диапазонам IP-адресов, а также фильтрации по конкретным типам БД (например, Oracle, MS-SQL, IBM DB2 и т.д.). Периодически проводите повторное сканирование для обнаружения новых баз данных или изменений в старых.


1.6 Анализируйте результаты поиска.

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

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


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

Отдавайте предпочтение решениям, способным работать с пользовательскими типами данных.

Результаты классификации должны содержать IP-адрес и имя хоста БД и указывать на наличие в ней конфиденциальных данных. Автоматическая идентификация конфиденциальных данных и персональной информации помогает точнее направлять усилия по защите и соответствию стандартам.


1.8 Управление правами доступа.

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


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

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


1.10 Идентифицируйте и устраняйте излишние привилегии и неактивные учетные записи.

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


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

Проверяющие должны подтверждать, отклонять права или передавать их на проверку другому лицу, а администраторы могут следить за ходом проверки. При проверке прав пользователей необходимо руководствоваться принципом минимальной осведомленности, что позволит соблюдать требования по безопасности данных и сократить возможные риски. Используйте решения, известные как Universal User Tracking (UUT), для сопоставления информации о пользователях с операциями, проводимыми в отношении БД. Результаты проверки могут включать в себя уникальные имена пользователей клиентских приложений.


2. Мониторинг и блокирование


2.1 Применяйте оповещение и блокирование в режиме реального времени.

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


2.2 Выявляйте аномальную активность.

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


2.3 Блокируйте вредоносные веб-запросы.

Поскольку веб-приложения являются одной из наиболее популярных целей атаки с помощью input-инъекций, еще одной важной линией обороны станет ваш файрволл для веб-приложений (Web Application Firewall, WAF). WAF распознает и заблокирует попытки воздействия input-инъекциями на веб-приложения. Для защиты от input-инъекций WAF должен выполнять следующее:

  • Проверять значения параметров HTTP на наличие специальных символов, таких как апострофы и скобки, и определять, свидетельствуют ли данные символы о проведении атаки.
  • Учитывать сигнатуры приложений и политики известных паттернов input-инъекций при принятии решений об оповещении и блокировании.

2.4 Проводите мониторинг активности локальной БД.

Решения класса DAP (Database audit and protection, аудит и защита БД) могут проводить аудит и мониторинг активности ваших наиболее привилегированных пользователей – администраторов БД и системных администраторов. Эти пользователи получают наиболее полный доступ к вашим БД и поэтому требуют особого внимания. Независимо от того, злоупотребили ли они своими правами или их учетные записи были взломаны, риск кражи данных и нанесения урона вашей организации возрастает. Внедрите меры по контролю соединений.


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

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


2.6 Согласованность ответов.

DoS-атака на БД, направленная на перегрузку ресурсов сервера, приводит к задержке отклика БД. Сюда относятся как задержки ответов на отдельные запросы, так и «торможение» системы в целом. Используйте решения, которые в случае задержки отклика проводят мониторинг времени реакции системы и генерируют уведомления.


3. Аудит


3.1 Автоматизируйте аудит при помощи платформы DAP.

Внедрите решение DAP в наиболее требовательных средах. Решение DAP лишено большинства недостатков, свойственных интегрированным в БД средствам аудита.


3.2 Разграничение обязанностей.

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


3.3 Кроссплатформенный аудит.

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


3.4 Быстродействие и эффективность.

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

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

Применяйте правила аудита для сбора информации, необходимой для выполнения требований таких стандартов безопасности, как SOX, PCI DSS и HIPPA, или для соответствия внутренним стандартам аудита.


3.5 Генерируйте отчеты для оценки регуляторами и криминалистами.

Оформляйте отчёты об активности БД, которые помогут удовлетворить требования регуляторов, проводить расследования злоупотреблений, собирать важную статистику и проводить мониторинг быстродействия системы. Внедряйте DAP-решения, способные вести отчётность согласно государственным и отраслевым стандартами и подстраиваться под требования бизнеса при необходимости.


4. Защита данных


4.1 Архивируйте внешние данные.

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


4.2 Применяйте шифрование к базам данных.

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


5. Меры безопасности нетехнического характера


5.1 Задействуйте опытных специалистов по информационной безопасности.

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


5.2 Обучайте своих сотрудников

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

Комментарии