Александр Каледа, Яндекс: Наш драйвер — ответственность перед миллионами пользователей

Журналисты Anti-Malware.ru на конференции OFFZONE 2025 взяли интервью у Александра Каледы, ИБ-директора (CISO) в «Яндексе». Мы обсудили практики кибербезопасности в масштабах крупной ИТ-компании: как встроить защиту в процессы разработки, поддерживать баланс между скоростью релизов и безопасностью, обучать команды и формировать культуру ответственности. Также затронули тему работы с уязвимостями, проведения соревнований в формате «захват флага» (CTF) и нашли ответ, что мотивирует специалистов в условиях постоянных атак и высокой нагрузки.

«Яндекс» — заметный игрок на рынке облачных услуг, и мы сами активно используем его сервисы. Хотелось бы понять, как вы оцениваете защищённость облачных платформ и есть ли свежие данные, которые показали бы, что облака могут быть даже безопаснее средней инфраструктуры.

А. К.: У крупных облачных провайдеров есть большие команды специалистов по безопасности, которых обычная компания не может себе позволить ни экономически, ни с точки зрения экспертизы. Эти команды уже обеспечили безопасность на уровне функций, предоставляемых облачным сервисом. Это прежде всего экономический вопрос.

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

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

Современная безопасность облачных сервисов по своим принципам чем-то отличается от того, к чему мы привыкли за все эти годы, или применяются те же принципы, что и раньше?

А. К.: Я бы здесь разделил два аспекта: технологические и принципы совместной ответственности. Если говорить о технологических принципах, то, как и в любой мультитенантной архитектуре, важно строить систему по принципам «нулевого доверия» (Zero Trust).

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

Именно на нём мы строим инфраструктуру внутри большого «Яндекса». Основная идея Zero Trust заключается в том, что система рассматривается как уже потенциально скомпрометированная: внутри может быть взломанный сервис или сотрудник. Задачи — выявлять нарушения как можно раньше и максимально снизить последствия.

Мне кажется, это перекликается с тем, о чём в первом докладе здесь, на OFFZONE, говорил Евгений Касперский, рассуждая о концепции кибериммунности.

А. К.: Речь идёт о том, что абсолютной безопасности не существует, а периметровая безопасность устарела. Старый подход — «забор», защита от «злого интернета» — в крупных корпорациях не работает, потому что настоящего периметра просто нет. При большом штате и обширном парке оборудования нужно исходить из того, что периметра не существует, и строить защиту на других принципах: везде должны быть контроль доступа, аутентификация, авторизация и аудит. Любое критическое действие должно подтверждаться либо вторым лицом, либо соответствующей технологией.

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

А. К.: Конечно. Если взломали ООО «Ромашка» из-за ошибки клиента или какой-то неверной конфигурации, это не должно сказываться на соседнем банке.

Да, я бы здесь сделал отдельный акцент на разграничении ответственности. На мой взгляд, это одна из сложных тем: как именно разделяется ответственность между провайдером и заказчиком. Это часто становится тормозом в работе. Как вы это видите? С точки зрения вашей компании, где заканчивается ответственность заказчика и начинается ваша ответственность за безопасность?

А. К.: Есть публичная концепция разделения ответственности между клиентом и облачным провайдером. Граница разделения ответственности зависит от используемых сервисов и модели их использования (IaaS — инфраструктура как услуга, PaaS — платформа как услуга, SaaS — программное обеспечение как услуга) и имеющихся у облачного провайдера защитных механизмов и политик.

Если говорить про модель IaaS, то ответственность провайдера — физическая безопасность и отказоустойчивость платформы, защита сети, сбор и анализ событий гипервизоров и компонентов инфраструктуры. Клиент же отвечает за безопасность виртуальных машин и всё, что на них будет разворачиваться. Уязвимые компоненты в ОС — это проблема клиента.

Для сервисов, распространяемых по модели PaaS (платформа как услуга), уровень ответственности облачного провайдера поднимается до безопасности операционной системы. При этом защита приложений остается на стороне клиента. Поэтому если вы развернёте, например, уязвимый Exchange, мы не в состоянии гарантировать его безопасность. Для модели SaaS (ПО как услуга) на стороне клиента остается только управление доступом к данным, об остальном позаботимся мы.

А какие в этой модели можно выделить болевые точки?

А. К.: Основная болевая точка в том, что клиент до конца не понимает модель ответственности. Он не всегда осознаёт, что берёт на себя, а что остаётся на стороне провайдера. Часто существует заблуждение: если провайдер говорит, что облако безопасно, значит, можно делать всё что угодно — открывать базу наружу, например.

На самом деле это не так. Любой сложный механизм требует понимания и тонкой настройки. Тем не менее такие случаи у нас бывают. Например, если у клиента произошел инцидент, а он забыл подключить audit-логи, то мы всегда идём навстречу: предоставляем необходимые логи из внутренних хранилищ, помогаем расследовать событие и настраивать систему, чтобы всё было безопасно.

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

Да, я знаю, у вас появилась новая функциональность в облаке примерно полгода назад, нацеленная в том числе на обеспечение прозрачности. А на какие векторы атаки стоит обратить внимание как наиболее актуальные в контексте современной многоуровневой архитектуры? У меня сложилось впечатление, что акцент постепенно смещается с атак на инфраструктуру к атакам на идентификацию, учётные записи, документацию и цепочки поставок.

А. К.: Мы действительно наблюдаем сдвиг от атак на периметр компании к переиспользованию легитимных учётных данных. Речь идёт о статических реквизитах доступа к S3-бакетам или о логинах и паролях для доступа к облачным платформам, особенно если клиент забыл настроить двухфакторную аутентификацию при подключении через SSO.

