Процитирую известную американскую поговорку: облако - лучшее изобретение от нарезанного хлеба до наших дней!
Это одно из тех исторических изобретений, которые мягко, но неумолимо меняют привычки, рабочие парадигмы, бизнес-процессы, принимаемые большими и маленькими компаниями, способные обеспечить преемственность и в то же время глубокие инновации.
Именно эти последние характеристики делают его мощным до такой степени, что в течение некоторого времени он обсуждает тему гибридное облако - то есть тот, который состоит из традиционной и онлайн-частей, личного опыта и который полагается на общих поставщиков, построенный на улучшении процессов, которые существовали в течение некоторого времени и чья неэффективность известна в отношении глубоких инноваций в способах выполнения бизнес.
Если толчка - модного или нет - цифровой трансформации было недостаточно, недавняя ситуация с пандемией привела к возникновению чрезвычайных ситуаций и методов работы, которые еще больше обострили необходимость сделать процессы и приложения доступными удаленно и вездесущими в любое время и подключенными из любого места.
Это часто приводило к поспешной реакции, иногда воспринимаемой как упрощение со значительным сокращением затрат, часто определяемой как «подъем-и-сдвиг» и характеризующейся вытеснением серверов из традиционных корпоративных центров обработки данных в среду. облако Амазонки, микрософтезе или гуглици.
Однако проекты с более структурированным подходом предполагают реинжиниринг платформ приложений в соответствии с принципами Платформа-как-Сервис (или PaaS).
Если с точки зрения ИТ и разработки, этот современный и эффективный подход требовал фрагментации сервера на его основные компоненты, такие как хранилище, списки доступа, сети, базы данных и т. Д., То немногие заметили глубокую разницу с точки зрения безопасности., особенно в отношении совместной ответственности.
Amazon Web Services или AWS прекрасно сформулировали эту концепцию в предложении «Это разделение ответственности обычно называют облачной безопасностью по сравнению с облачной безопасностью». и столь же эффективно иллюстрируется следующим образом.
Эта схема, очень часто используемая для обучения компаний сознательной эволюции своих бизнес-процессов и схем, позволяющих использовать преимущества платформ. облако, представляет собой иногда чрезмерное упрощение концепции, которое я попытаюсь объяснить на примере.
Предположим, вымышленная компания ACME Ricambi Motoveicoli завершила свою первую цифровую трансформацию четыре года назад, внедрив серверную систему, доступную в Интернете и расположенную в ее центре обработки данных, для создания системы, предназначенной для онлайн-продажи своих продуктов и услуг.
В данном случае предположим, что решение было успешным, но оказалось слишком сложным и дорогостоящим в обслуживании из-за необходимой инфраструктуры.
Итак, в 2019 году проект развился с переездом серверов в облако, в надежде на снижение затрат.
Из-за пандемии, которая привела к увеличению числа пользователей, необходимость масштабирования ресурсов привела к тому, что затраты на реплики серверов выше, чем операционная эффективность, из-за монолитной структуры серверов (поспешность привела к выбору быстрого решения ...) .
Поэтому в конце 2020 года наша ACME Ricambi Motoveicoli решила провести полную ревизию проекта, которая фрагментировала отдельные компоненты серверов, создав их сбалансированные и масштабируемые экземпляры в облако. По сути, идея состоит в том, чтобы разделить то, что обычно определяет сервер - например, хранилище или дисковое пространство, базу данных, в которой хранятся данные, правила доступа к предоставляемым службам и так далее. Каждый фрагмент настраивается в облако индивидуально, с системой, которая умножает свои запросы по мере увеличения спроса. Этот подход идеален, поскольку он воспроизводит только те компоненты мозаики приложения, которые в нем нуждаются, оптимизируя соотношение инвестиций и производительности.
Если с точки зрения приложения и эксплуатации это правильный путь, то с точки зрения безопасности это требует глубокого изменения стратегий защиты - именно из-за типичной непрозрачности совместной ответственности.
Чтобы понять, что я имею в виду, давайте углубимся в приведенный выше график:
На первый взгляд, если вы хотите создать экземпляр хранилища и базы данных, то ответственность за обеспечение безопасности лежит на Amazon.
И это, безусловно, касается устойчивости хранилища и / или инстанса БД.
Упрощенная диаграмма не говорит нам о том, что если мы более внимательно посмотрим на эти два элемента в настройках безопасности, мы заметим следующее.
Конфигурация экземпляра хранилища, например Amazon S3 Bucket, по умолчанию имеет значение Permissions - Bucket Policy - Principal, значение по умолчанию *, что позволяет любому получить доступ к открытому и доступному хранилищу.
Экземпляр Amazon> RDS, то есть база данных, имеет конфигурацию базы данных по умолчанию без защиты от удаления.
Компромисс окружающей среды облако - например, для кражи учетных данных - позволит злоумышленникам удалить экземпляр базы данных, возможно, после передачи данных.
Эти два примера иллюстрируют, как вся концепция безопасности в парадигме PaaS требует знаний, которые обычно не доступны каждому; это означает необходимость обновления навыков группы безопасности, элемент, который часто не учитывается при планировании проекта. облако.
Также было бы желательно иметь специализированные решения для инвентаризации и анализа динамической конфигурации, возможно, способные охватить нескольких поставщиков услуг. облако. Таким образом, мы достигаем единого и органичного представления уязвимой поверхности, непосредственно отображаемого на видимой части окружающей среды. мульти-облако, возможности, которые обсуждались в предыдущей статье «От необработанных данных к полезной информации: наглядность и наблюдаемость».
Cloud Security Alliance, организация по культурному распространению безопасности в средах облако, выпустила две важные публикации, которые я рекомендую прочитать:
Коварные Двенадцать (Коварные двенадцать), в которой уже в 2016 году он перечислил двенадцать инцидентов в облако Причиной тому было в основном несоблюдение лучших практик в конфигурациях.
Внушительные Одиннадцать (Gli Egregi Eleven), в которой два года назад он представил анализ одиннадцати важных инцидентов, происхождение которых все еще часто было неправильной конфигурацией или слишком ограниченным доступом к ресурсам.
Il облако это, безусловно, путь к большей гибкости бизнеса и экономии на масштабе при контроле затрат на ИТ. Однако внедрение этой новой технологии не может игнорировать обновление навыков безопасности и улучшение возможностей видимости, наблюдаемости, обнаружения и реагирования, подходящих для этой новой задачи.
Для углубления:
https://www.theinnovationgroup.it/ll-cloud-ibrido-leva-strategica-per-il...
https://aws.amazon.com/it/compliance/shared-responsibility-model/
