Развертывание защищенного сервера на враждебной территории

Оригинал: Secure Server Deployments in Hostile Territory
Автор: Kyle Rankin
Дата публикации: 25 июня 2015 г.
Перевод: А.Панин
Дата перевода: 29 августа 2015 г.

Изменили бы вы тон разговора по телефону, если бы узнали, что кто-либо враждебно настроенный по отношению к вам прослушивает его? Вне зависимости от того, считаете ли вы Агентство Национальной Безопасности США враждебно настроенной по отношению к вам организацией, я полагаю, что после прочтения материалов о слежке АНБ США за посетителями сайта Linux Journal некоторые из читателей изменят модель своего поведения. Я же столкнулся с аналогичной ситуацией тогда, когда начал процесс развертывания серверов в публичном облаке (в моем случае в облаке EC2).

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

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

В тылу врага

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

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

Практики, специфичные для облака EC2

Несмотря на то, что многие из описанных мною в данной статье практик могут быть использованы практически в любом окружении, некоторые из них специфичны для облака EC2, но даже в этом случае вы можете найти способы их переноса на другие облачные окружения. Многие из этих практик связаны с механизмом групп безопасности (Security Groups). Механизм групп безопасности облака EC2 может в некоторых случаях рассматриваться как аналог механизма VLAN в традиционной сети. Благодаря механизму групп безопасности вы можете сформировать набор правил межсетевого экрана для блокировки трафика, входящего на определенные порты всех серверов, состоящих в определенной группе. В отличие от традиционных сетей VLAN, благодаря механизму групп безопасности вы можете создать набор правил межсетевого экрана для блокировки всего трафика между участниками определенной группы. Каждый из серверов может состоять в множестве групп безопасности, но важно знать, что группы безопасности устанавливаются лишь в процессе создания серверов - вы не можете добавить сервер в группу безопасности или удалить его из группы безопасности после его создания.

В большинстве случаев я использую механизм групп безопасности таким же образом, как другие администраторы используют механизм VLAN с некоторыми исключениями. Для каждой группы серверов общего назначения выделяется своя группа безопасности. Во всех группах безопасности по умолчанию осуществляется блокировка всего входящего трафика, после чего я открываю порты лишь по мере необходимости. В большинстве случаев механизм групп безопасности помогает предотвратить попытки доступа к инфраструктуре извне. Также я сохраняю "стандартную" группу безопасности облака EC2 и добавляю каждый из серверов в нее; однако, я блокирую данную группу и пользуюсь ею только тогда, когда желаю предоставить доступ серверам из другой группы безопасности ко всем моим серверам. К примеру, я мог бы использовать изменения в рамках стандартной группы безопасности для разрешения взаимодействия всех серверов с мастер-сервером Puppet посредством порта с заданным номером. В качестве другого примера можно рассмотреть вариант использования VPN для доступа к облачной сети с возможностью доступа по SSH ко всем серверам из моего облачного окружения.

Наконец, я никогда не храню секретные данные в сценарии передачи пользовательских данных. Обычно при запуске сервера в облаке EC2 вы передаете серверу этот сценарий. Множество образов операционных систем Amazon или AMI (Amazon Machine Images - выбранный установочный образ операционной системы) настроены для автоматического исполнения сценария передачи пользовательских данных. Хотя в некоторых случаях данный файл и используется для передачи специальных значений параметров конфигурации сервера, многие администраторы (и я в том числе) используют данный файл в качестве пост-установочного сценария. В моем случае данный файл используется для настройки системы управления конфигурацией серверов (Puppet), которая сразу же после запуска осуществляет все изменения конфигурации элементов системы. Вы можете даже не догадываться о том, что содержимое сценария передачи пользовательских данных доступно посредством вызова API любому пользователю системы в течение времени существования сервера. Если вы используете сценарий передачи пользовательских данных для передачи любых секретных данных (таких, как сертификаты или закрытые ключи SSH, пароли или разделяемые секретные данные, используемые системой в процессе настройки, а также любые данные, которые не должны попадаться на глаза обычным пользователям), эти данные будут доступны любому пользователю системы. Фактически, в том случае, если вы самостоятельно используете систему Puppet (или в вашей системе установлено приложение facter), facter может вернуть вам содержимое этого сценария передачи пользовательских данных самостоятельно.

Работа с секретной информацией

Крайне важно подумать о том, как вы будете работать с секретной информацией в облачном окружении без задействования сценария передачи пользовательских данных. Фактически, несмотря на все ваши усилия по улучшению безопасности окружения, вам все же придется хранить закрытый ключ или пароль в текстовой форме где-либо в системе. Как говорилось ранее, я использую систему Puppet для управления конфигурацией всех моих серверов. Я храню все конфигурационные данные Puppet в репозитории Git для того, чтобы всегда имелась возможность отслеживания их изменений и аудита безопасности системы в случае необходимости. Размещение всех конфигурационных данных в репозитории Git является разумной практикой, но при этом наиболее важная практика размещения секретных данных, которую я могу порекомендовать для повышения безопасности системы, заключается в отказе от хранения этих данных в рамках данных вашей системы управления конфигурацией серверов. Всегда, когда это возможно, я пытаюсь генерировать секретные данные на уровне узла, для функционирования которого они необходимы, поэтому вместо передачи пары ключей GPG или SSH я могу использовать систему управления конфигурацией серверов для генерации этой пары на самом сервере.

Другая внедренная мной практика заключается в хранении секретных данных на диске в оперативной памяти при любой возможности. Данная практика позволяет избежать необходимости безопасного удаления файлов с жесткого диска, без которого эти данные могут в любой момент попасть в руки третьих лиц. Мы всего лишь разработали простейший модуль для нашей системы управления конфигурацией серверов, который автоматизирует процесс перемещения важных файлов на устройство /dev/shm, с присваиванием файлу имени, соответствующего его контрольной сумме, и созданием символьной ссылки по оригинальному пути. Конечно же, если вы пойдете этим путем, вам придется помнить о том, что все файлы, сохраненные на диске в оперативной памяти, исчезнут после перезагрузки системы (в этом и состоит вся идея), поэтому не следует хранить в оперативной памяти любые файлы, которые вы не сможете повторно сгенерировать после перезагрузки, хотя лично я обычно перезапускаю серверы, а не перезагружаю их в случае работы с облачным окружением.

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

Даже в случае использования всех описанных практик иногда гораздо проще сохранить пароль от базы данных в рамках набора данных вашей системы управления конфигурацией. В таких случаях я использую дополнительный модуль Puppet с именем hiera-gpg, который позволяет сохранять зашифрованные с помощью GPG файлы формата YAML с данными конфигурации системы Puppet, среди которых могут находиться значения важных параметров конфигурации. Каждое независимое окружение (такое, как окружение разработки и промышленного использования программных решений) имеет свои мастер-серверы Puppet со своими ключами GPG. Каждый системный администратор добавляет каждый из этих ключей в свою связку ключей GPG, а мы используем сценарий-обертку для того, чтобы поспособствовать редактированию описанных файлов модуля hiera-gpg. Данный сценарий передает информацию о том, какой файл следует отредактировать и для какого окружения он предназначен, а также проверяет корректность шифрования файла для того, чтобы любой системный администратор или мастер-сервер Puppet в определенном окружении мог открывать его.

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

http://rus-linux.net/MyLDP/sec/secure_server_on_hostile_territory.html