Гаманець Oracle Wallet: використання для шифрування даних на зовнішньому носії, Інші СУБД, Бази даних, статті



















Тримай кишеню ширше! Крилатий вислів


Введення


БД Oracle не є замкнутою системою. СУБД вступає в контакт з учасниками комп’ютерної мережі, а дані бази, так само як і резервні копії, технічно зберігаються на зовнішніх носіях. Хоча СУБД Oracle має власну систему захисту даних, зовнішнє оточення, з яким вона взаємодіє, зовсім не підконтрольне їй. Наприклад, канал зв’язку прикладної програми з СУБД може випробувати стороннє втручання; існує ризик стороннього ж звернення до вмісту файлів з даними в обхід Oracle.


Проблема не пов’язана виключно з Oracle і носить загальний характер для інформаційних систем як таких. Стандартне рішення полягає у використанні шифрування переданих даних і підрахунку контрольної згортки (суми). Більш того, передача шифру (необхідного для розшифровки приймаючою стороною) часто вдобавок змушене супроводжується посиланням на “свідоцтво автентичності”, так званий сертифікат. Коли взаємодія суб’єктів і об’єктів доступу в інформаційній системі йде активно, пред’являти в програмі шифр або його свідчення справжності багаторазово і “вручну” і незручно, і небезпечно. Набагато легше запам’ятати ці відомості десь один раз і “попросити” систему робити перевірку у міру потреби самостійно.


Популярним прийомом є використовувати для такого локалізованого розташування даних параметрів захищеного доступу “електронний гаманець” (ewallet). По суті це файл на комп’ютері (сервері або клієнті), де інформація про параметри доступу сама в свою чергу захищена. Англійським прообразом для “засвідчують параметрів доступу” є слово credentials, запозичене з юридичної мови і позначає там “вірчі грамоти”. (Слово credentials повинно бути знайоме адміністраторам роботі з Oracle Enterprise Manager). В “інформаційному”, електронному гаманці можуть зберігатися такі персональні “вірчі грамоти “, як ключі шифрування даних і сертифікати справжності, а крім того ще й” інші секретні відомості “(цитата) про учасника доступу.


Фірма Oracle передбачає використовувати в якості електронного гаманця власне рішення, Oracle Wallet, що існує в рамках розширення Advanced Security для Oracle Enterprise Edition або для клієнта. Oracle Wallet дозволяє зберігати і забезпечувати використання системою наступні основні категорії відомостей:



У цій статті буде розказано про застосування електронного гаманця Oracle в першому якості, а в подальшій – у другому. Використання гаманця для упроценія процедури з’єднання клієнтом розглядатися не буде.


У прикладах нижче мається на увазі файлова система ОС Windows, що ніяк не позначається на суть справи.


Електронний гаманець Oracle


Гаманець Oracle Wallet являє собою двійковий файл, складений з промислового стандарту PKCS # 12 “синтаксису обміну персональною інформацією” ( www.rsa.com/rsalabs/node.asp?id=2138 ), Що забезпечує йому сумісність з третіх фірм. Файл має ім’я ewallet. P 12, і він повинен розташовуватися в будь-якому доступному СУБД каталозі файлової системи. Тим не менш, коли гаманець використовується для зберігання головного ключа шифрування (про що мова в цій статті), є умолчательной місцезнаходження (не вимагає явної вказівки): по системі позначень Windows це% ORACLE _BASE% admin \% ORACLE _SID% Wallet. (Воно розумно прив’язане до місця зберігання робочих файлів СУБД, так як кілька СУБД на одному комп’ютері не мають права користуватися загальним гаманцем).


Сам гаманець Oracle з’явився у версії 8.1, проте приводиться далі його застосування виявилося можливим тільки у версії 10.2.


Для роботи зі своїм електронним гаманцем фірма Oracle дає наступні засоби:


– Команди SQL;


– Програму mkwallet;


– Програму Oracle Wallet Manager (вона ж owm);


– Програму orapki;


– Програму mkstore.


Три останні суть звернення до методів main класів Java, відповідно:


–          oracle.security.admin.wltmgr.owma.OwmaApp,


–          oracle.security.pki.textui.OraclePKITextUI,


–          oracle.security.pki.OracleSecretStoreTextUI.


(Усі вони, разом з адресованими по ланцюжку, розташовуються в каталогах ПО Oracle в різних архівах ORACLE_HOME).


Два останні класу дозволяють працювати з електронним гаманцем Oracle за допомогою командного рядка, а перший – за допомогою графіки; він і призначений бути основним інструментом для користувача. Описи API, що дозволяє користувачеві працювати з гаманцем зі своєї програми, фірма Oracle не дає. Програма mkwallet виконує все, на що здатна програма owm, але технікою командного рядка.


Створення, відкриття і закриття гаманця з головним ключем


Створити гаманець з головним ключем шифрування можна неявно командою ALTER SYSTEM SET ENCRYPTION WALLET … або явно програмами Oracle Wallet Manager і mkstore. Зверніть увагу, що головний ключ (симетричний) буде застосовуватися СУБД для шифрування даних при розміщенні на диску і розшифровці при взятті з диска, тому подальша робота передбачається на сервері, з серверним ПЗ.


На жаль, для електронного гаманця в Oracle ПО написано недостатньо ретельно, так що недотримання описаного далі порядку дій здатне привести до помилки ORA-00600 і необхідності перезавантаження СУБД.


Простіше завести гаманець неявно, командою SQL. Для цього потрібно створити необхідний умолчательной каталог і видати команду SQL від імені SYS, наприклад в SQL * Plus:


SQL> HOST mkdir C:oracleadminorclwallet


SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY “amicus123”;


Наведений пароль буде служити для подальшого відкриття гаманця і взагалі доступу до його вмісту. Подвійні лапки невипадкові, оскільки в паролі розрізняються великі та малі літери. Крім того пароль повинен містити більше 8 символів і складатися одночасно з букв і цифр. Для зміни пароля в майбутньому треба буде використовувати програму Oracle Wallet Manager, звернутися до якої в Windows можна через меню запуску програм або з командного рядка ОС, а в Unix – набором owm в командному рядку ОС.


За зазначеною команді SQL в (умолчательной) каталозі з’явиться файл гаманця з головним ключем доступу. До фактичним використанням головного ключа з гаманця ми ще не готові, так як гаманець потрібно відкрити. Команди відкриття і закриття гаманця:


ALTER SYSTEM SET ENCRYPTION WALLET OPEN AUTHENTICATED BY “amicus123”;


ALTER SYSTEM SET ENCRYPTION WALLET CLOSE;


Виконаємо першу команду, і створений попередньо гаманець можна використовувати.


Захист даних на зовнішньому носії засобами TDE


Термін “прозоре шифрування даних” (TDE) використовується для позначення процесів автоматичної шифровки даних при розміщенні на носій і дешифрування при читанні з носія. “Прозоре” тут означає “Прозоре” для прикладної програми, в якій жодним чином немає потреби враховувати фактичне виконання зазначених дій. На противагу цьому програма має право самостійно шифрувати потрібні значення перш ніж передавати їх БД і самостійно розшифровувати по витяганню, користуючись, наприклад, пакетом DBMS_CRYPTO. Обидва підходи мають свої переваги, при цьому TDE простіше для програміста, але і вимагає гаманця.


Техніка TDE не притаманна виключно СУБД Oracle (приклад: SQL Server), або навіть баз даних взагалі (приклад: патент IBM 7426745 ).


Створення стовпців з зашифрованими даними


Створимо таблицю для роботи, для визначеності в схемі SCOTT:


 CREATE TABLE closed (


  a VARCHAR2 ( 10 )


, b VARCHAR2 ( 10 )


, c VARCHAR2 ( 10 )


);


INSERT INTO closed VALUES ( “normal1”, “secret“, “normal1” );


INSERT INTO closed VALUES ( “normal2”, “secret“, “normal2” );


COMMIT;


Для початку розглянемо звичайне зберігання рядків. Видамо в SQL * Plus:


SQL> SELECT


  2    DBMS_ROWID.ROWID_RELATIVE_FNO ( ROWID ) file#


  3  , DBMS_ROWID.ROWID_BLOCK_NUMBER ( ROWID ) block#


  4  FROM closed


SQL> ;


      FILE#     BLOCK#


———- ———-


         4        597


         4        597


Обидві короткі рядки потрапили в один блок на диску. У моєму випадку це блок № 597 у файлі № 4. Підставимо отримані значення в команду, яку видамо від імені SYS:


ALTER SYSTEM DUMP DATAFILE 4 BLOCK 597;


У файлі трасування серверного процесу, обслуговуючого сеанс, з’явилася приблизно наступна інформація:



EEF7DB0 32656662 5F353633 72756F53 6F546563  [bfe2365_SourceTo]


EEF7DC0 4C4D5448 766E6F43 0703012C 6D726F6E  [HTMLConv,…norm]


EEF7DD0 06326C61 72636573 6E077465 616D726F  [al2.secret.norma]


EEF7DE0 012C326C 6F6E0703 6C616D72 65730631  [l2,…normal1.se]


EEF7DF0 74657263 726F6E07 316C616D A1810604  [cret.normal1….]


Block header dump:  0x01000255



Поки ще не засекречені значення виділені сірим фоном. Зашифруємо їх у блоці:


ALTER TABLE closed MODIFY ( b ENCRYPT );


Це можна зробити тільки при відкритому сумочці. Ось що отримаємо у файлі трасування серверного процесу:



EEF7D30 0B6A7807 12380B13 0703022C 6D726F6E  [.xj…8.,…norm]


EEF7D40 34326C61 0E8464A4 1304CAAE E1116635  [al24.d……5f..]


