Свои подходы к устранению уязвимостей облачных вычислений. Угрозы безопасности облачных вычислений

ТОП-12 угроз облачной безопасности по версии Cloud Security Alliance

Сегодня поговорим об угрозах облачной безопасности, рассмотрев ТОП-12, с которыми сталкиваются те или иные организации, использующие облачные сервисы. Как известно, количество облачных миграций с каждым годом растет, а вопрос безопасности по-прежнему остается серьезной темой.

Первым шагом к минимизации рисков в облаке является своевременное определение ключевых угроз безопасности. На конференции RSA , прошедшей в марте этого года, CSA (Cloud Security Alliance) представила список 12 угроз облачной безопасности, с которыми сталкиваются организации. Рассмотрим их более подробно.

Угроза 1: утечка данных

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

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

Угроза 2: компрометация учетных записей и обход аутентификации

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

CSA рекомендует использовать механизмы многофакторной аутентификации, включая одноразовые пароли, токены, смарт-карты, USB-ключи. Это позволит защитить облачные сервисы, поскольку применение озвученных методов усложняет процесс компрометации паролей.

Угроза 3: взлом интерфейсов и API

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

CSA рекомендует организовать адекватный контроль доступа, использовать инструменты защиты и раннего обнаружения угроз. Умение моделировать угрозы и находить решения по их отражению — достойная профилактика от взломов. Кроме того, CSA рекомендует выполнять проверку безопасности кода и запускать тесты на проникновение.

Угроза 4: уязвимость используемых систем

Уязвимость используемых систем — проблема, встречающаяся в мультиарендных облачных средах. К счастью, она минимизируется путем правильно подобранных методов управления ИТ, отмечают в CSA. Лучшие практики включают в себя регулярное сканирование на выявление уязвимостей, применение последних патчей и быструю реакцию на сообщения об угрозах безопасности. Согласно отчетам CSA, расходы, затраченные на снижение уязвимостей систем, ниже по сравнению с другими расходами на ИТ.

Распространена ошибка, когда при использовании облачных решений в модели IaaS компании уделяют недостаточно внимания безопасности своих приложений, которые размещены в защищенной инфраструктуре облачного провайдера . И уязвимость самих приложений становится узким местом в безопасности корпоративной инфраструктуры.

Угроза 5: кража учетных записей

Фишинг, мошенничество, эксплойты встречаются и в облачном окружении. Сюда добавляются угрозы в виде попыток манипулировать транзакциями и изменять данные. Облачные площадки рассматриваются злоумышленниками как поле для совершения атак. И даже соблюдение стратегии «защиты в глубину» может оказаться недостаточным.

Необходимо запретить «шаринг» учетных записей пользователей и служб между собой, а также обратить внимание на механизмы многофакторной аутентификации. Сервисные аккаунты и учетные записи пользователей необходимо контролировать, детально отслеживая выполняемые транзакции. Главное — обеспечить защиту учетных записей от кражи, рекомендует CSA.

Угроза 6: инсайдеры-злоумышленники

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

Угроза 7: целевые кибератаки

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

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

Угроза 8: перманентная потеря данных

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

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

Угроза 9: недостаточная осведомленность

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

Угроза 10: злоупотребление облачными сервисами

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

Угроза 11: DDoS-атаки

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

Угроза 12: совместные технологии, общие риски

Уязвимости в используемых технологиях — достаточная угроза для облака. Поставщики облачных услуг предоставляют виртуальную инфраструктуру , облачные приложения, но если на одном из уровней возникает уязвимость, она влияет на все окружение. CSA рекомендует использовать стратегию «безопасности в глубину», внедрять механизмы многофакторной аутентификации, системы обнаружения вторжений, придерживаться концепции сегментирования сети и принципа предоставления наименьших привилегий.

Безопасность в облаках. Изучаем безопасность облачных сервисов на примере инфраструктуры Яндекса

Содержание статьи

Сказка — ложь, да в ней намек

Начало этой истории можно рассказывать, как известную сказку. Было в фирме три админа: старший умный был детина, средний был и так и сяк, младший вовсе был… стажером-эникейщиком. Заводил юзеров в Active Directory и крутил хвосты цискам. Пришло время компании расширяться, и призвал царь, то есть босс, свое админское воинство. Желаю, говорит, новые веб-сервисы для наших клиентов, собственное файловое хранилище, управляемые базы данных и виртуальные машины для тестирования софта.

