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

Разумеется, конфиденциальные данные нужно защищать с помощью подходящих средств, например списков АСЕ в Windows и Apple MAC OS X 10.4 Tiger или прав доступа в *nix.

Есть и другие защитные меры, такие, скажем, как шифрование (с корректной политикой управления ключами) и управление цифровыми правами (Digital Rights Management – DRM). Механизм DRM в этой книге не рассматривается, но вкратце его суть в том, что пользователь может явно определить, кому разрешено открывать, читать, модифицировать и передавать другим лицам содержимое документов, в частности электронной почты. Организация может создать шаблоны политик управления правами, которые определяют правила, применимые к содержимому документов. Конечно, надо быть готовым к тому, что кто–то окажется достаточно настойчив, чтобы обойти механизм DRM, но на практике немного найдется людей, способных на это.

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

Искупление греха в С# (и других языках)

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