Доступ к данным во внутренних продуктовых базах данных с веб-сервера в DMZ

Ответ 1

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

Правила:

• Подключения извне могут поступать только на хосты в DMZ и на определенные порты (80, 443 и т.д.);
• Соединения снаружи и внутри блокируются абсолютно;
• Соединения изнутри или DMZ или снаружи являются точными и денди;
• Только узлы в DMZ могут устанавливать соединения внутри и снова, только на хорошо известных и разрешенных портах.

Точка четыре - та, которую они не поняли - политика "без соединений из DMZ" ошибочна.

Спросите их: "Как работает наша почтовая система?" Я предполагаю, что у вас есть корпоративный почтовый сервер, возможно, обмен, а у отдельных клиентов есть клиенты, которые подключаются к нему. Попросите их объяснить, как ваша корпоративная электронная почта, доступ к электронной почте в Интернете, работает и соответствует их политике.

Извините, это не дает вам ответа.

Ответ 2

Я архитектор безопасности в финансовой фирме 50. У нас были такие же разговоры. Я не согласен с вашей сетевой группой. Я понимаю их страх, и я понимаю, что они хотели бы лучшее решение, но большинство мест не выбирают лучший выбор (из-за незнания с их стороны [т.е. Сети, ребята, не вы]).

Два варианта, если они жестко установлены на этом: Вы можете использовать SQL-прокси-решение, такое как greensql (я не работаю для них, просто знаю их), они просто greensql dot com.

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

Его серая область, нет твердого права или неправильного в этом отношении, поэтому, если они говорят в терминах окончательности, то они явно ошибаются. Я приветствую их рвение, как профессионал безопасности, я понимаю, откуда они. НО, мы должны позволить бизнесу функционировать надежно. Это вызов и перчатка, которую я всегда стараюсь бросать на себя. как я могу доставить то, что мой клиент (мои разработчики, мои администраторы, мои dbas, бизнес-пользователи), что они хотят (в разумных пределах, и если я говорю кому-то, я всегда стараюсь предложить альтернативу, отвечающую большинству их потребностей).

Честно говоря, это должен быть открытый разговор. Здесь, где я думаю, вы можете получить какую-то комнату, попросите их оценить модель риска, которую они хотят смягчить. Попросите их предложить альтернативные решения, которые позволят вашим веб-приложениям функционировать. Если они говорят, что они не могут говорить, тогда наложите на них ответственность, чтобы обеспечить решение. Если они не могут, то вы по умолчанию работаете. Сайт, на котором вы открываете соединения от dmz до db ТОЛЬКО для утвержденных портов. Сообщите им, что DMZ предлагает внешние услуги. Внешние службы не являются хорошими без внутренних данных для чего-то большего, чем потенциально решения для передачи файлов.

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

Ответ 3

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

Один из способов - использовать структуру синхронизации ms - вы можете создать простую службу Windows, которая может синхронизировать изменения из внутренней базы данных в вашу внешнюю базу данных (которая может находиться на отдельном сервере db), а затем использовать ее на вашем публичном веб-сайте, Преимущество заключается в том, что ваша логика синхронизации может отфильтровывать конфиденциальные данные и сохранять только те вещи, которые действительно необходимы. И так как весь контроль данных будет на ваших внутренних серверах (данные PUSH вместо вытягивания), я не думаю, что у ЭТО будет проблема с этим.

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

Ответ 4

Вот что вы могли бы сделать... это немного растягивается, но оно должно работать...

Напишите службу, которая находится на сервере в DMZ. Он будет прослушивать три порта, A, B и C (выбор любых номеров портов имеет смысл). Я назову это приложение DMZ tunnel.

Напишите еще одну службу, которая живет где угодно во внутренней сети. Он подключится к приложению DMZ-туннеля на порту B. После того, как это соединение будет установлено, приложение туннеля DMZ больше не нужно слушать на порту B. Это "управляющее соединение".

Когда что-то подключается к порту A приложения туннеля DMZ, он отправляет запрос по управляющему соединению для нового DB/любого соединения. Внутреннее приложение туннеля ответит, подключившись к внутреннему ресурсу. Как только это соединение будет установлено, оно подключится обратно к приложению DMZ-туннеля на порту C.

После проверки некоторых токенов (эта часть зависит от вас) приложение DMZ-туннеля будет пересылать данные назад и вперед между соединениями, которые он получил на портах A и C. Фактически у вас будет прозрачный прокси-сервер TCP, созданный из двух служб работающих в DMZ и во внутренней сети.

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

Ответ 5

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

Я не работал в "большой" компании, хотя тяжело судить без контекста, но я создал свою долю веб-приложений для некоммерческого и университетского факультета, над которым я работал. В обеих ситуациях я всегда подключался к производственной БД, которая находится во внутренней сети с веб-сервера на DMZ. Я уверен, что многие крупные компании тоже это делают; подумайте, например, о том, как настраивается архитектура SharePoint - серверы back-end индексирования, базы данных и т.д., к которым подключены интерфейсные веб-серверы, расположенные в DMZ.

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

Теперь, если это не так, давайте посмотрим на вашу проблему. К сожалению, кроме двух представленных вами решений, я не могу придумать другого способа сделать это. Хотя некоторые вещи, о которых вы могли бы подумать:

Решения 1:

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

Решение 2:

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

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

Ответ 6

В основном я с Кеном Рэем; однако, как представляется, имеется некоторая недостающая информация. Посмотрим, получится ли это правильно:

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

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

Просто возьмите опцию 1. Попросите производственный сервер экспортировать данные, которые вам нужны, в общедоступное место для удаления. Попросите другой сервер db (один в DMZ) получить данные и импортировать их на регулярной основе. Наконец, ваше веб-приложение ТОЛЬКО разговаривает с сервером db в dmz.

Учитывая, как многие люди создают сайты в наши дни, мне также не хотелось бы просто открывать sql-порт из dmz на веб-сервер, о котором идет речь. Честно говоря, я мог бы убедиться, что вы откроете соединение, если я был уверен, что 1. вы использовали только хранимые procs для доступа к необходимым вам данным; 2. информация учетной записи, используемая для доступа к базе данных, была зашифрована и полностью ограничена только запуском этих процессов; 3. эти procs имели нулевой динамический sql и были ограничены выборами; 4. Ваш код был построен правильно.

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

Ответ 7

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

Поместите свой сайт в интрасеть и скажите им: "Теперь мне нужны входящие HTTP: 80 или HTTPS: 443 подключения к этим приложениям. Настройте то, что вы хотите: обратные прокси, ISA Server, перерыв протоколов, SSL... При необходимости приспособию приложение. '

Об ISA, я думаю, они получили один, если у вас есть обмен с внешними соединениями.

Многие компании выбирают это решение, когда ресурс должен делиться между интранет и общественностью.

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

Все больше системных инженеров (например, мины) предпочитают поддерживать сеть интрасети с небольшим "нарушением безопасности", например HTTP, чем открывать другие протоколы и порты.

Personnaly, я использую эти два метода: TCP (HTTP или нет) Сервисы и ISA-сервер.