Шифрование базы данных обычно можно определить как процесс, использующий алгоритм для преобразования данных, хранящихся в базе данных, в « зашифрованный текст », который непонятен без предварительного расшифрования. [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]
Важно отметить, что традиционные методы шифрования баз данных обычно шифруют и дешифруют содержимое базы данных. Базы данных управляются «системами управления базами данных» (СУБД), которые работают поверх существующей операционной системы (ОС). [15] Это создает потенциальную угрозу безопасности, поскольку зашифрованная база данных может работать в доступной и потенциально уязвимой операционной системе. EFS может шифровать данные, которые не являются частью системы базы данных, а это означает, что область шифрования для EFS намного шире по сравнению с такой системой, как TDE, которая способна шифровать только файлы базы данных. [ нужна цитация ] Хотя EFS расширяет возможности шифрования, он также снижает производительность базы данных и может вызвать проблемы с администрированием, поскольку системным администраторам требуется доступ к операционной системе для использования EFS. Из-за проблем с производительностью EFS обычно не используется в приложениях баз данных, которые требуют частого ввода и вывода данных из базы данных. Чтобы компенсировать проблемы с производительностью, часто рекомендуется использовать системы EFS в средах с небольшим количеством пользователей. [16]
BitLocker не имеет тех же проблем с производительностью, что и EFS. [16]
Симметричное шифрование в контексте шифрования базы данных предполагает применение закрытого ключа к данным, которые хранятся и вызываются из базы данных. Этот закрытый ключ изменяет данные таким образом, что они становятся нечитаемыми без предварительного расшифрования. [17] Данные шифруются при сохранении и расшифровываются при открытии при условии, что пользователь знает закрытый ключ. Таким образом, если данные должны быть переданы через базу данных, получатель должен иметь копию секретного ключа, используемого отправителем для расшифровки и просмотра данных. [18] Явным недостатком симметричного шифрования является возможность утечки конфиденциальных данных, если закрытый ключ будет передан лицам, которые не должны иметь доступа к данным. [17] Однако, учитывая, что в процессе шифрования участвует только один ключ, в целом можно сказать, что скорость является преимуществом симметричного шифрования. [19]
Асимметричное шифрование расширяет симметричное шифрование за счет включения в метод шифрования двух разных типов ключей: секретного и открытого ключа. [20] Открытый ключ доступен любому и уникален для одного пользователя, тогда как закрытый ключ — это секретный ключ, который уникален и известен только одному пользователю. [21] В большинстве сценариев открытый ключ является ключом шифрования, тогда как закрытый ключ является ключом дешифрования. Например, если человек А хочет отправить сообщение человеку Б, используя асимметричное шифрование, он зашифрует сообщение, используя открытый ключ человека Б, а затем отправит зашифрованную версию. Тогда человек Б сможет расшифровать сообщение, используя свой личный ключ. Индивид C не сможет расшифровать сообщение индивидуума A, поскольку закрытый ключ индивидуума C не совпадает с секретным ключом индивидуума B. [22] Асимметричное шифрование часто описывается как более безопасное по сравнению с симметричным шифрованием базы данных, поскольку частные ключи не должны быть общими, поскольку два отдельных ключа обрабатывают процессы шифрования и дешифрования. [23] По соображениям производительности при управлении ключами используется асимметричное шифрование, а не для шифрования данных, которое обычно выполняется с помощью симметричного шифрования.
В разделе «Симметричное и асимметричное шифрование баз данных» была представлена концепция открытых и закрытых ключей с основными примерами обмена ключами между пользователями. Обмен ключами становится непрактичным с логистической точки зрения, когда множеству разных людей необходимо общаться друг с другом. При шифровании базы данных система занимается хранением и обменом ключами. Этот процесс называется управлением ключами. Если ключи шифрования не управляются и не хранятся должным образом, возможна утечка очень конфиденциальных данных. Кроме того, если система управления ключами удаляет или теряет ключ, информация, которая была зашифрована с помощью этого ключа, по сути, также становится «потерянной». Сложность логистики управления ключами также является темой, которую необходимо принять во внимание. По мере увеличения количества приложений, которые использует фирма, также увеличивается количество ключей, которые необходимо хранить и управлять ими. Таким образом, необходимо создать способ, позволяющий управлять ключами всех приложений через один канал, который также известен как управление ключами предприятия. [24] Решения по управлению ключами предприятия продаются большим количеством поставщиков в технологической отрасли. Эти системы по существу предоставляют централизованное решение для управления ключами, которое позволяет администраторам управлять всеми ключами в системе через один концентратор. [25] Таким образом, можно сказать, что внедрение корпоративных решений по управлению ключами потенциально может снизить риски, связанные с управлением ключами в контексте шифрования баз данных, а также уменьшить логистические проблемы, которые возникают, когда многие люди пытаются вручную поделитесь ключами. [24]
Хеширование используется в системах баз данных как метод защиты конфиденциальных данных, таких как пароли; однако он также используется для повышения эффективности ссылок на базу данных. [26] Введенные данные обрабатываются с помощью алгоритма хеширования. Алгоритм хеширования преобразует введенные данные в строку фиксированной длины, которую затем можно сохранить в базе данных. Системы хеширования имеют две чрезвычайно важные характеристики, которые сейчас будут описаны. Во-первых, хэши «уникальны и повторяемы». Например, многократное выполнение слова «кот» через один и тот же алгоритм хеширования всегда будет давать один и тот же хэш, однако чрезвычайно сложно найти слово, которое будет возвращать тот же хеш, что и «кот». [27] Во-вторых, алгоритмы хеширования необратимы. Если связать это с примером, приведенным выше, было бы практически невозможно преобразовать выходные данные алгоритма хеширования обратно в исходные входные данные, которыми был «кошка». [28] В контексте шифрования баз данных хеширование часто используется в системах паролей. Когда пользователь впервые создает свой пароль, он проходит через алгоритм хеширования и сохраняется как хэш. Когда пользователь снова входит на веб-сайт, введенный им пароль проходит через алгоритм хеширования, а затем сравнивается с сохраненным хешем. [29] Учитывая тот факт, что хеши уникальны, если оба хеша совпадают, то говорят, что пользователь ввел правильный пароль. Одним из примеров популярной хеш-функции является SHA (алгоритм безопасного хеширования) 256. [30]
Одна из проблем, которая возникает при использовании хеширования для управления паролями в контексте шифрования базы данных, заключается в том, что злонамеренный пользователь потенциально может использовать радужную таблицу ввода в хэш-таблицу [31] для конкретного алгоритма хеширования, который использует система. Это фактически позволит человеку расшифровать хэш и, таким образом, получить доступ к сохраненным паролям. [32] Решением этой проблемы является «солить» хэш. Соление — это процесс шифрования не только пароля в базе данных. Чем больше информации добавляется в строку, подлежащую хешированию, тем труднее становится сопоставлять радужные таблицы. Например, система может объединить адрес электронной почты и пароль пользователя в один хэш. Такое увеличение сложности хэша означает, что создание радужных таблиц становится гораздо сложнее и, следовательно, менее вероятно. Это, естественно, означает, что угроза потери конфиденциальных данных сводится к минимуму за счет добавления хешей. [33]
Некоторые системы помимо солей включают в свои системы хеширования «перец». Системы перца спорны, однако объяснить их использование все же необходимо. [31] «Перец» — это значение, которое добавляется к хешированному паролю, который был подсолен. [34] Этот перец часто уникален для одного веб-сайта или службы, и важно отметить, что один и тот же перец обычно добавляется ко всем паролям, сохраненным в базе данных. [35] Теоретически включение перцев в системы хеширования паролей потенциально может снизить риск появления радужных (входных: хэш) таблиц, учитывая специфику перцев на системном уровне, однако реальные преимущества реализации перца весьма спорны. [34]
При шифровании на уровне приложения процесс шифрования данных завершается приложением, которое использовалось для создания или изменения данных, подлежащих шифрованию. По сути это означает, что данные шифруются перед записью в базу данных. Этот уникальный подход к шифрованию позволяет адаптировать процесс шифрования для каждого пользователя на основе информации (например, о правах или ролях), которую приложение знает о своих пользователях. [35]
По словам Евгения Пилянкевича, «Шифрование на уровне приложений становится хорошей практикой для систем с повышенными требованиями к безопасности, с общим уклоном в сторону облачных систем без периметра и более открытых». [36]
Одним из наиболее важных преимуществ шифрования на уровне приложения является тот факт, что шифрование на уровне приложения может упростить процесс шифрования, используемый компанией. Если приложение шифрует данные, которые оно записывает/изменяет из базы данных, то в систему не потребуется интегрировать дополнительный инструмент шифрования. Второе главное преимущество связано со всеобъемлющей темой воровства. Учитывая, что данные шифруются перед записью на сервер, хакеру потребуется доступ к содержимому базы данных, а также к приложениям, которые использовались для шифрования и расшифровки содержимого базы данных, чтобы расшифровать конфиденциальные данные. [37]
Первым важным недостатком шифрования на уровне приложений является то, что приложения, используемые фирмой, необходимо будет модифицировать для шифрования самих данных. Это потенциально может потребовать значительного количества времени и других ресурсов. Учитывая природу альтернативных издержек, компании могут не поверить, что шифрование на уровне приложений стоит вложений. Кроме того, шифрование на уровне приложения может ограничивать производительность базы данных. Если все данные в базе данных зашифрованы множеством различных приложений, индексирование или поиск данных в базе данных становится невозможным. Обосновать это на самом деле можно на простом примере: было бы невозможно составить глоссарий на одном языке для книги, написанной на 30 языках. Наконец, возрастает сложность управления ключами, поскольку множеству различных приложений необходимы полномочия и доступ для шифрования данных и записи их в базу данных. [37]
При обсуждении темы шифрования базы данных необходимо осознавать риски, связанные с этим процессом. Первый набор рисков связан с управлением ключами. Если закрытые ключи не управляются в «изолированной системе», системные администраторы со злыми намерениями могут иметь возможность расшифровывать конфиденциальные данные, используя ключи, к которым у них есть доступ. Фундаментальный принцип ключей также порождает потенциально разрушительный риск: если ключи утеряны, то, по сути, теряются и зашифрованные данные, поскольку расшифровка без ключей практически невозможна. [38]