Ограничение доступа к данным

Если доступ к данным ограничен, скрывать их местоположение не нужно. При таком подходе вы полагаетесь на технологические функции, встроенные в операционную систему и способные предотвратить несанкционированный доступ к данным. Обычно ограничения доступа базируются на идентификации вызвавшего (caller's identity) или знании общего секрета (рис. 3). Этот способ защиты данных используют Access Control Lists (ACL), Microsoft Data Protection API (DPAPI) и изолированные хранилища.

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

Например, управление доступом на основе идентификации пользователя

ненадежно для приложений, выполняемых анонимно или в контекстах разных пользователей. Другая проблема управления доступом на основе идентификации заключается в неспособности предотвратить доступ разных приложений, выполняемых под одной идентификацией, к данным друг друга. Типичные проблемы, связанные с управлением доступом на основе идентификации, приведены в табл. 1.

Табл. 1. Проблемы управления доступом на основе идентификации

С другой стороны, когда управление доступом основывается на знании секрета, проблемой становится защита этого секрета. Дополнительные сложности, связанные с ограниченным доступом, зависят от конкретной реализации. Например, в крупной корпоративной среде может быть затруднено управление ACL-списками, а защищенное хранилище может потребовать административных привилегий со стороны вызвавшего, нарушая тем самым правило наименьшей привилегии

Шифрование данных

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

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

Выбирая или создавая механизм защиты данных, взвесьте его уязвимость перед потенциальными угрозами. Такая оценка может оказаться проще, ес- ли мыслить в категориях основных технологий зашиты данных, описанных выше. Например, если вы храните информацию для подключения к базе данных, содержащую SQL-удостоверения пользователя в UDL-файле (рис. 5), безопасность ваших данных сильно зависит от разрешений для файла (ACL-списков), которые являются одной из форм ограничения доступа. (В какой-то мере она зависит и от скрытия данных, но в данном конкретном случае скрытие данных — очень слабая защита, поскольку тре- буется немного усилий, чтобы найти UDL-файл.) Хотя ACL-списки иг- рают важную роль в защите данных, важно понимать, что, если хакер су- меет получить доступ к UDL-файлу для чтения, ваши SQL-удостоверения будут раскрыты. Если речь не идет о ситуации, когда потенциальная угроза слишком мала или ваши данные не слишком важны, избегайте решений на основе лишь одной технологии защиты данных. Чем больше технологий задействовано в решении, тем оно надежнее.

Оценка вариантов

По мнению многих экспертов по безопасности, лучший способ защиты секретов — вовсе не использовать их. Например, если вам нужно защитить строки подключения к базе данных, содержащие SQL-удостоверения, подумайте об отказе от SQL-аутентификации. Если ваше приложение способно для подключения к серверу баз данных применять Windows-аутентификацию вместо SQL-аутентификации, вам вообще не нужно будет беспокоиться о защите SQL-удостоверений.

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

§ Насколько ценной является защищаемая информация? Какого ущерба можно ожидать, если защита данных будет скомпрометирована?

§ От каких пользователей вы защищаете данные? От сотрудников, которые любят заглянуть в информацию, для них не предназначенную, но которые не станут преднамеренно атаковать систему? Или от целеустремленных хакеров, которые готовы потратить время, силы и деньги, чтобы скомпрометировать систему? Насколько далеко, по-вашему, может зайти потенциальныйхакер, чтобы получить ваши данные?

§ Так ли необходимо вашему приложению работать с секретными данными в расшифрованном виде?

§ Вы защищаете только строки подключения к базам данных или данные и другого типа?

§ Сколько идентификаций использует приложение, получающее доступк вашим данным? Оно выполняется под одной идентификацией или несколькими?

§ Какие версии операционных систем должно поддерживать приложение?

§ Что вам важнее; производительность приложения или безопасность? Готовы ли вы пожертвовать производительностью ради большей безопасности?

§ Каков механизм определения данных? Это выполняется вручную, например с помощью текстового редактора, или программно? Если данные создаются программно, параметры приложения определяются из того приложения, которое их использует, или из другого приложения?

§ Сколько приложений в вашей организации или компании используют защиту данных? Если их больше одного, все ли они предъявляют одинаковые требования? Хотите ли вы применить единое решение, удовлетворяющее требованиям всех приложений, или предпочитаете разные механизмы защиты данных для каждого приложения?

§ Насколько сложно обслуживающему персоналу будет работать с защитой приложения после его развертывания? Согласна ли группа технической поддержки с вашим решением? В зависимости от ответов на эти вопросы можно выбрать тот или иной подход. Ниже в этой статье я представлю обзор нескольких технологий защиты данных, применимых в наиболее распространенных типах приложений, но сначала обрисую варианты, которых следует избегать при любых обстоятельствах.

Все способы хранения секретных данных в открытом виде считаютсяненадежными, поскольку раскрывают данные любому, кто получит доступ к их источнику, — задача, которая может оказаться проще, чем кажется. Следует избегать хранения незашифрованных данных в реестре Windows, конфигурационных файлах, каталогах СОМ+, изолированных хранилищах, файлах собственных форматов, метабазе IIS и UDL-файлах. Более того, вообще никогда не храните секретные данные в открытом виде.

Достичь абсолютной защиты нельзя, но получить ее приемлемый уровень — безусловно возможно. Некоторым приложениям нужна защита, требующая сложных и неординарных решений, особенно в таких областях, как банковская деятельность, оборона и закрытые научные исследования. Однако в большинстве случаев используется три этапа: шифрование данных, ограничение доступа к зашифрованным данным с помощью ACL-списков, а также скрытие и ограничение доступа к шифровальным ключам.

Реализуя защиту данных, можно принять во взимание и другие аспекты защиты, например предотвращение несанкционированной модификации данных (data tampering), но поскольку это не относится к секретности, я не стану рассказывать о таких аспектах в своей статье. Вместо этого я затрону более практичные темы: где хранить зашифрованные данные, какой тип алгоритмов шифрования использовать и как защитить криптографические ключи.