Централизованное управление учетными записями: что это значит на практике и как можно реализовать

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

В логике приказа № 66 эта тема вообще не существует отдельно от остальной модели управления доступом. В приложении 3 рядом стоят сразу несколько связанных требований: полномочное управление учетными записями, контроль правил генерации и смены паролей и централизованное управление учетными записями пользователей ИС. Это важная связка. Она сразу показывает, что речь не про “один удобный сервис”, а про целый слой управления: кто создаёт учетные записи, как они активируются, кто и когда их блокирует, как меняются права, где контролируются пароли и в какой точке это всё вообще удерживается в одних руках.

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

Что здесь на самом деле считается централизованным управлением

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

Именно здесь многие и ошибаются. Им кажется, что централизованное управление — это обязательно Active Directory, LDAP или IAM-платформа. На самом деле такие инструменты часто являются лучшим техническим способом реализации, но не исчерпывают саму задачу. Если внутри организации нет ясного порядка создания, изменения, пересмотра и уничтожения учетных записей, никакой каталог сам по себе проблему не решит. Он только ускорит хаос.

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

Где эта тема чаще всего ломается

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

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

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

Как это выглядит на практике

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

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

Уже после этого становится понятно, какая техническая реализация подходит: достаточно ли доменной модели и групп, нужен ли отдельный каталог, необходим ли IAM или PAM, или же для текущего масштаба системы пока достаточно более простой, но жёстко регламентированной схемы.

Какой минимум должен быть у владельца ИС

Приказ № 66 оставляет собственнику или владельцу ИС пространство для выбора конкретных мер, но сам порядок применения СЗИ должен быть определён локальными актами и организационно-распорядительными документами, которые владелец обязан утвердить и поддерживать в актуальном состоянии. Это означает, что без организационной опоры тема учётных записей вообще не удерживается. Нельзя считать вопрос решённым только потому, что в системе есть каталог пользователей.

Практический минимум обычно выглядит так:

• разделены обычные, административные и сервисные учетные записи;
• понятно, где и кем создаются, изменяются, блокируются и уничтожаются учетные записи;
• определён единый порядок назначения и пересмотра прав;
• локальные исключения либо исключены, либо строго учтены и обоснованы;
• правила паролей и привилегий контролируются из одной управляемой модели, а не вручную по каждому узлу;
• внутренние документы по применению СЗИ реально отражают этот порядок, а не просто декларируют его.

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

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

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