19 смертных грехов, угрожающих безопасности программ
Шрифт:
Вот еще одна типичная проблема: когда безопасность вступает в противоречие с желаниями пользователя, проектировщик часто не думает о том, как сделать работу простой и удобной. В результате пользователь остается недоволен и ищет способы обмануть систему. Предположим, например, что во имя повышения безопасности вы наложили строгие ограничения на структуру пароля. Например, он должен быть не короче восьми символов, содержать, по крайней мере, один символ, отличный от букв и цифр, а кроме того, не должен быть словом из словаря. Ну и что произойдет? Некоторые пользователи сумеют выбрать подходящий пароль только после 20 попыток. А потом они его либо забудут, либо запишут на бумажку, которую подсунут под клавиатуру. В результате вы вообще лишитесь
Каков круг ваших пользователей?
Одна из самых больших ошибок, которые можно сделать, размышляя (или не размышляя) о безопасности и удобстве, – это потерять из виду потенциальную аудиторию. При рассмотрении данного греха мы будем ориентироваться на две основные группы: конечных пользователей и администраторов.
С точки зрения безопасности у конечных пользователей и администраторов разные цели. Очень немногие программы предлагают ту степень безопасности, которая необходима пользователям. Администраторы хотят, чтобы системой можно было управлять напрямую, а потребители желают безопасности при работе в сети. Следовательно, администраторам нужен простой доступ к критически важным данным, который позволит им принимать правильные решения в плане безопасности. Потребители же ведут себя совсем иначе: они вообще не хотят принимать хороших решений, касающихся безопасности, сколько бы информации вы перед ними ни выложили. На самом деле осмелимся утверждать, что для большинства технически необразованных пользователей чем меньше технической информации, тем лучше (чуть позже мы еще вернемся к этой теме). Дело не в том, что они глупые, вовсе нет. (И пожалуйста, не называйте их «ламерами»; именно на деньги этих людей вы и существуете.) Просто им необязательно понимать последствия своих решений с точки зрения безопасности.
Один из аспектов практичности, который часто упускают из виду, – это удобство работы в корпоративной среде. Представьте, что ваша деятельность сводится к обеспечению правильного и безопасного функционирования 10 ООО систем, на которых установлена некая программа. И никто вам в этом помогать не собирается. Есть много людей, занимающихся администрированием больших сетей, и они оказывают влияние на решения о закупках, так что имеет смысл постараться им понравиться.
Вы должны думать о том, как централизовать установку параметров на клиентских системах, а равно о том, как аудировать те аспекты конфигурации, которые относятся к безопасности. Если для этой цели вам придется лично зайти на каждую из 10 ООО машин, неделя покажется очень долгой!
Минное поле: показ пользователям информации о безопасности
Часто приходится встречать тексты и сообщения, относящиеся к безопасности, которые обладают одним или несколькими из перечисленных ниже свойств.
□ Слишком мало информации. Это бич администратора: не хватает информации для принятия правильного решения.
□ Слишком много информации. Это беда для обычного пользователя: избыток информации приводит его в замешательство.
□ Слишком много сообщений. Обычно и администратор, и пользователь при виде слишком большого числа сообщений просто нажимают кнопку ОК или Yes. А подтверждение может как раз оказаться неверным решением.
□ Неточная или слишком общая информация. Ничего хуже не придумаешь, так как сообщение просто ничего не говорит пользователю. Конечно, вам бы не хотелось сообщать лишнее потенциальному противнику, но надо найти разумный компромисс.
□ Сообщения, содержащие только коды ошибок. Коды конечно, вещь полезная, особенно когда они что–то говорят администратору. Но надо также включать текст, понятный пользователю.
Помните, что люди, мало разбирающиеся в компьютерах, склонны принимать неправильные решения в том, что касается безопасности.
Родственные
Аутентификация, и прежде всего в системах на базе паролей, – это одно из мест, где конфликт между безопасностью и удобством особенно острый. Даже когда вы искренне пытаетесь построить хорошо защищенную парольную систему (и избежать описанных в грехе 11 ошибок), все усилия могут пойти насмарку, если не принять в расчет удобства пользования.
Где искать ошибку
С общей точки зрения, ошибка состоит в невнимании к тому, как типичный пользователь будет работать с частями программы, относящимися к безопасности. Эту ошибку совершают многие, но явно указать на нее сложно. Мы обычно смотрим, предприняты ли в проекте осознанные меры по повышению удобства пользования и включают ли эти меры вопросы безопасности. Если нет, то пользователь сумеет испортить себе жизнь. Этот грех не так откровенен, как большинство прочих, то есть его наличие еще не означает неизбежных проблем.
Выявление ошибки на этапе анализа кода
При рассмотрении большинства других грехов мы рекомендуем анализ кода как более эффективный по сравнению с тестированием метод. Здесь же все наоборот. Личные соображения по поводу того, как будут сочетаться удобство и безопасность, не выявят проблемы с той же полнотой и точностью, как реакция пользователей, непосредственно тестирующих приложение.
Это не означает, что на этапе анализа кода вообще ничего нельзя сделать. Мы хотим лишь сказать, что не нужно подменять анализом надлежащим образом организованное тестирование.
Исследуя, как удобство может повлиять на безопасность, примите во внимание следующие рекомендации.
□ Найдите в интерфейсе пользователя все параметры, относящиеся к безопасности. Что включено по умолчанию, а что выключено? Если программа по умолчанию небезопасна, возможны проблемы. Неприятности могут возникнуть и в тех случаях, когда ослабить безопасность слишком легко.
□ Изучите систему аутентификации. Если пользователь не может успешно аутентифицировать второго участника соединения, есть ли возможность все–таки установить соединение? Разумеется, при этом пользователь понятия не имеет, кто находится на другом конце. Хороший пример – это SSL–соединение, когда клиентская программа соединяется с сервером, но имя в сертификате свидетельствует о том, что это не тот сервер, а пользователь даже не обращает на это внимания. (Скоро мы объясним эту ситуацию подробнее.)
Стоит также взглянуть, существует ли очевидный способ переустановить пароль. Если да, то можно ли использовать этот механизм, чтобы вызвать отказ от обслуживания? Нельзя ли с его помощью заманить пользователя в ловушку методами социальной инженерии?
Тестирование
В основе науки о практичности лежит тестирование. К сожалению, фирмы–разработчики такому тестированию не уделяют много внимания. При тестировании практичности пользователи обычно работают парами (метод обсуждения вслух). Они самостоятельно исследуют систему, часто в первый раз. При оценке безопасности можно применить такой же подход; главное, чтобы пользователь попробовал те функции, которые вас интересуют.
Обычно в ходе испытания пользователям предлагается набор заданий, но в их работу никто не вмешивается до тех пор, пока они не застрянут окончательно.
Основы тестирования практичности применимы и к безопасности, поэтому имеет смысл познакомиться с этой дисциплиной. Мы рекомендуем книгу Jacob Nielsen «Usability Engineering» (Morgan Kaufman, 1994) («Инженерная оценка практичности»). Кроме того, в статье Alma Whitten и J.D. Tygar «Usability of Security: A Case Study» («Практичность безопасности на конкретном примере») излагаются некоторые соображения по поводу тестирования функций безопасности программ с точки зрения удобства пользования.