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