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

Родственные грехи

Совсем несложно полностью игнорировать вопросы безопасности в сети. Но не менее просто воспользоваться сервисами безопасности неправильно, особенно это относится к протоколам Secure Sockets Layer и Transport Layer Security (SSL / TLS) (Грех 10). Аутентификация тоже является важной частью инфраструктуры сетевой безопасности и также нередко становится точкой отказа (см., например, грехи 11, 15 и 17). Для обеспечения конфиденциальности нужен криптографически сильный алгоритм генерирования случайных чисел (грех 18).

Этот грех обычно проявляется, когда:

□ приложение пользуется сетью;

□ проектировщик не обращает внимания на риски, связанные с работой в сети, или недооценивает их.

Например, типичный аргумент звучит так: «мы ожидаем, что этот порт будет доступен только из части сети за межсетевым экраном». На практике в большинстве случаев нарушения безопасности так или иначе участвуют люди, причастные к работе компании, – недовольные, подкупленные или желающие оказать дружескую услугу сотрудники, уборщики, клиенты, поставщики, приехавшие осмотреть место развертывания своего продукта, и т. д. К тому же не так уж редко настройки межсетевого экрана не совпадают с ожидаемыми. А как вы думаете, сколько людей из–за неполадок с сетью временно отключают экран, а после устранения проблемы забывают его включить? В большой сети со многими точками входа представление о защищенной внутренней сети уже можно считать устаревшим. Такую сеть следует рассматривать как полуоткрытую, враждебную среду.

Если вы не задумывались о «площади атакуемой поверхности» приложения (в это понятие входят все точки входа в него), то следует заняться этим незамедлительно. В модели угроз, если таковая составлена, уже должны быть отражены точки входа. Как правило, сетевой трафик просто шифруется по протоколам SSL/TLS. Если это так, то в грехе 10 вы найдете рекомендации по устранению слабых мест.

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

Если какие–то сетевые соединения защищены, проверьте, работает ли защита, как задумано. Это может оказаться довольно сложно, поскольку требует глубоких знаний в области криптографии. Вот некоторые базовые рекомендации:

□ не занимайтесь реализацией криптографических решений самостоятельно. Пользуйтесь протоколом SSL или API на базе системы Kerberos, который Windows предоставляет в составе библиотек DCOM/RPC;

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

□ если основной поток данных шифруется с помощью пары ключей, то почти всегда наблюдается некое недопонимание. Криптография с открытыми ключами настолько неэффективна, что обычно используется лишь для шифрования случайных сеансовых ключей и необходимых для аутентификации данных, после чего эти ключи служат для симметричного шифрования. Если вы систематически применяете криптографию с открытыми ключами, то система легко может отказать в обслуживании из–за перегрузки. К тому же очень многое может пойти наперекосяк, особенно если длина открытого текста относительно велика. (Детали выходят за рамки данной книги, однако в разделе «Другие ресурсы» приведены ссылки на дополнительные источники информации.);

□ выясните, какой криптографический шифр применяется в системе. Это должен быть хорошо известный алгоритм, а не «самописное» произведение автора. Разработанные «на коленке» шифры применять нельзя. Это ошибка. Исправьте ее. Одобренные симметричные шифры бывают двух видов: блочные и потоковые;

□ шифры Advanced Encryption Standard (AES – улучшенный стандарт шифрования) и Triple Data Encryption (3DES – тройной DES) – это примеры блочных шифров. Оба хороши, и в настоящее время лишь они признаны в качестве безопасного международного стандарта. Шифр DES (Encryption Standard – стандарт шифрования данных) – еще один пример, но его можно вскрыть. Если вы пользуетесь чем–то, отличным от AES или 3DES, то почитайте в современной литературе по криптографии, считается ли выбранный вами шифр надежным.

Потоковые шифры - это по сути дела генераторы случайных чисел. На вход такого алгоритма подается некий ключ, по которому генерируется очень длинная последовательность чисел, которая объединяется с шифруемыми данными операцией XOR. Единственным по–настоящему популярным потоковым шифром является RC4, хотя можно услышать хвалы и в адрес других алгоритмов. Но ни один из них не признан органами стандартизации, к тому же в настоящее время применять потоковые шифры вообще бессмысленно, так как вы при этом жертвуете безопасностью в обмен на небольшое повышение производительности, которое вам, скорее всего, не нужно. Если все–таки в вашем приложении потоковый шифр необходим, поинтересуйтесь в литературе, какого рода проблемы возможны. Например, если вы вопреки нашему предостережению настаиваете на применении шифра RC4, убедитесь, что он используется в соответствии со сложившейся проверенной практикой. Но, вообще говоря, лучше пользоваться блочным шифром в режиме имитации потокового шифра (см. ниже);