Управление облачными удостоверениями
Распространенная проблема при вычислениях — точно определить пользователя, который использует систему в определенный момент времени. Удостоверение пользователя является важным по нескольким причинам. Наиболее значимой является ограничение доступа пользователей к ресурсам, на которые у них нет прав, и выполнения действий, которые они не имеют права выполнять. Например, пользователь, использующий веб-почту, не должен видеть сообщения, отправленные другим пользователям. Аналогичным образом, когда администратор базы данных обращается к облачной службе, они не должны иметь возможности получать доступ к базам данных, для которых они не несут ответственности или выполнять другие административные задачи, которые находятся за пределами область своих обязанностей. Все это невозможно обеспечить, если мы не знаем, кто является пользователем.
Существует множество примеров того, как удостоверение устанавливается и представляется для проверки в повседневной жизни. Многие страны или регионы используют идентификаторы, такие как номера социального страхования, для идентификации лиц в налоговых целях или предоставления им доступа к государственным программам. Правоохранительные органы требуют, чтобы водители автомобилей присутствовали на лицензиях водителей и квитанциях регистрации транспортных средств, чтобы идентифицировать себя и доказать, что они квалифицированы для эксплуатации транспортного средства. Международные органы пограничного контроля требуют, чтобы путешественники имели при себе паспорта для подтверждения своего гражданства.
В онлайн-мире удостоверение обычно определяется сложным пользователем, чтобы предоставить учетные данные, которые однозначно идентифицируют их, например имя пользователя и пароль, отпечатки пальцев или, как становится все чаще на смарт-телефонах, лицо. (Недавние достижения в искусственном интеллекте повысили распознавание лиц от магии до науки.) При первом входе в систему они могут быть вызваны проблемой ввода учетных данных, что обычно относится к административным порталам для облачных служб. Такой запрос может не поступить, если пользователи пытаются получить доступ к защищенному ресурсу, например к веб-странице, который предоставляется только для пользователей, прошедших проверку. Проверка подлинности — это процесс определения того, кто является кем-то, то есть подтверждение их личности за пределами разумных сомнений. Это отдельно от авторизации, которая определяет, что пользователь может и не может сделать после проверки подлинности.
Существует множество разнообразных примеров определения сетевого удостоверения. Они также зависят от сценария. Рассмотрим два распространенных примера использования проверки подлинности для определения удостоверения пользователя. В первом существует общедоступный веб-сайт, требующий, чтобы пользователь вошел в систему, прежде чем пытаться получить доступ к некоторым или всем ресурсам веб-сайта. Во втором выполняется проверка подлинности пользователей, которые желают получить доступ к общим папкам, сетевым устройствам и другим внутренним ресурсам. В обоих случаях определение удостоверения пользователя перед предоставлением ему доступа имеет первостепенную важность для реализации безопасной и надежной системы.
Проверка подлинности пользователей внешних веб-сайтов
Одним из наиболее распространенных способов использования цифрового удостоверения является вход на веб-страницу, которая доступна только для прошедших проверку пользователей (например, пользователей, которые приобрели подписку на интернет-издание газеты). Первое решение, которое должны принять разработчики веб-сайта, — определить, что они будут делать: писать логику, позволяющую пользователям регистрировать (создавать учетные записи) самих себя и входить в систему, или использовать сторонний поставщик удостоверений. Поставщик удостоверений — это служба, которая выполняет проверку подлинности пользователей, используя такие стандартные протоколы, как OAuth 2.0, OpenID Connect и SAML 2.0. Каждый из этих протоколов реализует механизмы для обеспечения подлинности передаваемой информации. Например, они используют цифровые подписи, позволяющие избежать изменения сведений об удостоверениях при передаче через Интернет.
Существует множество служб-поставщиков цифровых удостоверений. В качестве поставщиков удостоверений могут выступать социальные сети (например, Facebook или Twitter). Таким образом для доступа к другим сайтам пользователи могут использовать учетные данные этих сетей. Корпорации Майкрософт и Google также предлагают службы-поставщики удостоверений, позволяющие пользователям использовать учетные записи Майкрософт и Google для доступа к другим сайтам. Именно это происходит, когда вы используете учетную запись Майкрософт для входа в почту Outlook или учетную запись Google для входа в систему Gmail, YouTube и на другие сайты, поддерживающие учетные записи Google. Поставщики облачных служб предлагают службы-поставщики удостоверений, а также средства для их интеграции или интеграции других поставщиков удостоверений в веб-сайты. Например, с идентификатором Microsoft Entra это относительно простой вопрос для создания веб-сайта, который принимает частные имена входа, "общедоступные" имена входа с помощью Facebook, Twitter, Майкрософт или учетных записей Google или любого сочетания этих двух.
Использование сторонних поставщиков удостоверений для проверки подлинности пользователей обеспечивает три приведенных ниже преимущества.
Более надежная безопасность: сторонние поставщики удостоверений, такие как Майкрософт и Google, имеют глубокий опыт хранения и обмена учетными данными входа безопасно. Некоторые из серьезных брешей в системе безопасности, которые произошли в последние годы, были вызваны тем, что разработчики, которые не были экспертами в области безопасности, реализовали свои собственные системы входа и оказались жертвами распространенных ошибок, таких как хранение незашифрованных паролей в базе данных. Пароли никогда не следует хранить, даже если они зашифрованы. Вместо этого следует хранить односторонние хэши паролей. Следует также применять известный метод, например добавления случайных данных, чтобы пароли было сложнее взломать1.
Кроме того, многие поставщики удостоверений поддерживают многофакторную проверку подлинности (MFA), чтобы в случае кражи учетных данных их было труднее использовать. Примером MFA является запрос на введение кода доступа, отправленного с помощью SMS на мобильный телефон, при входе на веб-сайт. Наконец, сторонние поставщики удостоверений часто реализуют условный доступ, который создает дополнительные барьеры безопасности в режиме реального времени на основе истории входа, географического расположения или других факторов. Именно поэтому иногда требуется предоставить дополнительные сведения, если вы осуществляете вход на веб-сайт во время поездки. Поставщик удостоверений определяет IP-адрес, с которого ранее не выполнялся вход, и добавляет дополнительный уровень безопасности для процесса проверки подлинности.
Поддержка единого входа. Использование 20 имен пользователей и паролей для входа на 20 различных веб-сайтов не только является неудобством, это проблема безопасности. Пользователи, столкнувшиеся с управлением десятками имен пользователей и паролей, с большей вероятностью применят слабый уровень безопасности, выбрав пароли, которые легко угадать, или используя один и тот же пароль для нескольких учетных записей. Один отчет указывает, что количество пользователей учетных записей должно отслеживать двойные числа каждые пять лет - явление, известное как разрастание учетных записей.
В противоположность этому, если 20 несвязанных веб-сайтов позволяют пользователям входить в систему с учетными записями Майкрософт, Google или Facebook, один набор учетных данных можно использовать для всех 20 сайтов. Это называется единым входом. Это позволяет сократить рост количества учетных записей (и, соответственно, повысить уровень безопасности) за счет уменьшения количества учетных данных, которыми должны управлять пользователи.
Уменьшение времени на разработку. Написание собственного кода для управления именами и учетными данными для входа также подразумевает написание кода для создания учетных записей, изменения паролей, восстановления забытых паролей, реализации многофакторной проверки подлинности и условного доступа и многое другое. Сторонние поставщики удостоверений предоставляют эти службы бесплатно. Большая часть процесса кодирования состоит из взаимодействия с поставщиками удостоверений с помощью установленных протоколов. Существует множество библиотек, которые могут с этим помочь. Как правило, при использовании поставщиков удостоверений для реализации полной системы входа и управления учетными записями требуется менее 100 строк кода. В противоположность этому код, написанный поставщиком удостоверений, на порядок длиннее и сложнее.
На рисунке 3.1 показано упрощенное представление взаимодействия между пользователем и веб-сайтом, использующим сторонний поставщик удостоверений для проверки подлинности пользователей.
На сайте настроено использование для проверки подлинности пользователей поставщика удостоверений, которому он доверяет. Когда пользователь переходит на сайт или обращается к странице, требующей проверки подлинности, сайт обращается к поставщику удостоверений и запрашивает проверку подлинности пользователя.
Поставщик удостоверений запрашивает у пользователя ввод учетных данных. Поставщик использует эти учетные данные для установления личности пользователя и выдает маркер безопасности, подтверждающий эту личность. Маркер содержит цифровую подпись для предотвращения незаконного изменения. Иногда он также содержит такую информацию, как имя и фамилия пользователя и адрес электронной почты.
Браузер передает маркер на веб-сайт. Веб-сайт проверяет подлинность маркера.
Если проверка прошла успешно, пользователю разрешается продолжить работу.
Рис. 3.1. Проверка подлинности пользователей веб-сайта.
Как правило, после того как веб-сайт подтвердил допустимость маркера, он создает зашифрованный файл cookie HTTP со сведениями об удостоверении пользователя. Таким образом спустя некоторое время пользователь может вернуться на страницу без необходимости повторного входа. Файл cookie эффективно выполняет проверку подлинности пользователя в последующих запросах, так же как маркер идентификации после первоначального запроса.
Важной функцией этого потока является то, что на сайте никогда не отображаются учетные данные пользователя. На самом деле на сайте отсутствует информация о том, как пользователь прошел проверку подлинности. Следовательно, ответственность за сохранность учетных данных пользователя ложится на поставщика удостоверений. Более того, владелец веб-сайта может изменить физический механизм, используемый для проверки подлинности пользователей (например, переключиться с имен пользователей и паролей на отпечатки пальцев), путем изменения конфигурации поставщика удостоверений, а не переписывания большого объема кода.
Проверка подлинности внутренних пользователей организации
Обсуждение в предыдущем разделе актуально для группы разработчиков программного обеспечения, создающей веб-сайт, который поддерживает прошедших проверку пользователей за пределами организации. Но предположим, что вы являетесь ИТ-администратором и вам нужно выполнять проверку подлинности пользователей в организации для обеспечения безопасного доступа к общим папкам и другим локальным ресурсам. Для этого требуется другой подход к удостоверению.
В большинстве предприятий сведения об удостоверениях пользователей в организации (например, сотрудников компании) хранятся локально в службе каталогов. Служба хранит имена пользователей, хэши паролей и другие сведения в базе данных (обычно это распределенная база данных, которая поддерживает иерархические графы) и отображает ее содержимое с помощью таких стандартных протоколов, как LDAP. (Некоторые службы каталогов используют собственные протоколы, но они становятся менее распространенными, так как организации все чаще переносятся на открытый код и открытые стандарты.) При входе и выходе из организации администраторы обновляют каталог соответствующим образом. Когда пользователь покидает организацию и удаляется из каталога, он больше не может получить доступ к ресурсам в сети организации.
Одной из наиболее распространенных служб каталогов является Microsoft Active Directory. Она представляет собой семейство служб, предназначенных для хранения сведений о пользователях и безопасного доступа к сетевым ресурсам. Active Directory хранит объекты, которые могут представлять пользователей, компьютеры, общие папки, принтеры и другие ресурсы. Объекты можно организовать в домены, домены можно организовать в деревья, а деревья — в леса. Это обеспечивает гибкость, необходимую для моделирования больших и малых организаций.
Не нужно понимать работу служб каталогов, протоколы, которые они используют, или поток данных, который совершается с использованием этих протоколов. Важно знать, что службы каталогов предоставляют центральный репозиторий для сведений об удостоверениях пользователей в организации. Как вы узнаете далее, локальные службы каталогов можно расширить, чтобы они также применялись к облачным ресурсам, позволяя организациям выполнять проверку подлинности пользователей, получающих доступ к облачным ресурсам, таким же способом, как при доступе к локальным ресурсам. Среди прочего, это позволяет администраторам обеспечивать безопасный доступ к облачным ресурсам, используя те же удостоверения, что и для безопасного доступа к локальным ресурсам. Более того, такой подход позволяет пользователям использовать один набор учетных данных для доступа к обоим ресурсам.
Ссылки
- Auth0 (2018 г.). Добавление соли в хэширование: лучший способ хранения паролей. https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/.