Шифруємо свої ресурси даних

Створення гнучкої інфраструктури для захисту конфіденційних даних


Джон, головний адміністратор бази даних банку Acme Bank, залучений в дуже важливу ініціативу, пов'язану з безпекою і конфіденційністю. Джейн, начальник служби інформаційної безпеки банку, описала стратегію безпеки банку, і Джон визначив обов'язки своєї групи.

Джейн на нараді з ІТ-менеджерами банку Acme пояснила, що безпека компанії можна розглядати як ряд рівнів (шарів) захисту. Для ілюстрації цього Джейн використовує "матрьошку" – комплект ляльок, вкладаються одна в іншу. Остання з чотирьох або п'яти цих ляльок містить у собі щось на зразок призу. Щоб отримати приз потрібно один за іншим видаляти "шари" ляльок, і якщо з якихось причин шари не можуть бути вилучені, дістатися до призу буде важче. Джейн пояснює, що зловмисник, щоб дістатися до корпоративних інформаційних ресурсів, повинен також "перемогти" багато рівнів захисту.

Перша смуга оборони – міжмережевий екран (МЕ), що захищає всю інформаційну інфраструктуру організації; він перешкоджає стороннім отримувати доступ до будь-якого з інформаційних джерел у компанії. Однак ніяка організація не є островом і МЕ зовсім не повітронепроникні – необхідні "отвори" або порти, щоб із зовнішнього світу міг надходити законний трафік.

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

Джейн підкреслює, що зловмисник може так чи інакше перемогти всі захисні заходи і дістатися до даних підприємства. З точки зору планування ця можливість повинна бути допущена, проаналізовано і усунена. Єдиний варіант, що залишився на цій стадії для захисту від зловмисника, – останній рівень захисту, на якому дані змінюються так, щоб вони не здавалися зловмисникові корисними. Це робиться за допомогою процесу, званого шифруванням (encryption). Шифрування змінює дані так, щоб зробити їх нерозбірливими для всіх, крім тих, хто знає, як розшифрувати цю інформацію.

Шифрування бази даних


Після наради ІТ-менеджерів Джон негайно збирає своїх безпосередніх підлеглих для обговорення стратегії шифрування та її реалізації в своїй групі.

Він виклав свою точку зору на стратегію шифрування, почавши з короткого огляду процесу шифрування. Він уявляє свого групі простий приклад, в якому величина залишку на рахунку змінена доповненням секретного числа з однією цифрою. Якщо секретне число буде дорівнює, для прикладу, 2, а величина залишку на с рахунку – 3467, то зашифрована величина буде дорівнює 3469. Реальна величина може бути розшифрована вирахуванням числа 2 з зашифрованою величини, Джон пояснив, що цей процес називається дешифрованием (decryption). Таку логіку додавання певної кількості до реальних даних називають алгоритмом шифрування (encryption algorithm). Число 2, яке додається алгоритмом, називається ключем шифрування (encryption key). Вихідні дані (original data) і ключ шифрування обробляються алгоритмом шифрування для створення зашифрованих даних (encrypted data), як показано рис.1.

Рис 1. Механізм шифрування

При дешифрування для отримання вихідних даних логіка зміняться на зворотну. Ця схема також називається симетричним шифруванням (symmetric encryption), Оскільки один і той же ключ використовується для шифрування і дешифрування.

Алгоритми шифрування найчастіше загальнодоступні; отже, безпека забезпечується вибором важко вгадується ключа. Якби хакери в цьому прикладі повинні були вгадати 1-цифровий ключ, вони повинні були б перебрати тільки 10 чисел – цифри від 0 до 9. Однак, якби ключ складався з двох цифр, то вони повинні були б перебрати 100 чисел – від 0 до 99. Джон пояснює, чим довше ключ, тим більше важко вгадати його.

Пакети, що поставляються з СУБД Oracle


Джон продовжує: в сервері Oracle Database 10g користувачі можуть реалізовувати свої методи шифрування, використовуючи функції і процедури, які доступні у вбудованому пакеті DBMS_CRYPTO. У сервері Oracle Database 10g і більш ранніх версіях також доступний інший пакет, DBMS_OBFUSCATION_TOOLKIT, в якому пропонується підмножина функціональних можливостей пакета DBMS_CRYPTO. У банку Acme системи працюють в середовищі Oracle Database 10g, а в більш новому пакеті DBMS_CRYPTO пропонуються додаткові функціональні можливості, крім того, корпорація Oracle рекомендує використовувати саме його, тому Джон прийняв рішення використовувати цей пакет, і вся аудиторія з ним погодилася.

Генерація ключів. Оскільки безпеку зашифрованих даних залежить від труднощі вгадування ключа, вибір належного ключа – найголовніший крок в процесі шифрування. Ключ може бути будь-яким значенням даних типу RAW, але якщо вона вибрана не досить випадково, зловмисник буде в змозі вгадати ключ. Джон попереджає, ключ не може бути, наприклад, ім'ям вашого домашньої тварини або вашої датою народження; це повинно бути дійсно випадкове число. Один молодший адміністратор бази даних запитує: "Як ви сгенеріруете такий випадковий ключ"? Джон відповідає, що випадкові числа можуть генеруватися за допомогою вбудованого пакету DBMS_RANDOM, але криптографічно стійка генерація випадкових чисел досягається використанням функції RANDOMBYTES в пакеті DBMS_CRYPTO. Функція має один вхідний параметр (типу даних BINARY_INTEGER, на виході видається число типу даних RAW, довжина якого визначена вхідним параметром. Це число може використовуватися як ключ. Джон демонструє це на прикладі простого PL / SQL-коду, показаного на лістингу 1.

Лістинг 1. Шифрування даних





















































1 declare
2

enc_val raw (2000);

3

l_key raw (2000);

4

l_key_len number := 128;

5

l_mod number := dbms_crypto.ENCRYPT_AES128

6

+ dbms_crypto.CHAIN_CBC

7

+ dbms_crypto.PAD_PKCS5;

8 begin
9

l_key := dbms_crypto.randombytes (l_key_len);

10

enc_val := dbms_crypto.encrypt

11

(

12

UTL_I18N.STRING_TO_RAW (“SECRET”, “AL32UTF8”),

13

l_mod,

14

l_key

15

);

16

– Тут можна використовувати зашифровані дані enc_val

17 end;

Пояснюючи цей код, Джон звернув увагу, що для проекту шифрування в банку Acme в пакеті DBMS_CRYPTO підходить декілька типів алгоритмів і відповідних довжин ключів (див. табл. 1).

Таблиця 1. Константи для алгоритмів пакету DBMS_CRYPTO