Младшенький с ходу предложил создать с нуля собственную инфраструктуру: закупить серверы, установить и настроить софт, расширить основной интернет-канал и добавить к нему резервный — для надежности. И фирме спокойнее: железо всегда под рукой, в любой момент чего-нибудь заменить или перенастроить можно, и самому ему представится отличная возможность прокачать свои админские скиллы. Подсчитали и прослезились: не потянет компания таких затрат. Крупному бизнесу подобное под силу, а вот для среднего и малого — слишком накладно получается. Это ж нужно не просто оборудование приобрести, серверную оборудовать, кондиционеры повесить да противопожарную сигнализацию наладить, требуется еще и посменное дежурство организовать, чтобы денно и нощно за порядком следить и отражать сетевые атаки лихих людей из интернета. А по ночам и в выходные админы работать почему-то не захотели. Если только за двойную оплату.

Старший админ поглядел задумчиво в окошко терминала и предложил поместить все сервисы в облако. Но тут его коллеги принялись пугать друг друга страшилками: дескать, облачная инфраструктура имеет незащищенные интерфейсы и API, плохо балансирует нагрузку разных клиентов, из-за чего могут пострадать твои собственные ресурсы, а еще неустойчива к краже данных и внешним атакам. Да и вообще, боязно передавать контроль над критичными данными и ПО посторонним лицам, с которыми ты не съел пуд соли и не выпил ведро пива.

Средненький подал идею разместить всю IT-систему в дата-центре провайдера, на его каналах. На том и порешили. Однако тут нашу троицу поджидало несколько неожиданностей, не все из которых оказались приятными.

Во-первых, любая сетевая инфраструктура требует обязательного наличия средств защиты и безопасности, которые, конечно, были развернуты, настроены и запущены. Только вот стоимость используемых ими аппаратных ресурсов, как оказалось, должен оплачивать сам клиент. А ресурсы современная система ИБ потребляет немалые.

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

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

Подсчет расходов и подведение итогов привели руководство компании к неутешительным выводам: прав был тот админ, который с самого начала предлагал воспользоваться облачной моделью IaaS — «инфраструктура как сервис». Что же касается безопасности таких платформ, то об этом стоит поговорить отдельно. И сделаем мы это на примере самого популярного из подобных сервисов — Яндекс.Облака.

Безопасность в Яндекс.Облаке

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

Безопасность cloud-инфраструктуры Яндекса имеет несколько уровней, на каждом из которых реализованы собственные принципы защиты и применяется отдельный арсенал технологий.

Физический уровень

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

Кроме того, аппаратные средства Облака физически отделены от «большого Яндекса»: они расположены в разных стойках, но в точности так же проходят регулярное регламентное обслуживание и замену комплектующих. На границе этих двух инфраструктур используются аппаратные файрволы, а внутри Облака — программный Host-based Firewall. Кроме того, на коммутаторах Top-of-the-rack применяется система управления доступом ACL (Access Control List), что значительно повышает безопасность всей инфраструктуры.
Яндекс на постоянной основе проводит сканирование Облака извне в поисках открытых портов и ошибок в конфигурации, благодаря чему потенциальную уязвимость можно распознать и ликвидировать заранее. Для работающих с ресурсами Облака сотрудников реализована централизованная система аутентификации по ключам SSH с ролевой моделью доступа, а все сессии администраторов логируются. Такой подход является частью повсеместно применяемой Яндексом модели Secure by default: безопасность закладывается в IT-инфраструктуру еще на этапе ее проектирования и разработки, а не добавляется потом, когда все уже запущено в эксплуатацию.

Инфраструктурный уровень

На уровне «аппаратно-программной логики» в Яндекс.Облаке используются три инфраструктурных сервиса: Compute Cloud, Virtual Private Cloud и Yandex Managed Services. А теперь о каждом из них чуть подробнее.

Compute Cloud

Этот сервис предоставляет масштабируемые вычислительные мощности для различных задач, таких как размещение веб-проектов и высоконагруженных сервисов, тестирование и прототипирование или временная миграция IT-инфраструктуры на период ремонта либо замены собственного оборудования. Управлять сервисом можно через консоль, командную строку (CLI), SDK или API.

Безопасность Compute Cloud базируется на том, что все клиентские виртуальные машины используют минимум два ядра, а при распределении памяти не применяется overcommitment. Поскольку в этом случае на ядре исполняется только клиентский код, система не подвержена уязвимостям вроде L1TF, Spectre и Meltdown или атакам на побочные каналы.

Читать еще: Когда тебя внесли в черный список. Как обойти черный список в одноклассниках

Кроме того, Яндекс использует собственную сборку Qemu/KVM, в которой отключено все лишнее, оставлен только минимальный набор кода и библиотек, необходимых для работы гипервизоров. При этом процессы запускаются под контролем инструментария на базе AppArmor, который с использованием политик безопасности определяет, к каким системным ресурсам и с какими привилегиями может получить доступ то или иное приложение. AppArmor, работающий поверх каждой виртуальной машины, уменьшает риск того, что клиентское приложение сможет получить доступ из ВМ к гипервизору. Для получения и обработки логов Яндекс выстроил процесс поставки данных от AppArmor и песочниц в собственный Splunk.

Virtual Private Cloud

Сервис Virtual Private Cloud позволяет создавать облачные сети, используемые для передачи информации между различными ресурсами и их связи с интернетом. Физически этот сервис поддерживается тремя независимыми ЦОД. В этой среде логическая изоляция осуществляется на уровне многопротокольного взаимодействия — MPLS. При этом Яндекс постоянно проводит fuzzing стыка SDN и гипервизора, то есть со стороны виртуальных машин во внешнюю среду непрерывно направляется поток неправильно сформированных пакетов с целью получить отклик от SDN, проанализировать его и закрыть возможные бреши в конфигурации. Защита от DDoS-атак при создании виртуальных машин включается автоматически.

Yandex Managed Services

Yandex Managed Services — это программное окружение для управления различными сервисами: СУБД, кластерами Kubernetes, виртуальными серверами в инфраструктуре Яндекс.Облака. Здесь большую часть работы по обеспечению безопасности сервис берет на себя. Все резервное копирование, шифрование резервных копий, Vulnerability management и так далее обеспечивается автоматически программными средствами Яндекс.Облака.

Инструменты реагирования на инциденты

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

При выборе инструментария Яндекс руководствовался еще одним важным требованием: в случае успешной эксплуатации 0day-уязвимости в одном из приложений злоумышленник не должен выйти за пределы хоста приложения, в то время как команда безопасности должна моментально узнать об инциденте и среагировать нужным образом.

И последнее, но не самое маловажное пожелание заключалось в том, чтобы все инструменты имели открытый исходный код. Этим критериям полностью соответствует связка AppArmor + Osquery, которую и решено было использовать в Яндекс.Облаке.

AppArmor

AppArmor уже упоминался выше: это программный инструмент упреждающей защиты, основанный на настраиваемых профилях безопасности. Профили используют технологию разграничения доступа на основании меток конфиденциальности Mandatory Access Control (MAC), реализуемую с помощью LSM непосредственно в самом ядре Linux начиная с версии 2.6. Разработчики Яндекса остановили свой выбор на AppArmor по следующим соображениям:

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

Osquery

Osquery — это инструмент мониторинга безопасности системы, разработанный компанией Facebook, сейчас он успешно применяется во многих IT-отраслях. При этом инструмент кросс-платформенный и имеет открытый исходный код.

С помощью Osquery можно собирать информацию о состоянии различных компонентов операционной системы, аккумулировать ее, трансформировать в стандартизированный формат JSON и направлять выбранному получателю. Этот инструмент позволяет писать и направлять приложению стандартные SQL-запросы, которые сохраняются в базе данных rocksdb. Можно настроить периодичность и условия выполнения или обработки этих запросов.

В стандартных таблицах уже реализовано много возможностей, например можно получить список запущенных в системе процессов, установленных пакетов, текущий набор правил iptables, сущности crontab и прочее. «Из коробки» реализована поддержка получения и парсинга событий из системы аудита ядра (используется в Яндекс.Облаке для обработки событий AppArmor).

Сам Osquery написан на C++ и распространяется с открытыми исходниками, можно их модифицировать и как добавлять новые таблицы в основную кодовую базу, так и создавать свои расширения на C, Go или Python.

Полезная особенность Osquery — наличие распределенной системы запросов, с помощью которой можно в режиме реального времени выполнять запросы ко всем виртуальным машинам, находящимся в сети. Это может быть полезно, например, если обнаружена уязвимость в каком-либо пакете: с помощью одного запроса можно получить список машин, на которых установлен этот пакет. Такая возможность широко используется при администрировании больших распределенных систем со сложной инфраструктурой.

