Закрытие доступа к строкам подключения баз данных и другим секретным параметрам в коде

Закрытие доступа к строкам подключения баз данных и другим секретным параметрам в коде

Защита секретов приложения, таких как строки подключения к базам данных и пароли, требует тщательного учета множества факторов, в том числе, насколько секретны данные, кто может получать к ним доступ, как сбалансировать защиту, производительность и удобство в работе и т. д. В этой статье объясняются основы защиты данных и сравниваются различные технологии, которые могут быть использованы для защиты параметров приложения. Рассказывается, чего следует избегать, например скрытия ключей в исходном коде и использования Local Security Authority. Кроме того, он представляет некоторые эффективные решения вроде Data Protection API.

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

1. скрытие (hiding),

2. управление доступом (access control);и

3. шифрование (encryption).

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

Будет рассказано об основах защиты данных и сравнении нескольких технологий, улучшающих управление конфиденциальными данными. Опишем ситуации, в которых эти технологии применимы, и случаи, где их следует избегать. Дадим ссылки на примеры кода, инструменты и API, которые помогут реализовать механизм защиты данных.

Скрытие данных

Скрытие данных (data hiding) иногда называют зашитой через затуманивание (security through obscurity). Полагаясь на этот способ, вы считаете, что только вам известно, где хранится секретная информация, и надеетесь, что никто другой не сможет это выяснить. Подвох в том, что приложение тоже должно знать, как получить доступ к данным, поэтому возможность сохранения секретов во многом зависит от способности приложения защищать это знание.

В число самых распространенных мест для скрытия секретных параметров приложения входят исходный код приложения, файлы конфигурации и реестр Windows. Данные можно хранить и в таких экзотических местах, как метабаза IIS (IIS metabase), UDL-файлы (Universal Data Link), файлы собственного формата — где угодно.

За редкими исключениями, простое скрытие данных обеспечивает в лучшем случае примитивную защиту. Как правило, объем работы, необходимой, чтобы хакер выяснил ваши секреты, минимален. Так, взломщик может обнаружить местоположение данных, отслеживая изменения в системе, выполняемые работающим приложением (рис. 1). Это можно сделать с помощью таких утилит, как regmon, filemon и diskmon от SysInternals (http://www.sysinternals.com).

Простота декомпиляции.NET-сборок представляет еще более серьезную угрозу. При помощи декомпиляторов вроде Anakrino (http://www.saurik.com/net/exemplar) или Salamander (http://www.remotesoft.com) код приложения может быть подвергнут обратному проектированию (reverse engineering), что приведет к раскрытию секретных данных или логики приложения (рис. 2).

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

Тип идентификации	Проблемы
Пользователь	Не срабатывает для приложений, выполняемых анонимно (например приложений ASP.NET) или под несколькими идентификациями. Данные должен задавать и считывать один и тот же пользователь. Позволяет несвязанным приложениям, выполняемым под одной и той же идентификацией пользователя, получать доступ к данным друг друга
Машина	Позволяет всем приложениям, выполняемым на одной машине, получать доступ к данным друг друга
Сборка	Данные должно задавать и считывать одно и то же приложение. Поддерживается только при защите по правам доступа кода (code access security) и в изолированных хранилища-

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Алгоритмы хэширования

Самые популярные алгоритмы хэширования — MD5 и SHA-1. Длина хэшей SHA-1 равна 160 битам, а длина хэшей MD5 — 128, Алгоритм SHA-1 чуть медленнее, но обеспечивает более высокую защиту, чем MD5. В дополнение к MD5 и SHA-1 NET Framework предлагает поддержку 256-, 384- и 512-битных версий алгоритма SHA, что еще надежнее, но, вероятно, и медленнее.

Простейший способ хэшировать данные — вызвать метод HashPasswordForStoringlnConfigFile класса FormsAuthentication, как в следующем примере:

using System.Web.Security;

 

string base64Hasn\'alue =

FormsAuthentlcatlon.HashPasswordForStoringlnConfigFileC'mypassword",

"shaT);

К сожалению, этот метод поддерживает только алгоритмы хэширования MD5 и SHA-1, так что, если вы хотите использовать хэши SHA-256, SHA-384 или SHA-512, вам придется писать чуть больше кода. Пример по ссылке http;//www.obviex.com/samples/hash,aspx поясняет, как создавать и сравнивать хэши с применением различных алгоритмов хэширования.

Шифровальные ключи

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

из открытого и закрытого ключей. Если вы не уверены, какой тип ключей выбрать, используйте симметричные ключи. Основной недостаток шифрования с открытым ключом — низкая производительность, которая может быть в 1000 раз меньше, чем при шифровании с симметричным ключом. Шифрование с открытым ключом также накладывает некоторые ограничения на размер текстовых данных, которые могут быть зашифрованы.

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

При выборе алгоритма шифрования имеет смысл выбрать самый надежный алгоритм с максимально длинным ключом. Самым надежным среди всех алгоритмов с симметричным ключом, поддерживаемых.NET Framework, считается одобренный правительством США алгоритм Rijndael (также известный как алгоритм Advanced Encryption Standard, или AES). Этот алгоритм поддерживает 128-, 192- и 256-битные ключи. Более подробную информацию о Rijndael см. в статье Джеймса Мак-Каффри в этом номере.

Алгоритм Rijndael обладает еще одним преимуществом по сравнению с другими алгоритмами с симметричным ключом, поддерживаемыми.NET Framework. Тогда как другие алгоритмы предлагаются в форме ≪тонких≫ классов-оболочек.NET Framework над имеющимися модулями CryptoAPI, Rijndael (реализованный как класс RijndaelManaged) написан полностью в управляемом коде. Замечу, что некоторые разработчики считают это недостатком и предпочитают использовать неуправляемую реализацию алгоритма Rijndael для большей производительности.

К сожалению, эта реализация алгоритма Rijndael поддерживается только в Windows XP и выше, а также в системах, где установлена.NET Framework. Если ваше приложение должно быть совместимо с неуправляемыми программами, работающими под Windows 2000 или ниже, используйте Triple DES — улучшенную версию менее защищенного алгоритма DES. Алгоритм Triple DES поддерживает ключи длиной в 112 и 168 бит, но рекомендуется использовать 168-битные ключи. Из-за разной трактовки битов четности (parity bits) ключа 168-битные ключи Triple DES иногда называют 192-битными. Если вы хотите предоставить управляемым и неуправляемым приложениям возможность зашифровывать или расшифровывать данные одинаковым ключом Triple DES, учтите, что кодовая фраза (или пароль), из которого формируется ключ, должна

содержать только печатаемые ASCII-символы; иначе сгенерированные

ключи не совпадут (вследствие ограничений.NET-реализации алгоритма Triple DES). Оригинальные алгоритмы DES, RC2 и RC4 в целом считаются менее стойкими, чем Rijndael и Triple DES, поэтому их следует избегать. Ни при каких обстоятельствах не используйте доморощенный алгоритм шифрования. Не воображайте, что никто не сумеет его взломать.

На рис. 6 показаны различные схемы шифрования данных, которые вы можете задействовать.

Берегитесь LSA

Во времена расцвета Windows NT 4.0 функции LSA Policy LsaStore PrivateData и LsaRetrieve Private Data предоставляли достаточно надежный способ защиты секретов приложения. Хотя функции LSA Policy доступны в Windows 2000 и выше (и по-прежнему используются для защиты таких данных, как пароли для служб Windows), Microsoft не рекомендует применять их, поэтому я упомянул эти функции лишь для полноты картины,

чтобы объяснить, почему их следует избегать. Проблема с функциями LSA Policy в том, что они не только управляют ключами и шифруют их, но и работают с хранилищами данных, используя защищенную область реестра Windows. Может показаться, что это хорошо, но это не так, потому что объем доступного места для функций LSA Policy ограничен 4096 слотами, половина из которых уже занята системой. Если приложения будут использовать LSA Policy для хранения секретных данных, им просто не хватит места. Далее, поскольку лишь в высшей степени привилегированные пользователи могут вызывать функции LSA Policy, они не сработают для приложений, выполняемых под непривилегированными учетными записями, такими как ASP.NET. Хуже того, существуют инструменты вроде LSADUMP2 (http://razor.bindview.com/tools/desc/Isadump2_readme.html), способные раскрыть секреты LSA. Вывод: не применяйте функции LSA Policy для защиты данных.

Использование DPAPI

Как альтернативу функциям LSA Policy компания Microsoft рекомендует применять подмножество Crypto API, которое называется DPAPI. DPAPI включает две функции, пригодные для защиты данных: CryptProtectData и CryptUnprotectData. Эти функции реализованы в crypt32.dll и могут вызываться из приложений.NET Framework через P/Invoke. DPAPI является частью операционной системы и доступен в Windows 2000 и выше.

DPAPI — в отличие от функций LSA — не работает с хранилищами данных, но способен создавать индивидуальные для машины или пользователя ключи для шифрования и расшифровки данных. Чтобы различать два типа ключей, в документации DPAPI их называют хранилищем машины (machine store) и хранилищем пользователя (user store).

Ключи, специфичные для машины, в общем небезопасны, поскольку могут быть использованы любым, кто получает доступ к системе. Можно сгенерировать более защищенную версию такого ключа, передав функции DPAPI пароль (также называемый вторичной энтропией). Этот вариант лучше, поскольку он требует от вызвавшего кода знания этого пароля, но создает трудности с хранением пароля, что возвращает нас к исходной проблеме. Другая проблема с ключами, специфичными для машины, в отсутствии гарантий того, что они останутся такими же при изменениях в среде. Такие изменения, как перенос приложения на другой компьютер или перекомпиляция системы, способны разрушить приложение, использующее DPAPI с ключами, специфичными для машины.

Хотя ключи, специфичные для пользователя, считаются более безопасными, им свойственны те же ограничения, что и всем другим видам управления доступом на основе идентификации. Во-первых, поскольку эти ключи могут генерироваться только программами, выполняемыми с загружаемыми профилями пользователей, они не сработают в приложениях ASP.NET и в приложениях, выполняемых под определенными встроенными учетными записями,

Хотя существует' способ обойти эти ограничения через обслуживаемые компоненты (serviced components), расплатой за него станет рост сложности и снижение производительности приложения. Этот способ также требует, чтобы обслуживаемый компонент выполнялся под привилегированной учетной записью, что нарушает принцип наименьшей привилегии. Если вы решите использовать DPAPI с ключами для пользователей, учтите, что только пользователь, зашифровавший данные, сможет расшифровать результат. Очевидно, это неприемлемо для приложений, выполняемых под разными учетными записями, или для программ, чьи параметры могут определяться разными пользователями. Другая проблема ключей, специфичных для пользователей, в том, что они позволяют всем приложениям, выполняемым в одном профиле пользователя, получать доступ к данным /[руг друга, что может стать брешью в защите. Как и в случае с DPAPI, использующим хранилища машины, эту проблему можно решить, требуя от вызвавшего кода предоставить вторичную энтропию, но, как и в предыдущем примере, возникнет проблема с хранением этой энтропии. К сожалению, DPAPI не позволяет одновременно использовать ключи, специфичныедля машины и специфичные для пользователя (в одном вызове CryptProtectData).

DPAPI рекомендуется для приложений, которые выполняются под одной учетной записью с загружаемым профилем пользователя, и чьи параметры определяются одним пользователем. (Более подробную информацию см. во врезке ≪Загружаемый профиль пользователя≫.) Типичный пример — служба Windows, выполняемая под учетной записью локального или доменного пользователя. Если ваше приложение удовлетворяет этим требованиям, ему следует задействовать DPAPI с ключами, специфичными для пользователей. В других приложениях можно использовать DPAPI с ключами, специфичными для машины и защищенными вторичной энтропией (см. http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetHTOS.asp и http://www.obviex.com/samples/dpapi.aspx). Вы можете определить эту энтропию в исходном коде приложения и затемнить двоичный файл приложения, чтобы обнаружить энтропию было непросто. Но если вы изберете такой способ, учтите, что даже затемненный код может.быть подвергнут обратному проектированию. Чтобы узнать, что может и чего не может предложить вам затемнение, прочтите статью Брента Ректора (Brent Rector) ≪The Premier Obfuscator for Microsoft.NET Applications!≫ по ссылке http://www.wintellect.com/resources/newsletters/2002/aug2002.aspx и статью Габриэла Торока (Gabriel Torok) и Билла Лича(Bill Leach) в этом номере.

Загружаемый профиль пользователя

Хотя в документации Microsoft одним из требований к приложению, в котором применяется DPAPI с хранилищем пользователя, указан загружаемый профиль пользователя, там не объясняется, что это такое. Если вы озадачены этим термином, считайте, что это профиль интерактивного пользователя, который создается, когда пользователь впервые регистрируется в системе. Все приложения, интерактивно запущенные пользователем, выполняются с загруженным профилем интерактивного пользователя. Неинтерактивные приложения, такие как службы Windows, настроенные на выполнение под LocalSystem, не могут загружать профиль пользователя и, таким образом, не в состоянии задействовать DPAPI с хранилищем пользователя. То же можно сказать и о системных процессах, таких как процессы ASP.NET, которые выполняются под встроенными учетными записями. Чтобы позволить службам Windows обращаться к DPAPI с хранилищем пользователя, их следует настроить на выполнение под учетными записями локальных или доменных пользователей с уже созданным профилем. На практике это означает, что до того, как приложение сможет выполнять вызовы DPAPI от имени пользователя, тот должен хотя бы один раз интерактивно войти в систему.

Если ваше приложение не может напрямую использовать DPAPI с ключами, специфичными для пользователей, а вы не хотите примириться с угрозой обратного проектирования, подумайте о реализации DPAPI с обслуживаемым компонентом, но учтите, что это негативно отразится на производительности вашего приложения [см. ≪Use DPAPI (User Store) from

Если вы определяете ключ в приложении, то, кроме затемнения сборки, старайтесь не хранить реальные байты ключа в исходном коде. Вместо этого реализуйте логику генерации ключа на основе постоянных характеристик, таких как алгоритм шифрования, размер ключа, кодовая фраза, инициализирующий вектор, и ≪расширение≫ (см. пример по ссылке http://www.obviex.com/samples/encryption.asp). Это внесет дополнительный уровень неопределенности, и ключ не удастся получить простым дампом символов из двоичного файла сборки. Так как логика генерации ключа и его характеристики постоянны, неизменность результирующего ключа гарантирована. Также хорошей идеей будет отказ от использования статических строк в качестве характеристик для генерирования ключа и их создание ≪на лету≫. Еще можно предложить рассматривать сборку так же, как хранилище данных, т. е. применять соответствующие ACL. И прибегайте к этому варианту лишь в качестве крайней меры, когда никакая другая технология защиты данных неприменима и единственной альтернативой остается хранение секретных данных в незашифрованном виде.

Изолированное хранилище

Иногда изолированное хранилище упоминается как метод защиты данных. Оно позволяет ограничить доступ к данным сборки приложения. Хотя такой вариант может быть полезен, изолированное хранилище не рекомендуется для защиты секретных данных, поскольку в нем не используется шифрование; оно лучше подходит для хранения индивидуальных пользовательских параметров приложения. Для хранения секретных пользовательских данных в приложении используйте DPAPI совместно с изолированным хранилищем.

Заключение

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

Закрытие доступа к строкам подключения баз данных и другим секретным параметрам в коде

Защита секретов приложения, таких как строки подключения к базам данных и пароли, требует тщательного учета множества факторов, в том числе, насколько секретны данные, кто может получать к ним доступ, как сбалансировать защиту, производительность и удобство в работе и т. д. В этой статье объясняются основы защиты данных и сравниваются различные технологии, которые могут быть использованы для защиты параметров приложения. Рассказывается, чего следует избегать, например скрытия ключей в исходном коде и использования Local Security Authority. Кроме того, он представляет некоторые эффективные решения вроде Data Protection API.

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

1. скрытие (hiding),

2. управление доступом (access control);и

3. шифрование (encryption).

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

Будет рассказано об основах защиты данных и сравнении нескольких технологий, улучшающих управление конфиденциальными данными. Опишем ситуации, в которых эти технологии применимы, и случаи, где их следует избегать. Дадим ссылки на примеры кода, инструменты и API, которые помогут реализовать механизм защиты данных.

Скрытие данных

Скрытие данных (data hiding) иногда называют зашитой через затуманивание (security through obscurity). Полагаясь на этот способ, вы считаете, что только вам известно, где хранится секретная информация, и надеетесь, что никто другой не сможет это выяснить. Подвох в том, что приложение тоже должно знать, как получить доступ к данным, поэтому возможность сохранения секретов во многом зависит от способности приложения защищать это знание.

В число самых распространенных мест для скрытия секретных параметров приложения входят исходный код приложения, файлы конфигурации и реестр Windows. Данные можно хранить и в таких экзотических местах, как метабаза IIS (IIS metabase), UDL-файлы (Universal Data Link), файлы собственного формата — где угодно.

За редкими исключениями, простое скрытие данных обеспечивает в лучшем случае примитивную защиту. Как правило, объем работы, необходимой, чтобы хакер выяснил ваши секреты, минимален. Так, взломщик может обнаружить местоположение данных, отслеживая изменения в системе, выполняемые работающим приложением (рис. 1). Это можно сделать с помощью таких утилит, как regmon, filemon и diskmon от SysInternals (http://www.sysinternals.com).

Простота декомпиляции.NET-сборок представляет еще более серьезную угрозу. При помощи декомпиляторов вроде Anakrino (http://www.saurik.com/net/exemplar) или Salamander (http://www.remotesoft.com) код приложения может быть подвергнут обратному проектированию (reverse engineering), что приведет к раскрытию секретных данных или логики приложения (рис. 2).