7 основных ошибок безопасности при переходе на облачные приложения

Автор оригинала: David Strom
  • Перевод
image

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

Вступление


В связи с пандемией многие предприятия перешли на использование большего количества облачных приложений по необходимости потому, что всё больше из нас работают удаленно. В опросе 200 ИТ-менеджеров, проведенном Menlo Security, 40% респондентов заявили, что они сталкиваются с растущими угрозами со стороны облачных приложений и атак Интернета вещей (IoT) из-за этой тенденции.

Есть хорошие и плохие способы осуществить эту миграцию в облако. Многие подводные камни не новы. Например, на одной встрече Gartner 2019 два ИТ-менеджера заявили, что их развертывание Office 365 было приостановлено из-за необходимости обновления устаревшего оборудования. Теперь то, как мы используем и совместно используем наши домашние компьютеры, изменилось. Наши компьютеры больше не личные. Этот же компьютер может поддерживать виртуальную школу вашего ребенка и приложения вашего супруга.

Летний опрос CyberArk показал, что более половины респондентов сохраняют свои пароли в браузерах корпоративных ПК. Конечно, это не обещает ничего хорошего ни для какой политики безопасности.

Вот семь основных ошибок, которые негативно влияют на безопасность, и несколько советов, как их избежать.

1. Использование VPN для удаленного доступа


Со всеми удаленными сотрудниками, VPN может быть не лучшим решением для доступа. Посмотрите, что произошло в декабре 2020 года со взломом FireEye. По всей видимости, взломанная учетная запись VPN была отправной точкой для хакера кражи его инструментов. В прошлом виртуальные частные сети были основным способом защиты удаленных сотрудников.

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

2. Создание неправильного облачного портфеля


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

Доступны ли версии для запуска определенных приложений, зависящих от определенных конфигураций Windows и Linux? Есть ли у вас подходящие соединители и средства защиты аутентификации для работы с локальными приложениями и оборудованием, которое вы не переносите? Если у вас есть устаревшее приложение для мэйнфреймов?

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

3. Ваша политика безопасности не подходит для облака


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

Johnson & Johnson сделали это несколько лет назад, когда перенесли большую часть своих рабочих нагрузок в облако и централизовали свою модель безопасности. Есть помощь: Netflix только что выпустил инструмент с открытым исходным кодом, который они называют — ConsoleMe. Он может управлять несколькими учетными записями Amazon Web Services (AWS) в одном сеансе браузера.

4. Не тестировать планы аварийного восстановления


Когда вы в последний раз тестировали свой план аварийного восстановления (DR)? Возможно, это было слишком давно, особенно если вы были заняты повседневными проблемами, связанными с поддержкой домашних работников.

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

Еще одна важная часть любого плана аварийного восстановления — это непрерывное тестирование на предмет частичных сбоев облака. Скорее всего, у вас будут перебои в работе. Даже Amazon, Google и облака Microsoft испытывают это время от времени. Netflix был одним из первых мест, где несколько лет назад стала популярной общая инженерия хаоса с помощью инструмента под названием Chaos Monkey. Он был разработан для тестирования инфраструктуры AWS компании путем постоянного и случайного отключения различных рабочих серверов.

Используйте эти уроки и инструменты, чтобы разработать собственное тестирование отказов, особенно тесты, связанные с безопасностью, которые выявляют слабые места в вашей облачной конфигурации. Ключевой элемент — делать это автоматически и постоянно, чтобы выявлять узкие места и недостатки инфраструктуры. Помимо использования инструментов с открытым исходным кодом от Netflix, есть коммерческие продукты, такие как Verodin / Mandiant's Security Validation, SafeBreach’s Breach and Attack Simulation, инструменты моделирования Cymulate и AttackIQ's Security Optimization Platform.

5. Не оптимизирована аутентификация для портфеля с преобладающим облачным сервисом


У вас может быть учетная запись и управление доступом, SIEM, CASB или одно — инструмент входа в систему, который был приобретен в эпоху локальных сетей. Теперь не соответствует вашим потребностям в проверке подлинности, преимущественно облачном мире, и мире удаленного доступа.

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

6. Устаревший Active Directory


«Идентичность — это теперь новый периметр, и данные распространяются повсюду», — заявили Дэвид Махди и Стив Райли из Gartner в своей презентации.

«Вы должны предоставить людям правильный доступ к нужным ресурсам, в нужное время и по правильной причине».

Разумеется, здесь стоит многое исправить. Это означает, что ваша Active Directory (AD) может не отражать реальность как из списка текущих и авторизованных пользователей, так и из текущих и авторизованных приложений и серверов.

Переход в облако будет более плавным, если вы будете переносить наиболее точную информацию.

7. Отказ обратиться за помощью


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

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

Комментарии 6

    +3

    Одна ошибка — сам переход на облачные приложения. Всё остальное не существенно

      +1
      Как показала практика, в переходе в облака есть один «маленький минус»…
        0
        Подскажите, где почитать аргументацию?
        +2
        Гуглом переводили?
          0
          Все есть в первоисточнике AWS WAF — Security Pillar: wa.aws.amazon.com/wat.pillar.security.en.html
            0
            Неплохой слог, сторителлинг на уровне. Автор витает в облаках

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое