Шифрование базы данных - Database encryption

Шифрование базы данных в целом можно определить как процесс, который использует алгоритм для преобразования данные хранится в базе данных в "зашифрованный текст "что непонятно без предварительной расшифровки.[1] Таким образом, можно сказать, что цель базы данных шифрование заключается в защите данных, хранящихся в базе данных, от доступа лиц с потенциально «злонамеренными» намерениями.[2] Акт шифрования базы данных также снижает стимул для людей взламывать вышеупомянутую базу данных, поскольку «бессмысленные» зашифрованные данные практически бесполезны для хакеров.[3] Есть несколько техник и технологии доступны для шифрования баз данных, наиболее важные из которых будут подробно описаны в этой статье.

Прозрачное / внешнее шифрование базы данных

Прозрачное шифрование данных (часто сокращенно TDE) используется для шифрования всей базы данных,[2] что, следовательно, включает шифрование "данные в состоянии покоя ".[4] Неактивные данные обычно можно определить как «неактивные» данные, которые в настоящее время не редактируются или не передаются по сети.[5] Например, текстовый файл, хранящийся на компьютере, находится в состоянии покоя, пока он не будет открыт и отредактирован. Данные в состоянии покоя хранятся на физическом медиа хранилище такие решения, как ленты или жесткие диски.[6] Акт хранения большого количества конфиденциальные данные на физических носителях, естественно, вызывает опасения по поводу безопасности и кражи. TDE гарантирует, что данные на физических носителях не могут быть прочитаны злоумышленниками, которые могут иметь намерение украсть их.[7] Данные, которые не могут быть прочитаны, бесполезны, что снижает стимул для кражи. Возможно, самое важное преимущество TDE - это его прозрачность. Учитывая, что TDE шифрует все данные, можно сказать, что для правильной работы TDE не нужно изменять приложения.[8] Важно отметить, что TDE шифрует всю базу данных, а также ее резервные копии. Прозрачный элемент TDE связан с тем фактом, что TDE шифрует «на уровне страницы», что по сути означает, что данные шифруются при хранении и дешифруются при вызове в системную память.[9] Содержимое базы данных шифруется с использованием симметричного ключа, который часто называют «ключом шифрования базы данных».[2]

Шифрование на уровне столбца

Чтобы объяснить шифрование на уровне столбцов, важно обрисовать базовую структуру базы данных. Типичный реляционная база данных разделен на таблицы, которые делятся на столбцы что у каждого есть ряды данных.[10] Хотя TDE обычно шифрует всю базу данных, шифрование на уровне столбцов позволяет шифровать отдельные столбцы в базе данных.[11] Важно установить, что гранулярность шифрования на уровне столбцов вызывает определенные сильные и слабые стороны по сравнению с шифрованием всей базы данных. Во-первых, возможность шифрования отдельных столбцов позволяет шифрованию на уровне столбца быть значительно более гибким по сравнению с системами шифрования, которые шифруют всю базу данных, например TDE. Во-вторых, можно использовать совершенно уникальный и отдельный ключ шифрования для каждого столбца в базе данных. Это эффективно увеличивает сложность создания радужных таблиц, что, таким образом, означает, что данные, хранящиеся в каждом столбце, с меньшей вероятностью будут потеряны или утечка. Главный недостаток, связанный с шифрованием базы данных на уровне столбцов, - скорость или ее потеря. Шифрование отдельных столбцов с разными уникальными ключами в одной и той же базе данных может привести к снижению производительности базы данных и, кроме того, также снижает скорость, с которой содержимое базы данных может быть индексировано или выполнено поиск.[12]

Шифрование на уровне поля

Проводятся экспериментальные работы по обеспечению операций базы данных (таких как поиск или арифметические операции) над зашифрованными полями без необходимости их расшифровки.[13] Для рандомизации требуется надежное шифрование - каждый раз должен генерироваться другой результат. Это известно как вероятностное шифрование. Шифрование на уровне поля слабее случайного шифрования, но оно позволяет пользователям проверять равенство, не расшифровывая данные.[14]

Шифрование на уровне файловой системы

Основная статья: шифрование на уровне файловой системы

Шифрованная файловая система (EFS)

Основная статья: Шифрованная файловая система

Важно отметить, что традиционные методы шифрования базы данных обычно шифруют и дешифруют содержимое базы данных. Базы данных управляются «системами управления базами данных» (СУБД), которые работают поверх существующей операционной системы (ОС).[15] Это создает потенциальную угрозу безопасности, поскольку зашифрованная база данных может работать в доступной и потенциально уязвимой операционной системе. EFS может шифровать данные, которые не являются частью системы базы данных, что означает, что объем шифрования для EFS намного шире по сравнению с такой системой, как TDE, которая способна только шифровать файлы базы данных.[нужна цитата ] Хотя EFS расширяет объем шифрования, он также снижает производительность базы данных и может вызвать проблемы с администрированием, поскольку системным администраторам требуется доступ к операционной системе для использования EFS. Из-за проблем, связанных с производительностью, EFS обычно не используется в приложениях для создания базы данных, которые требуют частого ввода и вывода базы данных. Чтобы компенсировать проблемы с производительностью, часто рекомендуется использовать системы EFS в средах с небольшим количеством пользователей.[16]

Полное шифрование диска

Основная статья: полное шифрование диска

BitLocker не имеет тех же проблем с производительностью, что и EFS.[16]

Симметричное и асимметричное шифрование базы данных

Наглядная демонстрация симметричного шифрования

Симметричное шифрование базы данных

Симметричное шифрование в контексте шифрования базы данных включает закрытый ключ, применяемый к данным, которые хранятся и вызываются из базы данных. Этот закрытый ключ изменяет данные таким образом, что делает их нечитаемыми без предварительной расшифровки.[17] Данные шифруются при сохранении и дешифруются при открытии, если пользователю известен закрытый ключ. Таким образом, если данные должны быть переданы через базу данных, получатель должен иметь копию секретного ключа, используемого отправителем для расшифровки и просмотра данных.[18] Явным недостатком симметричного шифрования является возможность утечки конфиденциальных данных, если закрытый ключ будет передан лицам, которые не должны иметь доступа к данным.[17] Однако, учитывая, что в процессе шифрования задействован только один ключ, в целом можно сказать, что скорость является преимуществом симметричного шифрования.[19]

Асимметричное шифрование базы данных

Асимметричное шифрование расширяет симметричное шифрование за счет включения в метод шифрования двух разных типов ключей: закрытых и открытых ключей.[20] А открытый ключ может быть доступен любому и уникален для одного пользователя, тогда как закрытый ключ - это секретный ключ, который уникален и известен только одному пользователю.[21] В большинстве сценариев открытый ключ является ключом шифрования, тогда как закрытый ключ является ключом дешифрования. В качестве примера, если человек A хотел бы отправить сообщение отдельному лицу B, используя асимметричное шифрование, он зашифрует сообщение, используя открытый ключ индивидуума B, а затем отправит зашифрованную версию. После этого человек B сможет расшифровать сообщение, используя свой закрытый ключ. Индивидуум C не сможет расшифровать сообщение индивидуума A, поскольку закрытый ключ индивидуума C не совпадает с закрытым ключом индивидуума B.[22] Асимметричное шифрование часто описывается как более безопасное по сравнению с симметричным шифрованием базы данных, учитывая, что закрытые ключи не должны использоваться совместно, поскольку два отдельных ключа обрабатывают процессы шифрования и дешифрования.[23] По соображениям производительности асимметричное шифрование используется в Ключевой менеджмент вместо того, чтобы шифровать данные, как это обычно делается с помощью симметричного шифрования.

Ключевой менеджмент

