Почему пароля недостаточно

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

Пароль отвечает только на один вопрос: может ли пользователь подтвердить, что учётная запись принадлежит ему?

Но корпоративной системе этого недостаточно.

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

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

Поэтому нормальная модель доступа выглядит не как «логин + пароль», а как целая система правил:

• › кто обращается;
• › как подтверждается личность;
• › от чьего имени выполняется запрос;
• › что разрешено;
• › к каким ресурсам;
• › на какое время;
• › в каком контексте;
• › что произошло с этим доступом.

Пароль решает только задачу аутентификации

Начнём с базового различия.

Это принципиально разные задачи.

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

Пароль не описывает ни одно из этих правил.

Из чего складывается нормальная модель доступа

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

Условно цепочка выглядит так:

И каждый уровень решает свою задачу.

Также используются:

• › одноразовые коды;
• › аппаратные ключи;
• › сертификаты;
• › биометрия;
• › многофакторная аутентификация;
• › корпоративные системы единого входа.

Таким образом, пароль — это только один элемент одного уровня всей модели.

Почему роли важнее списка паролей

В небольшой системе можно представить доступ как список:

Но в корпоративной инфраструктуре такой подход быстро перестаёт работать.

Сотрудников становится сотни или тысячи. Систем десятки. Полномочия меняются. Люди переходят между подразделениями, получают временные функции, уходят из компании.

Поэтому права обычно связывают не напрямую с человеком, а с ролью.

А другой сотрудник получает другую роль:

Это значительно упрощает управление.

Роль не всегда отвечает на все вопросы

Предположим, у пользователя есть роль менеджера по продажам.

Можно ли ему видеть всех клиентов?

Не обязательно.

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

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

Например:

А если системы взаимодействуют между собой?

Вот здесь модель доступа становится ещё интереснее.

Представим обычный бизнес-процесс:

Пользователь может вообще не взаимодействовать с ERP напрямую.

CRM передаёт данные интеграционному сервису, а тот обращается к ERP.

Возникает вопрос:

Не человек.

Не его пароль.

Запрос выполняет другой программный компонент.

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

Токен — это не «пароль в другом формате»

В современных системах часто используются токены.

И здесь возникает распространённое заблуждение: будто токен просто заменяет пароль.

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

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

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

Поэтому важен не сам факт наличия токена.

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

Чем опасны слишком широкие права

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

Ему действительно нужен доступ ко всей ERP?

Скорее всего, нет.

Если ему выдать права администратора «на всякий случай», система становится удобнее для разработчика, но значительно опаснее для бизнеса.

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

Принцип наименьших привилегий

Этот принцип особенно важен в больших информационных системах.

Идея проста:

Причём речь не только о пользователях.

Принцип одинаково относится к:

• › сотрудникам;
• › администраторам;
• › сервисным аккаунтам;
• › приложениям;
• › интеграциям;
• › API;
• › автоматизированным процессам.

На практике это означает, что доступ нужно проектировать не по принципу «что можно разрешить», а по принципу:

Доступ должен иметь жизненный цикл

Ещё одна распространённая проблема возникает не при создании доступа, а после него.

Сотрудник получает расширенные права для выполнения определённой задачи. Через полгода он переходит в другой отдел. Но права остаются.

В крупной компании такие изменения происходят постоянно:

Поэтому управление доступом должно быть связано с жизненным циклом сотрудника.

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

• › Именно здесь автоматизация управления доступом становится особенно важной.

Временный доступ — тоже часть модели

Отдельная категория — временные права.

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

• › Такой подход позволяет снизить количество постоянных привилегий и уменьшить риск забытых разрешений.
• › Особенно это важно для административного доступа.

Единый вход не означает единый доступ

Single Sign-On часто воспринимают как решение проблемы доступа целиком.

Но SSO решает прежде всего задачу удобной и централизованной аутентификации.

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

Можно иметь единый вход и при этом совершенно разные модели авторизации в CRM, ERP, BI-системе и внутренних приложениях.

• › Поэтому единая аутентификация — это фундамент, но не вся модель управления доступом.

Где чаще всего ломается корпоративная модель доступа

На практике проблемы часто возникают не в самом механизме входа, а на стыках.

• 1. Избыточные права:
  Доступ выдаётся шире, чем требуется. Причина обычно проста: так быстрее настроить систему. Проблема появляется позже — при изменении процессов, состава команды или компрометации учётной записи.
• 2. Общие учётные записи:
  Когда несколько сотрудников работают под одной учётной записью, исчезает нормальная персональная ответственность. Система видит «admin» или «manager», но не всегда может определить конкретного человека. Это особенно опасно для критичных операций.
• 3. Сервисные аккаунты без контроля:
  Техническая учётная запись может годами использоваться несколькими интеграциями, иметь широкие права и при этом никто точно не помнить, кому и зачем она была выдана.
• 4. Долгоживущие токены:
  Если токен действует слишком долго или имеет слишком широкую область доступа, его компрометация становится серьёзной проблемой.
• 5. Права не отзываются вовремя:
  Сотрудник уходит из компании или меняет должность, но доступы остаются.
• 6. Разные системы используют разные правила:
  В одной системе сотрудник считается менеджером, в другой — администратором, а в третьей информация о его роли вообще обновляется вручную. В результате возникает расхождение между фактическими полномочиями и тем, что должно быть разрешено сотруднику.
• 7. Нет нормального аудита:
  Система умеет разрешать и запрещать действия, но не сохраняет достаточную информацию о том, кто, когда и каким способом получил доступ к критичному ресурсу. В результате проблему обнаруживают, но восстановить последовательность событий уже сложно.

Безопасность доступа — это не только запреты

Есть ещё одна важная сторона.

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

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

Именно поэтому безопасность нельзя рассматривать отдельно от удобства эксплуатации.

Как выглядит зрелая модель доступа

Условно её можно представить так:

На каждом уровне есть собственная задача.

Именно поэтому невозможно решить всю проблему одним механизмом, будь то пароль, SSO, роль или токен.

Что это означает для корпоративных систем

Чем больше компания, тем меньше работает подход «давайте просто настроим доступ пользователям».

В небольшой системе можно вручную создать несколько ролей и на этом закончить.

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

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

Нужно понимать:

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

Пароль — только входная дверь

У корпоративной системы нет одного «пароля от всего».

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

• › Пароль отвечает на вопрос:
  «Можешь ли ты доказать, что ты — это ты?»
• › Корпоративная безопасность начинается со следующего вопроса:
  «Что именно тебе разрешено делать после этого?»
• › А в распределённой системе появляется ещё один:
  «Почему мы должны доверять этому сервису или системе и какие именно действия мы разрешаем ей выполнять?»

Поэтому зрелая модель доступа строится не вокруг паролей.

Она строится вокруг управления идентичностями, полномочиями и доверием между компонентами системы.

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

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

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).