Выводы

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

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

Поскольку Яндекс.Облако предоставляет своим клиентам защищенную инфраструктуру со всеми необходимыми инструментами обеспечения безопасности, они могут сосредоточиться на бизнес-процессах, оставив задачи сервисного обслуживания и мониторинга железа провайдеру. Это не устраняет необходимости текущего администрирования ВМ, БД и приложений, но такой круг задач пришлось бы решать в любом случае. В целом можно сказать, что Яндекс.Облако экономит не только деньги, но и время. А второе, в отличие от первого, невосполнимый ресурс.

Облачные вычисления безопасности – Cloud computing security

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

содержание

Вопросы безопасности, связанные с облаком

Облачные вычисления и хранения данных предоставляет пользователям возможности хранить и обрабатывать свои данные в сторонних центров обработки данных . Организации используют облако в различных моделей обслуживания (с аббревиатурами , таких как SaaS , PaaS и IaaS ) и модели развертывания ( частное , публичное , гибрид , и сообщества ). Проблемы безопасности , связанная с облачными вычислениями , делятся на две основные категории: вопросы безопасности , с которыми сталкиваются поставщиками облачных услуг (организации , обеспечивающими программны , от платформы или инфраструктура как услуга через облако) и проблемы безопасности , с которыми сталкиваются их клиенты (компании или организации которые хост – приложение или хранить данные на облаке). Ответственность разделена, однако. Поставщик должен гарантировать , что их инфраструктура находится в безопасности и что данные и приложение своих клиентов защищены, в то время как пользователь должен принять меры , чтобы укрепить их применение и использовать надежные пароли и меры аутентификации.

Когда организация выбирает для хранения данных или хост – приложений на публичном облаке, она теряет способность иметь физический доступ к серверам хостинга своей информации. В результате, потенциально чувствительные данные риск от инсайдерских атак. Согласно недавнему Cloud Security Alliance доклада, инсайдерская атака является шестым самым большой угрозой в области облачных вычислений. Таким образом, поставщики облачных услуг должны гарантировать , что тщательные проверки анкетных проводятся для сотрудников , которые имеют физический доступ к серверам в центре обработки данных. Кроме того, центры обработки данных должны часто контролироваться на предмет подозрительной активности.

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

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

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

архитектура Облако безопасности является эффективной только тогда, когда правильные оборонительными реализации на месте. Эффективная архитектура безопасности облака следует признать проблемы, которые будут возникать в управлении безопасностью. Управление безопасности устраняет эти проблемы с контролем безопасности. Эти элементы управления созданы для защиты слабых мест в системе и уменьшить эффект атаки. Хотя существует много видов контроля за архитектуры безопасности облака, они, как правило, можно найти в одной из следующих категорий:

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

Размеры облака безопасности

Как правило , рекомендуется , что контроль информационной безопасности будут выбраны и реализованы в соответствии и в пропорции к рискам, как правило , путем оценки угроз, уязвимостей и воздействий. Проблемы безопасности Облачные могут быть сгруппированы по – разному; Gartner назвал семь в то время как Cloud Alliance Security определил двенадцать проблемных областей. Облако брокеры безопасности доступа (CASBs) программное обеспечение , которое находится между пользователями облачных и облачными приложениями , чтобы обеспечить видимость в использование облачных приложений, защиты данных и управление для контроля всей деятельности и обеспечения соблюдения политик безопасности.

Безопасность и конфиденциальность

Облако уязвимости и тестирования на проникновение

Сканирование может снаружи и изнутри , используя бесплатные или коммерческие продукты , очень важно , потому что без затвердевшей среды вашей службы рассматриваются как мягкая мишень. Виртуальные сервера должны быть закалены как физический сервер от утечки данных , вредоносных программ и используемых уязвимостей. «Потеря данных или утечка представляет собой 24,6% и облако , связанные с Malware 3.4% угрозы вызывает облако отключений»

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

Безопасность данных

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

конфиденциальность

Конфиденциальность данных является собственностью, что содержание данных не доступны или раскрываться незаконных пользователей. Outsourced данные хранятся в облаке и вне прямого контроля владельцев. Только авторизованные пользователи могут получить доступ к конфиденциальным данным, в то время как другие, в том числе ПСА, не должно получить какую-либо информации о данных. В том же время, владельцы данных ожидают в полную мере использовать услуги облачных данных, например, поиск данных, вычисления данных и совместное использование данных, без утечки содержимого данных в ИЕ или другие противник.

