Защита информации от несанкционированного доступа

Защита подключений

  • эквивалентен ли один бизнес-пользователь одному пользователю СУБД;
  • обеспечивается ли доступ к данным СУБД только через API, который вы контролируете, либо есть доступ к таблицам напрямую;
  • выделена ли СУБД в отдельный защищенный сегмент, кто и как с ним взаимодействует;
  • используется ли pooling/proxy и промежуточные слои, которые могут изменять информацию о том, как выстроено подключение и кто использует базу данных.
  1. Используйте решения класса database firewall. Дополнительный слой защиты, как минимум, повысит прозрачность того, что происходит в СУБД, как максимум — вы сможете обеспечить дополнительную защиту данных.
  2. Используйте парольные политики. Их применение зависит от того, как выстроена ваша архитектура. В любом случае — одного пароля в конфигурационном файле веб-приложения, которое подключается к СУБД, мало для защиты. Есть ряд инструментов СУБД, позволяющих контролировать, что пользователь и пароль требуют актуализации. Почитать подробнее про функции оценки пользователей можно здесь, так же про MS SQL Vulnerability Assessmen можно узнать тут. 
  3. Обогащайте контекст сессии нужной информацией. Если сессия непрозрачная, вы не понимаете, кто в ее рамках работает в СУБД, можно в рамках выполняемой операции дополнить информацию о том, кто, что и зачем делает. Эту информацию можно увидеть в аудите.
  4. Настраивайте SSL, если у вас нет сетевого разграничения СУБД от конечных пользователей, она не в отдельном VLAN. В таких случаях обязательно защищать канал между потребителем и самой СУБД. Инструменты защиты есть в том числе и среди open source.

Как это повлияет на производительность СУБД?

Тест 1 без SSL и с использованием SSL

vs

Тест 2 без SSL и с использованием SSL

vs

Остальные настройки

Результаты тестирования

  NO SSL SSL
Устанавливается соединение при каждой транзакции
latency average 171.915 ms 187.695 ms
tps  including connections establishing 58.168112 53.278062
tps excluding connections establishing 64.084546 58.725846
CPU 24% 28%
Все транзакции выполняются в одно соединение
latency average 6.722 ms 6.342 ms
tps including connections establishing 1587.657278 1576.792883
tps excluding connections establishing 1588.380574 1577.694766
CPU 17% 21%

SQLBase компании Gupta предлагает надежные средства защиты

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


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

Утилиты, которые перебирают огромные объемы паролей, очень эффективно блокируются.

Ограничение доступа к данным

  1. Шифрование и обфускация процедур и функций (Wrapping) — то есть отдельные инструменты и утилиты, которые из читаемого кода делают нечитаемый. Правда, потом его нельзя ни поменять, ни зарефакторить обратно. Такой подход иногда требуется как минимум на стороне СУБД — логика лицензионных ограничений или логика авторизации шифруется именно на уровне процедуры и функции.
  2. Ограничение видимости данных по строкам (RLS) — это когда разные пользователи видят одну таблицу, но разный состав строк в ней, то есть кому-то что-то нельзя показывать на уровне строк.
  3. Редактирование отображаемых данных (Masking) — это когда пользователи в одной колонке таблицы видят или данные, или только звездочки, то есть для каких-то пользователей информация будет закрыта. Технология определяет, какому пользователю что показывать с учетом уровня доступа.
  4. Разграничение доступа Security DBA/Application DBA/DBA — это, скорее, про ограничение доступа к самой СУБД, то есть сотрудников ИБ можно отделить от database-администраторов и application-администраторов. В open source таких технологий немного, в коммерческих СУБД их хватает. Они нужны, когда много пользователей с доступом к самим серверам.
  5. Ограничение доступа к файлам на уровне файловой системы. Можно выдавать права, привилегии доступа к каталогам, чтобы каждый администратор получал доступ только к нужным данным.
  6. Мандатный доступ и очистка памяти — эти технологии применяют редко.
  7. End-to-end encryption непосредственно СУБД — это client-side шифрование с управлением ключами на серверной стороне.
  8. Шифрование данных. Например, колоночное шифрование — когда вы используете механизм, который шифрует отдельную колонку базы.

Как это влияет на производительность СУБД?

Проведем тест c pgcrypto

Выборка из таблицы без функции шифрования

Время: 1,386 мсВыборка из таблицы с функцией шифрования:

Время: 50,203 мсРезультаты тестирования

  Без шифрования Pgcrypto (decrypt)
Выборка 1000 строк 1,386 мс 50,203 мс
CPU 15% 35%
ОЗУ   +5%

Пример такого шифрования в MongoDB

Аудит действий

  • default log — встроенное логирование;
  • extensions: pgaudit — если вам не хватает дефолтного логирования, можно воспользоваться отдельными настройками, которые решают часть задач.

Дополнение к докладу в видео:*

Как это повлияет на производительность СУБД?

postgresql.conf

log_destination = ‘stderr’ logging_collector = on log_truncate_on_rotation = on log_rotation_age = 1d log_rotation_size = 10MB log_min_messages = debug5 log_min_error_statement = debug5 log_min_duration_statement = 0 debug_print_parse = on debug_print_rewritten = on debug_print_plan = on debug_pretty_print = on log_checkpoints = on log_connections = on log_disconnections = on log_duration = on log_hostname = on log_lock_waits = on log_replication_commands = on log_temp_files = 0 log_timezone = ‘Europe/Moscow’

Результаты тестирования:

