Общие учётные записи можно классифицировать по трём признакам: последствиям неправильного использования, охвату доступа и возможности его контролировать. Для каждого признака задайте понятные уровни, а критичные ограничения отметьте отдельными флагами. Итог нужен для выбора мер и очередности работ, а не для вычисления вероятности взлома.
Ниже — внутренняя методика со шкалой от одного до трёх, условным примером и порядком пересмотра. Это авторский рабочий шаблон, не методика регулятора. Критерии согласуют владельцы систем и ИБ с учётом своих процессов: одинаковый балл у двух аккаунтов может означать разные проблемы и требовать разных действий.
Сначала определите, что именно оцениваете
В этой статье общим аккаунтом называем учётную запись, которой пользуются несколько людей. Сервисные учётные записи и токены интеграций включайте в тот же реестр риска, если это полезно для контроля, но отмечайте отдельным типом: автоматическое использование само по себе не делает аккаунт общим. Общий аккаунт отличайте от набора персональных аккаунтов: централизованное хранение их паролей само по себе не делает учётные записи общими. Для оценки риска важно понимать, кто действует в целевом сервисе и можно ли установить конкретного исполнителя.
Создайте короткий перечень объектов: общие административные логины, технические аккаунты приложений, доступы внешних подрядчиков, облачные консоли, резервные коды, токены интеграций. Объединять всё в одну категорию «пароли» неудобно: у каждого типа свои последствия отказа и возможности отзыва.
Для записи должны быть известны владелец сервиса, число фактических пользователей, предназначение, критичность данных, возможные действия в целевой системе и способ восстановления. Не нужно собирать сам пароль в оценочную таблицу — достаточно внутреннего идентификатора и защищённой ссылки на объект.
Если владелец неизвестен, отмечайте это как отдельный фактор неопределённости. Не назначайте низкий риск только потому, что никто не смог объяснить назначение аккаунта.
Три фактора: последствия, охват и сложность контроля
Предлагаем оценивать три свойства. Первое — последствия: какие данные, деньги или операции могут быть затронуты при неправильном использовании секрета. Второе — охват: скольким людям и системам доступ известен и насколько широко его можно применить. Третье — сложность контроля: насколько трудно обнаружить нежелательное использование, отозвать право и заменить реквизиты без длительного простоя. Чем сложнее контроль, тем выше балл по этому фактору.
Не подменяйте риск простым числом пользователей. У одного администратора может быть доступ ко всей производственной инфраструктуре, тогда как десять сотрудников совместно используют учётную запись для просмотра безопасного отчёта. Важны полномочия и последствия, а не только размер группы.
Для каждого фактора задайте качественные уровни. Например, низкое последствие — кратковременная остановка некритичного сервиса; высокое — невозможность восстановить работу ключевых систем или несанкционированное изменение чувствительных данных. Формулировки должны соответствовать вашей компании: универсальной границы в рублях здесь нет.
Обсудить проверку прав
Выберите обезличенные примеры записей разной критичности. Обсудим, как проверить разграничение прав в BearPass на пилоте.
Условная шкала — с понятным объяснением баллов
Для первоначального реестра можно использовать оценки от одного до трёх по каждому фактору. Это упрощение для расстановки приоритетов. Оно не является сертификационной методикой и не доказывает вероятность будущего инцидента.
| Фактор | 1 — меньшая выраженность | 2 — промежуточно | 3 — большая выраженность |
|---|---|---|---|
| Последствия | Локальная некритичная операция | Сбой работы подразделения | Доступ к критичным системам или значимым данным |
| Охват | Небольшой известный круг; один ресурс | Несколько команд или связанных ресурсов | Неучтённые получатели либо применение во многих системах |
| Сложность контроля | Быстрый отзыв и понятный аудит | Частично ручная ротация | Неясные владельцы, сложный отзыв или слабый контроль |
Можно суммировать баллы, но нельзя считать, что запись с девятью баллами в три раза опаснее записи с тремя. Числа показывают приоритет рассмотрения, а не объективное значение угрозы. Если высокий риск по последствиям является блокирующим условием, это должно работать независимо от общей суммы.
Проверьте шкалу на нескольких аккаунтах, хорошо знакомых команде. Если она даёт нелепый порядок — например, тестовый кабинет оказывается критичнее доступа к резервным копиям — уточните критерии до массовой классификации.
Не прячьте блокирующий фактор за средней оценкой. Простая сумма баллов удобна для сортировки, но у неё есть изъян. Аккаунт с максимальными последствиями и узким кругом пользователей может получить столько же баллов, сколько некритичный кабинет, доступный десяткам сотрудников. Однако мероприятия для них должны быть разными. Поэтому добавьте к шкале обязательные условия: привилегированная учётная запись, отсутствие владельца, доступ к резервным копиям, возможность финансовой операции и невозможность оперативного отзыва.
Если хотя бы один флаг означает неприемлемый для компании риск, запись должна идти на отдельное рассмотрение независимо от итоговой суммы. Проверяющий должен видеть не только «класс высокий», но и почему он назначен. Это позволяет избежать споров, когда разные подразделения пытаются получить более удобный рейтинг, просто изменяя веса.
Проверка устойчивости модели. Предложите двум специалистам независимо оценить одну выборку из пяти объектов. Затем сравните не только баллы, но и причины расхождений. Если один считает рекламный кабинет некритичным, потому что не отвечает за бюджет, а другой знает, что у аккаунта есть платёжные полномочия, проблему решает уточнение исходных данных, а не арифметическая формула. Только после согласования критериев стоит классифицировать остальной реестр.
Пример на трёх корпоративных аккаунтах
Допустим, у компании есть общий доступ к демостенду, рабочий рекламный кабинет и административный аккаунт инфраструктуры. Для демостенда последствия невелики, но доступ может быть известен многим стажёрам. Для рекламного кабинета последствия выше из-за возможных расходов и изменения настроек. Административный аккаунт может быть известен немногим, но его полномочия крайне чувствительны.
Заполните шкалу совместно с владельцами систем. Не определяйте класс из названия: «маркетинг» не всегда означает низкую критичность, а слово «сервер» ещё не доказывает высокую. Нужно оценить реальные действия и зависимости.
| Объект | Последствия | Охват | Сложность контроля | Что проверить |
|---|---|---|---|---|
| Демостенд | 1 | 3 | 1 | Не осталось ли доступа у бывших участников |
| Рекламный кабинет | 2 | 2 | 2 | Есть ли разделение платёжных прав и просмотра |
| Администрирование инфраструктуры | 3 | 1 | 3 | Работают ли отзыв, аварийный доступ и восстановление |
Это условные примеры. В конкретной компании финансовый кабинет может потребовать более строгого контроля, чем серверный доступ. Числа нельзя переносить без проверки контекста.
Подберите меры под характер риска
Для записи с высоким охватом полезно уменьшить число пользователей и заменить общий аккаунт персональными ролями в целевой системе, если это возможно. Когда основной риск связан со сложным отзывом, первыми мерами будут процедура ротации, учёт зависимостей и ответственное лицо. Необязательно снижать все три оценки одновременно: таблица должна показывать, какую конкретно проблему устраняет выбранное действие. Для критичной инфраструктуры нужны более строгие согласования и аварийный сценарий.
Корпоративный менеджер паролей помогает централизовать хранение и управлять разрешениями. Но он не меняет автоматически полномочия, которые уже существуют внутри сторонней CRM или банка. Если общий пароль предоставляет право на проведение платежей, необходимо пересмотреть сам аккаунт в целевой системе.
Установите требования к журналированию, не обещая невозможного. Журнал хранилища может отражать согласованные действия с записями; действия в целевом сервисе потребуют его собственных логов. Для расследования иногда нужно сопоставить оба источника.
При необходимости назначьте отдельные правила для внешних исполнителей. Временная выдача доступа должна иметь срок, владельца и проверяемое прекращение прав. Ранее раскрытый пароль может потребовать замены.
От классификации к конкретным настройкам. Для каждой группы риска составьте собственный минимальный набор контролей. Например, для обычного рабочего кабинета это владелец и назначенные пользователи. Для чувствительного общего аккаунта — подтверждённое основание выдачи, ограниченный круг получателей и план смены раскрытого секрета. Для инфраструктурного доступа — дополнительное согласование, проверка журналов, аварийный порядок и испытанная процедура восстановления.
У каждого контроля должно быть доказательство выполнения: результат теста, решение владельца или запись о проверке. Наличие функции в продукте этого не заменяет. Если в менеджере паролей есть ролевое разграничение, но весь отдел фактически входит в одну общую группу, риск широкого охвата остаётся. Если события сохраняются, но нужный журнал нельзя получить к моменту расследования, само наличие настройки не решает задачу контроля. Каждый контроль должен иметь исполнителя и проверяемый результат.
Как корректировать класс после улучшений. Допустим, компания перевела общий аккаунт на персональные учётные записи, ограничила право изменять данные и настроила понятный отзыв. Охват и сложность контроля изменились, поэтому оценку можно пересмотреть. Но не снижайте показатель последствий, если ошибка по-прежнему способна остановить критичную систему. Классификация нужна для объяснимого управления, а не для отчёта о непрерывном «снижении рисков» любой ценой.
Покажите в итоговой таблице состояние до изменений, действие, дату проверки, новый статус и оставшийся риск. Руководству будет видно, какие проблемы устранены, какие приняты временно и куда направить следующий ресурс.
Исключения: что делать, когда правила неприменимы
Реальные процессы редко идеально укладываются в классификацию. Например, устаревшая производственная система поддерживает только один общий аккаунт, а смена пароля требует остановки интеграции. Исключение может быть допустимо на ограниченный период, но его нельзя превращать в бессрочную норму.
Для каждого исключения запишите причину, бизнес-владельца, последствия, компенсирующие меры и дату повторного рассмотрения. Это не обязательно отдельный дорогой инструмент: достаточно контролируемой записи в системе заявок или реестре рисков.
Проверяйте не только сохранность описания, но и фактическое состояние доступа. Если подрядчику разрешали работу на две недели, а через месяц он всё ещё входит под общим аккаунтом, причина не в ошибке табличной формулы. Отсутствует механизм окончания прав.
Не снижайте класс риска из-за наличия исключения. Если критичная запись временно защищена менее строго, риск остаётся видимым для владельца процесса и ИБ до устранения первопричины.
Как принимать временный риск. Если изменить старый сервис сейчас невозможно, у исключения должны быть понятные границы: какие именно аккаунты затронуты, сколько человек ими пользуется, кто разрешил продолжать работу, какой контроль действует до исправления и когда решение пересматривается. В противном случае «техническое ограничение» превращается в бессрочное оправдание повышенного риска.
Полезно разделять неизменяемое ограничение внешнего продукта и внутреннее удобство команды. Отсутствие персональных ролей в старой программе может потребовать компенсирующих мер. Нежелание сотрудников переходить с общего пароля на персональные аккаунты — иная проблема, которую можно решать обучением и изменением процесса. В реестре эти причины должны быть видны раздельно.
После устранения исключения проверьте новые права, завершение старых сеансов и необходимость смены ранее известного секрета. Только затем закрывайте запись и фиксируйте остаточный риск.
Когда пересматривать риск и как показывать динамику
Повторная оценка нужна не только раз в год по календарю. Сильнее всего на класс записи влияют изменения полномочий, подключение нового филиала, передача процесса подрядчику, ротация критичных администраторов и появление новых интеграций. Эти события должны запускать внеплановую проверку.
Храните дату последней оценки, имя согласовавшего владельца, причину изменения класса и ссылку на доказательство. Если через полгода запись получила более широкий доступ, должен быть виден источник решения, а не просто новое число в таблице.
Для руководства полезнее показать долю критичных секретов с подтверждёнными владельцами, число необработанных исключений и скорость отзыва после завершения работ, чем отчёт из сотен непонятных баллов. Каждый показатель должен вести к действию: изменить роль, заменить общий аккаунт, проверить журнал или согласовать миграцию.
Первоначальную выборку можно взять из процедуры аудита корпоративных паролей. После классификации задача уже не в подсчёте записей, а в выборе приоритетных мер и повторной проверке.
Обсудить проверку прав
Подготовьте обезличенные примеры общих аккаунтов и требования к доступу. Обсудим сценарии пилота BearPass: кто может увидеть, изменить и передать запись, какие действия доступны для проверки в журнале.
Рекомендуем к прочтению
Частые вопросы
Это методика регулятора?
Нет. Это авторский шаблон внутренней приоритизации. Компания согласует определения, флаги и условия принятия риска; таблица не заменяет обязательную для конкретного проекта оценку.
Что означает сумма баллов?
Только порядок рассмотрения в выбранной модели. Она не измеряет вероятность инцидента и не делает аккаунт с девятью баллами втрое опаснее аккаунта с тремя. Критичные флаги рассматривают независимо от суммы.
Когда пересматривать оценку?
При изменении полномочий, круга получателей, владельца, интеграций и способа отзыва. Плановый период определяют отдельно; после улучшений сохраняют доказательства и оставшийся риск, а не только новый балл.