SFTP: как сохранить данные вне DMZ
Мы исследуем решения следующей проблемы:
У нас есть внешние (интернет) пользователи, которым нужен доступ к конфиденциальной информации. Мы могли бы предложить это им через SFTP, который предложил бы безопасный способ транспортировки.
Однако мы не хотим хранить данные на сервере, поскольку они будут находиться в демилитаризованной зоне.
Существует ли SFTP-сервер, на котором имеется "копия при доступе", так что, если блок в демилитаризованной зоне был скомпрометирован, на этом блоке не было реальных данных?
Я предполагаю прохождение через SFTP Proxy или SFTP. Существует ли такой продукт в настоящее время?
5 ответов
Похоже, использование HTTPS, а не SFTP было бы лучше. Запустите HTTP-прокси на сервере DMZ и сохраните данные на внутреннем веб-сервере. Если пользователь скомпрометирует сервер DMZ и получит оболочку, у него не будет доступа к данным. Они узнают о прокси, но если вы используете базовую аутентификацию, они не смогут получить доступ к данным.
EFT-сервер Globalscape со шлюзом DMZ делает именно то, что вы просите
У Jscape есть обратный прокси-сервер SFTP, который должен делать то, что вы хотите. См. http://www.jscape.com/reverseproxy/index.html.
Кстати, достаточно легко сделать SFTP-прокси, если вам не нужны какие-либо функции, кроме переадресации портов. Вы можете использовать netfilter http://kreiger.linuxgods.com/kiki/?Port+forwarding+with+netfilter, fwtk http://sourceforge.net/projects/openfwtk/ или даже переадресацию портов SSH.
Если вы хотите передать данные с ограниченным доступом в Интернет, решение не обязательно дает им доступ к ограниченному сегменту сети через Интернет. На самом деле, я бы категорически не одобрял это, когда вы это описываете. То, что вы спрашиваете, на самом деле довольно сложно реализовать ответственным образом.
Для иллюстрации у вас есть два сегмента сети. DMZ и частная сеть. Базы данных живут на частном, а веб-серверы - в DMZ. В целях безопасности вы полностью ограничиваете доступ к частной сети и из нее с помощью брандмауэра. Если DMZ взломана и данные аутентификации сохранены на сервере, взломщик сможет получить доступ к ограниченным данным.
Именно здесь появляются требования к шифрованию и методы управления ключами, которые рассматриваются в PCI DSS. Если у вас нет усовершенствованной архитектуры шифрования, вы все равно рискуете данными в случае компрометации, даже если они не хранятся в DMZ.
Вы могли бы потенциально реализовать ETL и пакетировать данные. Зачастую это решение диктует необходимость шифрования данных с использованием надежного шифрования и последующей передачи по предпочитаемому протоколу. Как только данные зашифрованы, методы, используемые для их передачи, могут быть значительно более гибкими.
Ваша точная ситуация будет диктовать, сколько усилий приложено, чтобы найти решение, достойное производства. Если вы имеете дело с одноразовым запросом, вам лучше вручную выполнить его с помощью такого инструмента, как GnuPG. В противном случае вам может понадобиться создать, найти или купить приложение. Подход, который становится все более распространенным, заключается в использовании веб-приложения для удовлетворения требований безопасности, в то же время позволяя данным быть доступными для тех, у кого меньше технических знаний.