Защита систем. Чему «Звездные войны» учат инженера ПО (страница 5)

Страница 5

Аутентификация людей компьютерами

В отличие от «Ромео и Джульетты», где тема идентичности и самозванства в мире людей заканчивается трагически, «Звездные войны» дают нам примеры того, как взаимодействуют люди и технологии. Как Бен Кеноби аутентифицируется у R2-D2, чтобы увидеть голограмму Леи? Когда R2-D2 подключается к системе «Звезды смерти», чтобы найти, где ее держат, какой идентификатор пользователя используется для его SQL-запроса?

(Между прочим, ваш первый ответ, что R2-D2, вероятно, обладает разумом, недостаточен. Лея не знает, что этот конкретный R2 знал Кеноби, поэтому как она могла прописать правило контроля доступа?)

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

Различные типы информации могут учитываться при принятии решения о подлинности (authentication decision). Ниже приведены наиболее часто используемые факторы и примеры каждого из них.

 Знание: комбинация сейфа.

 Объект, который у вас есть: ключ к депозитной ячейке или ID-карточка.

 Биометрия: ваше физическое тело, измеренное или оцененное различными способами (включая фотографию).

 Местоположение: непосредственно перед компьютером.

 Канал, который вы используете: интернет, телефон или личное присутствие.

 Люди, которых вы знаете: доверенные лица и попечители.

Факторы также обладают силой: обычно паспорт рассматривают как более сильное доказательство идентичности, чем читательский билет. Пароль secret не такой сильный, а пароль u8fdFN288jerfskla-#$d очень хорош.

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

Традиционные факторы обозначают как «Что вы знаете», «Что у вас есть» и «Кто вы такой». Они были дополнены такими факторами, как «Где вы находитесь», «Как вы связываетесь» и «Кого вы знаете». Фактор «Где вы находитесь» использовался по умолчанию в эпоху первых компьютеров (рядом со стеклянной комнатой с центральной ЭВМ), потом вышел из употребления на какое-то время и недавно снова появился, включая использование сигналов GPS, а также наносекундный тайминг в часах компании Apple для отпирания ассоциированного с ними компьютера. Канал, который вы используете для связи, может подвергать вас риску (личному) или быть неудобным для самозванца. Звоня по телефону, я рискую обнаружить, что не говорю на языке вуки.

«Кого вы знаете» может включать ваш новый пароль, выданный вашему менеджеру или системе социальной аутентификции, чтобы понять, знаете ли вы своих друзей, чтобы вернуться в соцсеть, или просьбу для доверенных лиц установить подлинность вашей личности, чтобы вернуться на какой-то другой аккаунт. Эти социальные аутентификаторы не так распространены, но, если вам интересно, я обсуждаю возникающие для них угрозы в главе 14 «Учетные записи и идентификация» моей книги Threat Modeling: Designing for Security («Моделирование угроз: проектирование для обеспечения безопасности»).

Традиционные факторы аутентификации часто пародируются как «Что вы забыли, что вы потеряли и каким вы были, когда были моложе и здоровее». Эти проблемы означают, что нам нужны резервные методы аутентификации.

Резервную аутентификацию именуют по-разному: «Забыл пароль», «Восстановление пароля» или «Восстановление учетной записи». Последний вариант наиболее точный: никому дела нет до восстановления своего пароля; все просто хотят получить доступ к учетной записи. Мне вообще не нужно, чтобы я когда-либо знал ваш дурацкий пароль, чтобы получить доступ к некоторой возможности, и вообще-то это не обязательно должна быть моя учетная запись. Это не мелочные придирки, понимание проблемы – ключ к ее надежному решению. Эти резервные системы аутентификации лучше всего работают, если они используют секреты, известные как можно меньшему количеству людей. («Где вы использовали вашу кредитную карту последние три раза?» известно только вам, вашему банку, процессинговой компании кредитных карт, торговым точкам и их агентствам маркетинговых исследований, в то время как «В какую школу вы ходили?» известно всем вашим друзьям в соцсетях и друзьям ваших друзей.)

Иногда дополнительные шаги или факторы выполняются как часть авторизации: вы можете зарегистрироваться (log in) с помощью некоторого пароля, но, чтобы добавить получателя платежа, может потребоваться что-то большее. Такой шаблон обеспечивает некоторое удобство использования (usability), за которое платишь конфиденциальной информацией вроде ваших последних транзакций, которая используется для такой сильной аутентификции. Или, в некоторых случаях, это делается ценой безопасности учетной записи, когда эта конфиденциальная информация используется, несмотря на ее раскрытие. Мы подробнее коснемся полномочий и авторизации в главе 6 «Расширение полномочий и изоляция».

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

Аутентификация компьютеров людьми

Трудно сказать, когда впервые был создан фальшивый экран для ввода логина и пароля: вероятно, в те времена, когда телетайпы заменили на электронные терминалы. Легко было написать программу, которая бы вывела на экран LOGIN:, приняла бы и сохранила имя и пароль, вывела бы Login incorrect (Неправильный логин) и отключилась бы, позволив выполняться настоящей программе для ввода логина и пароля.

