Я помню, как в школе пользовался милицейской базой данных телефонных номеров (с пиратского CD), где по номеру можно было пробить адрес дома и квартиру, и поражал девушек, у которых взял телефончик тем, что сообщал, где они живут. Уже тогда у меня не было доверия ни к одной базе данных.
А зачем компаниям защищать данные, если штраф за слив 50 млн учеток составляет 60 000 рублей? Более того, со временем компании будут все более и более халатно относиться к «старым данным» и будут уделять больше внимания на привлечение новых клиентов и разработке новых продуктов, чем на обеспечение безопасности данных.
Приватность баз данных — это суперхрупкая и неустойчивая система. Достаточно всего одной ошибки и усилия всех лет рушатся. И вероятность взлома растет со временем.
Керосина в огонь добавляют три момента:
- Оцифровывается очень чувствительная информация (Информационная безопасность и ДНК);
- Государство принуждает оцифровывать чувствительную информацию;
- Ущерб от утечки суперчувствительной информации может быть огромный, а ответственность за нее никто не несет и не гарантирует.
Сейчас я утверждаю, что любая и каждая база данных будет взломана и выложена в открытый доступ. Я отношусь ко ВСЕМ данным в цифровом формате так, как будто они УЖЕ в открытом доступе. Я не строю иллюзий по поводу приватности данных.
А вы что думаете?
Под катом я собрал несколько примеров утечек за последние годы.
2012
2013
- Adobe Systems, 38 000 000 записей клиентов
- Target, 110 000 000 записей
- Yahoo, 3 000 0000 учетных записей пользователей
2014
2015
- Anthem, 80 000 000 клиентов и сотрудников
- Кадровое управление правительства США, 25 000 000 госслужащих
- Ashley Madison, 37 000 000 записей
- Securus Technologies, 70 000 000 записей о звонках и порядка 144 000 аудиозаписей разговоров по телефону американских заключенных.
2016
2017
2018
2019
- Canva, 137 000 000 учетных записей пользователей
- ОФД «Дримкас», 76 000 000 записей
- Налоговые декларации россиян, 20 000 000
- Парковка Москвы, 30 000 000 автовладельцев
- Сбербанк, 60 000 000 записей
- «Билайн», 2 000 000 записей
- Skyeng, 5 000 000 записей учеников и работников.
- Базы данных московских автомобилистов, 1 000 000 записей
- «Альфа-банк», ОТП и ХКФ, 900 000 записей
- ОАО «РЖД», 700 000 записей сотрудников
- Orvibo, 2 000 000 пользователей
- First American Financial Corporation, 885 000 000 оцифрованных данных клиентов
- 2 200 000 000 паролей
2020
- Переболевшие короновирусом, 100 000 жителей Москвы
- «РЖД Бонус», 1 360 000 записей
- Паспортные данные проголосовавших за поправки в Конституцию, 1 1 000 000
- Keepnet Labs, 5 000 000 000 записей
- CouchSurfing, 16 900 000 записей
- Marriott Hotels, 339 000 000 учётных записей
- Nintendo, 160 0000 записей
- EasyJet, 9 000 000 записей
- Weibo, 500 000 000 записей
2021
- 8 200 000 000 паролей
- Alibaba, 1 000 000 000 имён пользователей и телефонных номеров
- Facebook, Instagram, LinkedIn, 214 000 000 записей
- Автомобилисты Москвы и Подмосковья, 50 000 000 наборов персональных данных
- Hyundai, 1 300 000 российских владельцев автомобилей Hyundai
- ПриватБанк, 40 000 000 записей
2022
- 100 000 карт из России
- «Яндекс.Еда», 49 000 000 строк с заказами, 6 800 000 уникальных номеров телефонов из России и 200 000 из Беларуси
- «Гемотест», 40 000 000 строк с персональными данными
P.S.
Вот примерные причины утечек:
- Атака хакеров – 24,6%;
- Внутренние уязвимости и сбои – 19,5%;
- Человеческий фактор – 18,7%.
Хотя мне, как конечному пользователю, плевать на причины утечки.
Комментарии (45)
ky0
04.05.2022 20:19+3Так, окей — вы ко всем базам относитесь как к утекшим. Что дальше? Ощущается, как будто нужно продолжение.
gleb_l
04.05.2022 20:27+3Утечка данных - однонаправленный процесс (в отличие, например, от обратимых химических реакций, или изменений агрегатного состояния вещества) - "втечки" данных после утечки быть не может. Значит, любая вероятность утечки, строго большая 0, рано или поздно реализуется, и система перейдет из нестабильного в стабильное (конечное) состояние "данные утекли".
В реальных информационных и соц. инженерных системах вероятность утечки всегда больше 0 - поэтому Ваше утверждение абсолютно верно - нужно действовать так, как будто ваши данные уже утекли. Парадокса здесь нет - например, для каналов связи с ошибками существуют корректирующие коды (как альтернатива попытке бесконечно улучшать физическое качество) - поэтому для борьбы последствиями утечек можно заранее предусмотреть проверочную и корректирующую информацию, и хранить ее независимо от основной - а вот вероятностью одновременного наступления двух событий (утечки из двух несвязанных источников по одной и той же персоне) уже можно пренебречь (если конечно, энергия не сконцентрирована именно на этом векторе)
PereslavlFoto
04.05.2022 20:42+1для борьбы [с] последствиями утечек можно заранее предусмотреть проверочную и корректирующую информацию, и хранить ее независимо от основной
Утечка данных не вредит исходной базе данных, не нарушает работу её владельца.
Утечка данных вредит только людям, которые передали свои данные владельцу базы данных.
А значит, это мы, все люди, должны бороться с последствиями утечек. Но как это сделать?gleb_l
04.05.2022 22:22+8Не класть все яйца в одну корзину- в идеале иметь для каждой группы систем свой емайл
Для емайлов брать надёжный хостинг, например протон
Везде, где можно, юзать 2FA
Иметь два телефона - финансы итд - один, котики - другой
Скачиваться базу pwned, скажем, раз в неделю, и искать в ней своё.
Записывать пароли ассоциативно (например, К*****н, который живет на крыше)
Искажать свои ПД везде, где это можно сделать безболезненно (включая латиницу внутри кириллицы, номера телефонов полутекстом итд)
Нигде не регистрироваться ради бонусов и промо-акций (в силу закона энтропии на дальнем горизонте выйдет дороже)
Короче, разделять свой цифровой Титаник на отсеки, и подозрительно смотреть в оба вперёд насчёт айсбергов ;)
MagisterLudi Автор
04.05.2022 22:37+1«Войны нельзя избежать, ее можно лишь отсрочить — к выгоде вашего противника.»
— Николо Макиавелли
Adiutant
05.05.2022 13:11Макиавелли - это уже попса для айтишников (просто интересное наблюдение).
А что насчет защиты данных, то само собой она возможна, вопрос в значимости для компаний, проблема скорее социальная и решение на мой взгляд состоит в осознании недееспособности некоторых социальных институтов которые современный человек так чтит и переводе проблемы в плоскость "заставить" компании сталкиваться с последствиями халатного отношения к нашим данным.
lolikandr
04.05.2022 22:59+1Но это всё профилактика, а *с последствиями утечек* то как бороться?
mixsture
05.05.2022 12:30+1Я бы как первую меру предложил обязательный ежегодный открытый ИБ аудит фирм. Мы хотя бы будем понимать, насколько все плохо и на основании этого принимать решение, отдавать свои ПД или нет.
Spunreal
05.05.2022 22:29Можно сменить паспорт, место жительства, телефон, имя с фамилией и даже пол. Главное биометрию не оставлять. Её сложнее сменить :)
Devakant
04.05.2022 23:16Я бы предложил для "временных" сервисов использовать одноразовую почту, а для постоянных 2-3 почты, но под каждую группу имхо бессмысленно, т.к. групп может быть очень много.
К сожалению протон показал себя как не очень надёжный.
https://dtf.ru/life/858403-protonmail-sdal-svoih-polzovateley-aktivistov-vlastyam-francii . При том что они позиционируют себя как сервис который не журналирует данные ip и прочую информацию, но как оказалось - очень даже.Согласен.
Большой погоды не сделает, т.к. уникальных номеров (если это не номер которому больше 10 лет у одного владельца) нет, и все + - номера слиты, но не все могут иметь реальное соотношение: Номер - человек.
К сожалению, данный совет во-первых, бесполезен, т.к. проще (и лучше, но тут решать каждому самостоятельно) раз в неделю/месяц менять пароли (вне зависимости от компрометации). А во-вторых, если нет платных подписок на форумы со слитой информацией, получить актуальную информацию практически невозможно. Различные ТГ каналы со сливами, обычно дают всякий шлак, большая часть которого итак в открытом доступе.
Я бы предложил юзать программы по типу keepass, а не придумывать ассоциативные пароли (которые тоже при должном желании можно подобрать), а к паролям типа: x23ja%!=|=! ассоциации кроме как "хаос", не приходит.
И да и нет. Это может быть полезно если это условно сервис какой-то одноразовой игры. А вот если это аккаунт от важного сервиса, даже банального steam аккаунта, ввод некорректных данных может помешать восстановлению в случае утери/краже, при общении с ТП.
В целом согласен.
Лучшая защита в интернете, отсутствие интернета. (что для айтишника почти невозможно).
gleb_l
04.05.2022 23:31+4В целом достаточно четырёх контуров безопасности - финансы, государство, имущество, котики. Контуры не должны иметь общих точек - то есть емайлов, логинов, телефонов, паролей. Если возможно, из самого расхлябанного контура котиков не должно быть прямых соответствий на ПД первых трёх.
Все, что не нужно электронным способом, должно быть отключено (переоформление имущества, запрет взятия финобязательств (такого пока нет) итд)
Keepass опасен тем, что он - единственная точка отказа. Список plain text’ом с загадками на основе только Вам известных фактов в какой-то степени надежнее. Равно как старый шпионский приём - индекс страницы-строки-слова в некой книге на полке. В реальности большое количество непроизносимых символов в пароле не делает его более стойким относительно человекочитаемого, кроме очевидного списка банальностей. Пароль вида “в огороде бузина..» может быть порядково надежнее и порядково же проще к запоминанию.
Devakant
04.05.2022 23:40+3Во многом, тут нужны действия государства. Например запрет на идентификацию человека по номеру телефона. Только по паспорту и например только в отделении. Да и смехотворный штраф указанный автором статьи не заставляет компании думать о безопасности.
А обычный человек от комфорта не откажется. К примеру, записаться к врачу через интернет, в десятки раз удобнее, чем сходить до поликлиники. (т.к. дозвонится это ещё тот челлендж). Хоть второй случай гораздо безопасней.
MagisterLudi Автор
05.05.2022 00:23+3Я предлагаю вводить 100% ответственность за ущерб из-за утечки к «хранителю» чувствительных данных. Например, сходил я к стоматологу, а у него украли мою учетку и я понес из-за этого 1 млн потерь, так их списать со стоматолога. Или если угнали фотку снилс из госуслуг — то снять бабло с госуслуг.
Можно еще в момент передачи своих данных какому-то сервису выставлять цену штрафа в следствие их угона. Типа: «я вам даю свои емэйл, ФИО, фотку и номер паспорта, вот на них электронная печать, если они всплывут в даркнете — с вас 1 млн штрафа.»
Xander_d
05.05.2022 01:06+3Я так понимаю, в этом и есть определенная сложность: а как оценить свои потенциальные потери?
Вот украли у стоматолога мою учётку - и?.. Пока с её помощью с меня не списали денег я прямых потерь, вроде как, и не понес, а когда всякий спам начинает сыпаться, так это больше чем на моральный ангел не тянет... (
Moskus
05.05.2022 02:47+2Строго говоря, это ситуация, когда потери могут быть отягчающим обстоятельством, но состав нарушения - ненадлежащее качество услуг (тут возвращаемся к вопросу отраслевых стандартов). Ну и сам стоматолог, конечно, никакой ответственности не несёт - он же не сам ведёт базу, это за него делает какой-нибудь вендор.
Moskus
05.05.2022 05:58Вы только забываете, что для доказательства факта утечки данных от конкретного ответственного за их хранение, акт передачи должен быть не только подписан владельцем данных, но и стороной, берущей ответственность за хранение. Иначе, кто угодно может сам выложить подписанные данные и утверждать, что они утекли.
Однако, хотя строгость наказания за нарушение и имеет связь с возможностью этих нарушений, но ни повлиять на что-то кроме откровенно халатного отношения (потому что действительная защита от взломов и утечек - не очень простая задача) ни снизить негативный эффект в случае, если нарушение таки произойдет, она прямо не может. Так что это хоть и не бесполезная, но не очень эффективная мера. Эффективны подробные меры только в воображении.
Devakant
05.05.2022 12:19Здесь сложно посчитать потери. Т.к. далеко не все пытаются юзать данные для прямого мошенничества. Некоторые подкручивают рекламу, чтобы вам в нужный момент вылезла реклама зубной пасты например.
Не просить же процент от "упущенной" прибыли? :)
antirek
07.05.2022 14:44+1обычно утекает много данных -> списывать будут коллективно -> например на 100 пострадавших будет 100 млн возмещения (из вашего примера 1 млн потерь) -> значит проще бизнес закрыть-продать-обанкротить, чем заниматься такой выплатой
еще вариант, обработкой данных в бизнесе будут перекладывать на какое-то стороннее юр.лицо типа однодневки, которое будет "мальчиком для битья" в случае проблем, а основной бизнес/юрлицо будет работать и дальше
возможно, поскольку все-таки это риски ущерба, то надо мыслить в сторону страхования - страховать риск утечки. по аналогии с ОСАГО/КАСКО и в анкете на согласие обработки персональных данных указывать кто страхует ответственность бизнеса, и если нет страховщика, то вы вправе выбрать другой бизнес, который все-таки застраховал свою ответственность.
кстати, можно также относиться и к управлению автомобилем - вероятность ДТП с вашим участием ненулевая, учитывая количество автомобилей, интенсивность движения и разный уровень водителей - вы покупаете страховку, чтобы как-то снизить претензии по ущербу в свою сторону.
Moskus
05.05.2022 02:43+5Если отбросить утечки данных, которые и так являются общедоступными и не могут быть использованы для аутентификации или повышения привилегий, проблема с оставшимися данными - то, что они часто не могут быть вообще или легко инвалидированы.
Поясню. Предположим, утекла база, содержащая ваш логин и пароль от какого-то сервиса. Если вы можете сменить пароль до того, как им воспользовались злоумышленники (или если этих факторов недостаточно) - инцидент просто исчерпан.
Теперь предположим, что к какому-то используемому вами сервису можно получить доступ, зная ваши неизменяемые личные данные (не обязательно только их, но их в том числе), которые берутся из какой-нибудь централизованной (например, государственной) базы данных. Их невозможно сменить, чтобы осложнить жизнь преступникам. Или это занимает значительное время (например, смена паспорта). Получается, что часть данных, нужных для нелегального доступа к вашей учётной записи, в принципе не являются секретом в полном смысле слова.
Так что вопрос стоит не столько в том, чтобы регулировать стандарты аутентификации, сколько в том, чтобы, для начала, различные сервисы начали понимать смысл концепции "секрета" в контексте аутентификации. Включая государство, которое любит использовать для этого то, над сохранностью секретности чего сам индивидуум не имеет ни малейшего контроля благодаря самому же государству. То есть от государства, для начала, имеет смысл требовать, чтобы оно перестало вредить, а потом уже смотреть, нужна ли от него помощь.
Sergey_datex
05.05.2022 14:44+11) в реальной жизни стараюсь забыть емейл как пережиток прошлого. Неудобная, подверженная тотальному заспамливанию технология.
4) основная проблема телефонов - нешифрованный SS7 и вероятность угона номера. Не спасут рекомендации.
5) параноя. жить страшно. остальные пункты - тоже самое.
begin_end
05.05.2022 03:27В реальности утечка данных конкурирует с параллельно возможным процессом — потерей данных. И в реальности, со временем чаще всего реализуется именно потеря/уничтожение/стирание данных, а система переходит в стабильное состояние «данные отсутствуют».
Politura
05.05.2022 05:30+4В реальных информационных и соц. инженерных системах вероятность утечки всегда больше 0 - поэтому Ваше утверждение абсолютно верно - нужно действовать так, как будто ваши данные уже утекли.
Из того, что какое-то событие имеет ненулевой шанс произойти вовсе не означает, что надо действовать так, как будто это событие уже произошло. Можно к нему быть готовым, это да, но действовать будто оно уже случилось, как-то не правильно. Все люди когда-нибудь умрут причем вероятность оного события 100%, но это вовсе не означает, что всем срочно пора в крематории или самозакапываться в землю.
Moskus
05.05.2022 06:11Верно, в отношении данных, которые могут утечь, правильная стратегия - считать, что утечка может произойти в любой момент (и иметь план на такой случай). Потому что если считать, что она уже произошла, то нужно постоянно (с какой периодичностью?) инвалидировать данные, которые могут быть использованы злоумышленниками. Это организационно невозможно, пока, например, вся аутентификация не включает TOTP или подобные средства. И то, даже TOTP имеет время жизни (стандартно - 30 секунд), которое, в принципе, позволяет ему быть перехваченным.
Стратегия "то, что могло произойти, должно считаться произошедшим" реалистично может (и должна) реализовываться только для ситуаций с известными возможностями утечек. В этом случае, неопределенность разрешается в пользу допущения, что произошёл худший сценарий. И вот тогда нужно заниматься инвалидацией, оповещением, прочими мерами, зависящими от контекста.
A_kris7
04.05.2022 20:52И вот тут начинаешь судорожно вспоминать а где ты зареган и что можно сделать с той инфой, с которой ты регался. Насколько она чувствительна и куда бежать, если её сольют.
ZekaVasch
05.05.2022 00:47Это вы список утечек.
А ведь можно просто пойти и официально купить кучу баз (обновляемых) для систем Кронос. Там и телефоны и адреса и все виды правонарушений. Эти базы покупают и пользуют все банки для проверки человека на выдачу кредитов.
Да там много чего есть.
antirek
05.05.2022 08:34+2рассматриваете только как пользователь
что делать сервисам, чтобы их БД, даже утекши, не несли чувствительных данных? или невозможно было использовать на стороне?
на стороне компании даже если данные будут разнесены по базам данных, разным сервисам есть возможность собирать и "компилировать" новую бд с сопоставленными данными
FlashHaos
05.05.2022 14:21+2Тем не менее, если разнести разные части данных по разным базам и разграничить доступ - то получится резко сократить вероятность этой «компиляции». См. кейс Яндекса, где дамп одной базы содержал все данные.
Можно запретить пакетные выгрузки в пользовательском интерфейсе, это позволит избежать кейса Сбербанка, когда юзер без доступа к непосредственно инфраструктуре смог выгрузить десятки тысяч номеров карт.
Можно использовать системы маскировки, по типу DPAN для номеров карт - когда в базе хранится не реальный номер карты, а первые и последние цифры от реального, а посередине некий хэш, который расшифровывается в отдельном сервисе со своими отграничениями.
Вариантов много, все это давно известно и работает. Надо просто не забивать на это.
А в текущей реальности, когда нет ни нормальных штрафов, ни репутационных рисков (в России, по крайней мере), всем наплевать. Вот сбер например до начала войны пытался строить компанию мирового уровня, думал о репутации (какая она ни была) - и сбер крепко усвоил урок, полученный после слива данных. Безопасность такие чистки устроила, так инфраструктуру затрахала, что пыль стояла. Так должно быть везде. И, желательно, заранее.
antirek
06.05.2022 08:00спасибо за ваш комментарий, почитал про DPAN
но, например, откуда такой подход возьмется? т.е. книги по базам данных рассказывают про стойкость пароля, а не то, что учетки надо хранить закодированными, и разные БД можно использовать
какие инструменты использовать, чтобы разработчикам было прозрачно подключить их к их сервисам и приложениям, чтобы эту безопасность можно было включить быстро, дешево и сердито? какие-то обертки над библиотеками по доступу к данным?
вариантов много и каждый может придумывать свои костыли. вот в плане авторизации сделали oAuth для логина в веб-сервисы, и стало очень удобно, ваши пользователи авторизуются через любой сервис Google/VK/другой сервис oauth-провайдер. и безопасно, т.к. вы по сути не занимаетесь авторизацией
если перевести в экономический разрез, то сейчас штраф за утечку данных небольшой, а разработка в плане безопасности - сложно и затратно. как сделать разработку в плане безопасности дешевле и быстрее? прям чтоб по чек-листу: это включили, это добавили, это внедрили - данные в безопасности
интересуют стандарты/книги/блоги/статьи
как пример, snyk.io интегрируется в процесс CI/CD просто, внедряешь и регулярно сканируешь свой код и зависимости на уязвимости - поддерживать проект актуальным достаточно дешево
FlashHaos
06.05.2022 19:38Я инфраструктурный инженер/менеджер, к data governance отношения мало имею, потому не могу ответить на Ваш вопрос.
Возможно, один из ответов кроется в стандарте PCI DSS. Честно скажу, читал поверхностно и только в части меня интересующей (бекапы, сетевая связность).
Но кроме статей - есть же банальная логика. Вы, конечно, правы - вопрос цены. Тот же Яндекс - пока штраф за утечку 60к, а рынок монополизирован, им выгоднее держать все данные в одной базе. Так же проще жить, дешевле писать. Атмосфера всеобщего доверия и большого стартапа, опять же. Знаю про это из первых рук.
anonym0use
05.05.2022 11:19> А вы что думаете?
Думаем что цифровой гулаг должен быть остановлен и рано или поздно это произойдет, но не раньше чем достаточное кол-во людей пострадает и осознает важность проблемы, к сожалению.
А пока простые советы в том, чтобы не плодить кучу аккаунтов, если только они не являются абсолютно необходимыми, не сливать данные направо и налево, заполнять фейковые где возможно и искать альтернативы требующие меньше/не требующие чувствительных данных.
JPEGEC
05.05.2022 12:08+1Касаемо конкретно телефонных номеров, я лично категорически за то что бы по любому существующему номеру вполне официально можно было увидеть ФИО владельца/наименование юрлица.
Адрес, конечно, это уже лишнее, я в принципе не понимаю для чего оператору такая информация в ней нет смысла если номер мобильный.
deathbel
05.05.2022 14:31А чего не упомянули слитую базу "Паспорт" МВД Беларуси? или тут только то, что подтвердили владельцы и то что потом появилось в открытом доступе?
MagisterLudi Автор
05.05.2022 14:32тут то что нашел за 2 часа поверхностного поиска
не было целью найти ВСЁ, хотел найти достаточно чтоб доказать (себе), что всё сливается
jupiter64
05.05.2022 16:20Взломы это следствие кривости софта. Пока к софту не будет отношения, как к надежности моста/самолета - проблема не сдвинется. Все ПО сейчас относится к разряду "фитюлек", а не инструментов. Никто не несет ответственности за неправильно работающее ПО. ПО, за которое выложены огромные деньги требует доработки "напильником", настройки сотни неочевидных параметров. Проблем полон рот, но никто об этом не говорит всерьез - в этом и корень проблемы. Поставил, работает и забыл - вот должен быть принцип работы enterprise ПО. Остальное отнесется к человеческому фактору, но это 10% проблем.
FlashHaos
05.05.2022 20:39Уж что-что, а самолёт вовсе не «работает и забыл». Да и с мостами все не так просто.
sneka
05.05.2022 21:13В одном фантастическом произведении оплата производилась биометрическим поцелуем. потому что перед этим утекла база биометрии пальцев :)
ЗЫ: Полностью поддерживаю автора.
Iguana2
07.05.2022 09:07С 1996 по 2011 я работал/являлся (о, три буквы Я в одном слове)) ИП - индивидуальным предпринимателем. Работал с юр лицами, но в большинстве с гражданами. За эти годы были выписаны тысячи договоров, накладных, счетов-фактур и прочих бумаг с указанием моих фио, инн, даты рождения, данных паспорта, домашнего адреса, телефонов. Розданы десятки, а может сотни копий паспорта, инн, постановки на налоговый учет. Пока живой)) В 2012 сменил номер мобильного. Не, не в целях абстрактной безопасности, а ибо достали старые клиенты и новые желающие.
vilgeforce
Это такой намек на то, что в ближайшие часы будет обнаружена слитая база клиентов Timeweb?
tw_community
Нет, мы исследуем регулярно инциденты чужих компаний для того, что бы не допускать подобных случаев, и используем современные практики по защите от таких утечек.