Перший стовпець у табл. 1 – Constant Name (ім'я константи) – показує константи, визначені в пакеті для вказівки різних алгоритмів і довжин ключів (Effective Key Length). Наприклад, для вказівки 128-бітового ключа, що відповідає стандарту Advanced Encryption Standard (AES, вдосконалений стандарт шифрування), пояснює Джон, ви використовуєте константу DBMS_CRYPTO.ENCRYPT_AES128 (див. рядок 5 лістингу 1). Чим довший ключ, тим менше шансів у зловмисника для його вгадування, але більше роботи у сервера для шифрування і дешифрування. Для встановлення співвідношення між безпекою і навантаженням на сервер Джон вибирає середній варіант – 128-бітовий ключ та алгоритм AES.

Потім визначається тип зчеплення, яке при блочному шифруванні дозволяє розбивати дані на дільниці для шифрування, як це показано у рядку 6 лістингу 1. Найпоширеніший формат – Cipher Block Chaining (CBC, зчеплення блоків шіфротекста), вказується в пакеті DBMS_CRYPTO константою CHAIN_CBC. Інші варіанти зчеплення: Electronic Code Book (CHAIN_ECB, електронна книга кодів), Cipher Feedback (CHAIN_CFB, шифрування зі зворотним зв'язком від шіфротекста) і Output Feedback (CHAIN_OFB, шифрування зі зворотним зв'язком по виходу).

Нарешті, пояснює Джон, при блочному шифруванні дані зазвичай шифруються в блоках по вісім символів. Якщо довжина вхідних даних не кратна восьми, додається відсутній символ або символи; цей процес називається доповненням (padding). Найпростіший варіант – доповнення нулями. Джон вказує, що цей варіант включається константою PAD_ZERO, визначеної в пакеті DBMS_CRYPTO, але він не вважається досить безпечним, оскільки потенційний зловмисник може вгадати його. Більш безпечне додаток засновано на стандарті Public-Key Cryptography Standard # 5 (PKCS # 5, криптографічний стандарт із загальним ключем), що задається в пакеті DBMS_CRYPTO константою PKCS5, як це показано у рядку 7 лістингу 1. Якщо ви впевнені, коментує Джон, що довжина даних вже кратна розміру блоків, то доповнення не буде потрібно, і ви можете вказати це за допомогою константи PAD_NONE.

Всі ці три параметри – алгоритм з довжиною ключа, методи зчеплення і доповнення – об'єднуються в один параметр, який передається у вбудовану функцію шифрування ENCRYPT пакету DBMS_CRYPTO. Функції ENCRYPT потрібно, щоб незашифровані дані мали тип RAW. Це перетворення робиться в рядку 12 лістингу 1.

З метою стандартизації, продовжує Джон, банк Acme прийняв рішення у всіх додатках використовувати алгоритм AES з 128-бітовими ключами, зчеплення CBC та доповнення PCKS # 5. Використовуючи ці значення, Джон створює найпростішу функцію GET_ENC_VAL, показану на лістингу 2, яка приймає тільки два параметри – вихідні незашифровані дані і ключ – і повертає зашифровані дані.

Лістинг 2. Проста функція шифрування






























































1 create or replace function get_enc_val
2 (
3

p_in in varchar2,

4

p_key in raw

5 )
6 return raw is
7

l_enc_val raw (2000);

8

l_mod number := dbms_crypto.ENCRYPT_AES128

9

+ dbms_crypto.CHAIN_CBC

10

+ dbms_crypto.PAD_PKCS5;

11 begin
12

l_enc_val := dbms_crypto.encrypt

13

(

14

UTL_I18N.STRING_TO_RAW

15

(p_in, “AL32UTF8”),

16

l_mod,

17

p_key

18

);

19

return l_enc_val;

20* end;

Дешифрування


Джилл, одна з розробників Джона, запитала: "Коли потрібно розшифровувати зашифровані дані і як ми будемо це робити"?

Джон пояснює, що в пакеті DBMS_CRYPTO є функція дешифрування DECRYPT. Вона приймає для дешифрування вихідні зашифровані дані; ключ, використаний під час шифрування; а також об'єднаний параметр: алгоритм, довжина ключа і схеми зчеплення і доповнення. Разом з даними, які потрібно дешифрувати, необхідно передавати ті ж самі ключ і модифікатори, використані під час шифрування. Банк Acme використовує стандартні (однакові) алгоритм, довжину ключа і схеми зчеплення і доповнення, тому Джон створив просту функцію для дешифрування зашифрованих даних, показану на лістингу 3. Ця функція приймає тільки два параметри – зашифровані дані і ключ – і повертає розшифровані дані типу VARCHAR2 (перетворення даних типу RAW робиться в рядку 20 лістингу 3).

Лістинг 3. Проста функція дешифрування







































































1 create or replace function get_dec_val
2 (
3

p_in in raw,

4

p_key in raw

5 )
6 return varchar2
7 is
8

l_ret varchar2 (2000);

9

l_dec_val raw (2000);

10

l_mod number := dbms_crypto.ENCRYPT_AES128

11

+ dbms_crypto.CHAIN_CBC

12

+ dbms_crypto.PAD_PKCS5;

13 begin
14

l_dec_val := dbms_crypto.decrypt

15

(

16

p_in,

17

l_mod,

18

p_key

19

);

20

l_ret:= UTL_I18N.RAW_TO_CHAR

21

l_dec_val, “AL32UTF8”);

22

return l_ret;

23* end;

Управління ключами


Займаючись блоковим шифруванням, група Джона шукає і повне рішення для шифрування інформації на основі пакету DBMS_CRYPTO. Найбільшою проблемою в шифруванні, пояснює Джон, є не генерація ключів або використання функцій, а управління ключами, які у процесі шифрування. Одні й ті ж ключі використовуються для шифрування і дешифрування даних, тому їх потрібно надійно охороняти, щоб захистити дані. У той же самий час, проте, додатки і користувачі повинні мати доступ до ключів, щоб дешифрувати дані для нормального використання. Ця проблема вирішується, пояснює Джон, вибором місця зберігання ключів та забезпеченням гарантій, що вони будуть доступні лише законним користувачам. Він надає два варіанти управління ключами:


  1. Використання одного і того ж ключа для всіх записів.
  2. Використання різних ключів для різних записів.

У варіанті 1, продовжує Джон, для шифрування даних у всіх рядках використовується один ключ. У цьому випадку для збереження ключа існує кілька варіантів:


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

Найбільший недолік цього підходу – уразливість ключа до крадіжок. Якщо ключ вкрадений, всі дані в базі даних поставлені під загрозу. Тому Джон запропонував інший підхід для захисту конфіденційних даних у базах даних OLTP-систем. Така база даних має таблицю ACCOUNT_MASTER, в якій зберігається конфіденційний елемент даних – ім'я власника банківського рахунку (account holder). Стовпець, який містить це ім'я, ACC_NAME, повинен бути зашифрований. Первинний ключ цієї таблиці – ACCOUNT_NO. Таблиця ACCOUNT_MASTER виглядає приблизно так:


























