Сегодня широко используется хранение и обработка данных на сторонних удаленных облачных серверах, демонстрируя взрывной рост [ 1 ]. Однако по мере увеличения масштаба, ценности и централизации данных выявляется обратная сторона этого процесса — обостряются проблемы обеспечения безопасности и конфиденциальности данных, что вызывает серьезное беспокойство у владельцев и пользователей данных. Существует выявленный риск того, что данные, хранящиеся в базах данных, могут быть скомпрометированы [ 2 ], и это соответствует различным международным законам и стандартам, таким как: Общий регламент по защите данных (GDPR [ 3 ], Стандарт безопасности данных индустрии платежных карт (PCI DSS) ) [ 4 ], Закон о переносимости и подотчетности медицинского страхования (HIPAA) [ 5 ] и некоторые другие не могут быть разрешены. Владелец данных должен быть уверен, что данные, хранящиеся на сторонних удаленных серверах поставщика услуг, не могут быть разрешены. Кроме того, эти данные должны быть защищены даже от самого поставщика услуг (действительного пользователя, известного как инсайдер), если соответствующему поставщику нельзя доверять.

Как известно, одним из принципиальных решений этой проблемы является использование соответствующих криптографических методов и примитивов. Шифрование — это стандартный подход к обеспечению конфиденциальности данных, который передается на аутсорсинг так называемым «честным, но любопытным» облачным серверам. Шифрование делает невозможным доступ к данным как инсайдерам, так и посторонним, не зная ключей. Однако у шифрования есть и обратная сторона. Прямое использование традиционных подходов к шифрованию/дешифрованию данных в большинстве случаев затрудняет выполнение операций поиска в зашифрованных данных [ 6 , 7 , 8 ]. Простое решение этой проблемы — скачать весь набор данных соответствующего хранилища, затем расшифровать его локально и искать нужные данные. Такой подход создает серьезные проблемы с производительностью, которые сводят на нет преимущества аутсорсинга и делают его неприемлемым для большинства приложений. Другой метод позволяет серверу расшифровать данные, выполнить запрос на стороне сервера и отправить пользователю только результаты. Однако в этом случае уровень безопасности снижается, поскольку данные, защищенные шифрованием, потенциально могут стать доступными поставщику услуг (привилегированному пользователю). Поэтому желательно поддерживать максимально полную функциональность поиска на стороне сервера с минимально возможной потерей конфиденциальности данных. В частности, безопасная поисковая система должна быть направлена ​​на то, чтобы поставщик услуг ничего не узнал о данных, хранящихся в защищенной базе данных, или о запросах, а запрашивающий соответствующие данные (запрашивающий) ничего не узнал, кроме результатов запроса. [ 2 ].

Проблема поиска данных в зашифрованных базах данных вызвала большой интерес как в научном сообществе, так и в промышленности [ 9 ]. Для решения проблемы обеспечения поиска в криптозащищенных базах данных были проведены соответствующие исследования, связанные с разработкой новых криптографических примитивов, новых структур данных для поискового шифрования, а также развитием взглядов на безопасность [6 , 10 ] . Доступные сегодня решения для поиска зашифрованных данных сочетают в себе нетривиальные идеи из криптографии, из основных положений теории алгоритмов и структур данных, поиска информации и баз данных [2 , 6 , 11 ] . Однако, несмотря на большое разнообразие предлагаемых вариантов, не существует доминирующего решения для всех случаев использования. Цель плана безопасности, по мнению Андресса [ 12 ], — найти баланс между защитой, удобством использования и стоимостью. Аналогичных взглядов придерживаются Fuller et al. [ 2 ], которые считают, что проектирование защищенной поисковой системы — это баланс между безопасностью, функциональностью, производительностью и удобством использования. Поэтому владельцам данных и пользователям важно понимать, какой довольно широкий спектр безопасных систем баз данных предлагается для их различных приложений и какие компромиссы приемлемы для каждого конкретного варианта использования. Все это стимулировало исследования в области безопасного управления данными и повысило их актуальность.

Безопасность, как известно, связана с информацией, которая в ходе работы поисковых схем шифрования раскрывается или попадает к злоумышленнику, имеющему доступ к серверу базы данных. Бёш и др. [ 6 ] считают, что в таких схемах возможна утечка информации, которую можно разделить на три группы:

(а)

индексная информация (относится к информации о ключевых словах, содержащихся в индексе);

(б)

шаблон поиска (информация, которую можно получить, зная, относятся ли два результата поиска к одному и тому же ключевому слову);

(с)

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

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

