Идентификация и аутентификация, управление доступом

~ 45 минут

В 2017 году из-за слабых мер аутентификации и управления доступом произошла утечка данных в компании Equifax, когда были скомпрометированы личные данные 147 миллионов человек. Это привело к многомиллиардным убыткам и тяжёлым юридическим последствиям.

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

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

Сергей

С каким кейсом будем работать?

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

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

Сам процесс выглядит так:

Поступление и договор с Минобром
Каждый студент поступает на курс и заключает договор, который обеспечивает ему доступ к единой системе обучения. После зачисления студенту открывается доступ к программе и он может выбирать модули на разных платформах. Программа строится так, чтобы каждый модуль охватывал важные аспекты архитектуры ПО. А платформы предоставляют разнообразие подходов и учебных материалов.
Выбор платформы для обучения
После регистрации студент получает возможность выбрать, на какой платформе ему удобнее проходить тот или иной модуль. Например, если студент заинтересован в изучении проведения аудита ИБ, он может выбрать этот модуль на одной платформе, а другие специфичные темы может изучить на других платформах. Каждый модуль привязан к общей программе, так что вся учебная история и прогресс сохраняются в единой системе Минобра.
Завершение обучения
По мере прохождения модулей на разных платформах система синхронизирует все данные о прогрессе и успеваемости студентов в единой базе данных Минобра. Это даёт возможность отслеживать успехи студентов, обмениваться информацией между платформами и учитывать все достижения в одном месте. Когда студент завершает все модули, ему выдаётся диплом об окончании курса от Минобра.

А передача данных происходит следующим образом:

Студент завершает модуль на платформе А.
Платформа А отправляет запрос на синхронизацию данных в единую базу Минобра, используя уникальный идентификатор студента и информацию о завершённом модуле.
Единая база данных проверяет аутентификацию платформы и актуализирует прогресс студента.
Прогресс студента обновляется на остальных платформах, при этом другим платформам сообщается только факт о прохождении модуля — без доступа к личным данным студента. Если в этой платформе нужно получить данные, то она выполняет дополнительный запрос к Минобру, в рамках которого проходит те же этапы — идентификации, аутентификации и авторизации. Например, платформа может запросить полученную за модуль оценку, чтобы соотнести материал следующего модуля с уровнем студента, а Минобр проверит, разрешено ли запрашивать этой платформе такую информацию.

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

✏️ Идентификация — процесс определения пользователя, в ходе которого система узнаёт, кто пытается получить доступ к ресурсу. Это первый рубеж, обеспечивающий безопасность системы.

На этом этапе система ещё не проверяет подлинность пользователя, но может определить какие-либо вспомогательные данные, например IP-адрес, местоположение или тип устройства. Мы ошибёмся, если скажем, что на этом этапе угроз нет. Но хорошая новость состоит в том, что существуют несложные и достаточные методы защиты.

Атаки на этапе идентификации направлены на компрометацию процесса распознавания пользователя или системы ещё до подтверждения их подлинности.

Разберём типовые угрозы и способы защиты.

1. Подмена идентификатора (ID Spoofing)

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

URL вида https://example.com/user/1234/profile позволяет злоумышленнику подставить другой ID, например https://example.com/user/5678/profile, и получить доступ к чужому профилю.

💡 Как защититься:

Проверять права доступа к ресурсам, связанным с каждым идентификатором.
Использовать безопасные токены вместо идентификаторов, передаваемых через URL.
Шифровать или маскировать идентификаторы.

2. Сбор информации (Information Harvesting)

На этапе идентификации злоумышленники могут собирать информацию о системе или пользователях для последующих атак. Это могут быть перечисления пользователей (Username enumeration), сбор публичных идентификаторов, раскрытие структуры URL или API и так далее.

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

💡 Как защититься:

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

3. Атака на перехват идентификационных данных (Session Hijacking)

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

💡 Как защититься:

Применять флаги безопасности для куки (HttpOnly, Secure).
Использовать защищённые каналы передачи данных (HTTPS).

Использование флагов HttpOnly и Secure

Допустим, образовательная платформа использует куки для отслеживания сессий студентов. Если куки не помечены флагом HttpOnly, злоумышленник, использующий вредоносный скрипт (атака XSS), может получить доступ к этим куки и украсть сессионные данные. Добавление флага HttpOnly предотвращает доступ к куки через скрипты, что снижает риск атаки.

Пример конфигурации куки с флагами безопасности:

JSX

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Strict;

