Брандмауэр + балансировщик нагрузки в качестве точки входа в кластер - что делать?

Мои два цента для вас.

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

Что бы я не делал.

Использование MySQL в контейнерах. Я знаю, что docker - отличное решение для развертывания, и с ним очень быстро справляются, но мой опыт работы с Docker + Database был не лучшим. Когда вы используете Docker для развертывания узлов MySQL, вы должны обеспечить внешнее постоянное хранилище для ваших файлов MySQL DB, что с неправильными дисками и сетевым оборудованием может легко стать проблемой, когда ваше приложение находится под высокой нагрузкой. Я предпочитаю иметь хорошую виртуальную машину (или больше, если необходимо), выделенную для БД, и использовать докер для создания множества серверов приложений, подключенных к этой БД. Это также решит вашу проблему с двумя типами виртуальных машин в docker swarm. Кроме того, поскольку вы используете марионетку, вы можете предоставить новый узел БД почти так же проще, как это сделал бы docker.

Что бы я сделал.

Это зависит только от того, насколько хорошо вы знакомы с инструментом и временем, чтобы узнать что-то новое. Если ваш сайт имеет низкий трафик <10 тыс. Запросов / с, Apache сразу станет хорошим инструментом для этой работы. Его легко настроить и поддерживать, и почти каждый знает, как с этим обращаться. По мере увеличения нагрузки вам следует искать более надежные решения. Я большой поклонник HAproxy. Пользуюсь им почти 6 месяцев, и мне это очень нравится. Он обслуживает как прокси / балансировщик L7 (как HTTP-прокси), так и L4 (как TCP-прокси, например, балансировщик нагрузки MySQL), имеет множество опций и намного легче, чем Apache. Это несложно, как только у вас возникнет идея, и вы сможете легко масштабировать ее для обработки множества соединений.

Как с Apache, так и с HAproxy вы можете использовать алгоритм балансировки нагрузки, распределяющий нагрузку между вашими узлами PHP. Вам, вероятно, понадобится Memcache / Redis для распределения сессий / кешей, и это совсем не сложно реализовать. Используя прокси-сервер в качестве дроссельной заслонки, вы также можете использовать его как TLS без нагрузки, уменьшая использование ваших узлов PHP.

Как и в вашем узле PHP, использование Apache и Ngnix зависит только от вас. Опять же, используйте инструмент, который у вас есть, и у вас есть знания и опыт. Оба являются отличными серверами для PHP.

Что касается вашей проблемы получения конфигураций узлами, ваши прокси также могут работать как шлюзы из вашей внутренней сети. Увеличение нагрузки будет минимальным (обычно вы вносите изменения на свой сайт по истечении рабочего времени). Если вам действительно нужно передать большое количество файлов / конфигураций, я предлагаю вам установить GIT / SVN или другой репозиторий, который вы используете на своем сайте. При таком подходе вам нужно только один раз передать файлы из DEV -> PRODUCTION, и использовать марионетку или любой другой инструмент для ваших серверов в вашей локальной сети. В зависимости от размера вашей среды это огромная победа.

И наконец, о безопасности. Вы всегда можете использовать старые добрые Iptables для удержания линии на ваших прокси и внутренних серверах, а также некоторый WAF (брандмауэр веб-приложений). Поскольку iptables разрешает соединения только через веб-порты (я бы отфильтровал ssh для набора определенных источников / туннелей внутри VPN), вашей поверхностью для атаки будет приложение. WAF может быть действительно проблематичным в реализации, но это способ. Вы также можете поискать устройства и проприетарные решения для этого. Централизуйте журналы своих приложений в чем-то вроде ELK или Gray Log и, прежде всего, отслеживайте все на предмет производительности и проблем, начиная с диска, памяти и использования диска, для связи и соединений на каждом прокси и сервере. Таким образом, вы можете оценить производительность своего сайта и спрогнозировать любое необходимое обновление (всегда готовьтесь к максимальной нагрузке) до того, как ваши клиенты начнут жаловаться. Мне нравится Zabixx за эту роль.

Надеюсь, это вам поможет.

