Спешка при переносе ключевых корпоративных приложений в облако ведет к ослаблению общей защищенности корпоративной среды. Для того, чтобы эти ошибки не стали критическими и не нанесли компании непоправимый вред, необходимо избегать ошибок, хотя бы самых распространенных.
Затраты на облачную безопасность растут опережающими темпами
В условиях пандемии во многих организациях увеличили объемы использования облачных приложений в связи с потребностью организовать дистанционную работу для сотрудников. Общие рекомендации по укреплению облачной безопасности соблюдают многие. Нужно обеспечить полную прозрачность обновленной инфраструктуры, особенно если это гибридная облачная среда, в которой данные распределены между локальными серверами и внешними сервисами. Само собой, необходимо обучение сотрудников с разъяснением практик безопасности — это поможет избежать неверных настроек, помешать успеху фишинговых атак и обеспечить своевременное уведомление о вероятных инцидентах. При проведении любых изменений заботиться о безопасности нужно с самого начала, причем лучше осваивать практики DevSecOps. Нужны механизмы непрерывного мониторинга работы всех систем и шифрования данных во всех состояниях. И, конечно, не стоит впадать в заблуждение относительно того, что переход данных в облако означает перенос заботы об их безопасности на плечи оператора — в случае утечки пострадает репутация именно вашей компании, и именно ей придется нести убытки, финансовые и репутационные, а в некоторых случаях — еще и платить штрафы, предусмотренные регуляторами.
Мировые расходы на безопасность растут даже в условиях стагнации и падения ИТ-бюджетов. Расходы на облачную безопасность увеличиваются очень быстро.
Мировые расходы на информационную безопасность в 2020 г., $млн
| Затраты в 2019 г. | Затраты в 2020 г. | Рост 2020/2019 (%) | |
| Безопасность приложений | 3 095 | 3 287 | 6,2% |
| Облачная безопасность | 439 | 585 | 33,3% |
| Безопасность данных | 2 662 | 2 852 | 7,2% |
| Системы индентификации и управления доступом (IAM) | 9 837 | 10,409 | 5,8% |
| Защита инфраструктуры | 16 52 | 17 483 | 5,8% |
| Комплексное управление рисками (IRM) | 4 555 | 4 731 | 3,8% |
| Оборудование сетевой защиты | 13 387 | 11 694 | -12,6% |
| Другое ПО | 2 206 | 2 273 | 3,1% |
| ИБ-сервисы | 61 979 | 64 27 | 3,7% |
| Потребительское ПО | 6 254 | 6 235 | -0,3% |
| Итого: | 120 934 | 123 818 | 2,4% |
Однако деньгами все проблемы не решишь. В процессе миграции в облако часто совершаются промахи, ведущие к ослаблению безопасности. В ходе опроса, проведенного Menlo Security среди 200 ИТ-директоров, 40% из них признались в том, что им приходится бороться с растущим количеством атак, исходящих не только от облачных приложений, но и от систем интернета вещей.
Во многих случаях, кстати, проблемы не отличаются новизной. Например, ИТ-директора, принимавшие участие в одном из мероприятий Gartner, сетовали на то, что внедрение Office 365 в их организациях затормозилось из-за того, что, как оказалось, облачный офисный пакет требует для работы более мощного оборудования.
Что касается дистанционной работы, проблемы могут возникнуть просто из-за того, что домашними компьютерами пользуются сразу несколько членов семьи. Один и тот же ноутбук может применяться для онлайн-обучения детей через Zoom и для работы родителей в корпоративных приложениях. Опрос, который летом прошлого года провела компания CyberArk, показал, что больше половины пользователей сохраняют свои рабочие пароли в браузерах, а это противоречит элементарным правилам безопасности.
Семерку упущений, которые часто делают при осуществлении проектов облачной миграции, перечисляет специалист по безопасности Дэвид Стром (David Strom).
1. Выбор неподходящей конфигурации облака
Речь идет об ошибке, когда упускают из виду сразу несколько факторов. Прежде всего, стоит задуматься о том, что, возможно, вам нужно частное облако для изоляции критических бизнес-данных. Также, если в вашей среде есть приложения, способные работать только на определенных конфигурациях Windows и Linux, нужно убедиться, что такие системы будут доступны в выбранном облаке. Кроме того, стоит позаботиться о доступности коннекторов и средств защищенной аутентификации для локальных приложений и оборудования, миграция которых в облако невозможна. А если у вас применяются приложения для мэйнфрейма, их лучше для начала перенести в частное облако, а впоследствии выбрать среду, которая максимально точно воспроизводит его особенности.
2. Общее пренебрежение правилами облачной безопасности
В числе типичных ошибок облачной безопасности — незащищенные контейнеры для хранения данных, неверные настройки прав доступа и параметров аутентификации, многочисленные открытые порты. О мерах безопасности надо заботиться с самого начала, при переносе самого первого приложения в облако, и необходимо обеспечить единство политик безопасности, которые будут действовать как при работе в офисе, так и при дистанционной — независимо от местонахождения пользователя. Помочь в подобных инициативах могут специальные инструменты. Например, в Netflix разработали сервис с открытым кодом ConsoleMe, который позволяет управлять многочисленными службами Amazon Web Services в одной вкладке браузера.
3. Применение средств аутентификации, не подходящих для облака
Возможно, ваша организация располагает системами единого входа, управления идентификацией и доступом, управления событиями безопасности (Security Information and Event Manager, SIEM) или брокером безопасности доступа к облаку (Cloud Access Security Broker, CASB). Но закуплены эти решения были еще в эпоху локальных систем и они не подходят для нынешней ситуации господства облаков и дистанционной работы. Соответственно, нужно уточнить, можно ли использовать имеющиеся системы со всеми приложениями, переносимыми в облако, и обеспечат ли они адекватную защиту. Среди перечисленных видов систем CASB достаточно эффективны в деле управления доступом к облачным приложениям, однако вам могут понадобиться и другие средства — специализированная система для приложений, разработанных в вашей организации, решение для аутентификации на основе риска или инструменты защиты от сложных угроз.
4. Пренебрежение тестированием планов аварийного восстановления
Когда вы последний раз проверяли, работает ли подготовленный в вашей организации план аварийного восстановления? Не исключено, что давно, так как все время уходило на решение бесчисленных проблем, связанных с поддержкой штата надомных работников. Даже если ваши приложения в облаке, они по-прежнему зависят от конкретных серверов, баз данных и других традиционных элементов инфраструктуры. В рамках плана аварийного восстановления обязательно надо задокументировать эти зависимости и завести сборник схем, описывающий наиболее критические рабочие процессы.
Кроме того, требуется непрерывное тестирование работоспособности вашей среды на случай отказа облачных служб. Отказы неизбежны — время от времени они происходят даже в облаках Amazon, Google и Microsoft. Поэтому, не дожидаясь реального сбоя, необходимо самостоятельно тестировать свои облачные платформы на «сопротивляемость» пертурбациям, в том числе — отключая работающие серверы для того, чтобы убедиться, что резервные системы подхватывают рабочие нагрузки.
При этом важно организовать автоматическое тестирование в непрерывном режиме, что позволит обнаруживать узкие места и ошибки конфигурации по мере внесения изменений.
5. Устаревшие данные каталогов Active Directory
Система управления учетными записями — это новый периметр, через который то и дело проходят новые данные, напоминают аналитики Gartner, добавляя о необходимости строгого разграничения прав доступа по ролям, ресурсам, времени и другим параметрам. Для этого каталоги Active Directory должны отражать самые актуальные сведения о пользователях, приложениях, серверах и их полномочиях. Проверьте: возможно, пришло время доставать «садовые ножницы» для вашего дерева каталогов. Приступая к миграции в облако, удостоверьтесь, что туда будет перенесена самая свежая и точная информация.
6. Использование VPN для удаленного доступа
VPN — не лучший вариант доступа при дистанционной работе. За примерами далеко ходить не надо — в конце прошлого года взломали системы компании FireEye, которая сама предоставляет услуги обеспечения сетевой безопасности. Есть предположения, что это было сделано путем сложнейшей атаки, организованной группировкой искусных хакеров, однако все указывает на то, что интеллектуальная собственность FireEye была похищена путем проникновения в ее сеть с помощью скомпрометированной учетной записи VPN.
Когда-то сети VPN были фактическим стандартом защиты удаленного доступа к корпоративным сетям. Но сегодня вместо VPN лучше прибегать к применению архитектур с нулевым доверием, то есть сетей, в которых оба соединяющихся устройства по умолчанию считают друг друга ненадежными и должны для установления соединения предоставить друг другу подтверждения своей «личности». Кроме того, при разработке политики информационной безопасности необходимо учесть ситуации совместного использования домашних компьютеров.
7. Пренебрежение помощью
Содействие в облачных миграциях сегодня оказывают многие поставщики управляемых услуг, и не стоит принципиально отказываться от такой помощи. У вас, вероятно, и без того полно дел, чтобы можно было уделить все необходимое внимание переносу систем в облако — случайно упустить из виду нечто важное очень легко. Если чересчур торопиться с миграцией всех систем на облачные платформы, можно оставить уязвимые места и лазейки для злоумышленников.
