Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ

В чем состоит грех

Несколько лет назад инженеры из Центра проблем безопасности Microsoft (Microsoft Security Response Center – MSRC) сформулировали 10 незыблемых законов безопасного администрирования. Второй закон звучит так:

Система безопасности работает только тогда, когда безопасный способ одновременно является простым.

Ссылку на 10 незыблемых законов вы найдете в разделе «Другие ресурсы».

Безопасность и простота часто конфликтуют. Пароли – это один из популярных «простых» способов, но безопасным его обычно не назовешь (см. грех 11).

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

Эта проблема не связана ни с каким конкретным языком.

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

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

Итак, безопасность для пользователя – не главное. Значит, если приложение не является безопасным по умолчанию, то пользователь и не поинтересуется, как сделать его таковым. Даже если для этого нужно всего лишь щелкнуть переключателем, он не станет утруждать себя. Поэтому не думайте, что вы сможете научить кого–то безопасному поведению с помощью руководства или сообщений, выдаваемых приложением. Конечно, очень соблазнительно переложить ответственность на пользователей, но мир от этого безопаснее не станет. Запомните: администраторы не склонны изменять настройки на более безопасные, а обычные пользователи представления не имеют, как это сделать.

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

Каков круг ваших пользователей?

Одна из самых больших ошибок, которые можно сделать, размышляя (или не размышляя) о безопасности и удобстве, – это потерять из виду потенциальную аудиторию. При рассмотрении данного греха мы будем ориентироваться на две основные группы: конечных пользователей и администраторов.

С точки зрения безопасности у конечных пользователей и администраторов разные цели. Очень немногие программы предлагают ту степень безопасности, которая необходима пользователям. Администраторы хотят, чтобы системой можно было управлять напрямую, а потребители желают безопасности при работе в сети. Следовательно, администраторам нужен простой доступ к критически важным данным, который позволит им принимать правильные решения в плане безопасности. Потребители же ведут себя совсем иначе: они вообще не хотят принимать хороших решений, касающихся безопасности, сколько бы информации вы перед ними ни выложили. На самом деле осмелимся утверждать, что для большинства технически необразованных пользователей чем меньше технической информации, тем лучше (чуть позже мы еще вернемся к этой теме). Дело не в том, что они глупые, вовсе нет. (И пожалуйста, не называйте их «ламерами»; именно на деньги этих людей вы и существуете.) Просто им необязательно понимать последствия своих решений с точки зрения безопасности.

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

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

Минное поле: показ пользователям информации о безопасности

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

□ Слишком мало информации. Это бич администратора: не хватает информации для принятия правильного решения.

□ Слишком много информации. Это беда для обычного пользователя: избыток информации приводит его в замешательство.

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

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

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

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

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

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

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

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

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

Исследуя, как удобство может повлиять на безопасность, примите во внимание следующие рекомендации.