HttpOnly запрещает доступ к куки через JavaScript.
Secure гарантирует, что куки будут переданы только через зашифрованное соединение (HTTPS).
SameSite=Strict ограничивает передачу куки только в рамках одного сайта, что защищает от CSRF-атак.

Использование HTTPS

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

В реальном сценарии пользователи могут быть особенно уязвимы, если они подключаются к платформе через общедоступные Wi-Fi-сети. Принудительное использование HTTPS минимизирует риск перехвата данных сессии в таких ситуациях.

4. Подбор идентификатора (Identifier Guessing)

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

Предположим, образовательная платформа присваивает студентам идентификаторы в виде последовательных целых чисел. Идентификатор одного студента может быть 1234, а второго — 1235. Злоумышленник может попробовать изменить URL, чтобы получить доступ к чужому профилю, подставив другой идентификатор, например https://platform.com/student/1235.

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

💡 Как защититься:

Использовать случайные и сложные идентификаторы. Вместо последовательных чисел система может использовать UUID (универсально уникальные идентификаторы), которые сложно предсказать. Например, https://platform.com/student/d7f4a29b-e75b-4d23-bb74-81fce3a3b354. Это значительно усложняет попытки подбора идентификатора.
Установить строгие проверки прав доступа. Даже если злоумышленник подберёт сложный идентификатор, система должна проверять, имеет ли текущий пользователь право доступа к запрашиваемому ресурсу.

5. «Человек посередине» (Man-in-the-Middle, MITM)

Атака происходит, когда злоумышленник встраивается между клиентом и сервером, перехватывая идентификационные данные, которые передаются по незащищённому каналу (публичные Wi-Fi сети).

Представим, что студент подключается к образовательной платформе через публичную Wi-Fi сеть, например в кафе или аэропорту. Если соединение между устройством студента и сервером образовательной платформы не защищено (например, не используется HTTPS), злоумышленник, находящийся в той же сети, может перехватить трафик и получить доступ к сессионным данным — куки или учётным данным. После этого злоумышленник может воспользоваться этими данными, чтобы выдать себя за студента и получить доступ к его учебному профилю.

💡 Как защититься:

Использовать только зашифрованные соединения (HTTPS, VPN).
Реализовать проверку целостности сообщений (например, с использованием цифровых подписей или HMAC) для предотвращения изменения данных при передаче.

Пример: вход в систему с нового устройства

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

Пример: обмен информацией о прогрессе между платформами

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

Важно исключить ошибки или подмену идентификаторов, чтобы прогресс одного студента не был случайно передан другому. Для этого можно использовать уникальные идентификаторы (например, UUID), которые не могут быть скомпрометированы или легко предсказаны. Платформы смогут сверять данные с единой базой данных Минобра.

Аутентификация

✏️ Аутентификация — это процесс подтверждения личности пользователя или системы перед предоставлением доступа к ресурсу. После идентификации система запрашивает подтверждение с помощью пароля, одноразового кода, биометрии или других факторов.

Только после успешной аутентификации пользователь получает возможность взаимодействовать с системой.

Ошибки в проектировании системы безопасности, такие как слабая политика паролей, могут привести к серьёзным последствиям. Допустим, если система позволяет пользователям выбирать короткие или простые пароли (например, «123456» или «password»), значительно повышается риск успешной атаки методом перебора (brute force). Злоумышленник может использовать специальные программы для автоматического подбора паролей, перебирая тысячи или даже миллионы комбинаций, пока не будет найден правильный пароль.

Слабая политика паролей повышает риск атак методом перебора (brute force), а отсутствие дополнительных методов аутентификации, таких как многофакторная аутентификация (MFA), облегчает жизнь злоумышленникам.

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

Факторы аутентификации

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

Что-то, что вы знаете (knowledge). Это парольная аутентификация. Она предполагает использование секретного вопроса, пароля или PIN-кода — информации, которой владеет только пользователь. Требует внедрения сложных политик управления паролями для защиты от подбора.
Что-то, что у вас есть (possession). Одноразовые пароли (OTP) — генерация уникальных токенов, отправляемых на мобильные устройства. Они упрощают защиту доступа при высоком уровне безопасности. Или аппаратные токены, такой способ защиты предполагает использование физических устройств (например, YubiKey) для подтверждения аутентификации.
Что-то, что вы представляете собой (inherence). Это биометрическая аутентификация с использованием биометрических данных: отпечатков пальцев, распознавания лица, — для подтверждения личности пользователя.

Сергей

По скольким факторам происходит аутентификация?

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

Трёхфакторная аутентификация (3FA) предполагает использование всех трёх категорий факторов аутентификации для проверки личности пользователя: knowledge, possession и inherence.

На практике 3FA не всегда понимается корректно: некоторые системы применяют три или более факторов, но все они могут относиться к одной категории. Например, два разных пароля и секретный вопрос — всё это относится к типу «что-то, что вы знаете». Более правильным термином в большинстве таких случаев является многофакторная аутентификация (MFA), которая описывает использование нескольких факторов аутентификации, независимо от их категории.

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

Пароль — стандартный фактор, который пользователь вводит при входе в систему.
SMS-код или голосовой вызов. После ввода пароля пользователь получает одноразовый код по SMS или голосовым вызовом, который необходимо ввести для завершения аутентификации.
Google Authenticator. Пользователь может использовать приложение Google Authenticator для генерации временных одноразовых паролей, которые меняются каждые 30 секунд.

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

💡 Лучшие практики

Регулярно обновлять факторы аутентификации.
Использовать приложения для аутентификации, которые не зависят от сети (например, Google Authenticator или Authy).
Настроить оповещения о подозрительных входах в систему.

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

Протоколы аутентификации

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

OAuth 2.0
Один из наиболее часто используемых протоколов аутентификации и авторизации. Он позволяет сторонним приложениям безопасно получать ограниченный доступ к ресурсам без передачи учётных данных пользователя.
OpenID Connect (OIDC)
Эта надстройка над OAuth 2.0 позволяет осуществлять аутентификацию пользователей. OIDC упрощает управление идентификацией в распределённых системах, передавая безопасные идентификационные токены между сервисами.
SAML (Security Assertion Markup Language)
Протокол, применяемый для организации SSO между разными доменами и приложениями. В отличие от OAuth и OIDC, SAML передаёт информацию об идентификации в формате XML.
Kerberos
Протокол аутентификации, основанный на использовании симметричных криптографических ключей и билетной системы. Часто применяется в корпоративных сетях и системах, работающих в домене Windows.

Пример: вход в систему с нового устройства

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

Пример: обмен информацией о прогрессе между платформами

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

Важно убедиться, что обе платформы аутентифицировали запрос передачи данных. Для этого можно использовать системы API-аутентификации, такие как OAuth 2.0, которые позволяют безопасно обмениваться информацией. Платформы должны использовать защищённые протоколы для передачи токенов, подтверждающих аутентификацию. Это гарантирует, что данные передаются только между доверенными системами.

Инструкция по внедрению многофакторной аутентификации

Оцените, есть ли потребность в MFA
- Анализ рисков: проведите оценку уязвимостей для выявления систем и данных, требующих дополнительной защиты. Учитывайте последствия утечек данных и соответствие законодательным требованиям.
- Определение пользователей: определите группы пользователей, которые должны использовать MFA, включая администраторов, финансовые и операционные команды, а также клиентов.
Выберите методы MFA
- Комбинация факторов: рассмотрите использование нескольких факторов аутентификации для повышения безопасности (например, пароли + одноразовые пароли (OTP) + биометрия).
- Аппаратные токены: обсудите использование аппаратных токенов (например, YubiKey) для критически важных операций.
- Сравнение решений: Проведите анализ доступных решений для MFA (например, КриптоПро) с точки зрения интеграции и поддержки.
Проектирование архитектуры MFA
- Интеграция с существующими системами: Разработайте стратегию интеграции MFA с текущими системами аутентификации, такими как Active Directory или LDAP.
- Обеспечение совместимости: Убедитесь, что выбранные методы MFA совместимы с существующими приложениями и сервисами.
Реализация MFA
- Настройка политики MFA: Определите правила, когда MFA будет обязательна (например, при входе с нового устройства или из нового местоположения).
- Тестирование: Проведите пилотное тестирование на ограниченной группе пользователей для выявления возможных проблем.
Обучение и информирование пользователей
- Кампания по осведомлённости: Запланируйте кампанию по информированию сотрудников о преимуществах MFA и о том, как правильно её использовать.
- Ресурсы для обучения: Предоставьте учебные материалы, видеоролики и часто задаваемые вопросы (FAQ) для поддержки пользователей.
Мониторинг и поддержка
- Отслеживание показателей MFA: Установите метрики для оценки эффективности MFA и реагирования на инциденты.
- Регулярные аудиты: Проводите регулярные аудиты системы MFA для выявления проблем и улучшения.
Документация и соблюдение требований
- Документирование процессов: Зафиксируйте все процессы и процедуры, связанные с внедрением и управлением MFA.
- Соблюдение стандартов: Убедитесь, что внедрение MFA соответствует корпоративным и законодательным стандартам безопасности (например, 152-ФЗ).

