Закрытие доступа уволенного администратора и аудит сервера ops-03

1. Ситуация

«Пятый склад» хранит товары интернет-магазинов и доставляет их покупателям: 14 складов в Северогорске и области, 600 курьеров, около 9 000 отправлений в день. Клиенты оформляют доставку на сайте и в приложении, оплату принимает собственный сервис billing, обращения клиентов разбирает отдел поддержки в сервисе helpdesk.

23 человека: разработка, группа эксплуатации (5 инженеров) и служба информационной безопасности. Внутренние сервисы работают на серверах Ubuntu 24.04 в собственной серверной. Группа эксплуатации устанавливает сервисы по стандарту, следит за их работой и закрывает доступ уволенным сотрудникам. С октября 2026 года в группе эксплуатации проходят производственную практику практиканты колледжа. Они работают парами, получают заявки из очереди группы и сдают работу наставнику. Изменения на рабочих серверах вносит дежурный инженер по отчёту и журналу работ пары.

Группа эксплуатации обслуживает три сервера: helpdesk-01 — сервис заявок отдела поддержки; billing-02 — приём платежей и ночная сверка с банком; ops-03 — сервер группы эксплуатации: скрипты выкладки магазина, общие папки, документы бухгалтерии. Это задание относится к серверу ops-03. Работа ведётся по регламентам компании РД-05 «Регламент прекращения доступа», ПД-02 «Политика доступа», ПР-06 «Порядок работы группы эксплуатации»; выдержки из них — в Приложении Б.

1.1. Заявка

Работа начинается с заявки в очереди группы эксплуатации. Её текст приводится полностью.

1.2. Хронология и участники

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

1.3. Что есть на сервере

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

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

2. Задача

Результат работы описывается пятью целями:

1. Закрыть вход учётной записи kozlov всеми способами и убрать её права, сохранив саму учётную запись и домашний каталог.
2. Завершить процессы уволенного сотрудника, предварительно записав, что они делали.
3. Передать каталог выкладки новому ответственному так, чтобы работа выкладки и бухгалтерии не прервалась.
4. Найти всё, что сотрудник оставил на сервере, и по каждой находке принять решение: передать, сохранить в копию или удалить.
5. Получить скрипт аудита учётной записи audit-user.sh и акт аудита для службы информационной безопасности.

Схема показывает части работы и порядок, в котором они связаны. Номер в блоке — раздел задания, где эта часть описана.

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

2.1. Учётная запись

1. 2.1.1
   Вход запрещён: пароль заблокирован, срок действия учётной записи истёк, оболочка — nologin. Учётная запись и домашний каталог остаются.
2. 2.1.2
   kozlov исключён из всех дополнительных групп. Личных правил sudo не осталось ни в одном файле.
3. 2.1.3
   Все процессы kozlov завершены. Перед завершением записано, что это за процессы: командная строка, родитель, текущий каталог, с какого времени работают.

2.2. Передача дел

1. 2.2.1
   Каталог /srv/devops со всем содержимым принадлежит orlova, группа — devops; права не ослаблены; ключ выкладки доступен только владельцу.
2. 2.2.2
   orlova запускает deploy.sh и читает ключ выкладки. lebedeva по-прежнему работает в /srv/finance.

2.3. Аудит файлов

1. 2.3.1
   Найдены все файлы kozlov вне его домашнего каталога, по каждому принято решение: передать, перенести в копию или удалить.
2. 2.3.2
   Дамп базы с персональными данными клиентов убран из общей папки в копию.
3. 2.3.3
   Из домашнего каталога в копию перенесены notes.txt и .ssh.
4. 2.3.4
   Найдены программы с битом setuid, которые не принадлежат пакетам системы. Посторонние удалены.

2.4. Акт аудита

1. 2.4.1
   Каждая находка: что найдено, чем опасно, что сделано. Отдельный раздел — что нужно сделать вне сервера: какие пароли, токены и ключи kozlov знал и кому их сменить.

2.5. Задачи по выбору

Эти задачи выполняются после основных требований и дают дополнительные баллы. Файлы кладутся в папку optional/; при приёмке пара запускает скрипт на стенде или показывает документ.

Требования выполняются на копии сервера, вдвоём, в течение 14 дней. Как устроены стенд, работа в паре и этапы, описано в части 3.

3. Порядок работы

3.1. Копия сервера

