Всем привет! Меня зовут Шипунова Вера, я магистр по специальности «Информационная безопасность» и куратор направления Cyber.
Мой путь в информационной безопасности начался в 2020 году с подачи документов на эту специальность. Тогда я не имела ни малейшего представления о своей будущей профессии, но постепенно влюбилась в ИБ и теперь уже не представляю себя вне этой сферы.
Наверное, именно поэтому мне особенно важно, как мы учим информационной безопасности. Не как набору терминов, требований и аббревиатур, а как целостной системе, в которой связаны бизнес, данные, инфраструктура, угрозы, риски и конкретные меры защиты.
Перед новым потоком мы серьёзно пересобрали программу: посмотрели на обратную связь участников, обсудили курс с преподавателями и усилили те места, где одной лекции было объективно недостаточно.
При этом сохранили то, что для нас принципиально важно: один сквозной кейс на весь курс, CyberLab, проектные домашние задания и финальную защиту проекта перед условным руководством.
Для меня обновлённый Cyber in Privacy — это именно тот курс, который я сама хотела бы пройти в начале своего пути в информационной безопасности.
Ознакомиться с обновленной программой и зарегистрироваться можно здесь
RPPA.pro | RPPAedu.pro | Cyber in Privacy
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍4
"Привет! Это Олег, соавтор курса по privacy engineering. Мы завершили очередной поток и я хочу поделиться мыслями.
Когда мы с Лизой и командой RPPA.pro запускали первый поток, программа сразу сложилась удачно. Основная идея курса оказалась очень точной, и отзывы превзошли мои ожидания. Тогда я почувствовал, что такое успех с первого запуска.
Однако после четвертого потока я понял: моя удача не только в старте, но и в работе с невероятно талантливыми коллегами и студентами. Они превратили курс в самоподдерживающуюся реакцию.
Например, после третьего потока мы получили важный урок по домашним заданиям. Раньше каждое задание было оторвано от других: мы рассматривали разные продукты и ситуации в рамках одной компании, и у студентов не складывалась целостная картина. Несмотря на хорошие отзывы, мы поняли, что это мешает обучению.
Между третьим и четвертым потоком мы полностью переработали практику, объединив все задания в единую логическую историю.
Мой главный вывод: качественный продукт — это не только видение авторов, но и результат непрерывного цикла обратной связи. Хороший курс привлекает талантливых людей, а они, в свою очередь, делают его еще лучше."
💫Обращение партнера и соавтора курса Елизаветы Дмитриевой по итогам позапрошлого 3-потока
RPPA.pro | RPPAedu.pro | Privacy Engineering
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Webiomed
Платформа прогнозной аналитики для здравоохранения на основе искусственного интеллекта, https://webiomed.ru
❤2👍2
Главная ошибка privacy-комплаенса: проверять доки, не проверяя инфраструктуру
Пост подготовлен командой Cyber in Privacy,когда DPO != юрист
Часть 1 - Часть 2
В реестре процессов может быть указано:
цель → состав данных → правовое основание → срок хранения → получатели
Но фактическая обработка выглядит иначе:
человек → система → API → DWH → выгрузка в файл на комп → почта → подрядчик, а за скобками: лог, резервная копия, тестовая среда
Именно на второй маршрут смотреть бы DPO.
Документы подтверждают, как процесс должен быть организован. Архитектура, настройки систем и действия пользователей показывают, как он работает в действительности.
Где чаще всего возникают расхождения:
🟣 Доступы
Сотрудник сменил должность или проект, но его учетная запись сохранила прежние роли.
Общая учетная запись используется несколькими работниками.
Администраторы и сервисные аккаунты имеют доступ ко всему массиву данных без обоснования.
📌 Для DPO важно инициировать проверку:
кто фактически имеет доступ;
по какому основанию он предоставлен;
соответствует ли роль должностным обязанностям;
проводится ли ресертификация;
как быстро доступ прекращается после увольнения или смены роли;
журналируются ли действия привилегированных пользователей.
🟣 Выгрузки
В основной системе действуют разграничение прав, журналирование и сроки хранения. После выгрузки в Excel эти меры перестают работать.
Файл может оказаться:
в почте;
в мессенджере;
на локальном диске;
в общей папке;
в личном облаке;
на устройстве подрядчика.
DPO должен понимать не только, кто может нажать кнопку «Экспорт», но и:
зачем пользователю нужна выгрузка;
какие поля в нее попадают;
ограничивается ли объем данных;
маркируется ли файл;
контролируется ли его дальнейшее распространение;
установлен ли срок удаления локальной копии.
🟣 Интеграции и API
Система может передавать больше атрибутов, чем требуется принимающему сервису. Например, для проверки статуса заказа достаточно идентификатора и статуса, но API дополнительно передает ФИО, телефон, адрес и историю покупок.
При проверке интеграции DPO нужны ответы на вопросы:
какие поля передаются;
в каком направлении;
с какой частотой;
на каком основании;
шифруется ли канал;
журналируется ли передача;
где данные сохраняются после получения;
может ли принимающая система использовать их для других целей;
что происходит после прекращения интеграции.
🟣 Тестовые среды
В dev-средах нередко используются копии продуктивных баз.
При этом тестовая инфраструктура обычно:
хуже защищена;
доступна большему числу специалистов;
не включена в реестр информационных систем;
не покрыта установленными сроками хранения;
размещена у внешнего разработчика или в отдельном облаке.
Безопасная модель предполагает синтетические либо корректно обезличенные данные. Простое удаление ФИО не всегда является обезличиванием: человека могут определить по телефону, адресу, номеру заказа, cookie, идентификатору устройства или сочетанию атрибутов.
🟣 Логи
Логи могут содержать:
идентификаторы пользователей;
IP-адреса;
телефоны и email;
параметры API-запросов;
поисковые запросы;
содержание ошибок;
токены доступа;
фрагменты документов.
Логирование часто рассматривается как чисто технический процесс, хотя фактически создает дополнительный массив персональных данных.
📌 DPO необходимо инициировать проверку:
какие события журналируются;
не записывается ли тело запроса целиком;
кто имеет доступ к логам;
где они хранятся;
установлен ли срок хранения;
маскируются ли чувствительные поля;
попадают ли логи в SIEM и внешние сервисы мониторинга.
🟣 DWH, аналитические витрины и профилирование
Удаление записи в CRM не означает удаления данных из:
DWH;
BI-системы;
аналитической витрины;
системы рекомендаций;
ML-модели;
архива;
резервной копии.
📌 DPO должен установить, какие производные данные создаются из исходной записи и возможно ли связать их с конкретным человеком.
Особенно важно различать:
агрегацию;
псевдонимизацию;
обезличивание;
удаление прямых идентификаторов.
Это разные технические состояния данных и разные уровни риска.
Пост подготовлен командой Cyber in Privacy,
Часть 1 - Часть 2
В реестре процессов может быть указано:
цель → состав данных → правовое основание → срок хранения → получатели
Но фактическая обработка выглядит иначе:
человек → система → API → DWH → выгрузка в файл на комп → почта → подрядчик, а за скобками: лог, резервная копия, тестовая среда
Именно на второй маршрут смотреть бы DPO.
Документы подтверждают, как процесс должен быть организован. Архитектура, настройки систем и действия пользователей показывают, как он работает в действительности.
Где чаще всего возникают расхождения:
Сотрудник сменил должность или проект, но его учетная запись сохранила прежние роли.
Общая учетная запись используется несколькими работниками.
Администраторы и сервисные аккаунты имеют доступ ко всему массиву данных без обоснования.
кто фактически имеет доступ;
по какому основанию он предоставлен;
соответствует ли роль должностным обязанностям;
проводится ли ресертификация;
как быстро доступ прекращается после увольнения или смены роли;
журналируются ли действия привилегированных пользователей.
В основной системе действуют разграничение прав, журналирование и сроки хранения. После выгрузки в Excel эти меры перестают работать.
Файл может оказаться:
в почте;
в мессенджере;
на локальном диске;
в общей папке;
в личном облаке;
на устройстве подрядчика.
DPO должен понимать не только, кто может нажать кнопку «Экспорт», но и:
зачем пользователю нужна выгрузка;
какие поля в нее попадают;
ограничивается ли объем данных;
маркируется ли файл;
контролируется ли его дальнейшее распространение;
установлен ли срок удаления локальной копии.
Система может передавать больше атрибутов, чем требуется принимающему сервису. Например, для проверки статуса заказа достаточно идентификатора и статуса, но API дополнительно передает ФИО, телефон, адрес и историю покупок.
При проверке интеграции DPO нужны ответы на вопросы:
какие поля передаются;
в каком направлении;
с какой частотой;
на каком основании;
шифруется ли канал;
журналируется ли передача;
где данные сохраняются после получения;
может ли принимающая система использовать их для других целей;
что происходит после прекращения интеграции.
В dev-средах нередко используются копии продуктивных баз.
При этом тестовая инфраструктура обычно:
хуже защищена;
доступна большему числу специалистов;
не включена в реестр информационных систем;
не покрыта установленными сроками хранения;
размещена у внешнего разработчика или в отдельном облаке.
Безопасная модель предполагает синтетические либо корректно обезличенные данные. Простое удаление ФИО не всегда является обезличиванием: человека могут определить по телефону, адресу, номеру заказа, cookie, идентификатору устройства или сочетанию атрибутов.
Логи могут содержать:
идентификаторы пользователей;
IP-адреса;
телефоны и email;
параметры API-запросов;
поисковые запросы;
содержание ошибок;
токены доступа;
фрагменты документов.
Логирование часто рассматривается как чисто технический процесс, хотя фактически создает дополнительный массив персональных данных.
какие события журналируются;
не записывается ли тело запроса целиком;
кто имеет доступ к логам;
где они хранятся;
установлен ли срок хранения;
маскируются ли чувствительные поля;
попадают ли логи в SIEM и внешние сервисы мониторинга.
Удаление записи в CRM не означает удаления данных из:
DWH;
BI-системы;
аналитической витрины;
системы рекомендаций;
ML-модели;
архива;
резервной копии.
Особенно важно различать:
агрегацию;
псевдонимизацию;
обезличивание;
удаление прямых идентификаторов.
Это разные технические состояния данных и разные уровни риска.
Please open Telegram to view this post
VIEW IN TELEGRAM
rppaedu.pro
Cyber in Privacy
Образовательная программа Cyber in Privacy предназначена для специалистов из различных направлений, желающих расширить свои знания и навыки в области защиты информации
❤6🤣1
Главная ошибка privacy-комплаенса: проверять доки, не проверяя инфраструктуру
Пост подготовлен командой Cyber in Privacy,когда DPO != юрист
Часть 1 - Часть 2
🟣 Резервные копии
Требование удалить данные невозможно корректно реализовать, пока не определено:
в какие бэкапы они попадают;
как долго хранятся копии;
возможно ли точечное удаление;
когда данные окончательно исчезнут;
могут ли удаленные сведения восстановиться вместе с резервной копией.
Для бэкапов обычно нужен отдельный режим: ограниченный доступ, запрет использования для текущих операций, установленный цикл перезаписи и повторное применение удаления после восстановления.
🟣 Подрядчики
В договоре может быть указан ограниченный набор данных, но технически подрядчик получает доступ ко всей системе или продуктивной базе.
📌 DPO должен сопоставлять договор не только с описанием процесса, но и с:
матрицей доступов;
архитектурой подключения;
перечнем учетных записей;
журналами действий;
возможностью выгрузки;
перечнем субподрядчиков;
местами хранения данных;
порядком прекращения доступа после завершения договора.
📌 Минимальный технический чек-лист DPO
При проверке нового процесса недостаточно спросить: «Есть ли согласие и договор?»
Нужно установить:
✔️ Откуда поступают данные?
Форма на сайте, приложение, cookie, телефонный звонок
✔️ Какие системы их получают?
Не только основная система, но и DWH, BI, CRM, сервисы аналитики, управления доступом, логирования и резервного копирования.
✔️ Какие идентификаторы используются?
ФИО, номер телефона, email, client ID, device ID.
✔️ Кто имеет доступ?
Работники, администраторы, разработчики, служба поддержки, подрядчики, аналитики.
✔️ Какие копии создаются
Выгрузки, кэш, бэкапы, тестовые базы, почтовые вложения.
✔️ Куда данные передаются?
Внутри группы компаний, внешнему оператору, обработчику, облачному провайдеру, сервису аналитики.
✔️ Как реализуются сроки хранения?
Автоматическим правилом, ручным удалением, архивированием или только записью в политике.
✔️ Как исполняются права субъекта?
Можно ли найти, выгрузить, исправить, заблокировать и удалить данные во всех связанных системах.
✔️ Какие технические меры применяются?
IAM, RBAC/ABAC, MFA, шифрование, DLP, DCAP, журналирование, маскирование, сегментация сред.
✔️ Что произойдет при инциденте?
Можно ли определить затронутые данные, субъектов, пользователей и системы.
✔️ Какие документы стоит запросить у ИТ и ИБ
DPO полезно работать не только с политиками и согласиями, но и с техническими материалами:
архитектурной схемой;
data flow diagram;
реестром информационных активов;
каталогом интеграций;
матрицей ролей и доступов;
описанием API;
правилами логирования;
схемой резервного копирования;
регламентом управления учетными записями;
результатами сканирования DLP/DCAP;
моделью угроз;
отчетами по уязвимостям;
регламентом реагирования на инциденты;
актами удаления и прекращения доступа подрядчиков.
❓ Вопрос, который меняет качество privacy-проверки
Не:
«В каком документе описана обработка?»
А:
«Покажите, где физически находятся данные, как они туда попадают, кто может их получить и как они удаляются».
DPO не обязан самостоятельно настраивать SIEM, IAM или DLP. Но он должен понимать, какие технические доказательства подтверждают соответствие и где юридическая модель расходится с реальной инфраструктурой.
Именно этот разрыв между privacy и ИБ мы разбираем на Cyber in Privacy: без попытки превратить DPO в инженера, но с пониманием архитектуры, доступов, интеграций, логов, тестовых сред, DLP, DCAP и технического жизненного цикла данных.
RPPA.pro | RPPAedu.pro
Пост подготовлен командой Cyber in Privacy,
Часть 1 - Часть 2
Требование удалить данные невозможно корректно реализовать, пока не определено:
в какие бэкапы они попадают;
как долго хранятся копии;
возможно ли точечное удаление;
когда данные окончательно исчезнут;
могут ли удаленные сведения восстановиться вместе с резервной копией.
Для бэкапов обычно нужен отдельный режим: ограниченный доступ, запрет использования для текущих операций, установленный цикл перезаписи и повторное применение удаления после восстановления.
В договоре может быть указан ограниченный набор данных, но технически подрядчик получает доступ ко всей системе или продуктивной базе.
матрицей доступов;
архитектурой подключения;
перечнем учетных записей;
журналами действий;
возможностью выгрузки;
перечнем субподрядчиков;
местами хранения данных;
порядком прекращения доступа после завершения договора.
При проверке нового процесса недостаточно спросить: «Есть ли согласие и договор?»
Нужно установить:
Форма на сайте, приложение, cookie, телефонный звонок
Не только основная система, но и DWH, BI, CRM, сервисы аналитики, управления доступом, логирования и резервного копирования.
ФИО, номер телефона, email, client ID, device ID.
Работники, администраторы, разработчики, служба поддержки, подрядчики, аналитики.
Выгрузки, кэш, бэкапы, тестовые базы, почтовые вложения.
Внутри группы компаний, внешнему оператору, обработчику, облачному провайдеру, сервису аналитики.
Автоматическим правилом, ручным удалением, архивированием или только записью в политике.
Можно ли найти, выгрузить, исправить, заблокировать и удалить данные во всех связанных системах.
IAM, RBAC/ABAC, MFA, шифрование, DLP, DCAP, журналирование, маскирование, сегментация сред.
Можно ли определить затронутые данные, субъектов, пользователей и системы.
DPO полезно работать не только с политиками и согласиями, но и с техническими материалами:
архитектурной схемой;
data flow diagram;
реестром информационных активов;
каталогом интеграций;
матрицей ролей и доступов;
описанием API;
правилами логирования;
схемой резервного копирования;
регламентом управления учетными записями;
результатами сканирования DLP/DCAP;
моделью угроз;
отчетами по уязвимостям;
регламентом реагирования на инциденты;
актами удаления и прекращения доступа подрядчиков.
Не:
«В каком документе описана обработка?»
А:
«Покажите, где физически находятся данные, как они туда попадают, кто может их получить и как они удаляются».
DPO не обязан самостоятельно настраивать SIEM, IAM или DLP. Но он должен понимать, какие технические доказательства подтверждают соответствие и где юридическая модель расходится с реальной инфраструктурой.
Именно этот разрыв между privacy и ИБ мы разбираем на Cyber in Privacy: без попытки превратить DPO в инженера, но с пониманием архитектуры, доступов, интеграций, логов, тестовых сред, DLP, DCAP и технического жизненного цикла данных.
RPPA.pro | RPPAedu.pro
Please open Telegram to view this post
VIEW IN TELEGRAM
rppaedu.pro
Cyber in Privacy
Образовательная программа Cyber in Privacy предназначена для специалистов из различных направлений, желающих расширить свои знания и навыки в области защиты информации
❤5👍3🤣1😎1
Публикуем итоги вебинара от Лии Барсегян об особенностях проведения профилактических визитов представителей Роскомнадзора!
ССЫЛКА VK | YOUTUBE
В плане профвизитов указан уровень риска и срок проверки в рабочих днях. Это подсказка — какие вопросы будут в приоритете у РКН и что стоит проверить у себя первым делом.
Риск = тяжесть (ex., категории ПД, наличие ТГП) + вероятность (были ли нарушения раньше). Срок = насколько критична обработка ПД в компании с точки зрения интересов субъектов. Чем крупнее компания, чем больше история нарушений и чем чувствительнее ПД/обработка ПД — тем выше внимание регулятора.
⚠️ На что обратить внимание:
— после тренингов из-за фонового стресса коллеги начинают видеть ПД там, где их нет
— легаси-системы легко забыть при инвентаризации
— если решение нельзя объяснить — скорее всего, это разовое решение конкретного человека, и его можно пересмотреть
Списки документов примерные, не исчерпывающие. Если вы спецсубъект — добавьте свои специальные документы.
На основе этого уже можно собрать минимально необходимый пакет документов.
RPPA.pro | RPPAedu.pro | CC | Telegram | Yandex
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤4
Со 2 августа 2026 года в ЕС начинают применяться требования о маркировке контента, созданного при помощи ИИ. Разбираемся, кого они касаются, что именно придётся наносить на контент и как ту же задачу решают в России и других юрисдикциях
Присоединяйся к осеннему ИИ-интенсиву
RPPA.pro | RPPAedu.pro | AI Intensive
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12👍4😎2
RPPA.pro совместно с Denuo провели летнее мероприятие в Санкт-Петербурге.
Помимо докладов экспертов в области персональных данных и информационной безопасности, событие запомнилось дебатами на самые актуальные privacy-темы.
RPPA.pro | RPPAedu.pro | CC
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9😎2❤1💔1
На неделе прошлой у Avito был ежегодный Privacy Day. Меня там физически не было, о чем я плачу и плачУ в душе, ибо ивент был годный, как минимум, по составу спикеров от регуляторов (они вообще так где-то собирались)???
ИМХО самый мощный состав за последние годы.
Обсуждали ужастик в карьере DPO, УК. По слухам, много полезного было на выходе обсуждений. Но как мы с тобой знаем, УК вещь такая: как чувствую, так и кручу.
Вот уже можно почитать очерки одного из спикеров, плюс ниже посты в канале этом про 272.1.
Мне как представителю бизнеса не хватает квалификации этой статьи…что-то бы начать делать
ИМХО самый мощный состав за последние годы.
Обсуждали ужастик в карьере DPO, УК. По слухам, много полезного было на выходе обсуждений. Но как мы с тобой знаем, УК вещь такая: как чувствую, так и кручу.
Вот уже можно почитать очерки одного из спикеров, плюс ниже посты в канале этом про 272.1.
Мне как представителю бизнеса не хватает квалификации этой статьи…что-то бы начать делать
Telegram
АЦУПиК | Уголовное и цифровое право
🗣 Пост-рассуждение: тревожность vs масочка
По приглашению компании Авито выступила на организованной ими конференции (хотя это какое-то не очень подходящее слово для людей, каждый из которых очень сильно в теме, а не просто пришёл поболтать), посвящённой…
По приглашению компании Авито выступила на организованной ими конференции (хотя это какое-то не очень подходящее слово для людей, каждый из которых очень сильно в теме, а не просто пришёл поболтать), посвящённой…
❤13👍4😎2
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍3