О защите данных

О защите персональных данных или причина очередного слива

03.10.2019 на всю страну прогремела новость об очередном сливе базы данных карт пользователей очередного российского банка. Как обычно всех поразил масштаб утечки - 60 миллионов записей. СМИ тут же окрестили это «самой крупной утечкой в российском банковском секторе»... Сколько раз уже это было. Объемы только ширятся, а компании, допустившие утечку, вновь и вновь говорят об усилении внутренней безопасности. Что в этой ситуации удивляет, так это выводы большинства экспертов о том, что "не система корявая, а человеческий фактор", т.е. все беды из-за людей.

А Вы тоже считаете, что система не виновата?!

Проще всего спихнуть все на человеческий фактор. Мол, раз человек по натуре существо корыстное, то он ради личной наживы пойдет на что угодно...

А давайте зададимся вопросом, почему система позволила получить доступ к столь большому объему данных?
Почему система позволила человеку скопировать столь большой объем данных?

Моя позиция по сути проблемы любых утечек: всегда на первом месте вина архитектуры системы хранения.

Именно архитектура решения по хранению информации позволяет злоумышленнику что-либо выгрузить в подобном объеме.

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

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

Есть ли решение, способное защитить облачные данные от любых форм злонамеренных действий и любых лиц, в том числе администраторов серверов?

Есть. В качестве примера приведу наше решение SafeBASIS.

Архитектура безопасного хранения данных у нас построена на следующих принципах:

• Данные должны быть сегментированы, а сегменты хранится распределенно.
• Шифрация данных должна производится до сегментации.
• Индексы сегментации не должны хранится на серверах с сегментами.
• Ключ шифрования не должен быть статичной последовательностью кода, который легко украсть и применить вне системы.
• Сегменты должны быть многократно продублированы на разных серверах.
• Архитектура решения не должна позволять получать данные большими объемами по одному запросу.

Каким должен быть ключ шифрования?

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

Почему даже в очень крупных банках не смогли самостоятельно реализовать что-то подобное?

Ответов два и оба будут неприятны многим.

1. Узкомыслие современных разработчиков, повальное использование общепринятых форматов хранения данных (и даже, вдумайтесь, Open Source) и неспособность придумать что-то новое - вот корень зла в этой проблеме.

2. Нежелание действительно защищать персональные данные.

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

Если система не позволит совершить преступление - меньше будет и преступлений.

Эпилог

Масштабная утечка персональных данных, о которой шла речь в этой статье, произошла в 2019 году.

Решение SafeBASIS было разработано и предложено нами к внедрению в 2016 году.

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

Делайте выводы сами, хотят ли на самом деле бороться компании с утечками персональных данных или делают это лишь на словах.

Владимир Шляпин