Все возможности системы
< Список статей

Аудит пользователей InPlan

Аудит пользователей проводится 1 раз в полгода. 

Последний аудит был в августе 2025 года, выложен в папку Аудит пользователей.

Цель аудита:

Убедиться, что:
  •  Аккаунты уволенных сотрудников Mars деактивированы в Inplan. Соответственно, на данном шаге выполняется проверка - проверяем активность аккаунта в MARS. 
  • Аккаунты действующих сотрудников, имеют необходимые списки рассылки и группа доступа в AD (группа безопасности Application-InPlan-Read) • Действующие сотрудники компании - могут отсутствовать в группе доступа и списках рассылки по разным причинам, например, не отработал TASK в Сore на добавление в группу доступа или списки рассылки. Поэтому, на данном шаге мы делаем запрос для таких сотрудников на добавление им в AD группы доступа и списков рассылки через форму Добавить Запрос- СORE
  • Сотрудники, которые не используют аккаунт Inplan, а так же и отсутствующие в группе доступа – деактивированы, если доступ не требуется. 
  • Неактивных пользователей, которые не планируют использовать учетную запись, необходимо удалить из системы InPlan и из группы доступа "Application-InPlan-Read" - Добавление и удаление пользователя из группы доступа InPlan - CORE
  • Проверить что роль пользователя в Inplan соответствует его должности в Mars (Cотрудник отдела Demand не может быть с роль Sales Head).
  • Поиск активных пользователей, не подключенных к общей рассылке group_inplan_ru@effem.com, либо удаление деактивированных пользователей из рассылки.
Важно: после деактивации аккаунта, необходимо создать реквест для вендора для удаления пользователя из цепочек согласования.

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

1. Запустить DBeaver CE
 
 

2. Запустить SQL script:
 
 

 
 

3. Скопировать и вставить селект для поиска деактивированных учетных записей: 

Условия скрипта: 

 ud.isactive is false - учетная запись неактивна
 ud.rowstatus = 1 не удалённые пользователи
 ud.rowstatus = 0  удаленные пользователи

SELECT
ud.email,
rd."name" AS Роль,
ud.id,
ud.firstname,
ud.lastname,
ud.isactive,
CONCAT(ud.lastname, ' ', ud.firstname, ' ', ud.middlename) AS ФИО,
STRING_AGG(sd."name", ', ') AS "Каправление канала продаж",
STRING_AGG(se."name", ', ') AS "Канал продаж",
STRING_AGG(cc."name", ', ') AS "Клиент",
STRING_AGG(cg."name", ', ') AS "Группа категорий",
STRING_AGG(sc."name", ', ') AS "Подразделение"
FROM
nrm_core.users_ds ud
LEFT JOIN
nrm_core.accessrules_ft af ON af.userid = ud.id
LEFT JOIN
nrm_core.role_ds rd ON rd.id = ud.roleid
LEFT JOIN
nrm_srv.t_accesstypes ta ON af.accesstypeid = ta.id
LEFT JOIN
nrm_core.saleschannel_et se ON af.referenceid = se.id AND af.accesstypeid = 1
LEFT JOIN
nrm_core.clientnrm_cds cc ON af.referenceid = cc.id AND af.accesstypeid = 2
LEFT JOIN
nrm_core.categorygroup_cds cg ON af.referenceid = cg.id AND af.accesstypeid = 4
LEFT JOIN
nrm_core.saleschanneldirection_et sd ON af.referenceid = sd.id AND af.accesstypeid = 6
LEFT JOIN
nrm_core.subdivision_cds sc ON af.referenceid = sc.id AND af.accesstypeid = 7
where ud.isactive is false and ud.issystemuser = false and ud.rowstatus = 1
GROUP BY
ud.email, rd."name", ud.id;



Результат скрипта: 3 неактивных пользователей в Inplan, но не удаленных в справочнике Пользователей

Пример: Баркова Анна, можно проверить что в Inplan запись неактивна.

 
 


 
 

Если поставить условие ud.rowstatus = 0, то результат список пользователей деактивированных и удаленных из cправочника пользователей:

 
 

Важно: деактивированных пользователей нельзя удалять из БД, должна остаться история.


5. Скопировать и вставить селект для поиска активных учетных записей:

 ud.isactive is true 
 ud.rowstatus = 1

