Comments 35
Они сами уже могли не знать толком, что содержится в их базах.
А как так случилось, что у вас 300+ баз данных без документации? Ну, условно, если принять за данность, что для вас сложнее запросить описание БД, чем строить догадки, что и где в ней хранится.
Лично мне навскидку кажется, что проще написать автоматизированный скрипт, анализирующий данные, чем самостоятельно изучить 300+ пусть и хорошо написанных документаций
Признаюсь, всю статью не читал. Дочитал до места с декомпозицией и сразу родились вопросы:
А вы уверены что номер varchar или text? Может быть int?
Почему номер начинается на 9? Может код оператора и сам номер хранится раздельно?
Как выше правильно заметили я бы обратился к документации. Документация это гарантия того что вы соберете всю информацию (ну или не получите по шапке от сб из-за какой либо ошибки)
Уточню, в России только мобильные номера начинаются с 9. Номера фиксированной связи с нескольких других цифр.
Код оператора отдельно от номера не нужен никому, кроме операторов связи. Для конечного пользователя одно от другого не отделимо.
Номер для удобочитаемости часто пишут со скобками и минусами внутри. Плюс первым символом — это признак номера в международном формате. Строго говоря, номер типа +7(123)456-7889 без плюса должен выглядеть как 8(123)456-78-89. Это внутрироссийский формат.
Сейчас везде применяется тональный набор, а во времена импульсного набора в номере также могли быть буквы: w — подождать гудок, p — сделать паузу.
Какой уж тут int.
Я говорю основываясь на своем опыте. У нас не 300 баз конечно а около 15 и тут столкнулись с тем что одна команда хранит номера в формате 88121233232 (для городских) и 79111233232 (для мобильных) что вполне укладывается в инт. Эту информацию я узнал из документации и не наступил бы на грабли.
Опять же у нас схема бд в самой макушке документации
Ну, если завтра безопасники попросят меня добавить поиск по int, то я в такой YAML
pd_data_types:
postgresql:
character varying: "~"
text: "~"
json: "#>> '{}' ~"
jsonb: "#>> '{}' ~"
mysql:
char: rlike
varchar: rlike
text: rlike
добавлю строчку типа
integer: between 70000000000, 89999999999
и всё найдётся в ближайшие выходные.
Может, я слишком бегло читал фз о персональных данных, но там они определяются так:
«персональные данные - любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);»
Там же не написано что это физическое лицо должно иметь российский телефон, а если у него казахский, то это не распространяется? Поэтому зачем исключать телефонные номера других стран из поиска?
столкнулись с тем что одна команда хранит номера в формате 88121233232 (для городских) и 79111233232 (для мобильных) что вполне укладывается в инт
int 64-битный?
Skyeng — компания с историей, давно на рынке. Разрабы приходят и уходят, а БД остаются. Для зрелой компании разумно поддерживать актуальную документацию. Но в первые годы работы об этом мало думали. Да и к ПДн не было такого трепетного отношения, как сейчас. Раньше можно было запросто собирать, скажем телефоны, на каких-нибудь лендингах для холодных рекламных звонков. Сейчас ни-ни. Кто сейчас помнит о лендинге с олимпиадой 2019-го года?
Документация не панацея. В статье мы пишем об этом:
Можно было решить задачу и по-иному. Например, прийти к разработчикам и сказать: «Вот, у вашей команды есть 5 баз данных. Покажите, что вы в них храните, дайте описание или структуру данных».
В теории, прошерстить документацию могло быть решением. На практике документация всегда отстаёт.
Working software over comprehensive documentation — один из принципов Agile подхода. Никто не любит писать документацию. Разработчики любят разрабатывать, а не писать доки. Документация всегда отстаёт от текущего момента. Она даёт ответ на вопрос «где», но не говорит «сколько». Моё же решение показывает «где», «что» и «сколько», и с лагом не более недели.
А как так случилось, что у вас 300+ баз данных без документации?
Так аджаил же ?
Документация может быть устаревшая. То есть все равно проверять запросами.
Если это столбец типа integer — я искать в нём ничего не буду
Какой наивный)
А ещё в ходе такое интересного процесса, как я понял, в какой-то момент все ПДн оказались в одном месте и практически без контроля. Это почти гарантия утечки.
Ну, и вообще, уровень безопасности и контроля просто прекрасный.
Не ПДн, а метаданные, что в такой-то БД, в такой-то таблице есть столько-то данных.
Когда вы считывали эти метаданные из всевозможных баз, вы и все логины и пароли к ним собрали в одном месте?
Мы всей инфраструктурой, включая БД, управляем Ансиблом. Логины и пароли конечно же лежат в одном месте -- в Вольте.
Персональные данные - это отнюдь не только номер телефона и почта :) Базы данных, в которых лежат домашние адреса, ники в Телеграм, фотографии, рассказы о себе и т.д. и т.п., а вот конкретно мейла/телефона нет (может, они из другой базы запрашиваются по общему ID или вообще для конкретных целей не нужны/опциональны), - Вы пропустили.
ники в Телеграм, фотографии, рассказы о себе
Фотографии понятно, а ники в Телеграм и рассказы о себе - это по законам РФ является персональной информацией? А если рассказы о себе выдуманные?
а туту как суд решит.... могут и признать ПД если это позволяет однозначно идентифицировать человека.... там Закон очень универсально написан и ПД становится фактический любая инфа позволяющая Идентификацию... у нас правда как Всегда но РКН впишет все что найдет, а суд Может решить что вот конкретно вам грусть-печаль...
Потому что в России изменилось законодательство и теперь их нужно хранить в особо защищённых хранилищах.
А можете рассказать что изменилось в законодательстве и как теперь надо хранить персональные данные?
/сарказм и все это чтобы не платить 60тр?
В ГД рассматривают поправки к КоАП за утечку ПДн:
если произошла утечка данных от 1000 до 10 000 субъектов персональных данных, штраф для юрлиц составит от 3 до 5 млн руб.;
за утечку данных 10 000–100 000 субъектов — от 5 до 10 млн руб.;
более 100 000 граждан — от 10 до 15 млн руб.
Технически задача интересная, но ваш руководитель ИБ или "посаженный генерал" или некомпетентен. Ну вот выполнили вы задачу и что? Как Вы будете доказывть РКН, что ваша программа всё нашла? Для этого есть определенный класс специализированного ПО (обычно в составе DCAP, стоят как чугунный мост), просто у ваш руководитель СБ не может обосновать выделение бюджета руководству или вообще безопасники только ради того, чтобы были. Спасибо, что хоть выделили трудозатраты разработчика для решения задачи (Вы же не на добровольных началах это делали?).
Это не так работает. Никто ничего РКН не доказывает. Но если случится утечка, то компания, которая допустила утечку, должна сообщить об этом.
Чтобы снизить возможность утечки, ПДн хранятся в защищённом хранилище, с особо регламентированным доступом и так далее.
Чтобы начать защищать ПДн, перенести их в защищённое место, прежде всего нужно знать, где чего и сколько.
Минусуете, но ничего не знаете про аттестацию ИСПДн, сертификацию средств защиты, поэтому и преподносите наколеночные поделки за инструменты, которые могут решить проблемму. Несведующие люди поверят, воспользуются (а может быть еще и заплатят за решение), а потом огребут.
Утверждаете, что РКН ничего не нужно доказывать - нужно в случае проверки. И у РФ это работает только когда ты обвещан бумажками.И не важно как это защищено к сожалению.
Ну неужели Яндекс, Альфа-Банк и всякие деливери не знали где, чего и сколько? Знали конечно, но это им никак не помогло :)
И поверьте, компания обязана (не должна) сообщить, если случилась утечка. Но это капля в море из того, что необходимо сделать и выполнить. Правда соит ли всё выполнять, если штрафы до сих пор неизмерно малы. Мне жаль ваших безопасников, введут оборотные штрафы и у них изменится (ну или безопасников сменят).
Задачи состояла из 2 частей:
1.Найти пд
2.Переложить в безопасное место
Это как первого человека направить в лес искать грибы и помечать флажками, а второго срезать, третьего собирать, ну вроде декомпозиция, но...
Причём первая заведомо проще и быстрее. Что по мне, что вы придете к тимлидам потом с просьбой переложить ПДн, или придете к ним же с просьбой найти и переложить ПДн, для них трудоёмкость несильно различается.
Вы там, кстати на уроках не пишете топики на тему, как я провёл лето? Если да, то у меня для вас плохие новости)
Разве вам все равно не пришлось бы бегать за командами и ставить им задачу по перепиливанию всего и выноса данных в специальное хранилище, чтобы они же уже ходили в этом самое хранилище?
Пилил нечто похожее. Видел ПД во всяких неожиданных типах данных, поэтому считаю более надёжным конвертировать все колонки в текст. Как начнёте искать дальше телефонов и емайлов - имена или адреса там текстовых полях всяких - то регулярные выражения не спасут. Рекомендую смотреть в сторону алгоритма ахо-корасика.
а где же поиск фамилии, СНИЛС, адреса, названия организаций работы
и где же код посмотреть?
вопрос в том что данные могут Хранится в крайне кривом виде - вплоть до того что номер телефона можно хранить отдельно по странам/регионам/операторам.... или ФИО может лежать не в строке... про email в base64 вобще промолчу...
да и в целом подход конечно "интересный", но для чего сначала тратить кучу времени на поиск ПД в куче БД, если всё равно строить защищенное хранилище и подключать к его базе UUID.....
ИМХО - тут больше подходит именно вариант построить соответствующее нормативам Хранилище - а уже потом пойти каждой команде и совместно с ними - искать данные в их БД и переделывать механики и софт на UUID из централизованного хранилища.....
Как я искал ПДн в 300 базах данных [и сохранил рассудок]