Шифрование базы данных
 | Эта статья нуждается в дополнительных цитатах для проверки . ( октябрь 2015 г. ) |
Шифрование базы данных обычно можно определить как процесс, использующий алгоритм для преобразования данных, хранящихся в базе данных, в « зашифрованный текст », который непонятен без предварительного расшифрования. [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] В большинстве сценариев открытый ключ является ключом шифрования, тогда как закрытый ключ является ключом дешифрования. Например, если человек А хочет отправить сообщение человеку Б, используя асимметричное шифрование, он зашифрует сообщение, используя открытый ключ человека Б, а затем отправит зашифрованную версию. Тогда человек Б сможет расшифровать сообщение, используя свой личный ключ. Индивид 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]
Ссылки
[ редактировать ]- ^ «Что такое шифрование и дешифрование базы данных? — Определение из Techopedia» . Techopedia.com . Проверено 4 ноября 2015 г.
- ^ Перейти обратно: а б с «Прозрачное шифрование данных с помощью базы данных SQL Azure» . msdn.microsoft.com . Проверено 4 ноября 2015 г.
- ^ «SQL SERVER — введение в шифрование SQL Server и учебное пособие по шифрованию с симметричным ключом с помощью скрипта» . Путешествие в SQL Authority с Пиналом Дэйвом . 28 апреля 2009 года . Проверено 25 октября 2015 г.
- ^ «Прозрачное шифрование данных (TDE)» . msdn.microsoft.com . Проверено 25 октября 2015 г.
- ^ «Что такое неактивные данные? — Определение с сайта WhatIs.com» . ПоискХранилища . Проверено 25 октября 2015 г.
- ^ «Методы и продукты шифрования для аппаратной безопасности хранения данных» . Компьютереженедельник . Проверено 31 октября 2015 г.
- ^ «Решения для шифрования хранилища» . www.thales-esecurity.com . Архивировано из оригинала 24 февраля 2017 года . Проверено 25 октября 2015 г.
- ^ «Прозрачное шифрование данных (TDE) в SQL Server — DatabaseJournal.com» . www.databasejournal.com . 19 мая 2014 года . Проверено 2 ноября 2015 г.
- ^ «Использование прозрачного шифрования данных» . sqlmag.com . Архивировано из оригинала 14 октября 2017 года . Проверено 2 ноября 2015 г.
- ^ «Учебное пособие по концепциям баз данных, SQL с использованием MySQL» . www.atlasindia.com . Проверено 4 ноября 2015 г.
- ^ «Параметры шифрования SQL Server» . sqlmag.com . Архивировано из оригинала 27 октября 2017 года . Проверено 2 ноября 2015 г.
- ^ «Различия между всей базой данных и шифрованием столбцов» . www.netlib.com . Проверено 2 ноября 2015 г.
- ^ «Оптимизированное и контролируемое предоставление зашифрованных внешних данных» (PDF) . www.fkerschbaum.org . Архивировано из оригинала (PDF) 26 марта 2017 года . Проверено 13 апреля 2016 г.
- ^ Сучу, Дэн (2012). «Техническая перспектива: SQL в зашифрованной базе данных». Коммуникации АКМ . дои : 10.1145/2330667.2330690 . S2CID 33705485 .
- ^ Спунер, Дэвид Л.; Гудес, Э. (1 мая 1984 г.). «Единый подход к разработке безопасной операционной системы базы данных». Транзакции IEEE по разработке программного обеспечения . СЭ-10 (3): 310–319. дои : 10.1109/TSE.1984.5010240 . ISSN 0098-5589 . S2CID 15407701 .
- ^ Перейти обратно: а б «Шифрование базы данных в SQL Server 2008 Enterprise Edition» . technet.microsoft.com . 4 сентября 2009 года . Проверено 3 ноября 2015 г.
- ^ Перейти обратно: а б «Описание симметричного и асимметричного шифрования» . support.microsoft.com . Проверено 25 октября 2015 г.
- ^ «Как работает шифрование» . Как все работает . 6 апреля 2001 года . Проверено 25 октября 2015 г.
- ^ «Асимметричный против симметричного – Взлом с помощью PHP – Практический PHP» . www.hackingwithphp.com . Проверено 3 ноября 2015 г.
- ^ «Как работает шифрование» . Как все работает . 6 апреля 2001 года . Проверено 1 ноября 2015 г.
- ^ Янг, доктор Билл. «Основы компьютерной безопасности, лекция 44: симметричное и асимметричное шифрование» (PDF) . Техасский университет в Остине. Архивировано из оригинала (PDF) 5 марта 2016 года . Проверено 1 ноября 2015 г.
- ^ «Что такое асимметричная криптография и как ее использовать?» . Двухфакторная подлинность . Проверено 1 ноября 2015 г.
- ^ «Преимущества и недостатки асимметричных и симметричных криптосистем» (PDF) . Вавилонский университет . Проверено 3 ноября 2015 г.
- ^ Перейти обратно: а б «Управление ключами шифрования жизненно важно для обеспечения безопасности хранения корпоративных данных» . Компьютереженедельник . Проверено 2 ноября 2015 г.
- ^ «Что такое управление ключами предприятия?» . web.townsendsecurity.com . Проверено 2 ноября 2015 г.
- ^ «Что такое хеширование? — Определение с сайта WhatIs.com» . ПоискSQLServer . Проверено 1 ноября 2015 г.
- ^ «Как программное обеспечение для шифрования данных создает односторонние хэш-файлы с использованием алгоритма хеширования sha1» . www.metamorphosite.com . 12 ноября 2007 года . Проверено 1 ноября 2015 г.
- ^ «Понимание шифрования: симметричное, асимметричное и хеширование» . Атомный спин . 20 ноября 2014 года . Проверено 1 ноября 2015 г.
- ^ «PHP: Хеширование паролей — Руководство» . php.net . Проверено 1 ноября 2015 г.
- ^ «Реализация алгоритма криптографического хеширования SHA-256 на языке JavaScript | Сценарии подвижного типа» . www.movable-type.co.uk . Проверено 3 ноября 2015 г.
- ^ Перейти обратно: а б «Соль и перец — Как зашифровать пароли к базе данных» . blog.kablamo.org . Проверено 1 ноября 2015 г.
- ^ «PHP: Хеширование паролей — Руководство» . php.net . Проверено 1 ноября 2015 г.
- ^ «Почему вы всегда должны солить свои хэши — Веб-разработка в Брайтоне — Добавленные байты» . Добавлены байты . Проверено 1 ноября 2015 г.
- ^ Перейти обратно: а б «Блог ircmaxell: Правильная засолка паролей, аргументы против перца» . blog.ircmaxell.com . 17 апреля 2012 года . Проверено 2 ноября 2015 г.
- ^ Перейти обратно: а б «Шифрование приложений от Thales e-Security» . www.thales-esecurity.com . Архивировано из оригинала 24 февраля 2017 года . Проверено 25 октября 2015 г.
- ^ Пилянкевич Евгений (18 декабря 2020 г.). «Шифрование уровня приложения для архитекторов программного обеспечения» . ИнфоQ .
- ^ Перейти обратно: а б Баккам, Таня (апрель 2010 г.). «Прозрачное шифрование данных: новые технологии и лучшие практики шифрования баз данных» . Санс.орг . Институт САНС. Архивировано из оригинала 12 апреля 2018 года . Проверено 25 октября 2015 г.
- ^ «Шифрование баз данных: проблемы, риски и решения» . www.thales-esecurity.com . Архивировано из оригинала 24 февраля 2017 года . Проверено 25 октября 2015 г.