При шифровании базы данных ее файл сжимается и делается недоступным для чтения с помощью служебных программ или текстовых редакторов. Шифрование базы данных не ограничивает доступ пользователей к объектам. Дешифрование базы данных является операцией, обратной шифрованию.
Чтобы зашифровать или дешифровать базу данных, необходимо быть либо владельцем базы данных, либо, если база данных защищена, членом группы «Admins» с разрешением «монопольный доступ». Перед шифрованием базы данных рекомендуется сохранить ее с другим именем либо на другом диске или папке. В процессе шифрования Microsoft Access не заменяет исходную базу данных до успешного завершения шифрования. Необходимо иметь на диске достаточно места для исходной и зашифрованной версии базы данных.
Запустите Microsoft Access без открытия базы данных. При работе с сетевой (общей) базой данных убедитесь, что все пользователи закрыли базу данных.
Важно! Нельзя зашифровать или дешифровать открытую базу данных.
В меню Сервис выберите командуЗащита и подкомандуШифровать/дешифровать .
Укажите имя базы данных, которую требуется зашифровать или дешифровать, и нажмите кнопку OK .
Укажите имя, диск и папку для конечной базы данных и нажмите кнопку OK .
Если указаны те же имя, диск и папка, что и у исходной базы данных, а шифрование или дешифрование базы данных выполнено успешно, то исходный файл будет заменен на зашифрованный или дешифрованный. Если же операция приводит к ошибке, то исходный файл удален не будет.
Создание, присоединение и исправление файлов рабочих групп
В файле рабочей группы Microsoft Access хранятся сведения о членах рабочей группы, включая пароли пользователей. При открытии базы данных этот файл читается для определения пользователей, которым разрешен доступ к объектам базы данных, и разрешений, полученных пользователями на эти объекты.
Создание и присоединение файла рабочей группы
Файл рабочей группы содержит список пользователей, совместно использующих данные, также известный как рабочая группа. Пароли пользователей также запоминаются в файле рабочей группы. Для управления доступом к базе данных необходимо создать новый файл рабочей группы.
Запустите Microsoft Access.
В меню Сервис выберите командуЗащита , а затем командуАдминистратор рабочих групп .
В диалоговом окне Администратор рабочих групп нажмите кнопкуСоздать .
В диалоговом окне Сведения о владельце рабочей группы введите свое имя, название организации и любое сочетание букв и цифр длиной до 20 знаков в качестве кода рабочей группы (WID).
Введите имя нового файла рабочей группы. По умолчанию файл рабочей группы сохраняется в папке языка. Чтобы сохранить его в другой папке, введите новый путь или нажмите кнопку Обзор , чтобы выбрать новый путь.
Нажмите кнопку OK .
Новый файл рабочей группы будет использоваться при следующем запуске Microsoft Access. Любые создаваемые учетные записи пользователей и учетные записи групп, а также их пароли, сохраняются в новом файле рабочей группы. Чтобы присоединить к рабочей группе, определенной новым файлом рабочей группы, других пользователей, скопируйте этот файл в общую папку (если он не был сохранен на шаге 5 в общей папке); после этого каждый пользователь должен будет запустить «Администратор рабочих групп» и присоединиться к новому файлу рабочей группы.
Как же ошибаются те люди, которые доверяют защиту данных исключительно самой
СУБД. Мол, если пароль на подключение хороший и версия демона – самая последняя,
то все будет нормально. Ничего подобного. Базы как сливали, так и будут сливать.
А наша задача – сделать их нечитаемыми для тех, кому они не предназначены.
Актуальная проблема из мира информационной безопасности – обеспечить
сохранность данных. Есть ситуации, в которых даже при наличии серьезной защиты
системы, сохранность данных оказывается под большим вопросом. Как так? Могу
привести пример из личного опыта, когда в разглашении информации был виновен
засланный сотрудник конкурирующей компании. Находясь на рабочем местом и будучи
технически подкованным, он взламывал сервера баз данных банальным брутфорсом
через терминальное соединение. Базы с клиентами "засланец" перепродавал другим
компаниям, а "интересная" информация о ведении бизнеса отправлялась сотрудникам
силовых структур. Что из этого вышло, объяснять излишне.
Вообще, имея физический доступ к локальной сети, инсайдер мог поступить
гораздо проще: атаковать программу, которая работает с базой данных. Нередко
сценарий взлома сводится к тому, что из программы разными способами извлекаются
конфиги для подключения к базе. Захватив ту же 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.
Чтобы предотвратить несанкционированное использование базы данных Access, ее можно зашифровать с помощью пароля. После этого расшифровать базу данных и удалить пароль можно будет, только введя его. В этой статье описано, как зашифровать базу данных с помощью пароля, а также расшифровать ее и удалить из нее пароль.
В более ранних версиях Access можно создать учетные записи пользователей и паролей, используя функцию с именем безопасности на уровне пользователя. В этом разделе рассматривается безопасности на уровне пользователя, который не поддерживается при использовании формате ACCDB.
Зашифрованную базу данных, пароль от которой утерян, невозможно использовать. Если пароль неизвестен, его нельзя удалить.
В этой статье
Обзор
С помощью средства шифрования можно предотвратить чтение базы данных через другие средства и защитить ее паролем. При этом необходимо помнить указанные ниже правила.
Новая функция шифрования действует только в отношении баз данных в формате ACCDB.
Это средство использует более стойкий алгоритм шифрования, чем в предыдущих версиях Access.
При шифровании баз данных, созданных в более ранних версиях Access (MDB-файлов), или применении к ним паролей используются соответствующие функции из Access 2003.
Шифрование базы данных с помощью пароля
В этом разделе описано, как создать пароль и применить к базе данных Access рабочего стола.
Шифрование базы данных
Шифрование разделенной базы данных
Чтобы зашифровать разделенную базу данных, эту процедуру нужно выполнить для ее интерфейсной и серверной части. При шифровании серверной базы данных изменяются связи с ее таблицами.
Открытие и расшифровка базы данных
Напоминание. Обязательно запомните пароль. Забытый пароль невозможно восстановить.
Защита информации от посторонних - это шифрование. Шифрование представляет собой способ скрытия данных с помощью ключа или пароля. Это делает данные бесполезными без соответствующего ключа или пароля для дешифрования.
Защита должна всегда начинаться с разграничения прав доступа, но, даже в случае обхода системы управления правами, шифрование поможет защитить информацию. Например, когда база данных попадет в чужие руки, украденная или изъятая информация будет бесполезна, если она была предварительно зашифрована.
Мы уже публиковали обзор средств шифрования , поэтому необходимо напомнить следующее:
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, в плане безопасности, расширяют границы системным администраторам и интеграторам для маневрирования и полета инженерной мысли. Возможность комбинирования блочных и поточных технологий шифрования с симметричными и асимметричными методами; реализация прозрачного шифрования баз данных; защита сетевых соединений и отдельных ячеек - это уже наши инструменты сегодня.
Системная интеграция. Консалтинг
SSL/SSH protects data travelling from the client to the server: SSL/SSH does not protect persistent data stored in a database. SSL is an on-the-wire protocol.
Once an attacker gains access to your database directly (bypassing the webserver), stored sensitive data may be exposed or misused, unless the information is protected by the database itself. Encrypting the data is a good way to mitigate this threat, but very few databases offer this type of data encryption.
The easiest way to work around this problem is to first create your own encryption package, and then use it from within your PHP scripts. PHP can assist you in this with several extensions, such as Mcrypt and Mhash , covering a wide variety of encryption algorithms. The script encrypts the data before inserting it into the database, and decrypts it when retrieving. See the references for further examples of how encryption works.
Hashing
In the case of truly hidden data, if its raw representation is not needed (i.e. will not be displayed), hashing should be taken into consideration. The well-known example for hashing is storing the cryptographic hash of a password in a database, instead of the password itself.
// storing password hash
// $random_chars retrieved e.g. using /dev/random
$query
=
sprintf
("INSERT INTO users(name,pwd) VALUES("%s","%s");"
,
pg_escape_string
($username
),
pg_escape_string
(crypt
($password
,
"$2a$07$"
.
$random_chars
.
"$"
)));
$result
=
pg_query
($connection
,
$query
);
// querying if user submitted the right password
$query
=
sprintf
("SELECT pwd FROM users WHERE name="%s";"
,
pg_escape_string
($username
));
$row
=
pg_fetch_assoc
(pg_query
($connection
,
$query
));
if ($row
&&
crypt
($password
,
$row
[
"pwd"
]) ==
$row
[
"pwd"
]) {
echo
"Welcome, "
.
htmlspecialchars
($username
) .
"!"
;
} else {
echo
"Authentication failed for "
.
htmlspecialchars
($username
) .
"."
;
}
?>
6 years ago
I would strongly recommend using SHA-2 or better the new SHA-3 hash algorithm. MD5 is practically unusable, since there are very well working rainbow tables around the whole web. Almost the same for SHA-1. Of course you should never do a hash without salting!
7 years ago
Using functions to obfuscate the hash generation does not increase security. This is security by obscurity. The algorithm used to hash the data needs to be secure by itself.
I would not suggest to use other data as salt. For example if you use the username, you won"t be able to change the values without rehashing the password.
I would use a dedicated salt value stored in the same database table.
Why? Because a lot of users use the same login credentials on different web services. And in case another service also uses the username as salt, the resulting hashed password might be the same!
Also an attacker may prepare a rainbow table with prehashed passwords using the username and other known data as salt. Using random data would easily prevent this with little programming effort.
