Двунаправленные подходы к работе с облаком: критический взгляд на современные облачные инфраструктуры

3 сентября 2019 г.

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

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

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

Мультиоблачные инфраструктуры становятся нормой

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

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

Что бы вы ни планировали — всегда готовьтесь к изменениям

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

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

Кто отвечает за безопасность при трансформации облачных проектов?

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

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

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

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

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

В качестве заключения

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

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

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

Источник: Алексей Андрияшин, технический директор Fortinet в России