Среди систем управления базами данных, размещаемых на собственных и облачных серверах, к MySQL пользователи обращаются чаще всего. Эта СУБД компании Oracle распространяется на условиях свободной и коммерческой лицензий. Иногда термином MySQL называют не систему управления, а базу данных, работающую в таком формате управления, и это не является ошибкой. Нередко разработчики дорабатывают продукт под конкретное задание заказчиков.
Обеспечение безопасности баз данных MySQL является серьезной задачей.
Поскольку базы данных под управлением MySQL широко распространены, хакеры уже успели изучить все прорехи, существующие в стандартной системе защиты.
Основными узкими местами признаются:
Эти три зоны риска, создающие уязвимость при реализации целевых атак, должны быть защищены. При обычном функционировании БД рисков не возникает, дефолтный уровень безопасности баз данных MySQL оказывается достаточным. Но если модель угроз предполагает вероятность риска целевых атак, должны быть предприняты дополнительные меры защиты.
Модель построения защиты базы данных должна строиться, исходя из стандартных настроек и возможностей ПО.
При ее разработке следует принять во внимание следующие предпосылки:
Уровни обеспечения безопасности баз данных MySQL могут быть различными.
Для реализации максимально возможного уровня защиты конфигурация системы должна выглядеть следующим образом:
При выполнении этих условий защита станет эффективнее.
Базы данных часто страдают от действий инсайдеров: сотрудники после конфликта с руководством удаляют из БД критически важные данные, взламывают базу, чтобы украсть данные клиентов на продажу. Как защититься?
Вопрос инсталляции программы является ключевым в обеспечении ее безопасности. При выполнении этого процесса потребуется создать уникальную учетную запись пользователя и собственный корневой каталог. Необходимые команды можно найти в руководстве пользователя программы, скрипты также размещены в тематических сообществах. Отличия при защищенной инсталляции возникнут при необходимости внесения дополнительных параметров в раздел, посвященный конфигурации системы. Предлагаемые значения снижают риск того, что проникновение в базу данных произойдет с использованием смежно протекающих процессов. При установке файл конфигурации копируется, возникает необходимость выбрать его подвариант, исходя из предполагаемых размеров БД – малая, средняя, большая, грандиозная.
Далее запускается сервер и происходит проверка соединений с БД. После фиксации подключения работа базы данных MySQL останавливается и начинается решение задачи по обеспечению ее защиты. Если подключения не произошло, источник проблемы можно установить, изучив файл регистрации, который поможет ее устранить.
Здесь придется выполнить алгоритм, каждый шаг которого потребует наличия у системного администратора специальных знаний. Первым этапом станет создание для базы данных MySQL chrooted-среды. Создается уникальная структура каталога, задаются права доступа для всех лиц, которым будет разрешено администрирование базы данных. При создании структуры в нее копируются ключевые файлы системы (указаны в руководстве пользователя). Некоторые файлы сжимаются, в них сохраняются только учетные записи и группы.
Далее необходимо решить задачу с выбранной операционной системой. Все базы данных MySQL разработаны для ОС UNIX и созданных на ее базе систем. Но рекомендуем выбирать FreeBSD 4.7. Для нее разработано максимальное количество скриптов и команд, хотя они применимы и в более современных юниксоидах. Также в FreeBSD 4.7 можно создать базу данных паролей, что не получится сделать в других ОС.
Среди нюансов, которые нужно учесть:
После выполнения предварительных этапов можно протестировать, готова ли база данных MySQL к запуску и работе в chrooted-среде. После запуска этой команды могут возникнуть проблемы. Использование команды truss позволит выявить причину отказа в запуске и устранить ее.
Защита базы данных тесно связана с особенностями конфигурации сервера, этой задачей придется заняться в первую очередь. Так как программа управления базами данных предназначена для работы в chrooted-среде, необходимо использовать два файла конфигурации. Первый предназначен для самой базы данных MySQL, второй используется ее утилитами, такими как mysqladmin, mysql, mysqldump. Обе задачи потребуют изменения изначально заданной конфигурации сервера.
Далее предстоит решить задачу отключения удаленного доступа. Первым делом потребуется найти порт 3306/tcp, им утилиты MySQL пользуются по умолчанию. Порт может быть без проблем отключен, так как приложения PHP, установленные на сервере и предназначенные для обращения к базе данных, в нем не нуждаются. Такое отключение снизит риск целевых атак на информацию, содержащуюся в БД, при помощи TCP/IP-подключений, производимых с внешних серверов.
Иногда возможность удаленного подключения требуется сохранить, часто это нужно для обеспечения возможности удаленного сохранения и резервирования информации, содержащейся в БД. Для этого можно использовать возможности удаленного протокола SSH.
После решения задачи с удаленным доступом нужно улучшить защиту от проникновений на локальном уровне. Одним из решений является отключение возможности использования команды LOAD DATA LOCAL INFILE. Это позволит предотвратить возможность несанкционированного доступа к БД из локальной сети. Опция необходима, так как не исключено, что профессионалы рынка программ-взломщиков найдут очередную возможность доступа, и в PHP появится новая уязвимость к SQL-инъекциям. Под этим термином понимается внешнее внедрение в программное обеспечение произвольного SQL-кода, который позволяет генерировать запросы на несанкционированное прочтение, изменение или удаление информации, содержащейся в базах данных SQL. Для снижения степени этого риска потребуется изменение ряда параметров chrooted-среды, скрипты изменений доступны в широком перечне источников.
Следующий обязательный шаг – изменение параметров пароля администратора. При инсталляции базы данных он по умолчанию является пустым, и это создает существенную зону риска. Задать пароль можно только при запуске базы данных. Не советуем изменять пароли при помощи командной строки. Если с сервером и БД работает несколько пользователей, то те из них, в добросовестности которых есть сомнения, могут узнать измененный пароль, просмотрев файлы истории команд. Дополнительной мерой защиты станет ограничение прав доступа к этим файлам. Права администратора никогда не должны превышать тот объем, который необходим ему для выполнения рабочих его обязанностей. Любое расширение объема прав должно быть санкционировано.
Большинство известных злоумышленникам уязвимостей содержатся в стандартных форматах БД и таблицах, которые загружаются вместе с программой автоматически. Необходимо полностью удалить типовую базу данных (test) и стереть все учетные записи, кроме главной. Это полностью исключит риски, связанные с возможностями анонимных подключений и несанкционированного доступа к БД, также это снизит риски удаленных подключений.
Далее необходимо изменить имя в учетной записи администратора (изначально это поле пустое). Требуется ввести максимально сложное значение, это снизит риск лобовых, прямых атак на учетную запись и подбора имени путем простого перебора словарных значений. Если злоумышленнику придется подбирать сразу два параметра – имя учетной записи и пароль, это удлинит время атаки и повысит вероятность ее выявления.
Для снижения степени инсайдерских рисков необходимо следить за полным удалением файлов, сохраняющих историю ввода команд. Все содержание файла, связанное с изменением паролей и параметров учетной базы, удаляется, права на доступ к нему ограничиваются.
Для оптимизации работы базы данных MySQL требуется оптимизировать связь между ней и процессами PHP. Связь может стать проблемой после того, как база данных MySQL будет запущена в chrooted-среде. Это полностью исключает связь между БД и приложениями, поэтому каждый раз при запуске БД потребуется вводить команду, обеспечивающую нормальное соединение. При этом необходимо размещение утилит обоих программных продуктов в одной файловой системе.
На этом этапе следует еще раз провести ревизию прав доступа. Все администраторы, работающие с процессами PHP, должны иметь ограниченные права доступа к БД – только к тем ее участкам, которые непосредственно взаимодействуют с администрируемыми ими приложениями. Нельзя давать им доступ к администрированию самой БД и ее утилит. Доступ с возможностью использования таких привилегий администратора, как FILE, GRANT, ALTER, SHOW DATABASE, RELOAD, SHUTDOWN, PROCESS, SUPER должен быть исключен.
Для упрощения загрузки БД и во избежание необходимости каждый раз вручную вводить ряд команд, обеспечивающих ее работоспособность и связь с приложениями, необходимо прописать сценарий загрузки.
Итогом выполнения мер, призванных обеспечить высокий уровень защищенности БД, должно стать:
Эти меры позволят снизить уровень критических рисков, обезопасить базу данных от внешних вторжений и несанкционированного доступа внутренних пользователей.
Приведенные решения позволяют во многом обеспечить безопасность базы данных MySQL при работе с операционной системой UNIX и ее производными. Но нередко возникают ситуации, когда защитить БД требуется в среде Linux. Специально для этой операционной системы создан форк (параллельная версия, развивающаяся на базе материнской, но по самостоятельным принципам) базы данных MySQL. Он получил название MariaDB. Сейчас версии этой программы занимают первое место среди всех инсталлируемых программ с открытым кодом. Но, как и изначальная версия, этот вариант систем управления базами данных окажется небезопасным, если использовать настройки по умолчанию, предусмотренные в первичной конфигурации.
Изменение уровня защиты MariaDB повысит степень безопасности информационной системы в целом. Злоумышленники всегда первым делом сканируют известные им уязвимости, и программы управления базами данных относятся к основным целям. Стандартной ситуацией становится лобовое применение общего и неизмененного пароля root для взлома базы данных MySQL.
Исходя из понимания этих рисков, часто полностью совпадающих с рисками, принятыми за основу для материнской версии программы, для установки и безопасной работы с MariaDB потребуется применять следующие правила:
1. Обеспечить безопасную установку. Для этого необходимо установить новый пароль для учетной записи, изменив очевидный root, отключить удаленный вход для пользователя с этим именем, удалить все учетные записи анонимных пользователей. Далее проверить БД на исключение доступа неавторизованных пользователей.
2. Привязать базу данных только к локальному серверу, исключив возможность обращения к ней с удаленных хостов. Безопасность базы данных MySQL обеспечивается видоизменением основного файла конфигурации программы.
3. Отключить LOCAL INFILE – средство, с помощью которого сервер базы данных может запросить абсолютно любой файл у клиента базы данных. Это обеспечит безопасность БД, сократив возможность обращений к ней.
4. Изменить порт по умолчанию. В первоначально заданных настройках используется порт 3306, но системный администратор может заменить его на любой, не столь очевидный и удобный для работы. При отсутствии необходимости удаленных подключений можно вовсе отключить порт.
5. Подключить опцию ведения журнала MySQL. Это даст возможность протоколировать любые операции с БД, в том числе внешние атаки и попытки несанкционированных проникновений из локальной сети. Ведение журнала осуществляется введением переменных в файлы MySQL, уточнить их можно в руководстве пользователя.
6. Ограничить возможность изменения системных и содержащих информацию файлов базы данных MySQL, введя для каждого администратора и пользователя доступные ему разрешения и привилегии.
7. Удалить историю системной оболочки MySQL. Полностью очистить файл истории и сохраненные в нем команды, связанные с изменением конфигурации и ключевых параметров работы БД. Так же, как и для версии под UNIX, полностью отказаться от практики введения паролей при помощи командной строки. Установить собственный график очистки истории и неуклонно соблюдать его.
8. Командную строку нельзя использовать для ввода не только паролей, но и иных команд. Все они сохраняются в файле истории, и злоумышленник иногда может получить к ним доступ раньше, чем системный администратор очистит историю изменений.
9. На программном и административном уровне, во внутренних регламентирующих документах определить список пользователей, допущенных к администрированию базы данных и работе с ней. Для каждого приложения назначить соответствующие уровни доступа для тех пользователей, которые с ними непосредственно работают. После того как конкретный пользователь перестал работать с БД и приложениями, необходимо удалить его учетную запись.
10. Использовать дополнительные меры защиты, находить плагины и библиотеки, которые помогут поднять уровень безопасности базы данных MySQL. Среди наиболее популярных – подключаемые модули безопасности для аутентификации пользователей при подключении к серверу MySQL, модули проверки пароля и его защиты, специальные защищенные архивы-хранилища для конфиденциальной информации. Все модули требуется предварительно тестировать на совместимость.
11. Постоянно менять все пароли к каждой учетной записи. Регламентировать на административном уровне обязанность и график смены паролей. Если на сервере установлена невыявленная программа-шпион, регулярная смена паролей существенно затруднит ее работу по отслеживанию действий пользователей.
12. Регулярно обновлять все программное обеспечение, контролирующее работу базы данных MySQL. Для программ с открытым кодом это бесплатно, а новые версии, полученные из репозиториев, снимают часть рисков, заложенных в предыдущих, и затрудняют работу хакеров. После установки каждого обновления требуется перезапускать систему.
13. Постоянно изучать тематические форумы, посвященные нюансам работы системы. Продвинутые пользователи обращают внимание на новые и известные хакерам уязвимости и предлагают дополнительные меры защиты. При этом не стоит устанавливать новые решения без предварительного тестирования.
***
Выполнение рекомендаций специалистов, сочетание программных и организационных мер позволят обеспечить безопасность баз данных MySQL на высоком уровне. Наличие уязвимостей и надежность системы защиты зависит от информированности пользователей и профессионализма системных администраторов.
31.07.2020
Подпишитесь на нашу рассылку и получите
свод правил информационной безопасности
для сотрудников в шуточных