Поиск по сайту:

Как вы должны защитить свою базу данных?

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

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

Обязательно запустите mysql_secure_installation

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

mysql_secure_installation

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

Заблокировать SSH

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

Вы можете прочитать наше полное руководство по безопасности SSH, чтобы узнать больше, но суть его состоит в нескольких шагах:

  • Отключите вход с паролем, используйте только ключи SSH.
  • Ограничьте количество неудачных попыток входа в систему с помощью denyhosts, чтобы предотвратить перебор.
  • Доступ к доверенным IP-адресам из белого списка.
  • Отключите вход в систему root через SSH, чтобы злоумышленники знали ваше имя пользователя.
  • Настройте многофакторную аутентификацию для SSH, если вы действительно параноик.

Запуск автономной базы данных в частной подсети

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

Настройка выглядит следующим образом:

Ваше виртуальное частное облако (VPC) — это просто контейнер, в котором работают все ваши ресурсы AWS. Объекты в этом облаке могут взаимодействовать друг с другом по своим частным IP-адресам точно так же, как взаимодействуют устройства в вашем доме.

Серверы в общедоступной подсети будут иметь общедоступные IP-адреса и будут доступны всем. Серверы в частной подсети не имеют общедоступных IP-адресов — только частный. Тем не менее, они все еще могут получить доступ к Интернету, используя преобразование сетевых адресов, тот же метод, который дает вашему компьютеру доступ за домашним маршрутизатором.

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

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

Чтобы MySQL принимал соединения только от частных соединений, вам нужно использовать сетевую маску в своем операторе GRANT. Это не работает с нотацией CIDR — только с полной сетевой маской.

GRANT ALL ON database.* TO 'user'@'10.0.1.0/255.255.255.0' IDENTIFIED BY 'password'

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

Привязать к локальному хосту, если это возможно (или, по крайней мере, к другому порту)

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

Если вы не можете привязаться к локальному хосту, рекомендуется изменить порт по умолчанию на что-то другое.

В любом случае, вы можете легко добиться этого, привязав MySQL к локальному хосту, что означает, что он будет прослушивать только петлевой адрес, а не какие-либо открытые порты. Откройте /etc/mysql/my.conf в вашем любимом текстовом редакторе и добавьте следующую строку в раздел [mysqld] :

bind-address = 127.0.0.1

Вы также можете изменить порт по умолчанию в этом же разделе:

Port=5000

Перезапустите MySQL, и вы должны увидеть изменения.

Следите за историей своей оболочки

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

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

mysql -u root -p

В противном случае его можно просмотреть с помощью команды history .

MySQL также имеет свой собственный файл истории, хранящийся в ~/.mysql_history. Это, очевидно, не регистрирует пароль, который вы используете для входа в систему, но если вы создали нового пользователя из командной строки MySQL, этот оператор будет зарегистрирован — пароль и все остальное. Вы захотите очистить этот файл в качестве меры предосторожности, если вам когда-либо придется изменять учетные записи пользователей.

# cat /dev/null > ~/.mysql_history

Если вы используете AWS, рассмотрите возможность использования RDS

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

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

Вы по-прежнему будете использовать стандартную аутентификацию имени пользователя и пароля MySQL для подключения к самой базе данных — IAM просто защищает все остальное в базе данных, например, конфигурацию. Однако вы можете использовать диспетчер секретов AWS, который позволяет постоянно менять ключи безопасности без повторного развертывания кода и имеет встроенную интеграцию для загрузки RDS.

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