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

Question

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

Все проекты, которые я придумала, отклонены, потому что сетевой отдел не допустит, чтобы какое-либо соединение (WCF, Oracle и т. Д.) Входило из DMZ.

Предложения, поступающие со стороны сети, обычно подразделяются на две категории -

1) Экспортировать необходимые данные на сервер в DMZ и экспортировать измененные / вставленные записи, в конце концов, каким-либо образом, или

2) Опрос изнутри, постоянно спрашивая службу в DMZ, есть ли у нее какие-либо запросы, требующие обслуживания.

Я против предложения 1, потому что мне не нравится идея базы данных, сидящей в DMZ. Вариант 2 кажется нелепым дополнительным усложнением характера того, что делается.

Это единственные законные решения? Есть ли очевидное решение, которое мне не хватает? Является ли постановление «Нет подключений из ДМЗ» практичным?

Редактировать: Одна строка, которую я постоянно слышу, заключается в том, что «ни одна крупная компания не позволяет веб-сайту подключаться внутри, чтобы получать оперативные производственные данные. Именно поэтому они отправляют электронные письма с подтверждением». Это действительно так работает?

Answer 1

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

Правила:

1. Соединения извне могут попадать только на узлы в DMZ и на определенные порты (80, 443 и т. Д.);
2. Соединения извне и внутри блокируются абсолютно;
3. Соединения изнутри либо с DMZ, либо с внешней стороны в порядке и отличны;
4. Только узлы в DMZ могут устанавливать соединения с внутренней и только с хорошо известными и разрешенными портами.

Четвертый пункт - это тот, который они не поняли - политика «нет соединений из DMZ» ошибочна.

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

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

Решения 1:

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

Решение 2:

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

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

Answer 5

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

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

Установленное соединение никогда не подключено - оно отсутствует - это означает, что порты открывать не нужно.

Answer 6

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

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

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

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

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

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

Answer 7

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

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

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

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

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

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

Кстати, если бы они знали службы WCF, они бы приняли это решение. Это наиболее безопасное решение, если оно хорошо спроектировано.

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