По сути, это эволюция классических техник подстановки (credential stuffing, атака подбором учётных данных — прим. Anti-Malware.ru), когда используются нестрогие аутентификационные факторы. То есть статические реквизиты доступа, которые не требуют двойного подтверждения или аппаратной поддержки вроде токенов, YubiKey или Touch ID. Часто это данные, сохранённые, например, в личной почте, которая была скомпрометирована, и далее с их помощью проводится большое количество атак. В этом году мы видели подобные случаи у десятков компаний.

А что насчёт цепочек поставок? Бывали ли у вас такие случаи, сталкивались с ними?

А. К.: Цепочки поставок здесь тоже стоит различать, потому что они бывают разными. Если говорить об атаках через цепочку поставщиков, особенно подрядчиков, это отдельная категория. В целом, это устоявшийся тренд: ломают один облачный сервис по модели SaaS, а через него получают доступ к другим компаниям.

Бывают ли атаки через репозитории исходного кода?

А. К.: Я бы не стал называть это трендом. Атаки понятны и ожидаемы, каких-либо явных тенденций здесь я не наблюдал.

Хотелось бы спросить про большой «Яндекс». Понятно, что в платформенных сервисах постоянно идёт разработка и внедряется много новых данных. Как вы находите баланс между скоростью разработки и безопасностью? Часто возникает дилемма: разработчикам хочется выпускать как можно больше интересных продуктов, а безопасность при этом может выступать своего рода стопором, указывая, что сначала нужно исправить баги.

А. К.: Такой подход изначально не работает в крупных технологических компаниях уровня «Яндекса». Например, только в одном сервисе это десятки релизов в день. Представьте, какого размера должна быть команда безопасности, если пытаться контролировать каждый релиз вручную.

Безопасность в этих условиях реализуется через множество практик. В первую очередь мы инвестируем в безопасность общих компонентов и автоматизацию процессов. Это позволяет выявлять уязвимости на ранних стадиях разработки, используя инструменты статического и динамического тестирования (SAST и DAST), ещё когда разработчик работает с контекстом запроса на принятие изменений (pull request).

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

Я правильно понимаю, что все эти концепции уже не новы, они достаточно устоявшиеся?

А. К.: По-другому просто невозможно, потому что «Яндекс» — это ИТ-компания, которая занимается разработкой кода. Чтобы процессы работали быстро и эффективно, они должны быть максимально нативны и стандартизированы.

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

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

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

Что касается концепции лидеров безопасности (security champions), то лично я в эту концепцию не верю. На рынке терминология уже сильно исказилась, и каждый вкладывает в это что-то своё. По моему мнению, каждый сотрудник должен быть «чемпионом» в безопасности, пусть на разных уровнях зрелости. Для всего персонала мы транслируем базовые концепции, безопасные компоненты и типичные уязвимости. Для заинтересованных разработчиков существуют отдельные активности — внутренние CTF, где соревнуются сотни команд и более тысячи участников.

Разделять сотрудников на «чемпионов» и остальных неправильно. Когда один человек назначается ответственным за безопасность, создаётся ложное ощущение, что остальные могут не думать об этом. Это ключевая ошибка.

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

На конференции OFFZONE на данный момент прошло только полдня, но, наверное, уже можно поделиться впечатлениями: чем он отличается от других подобных мероприятий и какая здесь роль «Яндекса»?

А. К.: Нам близка сама идея конференции, особенно учитывая, что мы здесь представлены как генеральный спонсор. Эта площадка позволяет открыто и на равных обсуждать вопросы безопасности всем — крупным корпорациям вроде «Сбера», «Яндекса», «Т‑Банка», а также независимым специалистам разного уровня.

Мне кажется, это очень ценно. Это миссия организаторов, которая не подкрепляется коммерческими интересами. Особенно важно это сейчас, когда индустрия сталкивается с постоянными атаками на крупные компании, и не вкладываться в безопасность уже нельзя. Такая площадка помогает повысить общий уровень защищённости индустрии.

Мы второй год являемся генеральным партнёром, и для нас это возможность разделить эту миссию с участниками. Мы верим в неё и активно делимся опытом: проводим доклады, организуем различные активности и так далее.

У вас большой опыт в области безопасности, который можно сравнивать с опытом операторов связи: они сначала учатся на собственных сервисах, а затем предлагают свои решения другим компаниям. Есть ли у «Яндекса» подобные планы?

А. К.: И они уже реализуются. У нас довольно много сервисов безопасности, которые представлены в рамках Yandex Cloud, также недавно мы анонсировали новые продукты типа WAF или «SOC как услуга».

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

А. К.: Думаю, здесь важно разделить два аспекта. Если говорить о взломах, которые мелькают в новостях, то они лишь подсвечивают низкий уровень зрелости отечественной кибербезопасности. Именно поэтому мы стараемся вместе поднимать этот уровень.

Говоря о «Яндексе» — это компания, глубоко интегрированная в повседневную жизнь миллионов людей. Соответственно, у нас совершенно другой уровень ответственности.

Масштаб наших сервисов добавляет сложности: десятки миллионов контейнеров, миллионы запросов в секунду (RPS), многочисленные заинтересованные стороны. Всё это и мотивирует команду. Лично меня мотивирует ответственность перед нашей огромной аудиторией.

Кроме того, учитывая уровень проникновения наших сервисов, у нас есть возможность повышать защищённость всей отрасли. Мы регулярно участвуем в расследовании серьёзных инцидентов, помогаем другим российским компаниям предотвращать атаки и восстановиться. Это тоже очень мотивирует и просто само по себе интересно.

Александр, благодарю за интересный разговор. Удачи вам и всего самого безопасного!