[] `s

Какая твоя главная цель?

Производительность

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

Безопасность

Вы можете улучшить свою безопасность, добавив маршрутизатор перед прокси (профессиональный, недорогой или экономичный, но полнофункциональный, такой как ubiquiti, mikrotik и т. Д.). Вам нужно знать, как его настроить и защитить свою частную сеть. С точки зрения безопасности, лучше запускать ваши базы данных в контейнерах и потерять некоторую производительность. Вы также можете установить свой прокси в контейнерах. Я бы рекомендовал проверить Traefik который представляет собой простой в использовании прокси / балансировщик нагрузки. Вы правы, один сервер легче обслуживать, чем два.

Резервирование (отказоустойчивое)

Если вы хотите, чтобы не было простоев, вам нужно будет изменить свой дизайн. Вам нужно как минимум 2 роутера и настроить VRRP. Вам необходимо настроить привязку сетевого интерфейса и иметь как минимум 2 сервера (лучше больше). Вы настраиваете свои маршрутизаторы для отправки нечетных IP-адресов на один из серверов и даже IP-адресов на другой (таким образом, вам не нужно синхронизировать сеансы), и это будет балансировать нагрузку на ваши соединения. Вам понадобится способ синхронизации файлов с одного сервера на другой (в случае загрузки файлов и т. Д.). Рекомендую использовать унисон, однако я использую LXD вместо докера, поэтому я не уверен, сработает ли это в вашем случае. Для базы данных лучше иметь их в кластере, отметьте Галера с участием maxscale. Обычно для этого требуется как минимум 3 сервера, но можно запустить его и с 2 серверами, если вы используете Галера Арбитр

Это только один путь, есть много путей, и это мое личное решение.

ОБНОВЛЕНИЕ (о безопасности)

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

У меня есть еще несколько предложений, которые могут улучшить вашу настройку:

1) Защита данных: Пожалуйста, взгляните на Шифрование неактивных данных с помощью MariaDB. Это довольно простой способ зашифровать ваши данные. Основное преимущество этого заключается в том, что если файлы вашей базы данных скомпрометированы, они бесполезны без ключа. Если вы храните ключ в памяти, лучше, поскольку он не будет храниться в ваших снимках или резервных копиях, недостатком является то, что вам придется вводить этот ключ каждый раз при запуске базы данных. Этот метод шифрования не поможет вам, если у кого-то есть доступ к работающему экземпляру (что является наиболее распространенным способом взлома базы данных).

2) Приложения: Я предполагаю, что ваше самое слабое звено находится на уровне приложений. Вы должны быть уверены, что ваш код хорошо защищен и не уязвим для XSS, SQL-инъекций и т.п. Если вы не можете быть на все 100%, лучше храните важные данные как можно дальше от ваших приложений. Не забудьте добавить дополнительные уровни защиты (например, дополнительную аутентификацию, шифрование значений в базе данных и т. Д.).

3) Зашифрованные каталоги: Шифрование каталогов обычно полезно в тех случаях, когда сервер украден или кто-то получает доступ с пользователем без полномочий root.

4) Резервные копии: Следите за тем, где вы храните свои резервные копии и снимки. Они так же важны, как и ваши базы данных. Если ваши серверы заражены вымогателем (да это могло случиться в Linux тоже), ваши резервные копии могут помочь вам сэкономить время. Хорошая идея - хранить их в безопасном месте (ограниченном, зашифрованном и, если возможно, неизменном).

5) Локальная сеть: Убедитесь, что ваши серверы изолированы от вашей локальной сети. Не думайте, что ваша локальная сеть безопасна, поэтому не предоставляйте специальные разрешения для локальных клиентов. Относитесь к своему серверу так, как если бы он был изолирован в удаленном месте и доступен только через Интернет, так вы защитите только одну точку входа.

6) SSH: Если вы все еще используете порт 22 для ssh, измените его. Я бы рекомендовал использовать клиентские ключи в дополнение к паролю для ssh (и дополнительно для стука порта).

7) Пароли: Убедитесь, что вы храните все пароли на сервере в безопасности с помощью хорошо протестированного приложения для управления паролями. Неважно, сколько вы добавите в эту формулу безопасности, если ваш персональный компьютер взломан и эти пароли взломаны. Так что защитите свой персональный компьютер и серверы. (вы ведь используете надежные пароли?)

8) Бэкдор: Со мной несколько раз случалось, что я заблокирован! Так что имейте в виду, что это может случиться и с вами. Убедитесь, что если вы откроете дополнительный способ доступа к серверам, они будут такими же мощными, как и основной. Если у вас есть физический доступ к серверам, вам не нужно особо об этом беспокоиться.

9) Антивирус: Не верь слишком сильно clamAV. Это неплохая программа, но у вас просто не будет такой же защиты, как с коммерческим решением. Я использую его на своих почтовых серверах и на некоторых файловых серверах (Samba), чтобы блокировать известные вирусы Windows, но я не рассчитываю на него, когда дело касается новых угроз. Лучше не предполагать, что он защитит вас. Как вы знаете, есть очень маленький список известных вредоносных программ для Linux, поэтому, если у вас возникли проблемы с производительностью из-за clamAV, вероятно, он не сильно повлияет на вашу безопасность без него (если вы уже защищаете свой сервер многими другими способами). Если вам нужно коммерческое решение, Sophos и ESET - хорошие варианты. Если вы действительно хотите быть в курсе всех угроз для своих серверов, вы можете попробовать AlienVault (но для этого вам понадобится дополнительный сервер).

Ключевые вопросы: (Что произойдет, если кто-то ...)

* gains access to the DB through my applications?
* gains access the containers?
* gains access to the servers as user?
* gains access to the servers as root? <-- usually this is gameover
* stole the server?
* has access to the local network?
* gains access to my 'development' computer?

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

Оба предоставленных ответа великолепны.

Я хотел бы добавить здесь аспект безопасности.

Основная проблема ДОКЕР.

С докером ответственность за безопасность переходит от вас к команде разработчиков. Это называется DevOps.

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

Решением было бы обучить разработчиков их новой роли.

Поскольку это длительный и подверженный ошибкам процесс, лучше поддержать его соответствующими методами. Это называется (в контексте Docker) DevSecOps.

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

Это может помочь в переходном процессе.