Как сохранить тайну в тайне

Новые подходы к полной защите данных, или Как избежать гнева ваших клиентов

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

Не секрет, что многие компании полагаются лишь на запертые двери, сетевые экраны и контроль доступа. Проблема же состоит в том, что нападающий зачастую может обойти подобные защитные механизмы и направить команды SQL (structured query language — международный стандартный язык для определения и доступа к реляционным базам данных) прямо на сервер базы данных. Такую атаку называют инъекцией SQL. Например, если у вас есть таблица с именем Customers (клиенты), злоумышленник может послать команду SQL «Select * from Customers», чтобы скопировать всю вашу базу данных о клиентах.

Существует множество предложений по пресечению такого рода атак, включая разнообразные системы обнаружения вторжений и управляющие программы, ограничивающие объем данных, доступных для загрузки через Web-браузер по HTTP-запросу. Мы предлагаем ознакомиться с некоторыми многообещающими методами, ранее не привлекавшими особого внимания.

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

Метод 1 Не собирайте конфиденциальных данных

Лучший способ обеспечить безопасность базы данных состоит в том, чтобы с самого начала отказаться от сбора больших объемов конфиденциальной информации. Это не столь очевидно, как хотелось бы.

Многие организации по привычке регистрируют номера карточек социального страхования (Social Security number, SSN) либо (что еще хуже) превращают их в идентификационные номера для своих сотрудников и студентов. Вместо номеров SSN, которые легко использовать для кредитного мошенничества и воровства личной информации, предприятиям следовало бы ввести собственные случайные идентификационные номера, состоящие из 10-11 цифр. В любом случае, организации, обслуживающие широкие слои населения, должны иметь средства генерации случайных номеров, поскольку не у каждого есть номер SSN.

Метод 2 Оперативно избавляйтесь от конфиденциальной информации

Те, кому действительно нужно хранить конфиденциальные сведения, должны избавляться от них как можно быстрее. Например, во многих случаях после того, как транзакция зафиксирована, сохранять номер кредитной карточки клиента (credit card number, CCN) просто незачем (по истечении трехмесячного срока, возможно, имеет смысл хранить только последние четыре цифры). Те, кому номера CCN нужны для целей аудита, должны иметь возможность переместить их на вторичный сервер базы данных, не связанный с Internet.

Метод 3 Разделите или перераспределите данные

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

Хотя метод разделения секретной информации изобретен еще в 1979 году криптографом Ади Шамиром (Adi Shamir, первая буква его фамилии «S» вошла в название алгоритма шифрования RSA), до недавнего времени он в значительной степени представлял лишь академический интерес. Но с ростом числа взломов баз данных и вступлением в силу закона об обязательном уведомлении пользователей о подобных инцидентах, для некоторых приложений метод разделения секретов может стать привлекательным.

В 2003 году компания RSA Security предложила технологию Nightingale, которая радикально упрощала для предприятий интеграцию разделенной секретной информации в существующие приложения. В соответствии с этой технологией специальный сервер хранит половину секретной информации, а существующая база данных организации хранит вторую часть. Такие секретные данные, как номера кредитных карточек или криптографические ключи, извлекаются из базы только по мере реальной необходимости. Проще говоря, сотрудники информационно-справочной службы не смогут просматривать эти данные во время обеденного перерыва.

В некоторых специализированных приложениях можно использовать секретные сведения, даже не собирая их вместе! Этот способ называется криптографией с разделенным ключом, и технология Nightingale поддерживает один из таких вариантов. Криптография с разделенным ключом полезна в приложениях, где даже помыслить нельзя о том, что кто-то может похитить ваш ключ шифрования. В этом случае часть криптографических вычислений производится на одном компьютере с применением половины ключа, затем документ перемещается на другой компьютер, где вторая часть вычислений выполняется со второй половиной ключа. Это довольно сложный метод, но он привлекателен для некоторых специальных приложений (например, в организациях, которые хотят управлять центром сертификации высокого уровня).

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

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

Несколько лет назад независимый консультант и исследователь Питер Вейнер, специализирующийся на криптографических приложениях, придумал метод использования необратимых хеш-функций для дифференцированной защиты информации, хранящейся в базе данных. Например, база данных, содержащая хеш-коды номеров SSN, позволяет проверить SSN, введенный в поле Web-формы, но не дает возможности оператору (или хакеру) просмотреть все содержимое и прочесть список фамилий и номеров SSN. Дело в том, что простое предложение SQL «Select * from Customers» возвращает не клиентские номера SSN, а только их хеш-коды.

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

Метод 4 Раздуйте данные до немыслимых размеров

Больше всего мне нравится система защиты баз данных от просмотра или загрузки под названием Vast, разработанная Дэвидом Дагоном, Венком Ли и Ричардом Лайптоном в Технологическом институте Джорджии. В этой системе криптографические методы используются для неимоверного увеличения размера базы данных. Например, база объемом в 5-10 гигабайт может быть раздута так, что для ее хранения понадобится 10 или 20 терабайт. Доступ к отдельным записям осуществляется относительно быстро, но любой злоумышленник, пытающийся прочесть все данные целиком, немедленно столкнется с проблемой гигантского объема данных. Загрузка же случайных фрагментов базы данных не принесет никакой пользы, так как по замыслу создателей Vast, «секретная информация разделена на части и разбросана по большому файлу таким образом, чтобы ни одна из частей сама по себе не поддавалась восстановлению». Ученые описали Vast в исследовании Protecting Secret Data from Insider Attacks, представленном в 2005 году на конференции Financial Cryptography and Data Security. Дэвид Дагон в приватной беседе посетовал, как трудно было найти предпринимателей, которые заинтересовались бы коммерческим применением этого открытия, потому что сама идея хранить гигабайты данных на терабайтных накопителях казалась ужасно расточительной! Создавалось впечатление, что люди просто не понимали самую суть Vast — ведь стоимость нескольких десятков жестких дисков достаточно незначительна по сравнению с той степенью защиты, которую они могут обеспечить против весьма распространенных атак.

Метод 5 Шифруйте только часть

Организации, присматривающиеся к техническим новинкам, недавно вышедшим на рынок из исследовательских лабораторий, могут заинтересоваться некоторыми вариантами шифрования на уровне столбцов, в которых часть информации в базе данных шифруется, а другая остается без изменений. Решения на уровне столбцов теперь доступны для IBM DB2, Oracle, Microsoft SQL Server и даже для MySQL. В этих системах обычно используется либо код в составе приложения, либо специальная программа-посредник, чтобы зашифровывать данные при записи в базу и расшифровывать их при чтении. Шифрование на уровне столбцов не столь безопасно, как другие подходы, описанные в этой статье, потому что ключ для расшифровки обычно тем или иным образом встраивается в прикладную программу или в базу данных. Но это, без сомнения, лучше, чем отсутствие шифрования вообще.