Аутентификация и авторизация: два вопроса, которые задаёт любая система

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

Бытовое сравнение: на входе в офис охранник сверяет ваш пропуск с лицом, это аутентификация. Дальше ваш пропуск открывает только определённые двери, и это авторизация. Можно быть надёжно опознанным и всё равно не иметь права заходить в серверную.

Факторы аутентификации делят на три группы. Знание: пароль, PIN-код, ответ на вопрос. Владение: телефон с приложением, аппаратный ключ, карта. Свойство: отпечаток, лицо, голос. Проверка по одному фактору слабее, по двум и более, многофакторная, заметно надёжнее, потому что взломать сразу несколько разных вещей трудно.

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

Модели авторизации различаются. Управление по ролям связывает права с ролью: обычный пользователь, редактор, администратор. Списки доступа перечисляют, кому что разрешено для каждого ресурса. В файловых системах Unix права на чтение, запись и исполнение выставляются для владельца, группы и остальных. Атрибутные модели учитывают контекст: время, расположение, состояние устройства.

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

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

Похожая путаница с протоколами. OAuth занимается делегированием доступа, то есть авторизацией, а подтверждением личности занимается OpenID Connect поверх него. Разработчики, которые принимали токен OAuth за доказательство личности, создавали уязвимости входа.

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

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

К паре аутентификации и авторизации в безопасности добавляют третью составляющую, учёт, по-английски accounting или audit. Она отвечает на вопрос, что делали пользователи после получения доступа: журнал входов, изменения прав, обращения к важным данным. Вместе они образуют триаду AAA, которую используют в сетевых системах и серверах доступа.

Без учёта невозможно расследовать инцидент и заметить злоупотребление правами. Поэтому журналы должны храниться отдельно от систем, за которыми следят, и быть защищены от изменения. Для личного пользования аналог это раздел с историей входов и действий в настройках аккаунта, который стоит иногда просматривать.

В качестве быстрого теста задайте вопрос по каждой проблеме доступа: система не знает, кто я, или знает, но не разрешает? Ответ сразу показывает, куда идти, к настройкам входа или к тому, кто выдаёт права. Так вы быстрее объясните проблему администратору и получите нужное решение без лишней переписки.