Без логирования С логированием
Итоговое время наполнения БД 43,74 сек 53,23 сек
ОЗУ 24% 40%
CPU 72% 91%
Тест 1 (50 коннектов)
Кол-во транзакций за 10 мин 74169 32445
Транзакций/сек 123 54
Средняя задержка 405 мс 925 мс
Тест 2 (150 коннектов при 100 возможных)
Кол-во транзакций за 10 мин 81727 31429
Транзакций/сек 136 52
Средняя задержка 550 мс 1432 мс
Про размеры
Размер БД 2251 МБ 2262 МБ
Размер логов БД 0 Мб 4587 Мб
  • Скорость сильно не меняется: без логирования — 43,74 сек, с логированием — 53,23 сек.
  • Производительность по ОЗУ и CPU будет проседать, так как нужно сформировать файл с аудитом. Это также заметно на продуктиве.
  • данных много;
  • аудит нужен не только через syslog в SIEM, но и в файлы: вдруг с syslog что-то произойдет, должен быть близко к базе файл, в котором сохранятся данные;
  • для аудита нужна отдельная полка, чтобы не просесть по I/O дисков, так как он занимает много места;
  • бывает, что сотрудникам ИБ нужны везде ГОСТы, они требуют гостовую идентификацию.

Обязательные требования к системе ИБ безналичных платежей

  • внедрение передовых практик по управлению IT и инфраструктурой;
  • создание комплексной системы защиты информации.
Защита персональных данных. Основание – в платежных документах есть персональные данные (Ф.И.О. плательщика / получателя, его адрес, реквизиты документа, удостоверяющего личность)
Федеральный закон «О персональных данных» от 27.07.2006 № 152-ФЗ КоАП РФ Статья 13.11, КоАП РФ Статья 13.12 – до 75 тыс. руб. штраф.,УК РФ Статья 137 – до 2 лет лишения свободы
Постановление Правительства РФ от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»
Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных» (Зарегистрировано в Минюсте России 14.05.2013 N 28375)
Указание Банка России от 10 декабря 2015 г. № 3889-У «Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных”
Обеспечение защиты информации в национальной платежной системе. Основание – кредитная организация, выполняющая переводы денежных средств, является частью национальной платежной системы.
Федеральный закон «О национальной платежной системе» от 27.06.2011 № 161-ФЗ
Постановление Правительства РФ от 13.06.2012 № 584 «Об утверждении Положения о защите информации в платежной системе»
Положение Банка России от 9 июня 2012 г. N 382-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств»
Положение Банка России от 24 августа 2016 г. № 552-П «О требованиях к защите информации в платежной системе Банка России»
Эксплуатационная документация на СКЗИ СКАД Сигнатура
Обеспечение безопасности критической информационной инфраструктуры Российской Федерации. Основание – банк в силу п.8 ст. 2 ФЗ от 26.07.2017 № 187-ФЗ является субъектом критической информационной инфраструктуры
Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» УК РФ Статья 274.1 – до 8 лет лишения свободы
Постановление Правительства РФ от 08.02.2018 N 127 »Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»
Приказ ФСТЭК России от 21.12.2017 N 235 «Об утверждении Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования» (Зарегистрировано в Минюсте России 22.02.2018 N 50118)
Приказ ФСТЭК России от 06.12.2017 N 227 «Об утверждении Порядка ведения реестра значимых объектов критической информационной инфраструктуры Российской Федерации» (Зарегистрировано в Минюсте России 08.02.2018 N 49966)
Указ Президента РФ от 22.12.2017 N 620 «О совершенствовании государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации»
Требования по защите информации, установленные договором об обмене электронными сообщениями при переводе денежных средств в рамках платежной системы Банка России. Основание – данный договор заключают все кредитные организации для электронного обмена платежными документами с Банком России.
Типовой договор обмена ЭС с приложениями. Документация на АРМ КБР, УТА (требования их использовании отражены в п.1. Приложения 3 к Договору) п. 9.5.4 Договора – одностороннее расторжение договора по инициативе Банка России.
  1. СТО БР ИББС. Стандарт и комплекс сопутствующих документов имеет силу только в случае его добровольного принятия кредитной организацией.
  2. PCI DSS. Стандарт будет действовать, только если в платежных документах передаются полные не маскированные номера платежных карт (PAN).
  3. Корпоративная политика информационной безопасности. Требования актуальны для больших банковских групп, где единая политика ИБ устанавливается в отношении всех банков группы и где каждый банк должен разрабатывать на ее базе внутренние документы.

АВЗ.1АВЗ.2Письмо Банка России от 24.03.2014 N 49-ТЗИС.17

Безопасность между локальными сетями компании


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

Вместо этого данные передаются через сети с протоколом IP или другие сети общего пользования, предоставляющие хакерам широкие возможности для атак. У каждого сервера имеется свой IP-адрес; чтобы обнаружить эти адреса, достаточно перехватить информацию на пути прохождения пакетов между двумя поддерживающими связь системами. Затем хакер может записать все данные, передаваемые между адресами отправителя и получателя. Поэтому с помощью кодировки данных можно обеспечить защиту от атак на существующие сетевые подключения к внешним системам: лицо без права доступа не сможет перехватить данные, передаваемые между двумя базами данных, не взломав код.

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

Ответственность пользователей


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

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

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

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


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

Резюме

Для удовлетворения различных потребностей требуются различные базы данных. Каждая база данных, рассмотренная в этой статье, имеет свои определенные преимущества. Для защиты больших систем с большим числом пользователей продукты компании Sybase видимо имеют преимущество перед Microsoft SQL Server и Oracle. Для встроенных баз данных и баз данных для рабочей группы Gupta SQLBase предлагает лучшую защиту из доступных в настоящее время.

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


С этим читают