Аудитория: ИТ-администратор, кадровая служба, ИБ, технический заказчик. Закрывает вопрос: «как доступ к ПО связан с приёмом/переводом/увольнением и как подключить действующих сотрудников?». Сценарии: найм нового, перевод действующего, увольнение, разовое подключение всего штата.
Это объяснение что произойдёт и за какое время. Часть потока (Grace и отзыв при увольнении) уже работает; часть — в текущем спринте. Где граница — честно отмечено ниже.
Доступ к ПО привязывается к трём кадровым событиям (модель JML — Joiner / Mover / Leaver), которые приходят из 1С:ЗУП:
- Найм (Joiner): вышел сотрудник → автоматически получает базовый набор ПО по должности,
без ручных заявок.
- Перевод (Mover): сменил отдел/должность → доступ пересобирается: добавить недостающее,
отозвать лишнее.
- Увольнение (Leaver): уволен → Grace-период (по умолчанию 48 ч) → **отзыв всех лицензий
и учёток**, возврат лицензий в общий пул.
Действующие сотрудники подключаются разовой сверкой: текущий штат сопоставляется с профилями должностей, и система показывает, у кого чего не хватает, а где — лишнее/теневое.
1. Кадры оформляют приём в 1С:ЗУП (должность, отдел, дата выхода).
2. Портал получает событие joiner (обезличенный id, отдел, должность).
3. По ПРОФИЛЮ должности определяется базовый набор ПО (напр.: ОС, антивирус,
офис, почта, СЭД, для бухгалтера — 1С:БГУ и КонсультантПлюс).
4. На каждый пункт набора создаётся заявка → проходит статусную машину
(approved → provisioning) → исполнитель устанавливает/выдаёт доступ.
5. Сотрудник к первому дню уже с рабочим набором ПО.Что админ настраивает один раз: профили «должность/отдел → набор ПО». Что происходит дальше: автоматически, на каждого нового человека.
Перевод: сотрудник переходит из отдела A в отдел B.
событие mover (из отдела A → в отдел B)
→ diff профилей: что в наборе B, но нет у человека → доставить
что было только для A и больше не нужно → отозвать (мягкий Grace)Действующие сотрудники (разовое подключение — «initial load»): при внедрении портал не знает историю — он делает разовую сверку:
1. Импорт текущего штата из 1С:ЗУП (снимок: кто, где, какая должность).
2. Сопоставление каждого с профилем его должности.
3. Сверка с фактом (из телеметрии/инвентаря KSC — что реально стоит и используется):
• положено, но нет / не используется → кандидат на выдачу или обучение;
• стоит, но не положено / теневое → кандидат на ревизию (см. статью 09).
4. Экран показывает ход подключения по подразделениям.После initial load дальше всё идёт инкрементально через события joiner/mover/leaver.
1. Кадры оформляют увольнение в 1С:ЗУП.
2. Портал регистрирует событие leaver → статус 'grace', дедлайн = now + 48 ч.
3. В течение Grace доступ ещё жив (на случай отмены/доработки/передачи дел).
4. По истечении Grace — grace-sweep: лицензии отзываются (remove-job),
учётки блокируются, лицензии возвращаются в пул.
5. Повторный прогон ничего не задваивает (идемпотентно).Реализовано полностью (J4): process_leaver помечает весь активный доступ к отзыву → по истечении Grace grace_sweep отзывает (remove-job), блокирует учётку (disable_sso, боевая сигнатура), возвращает места в пул (/license-pool) и пишет акт отзыва REVOKE_ACT в аудит ФЗ-152. Найм (J1+J2) и перевод (J3) тоже реализованы — см. таблицу статуса ниже.
| Возможность | Статус |
|---|---|
Экран ЖЦ /lifecycle, список событий | 🟢 готово |
| Увольнение: Grace 48 ч + отзыв + возврат лицензий в пул + акт | 🟢 готово (J4) |
| Найм: автонабор ПО по профилю должности | 🟢 готово (J1+J2) |
| Перевод: пересбор доступа (diff, мягкий Grace) | 🟢 готово (J3) |
| Профили «должность → набор ПО» | 🟢 готово (J2) |
HR-фид из 1С:ЗУП — приём POST /ingest/hr-events (PUSH) | 🟢 готово (J1, боевая сигнатура) |
Разовое подключение штата (initial load), экран /jml-initial-load | 🟢 готово (J6) |
| Реальная установка на АРМ (не симулятор) | 🟡 боевая сигнатура (J5): дефолт simulated, боевой WinRM/SSH/Ansible — по env-opt-in, заведение узлов на стороне заказчика |
Как и с телеметрией (статья 13), мы не следим за людьми: событие приносит обезличенный id, ФИО хранится только в Vault и раскрывается по основанию (статья 02). HR-событие = «принят/переведён/уволен», а не досье.
«Развернуть» — это не «написать код», а подключить к боевой 1С:ЗУП, завести профили и исполнитель на АРМ. Реалистичные сроки:
| Что разворачиваем | Срок | Узкое место |
|---|---|---|
| Демо-витрина ЖЦ (на фикстуре) | 1 день | docker compose up |
| Портал + телеметрия KSC | 1–5 дней | доступ к KSC, сеть |
| HR-фид 1С:ЗУП (события) | 1–3 недели | готовность выгрузки/OData 1С:ЗУП, маппинг отделов/должностей |
| Профили ПО по должностям | 1–2 недели | согласование «что кому положено» с заказчиком |
| Боевая установка на АРМ (J5) | 1–3 недели | парк АРМ, домен, агент/WinRM/SSH |
| Пилот на 1 отделе → весь штат | 2–4 недели | размер организации |
Итого:
- Показать, как это работает, — в тот же день (на демо-данных).
- Боевой найм/увольнение с реальной установкой — 4–6 недель календарно. Главные задержки —
на стороне заказчика (готовность 1С:ЗУП и парка АРМ), а не в нашем коде: разработка ядра (16–20 инж-дней) идёт параллельно интеграции.
- Выгрузку/доступ 1С:ЗУП на события приём/перевод/увольнение (или OData).
- Справочник должностей и отделов + решение «что кому положено» (профили ПО).
- Парк АРМ: как ставится ПО (агент/WinRM/SSH, домен) — для боевого исполнителя.
- Регламент Grace: сколько часов держать доступ после увольнения (по умолчанию 48 ч).
- Все три сценария рабочие (joiner/mover/leaver). На стенде профили и события —
демонстрационные; боевые — после подключения 1С:ЗУП и согласования профилей у заказчика.
- Профили — это решение бизнеса, не код. Стендовые профили (бухгалтер/кадры/ИТ/медиа) —
пример; боевой набор «что кому положено» согласуется с заказчиком — это главный оргшаг.
- Реальная установка зависит от парка. Срок J5 не в нашей власти целиком — это интеграция на
стороне инфраструктуры заказчика.
Связанные статьи: 02 — ПДн и Vault · 09 — Shadow IT · 15 — Клиентский слой.