Чтобы запустить экземпляр EC2, вам понадобится пара ключей. Как вы справляетесь с ситуацией, когда инженер, имеющий доступ к закрытому ключу для этой пары ключей, покидает компанию? Будет ли работать добавление индивидуального доступа по ssh и деавторизация исходной пары ключей сразу после запуска экземпляра?
Когда сотрудник или подрядчик покидает компанию, вам необходимо отключить любой привилегированный доступ, который он имел к ресурсам компании. Это включает (но не ограничивается) ваши ключевые проблемы ssh:
Удалите открытый ключ ssh из всех файлов authorized_keys во всех запущенных экземплярах. Замените их вновь сгенерированным открытым ключом ssh, который известен только тем людям, у которых должен быть доступ.
Удалите все записи пар ключей в EC2, которые были известны ушедшим, чтобы новые экземпляры не могли быть запущены с этими парами ключей. Замените их новыми записями пары ключей, возможно, с теми же именами, если ваш
Альтернативный метод, который вы предлагаете, также хорош, и я использую его: отключите начальный ключ ssh и добавьте индивидуальные открытые ключи ssh для каждого разработчика, чтобы они могли войти в систему со своим обычным закрытым ключом ssh. Это может быть сделано для входа в общую учетную запись или для того, чтобы каждый разработчик получил свою индивидуальную учетную запись пользователя (я предпочитаю).
После увольнения сотрудника вам нужно будет очистить не только работающие серверы, но и процесс добавления ключей ssh на новые серверы. И когда сотрудник присоединится, вам нужно будет сделать обратное: добавить ключи ssh к работающим серверам и обновить новый серверный процесс.
Может потребоваться немного больше усилий для поддержки большого количества ключей ssh на множестве серверов, но здесь на помощь приходит автоматизация.
Никогда не давайте этот закрытый ключ конечным пользователям. Конечным пользователям должны быть предоставлены собственные средства входа в систему, такие как аутентификация с открытым ключом (с использованием их СОБСТВЕННОГО закрытого ключа, защищенного паролем), с последующей авторизацией LDAP.
Распространение секретного ключа, предоставленного вам ec2, делает невозможным деинициализацию пользователей. Именно поэтому использование общих учетных данных полностью запрещено всеми правилами безопасности и соответствия.
Когда вы разрешаете использование общих учетных данных:
См. Документацию Amazon по доступ к ротации учетных данных.
Используйте что-нибудь вроде кукольный или твердый сценарий ssh для бега и замены всех экземпляров старого ключа, если вы не хотите все перезапускать ... или просто перезапускать все заново.