Сетевая безопасность в облачных сервисах

Как уже говорилось ранее, облако Amazon не имеет периметра. Вместо этого EC2 предоставляет группы безопасности, которые обеспечивают правила пропускания сетевого трафика, аналогичные правилам, задаваемым при конфигурировании брандмауэра (firewall). Группы безопасности позволяют управлять трафиком, который достигает виртуальных серверов в этой группе. Хотя я часто говорю о группах безопасности так же, как если бы они представляли собой сетевые сегменты, защищенные брандмауэром, в действительности они не являются виртуальными сетевыми сегментами, потому что:

± два сервера в двух различных зонах доступности Amazon EC2 могут работать в составе одной группы безопасности;

± сервер может принадлежать более, чем к одной группе безопасности;

± серверы, находящиеся в одной группе безопасности, могут вообще не иметь возможности поддерживать между собой какие бы то ни было коммуникации;

± серверы, находящиеся в одном и том же сетевом сегменте, могут иметь разные характеристики IP — они даже могут находиться в разных адресных пространствах;

1 О стандарте PCI DSS в России см. следующие ресурсы: http://www.pcisecurity.ru/, http://www.dsec.ru/consult/pcidss/, http://www.pcidss.ru/download/, http://www.iso27000.ru/standarty/pci-dss-standart-zaschity-informacii-v-industrii-platezhnyh-kart-1. — Прим. перев.

± ни один сервер в EC2 не может "видеть" входящий и исходящий сетевой трафик других серверов (для других облачных систем это не обязательно должно быть так). Если вы попытаетесь разместить ваш виртуальный сервер Linux в неизбирательном режиме, т. е. в режиме приема всех сетевых пакетов (promiscuous mode), то единственный сетевой трафик, который вы сможете увидеть, будет ваш собственный входящий и исходящий трафик.

Правила брандмауэра

Как правило, брандмауэр (firewall) защищает периметр одного или нескольких сетевых сегментов. Защита периметра сети с помощью брандмауэра показана на рис. 5.2.

Рис. 5.2. Брандмауэры являются основным инструментом защиты периметра

Основной брандмауэр защищает наружный периметр, пропуская только трафик HTTP, HTTPS и (иногда) FTP1. Между защищаемым сетевым сегментом и наружным периметром находятся пограничные системы, например балансировщики нагрузки, которые направляют трафик в так называемую "демилитаризованную зону" (DMZ), защищенную другим брандмауэром. В демилитаризованной зоне располагаются серверы приложений, которые направляют запросы к базам данных через третий брандмауэр во внутреннюю защищенную сеть, где находятся внутренние базы данных, хранящие конфиденциальную информацию.

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

На рис. 5.3 приведено визуальное представление концепции правил брандмауэров в облачной среде Amazon. Как видите, эта концепция в облачной инфраструктуре сильно отличается от концепции, принятой в традиционных центрах обработки данных.

Все виртуальные серверы находятся в сети на одном уровне, а управление трафиком осуществляется посредством определения групп безопасности (security group). Нет ни сетевых сегментов, ни периметра. Членство в одной и той же группе безопасности не предоставляет привилегированного доступа к другим серверам, принадлежащим к той же группе безопасности, за исключением того случая, когда вы явно определите правила, предоставляющие привилегированный доступ. Наконец, отдельный сервер может быть членом нескольких различных групп безопасности. Правила, определенные для конкретного сервера, представляют собой объединение (union) правил для всех групп, к которым этот сервер принадлежит.

Вы можете определить группы безопасности таким образом, чтобы имитировать традиционную защиту сетевого периметра. Например, вы можете создать следующую конфигурацию:

± создать пограничную группу безопасности (border security group), которая бы прослушивала весь трафик через порты 80 и 443;

1 Не следует пропускать в свою сеть трафик FTP. FTP — это небезопасный протокол, и на протяжении всей его истории в различных реализациях было найдено множество уязвимостей. Вместо FTP пользуйтесь SCP (secure copy) — протоколом копирования файлов, использующим в качестве транспорта не RSH (Remote Shell), а SSH (Secure Shell).

± создать группу безопасности DMZ, которая бы прослушивала трафик, исходящий из пограничной группы, через порты 80 и 443;

