Защита приложений: пять распространенных заблуждений

This post is also available in: Английский Французский Немецкий Итальянский Португальский, Бразилия Испанский

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

1-е заблуждение: «Я считал, что брандмауэра веб-приложений (WAF) будет достаточно»

Набор дополнительных угроз, которые часто игнорируются ИТ-специалистами, уже давно не исчерпывается эксплойтами, использующими десять основных уязвимостей веб-приложений, перечисленных сообществом OWASP. Да, внедрения кода (инъекционные атаки), межсайтовый скриптинг, межсайтовая подмена запросов (CSRF), перехваты сеансов, заражение файлов cookie и другие похожие методы по-прежнему опасны, особенно при наличии такого большого количества используемых устаревших систем без исправлений уязвимостей. Группы разработчиков уделяют больше внимания гибкости (agility), чем безопасности. При этом разнообразие атак и, как следствие, уровень риска в настоящее время существенно выше.

Ниже перечислены три новые угрозы, с которыми необходимо бороться:

1. Вредоносные боты — четверть интернет-трафика генерируется «плохими ботами» [CB1]. В условиях такой нагрузки на сети и постоянных попыток завладеть учетными записями пользователей, манипуляций с онлайн-транзакциями и скрапинга конфиденциальных данных организации не должны полагаться только на свой брандмауэр веб-приложений или, что еще хуже, тратить время на разработку собственных скриптов. Пора задуматься о специализированной технологии управления ботами, которая разрешает доступ «хорошим» ботам и преграждает путь вредоносным.

2. Защита API — взаимосвязанные системы и приложения, которые обмениваются данными посредством API. Как правило, они считаются надежными, поэтому их легко упустить из виду. Случаи кражи данных вследствие недостаточной защиты API неоднократно фигурировали в новостях (PaneraBread, Venmo, Boots и другие). Организации не всегда обладают информацией обо всех своих API и типах обрабатываемых ими данных, а также кто получает к ним доступ. Компаниям требуется эффективное средство для обнаружения, классификации и обеспечения безопасности всех конечных точек API.

3. Отказ в обслуживании (Denial of Service) — давно прошли те времена, когда атаки этого типа были головной болью только для операторов сетей. В настоящее время веб-серверы и цифровые ресурсы часто становятся мишенью злоумышленников, стремящихся нарушить работу сервиса или вывести из строя веб-сайт. При разработке стратегии обеспечения безопасности приложений целесообразно внедрить средство защиты от масштабных DDoS-атак.

2-е заблуждение: «Меня привлекала возможность совместить сервис сети доставки контента (CDN) с брандмауэром веб-приложений»

Это логично. Если на первом месте для вас стоит производительность, а не конфиденциальные данные клиентов, такой подход уместен. Но если вы несете ответственность за защиту данных компании и пользователей, вам придется отказаться от этого компромисса. В связи с особенностями архитектуры брандмауэр веб-приложений (WAF) на периферии сети не способен отслеживать трафик каждого приложения и потому не может применять механизмы обучения, выявления аномалий и позитивную модель безопасности. Результатом является отсутствие защиты от уязвимостей нулевого дня. Такие приложения, скорее всего, пострадают от утечек данных, поскольку они не защищены от неизвестных средств и методов атак.

В публичных облачных средах эффективность защиты приложений еще ниже — технология WAF, которая предоставляется облачным провайдером (поставщиком IaaS), а не специализированным производителем решений безопасности, обычно не отличается высокими оценками аналитиков. Подробнее в предыдущей статье блога

3-е заблуждение: «Я могу применить одинаковый уровень безопасности на всех платформах»

Это действительно большая проблема. В стремлении применить единую политику безопасности приложений для всех сред — ЦОД, частного облака, Azure, AWS, Google Cloud Platform и Alibaba или Tencent — компании вынуждены жертвовать надежностью защиты. Причина заключается в том, что для каждой среды и провайдера требуются отдельные настройки, например права доступа, защита инфраструктуры, механизмы аутентификации и авторизации, средства управления трафиком ботов, инструменты обеспечения безопасности API на стороне серверов и другие.

При выборе единого подхода (например, в случае с управляемым облачным сервисом защиты), страдает качество сервиса для пользователей (из-за задержки) и уровень обеспечения безопасности (см. пункт 2 выше). Выбор в пользу оптимизации средств безопасности приведет к поиску подходящих решений для каждой среды, а затем потребует время и ресурсы для их регулярного обновления и применения требуемых руководителями по ИБ политик безопасности.

Эта непростая задача приводит к своим пробелам в системе безопасности с очевидными последствиями. Здесь вы найдете несколько практических рекомендаций.

[Понравилась эта статья? Подпишитесь на еженедельные рассылки материалов Radware, а также эксклюзивный доступ к премиальному контенту Radware.]

4-е заблуждение: «Я предполагал, что смогу самостоятельно настраивать все исключения брандмауэра»

Брандмауэры веб-приложений традиционно пользуются плохой репутацией, и это неспроста. Слишком много правил и конфигураций брандмауэра не соответствуют требованиям бизнеса. Это может привести к катастрофическим последствиям: неудобство пользователей сервисов вызывает негативное отношение к бренду и снижению показателей конверсии. Совокупная стоимость владения штатным брандмауэром (WAF) может быть очень высокой из-за затрат на администрирование и требований к компетентности специалистов с учетом перечисленных выше угроз безопасности. Менее опытный сотрудник не разберется в потоке оповещений от разнообразных специализированных решений. Объединенная стратегия безопасности приложений, управляемая экспертами с использованием продвинутых средств автоматизации и аналитики с практическими рекомендациями существенно сокращает совокупную стоимость владения и обеспечивает оперативную защиту.

[Возможно, вам будет интересно: Обеспечение защиты приложений в сочетании с услугами CDN AWS или Azure]

5-е заблуждение: «Я думал, что команда DevOps должна учесть наши предложения»

Некоторые атаки завершаются неудачно по причине слабой, несогласованной системы безопасности, обусловленной недостаточно отлаженными процессами и внутренними конфликтами. Скорость развития современных процессов разработки приложений и методов обеспечения безопасности такова, что и решения по безопасности, и ИТ-сотрудники часто остаются позади. Разработчикам доступно множество инструментов для проектирования идеального конвейера CI/CD с автоматизированным способом сборки, тестирования и оркестрации. Гибкость предполагает быстрое движение вперед — к следующей версии, следующему обновлению, следующему исправлению — без промедлений для проверки отдельных операций и модулей. Поскольку производительность всегда в приоритете, средства безопасности должны подстраиваться. Это тонкое равновесие, которое реализуется в каждой организации индивидуально. Специалисты DevOps оказывают все большее влияние на принятие решений, связанных с безопасностью, поэтому решение для защиты приложений должно выполнять намного больше функций, чем простая блокировка атак. Оно должно эффективно интегрироваться в экосистему жизненного цикла разработки программного обеспечения (SDLC) и обладать необходимой гибкостью для редактирования политики при каждом изменении в приложении. Кроме того, оно должно обеспечить специалистам DevOps наглядность показателей производительности и автоматизации во всех средах. Это позволит наладить процесс принятия решений по безопасности, и все участники будут довольны.

Устранение этих пяти проблем позволит разработать стратегию безопасности приложений, которая будет:

• согласованной,

• прозрачной,

• настраиваемой,

• эффективной.

Загрузите 1-ю серию альманаха Radware’s Hacker’s Almanac 2021.