По данным Verizon, более 80% инцидентов взлома связаны со слабыми или украденными паролями. Защититься от несанкционированного доступа, следовать принципам Zero Trust и минимизировать вероятность таких инцидентов помогает сервис многофакторной аутентификации (MFA).
MWS запустил облачный сервис MFA — это хороший повод обсудить важные компоненты управления доступом и идентификационными данными (IAM).
Термины аутентификация и авторизация часто используют как взаимозаменяемые, что вызывает путаницу и может приводить к проблемам в ИБ. С одной стороны, в ИТ-сообществе встречается мнение о том, что терминологию стоит пересмотреть и внедрить более «прозрачные» названия процессов.
С другой стороны, участники ИБ-сообщества не видят проблемы в наименованиях и призывают сконцентрироваться на более насущных вопросах — в частности, искоренении слабых паролей. Мы решили обсудить различные предложения и точки зрения на ситуацию.
Аутентификация и авторизация: история вопроса
Прежде чем перейти к обсуждению темы с употреблением терминов, кратко обсудим, что, собственно, означают аутентификация и авторизация.
История аутентификации берет свое начало в 1960-х — по сути, с появлением первых компьютеров, доступных широкой публике — и связана с необходимостью использовать пароли. Вычислительные системы того времени были огромными, дорогими и занимали целые машинные залы. Чтобы на компьютере могли работать сразу несколько юзеров, использовали операционные системы с разделением времени. Одной из первых стала Compatible Time-Sharing System (CTSS), разработанная в MIT.
ОС с разделением времени помогли преодолеть проблему «спроса», но создали другую. Пользовательские файлы хранились в общей файловой системе, поэтому требовалось решить вопрос с приватностью. В 1961 году исследователь MIT Фернандо Корбато реализовал программу для управления доступом к системе по паролю. Однако она была рудиментарной, так как учетные данные хранились в чистом виде в текстовом файле.
Уже позже были внедрены хеширование, одноразовые пароли и другие механизмы, но в каком-то смысле решение Корбато можно назвать одним из первых для аутентификации. Если обратиться к современным определениям, то, как правило, под аутентификацией понимают процесс, который гарантирует, что доступ к ресурсам организации имеют лишь конкретные пользователи, сервисы и приложения.
Как правило, пользователи подтверждают свою личность с помощью пароля или PIN-кода. С целью усилить защиту многие организации требуют подтвердить личность с помощью физических токенов или биометрии. В редких случаях в качестве дополнительного фактора аутентификации могут использовать геолокацию или IP-адрес.
В то же время аутентификация является лишь одним из компонентов управления доступом и идентификационными данными (IAM). IAM включает и другие механизмы, к которым относится авторизация — процесс управления доступом к данным.
В целом принято выделять три класса авторизации:
- избирательное управление, когда владелец документа или файла сам устанавливает права доступа для него;
- мандатный доступ, когда информацию разделяют по степени секретности, а пользователей — по уровням доступа к ней;
- управление доступом на основе ролей, название которого говорит само за себя.
Стоит отметить, что в юридических документах вроде условий оказания услуг, смысл терминов может быть более ограниченным. Такой подход позволяет упростить их восприятие и избежать недопонимания со стороны клиентов. Например, можно определить аутентификацию как процесс проверки подлинности юзера, а авторизацию — как процедуру предоставления доступа к функциональности системы, которая производится на основании успешной аутентификации. По сути, система решает, есть ли у аутентифицированного пользователя права взаимодействовать с тем или иным контентом.
Замена терминов и сущность процессов
Несмотря на то что аутентификация и авторизация выполняют различные функции, многие используют эти термины как взаимозаменяемые. Усугубляет ситуацию тот факт, что в английском языке оба слова часто сокращают до простого auth. Когда такое сокращение является частью названия инструмента для управления доступом, сходу сложно сказать, за какой из двух аспектов он отвечает.
Например, библиотека go-auth позволяет реализовать аутентификацию с помощью аккаунтов в социальных сетях. В то же время OAuth является протоколом авторизации, позволяющим предоставить пользователям права доступа к набору ресурсов (например, API).
Некоторая путаница существует даже на уровне списка кодов состояния HTTP. Так, ошибка 401 Unauthorized обычно обозначает unauthenticated, а 403 Forbidden классифицируется как unauthorized. Вопрос двусмысленности терминов беспокоит, поскольку неверное их употребление в технической документации может вести к разногласиям в работе команды разработчиков.
Из-за расхождений в понимании определений авторизации и аутентификации можно было бы заменить термины на более однозначные. Так, есть предложение использовать написание AuthN для аутентификации и AuthZ для авторизации, чтобы избежать двусмысленности. Но такой подход создает сложности при составлении технической документации и юридических документов. В частности, возрастает риск опечаток и ошибок при использовании функций автоматического заполнения в текстовых редакторах.
Некоторые представители ИТ-сообщества высказывают предложение заменить термины аутентификация и авторизация следующими понятиями:
- «вход» (login) — речь идет об информации, которую пользователь вводит для получения доступа к системе;
- «разрешение» (permission) — отображает уровень доступа.
В теории такая терминология будет понятна даже людям, не связанным с разработкой программного обеспечения. Однако не все считают это предложение удачным. В то время как новые обозначения действительно упрощают понимание на базовом уровне, они не передают весь смысл и сложность процессов контроля доступа. Так, авторизация, помимо разрешения работать в системе, может включать проверку лицензий, ограничения по времени и другие специфические функции.
Вообще вместо «аутентификации» можно использовать слово «идентификация». В целом эта идея не новая. Однако и здесь присутствует разница в значениях — даже в методическом пособии CISSP (сертификация в области ИБ) они выделены как два раздельных компонента управления доступом.
Идентификация устанавливает факт существования личности, используя для этого персональные данные. Примером может быть процедура KYC в финансовых организациях. В то же время аутентификация не всегда подразумевает установление личности. Так, сотрудник компании может войти в панель управления облаком с корпоративного аккаунта: он будет аутентифицирован, но не идентифицирован.
Есть мнение, что простая замена слов не поможет распутать терминологический клубок. Проблема кроется в том, что не все понимают разницу в сущности процессов, а не сами термины. И в первую очередь нужно работать с этим — то есть повышать грамотность.
Qwerty123 и другие киберриски
В то же время можно встретить мнение, что разногласия в терминологии и потенциальные сложности с определением назначения библиотек — не тот вопрос из сферы контроля доступа, на котором стоит заострять внимание. Слабые пароли — куда более серьезная проблема. Согласно отчету ИБ-фирмы SpyCloud, в сети в свободном доступе находятся 27 млн учетных данных сотрудников и руководителей высшего звена самых крупных компаний.
Пользователи не хотят усложнять себе процесс входа в учетную запись дополнительными этапами. Пользователи имеют привычку повторно использовать данные аутентификации на нескольких ресурсах (включая личные и корпоративные). Проблема известна очень давно, и её не так-то просто искоренить — согласно опросам, 55% российских пользователей используют одинаковые пароли для разных аккаунтов, хотя 94% знают, что это опасно. Менеджеры паролей решают эту проблему, однако, согласно опросу интернет-пользователей по всему миру (BitWarden), с ними работают лишь 34% юзеров.
Для бизнеса же вопрос часто в стоимости, так как внедрение этой системы ведет к дополнительным расходам. Однако слабые пароли серьезно повышают риск кибератак. Так, в начале года злоумышленники «взломали» аккаунт RIPE NCC крупного (второй по величание в стране) испанского телекома. Всему виной чрезвычайно слабый пароль ripeadmin и отсутствие многофакторной аутентификации для защиты учетной записи.
Кажется, что в многофакторная аутентификация в наши дни — очевидное решение, которое сможет обезопасить данные. Однако оно до сих пор используется не везде.
Вопросами безопасности, связанной аутентификацией и паролями, занимаются на самом высоком уровне — законодательном. Например, в Великобритании приняли решение запретить компаниям-производителям смартфонов, телевизоров и других умных устройств устанавливать стандартные простые пароли наподобие 12345 или qwerty123. В 2020 году в штате Калифорния приняли закон «О конфиденциальности информации». Согласно нововведению, производители электроники обязаны присваивать уникальный пароль к каждому гаджету, продаваемому в регионе. Японский регулятор запустил серию «профилактических» кибератак на IoT-устройства граждан в преддверии Олимпийских игр 2020 года. Владельцев взломанных устройств оповещали о том, что их гаджеты уязвимы, и выдавали им инструкцию, как обеспечить защиту девайсов.
По данным Microsoft, более 99,9% учетных записей, которые в конечном счете взламывают, не имеют включенной функции MFA. Многофакторная аутентификация все равно остается самым простым и эффективным способом снизить риски подвергнуться кибератакам.