Xpoint
   [напомнить пароль]

ДМЗ (DMZ)

Метки: безопасность, dmz, веб-приложение
[арх]
2005-09-09 17:16:43 [обр] z...(0/47)[досье]
Коллеги, предлагаю обсудить т.н. демилитаризованные зоны.
Как лучше их устраивать, какие web-приложения туда выносить, как ковырять канал из ДМЗ во внутреннюю сеть.
спустя 2 дня 18 часов [обр] Андрей Новиков(8/1242)[досье]

По последним веяньям DMZ — это зло. :)

Ну а вообще вопрос какой-то слишком общий: приложение приложению — рознь.

спустя 3 часа 37 минут [обр] Виталий Ульченков(22/116)[досье]
Андрей Новиков[досье], и чем их заменяют по последним веяньям? :)
спустя 2 месяца 4 дня [обр] z...(0/47)[досье]

Андрей Новиков[досье], а почему зло?
Кто, когда сказал?

Что касается конкретики, то я бы хотел обсудить интернет-банкинг. Но, полагаю, специалистов по этому направлению не много, посему можем обсудить ЛЮБЫЕ приложения.

спустя 5 дней [обр] Yeoman(6/48)[досье]

А что именно с точки зрения интернет-банкинга(и-б) вас интересует? Основным отличием и-б от других приложений является свясь с production-базой с информацией с ограниченным доступом. То есть по сути дела надо дать доступ к данным, размещенным во внутреннем периметре. Судя по практике отдел безопасности банка, обычно упирается "рогами" до упора тчобы подобные системы не делать, не важно через ДМЗ или напрямую. Как правло используются два подхода:

  1. Это использование локальной "урезанной" с точки зрения полноты данных базы данных и иб-сервер работает с ней. То есть во внутренний периметр доступа нет. Синхронизация допустим по ночам через импорт-экспорт и т.п.
  2. Используется "шашлык" (термин не стандартизирован :-D) То есть веб-сервер вклбчается в DMZ зоне, прикрытый FW, на второй интерфейс кроссом вешается сервер приложений, а у него второй интрефейс торчит в локалку.
  3. Можно еще поставить веб-сервер в DMZ, а с него дать доступ к серверу приложений, распаложенному в промежуточной зоне, а оттуда уже в БД и т.п.

У каждого вариант есть сови плюсы и минусы. Реальная ситуация в банке как правило накладывает свои ограничения. Например политика безопасности и построение сети не позволяют реализовать вариант 2 и/или 3. Или например если многофилиальный банк, то вариант 3 не пройдет, надо опять же централизованную базу делать и к ней доступ давать, тогда варианты 1 и 2 могут помочь.

спустя 3 часа 4 минуты [обр] z...(0/47)[досье]

Yeoman[досье], спасибо за ответ. Наконец-то может получиться дискуссия.
Про доступ к данным во внутренней сети - вы все верно сказали.
Но есть еще и другой аспект - где хранить закрытые ключи банковской подписи. Вроде как в ДМЗ - плохо, компрометация грозит. Во внутренней сети тоже не ахти, ибо обычно канал защищается TLS, а значит ключи должны быть рядом с веб-серверром, а он ведь в ДМЗ.

По поводу ваших трех вариантов.
Вроде есть четвертый. Веб-сервер в ДМЗ. Сервер приложений и сервер БД во внутренней сети. Между ДМЗ и внутренней сеткой - хитрый шлюз, логирующий весь трафик, авторизующий проходящий траффик (подписанный) по сертификату.

А по поводу первого варианта - замечательно с точки зрения безопасности и безопасников банка, но с точки зрения онлайн- обслуживания клиент - кошмар. Платежи от клиента в АБСку раз в сутки попадать будут? :(

спустя 1 день [обр] Yeoman(6/48)[досье]

z...[досье]на самом деле ваш четвертый вариант и есть мой вариант номер 3 с некоторыми вариациями. :)
По поводу первого варианта - есть такое дело - синхронизацию можно сделать чаще и в АБСку будет падать чаще. Или пойти на некоторый риск. В Raiffeisen Connect например сегодня видны данные за вчера. Вообщем каждый выбирает по своемому.

По поводу ключей. А тут давайте разбираться.
Момент первый: у нас должно быть две пары - собственно для защиты траффика и для проставления банковской подписи, то есть совершили действие, проставили подпись. Если с ключами для TLS понятно и их с сервера не убрать, то ключи для банковской подписи должны находится там, где совершается действие, то етсь если операция осершается на выделенном сервере приложений, то ключи должны быть на нем.

момент второй: управление и использование. А ответ тут один - HSM. То есть аппаратный модуль. Если мы не настаиваем на использовании криптоалгоритмов ГОСТ, то перед нами богатый выбор - например nCipher HSM. И вот тут можно и ключи банковской одписи в него поместить и ключи SSL/TLS сделать, причем в последнем случае получим еще и ускорение SSL во много раз и решим вопрос с нагрузкой на сервер за счет выполнения криптографических преобраований на аппаратном модуле. Плюс это железо имеет сертификат FIPS 140-2 L3 (или L2) в зависимости от модели и прошло 3Dsecure платежной системы VISA, так что если фанатично не требовать ГОСТы, то можно использовать в i-banking.
В этом случае сделать что то с ключами практически не реально. А если еще защитить доступ к ним по схеме расщипления M of N, тогда решается задача борьбы с внутренним врагом :)

Лично мне синхронизация в офлайне не нравится. Разбор коллизий и вытряхивание денег из клиента денег постфактум сведут на нет все плюсы системы.

Есть еще момент который мы не рассматривали - аунтификация пользователей. И вот тут начинается настоящие пляски с бубном (сорри за цветистые фразы :).

Powered by POEM™ Engine Copyright © 2002-2005