Мы развертываем простое веб-приложение для информационных бюллетеней на автономной платформе LAMP в DMZ компании. Существует некоторое обсуждение того, следует ли удалить сервер MySQL из DMZ и поместить во внутреннюю сеть.
Сервер находится за брандмауэром с открытым только портом 80, и MySql будет подключен к нестандартному порту. База данных содержит адреса электронной почты клиентов.
Это безопасная установка (или достаточно безопасная)? Насколько безопаснее было бы разместить данные за вторым брандмауэром? (Я в большей степени разработчик, поэтому я не совсем осведомлен обо всех аспектах безопасности - может кто-нибудь просветит меня!)
Обновить Просто для пояснения и для привлечения дополнительных комментариев вот наша текущая настройка:
Интернет - firewall1 - http сервер - firewall2 - appserver - firewall3 - ресурсы предприятия
Это новое приложение должно было быть полностью внутри DMZ между межсетевыми экранами 1 и 2. В настоящее время мы обсуждаем размещение сервера MySQL за вторым межсетевым экраном.
Разрешение подключений из DMZ во внутреннюю LAN нарушает концепцию DMZ.
Привязка MySQL к localhost будет не менее безопасной, чем размещение MySQL в другом месте. Если вас беспокоит кража данных, вы должны предположить, что если две машины разделены и часть Apache была скомпрометирована, то данные о соединении MySQL, хранящиеся на скомпрометированной машине, могут просто повторно использоваться злоумышленником для чтения данных в любом случае.
Отредактируйте, чтобы добавить:
Даже при использовании DMZ с двойным переходом, как вы описываете, вы не приобретаете никакого реального преимущества в плане безопасности от разделения служб, одновременно усложняя настройку. Возможно, вы даже увеличите поверхность атаки, увеличив количество машин и отправив данные по сети, которые в противном случае были бы в режиме обратной связи.
Я бы поместил БД во внутреннюю сеть (за вторым межсетевым экраном).
Это значительно снижает поверхность атаки БД, потому что вы устанавливаете правила брандмауэра для второго брандмауэра (DMZ на Internal) ТОЛЬКО на разрешение соединений через порт XXXX (порт DB) с веб-сервера.
Таким образом, даже если ваша DMZ скомпрометирована, ваша БД все равно будет защищена.
Сервер БД должен быть защищен брандмауэром от любых внешних подключений к Интернету, чтобы только сервер приложений (плюс все необходимое для администрирования) мог подключаться к базе данных. Если он отделен от сервера приложений - для этого есть разные причины - настройте брандмауэр и безопасность соответствующим образом.
Взлом сервера приложений, скорее всего, сделает учетные данные приложения доступными для злоумышленника БД, поэтому некоторый уровень безопасности БД или уровня приложения может помочь. Например, вы могли бы разделить обязанности в следующем порядке:
Настройте право собственности на объект БД, чтобы приложение не могло напрямую читать данные о клиентах, а выполняло хранимую процедуру. Полные номера кредитных карт можно было только записать - sproc может разрешить их обновление, но считывать только последние 4 цифры для экрана «детали обновления». Все, что нуждалось в номере CC, может находиться на другом сервере и подключаться через другую учетную запись.
Если управление финансами осуществляется на физически другом сервере (возможно, с брандмауэром, отключенным от общедоступного Интернета), то в лучшем случае вы можете выдавать фиктивные заказы или аналогичные, не подвергая действительный риск для сервера. Для получения информации о кредитной карте потребуется взломать две машины (сервер приложений и сервер БД или финансовый сервер). Вам также придется запустить атаку со скомпрометированного веб-сервера. Это дает вам более длительное окно для обнаружения активности, поскольку злоумышленник не может поставить под угрозу обе машины одновременно.
Серверы БД и финансовых серверов также имеют очень специфический набор взаимодействий с веб-сервером. Это позволяет предположить, что большая часть, если не вся деятельность, не связанная с приложениями, является подозрительной, и настроить IDS на этих машинах с ультрапараноидальной конфигурацией.
Я думаю, что часть MySQL была подробно рассмотрена, и я, конечно, согласен с тем, что уже было сказано. Я просто хотел бы отметить, что в качестве первого шага вы должны выяснить, каковы юридические требования в вашей части мира, поскольку они значительно различаются. Вполне возможно, что это определит вашу конфигурацию.
Давайте оценим два сценария и посмотрим, какой из них лучше. Я предполагаю, что вы настроили учетную запись MySQL, чтобы иметь доступ только для ЧТЕНИЯ / ЗАПИСИ к таблицам, специфичным для приложения.
Я атакую веб-сервер с помощью эксплойта нулевого дня. Теперь у меня есть доступ администратора к веб-серверу и полный доступ к локальной файловой системе. Я также могу отправлять сетевые сообщения, исходящие с этого веб-сервера. Я получил доступ к учетным данным, необходимым для доступа к базе данных приложения.
Если сервер базы данных находится на том же компьютере, теперь у меня также есть прямой и полный доступ к базе данных. Я могу читать и писать во все таблицы в базе данных, создавать новые и прослушивать все другие коммуникации с этим сервером базы данных. Оценка: Это худший сценарий. База данных приложения и все другие базы данных теперь затронуты.
Если сервер базы данных находится на другом компьютере в той же DMZ, я могу полностью общаться с сервером базы данных. Теперь я могу использовать эксплойт в службе общего доступа к файлам Windows, чтобы получить доступ администратора к этому серверу. Оценка: я могу получить доступ к серверу базы данных, используя учетную запись веб-приложения, но это может дать мне только ограниченные права. Мне нужен другой эксплойт, чтобы получить полный доступ к серверу базы данных. Я могу использовать любую службу, доступную на сервере базы данных.
Если сервер базы данных находится в совершенно другой сети, я могу получить доступ только к порту базы данных. Любое другое сообщение фильтруется брандмауэром. Это означает, что я могу использовать эксплойт в программе базы данных только для получения доступа администратора. Если я получу доступ администратора, вся внутренняя сеть будет скомпрометирована. Оценка: я могу получить доступ к серверу базы данных, используя учетную запись веб-приложения, но это может дать мне только ограниченные права. Я могу использовать порт базы данных только для получения полного доступа. Если я это сделаю, сеть сервера базы данных будет скомпрометирована.
Если компьютер скомпрометирован, не имеет значения, находится ли сервер MySQL в DMZ или нет. Учетные данные для доступа к базе данных MySQL будут где-то в коде веб-приложения, и машина в DMZ должна будет иметь к нему доступ, поэтому брандмауэры не будут обеспечивать безопасность ваших данных в этом случае.
Лучше всего, если бы веб-приложение написало очередь, которая затем загружается в базу данных MySQL внутри вашей защищенной сети. Это ограничит доступ данных о клиентах к тому, что находится в очереди. Просто думаю здесь вслух. Это может не работать или быть практичным для вашего конкретного приложения.
Вы не должны пропускать трафик из DMZ во внутреннюю сеть. Это действительно плохая идея! Если кто-то может получить контроль над вашим веб-приложением dmz, то можно будет открыть соединение с сервером внутри вашей внутренней сети и получить полный контроль над всей вашей сетью. Если вы хотите отделить веб-приложение от своей сети, я предлагаю вам создать еще одну DMZ и разместить там свою БД. Единственный трафик, разрешенный для другой DMZ i с вашего веб-сервера. Я видел несколько ужасных конструкций межсетевых экранов, и это один из них.
Хокан Винтер Старший администратор баз данных и бывший владелец охранной компании.