Всем привет! Меня зовут Алёна, я руководитель группы аналитики отдела Compliance и безопасности данных в Ozon. Звучит длинно, поэтому мы с командой называем себя просто датасеками — от Data Security. В информационной безопасности я почти 13 лет, из них 4,5 года в Ozon. До этого больше восьми лет работала в интеграторе и занималась в основном персональными данными и банковской безопасностью — вопросами чистого compliance. Сейчас у меня команда из 11 человек, и мы занимаемся безопасностью данных в Ozon.
Сегодня хочу поговорить об одной важной теме — аудитах безопасности данных. Речь не про пентесты, нет, у нас совсем другая история. Мы смотрим на безопасность данных — и персональных, и финансовых, и любых других данных, которые нужно защищать по требованиям закона, компании или здравого смысла. Расскажу вам о сложностях и о том, как мы с ними справлялись.
Зачем бизнесу аудит безопасности данных
В Ozon много данных, и они распределены по большому числу систем, сервисов и процессов. Это и персональные данные (Ф. И. О., телефон, адрес — и всё остальное, что относится к конкретному человеку, например состав заказа, форма оплаты и платёжные средства, переписка с поддержкой и т. д.). Приватные данные — внутренний термин, обозначающий все данные, которые критичны для компании (выручка, списки контрагентов, внутренние процессы, персональные данные (да, снова они) и т. д.). И всё это надо защищать.
Почему? Во-первых, есть федеральный закон № 152-ФЗ «О персональных данных» и ощутимые штрафы. Первичное нарушение — 150–300 тыс. руб., повторное — 300–500 тыс., а за утечку могут и до 3% годового оборота взыскать. Верхняя граница — до 500 млн рублей.
Во-вторых — репутация. Никому не хочется однажды проснуться героем новостей из-за утечки данных. Такие ситуации уже не раз происходили как в России, так и в мире.
А в-третьих, есть вещи, которые законом не регулируются, но бизнесу от этого не легче. Например, кто-то может навешивать неправильные теги на товары, из-за чего товар неправильно хранится или показывается в выдаче. Убытки? Огромные.
Поэтому мы решили выстроить собственный процесс аудитов безопасности данных. Но сам факт аудита ещё не делает систему безопаснее. Можно собрать информацию, найти риски, написать подробный отчёт — и всё равно ничего не изменить в реальности.
Но давайте честно: сколько раз вы видели, как аудит превращается в формальность? Аудитор написал отчёт на 50 страниц, заказчик кивнул — и все разошлись. А безопасность? А она не изменилась. Знакомо? Мне — да.
Мы решили выстроить этот процесс по-другому.
Как мы проводим datasec-аудит
Знакомство с системой
Сначала мы просто пытаемся разобраться: а что вообще происходит? Что за систему мы пришли смотреть, кто в ней работает, какие бизнес-процессы реализуются, какие сервисы в систему входят, какие данные через них проходят, кто имеет к ним доступ и т. д.
На первом этапе собираем информацию. Просим команду рассказать про микросервисы и их ресурсы, API, помечаем, где лежат приватные данные. Строим схемы взаимодействия микросервисов и схемы потоков данных. Однажды я рисовала такую схему два месяца — это была одна из CRM-систем компании. Сейчас у нас есть инструменты, которые делают это быстрее и автоматически, но и сервисов становится больше с каждым днём, а значит, схемы становятся всё запутаннее. А они очень помогают в процессе аудита визуализировать потоки данных и понять, где могут быть опасные места.
Проверяем ролевую модель
Дальше смотрим ролевую модель: кто и к чему имеет доступ в рамках конкретной роли, нужен ли функционал в рамках работы или есть что-то избыточное. Чуть раньше я упоминала теги. В одном из аудитов мы увидели, что права на изменение товарных тегов были выданы слишком широко. Казалось бы, мелочь, но от этих тегов зависит, как товар хранится, кому показывается в выдаче и так далее. Мы нашли эту проблему и помогли сделать доступы более гранулярными. Закон этого не требует, но мы и не смотрим на систему только через призму закона. У нас более комплексный подход — с точки зрения бизнеса, пользователей, разработки, логики и многого другого. Мы решили проблему, потому что это оправданно и заодно снижает риск финансовых потерь.
Проверяем пользовательские и сервисные доступы
Потом — доступы. Мы проверяем доступы сотрудников к системе, к БД и доступы сервисных учётных записей. В одном из аудитов мы проанализировали более 84 000 пар «человек — роль». Представьте только — опросить 84 тысячи человек! Да даже если опрашивать только руководителей, то их ненамного меньше. К тому же не все руководители могут ответить, для чего работникам те или иные роли, ведь многие запрашивают доступ «на всякий случай» или «как у коллеги». Такие доступы мы предлагаем отзывать, потому что одна скомпрометированная учётка может нанести огромный вред.
Проверяем логирование
Ещё один из стримов, на которые мы обращаем внимание, — это логирование. В рамках аудита мы просим команду настроить аудит-логи, то есть логи в человекочитаемом формате, которые показывают выполнение каких-либо операций над данными со стороны потребителей сервиса, чтобы можно было расследовать инциденты. По логам настраиваются алерты и пишутся плейбуки, чтобы иметь возможность в моменте отлавливать подозрительные действия, например массовую выгрузку информации из системы или очень быстрое открытие страниц в UI из-под одной учётки.
Проверяем защищённый доступ и хранение
И конечно, защищённый доступ. Использование HTTPS — обязательно. Шифрование баз данных — тоже. Чтобы, даже если кто-то получит доступ к БД, данные было не прочитать.
Я перечислила далеко не все проверки, а только основной костяк аудита. Поскольку системы отличаются друг от друга, аналитик-датасек сам определяет, какие процессы, элементы архитектуры или особенности хранения данных стоит изучить глубже.
Кейс: когда формально допустимо, но всё равно небезопасно
Мы могли бы пойти по простому пути: проверили, отдали отчёт — и до свидания. Но нам важно, чтобы изменения реально внедрялись. Datasec — это не формальные бумажки.
Был у нас кейс, которым я очень горжусь: раньше на коробках Ozon писали Ф. И. О., телефон и адрес получателя. Формально это было законно: данные нужны для доставки. Но мы подумали: а что, если кто-то соберёт эти коробки и получит часть базы наших клиентов? Поэтому мы настояли, чтобы эту информацию убрали с коробок. Да, было непросто, мы столкнулись с большим количеством негатива, нас убеждали, что без этих данных процесс доставки станет сложнее. Как показала практика, процесс доставки продолжил работать без проблем. Для меня именно в этом и состоит задача Data Security: делать безопасно, потому что это действительно необходимо. Закон — лишь одна из причин.
Что аудировать в первую очередь
Ozon очень быстро развивается, количество микросервисов и систем быстро растёт, и перед нами очень скоро встал вопрос о том, куда смотреть в первую очередь. Систем много, а ресурсы команды всегда ограничены. Поэтому выбор объектов аудита «на ощущениях» не работает: нужна понятная модель приоритизации, которую можно объяснить и внутри команды, и бизнес-заказчикам.
Мы решили использовать следующие значения:
Критерий | Что оцениваем |
|---|---|
Data | Какие данные обрабатывает система, их объём и чувствительность |
Importance | Значимость системы для бизнеса |
Number | Сколько сотрудников работает с системой |
Money | Возможные финансовые потери при простое или утечке |
К базовым параметрам можно добавить дополнительные — например, учесть историю инцидентов, тип пользователей и регуляторные требования. Последнее особенно важно, если система относится к объектам критической информационной инфраструктуры.
Параметр | Что оцениваем |
|---|---|
Incidents | Происходили ли с системой инциденты |
Users | Кто пользуется системой: внешние или внутренние пользователи |
Law | Распространяются ли на систему дополнительные законодательные или отраслевые требования, например требования к КИИ |
Вы можете использовать и что-то другое. Главное — выбрать единый способ перевода этих параметров в числовую оценку. Пример на рисунке.
Дальше остаётся выбрать способ расчёта итогового приоритета. Можно складывать показатели, умножать их, использовать весовые коэффициенты или собственную формулу — главное, чтобы метод был единым для всех систем.
Нужно ли что-то ещё?
Мы научились приоритизировать и проводить аудиты, но это далеко не всё, поэтому мы вывели для себя ряд основополагающих идей, которые помогают в наших аудитах и в повседневной работе:
Расставляйте приоритеты. Кажется, это очевидно, но охватить всё и сразу не получится. Придётся выбирать, какой риск закрывать первым. Даже если сейчас кажется, что вы ставите кусок стены в чистом поле, со временем эту стену можно достроить и замкнуть. Главное — действовать последовательно.
Смотрите глубже. Небезопасные сценарии использования могут закладываться уже на этапе формирования бизнес-требований, и разработке нужно это учитывать.
Не бойтесь менять процессы. Во время аудитов мы часто сталкиваемся с практиками, которые работают неправильно уже много лет, и быстро изменить их не получается. В таких случаях мы помогаем найти более безопасную альтернативу и продумать плавный переход к новому процессу.
Разговаривайте с бизнесом и разработкой. У ИБ часто есть репутация функции, которая замедляет процессы. Поэтому нам важно объяснять разработчикам и бизнес-заказчикам, что именно мы предлагаем изменить и почему. Мы отвечаем на вопросы, помогаем сами или направляем к тем, кто может помочь, и стараемся общаться с командами не с позиции злого регулятора, а по-человечески. Часто после аудита команды сами начинают замечать риски в исходных требованиях и приходят к нам за советом.
Собирайте команду из людей, которым не всё равно. Если человек горит своим делом, он докопается до нюансов и постарается сделать хорошо.
Для меня настоящая безопасность начинается, когда первая рекомендация из отчёта становится реальным изменением на практике. Именно в этот момент аудит начинает приносить реальную пользу. Всем безопасных данных!