Что почитать про аутентификацию

Анализ утёкших учётных записей и паролей за 2023 год
Authy — приложение для двухфакторной аутентификации, которое генерирует одноразовые коды.
КриптоПро — ПО для шифрования информации, создания и проверки электронной подписи и защиты соединений с помощью криптографических протоколов.
Axiad — система мобильной аутентификации, ориентированная на корпоративный сектор.

Авторизация и управление доступом

После идентификации и аутентификации начинается процесс авторизации.

В рамках этого процесса определяется, какие именно действия в системе может совершать пользователь. Грамотное управление доступом на этом этапе позволяет минимизировать риск несанкционированных действий и защитить критические ресурсы.

В зависимости от гибкости системы и требований безопасности команда может выбрать один из методов авторизации. Например, доступ может предоставляться на основе роли пользователя — role-based access control (RBAC), на основе атрибутов пользователя, объекта и среды — attribute-based access control (ABAC) или в зависимости от контекста пользователя — contextual access.

Выбор метода авторизации определяет, какие архитектурные элементы и возможности необходимо внедрить в систему. Например, ABAC отлично подходит для крупных систем со множеством ресурсов и сложными требованиями к управлению доступом. Но в архитектуре системы необходимо предусмотреть хранение и управление атрибутами (должность, отдел, IP-адрес или даже время суток), а также поддержку сложных логических правил для принятия решений об авторизации.

В наиболее распространённой модели RBAC доступ предоставляется на основе роли пользователя — каждая роль содержит набор разрешений на выполнение определённых действий в системе, так называемых привилегий.

💡 Важно, чтобы доступы в системе были чётко определены и соотносились с бизнес-процессами, а само распределение этих разрешений соответствовало принципам информационной безопасности.

Современные организации следуют этим принципам для повышения безопасности своих систем и процессов. Мы перечислим несколько основных и дальше подробно разберём один из них.

Принцип наименьших привилегий (Least Privilege) предполагает, что пользователи и системы должны иметь доступ только к тем ресурсам и функциям, которые необходимы для выполнения их задач, и не больше.
Принцип разделения обязанностей (Separation of Duties). Ключевые задачи распределяются между разными сотрудниками, чтобы ни один человек не контролировал весь процесс целиком. Например, один человек не должен иметь возможность и инициировать, и утверждать финансовую транзакцию.
Принцип доверия с осторожностью (Zero Trust). Согласно этому принципу никто не считается безопасным по умолчанию — все пользователи и устройства постоянно проверяются и подтверждаются.
Принцип открытой безопасности (Security in the Open). Разработчики должны учитывать потенциальные уязвимости в своём коде, применять безопасные методы кодирования, тестировать ПО и сотрудничать с экспертами по безопасности для обеспечения безопасности конечного продукта.

Все они так или иначе связаны друг с другом и могут пересекаться в плане реализации. Предлагаем подробнее остановиться на принципе наименьших привилегий.

Принцип наименьших привилегий (Least Privilege Access, LPA)

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

В качестве примера можно привести иерархию пользователей и их привилегий в системе:

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

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

Реализация принципа наименьших привилегий

Шаг 1. Определить роли и разрешения

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

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

Шаг 2. Применить атрибутивное управление доступом (ABAC)

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

Шаг 3. Провести регулярный аудит и пересмотр ролей

Аудит ролей и прав доступа следует проводить на регулярной основе (например, раз в полгода) или по мере внесения изменений в организацию. Удобно использовать автоматизированные инструменты, чтобы анализировать права доступа и выявлять избыточные привилегии. Роли и разрешения обновляются в соответствии с изменениями в организационной структуре или при обнаружении избыточных привилегий.

Шаг 4. Внедрить временные роли

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

Так реализуется модель доступа Just-In-Time (JIT), когда привилегии выдаются только на короткий период времени и автоматически отзываются по истечении срока.

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

Шаг 5. Настроить контекстное управление доступом

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

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

Пример: вход в систему с нового устройства

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

Пример: обмен информацией о прогрессе между платформами

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

Важно, чтобы передача данных была минимальной. Передаваться должны только необходимые сведения, такие как статус выполнения модулей, оценки и комментарии преподавателей.

Для этого можно использовать атрибутивное управление доступом (ABAC), где данные о прогрессе передаются только с разрешения Минобра и соответствуют условиям авторизации (например, только по завершённым модулям, без лишней информации).

Что почитать про авторизацию

Пример удачного использования принципа наименьших привилегий
What is Just-in-Time Access? A Complete Guide — статья о модели доступа Just-in-Time Access (JIT).
Secure Product Design Cheat Sheet — памятка по безопасному проектированию продуктов с обзором принципов безопасности.
VK ID — система единого входа для авторизации на различных платформах с использованием учётной записи VK.
Active Directory от Microsoft — инструмент IAM. Он предоставляет возможности централизованного управления пользователями и группами, а также поддержки многофакторной аутентификации (MFA).
1С:Предприятие — эта платформа включает встроенные функции управления доступом, позволяющие настраивать права пользователей в зависимости от их ролей и обязанностей.

Типичные проблемы управления доступом

Централизованное управление доступом и его недостатки

Централизованное управление доступом предполагает, что все компоненты системы (веб-приложения, мобильные приложения, базы данных и API) используют один и тот же сервис для аутентификации и авторизации пользователей. Этот сервис становится единой точкой отказа или компрометации, злоумышленник может получить доступ к обширным ресурсам системы.

Что делать:

Разделить обязанности Разделите компоненты системы на независимые модули, каждый из которых отвечает за свою часть аутентификации и авторизации. Например, для веб-приложений используйте OAuth 2.0 и OpenID Connect, а для внутренних систем — отдельный модуль аутентификации (например, на базе Kerberos или SAML).

Изолировать сервисы Разделите задачи управления идентификацией, аутентификацией и авторизацией. Даже в рамках централизованного подхода различные аспекты управления доступом можно разделить по разным сервисам, что снизит риск полной компрометации при взломе одного из них.

Избыточные привилегии пользователей

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

Что делать:

Применять принцип наименьших привилегий (Least Privilege Access) Проектируя систему, создавайте роли с минимально возможными привилегиями. Определите типичные сценарии использования системы, чтобы понять, какие права действительно необходимы пользователям.

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

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

Сложности в управлении контекстным доступом

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

Что делать:

Использовать гибкие политики При проектировании архитектуры используйте системы управления доступом, которые поддерживают атрибутивное управление доступом (ABAC). Это позволит создавать гибкие и динамичные политики на основе различных атрибутов и контекстов (например, времени суток, IP-адреса, устройства или геолокации).
Внедрить мониторинг и машинное обучение Внедрите системы мониторинга, использующие машинное обучение для анализа поведения пользователей. Автоматический анализ поведенческих данных поможет выявлять аномалии и улучшать контекстные политики доступа.
Использовать простые правила Начните с базовых правил контекстного доступа и постепенно усложняйте их по мере накопления статистики использования. Например, начните с ограничений на геолокацию и уже после накопления данных добавляйте более сложные правила.

Проблемы интеграции

Интеграция современных протоколов (OAuth 2.0, OpenID Connect, SAML) с уже существующими системами может быть сложной задачей. Ошибки при интеграции приводят к уязвимостям, связанным с передачей и хранением токенов, неправильной обработкой запросов авторизации или подменой токенов.

Что делать:

Тщательно проектировать схемы работы Продумайте архитектуру взаимодействия между сервисами на этапе проектирования. Используйте OpenID Connect для веб-приложений и OAuth 2.0 для доступа к API.
Безопасно хранить и передавать токены Предусмотрите защищённые методы хранения токенов (например, в зашифрованном хранилище) и их безопасную передачу по защищённым каналам (TLS). Не используйте токены доступа в URL-запросах, так как они могут быть перехвачены.
Создать многоуровневую авторизацию Проектируя систему, создайте многоуровневый процесс авторизации. Например, при входе пользователя с использованием OpenID Connect система сначала получает токен доступа, а затем применяет дополнительные политики авторизации, чтобы обеспечить минимальные привилегии.

Проблемы с масштабируемостью

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

Что делать:

Организовать децентрализацию и кеширование Проектируйте архитектуру так, чтобы каждый сервис мог использовать локальное кеширование данных об аутентификации и авторизации, синхронизируя его с центральным хранилищем по мере необходимости. Например, микросервисы могут использовать кешированные токены JWT для проверки доступа без обращения к центральному серверу.
Использовать масштабируемые протоколы Используйте протоколы, оптимизированные для распределённых систем, такие как OAuth 2.0 и OpenID Connect. Они позволяют использовать токены с ограниченным сроком действия и поддерживают масштабируемое управление сеансами.