управляемость Доступ

контролируемость доступа означает, что владелец данных может выполнить выборочное ограничение доступа к ней или его данным отданных облака. Юридические пользователи могут быть санкционированы владельцем для доступа к данным, в то время как другие не могут получить доступ к нему без разрешения. Кроме того, желательно применять мелкозернистый контроль доступа к аутсорсингу данных, то есть, разные пользователи должны быть предоставлены различные права доступа в отношении различных частей данных. Разрешение доступа должно контролироваться только владельцем в ненадежных облачных средах.

целостность

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

шифрование

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

Шифрование атрибутов на основе (ABE)

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

Гипертекст-политика ABE (CP-ABE)

В CP-ABE, то шифратор контролирует стратегию доступа. Основная исследовательская работа CP-ABE сосредоточена на разработке структуры доступа.

Читать еще: Лучшие зарядные устройства на солнечных батареях. Лучшие внешние аккумуляторы с солнечной батареей

Key-политика ABE (KP-ABE)

В КП-ABE, наборы атрибутов используются для описания зашифрованных текстов и закрытые ключи, связанные с указанной политики, что пользователи будут иметь.

Полностью гомоморфна шифрование (FHE)

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

Searchable шифрования (SE)

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

податливость

Подобные законы могут применяться в различных правовых системах и может отличаться весьма существенно от тех, в силу в США. Пользователи сервиса Cloud могут часто должны быть осведомлены о правовых и регулятивных различиях между юрисдикциями. Например, данные, сохраненные поставщиком услуг облака могут быть расположены в, скажем, Сингапуре и отражение в США.

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

Обеспечение непрерывности бизнеса и восстановления данных Провайдеры облачных имеют непрерывности бизнеса и восстановления данных планов в месте , чтобы гарантировать , что обслуживание может поддерживаться в случае стихийного бедствия или чрезвычайной ситуации , и что любые потери данных будут восстановлены. Эти планы могут быть переданы и рассмотрены их клиентами, в идеале ласточкина хвоста с собственным обеспечением непрерывности клиентов. Совместные учения непрерывности могут быть уместными, имитируя большую неудачу в Интернете или электроэнергии, например. Журнал регистрации и аудита В дополнении к производству журналов и аудита , провайдеры облачных работы со своими клиентами , чтобы гарантировать , что эти журналы и журналы аудит были надежно закреплены, поддерживаться до тех пор , пока клиент требует, и доступны для целей судебно – медицинской экспертизы (например, поиск необходимого ) , Уникальные технические требования В дополнение к требованиям, к которым клиенты подвергаются, в центрах обработки данных, используемые поставщиками облачных может быть также при условии соблюдения требований соответствия. Использование поставщика облачных услуг (CSP) может привести к дополнительным проблемам безопасности вокруг юрисдикции данных, поскольку данные о клиентах или арендатор не может оставаться в той же системе, или в том же самом центре обработки данных или даже в пределах одного и того же облака провайдера. Европейский союз GDPR регулирования ввели новые требования для соблюдения данных клиента.

Юридические и договорные вопросы

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

Публичные записи

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

УГРОЗЫ БЕЗОПАСНОСТИ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ

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

В соответствии со всем вышесказанным, можно выделить следующие основные черты облачных вычислений:

1) облачные вычисления представляют собой новую парадигму предоставления вычислительных ресурсов;

2) базовые инфраструктурные ресурсы (аппаратные ресурсы, системы хранения данных, системное программное обеспечение) и приложения предоставляются в виде сервисов;

3) данные сервисы могут предоставляться независимым поставщиком для внешних пользователей по принципу «оплата по мере использования», основными особенностями облачных вычислений являются виртуализация и динамическая масштабируемость;

4) облачные сервисы могут предоставляться конечному пользователю через веб-браузер или посредством определенного программного интерфейса API (Application Programming Interface) [1].

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

Рис. 1. Общая модель и основные особенности облачных вычислений

При перемещении существующих физических виртуальных машин (ВМ) из центра обработки данных (ЦОД) во внешние облака или предоставление IT-сервисов вне безопасного периметра в частных облаках, приводит к тому, что периметр сети полностью теряет смысл, а общий уровень безопасности становится довольно низким.

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

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

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

