Назад | Перейти на главную страницу

Обсуждение нашей сетевой структуры (DMZ, база данных, сервис)

Мы пытаемся решить, где разместить разные серверы. Должны ли мы поместить их в DMZ? В нашей зоне доверенной сети? И так далее ... На эту тему написано много, но, похоже, есть разные мнения о том, разрешать ли доступ из DMZ к серверу базы данных во внутренней сети. Хотелось бы узнать ваше мнение о наших мыслях.

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

«Служба приложений (WCF)» - это, по сути, наша точка входа в базу данных, содержащая всю бизнес-логику и проверяющую, все ли в порядке, перед тем, как зафиксировать ее в базе данных. Здесь также есть служба только для чтения, оптимизированная для запросов к базе данных.

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

  1. Служба приложений и сервер базы данных во внутренней сети, защищенные брандмауэром, позволяют только внешнему веб-серверу и службе напрямую подключаться к службе приложения, но не к базе данных.
  2. Служба приложений в DMZ, сервер базы данных во внутренней сети, защищенный брандмауэром, позволяющий приложениям подключаться к базе данных. Внутренние приложения будут подключаться к сервису приложений в DMZ.
  3. Все в демилитаризованной зоне.
  4. Полное отделение DMZ от внутренней сети путем помещения базы данных только для чтения и очереди сообщений в DMZ. Односторонний доступ из внутренней сети в DMZ, позволяющий внутренней базе данных реплицировать транзакции в базу данных DMZ, поддерживая ее в актуальном состоянии. Вместо записи в базу данных DMZ команды записываются в очередь сообщений, забираются из службы изнутри и обрабатываются службой приложения (мы можем жить с задержкой). Этот сценарий также включает разделение службы приложения, поэтому она состоит только из службы запросов только для чтения и службы размещения команд в очереди в DMZ. Исходная служба приложений по-прежнему будет активна во внутренней сети. Здесь есть дублированный код, но если это лучший сценарий, мы можем с этим жить.

Насколько мне известно (не специалист по сетям), сценарий 1 или 4 кажется наиболее подходящим решением. В решении 1 нет прямого подключения к нашей базе данных из DMZ, но есть порт, открытый из DMZ внутрь. В решении 4 ничего не открывается из DMZ внутрь, но мы открываем доступную только для чтения копию базы данных в DMZ. База данных содержит много конфиденциальной информации о клиентах, поэтому это может быть не идеально.

Что вы думаете? Мы будем очень благодарны за любые мысли и мнения.

Я думаю, что самый простой способ ответить на этот вопрос - это начать с другой стороны: спросить: «Что происходит в случае компромисса?». Если внешний веб-сервер скомпрометирован, то что злоумышленник может оттуда перейти? Давайте посмотрим на варианты:

  1. (Вы не представили его, но я помещаю его здесь для полноты картины.) Все во внутренней сети, с дырой в брандмауэре: вы облажались. Если веб-сервер скомпрометирован, злоумышленники могут получить доступ ко всему во внутренней сети (а не только к серверу базы данных).
  2. Внешний веб-сервер в демилитаризованной зоне, служба приложений в демилитаризованной зоне, сервер базы данных во внутренней сети: дополнительное препятствие для злоумышленников: и веб-сервер, и служба приложений должны быть скомпрометированы, прежде чем атака может перейти в базу данных. Успешная атака означает, что у злоумышленников есть потенциальный доступ ко всему во внутренней сети.
  3. Все в демилитаризованной зоне: успешная атака не имеет доступа к внутренней сети.
  4. Полное отделение DMZ от внутренней сети путем размещения базы данных только для чтения и очереди сообщений в DMZ ...: минимизирует возможность перехода из DMZ внутрь, но не устраняет его полностью. Требуется дополнительная сложная настройка и работа, чтобы убедиться, что все в порядке.

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

Это действительно большая проблема, когда, с одной стороны, мы беспокоимся о том, что хакер получает доступ к корпоративным данным, а также думаем о сохранении доступной только для чтения БД в DMZ. Но что мы будем помещать в БД, доступную только для чтения? Если это конфиденциальные данные PII, это просто не разрешено мерами ИТ-безопасности. Я бы сказал, что у нас есть прокси-клиент в приложении и есть возможность подключения к защищенной внутренней сети через RMI или HTTPS. Выполняйте вызовы через прокси-сервер, и это помогает поддерживать базу данных из хранилища, не опасаясь раскрытия данных внешнему безжалостному миру.