Задание 1

Компания разрабатывает систему управления проектами для внутренних сотрудников. При обсуждении политики безопасности было решено использовать двухфакторную аутентификацию (2FA) с использованием одноразовых паролей (OTP), отправляемых на мобильный телефон пользователя. Но один из сотрудников выразил обеспокоенность тем, что не сможет войти в систему, если потеряет доступ к своему телефону.

Какое решение следует внедрить, чтобы обеспечить доступ сотрудников в подобных ситуациях, не снижая уровень безопасности?

Отключить 2FA для всех сотрудников

Отключение 2FA значительно снизит уровень безопасности системы и сделает систему уязвимой для атак. Это решение не является безопасным и не решает проблему потерянного телефона.

Предусмотреть резервные методы аутентификации, такие как использование резервных кодов

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

Использовать только пароль для аутентификации

Использование только пароля снижает безопасность системы, так как пароль может быть легко скомпрометирован с помощью методов, таких как перебор (brute force). Двухфакторная аутентификация (2FA) обеспечивает дополнительный уровень защиты, и замена её на только пароль — неэффективное решение.

Разрешить вход без 2FA, если система обнаружит, что пользователь находится в офисе компании

Вход без 2FA, даже в офисе компании, создаёт серьёзную уязвимость, поскольку злоумышленник может воспользоваться этой лазейкой. Устройства и данные могут быть скомпрометированы даже в физически безопасной зоне. Для поддержания высокого уровня безопасности важно сохранять 2FA в любых условиях.

Задание 2

Компания недавно провела аудит системы безопасности и выяснила, что одному из системных администраторов были предоставлены полномочия на доступ к данным, которые не требуются для его повседневной работы. Кроме того, обнаружилась проблема отсутствия регулярного пересмотра прав доступа сотрудников.

Что нужно сделать для соответствия принципу наименьших привилегий и устранения проблемы?

Автоматизировать процесс выдачи прав доступа на основе атрибутов (например, должность, отдел)

Это хорошая практика для управления доступом, но не решает проблему с избыточными привилегиями и регулярным пересмотром прав.

Удалить все учётные записи сотрудников, которые не используют свои права доступа

Удаление учётных записей не является эффективным решением в данном случае, так как речь идёт о проблеме с избыточными правами доступа, а не с неиспользуемыми учётными записями.

Запретить администраторам выполнять любые действия без одобрения

Это чрезмерно строгая мера, которая может снизить продуктивность работы. Важно не запрещать действия, а грамотно распределять привилегии.

Ввести политику выдачи временных привилегий для выполнения специфических задач

Введение временных привилегий позволяет сотрудникам получать доступ только на время выполнения конкретной задачи, что соответствует принципу наименьших привилегий.

Итоги

Идентификация — это процесс установления личности пользователя, при котором система определяет, кто пытается получить доступ к её ресурсам. Это начальный уровень защиты системы, где важно учитывать такие угрозы, как подмена личности, сбор данных, перехват информации, подбор учётных данных и атаки типа «человек посередине».
Аутентификация — это проверка и подтверждение личности пользователя или системы перед предоставлением доступа к ресурсам. После идентификации система требует подтверждения с использованием паролей, одноразового кода, биометрических данных или с помощью других методов. Факторы аутентификации делятся на три группы: то, что вы знаете (например, пароль), то, что у вас есть (например, токен или телефон с одноразовым кодом), и то, что вы собой представляете (например, отпечаток пальца). Многофакторная аутентификация использует сочетание этих факторов для повышения уровня безопасности.
Авторизация — это процесс определения действий, которые пользователь может выполнять в системе. Эффективное управление доступом на этом этапе помогает снизить риск несанкционированных действий и защитить важные ресурсы. Доступ может быть организован по ролям (RBAC), атрибутам пользователя и среды (ABAC) или в зависимости от контекста (contextual access). Важно, чтобы управление доступом соответствовало принципам информационной безопасности.
Принцип наименьших привилегий — это базовый принцип информационной безопасности, который подразумевает, что пользователи и приложения получают минимально необходимые права для выполнения своих задач. Этот принцип может применяться при проектировании различных систем, таких как микросервисные архитектуры, чтобы минимизировать риски и обеспечить лучшую безопасность.