Рівень С2 системи безпеки

Організації, яким потрібен надійний захист бази даних, можуть розробити і впровадити систему безпеки рівня С2

Критерії оцінки безпеки Міністерства оборони США для компютерних систем і баз даних варіюються від рівня А (використовується дуже рідко), що позначає перевірену конструкцію, до рівня D, що позначає мінімальний захист Рівень безпеки С2 позначає захист управління доступом Вона необхідна для багатьох класифікованих даних, даних інформаційно-пошукових систем і більшості урядових контрактів

По суті, рівень захисту С2 вимагає наявності кількох умов

■ Унікальний ідентифікатор реєстрації для кожного користувача, захищений від перехоплення Для надання доступу до базі даних користувач повинен зареєструватися

■ Метод аудиту всіх спроб кожного користувача або процесу доступу до даних і їх зміни

■ Відсутність прав доступу за замовчуванням до всіх обєктів

■ Надання доступу до обєктів виключно їх власнику або під його відповідальність

■ Відповідальність всіх користувачів за свій доступ до даних і їх зміну

■ Захист даних в памяті від несанкціонованого доступу

Для сертифікації SQL Server корпорація Science Applications International Corporation (Сан-Дієго) виконала тестування для Агентства національної безпеки США та Національного інституту стандартів і технологій, які залучені в урядову програму сертифікації безпеки Процес тестування тривав 14 місяців і фінансувався компанією Microsoft

Публікацію SQL 2005 С2 Admin and Users Guide можна завантажити з сайту http:/ / msdn microsoftcom/library/en-us/secauthz/security/c2_level_securityasp

Реалізація системи безпеки рівня С2 в SQL Server вимагає наступного

■ СУБД SQL Server повинна бути запущена в операційній системі Windows NT 4 Service Pack 6a

■ He допускаються реплікації злиття, реплікації знімків бази даних, федеративні і розподілені бази даних

■ За допомогою утиліти SQL Profiler повинен здійснюватися повний аудит

■ Параметр безпеки С2 повинен бути включений – це призводить до останову SQL Server, якщо файл аудиту не функціонує

■ Існують інші обмеження на розміщення і розміри файлу аудиту

Подання та безпека

Популярний, але дуже спірний метод реалізації системи безпеки заснований на використанні уявлень, які проектують тільки певні стовпці або обмежують рядка за допомогою пропозиції WHERE і параметра WITH CHECK OPTION, та видачу дозволів тільки на ці подання Цей метод відкриває користувачам тільки обмежений доступ до даних Деякі компютерні рішення навіть вимагають організації всього доступу користувачів тільки за допомогою уявлень використання цієї ж методики припускають тести сертифікації фахівців Microsoft

Додаткова Про те, як створювати уявлення і використовувати параметр with check інформація OPTION, см в розділі 14

Опоненти використання уявлень як засіб захисту використовують такі аргументи

■ Уявлення не відкомпільовані і не оптимізовані

■ Захист на рівні стовпців можна забезпечити і стандартними засобами захисту SQL Server

■ Використання подань для забезпечення безпеки на рівні рядків припускає, що параметр WITH CHECK OPTION має бути створений в кожній виставі вручну У міру збільшення категорій рівня рядків система зажадає ручного налаштування

Криптографія

Зазвичай забезпечення захисту доступу на рівні таблиць достатньо якщо ж ні – можна понизити рівень захисту до рівня стовпців Водночас деяка конфіденційна інформація, така як номери кредитних карток і документи особливого відділу, вимагає додаткового захисту інформації, що реалізується за допомогою шифрування даних в базі

У той час як попередні версії SQL Server абсолютно не вирішували завдання Новинка шифрування даних (можливо, за винятком процесу транспортування

2005 даних клієнту), СУБД SQL Server 2005 краще оснащена для корпоративної

середовища, оскільки здатна шифрувати дані за допомогою ключів, паролів та сертифікатів Всі редакції SQL Server підтримують шифрування

Введення в криптографію

Шифрування даних являє собою їх перемішування з секретними ключами для отримання копії, званої шифрованими даними Не маючи ключа, ці дані практично неможливо розшифрувати

