Вариант использования обычно описывает ситуацию, когда и как можно использовать систему, продукт или услугу. Обычно это короткий список действий, которые нужно предпринять, чтобы достичь цели.
Концепция вариантов использования очень широка. Вариант использования может, например, охватывать установку бампера на автомобиль; в мире безопасности они обычно охватывают метод атаки или анализ. Примером варианта использования безопасности, охватывающего атаку SQL, является пошаговая инструкция, в которой аналитик может найти данные и какие решения принять: найти журналы сети в X, найти журналы локальных приложений в Y, заблокировать источник на Z и эскалации при необходимости.
Есть много хорошо документированных случаев использования безопасности, доступных в Интернете, от вспышек вымогателей до мошенничества со стороны инсайдеров и кражи данных. Когда дело доходит до облачных сервисов, существуют также хорошие возможности, которые часто основаны на уникальных аспектах самих облачных сред.
Безусловно, самый важный контроль безопасности в облачных средах это управление учетными записями. Мало того, что учетные записи должны быть настроены с «наименьшими привилегиями», необходимыми для выполнения их обязанностей, их использование также необходимо постоянно контролировать.
Это особенно важно для административных учетных записей облачной платформы. Представьте, что такая учетная запись скомпрометирована: для злоумышленника было бы тривиально изменить конфигурации брандмауэра или добавить службы, где это необходимо.
Общие учетные записи, такие как «администратор», «администратор» или «root», не должны использоваться для обеспечения подотчетности. Необычная активность должна контролироваться и сравниваться с запланированными изменениями.
Любой доступ из регионов за пределами ожидаемых областей деятельности организации должен быть отмечен и исследован. Например, при входе из Бразилии в облачный аккаунт региональной сети австралийских супермаркетов должно появиться предупреждение (или оно должно быть предварительно заблокировано). Однако помните, что использование VPN или скомпрометированных локальных систем может обойти некоторые из этих мер.
Это, безусловно, самый важный вариант использования, но из-за его широкой области его можно разбить на несколько отдельных вариантов использования.
Облачная среда обычно содержит много ценных данных для злоумышленника. В конце концов, ценность данных и необходимость иметь высокодоступную и доступную платформу это причина, по которой организации должны мигрировать системы в облако.
Даже если объем данных в самой облачной среде ограничен, систему можно использовать как способ эксфильтрации локальных данных из локальной сети, потенциально обходя правила брандмауэра и предупреждения о трафике. Любые необъяснимые данные, покидающие облачные системы которые могут быть большими по объему, использовать подозрительный сетевой порт или могут содержать определенные строки или заголовки должны, по крайней мере, отслеживаться и, по возможности, также блокироваться на основе достоверности обнаружений.
Помимо контроля за отфильтрованными данными, следует контролировать сетевые соединения на предмет наличия средств удаленного доступа (RAT), SQL-инъекций, удаленных и локальных файловых инъекций и целого ряда других действий. Лучше всего это сделать с помощью системы обнаружения вторжений (или предотвращения).
Однако в большинстве облачных коммуникаций используется зашифрованный трафик. Шифрование великолепно, но в случае системы IDS оно делает его практически бесполезным; IDS не сможет видеть фактический трафик, поэтому ни одна подпись не может успешно совпадать.
Ответом здесь является дешифрование SSL, но оно будет сопровождаться некоторыми проблемами конфиденциальности и соответствия, которые необходимо тщательно проработать. Технические проблемы, связанные с платформой, связанные с расшифровкой SSL, вероятно, также потребуют помощи соответствующего поставщика облачных услуг.
Атака «Человек в облаке» ориентирована на токен аутентификации, находящийся на устройстве, таком как ПК или мобильный телефон. Этот токен может использоваться локальным приложением для автоматической аутентификации пользователя на облачной платформе. Злоумышленник будет стремиться заменить этот токен другим (обычно через кампанию по подбору фишинга), вместо этого направляя пользователя и его данные в облачный экземпляр атакующего. Результатом может быть синхронизация данных жертвы прямо в систему злоумышленника.
Мониторинг подключений к неизвестным облачным экземплярам с помощью мониторинга конечных точек, дешифрования SSL в сети или брокера Cloud Access Security (CASB) может обнаруживать и часто предотвращать эту активность.
Будь то контейнер или что-то еще, когда речь идет о хранении данных в облачной платформе, доступ к хранилищу данных должен тщательно контролироваться и контролироваться. Необходимо отслеживать большие неожиданные объемы входящих и исходящих данных, связанных с контейнером хранения, и исследовать доступ из подозрительных источников.
Доступно много, часто полностью автоматизированных сканеров, которые позволяют злоумышленнику легко находить незащищенные сегменты, такие как сканер S3 и AWSBucketdump. Там, где это возможно, вызовы API к платформе хранения должны отслеживаться на предмет подозрительной активности, но, опять же, для этого потребуется дешифрование SSL, чтобы работать, если нет подробных журналов облачного хранилища. Заключение
Облачная безопасность сопряжена со своими проблемами и вариантами использования. Некоторые из них более специфичны для облака, чем другие, но важно учитывать уникальные аспекты облачных сред.
Для начала важно сначала изложить требования для варианта использования например, выстроить в ряд необходимые журналы и инфраструктуру для их поддержки. Следующий шаг убедиться, что все эти требования соблюдены. Слишком часто организация в конечном итоге получает «сломанные» варианты использования и неактивные оповещения, потому что некоторая ключевая информация была структурно отсутствует, в то время как реализация варианта использования просто продолжалась.