EEF7D50 5B06C8CD C3AABA4A 8B4EA144 CE2B4987  […[J…D.N..I+.]


EEF7D60 EB2DEBB1 E97EB0C5 CDCA2CDB 99AC18E9  [..-…~..,……]


EEF7D70 52E1F415 CA85201C 726F6E07 326C616D  […R. …normal2]


EEF7D80 0703022C 6D726F6E 34316C61 1F21C866  [,…normal14f.!.]


EEF7D90 D765D462 EC2D8A33 8DF8F328 EC42E142  [b.e.3.-.(…B.B.]


EEF7DA0 CB3EEB72 A36909CE A28C845E 0F04567C  [r.>…i.^…/V..]


EEF7DB0 3C74BEC5 8F3EAEA8 B3612F6E 6009C40C  [..t<..>.n/a….`]


EEF7DC0 726F6E07 316C616D 0703002C 6D726F6E  [.normal1,…norm]


EEF7DD0 06326C61 72636573 6E077465 616D726F  [al2.secret.norma]


EEF7DE0 002C326C 6F6E0703 6C616D72 65730631  [l2,…normal1.se]


EEF7DF0 74657263 726F6E07 316C616D A9BB0601  [cret.normal1….]


Block header dump:  0x01000255



Значення двох слів “secret” в блоці дійсно виявилися зашифровані (і стали займати більше місця). Зверніть увагу, що шифрування раніше занесених даних Oracle відпрацьовує алгоритмом команди UPDATE, який допускає тимчасове збереження в блоці старих даних, на радість зловмисникам (в SQL Server те ж саме, якщо вірить інтернету).


Видача значень не розкриє тієї обставини, що в блоці вони зберігаються зашифровано:


SQL> SELECT * FROM closed;


A          B          C


———- ———- ———-


normal1    secret     normal1


normal2    secret     normal2


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


Впадає в око, що одне і те ж значення (“secret”) дало різний результат шифрування. Так сталося тому, що для додаткового захисту Oracle перед шифруванням приписує до значення випадкову послідовність байтів, так звану “прив’язку” (salt). Це перешкоджає розшифровці, і навіть позбавляє можливості зловмисника зрозуміти, що в різних полях початково були однакові значення. З іншого боку (а) “прив’язка” уповільнює обробку даних і (б) перешкоджає створенню (деревоподібного) індексу на шіфруемий стовпець. Останнє викликано тим, що значення полів індексуємого стовпця поміщаються в структуру індексу, і оскільки рівні вихідні значення будуть давати різні шифровані, індекс не зможе відпрацьовувати пошук по діапазону, тобто знеціниться. Ось Oracle це і забороняє:


SQL> CREATE INDEX closed_b ON closed ( b );


CREATE INDEX closed_b ON closed ( b )


                                  *


ERROR at line 1:


ORA-28338: cannot encrypt indexed column(s) with salt


Від застосування прив’язки можна відмовитися:


ALTER TABLE closed MODIFY ( b ENCRYPT NO SALT );


Ось приклад послідував результату з файлі трасування:


 …


EEF7CC0 02C10265 06C102FF 0703012C 6D726F6E  [e…….,…norm]


EEF7CD0 24326C61 C565F542 45F6CA9D C4516D27  [al2$B.e….E”mQ.]


EEF7CE0 902DEF69 C655685B 00844987 08803082  [i.-.[hU..I…0..]


EEF7CF0 A6106E22 45F862E5 726F6E07 326C616D  [“n…b.E.normal2]


EEF7D00 0703012C 6D726F6E 24316C61 C565F542  [,...normal1$B.e.]


EEF7D10 45F6CA9D C4516D27 902DEF69 C655685B  […E”mQ.i.-.[hU.]


EEF7D20 00844987 08803082 A6106E22 45F862E5  [.I…0..”n…b.E]


EEF7D30 726F6E07 316C616D 0703002C 6D726F6E  [.normal1,…norm]


EEF7D40 34326C61 0E8464A4 1304CAAE E1116635  [al24.d……5f..]


EEF7D50 5B06C8CD C3AABA4A 8B4EA144 CE2B4987  […[J…D.N..I+.]


EEF7D60 EB2DEBB1 E97EB0C5 CDCA2CDB 99AC18E9  [..-…~..,……]


EEF7D70 52E1F415 CA85201C 726F6E07 326C616D  […R. …normal2]


EEF7D80 0703022C 6D726F6E 34316C61 1F21C866  [,…normal14f.!.]


EEF7D90 D765D462 EC2D8A33 8DF8F328 EC42E142  [b.e.3.-.(…B.B.]


EEF7DA0 CB3EEB72 A36909CE A28C845E 0F04567C  [r.>…i.^…/V..]


EEF7DB0 3C74BEC5 8F3EAEA8 B3612F6E 6009C40C  [..t<..>.n/a….`]


EEF7DC0 726F6E07 316C616D 0703002C 6D726F6E  [.normal1,…norm]


EEF7DD0 06326C61 72636573 6E077465 616D726F  [al2.secret.norma]


EEF7DE0 002C326C 6F6E0703 6C616D72 65730631  [l2,…normal1.se]


EEF7DF0 74657263 726F6E07 316C616D A9BB0601  [cret.normal1….]


Block header dump:  0x01000255



Тепер два верхніх зазначених сірим фоном значення в блоці стали однаковими.


Вправа. Перевірити відкрився шанс завести індекс по полю B таблиці CLOSED.


Довідкова інформація та деякі подробиці


Переглянути стан та місцезнаходження гаманця з шіфроключамі можна тільки з версії 11 в таблиці V $ ENCRYPTION_WALLET.


Перелік шіфруемих стовпців в таблицях БД можна отримати з окремих системних таблиць DBA / ALL / USER_ENCRYPTED_COLUMNS. У нашому випадку ми отримаємо:


SQL> SELECT * FROM user_encrypted_columns;


TABLE_NAME          COLUMN_NAME         ENCRYPTION_ALG             SAL


——————- ——————- ————————– —


CLOSED              B                   AES 192 bits key           NO


Повне ім’я останнього стовпця SALT. Поле ENCRYPTION_ALG повідомляє алгоритм шифрування. Крім умолчательной AES192 можливі AES128, AES256 і 3DES168. Ці алгоритми слід вказувати явно:


ALTER TABLE closed REKEY USING “aes256”;


Зверніть увагу, що алгоритм вказується не для стовпця, а для всієї таблиці. Це тому, що Oracle не дозволяє різним стовпцях таблиці використовувати різні алгоритми шифрування: технічно “шифрування виконується на рівні блоку “(цитата). Фактично остання команда змінює не тільки алгоритм, але і ключ шифрування, теж один на всю таблицю. Цей власний ключ шифрування таблиці (не” головний “) тут же сам шифрується головним ключем з гаманця і запам’ятовується для неї в БД, в системній таблиці ENC $. Звідти він буде братися за будь-якої шифровці / розшифровці значень полів рядків таблиці. Так, при зверненні до зашифрованого полю таблиці СУБД візьме з ENC $ зашифрованих ключ цієї таблиці, розшифрує його головним ключем з гаманця, і вже відновленим ключем таблиці розшифрує значення поля.


Якщо потрібно змінити збережені шіфрозначенія, можна видати просто:


ALTER TABLE closed REKEY;


На “законну” можливість читати дані це ніяк не позначиться (так само як і попереднє дію), але збережені значення будуть підмінені на обчислені заново.


Вправа. Перевірити, чи зміниться зберігання в БД зашифрованих даних при зміні шіфроключа таблиці.


Переглянути ключі шифрування в гаманці можна програмою mkstore, наприклад:


>mkstore -wrl C:oracleadminorclwallet -list


Enter password: amicus123


Oracle Secret Store entries:


ORACLE.SECURITY.DB.ENCRYPTION.AcYP07kvGk+av9Jnw2C48y0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA


ORACLE.SECURITY.DB.ENCRYPTION.MASTERKEY


Те ж, але трохи інакше, покаже програма orapki, якщо видати:


 >orapki wallet display -wallet C:oracleadminorclwallet -pwd amicus123


Ці ж ключі покаже і Oracle Wallet Manager:


(Для цього потрібно буде викликати програму, послатися на каталог з файлом гаманця і ввести пароль).


А от значення головного ключа покаже тільки програма mkstore (слід один рядок):


 >mkstore -wrl C:oracleadminorclwallet -viewEntry ORACLE.SECURITY.DB.ENCRYPTION.MASTERKEY


Змінити значення головного ключа можна командою типу:


ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY “amicus123”;


Вправа. Перевірити, чи зміниться зберігання в БД зашифрованих даних при зміні головного ключа в сумочці.


Створення табличних просторів з шифруванні даними


Коли виникає потреба шифрувати дані багатьох стовпців в багатьох таблицях, доводиться мати справу з великою кількістю довідкових відомостей, що технологічно клопітно. Версія 11 дає для таких випадків узагальнене рішення: шифрування всіх даних, які розміщені в конкретне табличний простір. Така властивість табличного простору незмінно і вказується один раз при його створенні, наприклад:


CREATE TABLESPACE encrypted_data


DATAFILE “з: oracleoradataorclencrypt_df.dat” SIZE 1M


ENCRYPTION USING “3DES168”


DEFAULT STORAGE ( ENCRYPT )


;


Воно відображено в поле ENCRYPTED таблиці DBA_TABLESPACES.


Створення шифрування запасних копій


Дані БД можуть перебувати на зовнішніх носіях та у вигляді запасних (резервних) копій. Версія 10 дозволила їх шифрувати. Це робиться програмою rman, і поширюється на резервні набори (але не на копії образів файлів).


Шифрування резервного набору програмою rman може здійснюватися (1) з явною вказівкою ключа шифрування; (2) “прозоро”, тобто без явної вказівки, коли ключ береться з гаманця, (3) в “подвійному режимі”, коли допускається вказувати ключ явно або користуватися гаманцем – за вибором. Адміністратору простіше використовувати для шифрування резервних наборів гаманець, і цей спосіб розглянуто нижче.


Видамо:


 >rman TARGET /


… [Відповідь] …


RMAN> SET ENCRYPTION OFF;


… [Відповідь] …


RMAN> BACKUP AS BACKUPSET TABLESPACE users TAG “unencrypted”;


… [Відповідь] …


RMAN> SET ENCRYPTION ON;


… [Відповідь] …


RMAN> BACKUP AS BACKUPSET TABLESPACE users TAG “the last one”;


… [Відповідь] …


Для перевірки можна послідовно видати команди (далі у цьому розділі – все для rman):


 RESTORE TABLESPACE users VALIDATE;


SQL “ALTER SYSTEM SET ENCRYPTION WALLET CLOSE”;


RESTORE TABLESPACE users VALIDATE;


RESTORE TABLESPACE users FROM TAG “unencrypted” VALIDATE;


SQL “ALTER SYSTEM SET ENCRYPTION WALLET open AUTHENTICATED BY “amicus123″”;


RESTORE TABLESPACE users VALIDATE;


Алгоритми, які можна використовувати для шифрування, перераховані в таблиці V $ RMAN_ENCRYPTION_ALGORITHMS. Поставити потрібний алгоритм можна явочним шляхом, наприклад:


SET ENCRYPTION ALGORITHM “AES192”;


На практиці в rman зручно встановити умовчання, наприклад:


CONFIGURE ENCRYPTION ALGORITHM “AES256”;


CONFIGURE ENCRYPTION FOR DATABASE ON;


Інші властивості гаманця


Вибір розташування файлу гаманця


Файл гаманця ewallet. P 12 має право розташовуватися в будь-якому місці файлової системи сервера, аби тільки в області доступності СУБД. Нестандартне його місцезнаходження слід вказати в конфігураційному файлі серверного мережевого ПО sqlnet. ora. Включимо в нього параметр:



WALLET_LOCATION =


  ( SOURCE =


    ( METHOD = FILE )


    ( METHOD_DATA =


      ( DIRECTORY = C:oracleproduct10.2.0db_1encryptionwallet )


    )


  )



Створимо зазначений каталог і перенесемо в нього раніше створений файл ewallet. P 12. Закриємо гаманець і відкриємо знову командами ALTER SYSTEM, як вище. Файл гаманця самодостатній, і тому зробленого досить, щоб продовжувати з ним роботу на новому місці.


Замість назви WALLET_LOCATION файл sqlnet. Ora розуміє назву ENCRYPTION_WALLET_LOCATION.


Розміщення гаманця в реєстрі Windows


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


Перенести гаманець в реєстр можна засобами Oracle Wallet Manager (позначка Use Windows Registry в меню Wallet):


Постійно відкритий гаманець


Гаманець не обов’язково відкривати і закривати всякий раз у міру потреби вручну. На комп’ютері, де він розташовується, можна повідомити його режим “автооткритія” – при запуску ОС. Зробити це можна знову ж таки через Oracle Wallet Manager:


Зверніть увагу, що після цього в каталозі гаманця на пару файлу ewallet. P 12 з’явився файл cwallet.sso. Розширення sso є скорочення від single sign-on, що позначає “техніку єдиного входу”. Новий файл є по суті копія колишнього гаманця (але не копія файлу).


Вправа. Перевірити автоматичну готовність гаманця до вживання після переведення в режим автооткритія.


Щоб зняти режим автооткритія, в тому ж меню Wallet слід зняти позначку Auto Logon. Файл cwallet. Sso після цього автоматично пропаде. Це ж (але не протилежне!) Дію можна виконати командою, наприклад:


>mkstore -wrl C:oracleadminorclwallet -deleteSSO


Зовнішнє зберігання ключа


Гаманець Oracle дозволяє працювати з ключами, збереженими не в файлі, а на зовнішньому пристрої, наприклад підключається через порт USB (стандарт PKCS # 11). В цьому випадку (де-) шифрувальні процедури відпрацьовуються також на зовнішньому пристрої. Зв’язок з таким пристроєм дозволяє організувати програма orapki, проте вона носить цілком конкретний характер і тут не пояснюється.

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


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

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

Ваш отзыв

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

*

*