Ещё одной угрозой является угроза целостности данных: компрометации и кражи данных. Целостность операционной системы и файлов приложений, а так же внутренняя активность должны контролироваться.

Использование многопользовательских облачных сервисов усложняет следование требованиям стандартов и законов, включающих в себя требования использования криптографических средств, для защиты важной информации, такой как информация о владельце кредитной карты и информации идентифицирующей человека. Это в свою очередь, порождает непростую задачу обеспечения надёжной защиты и безопасного доступа к важным данным [2].

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

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

Литература:

1. Радченко Г.И. Распределённые вычислительные системы // Учебное пособие. – 2012. – С. 146-149.

2. Кондрашин М. Безопасность облачных вычислений // Storage News. – 2010. – №1.

Автор: Борискин В.С.

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

In article there is an analysis of possible security threats in cloud IT-infrastructure, based on the specifics, deployment models and cloud computing architecture.

Облачные вычисления безопасности – Cloud computing security

содержание

Вопросы безопасности, связанные с облаком

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

Размеры облака безопасности

Безопасность и конфиденциальность

Облако уязвимости и тестирования на проникновение

Читать еще: Процессор A9 от Samsung прожорливей аналога от TSMC. Микропроцессор Apple A9: технические характеристики, преимущества, где используется? Процессор a9 с 64 битной архитектурой

Безопасность данных

конфиденциальность

управляемость Доступ

целостность

шифрование

Шифрование атрибутов на основе (ABE)

Гипертекст-политика ABE (CP-ABE)

Key-политика ABE (KP-ABE)

Полностью гомоморфна шифрование (FHE)

Searchable шифрования (SE)

податливость

Юридические и договорные вопросы

Публичные записи

К вопросу о безопасности облачных технологий в информационной среде

Дата публикации: 16.04.2014 2014-04-16

Статья просмотрена: 1594 раза

Библиографическое описание:

Котяшичев, И. А. К вопросу о безопасности облачных технологий в информационной среде / И. А. Котяшичев, С. В. Смоленцев. — Текст : непосредственный // Молодой ученый. — 2014. — № 5.1 (64.1). — С. 25-28. — URL: https://moluch.ru/archive/64/10351/ (дата обращения: 26.05.2020).

В данной статье автор раскрывает определение, назначение облачных вычислений, а также определяет направления защиты и обеспечения безопасности их свойств, основные достоинства и недостатки.

Облачные вычисления (англ. cloud computing) – технология распределённой обработки данных, в ней компьютерные ресурсы и мощности предоставляются как Интернет-сервис.

Ключевой вопрос облачных вычислений – расположение приложений. Существуют три модели расположения приложений (см. рис 1):

Рисунок 1. Модели расположения приложений

– в инфраструктуре заказчика (полный контроль за инфраструктурой, аппаратным и программным обеспечением при высоких капитальные затратах);

– у компании-хостера (меньший контроль за инфраструктурой, аппаратным и программным обеспечением, базируется на оплате фиксированного числа ресурсов, что обычно предполагает оплату даже в тех случаях, когда арендуемые ресурсы не используются);

– в облаке (отсутствует контроль за инфраструктурой, аппаратным обеспечением) [1].

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

Основными характеристиками облачных вычислений являются:

– масштабируемость (масштабируемое приложение обеспечивает большую нагрузку за счет увеличения количества запущенных экземпляров);

– эластичность (позволяет быстро нарастить мощность инфраструктуры без внедрения инвестиций в оборудование и программное обеспечение);

– мультитенантность (снижает расходы на облачную платформу и использует доступные вычислительные ресурсы);

– оплата за использование (перевод части капитальных издержек в операционные);

– самообслуживание (позволяет потребителям запросить и получить требуемые ресурсы за считанные минуты).

Облачные вычисления и предоставляемые ими сервисы можно сравнить с коммунальными услугами. Как в жару или холод меняется потребление воды и электричества, так и потребление сервисов, предоставляемых «облачными» платформами, может возрастать или уменьшаться в зависимости от повышения или понижения нагрузок [2].

Схожесть сервисов и коммунальных услуг заключается в том, что:

во-первых, потребители платят только за реальную утилизацию;