Фуллер и др. [ 2 ] различают два типа объектов, которые могут представлять угрозу безопасности базы данных: действительный пользователь, известный как инсайдер, выполняющий одну или несколько ролей, и аутсайдер. Последний может отслеживать и потенциально изменять сетевое взаимодействие между действительными пользователями, разделяя злоумышленников на тех, кто сохраняется в течение всего срока службы базы данных, и тех, кто получает снимок в один момент времени. При этом злоумышленники делятся на тех, кто сохраняется на протяжении всего времени жизни базы данных и тех, кто получает снимок в один конкретный момент времени [ 15 ]. Кроме того, Фуллер и др. [ 2 ] различают злоумышленников на: получестных (или честных, но любопытных), т. е. тех, кто следует установленным протоколам, но может попытаться получить дополнительную информацию из данных, которые они наблюдают; и вредоносные, то есть те, которые активно совершают действия, направленные на получение дополнительной информации или влияние на работу системы. Они также отмечают, что большая часть активных исследований в области технологий защищенного поиска рассматривает получестную защиту от постоянного внутреннего злоумышленника. При этом особое внимание уделяется таким типам объектов внутри защищенной поисковой системы, которые уязвимы к утечкам, как: (а) элементы данных и любые индексирующие структуры данных; (б) запросы; (c) записи, возвращаемые в ответ на запросы или другие связи между элементами данных и запросами; (г) правила контроля доступа и результаты их применения.

Криптографическое сообщество разработало несколько общих примитивов:

−

полностью гомоморфное шифрование [ 16 , 17 , 18 , 19 ],

−

функциональное шифрование [ 20 , 21 ] с его подклассами и более ранними представителями:

−

шифрование предикатов [ 22 , 23 ],

−

шифрование на основе личности [ 24 ],

−

шифрование на основе атрибутов [ 25 ]

и некоторые другие, полностью или частично решающие проблему поиска в защищенной базе данных. Методы защищенного поиска часто основаны на этих примитивах, но редко полагаются исключительно на один из них. Вместо этого они склонны использовать специализированные протоколы, часто с некоторой утечкой для повышения производительности [ 2 ].

Один из возможных подходов к уменьшению ущерба, вызванного взломом сервера, — это зашифровать конфиденциальные данные и запустить все вычисления (логику приложения) на клиентах. Однако, как отмечают Попа и др. [ 26 ] некоторые важные приложения не подходят для этого подхода. Например, веб-сайты на основе баз данных, которые обрабатывают запросы для создания данных для пользователя, и приложения, вычисляющие большие объемы данных. Другой возможный подход – использование такого теоретического решения, как полностью гомоморфное шифрование (FHE) [ 16 , 17 , 18 , 19 ]. Его использование позволяет серверам выполнять произвольные функции над зашифрованными данными, в то время как расшифрованные данные видят только клиенты. Однако одной из проблем схем с полностью гомоморфным шифрованием является производительность, поскольку современные схемы требуют больших вычислительных ресурсов и больших затрат на хранение данных [ 6 , 26 ]. Для некоторых приложений могут использоваться так называемые несколько гомоморфные схемы шифрования. Эти схемы более эффективны, чем FHE, но допускают только определенное количество сложений и умножений [ 16 , 18 ]. Основная проблема при использовании частично или полностью гомоморфного шифрования заключается в том, что полученные схемы поиска требуют линейного времени поиска по длине набора данных, а это слишком медленно для практического использования в современных приложениях.

Как отмечалось ранее, проблема поиска зашифрованных данных представляет большой интерес как с теоретической, так и с практической точки зрения. Это объясняется важностью обеспечения безопасности и конфиденциальности данных, хранящихся и обрабатываемых на сторонних удаленных облачных серверах поставщика услуг. Однако, как отмечают некоторые эксперты в этой области [ 9 , 27 ], исследования по этой теме больше ориентированы на сценарий пользователя, который передает на аутсорсинг зашифрованный набор документов (например, электронные письма или медицинские записи) и хотел бы продолжить поиск по ключевым словам в этом зашифрованном наборе данных. Однако на практике многие компании, организации и учреждения хранят данные в базах данных, использующих реляционную модель данных. Пользователи привыкли использовать широко распространенный SQL, который позволяет им удобно хранить, запрашивать и обновлять данные. Базы данных, поддерживающие SQL (это относится в целом как к NewSQL, так и к некоторым базам данных NoSQL, которые также позволяют работать в парадигме SQL-запросов), обеспечивают быстрый поиск и извлечение записей при условии, что база данных может считывать содержимое данных. Однако шифрование затрудняет поиск в зашифрованных базах данных. Поэтому непосредственное применение решений для поиска необходимой информации в зашифрованных данных традиционных баз данных является непростой задачей.

Чтобы решить определенные проблемы, Хаджигюмюш и др. [ 28 ] разработали методы, с помощью которых основная часть работы по выполнению SQL-запросов может выполняться поставщиком услуг без необходимости расшифровки хранимых данных. В статье исследуется алгебраическая структура разделения запросов для минимизации вычислений на стороне клиента. Использование так называемого «грубого индекса» позволяет частично выполнить SQL-запрос на стороне провайдера. Результат этого запроса отправляется клиенту. Окончательный правильный результат запроса находится путем расшифровки данных и выполнения запроса компенсации на стороне клиента.