± создать внутреннюю группу безопасности, которая бы прослушивала трафик, исходящий из группы DMZ, через порт 3306.

Рис. 5.3. В облачной среде нет периметра и сетевых сегментов

ВНИМАНИЕ!

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

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

Подход Amazon позволяет использовать и такие возможности, которые были недоступны в традиционной инфраструктуре. Например, вы можете с легкостью обеспечить прямой доступ через SSH к любому виртуальному серверу в вашей облачной инфраструктуре из вашей корпоративной сети, не используя для этого виртуальную частную сеть (Virtual Private Network, VPN). При этом вы сохраняете возможность использования преимуществ, даваемых традиционным подходом к защите сети по периметру, когда речь идет об открытом доступе в Интернет, и можете получать быстрый доступ к вашим серверам для управления ими из критических точек.

Такая архитектура системы безопасности предоставляет два основных преимущества.

± Поскольку вы удаленно управляете правилами брандмауэра, атакующий не имеет единой мишени для своей атаки, как в случае с физическим брандмауэром.

± У вас нет возможности случайно разрушить правила защиты сети и таким образом навсегда блокировать любой доступ в данный сетевой сегмент.

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

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

± На каждом виртуальном сервере запускайте только один сетевой сервис (плюс все сервисы, необходимые для администрирования). Каждый новый сетевой сервис, присутствующий в системе, представляет собой вектор атаки. Если вы сосредоточите на одном сервере множество сервисов, вы создадите множество векторов атаки, потенциально позволяющих получить доступ к данным, хранящимся на этом сервере или для использования этого сервера для получения прав доступа к остальной сети.

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

± Открывайте только те порты, которые абсолютно необходимы для поддержания сервиса, предоставляемого конкретным сервером, и не более того. Разумеется, защита каждого из серверов должна быть усилена таким образом, чтобы на нем работал только один сервис — тот, который изначально был предназначен для работы на нем. Иногда бывает и так, что вы непреднамеренно запускаете на сервере те сервисы, которые изначально не предназначались для работы на данном сервере, или же вы оказываетесь в ситуации, когда в составе сервиса обнаруживается эксплоит, не требующий доступа от имени root (nonroot exploit), который позволяет атакующему запустить еще один сервис с помощью эксплоита, требующего доступа от имени root (root exploit). Блокируя доступ ко всему, за исключением вашего целевого сервиса, вы можете предотвратить использование этих типов эксплоитов.

± Ограничьте доступ к вашим сервисам, предоставляя его только тем клиентам, которые действительно в них нуждаются. Естественно, ваши балансировщики нагрузки должны открывать Web-порты 80 и 443 для всего трафика. В открытом доступе нуждаются только эти два протокола и конкретный сервер. Для любого другого сервиса трафик должен быть ограничен конкретными исходными адресами или группами безопасности.

± Даже если вы не осуществляете балансировку нагрузки, используйте обратный прокси (reverse proxy)1. Обратный прокси представляет собой Web-сервер, например Apache, который маршрутизирует трафик от клиента к серверу. За счет использования прокси-сервера вы можете усложнить для злоумышленника атаку на вашу инфраструктуру. Во-первых, Apache и IIS намного лучше справляются с "боевыми задачами" по отражению сетевых атак, чем любой из серверов приложений, которые вы можете использовать. В результате вероятность проникновения эксплоита будет значительно снижена, а вероятность его обезвреживания и скорость выпуска "заплатки" (patch) существенно повысятся. Вовторых, использование эксплоита на прокси-сервере оставит атакующего буквально "ни с чем" — никакого доступа он все равно не получит. Атакующим в любом случае придется искать дополнительную уязвимость на самом вашем сервере приложений.

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

1 Обратный прокси — это прокси-сервер, который, в отличие от прямого, ретранслирует запросы клиентов из внешней сети на один или несколько серверов, логически расположенных во внутренней сети. Обычно обратные прокси-серверы устанавливаются перед Web-серверами. Часто используется для балансировки сетевой нагрузки между несколькими Web-серверами и повышения их безопасности, играя при этом роль брандмауэра (межсетевого экрана) на прикладном уровне. Подробнее см. http://tinyurl.com/36smmyu, http://en.wikipedia.org/wiki/Reverse_proxy. — Прим. перев.

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100