SELECT
ud.email,
rd."name" AS Роль,
ud.id,
ud.firstname,
ud.lastname,
ud.isactive,
CONCAT(ud.lastname, ' ', ud.firstname, ' ', ud.middlename) AS ФИО,
STRING_AGG(sd."name", ', ') AS "Каправление канала продаж",
STRING_AGG(se."name", ', ') AS "Канал продаж",
STRING_AGG(cc."name", ', ') AS "Клиент",
STRING_AGG(cg."name", ', ') AS "Группа категорий",
STRING_AGG(sc."name", ', ') AS "Подразделение"
FROM
nrm_core.users_ds ud
LEFT JOIN
nrm_core.accessrules_ft af ON af.userid = ud.id
LEFT JOIN
nrm_core.role_ds rd ON rd.id = ud.roleid
LEFT JOIN
nrm_srv.t_accesstypes ta ON af.accesstypeid = ta.id
LEFT JOIN
nrm_core.saleschannel_et se ON af.referenceid = se.id AND af.accesstypeid = 1
LEFT JOIN
nrm_core.clientnrm_cds cc ON af.referenceid = cc.id AND af.accesstypeid = 2
LEFT JOIN
nrm_core.categorygroup_cds cg ON af.referenceid = cg.id AND af.accesstypeid = 4
LEFT JOIN
nrm_core.saleschanneldirection_et sd ON af.referenceid = sd.id AND af.accesstypeid = 6
LEFT JOIN
nrm_core.subdivision_cds sc ON af.referenceid = sc.id AND af.accesstypeid = 7
where ud.isactive is true and ud.issystemuser = false and ud.rowstatus = 1
GROUP BY
ud.email, rd."name", ud.id;

Результаты скрипта:

 
 

Количество пользователей можно сверить со справочником пользователей: 
 
 

273 пользователя, из них 3 неактивных. Количество совпадает.

6. Сделать выгрузку полученных данных:
 
 

 
 

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

 
 

Важно: в данном справочнике можно установить кто Линейный менеджер сотрудника, должность, активность (вот например пользователи, у которым ЛМ - Игорь Бугаков (фильтр на id LM-а установлен)

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


8. К списку также подтянуть атрибут IsActive - признак неактивных пользователей: 



Уволенные сотрудники - после увольнения, у сотрудника автоматически удаляются группа доступа и списки рассылки Inplan в AD , но в Inplan не происходит автоматическая деактивация аккаунта. Соответственно, на данном шаге мы деактивируем уволенных сотрудников и удаляем их роли и аккаунт роли в Inplan.
Дополнительно сделать реквесты для вендора для удаления из цепочек согласования), создать заявку в Intradesk ( Пример заявки Деактивация пользователя_Rudkovskaya Alina)

Пример реквеста для вендора RTASK0035886:

 
 


 
9. Делаем автоматическую рассылку линейным менеджерам (Массовая рассылка писем пользователям), у которых есть сотрудники с должностью Intern: 
Intern с ролью View - по таким пользователям ЛМ рассылка не нужна.

 
 
Важно: сотрудники с должностью Intern (стажер) не могут быть с ролью Sales Head. 


10. Делаем автоматическую рассылку линейным менеджерам, у которых есть сотрудники с доступ в Inplan. (будет автоматизировано).

 Рассылку сотрудникам о проверке своих ролей, клиентов, т.д необходимо сделать за 2-3 недели до начала аудита. 

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

Пример рассылки: Аудит пользователей системы InPlan.msg (предварительно выложив файл на общий ресурс, пример файла Аудит пользователей Inplan.xlsx)
 
 
11. Обратную связь после рассылок ЛМ фиксируем в файле, пример Выгрузка пользователей с ЛМ (13.08) с ОС.xlsx . Все отправленные и полученные письма сохраняем в папку с данными аудита.

Дополнения от 02.10 от аудитора InPlan_ User Access Review recommendation.msg

1. Сопровождать выгрузку скриншотами из системы, которые демонстрируют логику формирования отчета:
  •  Система источник (проверяющий убеждается, что выгрузка формируется из продуктивной среды InPlan)
  • Используемые фильтры (проверяющий убеждается, что при выгрузке не были использованы фильтры, которые могли бы повлиять на заключение при проверке)
  • А также, указывать в изначальном письме на проверку, что проверяющий может обратиться к данному скриншоту, чтобы получить понимание о том, какой список он проверяет.

2. В изначальном письме на проверку указывать атрибуты, которые должны быть проверены:
  • Актуальность доступа (Сотрудник не переведен и не уволен, доступ в InPlan все еще необходим)
  • Корректность назначенных ролей (Роли соответствуют должностным обязанностям)
  • Корректность информации о пользователе: Канал продаж, Клиент, Группа категорий.
Это необходимо для того, чтобы каждый проверяющий анализировал один и тот же набор атрибутов, а не проверял, например, только наличие доступа или только роль.

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

Комментарий аудитора: Так как система финансово-значимая, то нужно будет проходить аудит, где предстоит показывать, что для каждого пользователя, для которого выполнялась проверка, получен явный прозрачный ответ от руководителя. Если у нас не будет этих ответов, то как бы качественно мы сами не проверяли, то в этом контроле всегда будет недостаток из-за отсутствия audit evidence.

Необходимо добавить в письмо:  если не предоставлен ответ от ЛМ в течение 3 недель, то доступ его сотруднику будет заблокирован. RE_ InPlan_ User Access Review recommendation.msg
За 1 день до блокировки учетных записей пользователей, по которым не поступил ответ от их ЛМ, необходимо сделать рассылку с текстом:
Прошу обратить внимание, что в рамках аудита пользователей Inplan от вашего линейного менеджера не поступило подтверждение об актуальности вашей учетной записи в Inplan. Завтра ваш аккаунт будет деактивирован. Если вам необходим доступ в Inplan - просим вашего линейного менеджера вернутся с обратной связью.


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



Файлы:

Инструкция