Разделение служб может помочь, если сами серверы выйдут из строя, в том случае, если ваши резервные копии являются последними, вы сможете быстрее восстанавливать отдельные службы, или, таким образом, вы можете создать среду аварийного переключения (применимо, только если вы дублируете всю среду во второй раз, поэтому в конечном итоге с 6 серверами, так как каждый сервер должен иметь аварийное переключение), но это никоим образом не помогает против активных сетевых угроз и не повышает вашу безопасность.
Возникают такие вопросы:
- Как вы защищаете от хакерских угроз с этой настройкой? Если хакер проникнет на ваш веб-сервер и установит вредоносные сценарии для получения данных из вашей базы данных или какого-либо другого действия, разделение служб не поможет.
- Что у вас есть для борьбы с вторжениями и злонамеренными действиями, чтобы вообще их смягчить? Как правило, на границе вашей сети у вас есть IDS/IPS, а также брандмауэры для защиты от некоторых сетевых угроз, чтобы они на самом деле не стали проблемой.
- Вы не защищаете от DoS или DDoS с разделением услуг. Это снимет ваши сайты, будь то один сервер или десять.
- У вас все еще есть риск угона сервисов в каждой системе с помощью вредоносных скриптов. Область FTP может получить вредоносное ПО, которое затем атакует другие серверы, или может запустить вредоносный сценарий, чтобы помочь распространять вредоносное ПО другим, или может перехватить ваши системы для DDoS и атаковать другие системы. Сервер PHP может получать инъекцию кода, которая затем может атаковать другие системы. Ваш сервер базы данных может добавить к нему вредоносный код. Эти вещи - вещи, с которыми разделение серверов не поможет.
В конечном счете, хотя это может обеспечить преимущества для отработки отказа и более быстрого восстановления, если ваши серверы взрываются, при условии, что вы делаете хорошие резервные копии, дополнительных преимуществ не так уж много. Никаких реальных дополнительных преимуществ безопасности не возникает из-за разделения услуг. Конечно, вы получаете сервисы отдельно друг от друга, но это не добавляет дополнительной защиты от (буквально) тысяч векторов атаки.
Поправки:
Выбрав сайт Security Information SE, я исправляю свои заявления здесь:
- Любые веб-зоны открыты для риска атаки. В идеальном мире ваши PHP-приложения не смогут выполнять ничего, что они не должны делать. В реальном мире это не так, и существует множество способов атаковать сайты и сервисы PHP.
- Я не знаю вашу сетевую структуру. Я не знаю, все ли это VPS или все серверы (виртуальные или иные) за брандмауэром корпоративного уровня, где вы можете разделить внутренние коммуникации и ограничить сервер Apache/PHP, чтобы он был доступен из Интернета, но он может общаться только с вашими базами данных через определенные порты и тому подобное. Если у вас есть такая среда, и она все внутренняя, а не VPS, и вы можете разделить межсетевой экран, я бы пошел по пути разделения служб и обеспечил хорошее управление резервным копированием для всех серверов. Оттуда поместите Apache/MySQL в DMZ, доступную как изнутри, так и снаружи через веб-порты, а затем разрешите ограниченный обмен данными между серверами базы данных и Apache/MySQL.
- Я делаю предположения о том, что именно вы пытаетесь защитить. Если ваши серверы не находятся в среде корпоративного класса, вам нужно настроить каждый сервер на ограничение взаимодействия с другими. Если они все на VPS, а не на одной и той же сети, это умаляет безопасность, потому что ваши базы данных должны будут иметь прослушиватели, обращающиеся к сети, даже если вы ограничиваете, какие IP-адреса могут достигать их. Это делает более разумным просто хранить все на одном сервере и использовать локальные приемники для серверов баз данных.
- Есть буквально сотни тысяч угроз, которые могут быть проблемой. Если вы говорите об угрозах в целом, то нет никакой реальной разницы в безопасности, если вы все находитесь в одной подсети за брандмауэром корпоративного уровня. Если это VPS, разделение услуг может фактически отвлечь внимание от вашей безопасности.
В конечном счете, ваши возможности восстановления после сбоя зависят от наличия хороших резервных копий и наличия сервера резервного копирования, который вы можете очень быстро развернуть, чтобы заменить неисправный сервер. Безопасность - это совсем другое дело, и без какой-либо информации о том, с какими угрозами вы пытаетесь противостоять, нет реального способа дать полный ответ. Разделение сервисов - это начало, но на самом деле оно не обеспечивает такой дополнительной безопасности, и вы никогда не должны полагаться на безопасность разделения сервисов, чтобы защитить себя.