Симетричне шифрування використовує для шифрування і розшифровки даних одні і ті ж ключі Незважаючи на те що цей метод простіше в адмініструванні, як правило, він розцінюється як ризикований, оскільки в копіях ключа потребує безліч людей Це може і не бути проблемою, якщо шифрування та дешифрування даних виконуються в межах одного сервера баз даних

Асиметричне шифрування розглядається як більш суворе, оскільки один з ключів – приватний – створюється в парі з другим ключем – загальним Якщо дані зашифровані за допомогою одного ключа з цієї пари, їх можна розшифрувати за допомогою іншого ключа Наприклад, якщо я зашифрував дані за допомогою свого приватного ключа, ви можете їх дешифрувати за допомогою парного йому загального ключа Якщо виникає необхідність поділитися своїм загальним ключем з кількома партнерами і потрібно, щоб тільки вони могли дешифрувати дані, необхідно подвійне шифрування за допомогою двох пар приватного і загального ключів Наприклад, я шифруюч за допомогою свого приватного ключа, а потім за допомогою загального ключа партнера Мій партнер виконує все в зворотному порядку: він дешифрує дані за допомогою свого приватного ключа, а потім за допомогою мого спільного

гДані можуть бути також шифрувати та дешифрувати на середньому або клі-

Назаметку ентском рівні додатку NET Цей підхід має ту перевагу, що сервер баз даних ніколи не бачить незашифрованих даних Ми з Дарреном Шейфер використовували цей метод при реалізації проекту зберігання даних кредитних карток в SQL Server 2000 Даррен створив клас C # NET, вповні клас SystemSecurityCryptography, для використання криптографічного алгоритму Rinjdael Цей клас працював відмінно, і дані були зашифровані з моменту їх споконвічного введення до моменту перегляду автори-зірованним користувачем звіту

Шифрування за допомогою симетричного ключа дає на виході менший масив даних, ніж при використанні асиметричного ключа Один з методів вирішення цієї проблеми полягає в шифруванні даних за допомогою симетричного ключа, спеціально згенерованого для даного набору даних, і наступному шифруванні самого симетричного ключа за допомогою асиметричного

Сертифікати аналогічні ключам, але найчастіше випускаються спеціальними центрами сертифікації, такими як VeriSign, що гарантують легітимність організації, повязаної з сертифікатом У SQL Server можна згенерувати і локальний сертифікат

Криптографічний ієрархія SQL Server

Система шифрування в SQL Server заснована на ієрархії ключів На вершині цієї ієрархії знаходиться унікальний службовий майстер-кчюч, використовуваний в SQL Server для виконання шифрування майстер-ключів бази даних при їх створенні

На наступному рівні ієрарх ™ знаходиться майстер-ключ бази даних, що є симетричним ключем, використовуваним в SQL Server для шифрування приватних сертифікатів та асиметричних ключів Майстер-ключ бази даних створюється за допомогою інструкції DDL CREATE MASTER KEY Після цього створений ключ шифрується за допомогою службового мас-тер-юноча і зберігається як у користувача базі даних, так і в базі даних master

CREATE MASTER KEY

ENCRYPTION BY PASSWORD = P@$rwOrD;

Пароль ключа повинен задовольняти вимогам операційної системи Windows для суворого ключа

| Для перегляду інформації про майстер-ключах використовуються уявлення ка-

суо талоге syssymmetric_keys і sysdatabases is_master_key_encrypted_ I * by_server

У самій базі даних, нижче рівня її майстер-ключа, знаходяться сертифікати та приватні ключі

Коли необхідно виконати шифрування даних, SQL Server використовує чотири методи:

■ використання парафраз

■ використання симетричного ключа

■ використання асиметричного ключа

■ використання сертифіката

Шифрування парафразою

Перший метод шифрування даних припускає використання парафрази Парафрази аналогічні паролів, але на них не накладаються обмеження суворого пароля Шифровані дані мають двійковий вигляд, тому в коді прикладу для стовпця номера кредитної картки creditcardnumber використаний тип даних varbinary Необхідна довжина для зашифрованих даних визначається виходячи з конкретної ситуації

Реальне шифрування виконується за допомогою функції Encrypt by Pass Phrase Першим її параметром є парафразу, за якою слідують шіфруемие дані У наступному прикладі продемонстровано шифрування даних в інструкції INSERT:

CREATE TABLE CCard (

CCardID INT IDENTITY PRIMARY KEY NOT NULL,

CustomerID INT NOT NULL,

CreditCardNumber VARBINARY(12 8),

Expires CHAR(4)

)

INSERT CCard(CustomerlD, CreditCardNumber, Expires)

VALUES(1,EncryptbyPassPhrase(Passphrase,

‘ 123456789012345678 90) , 08081)

Зашифроване значення, збережене в базі даних, витягується за допомогою звичайної інструкції SELECT:

SELECT *

FROM CCard

WHERE CustomerlD = 1

Результат в даному прикладі буде отриманий наступний (двійкове значення обрізане): CCardID CustomerlD CreditCardNumber Expires

1 січня 0x010 ТОВ 0 0C8CF6 8C 0808

Для дешифрування даних кредитної картки в звичайний читається текст використовується функція decryptbypassphrase в парі з функцією convert, перетворюючої двійковий формат:

SELECT CCardID, CustomerlD,

CONVERT(VARCHAR(20), DecryptByPassPhrase(Passphrase, CreditCardNumber)),Expires FROM Ccard

WHERE CustomerlD = 1

Буде отримано наступний результат:

CCardID CustomerlD                                                       Expires

1&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp 1                           12345678901234567890 0808

Цілком очевидно, що дані дешифрируются таким же чином, яким раніше були зашифровані Якщо задана для розшифровки парафразу некоректна, в результаті буде отримано порожнє значення

Метод використання парафрази має одне розширення У процес шифрування може бути залучений аутентифікатор В якості аутентифікатора зазвичай використовують деякий вбудоване значення, невідоме користувачеві Це в ще більшій мірі ускладнює завдання дешифрування даних, якщо вони були витягнуті з бази

У наступному прикладі ми додамо аутентифікатор в шифрування з використанням парафрази Код 1 включає аутентифікатор, а останнім аргументом є фраза аутентифікатора:

INSERT CCard(CustomerlD, CreditCardNumber, Expires)

VALUES(3,EncryptbyPassPhrase(Passphrase,

‘12123434565678788989,1,

‘hardCoded Authenticator), 0808)

SELECT CCardID, CustomerlD,

CONVERT(VARCHAR(20),DecryptByPassPhrase(Passphrase, CreditCardNumber,1,

‘hardCoded Authenticator)), Expires FROM Ccard

WHERE CustomerlD = 3

Буде отримано наступний результат:

CCardID                                                        CustomerlD      Expires

2      3                    12123434565678788989 0808

Шифрування за допомогою симетричного ключа

Використання симетричного ключа припускає наявність реального обєкта, який використовується при шифруванні, а не придатною для читання парафрази Симетричні ключі створюються в SQL Server за допомогою наступної інструкції CREATE:

CREATE SYMMETRIC KEY CCardKey WITH ALGORITHM = TRIPLE_DES ENCRYPTION BY PASSWORD = P@s$wOrD;

Після того як ключі будуть створені, вони відобразяться у вузлі Security ^ Symmetric keys вікна Object Explorer утиліти Management Studio,

Для перегляду інформації про симетричних ключах використовується запит T-SQL до подання каталогу syssymmetric_keys

Ключі являють собою обєкти, так що їх можна змінити і видалити так само, як і будь-які інші обєкти SQL Server

Криптографічні алгоритми

Криптографічні алгоритми визначають, як саме дані будуть шифруватися за допомогою ключа Існує девять доступних для вибору алгоритмів: DES, TRIPLE_DES, RC2, RC4, RC4_128, DESX, AES_128, AES_192 і AES_256 Вони відрізняються швидкістю і суворістю

Алгоритм DES (Data Encryption Standard) був обраний в 1976 році офіційним криптографічним алгоритмом для уряду США, проте рідко використовувався, так як на компютерах того часу процес шифрування міг зайняти добу Алгоритм TRIPLE_DES використовує більш довгий і, отже, більш строгий ключ

Алгоритм AES (Advanced Encryption Standard), також відомий як Rijndael, введений Національним інститутом стандартів і технологій США в листопаді 2001 року Числа 128, 192 і 256 в імені алгоритму відображають розмір ключа в бітах Найбільш суворим алгоритмом цього сімейства є AES_256

SQL Server використовує криптографічні алгоритми Windows Так що якщо На замітку деякий алгоритм не встановлений в операційній системі, SQL Server не зможе його використовувати Алгоритми AES не підтримується в Windows ХР і Windows 2000

Оскільки симетричні ключі повинні передаватися клієнту у відкритому вигляді, сам ключ також може бути зашифрований SQL Server може шифрувати ключі, використовуючи один або безліч паролів, інші ключі або сертифікати Для поширення покоління ключів може бути задіяна ключова фраза

Тимчасовий ключ дійсний протягом поточної сесії, і, аналогічно тимчасовим таблицям, його можна ідентифікувати за знаком решітки (#) Тимчасові ключі можуть використовувати ідентифікатори GUID для ідентифікації зашифрованих даних, застосовуючи параметр indent ity_value = passphrase.

Використання симетричних ключів

Для використання симетричного ключа його потрібно спочатку відкрити за допомогою команди OPEN, яка дешифрує ключ і робить його доступним для SQL Server:

OPEN SYMMETRIC KEY CCardKey

DECRYPTION BY PASSWORD = P@s$wOrD;

Використовуючи раніше таблицю CCard, в наступному фрагменті коду дані шифруються за допомогою ключа CCardKey Функція encryptbykey приймає ідентифікатор GUID ключа, який знаходиться за допомогою функції key_guid (), а також дані, що підлягають шифруванню:

INSERT CCard(CustomerlD, CreditCardNumber, Expires)

VALUES(1,EncryptbyKey(Key_GUID(CCardKey),

‘ 11112222333 344445555) , 0808 )

Для дешифрування даних ключ повинен бути відкритий Функція decryptbykey ідентифікує коректний ключ з даних, а потім виконує дешифрування:

SELECT CCardID, CustomerlD,

CONVERT(varchar(2 0), DecryptbyKey(CreditCardNumber)) as CreditCardNumber, Expires FROM Ccard

WHERE CustomerlD = 7

Буде отримано наступний результат:

CCardID                                                                                                       CustomerlD CreditCardNumber Expires

1           7                           11112222333344445555                                   0808

На практиці рекомендується закривати відкритий ключ відразу ж після транзакції, в якій він використовувався:

CLOSE SYMMETRIC KEY CCardKey

У більшості додатків вам доведеться шифрувати дані по мірі їх надходження в базу і дешифрувати по мірі їх вилучення Якщо ви хочете перемістити дані на інший сервер і дешифрувати їх там, то обидва сервера повинні мати ідентичні ключі Для генерації одного і того ж ключа на двох серверах вони повинні створюватися з використанням одного алгоритму, значення ідентичності та ключової фрази

Використання асиметричних ключів

Використання асиметричного ключа припускає виконання шифрування і дешифрування за допомогою пари відповідних один одному приватного і загального ключів Генерація асиметричного ключа схожа з генерацією симетричного:

CREATE ASYMMETRIC KEY AsyKey WITH ALGORITHM = RSA_512 ENCRYPTION BY PASSWORD = P@s$w0rD;

SQL Server підтримує такі асиметричні алгоритми: RSA_512, RSA_1024 і RSA_2048 Вони розрізняються довжиною приватного ключа

Асиметричні ключі також можуть бути згенеровані з існуючих файлів ключів: CREATE ASYMMETRIC KEY AsyKey

FROM FILE = C:\SQLServerBIble\AsyKeykey1 ENCRYPTION BY PASSWORD = P@s$w0rD;

Шифрування і дешифрування даних за допомогою асиметричного ключа подібні з використанням симетричного ключа, за винятком того, що асиметричний ключ не потрібно відкривати

Використання сертифікатів

Сертифікати зазвичай використовуються для шифрування даних, переданих по Інтернету між ключовими точками HTTPS SQL Server містить сертифікати для своєї рідної служби HTTP Web Services Сертифікати отримують від спеціалізованих центрів сертифікації

Додаткова Про використання сертифікатів з кінцевими точками HTTP см в розділі 32

інформація

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*