боков блог

Amazon анонсировал документ посвященный общему описанию системы безопасности своих веб-сервисов – Amazon Web Services: Overview of Security Processes.  Несмотря на то что технических подробностей в документе не описаное, кое-что интересное стоит отметить. Итак, почему мы можем быть уверены что наши данные внутри AWS будут защищенны должным образом? Посмотрим что же обещает Amazon в плане защищенности данных внутри Elastic Compute Clouds ( EC2 ), SimpleDB и Simple Storage Service (S3).

Amazon говорит о том, что дата центры где находятся серверы построены в правильных местах, имеют все уровни физической защиты и опытный персонал. Также говорится о том, что backup данных нет, но зато данные хранятся распределенно, и эта распределенность ничего не стоит пользователям (бесплатна для них:-) ).

C EC2 ситуация следующая – там есть несколько уровней организации доступа – это собственно ОС ( host OS ), поверх нее запущено несколько виртуальных instance c guest OS ( на физически одном host работает несколько instance разных пользователей c разными guest OS), firewall ( регламентирующий доступ по сети к данному instance ) и вызовы API Amazon ( через него работает например Amazon command line tools ) – в целом вся структура должна работать таким образом чтобы данные внутри Amazon EC2 не могли быть доступны неавторизованным пользователям и каждый instance Amazon EC2 должен быть защищен настолько, насколько это возможно без ущерба для гибкости в необходимом для пользователей конфигурировании.

К host OS имеют доступ только AWS administators, которые получают доступ к host OS через специальные bastion host, используют сильные ключи, все действия на bastion hosts логгируются и т.п. – утверждается что технически и организационно всё организовано с высоким уровнем защищенности.

К guest OS полный доступ имеет клиент ( root доступ ) который запустил данный instance. Администраторы AWS не имеют доступа к guest OS ( не имеют доступа в данном случае означает не могут logon на нее сделать ). Вся забота о защищенности, ключах, и распределении прав лежит на клиенте.

Firewall – входящий трафик по умолчанию запрещен – чтобы открыть доступ ( в т.ч. ssh ) клиенту необходимо открывать соответствующий порт. Трафик можно конфигурировать по протоколам, портам или по IP адресам, есть поддержка IPTables, что позволяет регулировать трафик по ip в обоих направлениях. Instance могут быть объединены в группы, каждой группе можно задавать свои правила доступа – например, для серверов из группы front-end ( “морды” как говорят в крупных порталах ) открыть 80 порт, к группе back-end серверов можно обращаться только с серверов группы frond-end по портам 8000. И ко всем этим серверам открыть ssh доступ по 22 порту только с IP с которых заходят разработчики. Физически firewall host OS или instance с host/instance не связаны и внутри Amazon EC2 их обслуживают разные группы сисадминов – я так понимаю этот волшебный firewall в жизни есть cisco или hyawei на которую загружаются соответствующие правила . Защищенность на уровне firewall также полностью регулируется клиентом – amazon гарантирует что средства которые используются для этого обладают достаточной производительность и защищенностью.

API – искользуется для запуска instance, изменения параметров firewall и тп – фунционал доступен например через Amazon command tools . Все операции производятся с авторизацией по цифровому сертификату и защищенность на этом уровне фактически обеспечивается защищенностью приватного ключа клиента Secret Acess Key. При работе с API рекомендуется пользоваться SSL ( по умолчанию SSL включен, и обмен данными ведется через https ).

Guest OS запускается на host OS c использование монитора виртуальных машин Xen. Amazon принимает активное участие в работе Xen community что обещает поддержание работающего внутри Amazon Xen в наиболее актуальном состоянии. Естественно? прямого доступа к аппаратным ресурсам ( процессору, памяти, жесткий диск ) guest OS не имеет – все обращения осущствляются через слой виртуализации, при этом  одновременно работающие guest OS одной host OS могут видеть и обращаться только к своим данным – данные других пользователей защищены слоями виртуализации. При этом Amazon рекомендует хранить данные на жестких дисках ( естественно тоже виртуальных ) с использованием шифрованных файловых систем, посколько на самом деле иногда возможны и утечки – “note that unintentionally leaving data on disk devices is only one possible breach of confidentiality”.

В плане сетевой защиты обещается защита от DDoS атак ( ограничение по числу соединений, высокопроизводительная сеть внутри Amazon EC2 и тп ), Man In the Middle атак ( бороться помогает SLL ), атак с подменой IP Spoofing IP ( внутри Amazon EC2 instance не смогут генерировать трафик только со своими IP и MAC ), сканирование портов неэффективно поскольку большинство портов на amazon instance закрыто по умолчанию, а сам факт сканирования портов нарушет пользовательское соглашение, что ведет блокирование аккаунта. Естесственно, что если клиент сам открыл на своем instance какой то порт наружу, то только он сам несет ответсвенность за то что на этом порту будет работать правильно настроенное ПО которое и будет обеспечивать нужный уровень защищенности ( например apache на 80 порту ). Перехват чужих пакетов ( packet sniffing и ARP cache ) внутри сети Amazon EC2 невозможен ( я так понимаю защита на уровне Xen ) – instance может получить только тот трафик который адресован только ей ( нельзя получить доступ к трафику даже для других instance того же самого клиента, даже если эти instance находятся физически на одном host ).

Безопасность данных в Simple Storage Service ( S3 ) базируется на защищенной реализации API доступа к данному сервису – информация о правах доступа хранится в Access Contol List ( ACL ) которые по умолчанию доступны для редактирования только владельцам данных. При необходимости владелец данных может изменить права доступа к своим данным вплоть до того чтобы сделать их открытыми. Защищенность данных при передаче их между разными S3 endpoints  ( S3 – распределенное хранилище данных ) обеспечивается использованием SSL. Сами по себе данные в S3 не шифруются и если есть такая необходимость для обеспечения дополнительной защиты данных ( чтобы никто, включая AWS, не мог получить к ним доступа ), то перед тем как сохранять данные в S3 пользователь должен самостоятельно зашифровать их соответсвующим образом. После удаления объекта из S3 он сразу же ( в течении нескольких секунд ) становится недоступным снаружи – место где были удаленные данные становится доступным только для записи и будет перезаписано вновь сохраняемыми объектами.

Защита информации в SimpleDB осуществляется аналогиченым образом – имеется ACL который доступен для редактирования только владельцу, защита передаваемых данных между simpleDB domains ( SimpleDB – распределенная база данных ) осуществляетс с использование SSL. Данные внутри SimpleDB не шифруются – если это надо, так же как и в S3, пользователь должен делать это самостоятельно. После удаления домена из списка  SimpleDB он становится сразу же ( в течении нескольких секунд )недоступным снаружи. При удалении записей в базе внутри домена, удаление mapping этих записей начинается сразу же ( в течении секунд ) и данные становятся недоступны – аналогично S3, место где были удаленные данные становится доступным только для записи и будет перезаписано вновь сохраняемыми объектами.

Share/Bookmark