Требуются ли CI/CD пайплайны в Azure DevOps выделенный пользователь без MFA?

Во время аудитов безопасности я несколько раз видел, что DevOps создал «особый» пользовательский аккаунт для CI/CD пайплайнов, особенно при использовании Azure DevOps. Часто этот пользователь — единственный, у кого отключена многофакторная аутентификация (MFA), что, на мой взгляд, нежелательно. Я понимаю, что MFA не может использоваться обычным образом при использовании машинной связи, но это действительно предполагалось как способ работы?

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

Либо, если этот «особый» пользователь используется для другой цели, например, для подключения сетевого хранилища, я считаю, что используемый механизм сам по себе должен быть полностью пересмотрен для этой цели? Поскольку это создает потенциальную уязвимость, имея активную учетную запись пользователя без MFA.

MFA в основном используется потому, что для людей пароль считается чем-то, что можно «легко» восстановить (если он не был случайно выбран, если жертва подверглась фишинговой атаке, если пароль был повторно использован…). В этой ситуации наличие нескольких уровней аутентификации полезно, поскольку пароль недостаточно надежен.

Но для машин «что-то, что вы знаете», «что-то, что у вас есть» или «что-то, чем вы являетесь» в основном одно и то же. Как только у вас есть доступ к машине, у вас есть доступ ко всей этой информации (что очень хорошо объясняется в другом ответе). Поэтому не имеет смысла иметь многофакторную аутентификацию, поскольку она не обеспечивает дополнительной защиты от компрометации машины.

Кроме того, машины не будут «повторно использовать» свои пароли (каждая машина должна иметь разные учетные данные именно для предотвращения этого), и они не будут обманываться фишинговыми атаками. Это означает, что учетные данные машины подвержены совершенно другим угрозам, чем учетные данные пользователя (угрозам, которые не решает MFA).

То, что вы называете «специальным токеном развертывания», это то же самое, что и пароль; секрет, который используется для аутентификации. Называется ли это «токеном», «паролем» или «супер-защищенной штукой» — это не имеет значения. (Но, чтобы быть справедливым, это в основном называется «токен», когда речь идет о паролях машин.)

Имейте в виду, что вы все равно должны убедиться, что доступ к этому секрету правильно реализован на самой машине (правильный контроль доступа, управление правами…).

Еще одно преимущество наличия специальной учетной записи машины (вместо использования токена, привязанного к пользователю, как вы предложили) заключается в том, что вы можете обеспечить более строгую авторизацию для этой учетной записи (то есть пайплайн CI/CD может иметь меньше/другие привилегии, чем разработчик). Кроме того, вы можете создать несколько учетных записей для машин для конкретных действий, если хотите (подключение сетевого хранилища может быть еще одним сценарием, который использует другую учетную запись). Хотя это связано с дополнительной нагрузкой по управлению всем этим (т.е. если существует только один скрипт, который выполняет все действия на одной и той же машине, то создание 100 учетных записей для каждого действия может быть не самым правильным решением…).

Таким образом, чтобы ответить на ваш вопрос, нет, это не плохая практика иметь «особые» учетные записи, используемые машинами без MFA, потому что угрозы, которые решает (или пытается решить) MFA для учетных данных пользователей, не те же, что влияют на учетные данные машин.