Шифрування бази даних
Шифрування бази даних — використання технології шифрування для перетворення інформації, що зберігається в базі даних (БД), в шифротекст, що робить її прочитання неможливим для осіб, що не володіють ключами шифрування[1].
Прозоре шифрування бази даних (англ. Transparent Database Encryption, TDE) — технологія, яка застосовується, наприклад, у продуктах Microsoft і Oracle для шифрування і дешифрування вводу-виводу файлів БД. Дані шифруються перед записом на диск і дешифруються під час читання в пам'ять, що вирішує проблему захисту «неактивних» даних, але не забезпечує збереження інформації при передачі по каналах зв'язку або під час використання. Перевагою TDE є те, що шифрування і дешифрування виконуються прозоро для додатків, тобто їх модифікація не потрібна[2][3][4].
TDE застосовується для файлів БД і журналу транзакцій на рівні сторінок. Сторінки шифруються за допомогою спеціального симетричного ключа шифрування бази даних (англ. Database Encryption Key), захищеного сертифікатом, який зберігається в БД master і шифрується її головним ключем, або асиметричним ключем, захищеним модулем розширеного керування ключами (англ. Extensible Key Manager, EKM). Застосування TDE не збільшує розмір зашифрованої БД і має незначний вплив на її продуктивність.
TDE застосовується для файлів БД на рівні стовпців. Для таблиці, що містить вибрані для шифрування стовпці, створюється симетричний ключ шифрування, захищений головним ключем, який зберігається в іншому місці за межами БД, званому гаманцем (англ. Wallet). Зашифровані ключі таблиць містяться в словнику даних (англ. Data Dictionary).
Шифрування на рівні стовпців (англ. Column-Level Encryption) на відміну від TDE, що шифрує БД повністю в реалізації Microsoft і окремі стовпці, але з однаковим ключем для всієї таблиці в реалізації Oracle, цей метод дозволяє шифрувати окремі стовпці з різними ключами, що забезпечує додаткову гнучкість при захисті даних. Ключі можуть бути призначені користувачам і захищені паролем для запобігання автоматичної розшифровки, однак це ускладнює адміністрування БД. При використанні шифрування на рівні стовпців необхідно внесення змін до клієнтських додатків. Крім цього зменшується продуктивність БД[5].
Важливо зазначити, що традиційні методи шифрування баз даних зазвичай шифрують і дешифрують вміст БД, адміністрування якої забезпечується системою керування базами даних, що працює поверх операційної системи[6]. Це зменшує захищеність інформації, так як зашифрована БД може бути запущена на відкритій або потенційно вразливій операційній системі. Наприклад, Microsoft використовує технологію шифрування файлової системи (англ. Encrypting File System, EFS), яка забезпечує шифрування на рівні файлів. Кожен об'єкт шифрується за допомогою унікального ключа шифрування файлів (англ. File Encryption Key), захищеного сертифікатом користувача. Цей сертифікат може бути складовим, що дає можливість отримати доступ до файлу більше ніж одному користувачеві. Через розширення сфери шифрування, використання EFS може знизити продуктивність і ускладнити адміністрування, так як системному адміністратору потрібно мати доступ до операційної системи для використання EFS[7].
Існує два основних способи шифрування інформації: симетричний та асиметричний. Головним принципом у них є те, що передавач і приймач заздалегідь знають алгоритм шифрування і ключ до повідомлення, без знання яких інформація являє собою безглуздий набір символів[8].
Симетричне шифрування (шифрування з закритим ключем) є найстарішим і найвідомішим методом. У контексті баз даних він включає в себе закритий ключ, який застосовується для шифрування та дешифрування інформації, що зберігається в БД і викликається з неї. Цей параметр змінює дані таким чином, що їх прочитання без розшифровки стає неможливим. Явним недоліком цього методу є те, що може статися витік конфіденційної інформації, якщо ключ виявиться у осіб, які не повинні мати доступ до даних. Однак використання лише одного ключа в процесі шифрування дає перевагу у вигляді швидкості і простоти застосування даної технології[9].
Проблема потрапляння секретного ключа в чужі руки при передачі по каналах зв'язку, яку має шифрування з закритим ключем, вирішена в методі асиметричного шифрування (шифруванні з відкритим ключем), в якому є два пов'язаних між собою ключа — це пара ключів. Відкритий ключ відомий всім і може передаватися по незахищеному каналу зв'язку. У той час як другий, закритий ключ зберігається в таємниці і є унікальним для кожного користувача. Відкритий ключ використовується для шифрування даних, а закритий — для розшифрування. Асиметричне шифрування є більш безпечним, у порівнянні з симетричним, але в той же час воно істотно повільніше.
Хешування (англ. hashing) використовується в якості методу захисту інформації. Алгоритм хешування генерує рядок певної довжини, звану геш-сумою, на основі введених даних або повідомлення. Хешування відрізняється від шифрування тим, що алгоритм є незворотнім, тобто не існує перетворення, що дозволяє отримати повідомлення із його хешу[10][11].
Процес шифрування здійснюється додатком, який створює або змінює дані, тобто він відбувається перед записом в базу даних. Цей підхід є більш гнучким, так як з додатком відомі ролі або права доступу користувачів, а також інформація про те, які дані є конфіденційними[12].
Одним з головних переваг шифрування, вбудованого в додаток, є те, що немає необхідності використовувати додаткове рішення для захисту даних при передачі по каналах зв'язку, так як вони відправляються вже зашифрованими. Ще одна перевага такого методу — це те, що крадіжка конфіденційної інформації стає складніше, так як зловмисник повинен мати доступ до додатка для того, щоб розшифрувати дані, що зберігаються в БД.
Для реалізації шифрування на рівні додатків необхідно внесення змін не тільки в сам додаток, але і в базу даних. Також можуть виникнути проблеми з продуктивністю БД, у якій, наприклад, пропадає можливість індексування і пошуку. Ще одним недоліком є управління ключами в системі з таким шифруванням. Так як кілька програм можуть використовувати БД, то ключі зберігаються у багатьох місцях, тому неправильне управління ними може призвести до крадіжки інформації або унеможливлення її використання. До того ж, якщо виникає необхідність зміни ключа, то для початку потрібно розшифрувати всі дані зі старим ключем, і потім знову зашифрувати, використовуючи новий ключ.
- ↑ Luc Bouganim, Yanli GUO. Database Encryption (PDF). www-smis.inria.fr. Архів оригіналу (PDF) за 17 квітня 2018. Процитовано 9 квітня 2018. [Архівовано 2018-04-17 у Wayback Machine.]
- ↑ Прозоре шифрування даних (TDE). microsoft.com. Архів оригіналу за 24 березня 2017.
- ↑ Transparent Data Encryption. oracle.com. Архів оригіналу за 9 квітня 2018. Процитовано 9 квітня 2018.
- ↑ Postgres and Transparent Data Encryption (TDE). enterprisedb.com. Архів оригіналу за 28 листопада 2016. Процитовано 9 квітня 2018.
- ↑ Database Encryption in SQL Server 2008 Enterprise Edition. microsoft.com. Архів оригіналу за 8 грудня 2017. Процитовано 9 квітня 2018.
- ↑ Дейт, 2005.
- ↑ Baccam, Tanya (April 2010). Transparent Data Encryption: New Technologies and Best Practices for Database Encryption. Sans.org. SANS Institute. Архів оригіналу за 12 квітня 2018. Процитовано 25 жовтня 2015. [Архівовано 2018-04-12 у Wayback Machine.]
- ↑ Description of Symmetric and Asymmetric Encryption. microsoft.com. Архів оригіналу за 13 вересня 2016. Процитовано 9 квітня 2018.
- ↑ Коробейников, 2004.
- ↑ Passwords Technical Overview. microsoft.com. Архів оригіналу за 15 жовтня 2017. Процитовано 9 квітня 2018.
- ↑ Security Glossary — «H». microsoft.com. Архів оригіналу за 25 листопада 2017. Процитовано 9 квітня 2018.
- ↑ Шифрування на рівні додатків. thales-esecurity.com. Архів оригіналу за 3 серпня 2016. [Архівовано 2016-08-03 у Wayback Machine.]
- Дейт К. Дж. Введення в системи баз даних = Introduction to Database Systems. — 8-е изд. — М. : Вільямс, 2005. — 1328 с. — ISBN 5-8459-0788-8 (рус.) 0-321-19784-4 (англ.).
- Коробейников А. Г., Гатчин Ю. А. Математические основы криптографии. Учебное пособие. — СПб : СПб ГУ ИТМО, 2004. — 106 с.
- Robert Morris, Ken Thompson. Password security: a case history. — Communications of the ACM, 1979. — Vol. 22, no. 11. — P. 594—597.