В разделе «Симметричное и асимметричное шифрование базы данных» представлена ​​концепция открытых и закрытых ключей с базовыми примерами, в которых пользователи обмениваются ключами. Акт обмена ключами становится непрактичным с логистической точки зрения, когда множеству разных людей необходимо общаться друг с другом. При шифровании базы данных система обрабатывает хранение и обмен ключами. Этот процесс называется управлением ключами. Если ключи шифрования не управляются и не хранятся должным образом, может произойти утечка очень конфиденциальных данных. Кроме того, если система управления ключами удаляет или теряет ключ, информация, которая была зашифрована с помощью указанного ключа, по существу также оказывается «потерянной». Сложность логистики управления ключами также является темой, которую необходимо учитывать. По мере увеличения количества приложений, которые использует фирма, увеличивается и количество ключей, которые необходимо хранить и управлять ими. Таким образом, необходимо установить способ управления ключами от всех приложений через один канал, который также известен как корпоративное управление ключами.[24] Решения для управления корпоративными ключами продаются множеством поставщиков в технологической отрасли. Эти системы по сути представляют собой централизованное решение для управления ключами, которое позволяет администраторам управлять всеми ключами в системе через один концентратор.[25] Таким образом, можно сказать, что внедрение корпоративных решений для управления ключами может снизить риски, связанные с управлением ключами в контексте шифрования базы данных, а также уменьшить логистические проблемы, которые возникают, когда многие люди пытаются вручную поделиться ключами.[24]

Хеширование

Хеширование используется в системах баз данных как метод защиты конфиденциальных данных, таких как пароли; однако он также используется для повышения эффективности обращения к базе данных.[26] Введенные данные обрабатываются алгоритмом хеширования. Алгоритм хеширования преобразует введенные данные в строку фиксированной длины, которую затем можно сохранить в базе данных. У систем хеширования есть две критически важные характеристики, которые будут описаны ниже. Во-первых, хэши «уникальны и повторяемы». Например, многократное выполнение слова «кошка» через один и тот же алгоритм хеширования всегда будет давать один и тот же хеш, однако очень сложно найти слово, которое вернет тот же хеш, что и «кошка».[27] Во-вторых, алгоритмы хеширования необратимы. Чтобы связать это с примером, приведенным выше, было бы почти невозможно преобразовать вывод алгоритма хеширования обратно в исходный ввод, которым был "кот".[28] В контексте шифрования базы данных хеширование часто используется в системах паролей. Когда пользователь впервые создает свой пароль, он проходит через алгоритм хеширования и сохраняется в виде хеша. Когда пользователь снова входит на веб-сайт, вводимый им пароль проходит через алгоритм хеширования и затем сравнивается с сохраненным хешем.[29] Учитывая тот факт, что хеши уникальны, если оба хеша совпадают, считается, что пользователь ввел правильный пароль. Одним из примеров популярной хеш-функции является SHA (Secure Hash Algorithm) 256.[30]

Соление

Одна проблема, которая возникает при использовании хеширования для управления паролями в контексте шифрования базы данных, заключается в том, что злоумышленник потенциально может использовать таблицу Input to Hash. радужный стол[31] для конкретного алгоритма хеширования, который использует система. Это эффективно позволит человеку расшифровать хэш и, таким образом, получить доступ к сохраненным паролям.[32] Решение этой проблемы - «посолить» хеш. Соль - это процесс шифрования не только пароля в базе данных. Чем больше информации добавляется к строке, подлежащей хешированию, тем сложнее становится сопоставление радужных таблиц. Например, система может объединить адрес электронной почты и пароль пользователя в один хэш. Это увеличение сложности хэша означает, что создание радужных таблиц намного сложнее и, следовательно, менее вероятно, что они будут созданы. Это, естественно, означает, что угроза потери конфиденциальных данных сводится к минимуму за счет использования хешей.[33]

Перец

Некоторые системы включают в свои системы перемешивания «перец» помимо солей. Перцовые системы спорны, однако их использование все же необходимо объяснить.[31] Перец - это значение, которое добавляется к хешированному паролю, который был посолен.[34] Этот перец часто уникален для одного веб-сайта или сервиса, и важно отметить, что один и тот же перец обычно добавляется ко всем паролям, сохраненным в базе данных.[35] Теоретически включение перца в системы хеширования паролей может снизить риск радужных (входных данных: хэш) таблиц, учитывая специфичность перца на системном уровне, однако реальные преимущества реализации перца весьма спорны.[34]

Шифрование на уровне приложений

