О защите данных в облаках
За последние несколько лет участились случаи утечек личных данных граждан (утечки из банковских, медицинских, а также баз данных сотовых операторов). Очередной скандал с утечкой разгорелся теперь уже в ПриватБанке. Персональные данные продают всего по $50 за CD.
Одновременно с этим наметилась тенденция все более широкого использования облачных вычислений среди организаций в надежде на то, что такие меры помогут уберечь данные от утечек. Однако важно понимать, что реальной защиты от действий умелых и опытных администраторов СУБД как в закрытой корпоративной сети, так и в облаках, во встроенных средствах современных и широко распространенных СУБД просто не существует.
Известные утечки информации из баз данных (БД), содержащих персональные данные граждан, как правило, связаны с действиями инсайдеров и, прежде всего, администраторов баз данных. Для БД известны следующие основные функции защиты информации:
- защита доступа – доступ к данным пользователь получает только при успешном прохождении им процедур идентификации и аутентификации;
- разграничение доступа — каждый пользователь, включая администратора, имеет доступ только к необходимой ему информации, согласно занимаемой должности;
- шифрование данных — шифровать необходимо как передаваемые в сети данные для защиты от перехвата, так и данные, записываемые на носитель, для защиты от кражи носителя и несанкционированного просмотра/изменения нештатными средствами СУБД;
- аудит доступа к данным — действия с критичными данными должны протоколироваться. Доступ к журналу не должны иметь пользователи, на которых он ведется.
Последние версии международных стандартов ИСО для защиты данных, хранящихся и обрабатываемых в логической структуре реляционных таблиц на серверах баз данных в облачной инфраструктуре, прямо рекомендуют:
- использование строгой аутентификации в системах управления доступом пользователей к данным;
- методы криптографической защиты для шифрования данных, хранящихся в облаках.
Сначала поясним, что такое «строгая аутентификация». К такому шагу вынуждает множество появляющихся в последние пару лет толкований понятий «многофакторной аутентификации», особенно среди сторонников биометрических методов распознавания личности. Раньше я терпеливо объяснял, что строгая аутентификация должна быть обязательно взаимной (аутентифицируются обе стороны – субъект и объект доступа), многофакторной (факторы должны быть разной природы и использоваться одновременно) с применением строгих криптографических алгоритмов. Теперь, после вступления в действие ГОСТ Р 58833 «Идентификация и аутентификация. Общие положения» мне не надо тратить много усилий на переубеждение оппонентов.
Кстати, это рекомендуется сделать сотрудникам банков и организаций других сфер деятельности, которым навязываются решения «удаленной многофакторной идентификации», которой тоже нет ни в международных стандартах, ни в системе национальных стандартов системы ГОСТ Р в части управления логическим доступом к информационным ресурсам и системам. Факторов может быть только три: знание, владение и биометрия. Сколько бы разновидностей биометрических характеристик ни снималось с одного субъекта, это все равно один фактор. Более того, последовательное использование различных факторов только понижает надежность идентификации.
Что касается хранения, обработки и шифрования данных, то традиционно защита информации в базах данных была достаточно сложной задачей. Это связано и с особенностями работы с данными, и с проблемами производительности, и с вопросами доверия к привилегированным пользователям – администраторам баз данных. Решение такой задачи с учетом совокупности всех факторов весьма сложно, с учетом того, что ею предпочитали не заниматься, объявляя администратора базы данных доверенной персоной и полагаясь на встроенные механизмы защиты СУБД. Подобный подход вкупе с накоплением огромных объемов конфиденциальной информации обернулись периодическими скандалами разглашения персональных и иных конфиденциальных данных, а также умышленного искажения информации.
Все вышеперечисленные задачи решает сертифицированное по классу КС3 требований ФСБ России решение по криптографической защите данных разработки компании "Аладдин Р.Д.". СКЗИ "Крипто БД" используется в ряде крупных организаций, применяется в существующих прикладных системах практически без их переделки. Для существенного снижения рисков бесконтрольных утечек данных владелец ИС вводит новую роль, которую может выполнять один человек. Роль администратора безопасности подразумевает управление и распределение ключей шифрования, при этом у самого администратора безопасности доступа к данным не предусмотрено. Администраторы СУБД выполняют все свои обязанности без доступа к ключу шифрования, а легальным пользователям ключи шифрования распределяются в зашифрованном на их открытых ключах виде. Для пользователей внедрение проходит незаметно, поскольку криптографические преобразования информации, с которой они работают, как правило, незначительно (незаметно для человеческого глаза) замедляют основные процессы.
Для защиты от неправомерных действий администратора СУБД в решении предполагается отсутствие предоставления доступа администраторам к информации при одновременном полном доступе к структурам хранения данных. Доступ всех легальных пользователей дополнительно персонифицируется системой распределения ключей шифрования и контролируется с помощью ведения аудита событий доступа к защищённой информации с помощью специально разработанной (не предоставленной разработчиком СУБД) процедуры аудита. Доступ к журналу аудита предоставляется доверенным сотрудникам с правами администратора безопасности.
Управление ключевым материалом для процессов зашифрования и расшифрования должно производиться не в «облаках», а внутри защищенного периметра организации. Также весьма непростой задачей, имеющей красивое решение на базе инфраструктуры открытых ключей, является распределение ключей шифрования. Это важно и полностью соответствует требованиям ФСБ России.
Алексей САБАНОВ,
заместитель генерального директора компании «Аладдин Р.Д.»
Опубликовано 22.05.2020