Вот почему комбинация Ctrl+Alt+Delete помогала держать ваш компьютер в безопасности: она возвращала вам заведомо настоящую экранную страницу входа. Аналогично кнопка Home на вашем телефоне не может быть перехвачена какой-либо программой, и в идеальном случае это верно для жестов, которые заменяют физические кнопки. Фишинг – это разновидность такого подхода, просто компьютер, которому вы шлете свою аутентифицирующую информацию, находится дальше. Современные схемы фишинга будут запрашивать у вас код, посланный смской на ваш телефон или отправленный на вашу электронную почту. Аналогично мошенники сфальсифицируют информацию о вызывающем (Caller ID), чтобы это выглядело так, будто вам звонят из учреждения, которому вы доверяете: ваш банк или Имперское бюро безопасности Галактической Империи.

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

Можем ли мы понять, с каким компьютером общаемся? Конечно, с определенной точки зрения. Большинство веб-сайтов, которыми мы пользуемся, полагаются на некоторую комбинацию независимо управляемых компьютерных систем: веб-сервер, сеть распространения контента (CDN) или различные инструменты рекламы, трекинга и анализа. Когда это так и задумано, мы не размышляем об этом как о проблеме, за исключением, возможно, приватности, но я упомянул об этом, чтобы проиллюстрировать, что большинство людей не задумываются, с каким компьютером они общаются. Уверенность в подлинности удаленного компьютера наиболее важна, когда он запрашивает информацию для аутентификации или другие конфиденциальные данные: мы хотим, чтобы наше мысленное представление было достаточно точным, даже если наше понимание ограничено.

Мы можем распознать C-3PO из-за характерного голоса и манерности, которую создал Энтони Дэниэлс. К сожалению, большинство компьютеров не так легко опознать. Существует множество инструментов, которые облегчают распознавание компьютера, и они часто меняются, чтобы злоумышленникам было легче сбить вас с толку относительно того, что вас ждет сегодня. Подождите, я не думаю, что это делается специально, но это реальный эффект изменений. Инструменты часто меняются в надежде справиться с новыми атаками. Чтобы обезопасить себя от всего этого, нужно взять ситуацию под контроль: нажмите Ctrl+Alt+Delete, откройте сохраненную вами страницу вашего банка, позвоните по номеру, указанному на обратной стороне вашей банковской карты. Это работает гораздо лучше, когда организации упрощают для вас доступ к нужному человеку или человеку с нужной информацией, когда вы берете под контроль процесс аутентификации.

Аутентификация компьютеров компьютерами

Аутентификация важна всякий раз, когда у вас есть вызов, например listen(socket_id). То, что находится по другую сторону этого сокета, должно быть идентифицировано. Когда R2-D2 подключается к сокету, «Звезда смерти» позволяет выполнять всевозможные запросы, возвращая чрезвычайно важную информацию о местонахождении заключенных. Учитывая конфиденциальность полученных данных, мы можем только надеяться, что учетная запись не была guest или rebelscum (гнусный повстанец), но что это было и как R2-D2 доказал возможность использовать эту учетную запись?

Каждая аутентификация может иметь некоторую многоуровневую комбинацию технических и человеческих идентификаторов. Например, у удаленного хоста, вероятно, есть IP-адрес. Он может предоставлять какую-либо форму идентификатора клиента, например файл cookie или токен OAuth. Кроме того, он может иметь идентификаторы человека или сервиса.

Когда клиент инициирует подключение к серверу, любая из сторон может потребовать аутентификацию. Сложности возникают, когда на акт подключения может влиять другой компьютер или когда эта аутентификация осуществляется от имени человека. Простейшим случаем может быть использование Telnet для подключения к IP‐адресу: это происходит в ответ на ввод человеком команды, на которую трудно повлиять. Но чуть более сложные примеры, такие как отправка электронной почты, подвержены влиянию. Если я попытаюсь отправить электронное письмо адресату luke@threatsbook.com, мой почтовый клиент подключится к моему почтовому серверу, который будет использовать DNS для поиска записи MX для threatsbook.com и подключения к этому сайту. DNS-сервер для threatsbook.com может влиять на то, куда будет подключаться мой почтовый сервер.

Спуфинг может произойти, когда ваш код прямо или косвенно вызывает метод listen(). В случае косвенного вызова, возможно, веб-сервер вызывает listen(), разбирает сообщения TLS и HTTP и передает что-то более «уточненное». Код по-прежнему должен идентифицировать вызывающую сторону. Веб-сервер может выполнять часть этой работы, и даже в этом случае вам вполне может потребоваться сопоставить таблицу учетных записей сервера с таблицей, используемой в ваших базах данных. Например, я могу войти в систему как adam@threatsbook.com и иметь customer_id 1234.