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

Делайте интерфейс пользователя простым и понятным

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

Вспомните: «Безопасность (почти) никогда не стоит у пользователей на первом месте». Для иллюстрации этого тезиса мы еще приводили в пример систему, в которой пользователь должен был сделать несколько попыток, чтобы выбрать приемлемый пароль.

Лично мы полагаем, что не нужно накладывать слишком строгих ограничений на выбор пароля, поскольку это приведет лишь к тому, что пользователи станут записывать или забывать пароли. Но с теми ограничениями, что есть, пользователя нужно познакомить в самом начале. Перечислите требования к паролю рядом с полем ввода и изложите их максимально просто. Хотите, чтобы пароль был не короче восьми знаков и содержал хотя бы одну не–букву? Так и скажите!

Принимайте за пользователей решения, касающиеся безопасности

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

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

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

Избегайте также вовлекать пользователя в принятие решений о доверии. Так, в разделе «Примеры из реальной жизни» мы говорили о проверке сертификата SSL/TLS браузерами (конкретно, при работе по протоколу HTTPS). Если проверка не проходит, пользователь видит непонятное окно с предложением принять решение, для чего у него обычно не хватает квалификации.

Что же делать? Оптимальный подход – считать, что сайт, не прошедший проверку сертификата, вообще не работает. Тем самым ответственность за предоставление гарантий достоверности сертификата снимается с пользователя и возлагается на Web–сервер и владельца сертификата. При таком развитии событий пользователя не просят ничего решать. Если пользователь не может зайти на сайт из–за ошибки в сертификате, то такой сайт для него ничем не отличается от неработающего. А раз никто не может зайти, администратор сайта об этом рано или поздно узнает и будет вынужден принять меры. Побочный эффект такого подхода – принуждение людей, отвечающих за Web–сервер, выполнять свою работу. Сейчас же операторы сайта знают, что могут вольно относиться к именам в сертификатах, поскольку по умолчанию браузеры все равно установят соединение. Это классический пример на тему «курица и яйцо».

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

К сожалению, решить эту проблему только на уровне браузера невозможно. Если какой–то браузер реализует описанную стратегию, а все остальные не будут ей следовать, то обвинить в недоступности сайта можно будет «браузер–новатор», а не сервер. Возможно, подкорректировать надо сам протокол HTTPS!

Если вы решите предоставить параметры, позволяющие ослабить безопасность, то мы рекомендуем запрятать их подальше. Не вручайте пользователю мыло и веревку! Считается, что средний пользователь не станет щелкать мышью больше трех раз, чтобы найти нужный параметр. Упрячьте такие параметры поглубже в интерфейсе конфигурации. Например, вместо того чтобы включать в диалоговое окно вкладку Security (Безопасность), сделайте вкладку Advanced (Дополнительно), а уже на ней – кнопку Security. При нажатии этой кнопки откройте окно, в котором будут отображаться текущие значения параметров безопасности, средства для конфигурирования протоколов и другие безвредные вещи. И поместите еще одну кнопку Advanced – вот она–то и позволит сделать что–то по–настоящему опасное. И ПОЖАЛУЙСТА, сопровождайте такие действия предупреждениями!

Упрощайте избирательное ослабление политики безопасности

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

Хороший пример такого рода – это идея «Информационной панели» (Information Bar), небольшой области состояния, добавленной к Internet Explorer в Windows ХР SP2 (позже ее позаимствовал Firefox). Она находится сразу под строкой ввода адреса и информирует пользователя о текущих политиках безопасности. Например, браузер не спрашивает, хочет ли пользователь разрешить выполнение активного или мобильного кода, а просто запрещает, но информирует об этом. В этот момент пользователь может при желании изменить политику (если, конечно, имеет на это право), но по умолчанию предпринимается безопасное действие. Пользователю не надо думать о доверии, система безопасна, но сообщает, если происходит что–то необычное. Информационная панель показана на рис. 19.3.

Рис. 19.3. Информационная панель в Internet Explorer Ясно описывайте последствияЕсли пользователь поставлен перед необходимостью принять решение об ослаблении политики безопасности (например, дать разрешение на использование ресурса кому–то еще или рискнуть загрузить какой–то один потенциально небезопасный файл), то вы должны ясно обрисовать, чем это грозит! То же самое относится к случаю, когда пользователя надо информировать о произошедшем событии, касающемся безопасности, хотя напрямую оно с его действиями не связано.Сообщение об опасности не должно быть перегружено техническими подробностями. Например, одна из многих причин, по которым обсуждавшееся выше окно с информацией о сертификате – это никуда не годный механизм ослабления политики безопасности, состоит как раз в том, что содержащиеся в нем сведения совершенно невразумительны. Другая серьезная проблема заключается в том, что на основании этой информации нельзя предпринять никаких действий, но об этом ниже.Мы рекомендуем выводить короткое сообщение об ошибке, а подробности показывать, только если пользователь попросит. Это называется прогрессивным раскрытием информации. Не обременяйте пользователя или администратора ненужной и непонятной информацией, захотят – сами попросят. В качестве удачных примеров можно привести то, как браузеры Internet Explorer и Firefox выводят информацию о сертификатах корневых УЦ. На рис. 19.4 показано, как Internet Explorer отображает сертификат и предлагает его установить. Если вам нужна дополнительная информация, а если честно, нужна она только знающим пользователям, то достаточно перейти на вкладку Details (Детали) или Certification Path (Перечень сертификатов). Вкладки – это превосходный механизм прогрессивного раскрытия информации.Отметим, что показанное на рисунке диалоговое окно Internet Explorer – это стандартный диалог операционной системы, его можно вызвать с помощью функции CryptUIDlgViewCertificate: