Дилемма CIO: как найти баланс между безопасностью и производительностью веб-ресурса

Константин Анохин, коммерческий директор и директор по развитию продукта в NGENIX

Триада информационной безопасности

Триада информационной безопасности является основой для создания политики киберзащиты и позволяет оценить уровень безопасности системы или организации. Это модель, которая описывает три основных аспекта информационной безопасности: конфиденциальность, целостность и доступность.

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

Наложенные и интегрированные средства безопасности

Существуют две фундаментальных парадигмы, в которых живут технические лидеры, возглавляющие команды веб-ресурсов. Это использование наложенных и интегрированных средств обеспечения ИБ. Оба подхода появились под влиянием различных факторов.

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

Организации enterprise-сегмента первыми стали располагать бюджетами для обеспечения защиты информации внутри своего периметра, сталкиваться с повышенными рисками, а также ощущать на себе давление регуляторов. Для них наиболее логичной является модель поставки ПО для киберзащиты on-premise — то есть, в качестве наложенного средства, которое полностью контролируется внутренней командой или интегратором, эксплуатируется внутри периметра организации и масштабируется путем расширения закупаемых лицензий. Если смотреть на «триаду ИБ», стратегический фокус в этом случае смещен на конфиденциальность и целостность, а ИБ, проводя аудит или аттестацию, руководствуется привычными подходами к организации архитектуры безопасности.

Что касается интегрированных в облако СЗИ, на их развитие и востребованность повлияли другие причины. С середины 2010-х публичные облака стали топливом, подпитывающим бурный рост веба, особенно для кратно растущего рынка электронной коммерции. Эластичность облака, экономическая выгода от возможности гибко масштабировать инфраструктуру под непрогнозируемую нагрузку, возможность «перекрыть» часть отсутствующих в штате ИТ-компетенций за счет облачных сервисов сделали облака неотъемлемой частью бизнес-модели растущих онлайн-бизнесов. Появление в этом уравнении информационной безопасности было вопросом времени, и в период крупных кибератак 2022 года так и произошло.

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

Этот вектор развития характерен для глобальных лидеров типа Akamai и Cloudflare — как и для нас в NGENIX. Веб стал требуемым элементом новой реальности, и каждая организация, имеющая публичный интерфейс для взаимодействия через интернет, становится веб-компанией и вынуждена жить по правилам этого мира. Если вернуться к «триаде ИБ», вершина под названием «доступность» получает не меньший приоритет относительно конфиденциальности и целостности.

При чем здесь забор?

Для наглядности можно сравнить оба подхода к ИБ с методами обеспечения физической безопасности различных объектов. Если перед вами стоит задача обеспечить безопасность на режимном объекте типа завода, ее архитектура будет принципиально отличаться от подхода к обеспечению безопасности публично доступного объекта вроде торгового центра, МФЦ или музея.

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

Торговый центр, музей или МФЦ — общественное место, существование которого зависит от прибыли, полученной с посетителей, в случае с МФЦ — от их комфорта и лояльности. Чтобы обеспечить безопасность таких объектов, нецелесообразно строить забор, ставить КПП или проверять пропуска — иначе обслужить поток пользователей, особенно в дни ажиотажа, не получится. Торговый центр лишится части прибыли, администрация МФЦ столкнется с негативом от граждан. Поэтому безопасность в данном случае устроена по-другому: на входе стоят рамки, не сильно мешающие потоку, есть камеры видеонаблюдения, по этажам ходит охрана, отслеживающая подозрительных лиц, но не останавливающая каждого посетителя. Это модель безопасности, которая нужна веб-ресурсу. Выстроить периметр вокруг торгового центра, музея или МФЦ — значит снизить его функциональность. К тому же это будет откровенно дорого.

Почему мы все еще «строим заборы»?

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

Во-вторых, с ростом киберрисков наблюдается размытие границ ответственности за защиту веб-ресурса, особенно в крупных ИТ-командах и enterprise-компаниях. Нередко обеспечение цифровой безопасности попадает в сферу ответственности CISO, обеспечение доступности — в сферу ответственности ИТ, DevOps и SRE-команд, а общий бюджет на закупку и эксплуатацию ИБ-решений находится в руках CIO. По этой причине могут возникать конфликты интересов, при которых все фигуранты такой структуры стремятся ответственно выполнить свои KPI и не всегда находят компромиссное решение. CISO обязан снизить риски и обеспечить соответствие регуляторным требованиям. ИТ-команда хочет добиться максимального аптайма веб-ресурса в довольно агрессивной среде, и для этого ей нужны адекватные средства защиты от угроз. После «закручивания гаек» могут пострадать показатели команд бизнеса — условных продуктологов и маркетологов — для которых новые меры безопасности влияют на пользовательский опыт, CJM, лояльность и другие бизнес-метрики. Усложняя это уравнение, существует CIO, который не может допустить, чтобы стоимость мер по защите организации и «закрученные гайки» вредили бизнесу и прибыльности компании. Но практика говорит: если бюджет на СЗИ находится в ведении подразделения ИБ, в этом месте с большой вероятностью появляется «забор» — очень безопасный, но дорогой для бизнеса, неудобный для пользователя и трудно управляемый для ИТ.

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

Что нужно сделать, чтобы веб-ресурс выполнял задачи бизнеса и нес меньше рисков ИБ?

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

Что нужно делать для того, чтобы не городить «заборы» вокруг веб-ресурса и изменить привычный стереотипный подход к ИБ?

1. Воспринимать веб-ресурс как отдельный класс информационных систем. Веб-сайт должен управляться и масштабироваться согласно собственной логике, и к которому неприменимы подходы закрытых корпоративных ИС.

2. Использовать публичные многофункциональные облака. Изначально строить веб-ресурс на легко и быстро масштабируемой инфраструктуре, то есть в публичных облаках — только они обладают необходимой эластичностью, благодаря которой веб-ресурс готов к любому объему легитимной и нелегитимной нагрузки. При этом выбирать для этого те публичные облака, в которых функции, обеспечивающие доступность, производительность и безопасность, равнозначны и интегрированы на уровне дизайна сервисов. Стоит минимизировать количество публичных облаков: любая граница ответственности усложняет управление и траблшутинг. Если это невозможно, стоит хотя бы архитектурно разделить бэкенд и фронтенд-инфраструктуры.

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

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

Что в итоге?

В отрасли давно известно о закономерности: чем безопаснее процесс, тем он неудобнее. Эта антагонистичность укоренилась на уровне понимания обывателя. Капча создана для безопасности, но неудобна для пользователя. Сложные пароли — безопасно, но неудобно. Пароль «12345» — удобно, но очень небезопасно.

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

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

13 декабря мы поговорим о современном видении средств защиты веб-приложений, практиках использования WAF в облаке, борьбе с DDoS и ботами на ежегодной онлайн-конференции NGENIX Icebreaker 2023 — приходите, будет интересно.