Защита информации от посторонних - это шифрование. Шифрование представляет собой способ скрытия данных с помощью ключа или пароля. Это делает данные бесполезными без соответствующего ключа или пароля для дешифрования.
Защита должна всегда начинаться с разграничения прав доступа, но, даже в случае обхода системы управления правами, шифрование поможет защитить информацию. Например, когда база данных попадет в чужие руки, украденная или изъятая информация будет бесполезна, если она была предварительно зашифрована.
Мы уже публиковали обзор средств шифрования , поэтому необходимо напомнить следующее:
1. В обзоре рассматривались «универсальные» криптосистемы, работа которых в большей степени не зависит от платформы.
2. Рассмотренные системы обеспечивают шифрование информации хранимой на диске, а прозрачный режим расшифровывает данные «на лету» и передает их в незащищенном виде другим приложениям.
3. Данные средства работают самостоятельно в стеке между приложениями и носителями информации, что требует дополнительных ресурсов производительности и добавляет еще одно звено в цепочку передачи данных.
Учитывая все вышесказанное, возникает закономерный вопрос: нет ли более простого решения? Можно ли пожертвовать универсальностью решения в пользу производительности, удобства, безопасности, учитывая специфику работы с информацией в конкретной организации?
Допустим, в компании используется ERP, CRM или учетная система, данные которых необходимо защищать. Любая из этих систем не привязана к какой-то определенной СУБД и у нас есть свобода выбора. Тогда стоит обратить внимание на систему управления базами данных Microsoft SQL Server. Компания Microsoft стала больше уделять внимания безопасности в своих продуктах – и вот что это нам принесло на сегодняшний день.
Шифрование баз данных средствами MS SQL Server
В Microsoft SQL Server 2008 впервые реализовано прозрачное шифрование баз данных (Transparent Data Encryption). Прозрачное шифрование кодирует базы данных целиком. Когда страница данных записывается из оперативной памяти на диск, она шифруется. Когда страница загружается обратно в оперативную память, она расшифровывается. Таким образом, база данных на диске оказывается полностью зашифрованной, а в оперативной памяти – нет. Основным преимуществом TDE является то, что шифрование и дешифрование выполняются абсолютно прозрачно для приложений. Использовать преимущества шифрования может любое приложение, использующее для хранения своих данных Microsoft SQL Server. При этом модификации или доработки приложения не потребуется.
В Microsoft SQL Server 2012 функции шифрования были улучшены и расширены. Для увеличения надежности криптозащиты и уменьшения нагрузки на систему применяется специальная иерархия ключей.
1. Каждой базы данных шифруется при помощи специального ключа – Database Encryption Key.
2. Database Encryption Key шифруется сертификатом, который создан в базе данных Master.
3. Сертификат базы данных Master шифруется ее главным ключом.
4. Главный ключ БД Master шифруется главным ключом службы Service Master Key.
5. Главный ключ службы SMK шифруется службой защиты данных операционной системы.
Наглядно схема работы с зашифрованной базой данных выглядит следующим образом:
Рисунок 1 - Схема работы с зашифрованной базой данных
В приведенной схеме используется, как симметричное, так и ассиметричное шифрование. Симметричное шифрование менее требовательно к ресурсам системы, но крайне уязвимо в управлении криптоключами. Ассиметричный метод, наоборот, защищен на этапе менеджмента ключей, но, по той же причине, требует значительно больше вычислительных ресурсов. Использование комбинации обоих методов позволяет нейтрализовать недостатки каждого из них, но повысить ИТ-безопасность и производительность в целом.
Так, база данных защищается более быстрым симметричным шифрованием, которое, при учете больших объемов информации, предпочтительнее. В свою очередь, ассиметричному шифрованию подвергаются ключи шифрования базы, размер которых несоизмеримо мал, но критичность их защиты выше. Использование такого подхода, на серверах с низким уровнем ввода/вывода, низким потреблением процессорного времени и оперативной памятью, достаточной для хранения больших массивов информации, влияет на производительность на 3-5% при включении TDE. Серверы с меньшим объемом ОЗУ, чьи приложения нагружают ЦПУ и систему ввода/вывода, будут страдать на 28%, что достигается асинхронным выполнением процедур SQL (распараллеливание процессов).
Что следует понимать и помнить при использовании TDE
При включении функции Transparent Data Encryption для любой пользовательской базы происходит следующее:
- шифруется база, для которой включено шифрование;
- шифруется журнал транзакций пользовательской базы данных;
- шифруется общая временная база данных tempdb.
Также следует отметить, что Transparent Data Encryption (TDE) не заменяет криптографические возможности SQL Server 2005. Шифрование в MS SQL Server 2005 работает на уровне значений и столбцов, а Transparent Data Encryption (TDE) – на уровне базы данных – на более высоком уровне. Данное решение не защитит от системного администратора или администратора SQL Server, но идеально противостоит краже или изъятию самой базы данных.
Но что же делать, если соединение между сервером СУБД и клиентом не может считаться доверительным? Информация, которой они обмениваются, может быть перехвачена, «подслушана» или подменена – ведь рассмотренные средства не защищают сетевые соединения, а дополнительная организация шифрованных каналов, особенно проприетарных, влечет за собой дополнительные расходы производительности и финансов.
Шифрование соединения средствами MS SQL Server
Если возможность прозрачного шифрования появилась лишь в SQL Server 2008, то защита соединения между сервером и клиентом известна еще со времен SQL Server 7.0. К релизу 2012 она претерпела значительные доработки. Если раньше, для передачи конфиденциальных данных использовался протокол SSL, то теперь пакеты «оборачиваются» в его логическое продолжение – протокол TLS.
По заявлению Microsoft: «SQL Server всегда шифрует сетевые пакеты, связанные со входом в систему. Если сертификат не был предоставлен на сервере при запуске, SQL Server создает самозаверяющий сертификат, который используется для расшифровки пакетов входа». И это действительно так: сервер создает собственный сертификат, который принимается клиентом, но шифруется лишь информация о соединении.
Чтобы шифровать всю информацию по каналу «клиент-сервер-клиент», необходимо выдать серверу корневой (доверенный) сертификат, импортировать его на клиентские станции и настроить схему взаимодействия криптоалгоритмов. Одной из наиболее результативной схем будет шифрование трафика симметричным методом, в то время, как ключи защищаются открытыми сертификатами.
Подводя итоги
Возможности Microsoft SQL Server 2012, в плане безопасности, расширяют границы системным администраторам и интеграторам для маневрирования и полета инженерной мысли. Возможность комбинирования блочных и поточных технологий шифрования с симметричными и асимметричными методами; реализация прозрачного шифрования баз данных; защита сетевых соединений и отдельных ячеек - это уже наши инструменты сегодня.
Системная интеграция. Консалтинг
Базит Фарук
Сообщения о потерях и несанкционированном доступе к конфиденциальным данным появляются все чаще, а значит безопасность баз данных - весьма актуальная проблема для многих компаний. Организации, в чьих базах данных хранится конфиденциальная информация, должны соблюдать требования многочисленных законодательных актов, в том числе Грэмма-Лича-Блайли (GLBA), директивы защиты данных ЕС (EUDPD), акта о преемственности и подотчетности медицинского страхования (HIPAA), стандарта безопасности данных индустрии платежных карт (PCI DSS) и закона Сарбейнса-Оксли (SOX). Эти законы требуют шифрования конфиденциальной информации на уровне базы данных и операционной системы. , как и другие распространенные коммерческие системы управления базами данных, располагает множеством вариантов шифрования, в том числе на уровне ячеек, базы данных и файлов через Windows, а также на транспортном уровне. Эти варианты шифрования обеспечивают безопасность информации на уровне базы данных и операционной системы. Кроме того, они снижают вероятность несанкционированного раскрытия конфиденциальных сведений, даже если поражены инфраструктура или база данных . После описания модели шифрования я рассмотрю возможности шифрования, реализованные в , а также способы шифрования конфиденциальной информации, сохраненной в базах данных .
Модель шифрования SQL Server
Теперь мы можем приступить к шифрованию данных. Для этого необходимо сначала открыть симметричный ключ, только что созданный с помощью команды OPEN SYMMETRIC KEY, за которой следует имя симметричного ключа. Затем вы указываете, что нужно расшифровать его с использованием заданного асимметричного ключа. Программный код выглядит следующим образом:
USE GO OPEN SYMMETRIC KEY MySymmetricKey DECRYPTION BY ASYMMETRIC KEY MyAsymmetricKey WITH PASSWORD = "StrongPa$$w0rd!" GO
После выполнения этого кода направьте запрос в представление sys.openkeys, чтобы убедиться, что ключ открыт:
USE GO SELECT * FROM .
Будут получены результаты, аналогичные показанным на рисунке 2. Наконец, необходимо ввести несколько номеров кредитных карт в таблицу CreditCardInformation, запустив код из листинга 2 . Затем направьте запрос к таблице CreditCardInformation:
USE GO SELECT * FROM .[ CreditCardInformation]
Как показано на рисунке 3, все данные в столбце CreditCardNumber представлены в двоичном формате. С помощью функции DECRYPTBYKEY можно просмотреть зашифрованные данные:
USE GO SELECT CONVERT((32), DECRYPTBYKEY(CreditCardNumber)) AS FROM . GO
Результаты показаны на рисунке 4.
Демонстрация 2. Во второй демонстрации данные шифруются с использованием асимметричного ключа, но на этот раз симметричный ключ шифруется сертификатом. Для этого выполните код из листинга 3 . Сначала создается сертификат с помощью инструкции CREATE CERTIFICATE. Затем создается симметричный ключ, шифруемый сертификатом. Наконец, открыв симметричный ключ, код вставляет три строки в таблицу CreditCardInformation.
Преимущества и недостатки шифрования на уровне ячеек
У шифрования на уровне ячеек есть свои достоинства и недостатки. Среди достоинств - более детальный уровень шифрования, что позволяет зашифровать единственную ячейку внутри таблицы. Кроме того, данные не расшифровываются, пока не придет время их использовать, то есть данные из загруженной в память страницы зашифрованы. Можно назначить ключ пользователям и защитить его паролем, чтобы предотвратить автоматическую расшифровку.
Среди недостатков шифрования на уровне ячеек - необходимость изменения схемы, так как все зашифрованные данные должны быть сохранены с использованием типа данных varbinary. Кроме того, снижается общая производительность базы данных из-за дополнительной обработки при шифровании и расшифровке данных. Требует времени и просмотр таблицы, поскольку индексы для таблицы зашифрованы и не могут быть использованы.
Прозрачное шифрование данных
В SQL Server 2008 появилась возможность зашифровать всю базу данных с использованием прозрачного шифрования. При таком шифровании можно защитить базы данных без изменения существующих приложений, структур баз данных или процессов. Это лучший вариант для выполнения требований нормативных актов и правил корпоративной безопасности, поскольку шифруется вся база данных на жестком диске.
Прозрачное шифрование данных шифрует базы данных в реальном времени, по мере внесения записей в файлы (*.mdf) базы данных и файлы (*.ldf) журнала транзакций. Записи также шифруются в реальном времени во время резервного копирования базы данных, а затем формируются моментальные снимки. Данные шифруются перед записью на диск и расшифровываются перед извлечением. Процесс полностью прозрачен для пользователя или приложения, поскольку выполняется на уровне SQL Server Service.
Листинг 1. Программный код для создания ключей для демонстрации 1
USE GO - Создание асимметричного ключа, зашифрованного - парольной фразой StrongPa$$w0rd! CREATE ASYMMETRIC KEY MyAsymmetricKey WITH ALGORITHM = RSA_2048 ENCRYPTION BY PASSWORD = "StrongPa$$w0rd!" GO - Создание симметричного ключа, зашифрованного - асимметричным ключом. CREATE SYMMETRIC KEY MySymmetricKey WITH ALGORITHM = AES_256 ENCRYPTION BY ASYMMETRIC KEY MyAsymmetricKey GO
Листинг 2. Программный код для заполнения таблицы CreditCardInformation
USE GO DECLARE @SymmetricKeyGUID AS SET @SymmetricKeyGUID = KEY_GUID("MySymmetricKey") IF (@SymmetricKeyGUID IS NOT NULL) BEGIN INSERT INTO . VALUES (01, ENCRYPTBYKEY(@SymmetricKeyGUID, N"9876-1234-8765-4321")) INSERT INTO . VALUES (02, ENCRYPTBYKEY(@SymmetricKeyGUID, N"9876-8765-8765-1234")) INSERT INTO . VALUES (03, ENCRYPTBYKEY(@SymmetricKeyGUID, N"9876-1234-1111-2222")) END TRUNCATE TABLE .
Листинг 3. Программный код для шифрования данных с использованием симметричного ключа,
зашифрованного сертификатом
USE GO - Создание сертификата. CREATE CERTIFICATE WITH SUBJECT = "Самозаверяющий сертификат для шифрования симметричного ключа." - Создание симметричного ключа, зашифрованного - сертификатом. CREATE SYMMETRIC KEY WITH ALGORITHM = AES_256 ENCRYPTION BY CERTIFICATE - Открытие симметричного ключа. OPEN SYMMETRIC KEY DECRYPTION BY CERTIFICATE - Усечение таблицы CreditCardInformation. TRUNCATE TABLE . - Вставка данных в таблицу. DECLARE @SymmetricKeyGUID AS SET @SymmetricKeyGUID = KEY_GUID("SymmetricKeyEncryptedWithCert") IF (@SymmetricKeyGUID IS NOT NULL) BEGIN INSERT INTO . VALUES (01, ENCRYPTBYKEY(@SymmetricKeyGUID, N"9876-1234-8765-4321")) INSERT INTO . VALUES (02, ENCRYPTBYKEY(@SymmetricKeyGUID, N"9876-8765-8765-1234")) INSERT INTO . VALUES (03, ENCRYPTBYKEY(@SymmetricKeyGUID, N"9876-1234-1111-2222")) END
Я пытаюсь создать платформу для пользователей, которые будут хранить конфиденциальные данные о своих клиентах. Контекст довольно прост: французские законы запрещают мне иметь доступ к данным, которые хранят мои пользователи (например, медицинские записи пациентов).
Поэтому, когда пользователь отправляет данные, которые будут храниться в базе данных, он должен быть единственным, имеющим доступ к этой информации. Например, зашифровав его своим паролем. Таким образом, если я войду в mysql, я бы увидел только зашифрованную глупость и нечитаемые данные.
Моя философия, которая может быть неправильной, заключается в том, чтобы учиться, выполняя ее. Надеюсь, вы, ребята, в порядке с моим подходом.
Проблема в том, что я понятия не имею, с чего начать, как это сделать... и даже не на то, что искать в google. Я даже пытался найти что-то подходящее на codecanyon.net, например, и не мог любить любые соответствующие сценарии.
Заранее спасибо:)!
PS: У меня будет такая же проблема с файлами (jpg, word, pdf, xls..., которые должны быть достаточными для пользователей). Но эта другая история.
3 ответов
Хотя я не знаком с французскими законами о защите данных, у меня есть некоторый опыт в общем законодательстве ЕС. Возможно, вам необходимо шифровать личные данные в вашей системе таким образом, чтобы человек не мог быть идентифицирован. Это означает, что технические данные, такие как идентификатор системы в таблице, могут оставаться незашифрованными. Это единственная причина, по которой я считаю, что вы действительно можете сделать эту работу. Вроде. Вы должны работать с юристами, чтобы определить, какие данные могут оставаться незашифрованными, чтобы соответствовать законам и все еще иметь возможность предоставлять ценные услуги вашим клиентам.
Однако я считаю, что вам не хватает важного момента: если у вас нет доступа к определенным данным, эти данные НЕ ДОЛЖНЫ поступать в вашу организацию в обычном формате. Период. Если да, то у вас уже есть доступ к нему. Таким образом, php (или любое шифрование на основе сервера) или основанные на mysql решения для шифрования не соответствуют действительности.
Единственное решение, о котором я могу думать, это объединиться с сторонним поставщиком PKI, который предоставит вашим клиентам сертификаты (возможно, на чип-картах), а клиентская сторона вашего приложения шифрует чувствительные персональные данные на клиент, прежде чем они будут отправлены на ваш сервер, а также расшифруйте эти элементы данных на клиенте. Это также означает, что вам нужно будет использовать некоторые плагины на стороне клиента, если вы хотите, чтобы эта система была веб-. Возможно, вам понадобится какое-то подписанное приложение java для управления устройством чтения карт и сертификатом.
У установки есть 2 недостатка для ваших клиентов:
Итак, предполагая, что проблема такова:
- Вам необходимо зашифровать данные перед их сохранением.
- У вас не должно быть ключей для его расшифровки, только зашифруйте его.
На самом деле это инструмент: он называется API герметизации , и это может быть достигнуто через OpenSSL или Libsodium.
Вообще-то, у меня тоже есть аналогичный проект, где я пытаюсь создать безопасную базу данных в MySQL Server, что также полезно для запуска всех действительных SQL-запросов. Он все еще находится в процессе, и существует слишком много трудностей; Я согласен.
Но для вашей проблемы кажется, что вам нужно только шифровать и расшифровывать значения. И вы не хотите хранить ключ, также находящийся в базе данных. Для меня есть два пути, которые возникают у меня в голове:
Первый способ заключается в том, что вы решаете использовать фиксированный секретный ключ для шифрования и дешифрования значений и использования его для всех данных, которые хранятся в базе данных.
Но я не думаю, что это не практично, так как безопасность становится слабым при таком подходе, и человек может идентифицировать ваш ключ с помощью грубой силы.
Второй способ: генерировать случайный ключ для каждого другого пользователя, например, во время регистрации. И данные другого пользователя могут быть просмотрены только пользователем, у которого есть ключ для его расшифровки, который здесь только у пользователя. И затем вы применяете первый подход после этого. т.е. вы выбираете ключ, который будет использоваться для шифрования этих ключей разных пользователей. а затем сохраните этот зашифрованный ключ в базе данных в отдельной таблице. Чтобы в следующий раз пользователь попытался получить доступ к своим данным, его введенный ключ (может быть его пароль) будет зашифрован вашим выбранным статическим ключом, если этот зашифрованный ключ находится в таблице вашей базы данных, вы получите данные этого пользователя, расшифровать его своим ключом и отобразить его/ее.
Все, что вам нужно, это,
(i) платформа программирования для выбора, лучше JAVA.
(ii) узнать, как использовать базу данных с этим языком программирования, MySQL Server - отличный выбор для работы.
(iii) И хороший алгоритм шифрования для реализации.
Надеюсь, я не рассердился на этот ответ:) Приветствия.
Чтобы предотвратить несанкционированное использование базы данных Access, ее можно зашифровать с помощью пароля. После этого расшифровать базу данных и удалить пароль можно будет, только введя его. В этой статье описано, как зашифровать базу данных с помощью пароля, а также расшифровать ее и удалить из нее пароль.
В более ранних версиях Access можно создать учетные записи пользователей и паролей, используя функцию с именем безопасности на уровне пользователя. В этом разделе рассматривается безопасности на уровне пользователя, который не поддерживается при использовании формате ACCDB.
Зашифрованную базу данных, пароль от которой утерян, невозможно использовать. Если пароль неизвестен, его нельзя удалить.
В этой статье
Обзор
С помощью средства шифрования можно предотвратить чтение базы данных через другие средства и защитить ее паролем. При этом необходимо помнить указанные ниже правила.
Новая функция шифрования действует только в отношении баз данных в формате ACCDB.
Это средство использует более стойкий алгоритм шифрования, чем в предыдущих версиях Access.
При шифровании баз данных, созданных в более ранних версиях Access (MDB-файлов), или применении к ним паролей используются соответствующие функции из Access 2003.
Шифрование базы данных с помощью пароля
В этом разделе описано, как создать пароль и применить к базе данных Access рабочего стола.
Шифрование базы данных
Шифрование разделенной базы данных
Чтобы зашифровать разделенную базу данных, эту процедуру нужно выполнить для ее интерфейсной и серверной части. При шифровании серверной базы данных изменяются связи с ее таблицами.
Открытие и расшифровка базы данных
Напоминание. Обязательно запомните пароль. Забытый пароль невозможно восстановить.
Как же ошибаются те люди, которые доверяют защиту данных исключительно самой
СУБД. Мол, если пароль на подключение хороший и версия демона – самая последняя,
то все будет нормально. Ничего подобного. Базы как сливали, так и будут сливать.
А наша задача – сделать их нечитаемыми для тех, кому они не предназначены.
Актуальная проблема из мира информационной безопасности – обеспечить
сохранность данных. Есть ситуации, в которых даже при наличии серьезной защиты
системы, сохранность данных оказывается под большим вопросом. Как так? Могу
привести пример из личного опыта, когда в разглашении информации был виновен
засланный сотрудник конкурирующей компании. Находясь на рабочем местом и будучи
технически подкованным, он взламывал сервера баз данных банальным брутфорсом
через терминальное соединение. Базы с клиентами "засланец" перепродавал другим
компаниям, а "интересная" информация о ведении бизнеса отправлялась сотрудникам
силовых структур. Что из этого вышло, объяснять излишне.
Вообще, имея физический доступ к локальной сети, инсайдер мог поступить
гораздо проще: атаковать программу, которая работает с базой данных. Нередко
сценарий взлома сводится к тому, что из программы разными способами извлекаются
конфиги для подключения к базе. Захватив ту же 1С, которая хранит в себе конфиги
подключения к базе (в том числе, шифрованный обычным XOR’ом пароль),
злоумышленник получает доступ к самой базе. Особо не стесняясь, он может ее
выкачать, модифицировать или просто удалить. Такая брешь в защите способна
сыграть злую шутку, особенно в корпоративной среде.
В статье я как раз хочу рассказать о том, как обезопасить информацию в
обычной базе данных. Даже если СУБД будет взломана или левый человек скопирует
данные, утечки конфиденциальной информации не произойдет!
Шифрованию – быть!
Общий подход прост до гениального: раз злоумышленник гипотетически сможет
извлечь данные, надо сделать так, чтобы он их не смог прочитать. Информацию все
равно придется хранить в базе, но… ничего не мешает хранить ее в каком угодно
виде, в том числе зашифрованном! Главное, чтобы мы сами потом смогли
расшифровать:).
Компания Spelabs (www.spellabs.ru/spellabsCrypto1C.htm)
как-то анонсировала продукт, организующий дополнительную безопасность
бухгалтерских 1С на уровне шифрования данных, причем на полностью прозрачном
уровне. Пользовательские приложения, не подозревая о надстройке, работали в
обычном режиме. Увы, компания прекратила разработку этого направления. Но
реально обойтись и без подобных инструментов, ведь для шифрования сгодятся даже
штатные средства СУБД!
Любая современная СУБД, если это, конечно, не собранная на коленке курсовая,
может похвастаться достаточно надежными механизмами шифрования данных. В той же
самой MySQL я по памяти насчитал около 14 соответствующих функций, которые тебе
наверняка хорошо известны:
- AES_ENCRYPT() — шифрование AES
- AES_DECRYPT() — расшифровка AES
- COMPRESS() — возвращение результата в бинарном виде
- DES_ENCRYPT() — шифрование DES
- DES_DECRYPT() — дешифрование DES
- ENCODE()
— шифрование строки поверхностным паролем (на выходе
получается шифрованное слово первоначальной "plaintext" длины - DECODE() — расшифровка текста, обработанного функцией ENCODE()
- ENCRYPT() — шифрование с помощью Unix’ового системного вызова crypt
- MD5() — подсчет MD-5 суммы
- SHA1() , SHA() — подсчет SHA-1 (160-бит)
Для их применения надо лишь чуть изменить свои SQL-запросы, добавив в нужном
месте функции AES_ENCRYPT() или DES_ENCRYPT(), которые считаются наиболее
надежными в MySQL на текущий момент. Например, так:
INSERT INTO t VALUES (1,AES_ENCRYPT("text","password"));
Приятно признать, что хорошие программисты эти функции используют. Часто во
время проведения SQL-инжекции мне приходилось ломать голову и определять
функцию, которую использовал кодер для крипточки данных. В результате, требуется
производить те же AES_DECRYPT(AES_ENCRYPT()) наряду с unhex(hex()).
T-SQL
Помимо симметричного шифрования, когда упаковка и распаковка текста
производятся одним и тем же ключом (общим для двух участников обмена
сообщениями), поддерживается и ассиметричное криптование. Идея ассиметричных
алгоритмов подразумевает наличие двух ключей – открытого и закрытого
(секретного). Один из них используется для шифрования информации, а другой - для
дешифрования. Если кодирование осуществляется с помощью открытого ключа, то
расшифровать такие данные можно только с помощью парного ему закрытого.
Предлагаю разобраться с этим на примере Microsoft SQL Server, который часто
используется в корпоративных порталах и сложных приложениях.
Для шифрования применяются функции T-SQL, представляющие собой специальное
дополнение языка SQL. Оно поддерживает управляющие операторы, локальные
переменные и различные дополнительные функции.
Одна из таких функций — EncryptByCert(), используемая для ассиметричного
шифрования данных с помощью сертификатов. Открытым ключом тут выступает
сертификат. Только откуда этот сертификат взять? Ответ прост – сгенерировать с
помощью другой специальной функции. Покажу на примере, как можно сгенерировать
сертификат с именем для andrej базы "Bank" с помощью хранимой процедуры:
USE Bank;
CREATE CERTIFICATE andrej
ENCRYPTION BY PASSWORD = "pGFD4bb925DGvbd2439587y"
# Для генерации с использованием подгрузки из файла
# FROM FILE = "c:\Shipping\Certs\Shipping11.cer"
# WITH PRIVATE KEY (FILE = "c:\Shipping\Certs\Shipping11.pvk",
WITH SUBJECT = "Employers Access",
EXPIRY_DATE = "10/31/2009";
GO
У нас создался сертификат! Теперь его можно без проблем использовать для
размещения в таблице зашифрованных записей, выполняя привычные SQL-запросы:
INSERT INTO [БАЗА].[ТАБЛИЦА]
values(N"ДАННЫЕ ДЛЯ ЗАШИФРОВКИ’,
EncryptByCert(Cert_ID("andrej"), @cleartext));
GO
В этом примере неформатированный текст из переменной @cleartext шифруется
сертификатом с именем "andrej". Зашифрованные данные помещаются в таблицу
"ТАБЛИЦА". Уточню, что данные могут быть расшифрованы только с помощью
соответствующего закрытого ключа (как уже было сказано, "приватного").
Имя функции для обратного преобразования угадать несложно: DecryptByCert(). А
вот синтаксис более хитер, и с ним все чуть сложнее. Дело в том, что на
приватный ключ, как правило, закладывается дополнительный пароль (passphrase).
Его необходимо ввести, и по этой причине он обязательно будет присутствовать в
коде запроса или процедуры. Это не очень хорошо, потому что в этом случае его
можно быстро увести. Но с этим мы разберемся позже, когда поговорим о
безопасности хранимых процедур. А пока – код для извлечения данных из
шифрованной базы данных:
SELECT convert(nvarchar(max), DecryptByCert(Cert_Id("andrej"),
ProtectedData, N"pGFD4bb925DGvbd2439587y"))
FROM [БАЗА].[ТАБЛИЦА]
WHERE Description
= N"Employers Access’;
GO
В этом примере производится выборка строк из таблицы [БАЗА].[ТАБЛИЦА],
помеченных как "Employers Access". Пример дешифрует зашифрованный текст с
помощью закрытого ключа сертификата "Andrej" и дополнительного пароля
pGFD4bb925DGvbd2439587y. Расшифрованные данные преобразуются из типа varbinary в
тип nvarchar.
Надо сказать, что ассиметричные преобразования гораздо более накладны, чем
шифрование и дешифрование с использованием симметричного ключа. Поэтому
использование ассиметричного шифрования не рекомендуется при работе с большими
объемами данных, например, таблицами пользовательских данных. Это важно
учитывать при особо больших базах, а также базах, структура которых не приведена
к одной из нормальных форм.
Прячем хранимые процедуры!
Если ты не заметил, многое упирается в то, что вся конфиденциальность и
целостность завязана на использование хранимых процедур или функций. Получается,
что, получив к ним доступ и грамотно проанализировав их код, любой опытный хакер
сможет преобразовать шифрованную белиберду в исходный текст. Конечно, добраться
до кода процедур далеко не всегда реально, потому здесь всплывает вопрос об
утечке программной начинки производства, а именно – логике ПО. Но именно по этой
причине необходимо прибегать к шифрованию процедур и функций в базе. Одно из
самых популярных и удачных средств для таких действий – это программа SQL Shield
(www.sql-shield.com).
После несложной установки приложения не забудь указывать дополнительный флаг
/*sqlshield*/ с выражением "WITH ENCRYPTION" всякий раз, когда будешь создавать
защищенную процедуру. Вот пример функции, которая исполняет простейший запрос к
базе:
CREATE PROCEDURE MyTest
WITH /*sqlshield*/ ENCRYPTION
AS
SELECT 2+2
Исполняем процедуру и получаем:
MyTest
> 4
Проверим, в каком виде хранится процедура, с помощью специального средства
для ковыряния в файлах базы. Подойдет SQL Server Syscomments Decryptor (www.geocities.com/d0mn4r/dSQLSRVD.html),
который при отображении текста процедуры показывает одни лишь знаки вопроса.
Все работает!
Как облегчить себе жизнь?
В заключение – не менее интересный продукт XP_CRYPT (www.xpcrypt.com).
Это средство осуществляет весь тот геморрой, который мы только что проделали
вручную. Все, что от тебя требуется, – скачать дистрибутив проги, установить ее
на сервер (к сожалению, есть версия только для Винды), обозначить свою базу
данных и начать химию с таблицами с помощью удобного GUI-интерфейса.
Организуем знакомство на примере из практики. Предположим, у нас есть
интернет-магазин, где каким-то образом хранятся данные о кредитных картах
клиентов (распространенная ситуация, хотя это категорически запрещено!). Наша
задача — зашифровать конкретные данные о клиентах, т.е. поля с паролем, номером
кредитной карточки и т.п. Пока мы ничего не делали, при запросе SELECT * FROM
tbl_CCards, СУБД возвращает все в открытом виде:
Username Password CredCardNum
james god 1234567890123456
lucas sex 2894787650102827
anna love 3234563638716434
Напишем внешнюю функцию UDF (расшифровывается, как "User-Defined-Function",
подробности) для преобразования строки в SHA-хеш:
CREATE FUNCTION ud_MakeSHA1 (@clearpass VARCHAR (8000))
RETURNS VARCHAR (40)
AS
BEGIN
DECLARE @ret as VARCHAR(40)
EXEC master..xp_sha1 @clearpass,@ret OUTPUT
RETURN @ret
END
Отдаем команду: UPDATE tbl_CCards SET password = dbo.ud_MakeSHA1(Password).
После чего еще раз проверяем содержимое базы той же командой. Что видим? Все
зашифровано, все пароли захешировались!
Теперь нужно не забыть о том, что мы используем шифрование при обращении к
базе. В нашем случае, когда ты будешь делать авторизацию пользователей,
процедура проверки пароля по хешу будет выглядеть примерно так:
CREATE FUNCTION ud_CheckUser (@username VARCHAR(16),@clear_pass VARCHAR
(16))
RETURNS INTEGER
AS BEGIN
DECLARE @res INTEGER
SELECT @res = count(*) FROM tbl_CCards where username=@username AND
password=dbo.ud_MakeSHA1(@clear_pass)
IF @res > 1 SELECT @res= 0
RETURN @res
END
Проверяем исполнением команды:
SELECT dbo.ud_CheckUser ("anna","kolbaska")
>1 (неправильно)
SELECT dbo.ud_CheckUser ("anna","love")
>0 (окейно!)
К шифрованию номера кредитной карты надо подойти более серьезно. Впрочем, мы
не будем вникать в различного рода стандарты по информационной безопасности в
платежно-карточной сфере (вроде PCI; хотя организации, работающие с кредитными
картами, безусловно обязаны это делать). В бесплатной версии XP_CRYPT существует
возможность генерации только 256-битного ключа RSA. Вот этим и можно
воспользоваться (пусть упомянутый стандарт и требует, как минимум, 768-битного
ключа). Я бы мог сейчас привести код по генерации публичного и приватного ключа,
но… поступим проще. Все действия можно выполнить из понятного графического
интерфейса, и во многих случаях оставить все на совести программы, не написав ни
строчки кода. И поверь, будет работать!
Пример из личного опыта
Сотрудниками одной из компаний платежно-карточного сектора велась база данных
для выдачи зарплат. Для простого понимания, – пусть это будет примерно следующая
структура:
ID LastName FirstName Emp
Sum
354 Somov Oleg
IT-Manager M0x8900f56543
643 Antipova Alexandra Director
4343Lax#dsdsss
411 Timurov Valeriy Technical Dep.
0x2322322222
Выборку из базы я привел абсолютно произвольную, а теперь суть идеи.
"Безопасниками" компании было предпринято вполне благородное решение – шифровать
данные о зарплатах, которые очень часто бывают "серыми". Инсайдер получил доступ
к базе и сильно обломался, заимев информацию в таком виде. Однако, он не
отчаялся и проделал следующий фокус. Резонно предположив, что человек с
должностью директора должен получать больше, чем простой менеджер, он поменял
соответствующие поля со значениями зарплат одно на другое, тем самым – подложив
бухгалтерскому отделу абсолютно левую информацию. В благополучный день такая
вещь прокатила, и все безопасники были уволены. Для справки: этим сотрудником
был не я, как впрочем, и не безопасником.
Так делать не стоит
В SQL Server можно создавать четыре типа объектов (хранимые процедуры,
представления, пользовательские функции и триггеры) с параметром WITH
ENCRYPTION. Этот параметр позволяет зашифровать определение объекта таким
образом, что тот можно будет использовать, но получить его определение
стандартными способами станет невозможно. Это средство рекомендуется и
Microsoft. К сожалению, на практике никакой защиты применение стандартных
средств шифрования не обеспечивает! Алгоритм, используемый при шифровании
определений объектов, выглядит так:
- SQL Server берет GUID той базы данных, в которой создается объект, и
значение столбца colid таблицы syscomments для создаваемого объекта (чаще
всего, его значение – 1 или 2) и производит их конкатенацию; - Из полученного значения генерируется ключ при помощи алгоритма SHA;
- Этот хеш используется в качестве входящего значения при применении еще
одного алгоритма хеширования – RSA. С его помощью генерируется набор символов,
равный по длине шифруемому определению объекта; - С этим набором символов и с реальным определением объекта производится
операция XOR. В результате получаются данные, которые помещаются в столбец
ctext таблицы syscomments.
У этой схемы есть два слабых места:
- Нам ничего не мешает заиметь исходные значения (GUID и colid) для
выполнения тех же самых операций и получить ключ на расшифровку. Это можно
сделать, например, использовав утилиту dSQLSRVD. Правда, для получения GUID
базы данных (и для запуска этой утилиты) нам нужны права системного
администратора; - Если у нас есть права на создание объектов в базе данных, можно
сгенерировать точно такой же ключ для объекта, определение которого нам уже
известно (путем сравнения шифрованного определения с незашифрованным). Ну и –
использовать его для расшифровки значения другого объекта.
Как можно расшифровать зашифрованные объекты на SQL Server? Есть два
варианта:
- Использовать утилиту dSQLSRVD. Она позволяет выбрать любой зашифрованный
объект на сервере и записать его определение в текстовый файл; - Использовать хранимую процедуру DECRYPT2K. Код на создание данных хранимых
процедур (в разных вариантах и с разными объяснениями), которые расшифровывают
определение зашифрованных объектов, легко найти через Google.