Изменения на рабочем сервере ops-03 вносит дежурный инженер по отчёту пары. Пара работает на копии сервера: её разворачивает скрипт стенда в виртуальной машине с Ubuntu 24.04 из занятия 1. У каждого практиканта своя машина и свой стенд; нужно не меньше 2 ГБ свободного места и 2 ГБ памяти.

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

cd ~/Downloads
wget https://algorthimization-course-vvodnoe.vercel.app/op05-operacionnye-sistemy-i-sredy/proekty/ekspluataciya-servera/materials/offboarding-stand.sh
wget https://algorthimization-course-vvodnoe.vercel.app/op05-operacionnye-sistemy-i-sredy/proekty/ekspluataciya-servera/materials/offboarding-acceptance.sh
sudo bash offboarding-stand.sh

Стенд создаёт учётные записи kozlov, orlova и lebedeva, каталоги команды и запускает процессы kozlov. Перед изменениями стенд записывает список программ с setuid, чтобы приёмка увидела новые.

Скрипт приёмки ничего не изменяет: он проверяет копию сервера и печатает OK или FAIL по каждому из 17 пунктов. Пункт FAIL показывает, какое требование не выполнено; перевод пунктов — в Приложении А. Подгонять сервер под скрипт в обход требований запрещено.

sudo bash ~/Downloads/offboarding-acceptance.sh | tee acceptance.txt

3.2. Работа в паре

Работа делится на две части, общую часть пара выполняет вместе. Кто из пары практикант 1 и кто практикант 2, записывается в README.md. При приёмке каждый отвечает и за свою часть, и за часть напарника.

У пары один репозиторий — tz-03-offboarding: его создаёт практикант 1 и добавляет напарника в Settings → Collaborators. Каждый работает в своей ветке (part-1, part-2) и открывает Pull Request в main. Напарник повторяет команды на своём стенде, оставляет замечания и одобряет слияние. Журнал работ runbook.md общий: время, кто из пары, команда, результат, номер требования; ошибки и откаты тоже записываются.

3.3. Этапы

День 0 — дата выдачи задания. К концу каждого этапа результат загружен в репозиторий, наставник может проверить его без предупреждения.

3.4. Материалы

В работе используются методичка (порядок работы, частые сообщения об ошибках, Git в паре), справочник команд, шаблоны документов и каркасы скриптов и лекции занятий 3–8. Что изучить по каждой задаче, сказано в разделе «Куда смотреть» в конце страницы. PDF этого ТЗ содержит лист согласования и акт сдачи-приёмки.

Работа заканчивается сдачей репозитория и проверкой в присутствии пары. Что сдаётся и как выставляются баллы, описано в части 4.

4. Сдача и проверка

4.1. Что сдаётся

Работа сдаётся одной ссылкой на репозиторий GitHub. README.md начинается с таблицы: практикант 1 и практикант 2, за что отвечает каждый, итог приёмки «N из 17»; ниже — команды стенда, решения и приёмки по порядку. В конце две строки: «Не получилось: ___» и «Нейросеть использовалась для: ___».

tz-03-offboarding/
├── README.md            состав пары, кто за что отвечает, итог приёмки
├── server-passport.md   паспорт сервера до изменений
├── runbook.md           журнал работ
├── audit.md             акт аудита
├── audit-user.sh        скрипт повторяемости
├── acceptance.txt       вывод приёмки после финального прогона
├── optional/            задачи по выбору
└── screenshots/         снимки из таблицы ниже

Шаблоны README.md, журнала работ, паспорта сервера и документа «акт аудита», а также каркас скрипта audit-user.sh — в архиве шаблонов. Команды и их вывод в документах — только с вашей виртуальной машины.

4.2. Проверка

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

4.3. Оценка

Работа оценивается в 30 баллов. Оценку получает пара, вклад каждого виден по коммитам, Pull Request и журналу работ.

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

Куда смотреть

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

Приложение А. Пункты скрипта приёмки

Скрипт offboarding-acceptance.sh печатает пункты на английском языке, сгруппированные по частям. В таблице — что означает каждый пункт и какое требование части 2 он проверяет. Требования, которые скрипт проверить не может, проверяются по документам и на испытаниях части 4.

Приложение Б. Выдержки из регламентов

Регламенты ИТ-отдела ООО «Пятый склад», которые относятся к этому заданию. Полные тексты хранятся во внутренней базе знаний группы эксплуатации.