Попа и др. [ 26 ] предложил систему под названием CryptDB, которая поддерживает запросы SQL к зашифрованным данным. Это решение основано на различных типах шифрования, таких как случайное (RND), детерминированное (DET) и шифрование с сохранением порядка (OPE), применяемое к столбцу таблицы SQL. Чтобы запросить данные из зашифрованной базы данных, CryptDB преобразует незашифрованный запрос SQL в его зашифрованный эквивалент и расшифровывает соответствующие уровни шифрования. CryptDB достигает своих целей, используя три идеи: выполнение запросов к зашифрованным данным с использованием новой стратегии шифрования с поддержкой SQL, динамическую настройку уровня шифрования с помощью луковицы шифрования для минимизации информации, раскрываемой ненадежному серверу СУБД, и связывание ключей шифрования с паролями пользователей в таким образом, что только авторизованные пользователи могут получить доступ к зашифрованным данным. При этом CryptDB хоть и защищает конфиденциальность данных, но не гарантирует целостность, актуальность и полноту результатов, возвращаемых приложению. Однако основной недостаток CryptDB, как отмечают Azraoui et al. [ 9 ] заключается в том, что всякий раз, когда удаляется один уровень, схема шифрования становится слабой. В свете этого основная проблема состоит в том, чтобы предоставить практическое решение для поиска в зашифрованных базах данных, которое не страдает от утечек, происходящих в CryptDB, и которое обеспечивает прозрачную обработку сложных запросов к зашифрованным базам данных SQL. В своей статье [ 9 ] авторы пытаются решить эту проблему, предлагая практическую конструкцию поиска данных в зашифрованных базах данных SQL, ограничивающую утечку информации. Их решение основано на методе шифрования с возможностью поиска, разработанном Куртмолой и др. [ 29 ] и применяется к неструктурированным документам. Этот механизм создает инвертированный индекс поиска ключевых слов в базе данных, чтобы обеспечить возможность выполнения запросов поиска по ключевым словам по зашифрованным данным. Практичность данного решения достигается за счет использования техники хеширования кукушки, что делает поиск по индексу эффективным. Предлагаемое решение поддерживает логические запросы и запросы по диапазонам.

Пилянкевич и др. [ 27 ] предлагают систему (названную Acra), которая позволяет, среди прочего, обеспечивать поиск зашифрованных данных в базах данных SQL. Предлагаемое решение Acra Searchable Encryption (Acra SE) основано на подходе слепого индексирования, который развивает оригинальную идею проекта CipherSweet [ 30 ]. Основным компонентом схемы Acra SE является так называемый Acra Server, который работает как обратный прокси (прокси-сервер прозрачного шифрования/дешифрования). Он находится между приложением и базой данных. Приложение не знает, что данные зашифрованы до того, как попадут в базу данных, база данных не знает, что кто-то зашифровал данные. Стоит отметить, что функции шифрования и безопасного поиска Acra Server можно настроить для каждого столбца. Это означает, что каждая таблица в базе данных может быть полностью зашифрована (каждый столбец), частично зашифрована (некоторые столбцы зашифрованы, некоторые нет) или полностью незашифрована. Все свойства безопасности шифрования Acra с возможностью поиска очень похожи на свойства безопасности CipherSweet, что создает риск атак с частично известным открытым текстом. В связи с этим Пилянкевич и др. [ 27 ] дают практические рекомендации по обеспечению безопасности. Однако, несмотря на определенные решения, направленные на обеспечение безопасности хранения и поиска конфиденциальных данных, Acra, как и CipherSweet, взятый за прототип схемы шифрования с возможностью поиска, поддерживает минимальную функциональность запросов, а именно только на равенство.

Для различных СУБД характерна так называемая технология «прозрачного шифрования данных» (TDI) [ 31 ], которая позволяет выборочно шифровать конфиденциальные данные, хранящиеся в файлах базы данных, а также в файлах, связанных с восстановлением данных, например журналах повторного выполнения. , архивные журналы, резервные ленты. Суть прозрачного шифрования заключается в том, что используется комбинация двух ключей: ключ для каждой таблицы базы данных, который уникален, главный ключ, который хранится вне базы данных в так называемом «кошельке». Данные, хранящиеся на диске, зашифрованы; однако они автоматически расшифровываются, чтобы законный пользователь мог обрабатывать запросы. То есть, когда пользователь выбирает зашифрованные столбцы, СУБД незаметно извлекает ключ из «кошелька», расшифровывает столбцы и показывает их пользователю. В результате сервер должен иметь доступ к ключам расшифровки, а злоумышленник, скомпрометировавший программное обеспечение СУБД, может получить доступ ко всем данным. Поэтому основная цель TDE — защитить конфиденциальные данные, находящиеся в соответствующих файлах операционной системы. TDE не является полноценной системой шифрования, и ее не следует использовать в этом качестве.

Кроме того, следует обратить внимание на то, что возможность выполнения поисковых операций над зашифрованными базами данных приводит к усложнению систем и увеличению объема необходимой памяти и времени выполнения запросов. При этом некоторые схемы поискового шифрования при выполнении определенных запросов не обеспечивают достаточной конфиденциальности данных. То есть при длительном наблюдении злоумышленник может получить значительную часть информации о конфиденциальных данных. Все это свидетельствует об открытости проблемы безопасного поиска и необходимости дальнейших исследований в этом направлении для обеспечения безопасной работы с удаленными базами данных и хранилищами данных.