Основы выигрышной стратегии облачной безопасности

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

В 2016 году Amazon стала самой быстрой компанией, когда-либо достигшей годового объема продаж в 100 миллиардов долларов. Годовой объем продаж Amazon Web Services (AWS) достигает 10 миллиардов долларов, и это даже быстрее, чем веха, достигнутая Amazon.com. Amazon Web Services — наиболее широко распространенный поставщик облачной инфраструктуры как услуги. Быстрый темп развития предприятий, использующих Amazon Cloud, как никогда требует понимания и соблюдения передовых методов обеспечения безопасности ваших облачных развертываний.

Согласно недавнему отчету Gartner, «AWS является наиболее широко используемым в мире решением для публичной облачной инфраструктуры как услуги (IaaS) и лидирует в «Магическом квадранте» Gartner для инфраструктуры как услуги (IaaS). AWS предлагает большое количество встроенных функций безопасности, и количество вопросов о надлежащих методах защиты рабочих нагрузок в AWS растет».

Далее аналитики Gartner отмечают, что «AWS — это не облако IaaS потребительского уровня. Это лидер рынка с портфелем возможностей безопасности и партнерами по экосистеме безопасности, не имеющими себе равных у других поставщиков IaaS. Однако простой перенос существующих рабочих нагрузок в AWS без переосмысления инструментов безопасности, процессов и управления системой приведет к тому, что рабочие нагрузки станут менее безопасными, чем при размещении в корпоративных центрах обработки данных. И наоборот, правильно управляемая и защищенная рабочая нагрузка в AWS будет не менее, а в большинстве случаев и более безопасной, чем в корпоративном центре обработки данных ».

Поскольку AWS признана крупнейшим поставщиком публичного облака IaaS, я сосредоточусь на передовых практиках для AWS. Однако меры безопасности, обсуждаемые в этой серии, рассматриваются комплексно и применимы к большинству развертываний Enterprise Cloud. Важно отметить, что порядок тем в этой серии не совсем случайный. Многие из этих шагов являются последовательными и крайне важны для последовательного выполнения.

В первой части этой серии, посвященной обеспечению безопасности облачных развертываний, мы рассмотрим:

• Liftoff: почему стратегия и планирование имеют решающее значение для безопасного облака
• Двойственность: важность модели общей ответственности за безопасность
• ЗНАТЬ: глобальная инфраструктура безопасности вашего провайдера
• Исходное предотвращение отказоустойчивости: обнаружение

Liftoff: почему стратегия и планирование имеют решающее значение для безопасного облака

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

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

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

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

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

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

Сунь Цзы

Двойственность: важность модели общей ответственности за безопасность

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

Модель AWS Shared Security Responsibility является основой Amazon Security Platform. Модель общей ответственности за безопасность также является основой подавляющего большинства всех облачных развертываний. При подготовке к облачному развертыванию AWS очень важно понимать, что при использовании сервисов AWS клиенты сохраняют полный контроль над своим контентом и несут ответственность за соблюдение критически важных требований к безопасности контента.

Краткое изложение основных обязанностей клиента включает:

• Какой контент вы выбираете для хранения на AWS
• Какие сервисы AWS используются с вашим контентом
• Страна, в которой контент хранится в центре обработки данных AWS
• Формат и структура вашего контента, а также то, является ли он замаскированным, анонимным или зашифрованным.
• Кому вы предоставляете доступ к своему контенту и как эти права доступа предоставляются, управляются и отзываются

В то же время AWS понимает свои обязанности в модели облачной безопасности. В соответствии с моделью общей ответственности AWS:

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

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

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

«Мы должны сделать все, что в наших силах. Это наша священная человеческая ответственность». ~ Альберт Эйнштейн

ЗНАТЬ: глобальная инфраструктура безопасности вашего провайдера

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

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

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

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

AWS управляет своей глобальной облачной инфраструктурой с 35 «зонами доступности», которые вы используете для предоставления различных базовых вычислительных ресурсов, таких как обработка и хранение. Глобальная инфраструктура AWS включает средства, сеть, оборудование и операционное программное обеспечение (например, ОС хоста, программное обеспечение для виртуализации и т. д.), которые поддерживают предоставление и использование этих ресурсов. Глобальная инфраструктура AWS спроектирована и управляется в соответствии с передовыми методами обеспечения безопасности, а также с соблюдением различных стандартов безопасности. Как клиент AWS, вы можете быть уверены, что создаете веб-архитектуры на основе одной из самых безопасных вычислительных инфраструктур в мире.

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

«В Интернете нет локальности — каждый рынок является глобальным рынком». ~ Итан Цукерман

Исходное предотвращение отказоустойчивости: обнаружение

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

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

Обнаружение — важная часть платформы внедрения облачных вычислений AWS (или любой другой). Эта структура помогает нашим клиентам планировать свое путешествие. Среди прочего, в нем описывается ряд шагов миграции:

• Оцените текущее ИТ-предприятие
• Откройте для себя и спланируйте
• Строить
• Бежать

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

Сервис AWS Application Discovery автоматически собирает данные о конфигурации и использовании с серверов, хранилищ и сетевого оборудования для составления списка приложений, их производительности и взаимозависимости. Эта информация хранится в формате в базе данных AWS Application Discovery Service, которую вы можете экспортировать в виде файла CSV или XML в предпочитаемый вами инструмент визуализации или решение для миграции в облако, чтобы сократить время и сложность планирования миграции в облако.

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

Я верю, что это полезно, и поощряю ваши комментарии и вопросы!