Сотрудник ввёл логин, подтвердил вход и открыл рабочую программу. Для него это одно действие — «зайти в систему». Для компании здесь три разных вопроса: какую учётную запись выбрали, как проверили входящего и какие действия ему разрешили. Разобраться в них полезно руководителю, администратору и каждому, кто согласует доступ к данным.
Сотрудникам — нужный доступ
Понятный вход и права для рабочих задач без чужих учётных записей и постоянных просьб выдать администратора.
Бизнесу — управляемые полномочия
Видно, кому, для чего и на какой срок открыты данные; доступ можно пересмотреть и отозвать.
Три понятия: короткое сравнение
| Понятие | На какой вопрос отвечает | Пример |
|---|---|---|
| Идентификация | Какая это учётная запись или субъект? | Указали логин сотрудника или система получила его идентификатор |
| Аутентификация | Чем подтверждено право действовать от этой учётной записи? | Проверили пароль, ключ или другой настроенный способ входа |
| Авторизация | Разрешено ли этому субъекту выполнить конкретное действие? | Разрешили чтение документа, но запретили изменение и удаление |
Логин помогает выбрать запись, но сам по себе ничего не доказывает: адрес коллеги можно знать. Проверка входа тоже не даёт всех прав. Пользователь может успешно войти в приложение и не иметь доступа к определённому отчёту.
Это упрощённое объяснение рабочего входа. В документах термин «идентификация» имеет и более широкий смысл; определения приведены в глоссарии NIST, а проверка подлинности раскрыта в определениях аутентификации. Важно также отличать повседневный вход от первоначальной проверки личности при оформлении учётной записи.
Как это выглядит при работе с документами
Учебный пример: бухгалтер открывает корпоративный портал. Его рабочая роль позволяет читать документы своего подразделения и готовить отчёт. Изменять настройки пользователей ему не требуется.
Портал определяет учётную запись по логину или данным единого входа.
Проверяется настроенный способ аутентификации; при необходимости — дополнительный фактор.
Система разрешает работу с нужными документами и отклоняет запрещённые операции.
Управление доступом продолжается после входа. Если сотрудник пытается открыть другой объект или выполнить новую операцию, приложение должно проверить соответствующее разрешение. Скрытая кнопка сама по себе такую проверку не заменяет.
Зачем бизнесу разделять эти проверки
Не путать причины отказа
Забытый пароль, блокировка записи и отсутствие прав требуют разных действий. Не каждую проблему нужно решать выдачей новых полномочий.
Сократить лишний доступ
Для подготовки отчёта не обязательно разрешать управление всей системой или просмотр данных других подразделений.
Упростить кадровые изменения
При переводе и увольнении можно проверить роли, группы и приложения по понятному списку.
Сохранить историю действий
Именная запись и журналы помогают выяснять обстоятельства событий. Общий пароль затрудняет такую проверку.
При этом запись в журнале под именем сотрудника ещё не доказывает, что действие лично выполнил он: нужно учитывать передачу пароля, активные сеансы, автоматизацию и возможную компрометацию. Историю рассматривают вместе с другими фактами.
Пароль, MFA и ключ: что подтверждает вход
- Что человек знает: например, пароль.
- Чем владеет: устройство или ключ с настроенным аутентификатором.
- Биометрический признак: например, отпечаток для локальной активации аутентификатора.
MFA сочетает разные типы факторов. Два пароля не становятся двумя факторами. Биометрия в модели NIST не выступает самостоятельным аутентификатором: она может активировать физический аутентификатор. Конкретную схему нужно оценивать целиком.
Способы MFA неодинаково защищают от фишинга. Введённый вручную одноразовый код могут выманить и передать настоящему сервису. Механизмы FIDO2/WebAuthn связывают проверку с настоящим сайтом; свойства зависят от реализации и настройки. Учитывайте также регистрацию нового устройства и восстановление доступа. Основа этих различий — NIST SP 800-63B-4.
Дополнительный фактор помогает защитить вход, но не исправляет чрезмерные права уже вошедшего пользователя.
Как выдавать права под рабочую задачу
Начните с перечня ресурсов и операций: читать, создавать, изменять, удалять, выгружать, согласовывать, администрировать. Даже внутри одной программы они могут относиться к разным объектам и областям данных.
- Роль: набор полномочий для определённой работы.
- Граница данных: своё подразделение, проект или согласованный список объектов.
- Срок: постоянная обязанность или временная задача.
- Основание: кто запросил и кто согласовал доступ.
- Проверка: нужная операция доступна, лишняя — отклоняется.
Например, временное участие в проекте не требует автоматически копировать все права руководителя. Это редакционный пример применения минимальных полномочий. Рекомендации проверять разрешения при каждом запросе и запрещать доступ без явного основания приведены в руководстве OWASP по авторизации.
Проверяйте и чтение, и изменение данных. Просмотр чужой карточки может быть нарушением даже без права её редактировать. Точные правила определяет владелец соответствующего ресурса совместно с ответственными специалистами.
Что меняет единый вход — SSO
SSO позволяет использовать результат входа в доверенную систему идентификации для связанных приложений. Пользователю не обязательно вводить отдельный пароль в каждом сервисе. Но приложению всё равно нужно определить, какие действия ему разрешить.
Одинаковый пароль в нескольких программах сам по себе не является SSO. И единый вход не означает единую роль: доступ к почте, бухгалтерским документам и панели управления облаком может различаться.
На уровне протоколов тоже есть различия. OAuth 2.0 используется для делегированного доступа, а OpenID Connect добавляет слой аутентификации. Для проверки входа нельзя произвольно подменять предназначенные для него данные любым токеном доступа. Это поясняется в документации Microsoft по OpenID Connect.
Соответствие учётных записей и ролей, вход нового сотрудника, изменение полномочий, недоступность поставщика идентификации и прекращение доступа. Наличие кнопки «Войти» — только начало проверки.
Почему смены пароля иногда недостаточно
После входа приложение обычно поддерживает сеанс. У пользователя также могут быть токены, подключённые устройства и отдельные ключи интеграций. Их сроки и способы отзыва определяются конкретными системами.
Поэтому при прекращении доступа нужно проверить не только возможность нового входа, но и уже открытые сеансы. Смена пароля не является универсальным способом немедленно завершить их во всех приложениях. Закрытие окна браузера тоже не гарантирует выход.
Управление временем жизни сеанса, явный выход и прекращение действия на стороне сервера разобраны в руководстве OWASP по сеансам. Для своей инфраструктуры составьте проверяемый перечень: запись, сеансы, токены, устройства и отдельные подключения.
Приём, перевод и увольнение: доступ как процесс
- Приём: подтвердить сотрудника и рабочую роль, оформить согласование, создать именную запись и выдать необходимые способы входа.
- Работа: учитывать изменения обязанностей, временные разрешения и восстановление доступа.
- Перевод: проверить не только новые, но и прежние права; отменить больше не нужные полномочия.
- Завершение: прекратить доступ по согласованному порядку, проверить сеансы и передать рабочие ресурсы уполномоченным лицам.
- Пересмотр: сверить действующие роли, исключения и записи с владельцами сервисов.
Это пример организации работы, а не обязательный для любой компании регламент. Назначьте ответственных за согласование и исполнение: кадровая информация, решение о доступе и техническая настройка могут находиться у разных людей.
Отдельно учитывайте подрядчиков, привилегированные и сервисные записи. Для автоматизации нужны владелец, назначение и управляемые секреты; общая запись «на всякий случай» усложняет сопровождение. Маршрут запросов и согласований можно организовать через службу поддержки.
Не входит или не разрешено: что сообщить поддержке
| Наблюдение | Что проверить | Что передать специалисту |
|---|---|---|
| Запись не находится | Логин, организацию, нужный сервис и существование записи | Адрес сервиса и используемое имя без пароля |
| Вход отклонён | Текст ошибки, блокировку, настроенный фактор и состояние входа | Время, сообщение и этап отказа |
| Вход успешен, документ закрыт | Роль, объект и требуемую операцию | Какой ресурс нужен и кто согласовал доступ |
| После изменения прав поведение прежнее | Обновление групп, сеанс и правила конкретного приложения | Когда и какие изменения были выполнены |
Это направления диагностики, а не готовый диагноз по одному сообщению. Внешне одинаковый отказ может иметь разные причины. Не передавайте поддержке пароли, одноразовые коды, резервные коды и токены; из снимка экрана уберите лишние персональные и служебные сведения.
Не открывайте полный доступ только ради проверки. Лучше воспроизвести нужную операцию на согласованной учётной записи и среде, выяснить причину и оформить минимальное изменение.
Две формы для управления доступом
Матрица доступа
Кто, к какому ресурсу, с какими операциями и по чьему согласованию получает права.
Скачать матрицу · TXTПроверка изменения прав
Новый вход, действующие сеансы, разрешённые и запрещённые действия после изменения.
Скачать проверку · TXTФормы помогают собрать сведения и проверить результат. Конкретные роли, сроки и порядок согласования определяются для вашей компании.
Управление доступом в сопровождении и облаке
ИТ-аутсорсинг: порядок в учётных записях
- Собрать сервисы и владельцев доступа.
- Описать запросы, согласования и исполнение.
- Разобрать роли и временные исключения.
- Проверять изменения и прекращение доступа.
Обсудим задачи сопровождения и ответственность участников.
Обсудить управление доступомОблачные ресурсы: разделить полномочия
- Определить доступ к среде и приложениям.
- Разграничить административные операции.
- Согласовать порядок работы подрядчиков.
- Проверить восстановление и отзыв доступа.
Состав ресурсов, средства защиты и условия аренды уточняются по задаче.
Обсудить облачные ресурсыЧастые вопросы
Логин и пароль — это идентификация и аутентификация?
В простой схеме логин выбирает учётную запись, а проверка пароля подтверждает владение связанным секретом. В других схемах используются ключи, сертификаты или доверенный результат единого входа; отдельного ввода логина может не быть.
Авторизация — это вход по паролю?
В бытовой речи так иногда называют вход. Технически авторизация определяет, разрешено ли действие. Для рабочих документов лучше разделять вход и выдачу прав, чтобы не путать задачи поддержки.
Успешный вход означает доступ ко всем данным?
Нет. Он не отменяет проверку прав на ресурс и операцию. Например, чтение своего документа и удаление чужого — разные полномочия.
Два пароля считаются MFA?
Нет: это один тип фактора — знание секрета. Многофакторная аутентификация использует разные типы факторов; её свойства зависят от всей настроенной схемы.
Можно пользоваться одной учётной записью всем отделом?
Так сложнее ограничивать индивидуальные права, прекращать доступ конкретного сотрудника и разбирать события. Для обычной работы предпочтительны именные записи; особые технические случаи требуют отдельного порядка и ответственного.
После увольнения достаточно поменять пароль?
Нужно проверить способ прекращения доступа в каждой системе: состояние записи, активные сеансы, токены, устройства и отдельные подключения. Результат подтверждают проверкой, а не предположением, что один шаг автоматически охватил всю инфраструктуру.
Нужно проверить управление доступом и защиту учётных записей?
Контроль доступа включает жизненный цикл учётных записей, MFA, разграничение прав, журналирование и своевременное прекращение доступа.