во-вторых, ресурсы берутся в аренду – т.е. поставщики таких сервисов обеспечивают их доступность в виде арендуемых «ресурсов», оставляя за собой вопросы создания и поддержания инфраструктуры;

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

Говоря про «облачные» платформы, употребляют словосочетание «. как сервис». Выделяют следующие основные сервисы:

– программное обеспечение как сервис (SaaS) – обеспечивает аренду приложений. Потребители этих сервисов – конечные пользователи, они работают с приложениями в «облаке». Модель предоставления программного обеспечения как сервиса – модель обеспечения доступа к приложениям через Интернет с оплатой по факту их использования;

– платформа как сервис (PaaS) – предоставляет возможность аренды платформы. Потребители – сами компании, разработавшие приложения. Платформа обеспечивает среду для выполнения приложений, сервисы по хранению данных и ряд дополнительных сервисов, например, интеграционные или коммуникационные;

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

Основными достоинствами облачных вычислений являются:

– доступность (облака доступны всем, из любой точки, где есть Интернет, с любого компьютера, где есть браузер);

– низкая стоимость (1)снижение расходов на обслуживание виртуальной инфраструктуры; 2) пользователь «облака» платит за фактическое использование вычислительных мощностей; 3) использование «облака» на правах аренды; 4)развитие аппаратной части вычислительных систем ).

– гибкость (неограниченность ресурсов (память, процессор, диски));

– надежность (очень высокая, особенно в специально оборудованных ЦОД);

– безопасность («облачные» сервисы имеют высокую безопасность при должном ее обеспечении, однако при халатном отношении эффект может быть полностью противоположным);

– большие вычислительные мощности (пользователь «облачной» системы может использовать все ее вычислительные способности, заплатив только за фактическое время использования. Предприятия могут использовать данную возможность для анализа больших объемов данных).

Основными недостатками облачных вычислений являются:

– постоянное соединение с сетью (для получения доступа к услугам «облака» необходимо постоянное соединение с сетью Интернет);

– программное обеспечение и его кастомизация (есть ограничения по ПО, которое можно разворачивать на «облаках» и предоставлять пользователю);

– конфиденциальность (нет технологии, которая бы гарантировала 100% конфиденциальность хранимых данных);

– надежность (если информация, хранимая в “облаке” потеряна, то она потеряна навсегда);

– дороговизна оборудования (для построения собственного «облака» компании необходимо выделить значительные материальные ресурсы, что невыгодно только что созданным и малым компаниям);

– безопасность («облако» является надежной системой, но, проникнув, злоумышленник получает доступ к огромному хранилищу данных, а также эта система может подвергнуться вирусной атаке). Безопасности в облачных технологиях рассмотрим более подробно.

Один из минусов облачных технологий состоит в их главном принципе – “облачности”. Человек не знает, где хранятся, обрабатываются и как защищены его данные. А незнание означает отсутствие контроля. Поэтому пользователь либо полагается на хорошую репутацию хостинг-провайдера, либо отказывается пользоваться такими технологиями.

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

Распространение услуг шифрования в “облаках” идет крайне медленно по ряду причин. Основная причина – это нагрузка. Шифрование, встроенное в облачную инфраструктуру, будет сильно тормозить работу приложений. Дешифрование также может сказаться на дальнейшей работе приложения. Задержки при постоянных циклах шифрования-дешифрования могут сильно сказаться на работе системы, вплоть до разрушения. Для решения этой проблемы специалисты предлагают шифровать не всю виртуальную среду, а только сами данные. Этот процесс тоже повлияет на работу системы, но в гораздо меньшей степени. И при этом обеспечит защиту информации.

Следующий немаловажный изъян можно обозначить как «пробелы в законе».

Несовершенство законодательства делают облачные технологии в России в плане защиты информации крайне уязвимыми. В законе “О персональных данных” не прописано, кто является владельцем системы, если хотя бы часть ее находится в “облаке”. При работе с облачными приложениями пользователи сталкиваются и с рядом других проблем. Например, если в “облако” нужно перенести персональные данные клиентов компании, то их необходимо зашифровать, причем по системе криптографии, сертифицированной в ФСБ. Облачных приложений, которые прошли бы подобную процедуру, в настоящее время нет. И когда они появятся, неизвестно.

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

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

Рекомендации по облачной безопасности для операторов и пользователей

Приватность пользовательской информации

Зонирование выделенной сети, переадресация принимаемых данных.

голоса

Рейтинг статьи