Телевизор 

Шифрование в базах данных SQL Server. Шифрование базы данных с использованием пароля базы данных. Выдача прав на чтение зашифрованных столбцов

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

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

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

В этой статье

Обзор

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

    Новая функция шифрования действует только в отношении баз данных в формате ACCDB.

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

    При шифровании баз данных, созданных в более ранних версиях Access (MDB-файлов), или применении к ним паролей используются соответствующие функции из Access 2003.

Шифрование базы данных с помощью пароля

В этом разделе описано, как создать пароль и применить к базе данных Access рабочего стола.

Шифрование базы данных

Шифрование разделенной базы данных

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

Открытие и расшифровка базы данных

Напоминание. Обязательно запомните пароль. Забытый пароль невозможно восстановить.

Я пытаюсь создать платформу для пользователей, которые будут хранить конфиденциальные данные о своих клиентах. Контекст довольно прост: французские законы запрещают мне иметь доступ к данным, которые хранят мои пользователи (например, медицинские записи пациентов).

Поэтому, когда пользователь отправляет данные, которые будут храниться в базе данных, он должен быть единственным, имеющим доступ к этой информации. Например, зашифровав его своим паролем. Таким образом, если я войду в 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) И хороший алгоритм шифрования для реализации.

Надеюсь, я не рассердился на этот ответ:) Приветствия.

Как же ошибаются те люди, которые доверяют защиту данных исключительно самой
СУБД. Мол, если пароль на подключение хороший и версия демона – самая последняя,
то все будет нормально. Ничего подобного. Базы как сливали, так и будут сливать.
А наша задача – сделать их нечитаемыми для тех, кому они не предназначены.

Актуальная проблема из мира информационной безопасности – обеспечить
сохранность данных. Есть ситуации, в которых даже при наличии серьезной защиты
системы, сохранность данных оказывается под большим вопросом. Как так? Могу
привести пример из личного опыта, когда в разглашении информации был виновен
засланный сотрудник конкурирующей компании. Находясь на рабочем местом и будучи
технически подкованным, он взламывал сервера баз данных банальным брутфорсом
через терминальное соединение. Базы с клиентами "засланец" перепродавал другим
компаниям, а "интересная" информация о ведении бизнеса отправлялась сотрудникам
силовых структур. Что из этого вышло, объяснять излишне.

Вообще, имея физический доступ к локальной сети, инсайдер мог поступить
гораздо проще: атаковать программу, которая работает с базой данных. Нередко
сценарий взлома сводится к тому, что из программы разными способами извлекаются
конфиги для подключения к базе. Захватив ту же 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. К сожалению, на практике никакой защиты применение стандартных
средств шифрования не обеспечивает! Алгоритм, используемый при шифровании
определений объектов, выглядит так:

  1. SQL Server берет GUID той базы данных, в которой создается объект, и
    значение столбца colid таблицы syscomments для создаваемого объекта (чаще
    всего, его значение – 1 или 2) и производит их конкатенацию;
  2. Из полученного значения генерируется ключ при помощи алгоритма SHA;
  3. Этот хеш используется в качестве входящего значения при применении еще
    одного алгоритма хеширования – RSA. С его помощью генерируется набор символов,
    равный по длине шифруемому определению объекта;
  4. С этим набором символов и с реальным определением объекта производится
    операция XOR. В результате получаются данные, которые помещаются в столбец
    ctext таблицы syscomments.

У этой схемы есть два слабых места:

  • Нам ничего не мешает заиметь исходные значения (GUID и colid) для
    выполнения тех же самых операций и получить ключ на расшифровку. Это можно
    сделать, например, использовав утилиту dSQLSRVD. Правда, для получения GUID
    базы данных (и для запуска этой утилиты) нам нужны права системного
    администратора;
  • Если у нас есть права на создание объектов в базе данных, можно
    сгенерировать точно такой же ключ для объекта, определение которого нам уже
    известно (путем сравнения шифрованного определения с незашифрованным). Ну и –
    использовать его для расшифровки значения другого объекта.

Как можно расшифровать зашифрованные объекты на SQL Server? Есть два
варианта:

  • Использовать утилиту dSQLSRVD. Она позволяет выбрать любой зашифрованный
    объект на сервере и записать его определение в текстовый файл;
  • Использовать хранимую процедуру DECRYPT2K. Код на создание данных хранимых
    процедур (в разных вариантах и с разными объяснениями), которые расшифровывают
    определение зашифрованных объектов, легко найти через Google.

Базит Фарук

Сообщения о потерях и несанкционированном доступе к конфиденциальным данным появляются все чаще, а значит безопасность баз данных - весьма актуальная проблема для многих компаний. Организации, в чьих базах данных хранится конфиденциальная информация, должны соблюдать требования многочисленных законодательных актов, в том числе Грэмма-Лича-Блайли (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

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

Чтобы зашифровать или дешифровать базу данных, необходимо быть либо владельцем базы данных, либо, если база данных защищена, членом группы «Admins» с разрешением «монопольный доступ». Перед шифрованием базы данных рекомендуется сохранить ее с другим именем либо на другом диске или папке. В процессе шифрования Microsoft Access не заменяет исходную базу данных до успешного завершения шифрования. Необходимо иметь на диске достаточно места для исходной и зашифрованной версии базы данных.

    Запустите Microsoft Access без открытия базы данных. При работе с сетевой (общей) базой данных убедитесь, что все пользователи закрыли базу данных.

Важно! Нельзя зашифровать или дешифровать открытую базу данных.

    В меню Сервис выберите командуЗащита и подкомандуШифровать/дешифровать .

    Укажите имя базы данных, которую требуется зашифровать или дешифровать, и нажмите кнопку OK .

    Укажите имя, диск и папку для конечной базы данных и нажмите кнопку OK .

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

Создание, присоединение и исправление файлов рабочих групп

В файле рабочей группы Microsoft Access хранятся сведения о членах рабочей группы, включая пароли пользователей. При открытии базы данных этот файл читается для определения пользователей, которым разрешен доступ к объектам базы данных, и разрешений, полученных пользователями на эти объекты.

Создание и присоединение файла рабочей группы

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

    Запустите Microsoft Access.

    В меню Сервис выберите командуЗащита , а затем командуАдминистратор рабочих групп .

    В диалоговом окне Администратор рабочих групп нажмите кнопкуСоздать .

    В диалоговом окне Сведения о владельце рабочей группы введите свое имя, название организации и любое сочетание букв и цифр длиной до 20 знаков в качестве кода рабочей группы (WID).

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

    Нажмите кнопку OK .

Новый файл рабочей группы будет использоваться при следующем запуске Microsoft Access. Любые создаваемые учетные записи пользователей и учетные записи групп, а также их пароли, сохраняются в новом файле рабочей группы. Чтобы присоединить к рабочей группе, определенной новым файлом рабочей группы, других пользователей, скопируйте этот файл в общую папку (если он не был сохранен на шаге 5 в общей папке); после этого каждый пользователь должен будет запустить «Администратор рабочих групп» и присоединиться к новому файлу рабочей группы.