SQL> desc account_master
Name Null? Type
——— ——— ———–
ACCOUNT_NO NOT NULL NUMBER
ACC_NAME VARCHAR2(200)
ACC_TYPE CHAR(1)

Джон пропонує використовувати різні ключі для різних рядків таблиці ACCOUNT_MASTER, що усуває ризик незахищеності даних на рівні всієї бази даних, якщо ключ крадеться. Він створює таблицю ACCOUNT_MASTER_ENC для зберігання зашифрованих даних (імена власників рахунків) та іншу таблицю для зберігання ключів, використаних для шифрування. Ці таблиці – ACCOUNT_MASTER_ENC і ACCOUNT_MASTER_KEYS – виглядають приблизно так:












































SQL> desc account_master_enc
Name Null? Type
——— ——— ———–
ACCOUNT_NO NOT NULL NUMBER
ACC_NAME_ENC RAW(2000)
SQL> desc account_master_keys
Name Null? Type
——— ——— ———–
ACCOUNT_NO NOT NULL NUMBER
KEY NOT NULL RAW(2000)

Потім Джон створює уявлення VW_ACCOUNT_MASTER, показане на лістингу 4, щоб з'єднати ці три таблиці для отримання розшифрованих даних. Він вказує на рядок 8 лістингу 4, в якій дані розшифровуються за допомогою функції GET_DEC_VAL, розглянутої вище. Ця функція повертає дані типу VARCHAR2, тому вони демонструються як стовпець VARCHAR2 (2000); функція CAST у рядку 7 перетворює їх в дані типу VARCHAR2(20).

Це подання, не таблиця, як раз є те, що надається для доступу іншим користувачам. Джон створює публічний синонім ACCOUNT_MASTER, який вказує на подання VW_ACCCOUNT_MASTER, а не на таблицю з таким же ім'ям як у синоніма.

Лістинг 4. Представлення VW_ACCOUNT_MASTER


















































1 create or replace view
2

vw_account_master

3 as
4 select
5

m.account_no as account_no,

6

m.acc_type as acc_type,

7

cast (

8

get_dec_val (e.acc_name_enc, k.key)

9

as varchar2(20)) as acc_name

10 from
11

account_master m,

12

account_master_enc e,

13

account_master_keys k

14 where
15

k.account_no = e.account_no

16*

and m.account_no = e.account_no;


Публічний синонім ACCOUNT_MASTER вказує на це подання, тому користувачі можуть отримувати з нього дані. Але, запитує розробник Джилл, як же користувачі зможуть маніпулювати даними у таблиці ACCOUNT_MASTER? Використовуючи тригер INSTEAD OF (див. лістинг 5), пояснює Джон. Цей тригер модифікує реальні таблиці, коли користувачі вставляють рядка до подання або оновлюють його.

Лістинг 5. Тригер INSTEAD OF для представлення


















































































































































1 create or replace trigger io_vw_acc_master
2 instead of insert or update on
3 vw_account_master
4 for each row
5 declare
6

l_key raw(2000);

7 begin
8

if (inserting) then

9

l_key := dbms_crypto.randombytes (128);

10

insert into account_master

11

(account_no, acc_type, acc_name)

12

values

13

(

14

:new.account_no,

15

:new.acc_type,

16

:new.acc_name

17

);

18

insert into account_master_enc

19

(account_no, acc_name_enc)

20

values

21

(

22

:new.account_no,

23

get_enc_val (

24

:new.acc_name,

25

l_key )

26

);

27

insert into account_master_keys

28

(account_no, key)

29

values

30

(

31

:new.account_no,

32

l_key

33

);

34

else

35

select key

36

into l_key

37

from account_master_keys

38

where account_no = :new.account_no;

39

update account_master

40

set acc_name = :new.acc_name,

41

acc_type = :new.acc_type

42

where account_no = :new.account_no;

43

update account_master_enc

44

set acc_name_enc =

45

get_enc_val (:new.acc_name, l_key)

46

where account_no = :new.account_no;

47

end if;

48* end;

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

Додаткові заходи


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

Після завершення обговорення Джон негайно посилає Джейн електронний лист, сповіщаючи її, що план шифрування готовий, і пропонує продемонструвати його у зручний для неї час.

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


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

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

Ваш отзыв

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

*

*