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

SFTP: как хранить данные вне DMZ

Мы ищем решения следующей проблемы:

У нас есть внешние (Интернет) пользователи, которым нужен доступ к конфиденциальной информации. Мы могли бы предложить им это через SFTP, который предложит безопасный метод транспортировки.

Однако мы не хотим хранить данные на сервере, поскольку тогда они будут находиться в DMZ.

Существует ли SFTP-сервер, у которого есть «копирование при доступе», так что если бы ящик в DMZ был скомпрометирован, на этом ящике не было бы реальных данных?

Я предполагаю использование прокси-сервера SFTP или сквозной передачи SFTP. Такой продукт существует в настоящее время?

Похоже, что лучше использовать HTTPS, а не SFTP. Запустите прокси-сервер HTTP на сервере DMZ и храните данные на внутреннем веб-сервере. Если пользователь скомпрометирует сервер DMZ и получит оболочку, у него не будет доступа к данным. Они узнают о прокси, но если вы используете базовую аутентификацию, они не смогут получить доступ к данным.

Сервер Globalscape EFT со шлюзом DMZ делает именно то, о чем вы просите

http://globalscape.com/eft/

Кстати, создать прокси-сервер 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. В противном случае вам может потребоваться создать, найти или купить приложение. Подход, который становится все более распространенным, заключается в использовании веб-приложения для удовлетворения требований безопасности, в то же время позволяя доступ к данным тем, у кого меньше технических знаний.

В Jscape есть обратный прокси-сервер SFTP, который должен делать то, что вы хотите. Видеть http://www.jscape.com/reverseproxy/index.html.