Как вы относитесь к процессу увольнения, когда увольняется / увольняется привилегированный или технический персонал? Есть ли у вас контрольный список того, что нужно сделать, чтобы обеспечить непрерывную работу / безопасность инфраструктуры компании?
Я пытаюсь составить хороший канонический список вещей, которые мои коллеги должны сделать, когда я уйду (я уволился неделю назад, так что у меня есть месяц, чтобы привести в порядок и GTFO).
Пока у меня есть:
Сопровождайте их из помещения
Удалить их почтовый ящик (настроить пересылку всей почты для приема всей почты)
Удалить их ключи SSH на сервере (ах)
Удалите их учетные записи пользователей mysql
...
Ну и что дальше. Что я забыл упомянуть или что может быть полезно?
(примечание: почему это не по теме? Я системный администратор, и это касается постоянной безопасности бизнеса, это определенно по теме.)
Я бы предложил создать контрольный список того, что вы делаете, когда новый системный администратор присоединяется к компании (системы, в которые вы должны их добавить, группы, в которые должна входить их учетная запись и т. Д.), И включать как технические, так и физические вещи - например, физические ключи и коды сигналов тревоги не менее важны, чем ключи и пароли SSH.
Обязательно обновляйте этот список - я знаю, легче сказать, чем сделать. Но это упрощает процесс ввода новых членов команды в компанию и их повторную обработку. Вы все еще можете сделать это сейчас и получить хоть какую-то пользу от его использования, чтобы помочь с уходящим человеком. Причина, по которой я упоминаю контрольный список, заключается в том, что мы все склонны мыслить в своих сферах комфорта, и в противном случае можно упустить разные вещи, в зависимости от того, кто обрабатывает уход. Например: «менеджер по безопасности здания» или «офис-менеджер» будет больше думать о дверных ключах, чем о ключах SSH, а ИТ-специалист будет полной противоположностью и в конечном итоге откажется от доступа к системе, оставив при этом возможность войти в здание ночью.
Затем просто просмотрите их контрольный список, когда они уйдут, используйте его как контрольный список того, что нужно отменить / вернуть. Вся ваша ИТ-команда должна с энтузиазмом относиться к этому, если они профессиональны, поскольку согласованный процесс, подобный этому, защищает их от необоснованной вины со стороны бывшего работодателя так же, как он защищает от них работодателя.
Не забывайте о таких вещах, как доступ к удаленным центрам обработки данных или физический доступ к стороннему хранилищу данных резервного копирования.
Я удивлен, что никто не упомянул об этом раньше, но ...
Если ваша сеть WiFi использует WPA или (я надеюсь, что нет) WEP, а не подключение к серверу Radius, вы можете подумать об изменении этого ключа.
Это огромная дверь, оставленная открытой, если вы администратор сети, есть большая вероятность, что вы знаете этот ключ наизусть ... представьте, как легко было бы вернуться в сеть с парковки или чего-то в этом роде .
Другие вещи, которые приходят на ум:
Если из компании уходит какой-то сисадмин, мы меняем все пароли для пользователей (вместо ежемесячной смены пароля). У нас есть ldap и radius, так что это не очень сложно. Затем мы смотрим на системы, над которыми он работал, а также на файлы, которые были созданы / изменены им. Если на его рабочем месте есть важные данные, мы их очищаем или архивируем.
У нас есть аудит доступа ко всем сервисам, у которых есть пользователи. Если сервисом пользуется какой-то неизвестный пользователь, мы его блокируем, по крайней мере, до прохождения идентификации.
Остальные системы почистят через неделю; большинство из них предназначены для разработки и не содержат ценной информации, и они регулярно очищаются путем переустановки.
В этой теме много хороших идей ... Еще несколько вещей, которые следует учитывать:
Я согласен на изменение паролей или отключение учетных записей пользователей с ограниченным сроком действия вместо их удаления (по крайней мере, на начальном этапе), однако, возможно, будет хорошей идеей проверить и посмотреть, используется ли учетная запись пользователя для запуска служб / запланированных задач, прежде чем принимать меры. Это, вероятно, более важно в среде Windows / AD, чем в U
Некоторые из следующих пунктов могут быть трудными для выполнения, если сотрудник увольняется быстро или при менее чем идеальных обстоятельствах; но это может быть важно (особенно в те моменты, когда только что произошло 2 часа ночи)
Передача знаний - хотя мы все поддерживаем всю нашу документацию в актуальном состоянии (кхм, перетасовка ног), может быть полезно запланировать время с помощью таймера и сделать некоторые вопросы и ответы или пошаговые инструкции с другим администратором. Если у вас много настраиваемого ПО или сложная среда, может быть действительно полезно задать вопросы и пообщаться один на один.
Наряду с этим идет пароли. Надеюсь, все используют какой-либо тип зашифрованного хранилища учетных записей / паролей (KeePass / PassSafe и т. Д.). Если это так, это должно быть довольно просто - получите копию их файла и ключ к нему. Если нет, то пришло время выбросить мозги.
Начните с изменения всех паролей «периметра» вашей сети. Любые учетные записи, которые он может использовать для входа в вашу сеть из дома (или с парковки с WiFi), должны быть немедленно изменены.
Как только они будут покрыты, продвигайтесь внутрь.
Другие вещи, которые нужно проверить, чтобы навести порядок:
Постарайтесь, чтобы все изменения паролей происходили между «выходящим из сети» (возможно, выходным собеседованием в конференц-зале, после того, как рабочий ноутбук был возвращен) и «выходящим остается наедине с устройствами». Это резко снижает вероятность того, что выпавший будет отслеживать новые учетные данные (но со смартфонами и тому подобным он все еще не равен нулю).
Все приведенные выше ответы очень хороши. Как практикующему специалисту в области информационной безопасности (ИТ-аудитор), вам следует рассмотреть еще несколько моментов:
Удалите привилегированные административные права, такие как администратор домена, если вы используете Active Directory.
Удалите привилегированные роли базы данных, которые у них могли быть (например, db_owner)
Сообщите внешним клиентам, что завершенный пользователь мог иметь доступ, чтобы права доступа можно было отозвать.
Удалите учетные записи локальных компьютеров, если они были в дополнение к доступу к домену