При шифровании на уровне приложений процесс шифрования данных завершается приложением, которое использовалось для создания или изменения данных, которые должны быть зашифрованы. По сути, это означает, что данные шифруются перед записью в базу данных. Этот уникальный подход к шифрованию позволяет адаптировать процесс шифрования для каждого пользователя на основе информации (например, полномочий или ролей), которые приложение знает о своих пользователях.[35]

Преимущества шифрования на уровне приложений

Одним из наиболее важных преимуществ шифрования на уровне приложений является тот факт, что шифрование на уровне приложений может упростить процесс шифрования, используемый компанией. Если приложение шифрует данные, которые оно записывает / изменяет из базы данных, то дополнительный инструмент шифрования не нужно будет интегрировать в систему. Второе главное преимущество связано с общей темой воровства. Учитывая, что данные зашифрованы перед записью на сервер, хакеру потребуется доступ к содержимому базы данных, а также к приложениям, которые использовались для шифрования и дешифрования содержимого базы данных, чтобы расшифровать конфиденциальные данные.[36]

Недостатки шифрования на уровне приложений

Первым важным недостатком шифрования на уровне приложений является то, что приложения, используемые фирмой, необходимо будет модифицировать для шифрования самих данных. Это может потребовать значительного количества времени и других ресурсов. Учитывая характер альтернативных издержек, компании могут не поверить, что шифрование на уровне приложений стоит вложенных средств. Кроме того, шифрование на уровне приложения может ограничивать производительность базы данных. Если все данные в базе данных зашифрованы множеством различных приложений, становится невозможным индексирование или поиск данных в базе данных. Обосновать это на самом деле в виде базового примера: было бы невозможно создать глоссарий на одном языке для книги, написанной на 30 языках. Наконец, сложность управления ключами возрастает, поскольку несколько разных приложений должны иметь полномочия и доступ для шифрования данных и записи их в базу данных.[36]

Риски шифрования базы данных

Обсуждая тему шифрования базы данных, необходимо осознавать риски, связанные с этим процессом. Первый набор рисков связан с управлением ключами. Если закрытые ключи не управляются в «изолированной системе», системные администраторы со злонамеренными намерениями могут иметь возможность расшифровать конфиденциальные данные с помощью ключей, к которым у них есть доступ. Фундаментальный принцип ключей также порождает потенциально разрушительный риск: если ключи потеряны, то и зашифрованные данные по существу теряются, поскольку дешифрование без ключей практически невозможно.[37]

