Шифруємо свої ресурси даних, Криптографія, Security & Hack, статті

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


Джон, головний адміністратор бази даних банку 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>

*

*