Файл: Облачные сервисы (Облачные сервисы в системе информационных технологий).pdf
Добавлен: 24.05.2023
Просмотров: 141
Скачиваний: 3
Один из основных моментов, который необходимо учитывать применительно к безопасности в облаке, состоит в том, что ответственность за использование ресурсов разделяется между клиентом и поставщиком облачного сервиса. И необходимо понимать, где кончается ответственность провайдера облачных вычислений и начинается ответственность клиента. При построении сложных систем (одной из разновидностей которых являются облака) применяют архитектурную концепцию многоуровневой безопасности (Defense in-Depth) – механизм, который использует несколько уровней защиты (рис. 3), чтобы увеличить время атакующего, затрачиваемое на попытки взломать систему; а также вести подсчёт количества попыток взлома для принятия решения о блокировке атакующего [37].
Соответственно, при построении системы безопасности среды облаков также можно выделить свои слои контроля и доступа. Облако комбинирует возможности пользователя и поставщика, брандмауэры и разновидности способов изоляции. При этом отдельные элементы безопасности могут контролироваться пользователем независимо от провайдера (рис. 3).
Как можно увидеть из рисунка 3, возможности пользователя по управлению системой безопасности зависят от выбора сервисной модели. В модели IaaS (например, IBM SoftLayer или Amazon WebServices) на стороне заказчика можно построить свои собственные технические средства обеспечения безопасности. Клиент может иметь полный контроль над реальной конфигурацией сервера, что гарантирует ему больший контроль рисков безопасности окружения и данных. В PaaS (IBM Bluemix, Microsoft Windows Azure) поставщик управляет лишь аппаратной платформой и операционной системой, что ограничивает способности предприятия заказчика в управлении рисками на этих уровнях. В модели SaaS (Salesforce.com, Google) как платформа, так и инфраструктура полностью управляется провайдером облачных услуг. Это означает, что, если операционная система или сервис не настроены должным образом, то данные на более высоком прикладном уровне могут быть в опасности [11, c. 567–579].
КЛИЕНТ
К Л И Е Н Т
П О С Т А В Щ И К
среда исполнения
связующее ПО
ОС
среда исполнения
связующее ПО
ОС
среда исполнения
связующее ПО
ОС
вычислительные ресурсы
ресурсы для
хранения данных
сетевые ресурсы
вычислительные ресурсы
ресурсы для
хранения данных
сетевые ресурсы
ПОСТАВЩИК
вычислительные ресурсы
ресурсы для
хранения данных
сетевые ресурсы
IaaS PaaS SaaS
Рис. 3. Многоуровневая система безопасности облаков на примере трёх моделей облачных сервисов. В разных сервисах клиентом контролируются различные слои безопасности независимо от провайдера [16].
Ответственность поставщика облачного сервиса начинается с физической безопасности и безопасности среды. Этот уровень безопасности – высокоуровневый, так как он связан с управляемостью облаком как единой информационной системой. Именно поставщик облачного сервиса осуществляет эксплуатацию физических серверов центров обработки данных, поэтому клиент так же, как и в случае с обычным ЦОД, должен рассмотреть следующие ключевые моменты: физический доступ персонала к серверам и сетевой инфраструктуре, средства пожарной сигнализации и пожаротушения, климатический и температурный контроль над серверами и другими аппаратными средствами, уничтожение выводимых из эксплуатации устройств хранения данных.
В отличие от физической безопасности, сетевая безопасность в первую очередь представляет собой построение надёжной модели угроз, включающей в себя защиту от вторжений и межсетевой экран. Использование межсетевого экрана подразумевает работу фильтра с целью разграничить внутренние сети ЦОД на подсети с разным уровнем доверия. Это могут быть отдельно серверы, доступные из Интернета, или серверы из внутренних сетей. Доступ через Интернет к управлению вычислительной мощностью облака – одна из ключевых характеристик облачных вычислений. В большинстве традиционных ЦОД доступ инженеров к серверам контролируется на физическом уровне, в облачных средах они работают через Интернет. Разграничение контроля доступа и обеспечение прозрачности изменений на системном уровне являются одними из главных критериев защиты.
Аналогичным образом на общий уровень безопасности влияет выбор модели развёртывания облачной среды: частное облако, инфраструктура, подготовленная для эксклюзивного использования единой организацией; публичное облако, инфраструктура, предназначенная для свободного использования широким кругом пользователей; общественное облако, вид инфраструктуры, предназначенный для использования конкретным сообществом потребителей из организаций, имеющих общие задачи; и гибридное облако, комбинация из двух или более различных облачных инфраструктур. Ключевые особенности частных облаков в структуре обеспечения информационной безопасности [11, c. 567–579]:
- ответственность клиента за инфраструктуру;
- возможность детальной настройки управления безопасности;
- хорошая видимость внутридневных операций;
- лёгкий доступ к системным логам и политикам;
- приложения и данные остаются внутри сетевого экрана.
Принято считать, что частные облака являются наиболее безопасными, поскольку они позволяют внедрить собственные средства шифрования и защиты ещё на этапе их создания, а также из-за того, что данные остаются в существующей инфраструктуре компании. Однако, если данные не защищены должным образом в облаке они могут быть потеряны или повреждены независимо от того частное это облако или публичное. В частности, недобросовестные лица внутри компании, имеющие доверенный доступ к системе могут просматривать, повреждать и похищать незащищённые данные.
Внутренние угрозы не являются какими-то новыми типами угроз, но при переходе корпоративных дата-центров в виртуальные, традиционные механизмы контроля доступа становятся менее эффективными, не будучи приспособленными к виртуальному пространству. Например, когда требуется установить экземпляр базы данных на новый физический сервер, применяются процедуры управления изменениями. Управление изменениями представляет собой процесс прогнозирования и планирования будущих изменений, регистрации всех потенциальных изменений для детального изучения, оценки последствий, одобрения или отклонения, а также организации мониторинга и координации исполнителей, реализующих изменения в проекте. В виртуальном частном облаке новый экземпляр базы данных может быть создан простым клонированием уже существующего виртуального сервера. Если данные с защищаемого сервера передаются на незащищённый, то эти данные смогут просмотреть пользователи, имеющие меньшие права доступа в этом частном облаке.
Интересно наличие неконтролируемой системами безопасности слепой зоны – трафика между виртуальными серверами в облаке. Традиционные средства мониторинга работают с использованием зеркалирования трафика с портов сетевых устройств и сенсоров, которые способные захватывать и анализировать этот трафик. Однако каналы передачи данных между ВМ создаются в гипервизоре. Вредоносный трафик и данные могут перемещаться между ВМ без выхода в реальную сеть, что означает, что атака будет не замечена традиционными инструментами. Данные, хранящиеся на выключенных ВМ, также являются уязвимыми, в случаях, когда в основной ОС, на которой они размещаются, контроль доступа не настроен должным образом, или не установлены обновления, исправляющие критические уязвимости.
На другом полюсе (в сторону уменьшения безопасности) принято располагать публичные облака. Можно отметить следующие особенности публичных облаков [11, c. 567–579]:
- за инфраструктуру отвечает провайдер;
- меньшая настраиваемость управления безопасностью;
- нет видимости внутридневных операций;
- трудный доступ к логам и политикам;
- приложения и данные используются публично.
Используя публичное облако, организации могут воспользоваться инфраструктурой провайдера в облаке (IaaS), платформой (PaaS) и программным обеспечением (SaaS). Данные сохраняются в среде облачного провайдера, с использованием арендуемой инфраструктуры коммерческих ЦОД. В большинстве случаев экономия средств в публичном облаке достигается за счёт более эффективного использования общих физических ресурсов. Это может означать как предоставление клиентам разных ВМ, размещённых на одном и том же физическом сервере, так и организация доступа клиентов к одному и тому же сервису или приложению под разными учётными записями. Например, популярное облачное CRM-приложение salesforce.com является примером предоставления одного и того же сервиса разным клиентам с использованием уникальных логинов для предотвращения неавторизованного доступа, хотя при этом данные разных пользователей оказываются перемешанными на одном хранилище.
В любом случае при использовании виртуализации приходится принимать во внимание весь комплекс проблем информационной безопасности, связанный с этой технологией. Конечно, в рамках публичного облака возможно и предоставление клиенту целиком отдельного, выделенного компьютерного ресурса, что, в частности, даёт возможность более качественного мониторинга и аудита. Однако такой дополнительный уровень комфорта в обеспечении безопасности часто сопровождается существенным увеличением цены использования облачных ресурсов, что может в целом снизить преимущества таковых перед собственным дата-центром [31].
Организации могут повысить уровень безопасности при использовании гибридного подхода к облачным вычислениям, который сочетает в себе публичные и частные облака. Часть данных, которые классифицируются организацией как наиболее критические остаются в частном облаке, тогда как все остальные данные хранятся в публичном облаке. Хотя этот подход может гарантировать большую безопасность, чем стандартная модель публичного облака, гибридные облака несут в себе те же риски, как частные и публичные облака в случаях неправильного их использования. Сохранение критически важных данных внутри предприятия требует вовлечения механизмов и процедур, гарантирующих, что эти данные не попадут наружу, в публичное облако. Таким образом, для облачных технологий наблюдается обратная зависимость: при увеличении степени открытости технологии, гибкости работы с ней и универсальности доступа, уменьшается защищенность системы и усложняется методика обеспечения её безопасности.
Для того, чтобы создать более безопасную среду облачных вычислений, организации могут начать с простых шагов, например, с разработки политики и процедуры безопасности, повышения прозрачности в использовании облачных приложений, платформ и инфраструктуры, и защиты данных с шифрованием и усилением процедуры доступа к элементам управления, таких как многофакторная аутентификация [11, c. 567–579].
ИТ-организации должны сделать больший акцент на усиление контроля доступа пользователей методом многофакторной аутентификации. Это ещё более важно для компаний, которые дают третьим сторонам и поставщикам доступ к своим данным в облаке. Многофакторные решения аутентификации, управляемые централизованно, обеспечат более безопасный доступ ко всем приложениям и данным – вне зависимости от того, находятся ли они в облаке или в локальной сети [39]. Технически хотя и сложно, но все же вполне реализуемо (в частном облаке – уже сейчас) настроить на всех промежуточных уровнях элементы шифрования, аутентификации, защиты данных.
В последние несколько лет, например, переживают бурный рост различные облачные системы медицинской направленности (см., например, [38]), хотя ещё несколько лет назад из-за проблем обеспечения конфиденциальности и сохранности персональных данных облака не рекомендовались для употребления медициной. В данный момент медицинские облака строятся на основе частных облаков с эшелонированной многослойной защитой и управляемой обычно специальным сервером безопасности данных.
Существует несколько способов защитить данные в облаке, среди которых контроль доступа и мониторинг. Однако наиболее эффективным и при этом универсальным способом обеспечить защиту данных, их конфиденциальность и целостность – это использованием шифрования данных при их передаче по информационным сетям и при хранении внутри облака. Например, в руководстве по информационной безопасности [30], разработанном Альянсом безопасности облаков, утверждается, что шифрование предоставляет преимущества наименьшей зависимости как от провайдера облачного сервиса, так и от эксплуатационных ошибок. Защита данных, основанная на шифровании, делает эти данные бесполезными для любого лица, не имеющего ключей для их дешифровки. И не важно, находятся эти данные в процессе передачи или хранения, они остаются защищёнными. Владелец ключей шифрования поддерживает безопасность данных, и принимает решения кому, и к каким данным предоставлять доступ. Процедура шифрования может быть встроена в существующий рабочий процесс облачных сервисов. Например, администратор может зашифровывать все данные резервного копирования перед отправкой их в облачное хранилище. Сотрудник организации может защитить корпоративную интеллектуальную собственность, прежде чем положить его в частное облако. Представитель компании может зашифровать личные контракты клиентов, прежде чем отправить их в совместное рабочее место в публичном облаке.