Рекомендации

  1. ^ «Что такое шифрование и дешифрование базы данных? - Определение из Техопедии». Techopedia.com. Получено 4 ноября, 2015.
  2. ^ а б c «Прозрачное шифрование данных с помощью базы данных SQL Azure». msdn.microsoft.com. Получено 4 ноября, 2015.
  3. ^ "SQL SERVER - Введение в шифрование SQL Server и шифрование симметричного ключа с помощью сценария". Путешествие к авторитету SQL с Пиналем Дэйвом. 28 апреля 2009 г.. Получено 25 октября, 2015.
  4. ^ «Прозрачное шифрование данных (TDE)». msdn.microsoft.com. Получено 25 октября, 2015.
  5. ^ «Что такое данные в состоянии покоя? - Определение с сайта WhatIs.com». SearchStorage. Получено 25 октября, 2015.
  6. ^ «Методы и продукты шифрования для аппаратной безопасности хранения данных». КомпьютерЕженедельно. Получено 31 октября, 2015.
  7. ^ «Решения для шифрования хранилища». www.thales-esecurity.com. Получено 25 октября, 2015.
  8. ^ «Прозрачное шифрование данных (TDE) в SQL Server - DatabaseJournal.com». www.databasejournal.com. Получено 2 ноября, 2015.
  9. ^ «Использование прозрачного шифрования данных». sqlmag.com. Архивировано из оригинал 14 октября 2017 г.. Получено 2 ноября, 2015.
  10. ^ "Учебное пособие по базам данных, SQL с использованием MySQL". www.atlasindia.com. Получено 4 ноября, 2015.
  11. ^ «Параметры шифрования SQL Server». sqlmag.com. Архивировано из оригинал 27 октября 2017 г.. Получено 2 ноября, 2015.
  12. ^ «Различия между шифрованием всей базы данных и шифрованием столбцов». www.netlib.com. Получено 2 ноября, 2015.
  13. ^ «Оптимизированное и контролируемое предоставление зашифрованных внешних данных» (PDF). www.fkerschbaum.org.
  14. ^ Сучиу, Дэн (2012). «Техническая перспектива: SQL в зашифрованной базе данных». Коммуникации ACM.
  15. ^ Spooner, Дэвид Л .; Гудес Э. (1 мая 1984 г.). «Универсальный подход к разработке безопасной операционной системы баз данных». IEEE Transactions по разработке программного обеспечения. SE-10 (3): 310–319. Дои:10.1109 / TSE.1984.5010240. ISSN  0098-5589.
  16. ^ а б «Шифрование базы данных в SQL Server 2008 Enterprise Edition». technet.microsoft.com. Получено 3 ноября, 2015.
  17. ^ а б «Описание симметричного и асимметричного шифрования». support.microsoft.com. Получено 25 октября, 2015.
  18. ^ «Как работает шифрование». Как это работает. 6 апреля 2001 г.. Получено 25 октября, 2015.
  19. ^ «Асимметричный и симметричный - Взлом с помощью PHP - Практический PHP». www.hackingwithphp.com. Получено 3 ноября, 2015.
  20. ^ «Как работает шифрование». Как это работает. 6 апреля 2001 г.. Получено 1 ноября, 2015.
  21. ^ Молодой, доктор Билл. «Основы компьютерной безопасности, лекция 44: симметричное и асимметричное шифрование» (PDF). Техасский университет в Остине. Архивировано из оригинал (PDF) 5 марта 2016 г.. Получено 1 ноября, 2015.
  22. ^ «Что такое асимметричная криптография и как ее использовать?». Двухфакторная аутентичность. Получено 1 ноября, 2015.
  23. ^ «Преимущества и недостатки асимметричных и симметричных криптосистем» (PDF). Вавилонский университет. Получено 3 ноября, 2015.
  24. ^ а б «Управление ключами шифрования жизненно важно для защиты корпоративного хранилища данных». КомпьютерЕженедельно. Получено 2 ноября, 2015.
  25. ^ "Что такое корпоративное управление ключами?". web.townsendsecurity.com. Получено 2 ноября, 2015.
  26. ^ «Что такое хеширование? - Определение с сайта WhatIs.com». SearchSQLServer. Получено 1 ноября, 2015.
  27. ^ «Как программное обеспечение для шифрования данных создает односторонние хеш-файлы с использованием алгоритма хеширования sha1». www.metamorphosite.com. Получено 1 ноября, 2015.
  28. ^ «Понимание шифрования - симметричного, асимметричного и хеширования». Атомный спин. 20 ноября 2014 г.. Получено 1 ноября, 2015.
  29. ^ «PHP: хеширование пароля - руководство». php.net. Получено 1 ноября, 2015.
  30. ^ "Реализация алгоритма криптографического хеширования SHA-256 в JavaScript | Скрипты подвижного типа". www.movable-type.co.uk. Получено 3 ноября, 2015.
  31. ^ а б «Соль и перец - Как зашифровать пароли к базе данных». blog.kablamo.org. Получено 1 ноября, 2015.
  32. ^ «PHP: хеширование пароля - руководство». php.net. Получено 1 ноября, 2015.
  33. ^ «Почему всегда нужно солить свои хэши - Веб-разработка в Брайтоне - Добавленные байты». Добавленные байты. Получено 1 ноября, 2015.
  34. ^ а б "Блог ircmaxell: правильно солить пароли, дело против перца". blog.ircmaxell.com. Получено 2 ноября, 2015.
  35. ^ а б «Шифрование приложений от Thales e-Security». www.thales-esecurity.com. Получено 25 октября, 2015.
  36. ^ а б Бакчам, Таня (апрель 2010 г.). «Прозрачное шифрование данных: новые технологии и лучшие методы шифрования баз данных». Sans.org. Институт SANS. Получено 25 октября, 2015.
  37. ^ «Шифрование базы данных: проблемы, риски и решения». www.thales-esecurity.com. Получено 25 октября, 2015.