Вопрос или проблема
Я недавно начал работу с Google Cloud Platform (GCP), и, разрабатывая стратегию аутентификации для своей компании, я неоднократно сталкивался с рекомендацией использовать служебные аккаунты для аутентификации. Это имеет смысл во многих ситуациях. Приложение или сервис не должны иметь пользовательской учетной записи. В той ссылке Google фактически излагает первоначальную цель служебных аккаунтов:
Служебный аккаунт — это особый тип аккаунта Google, который принадлежит вашему приложению или виртуальной машине (VM), а не отдельному конечному пользователю.
Но схема служебных аккаунтов доминирует во всех инструментах вокруг GCP.
В отличие от файла ~/.aws/credentials, нет хорошего способа использовать учетные данные пользователя из CLI без того, чтобы ваша пользовательская учетная запись выглядела как служебный аккаунт с запутанными рабочими процессами, такими как gcloud auth application-default login, поэтому рекомендации часто выходят за рамки использования приложениями и сервисами до сценариев, где за рулем будет человек.
Такие инструменты, как Ansible и Terraform, являются примерами сторонних инструментов, которые делают эти рекомендации. Я понимаю, что часто вы будете запускать эти инструменты в автоматизированном конвейере, но, безусловно, есть случаи, когда их будут запускать отдельные люди. Устойчивое рекомендуемое использование служебных аккаунтов для всего привело к паттерну, где разработчик Джим локально создает учетные данные для ServiceAccountA, а затем использует их!
Вот моя проблема с этим: вы теряете аудит! Непостановка — это основная часть информационной безопасности, верно? Почему основным методом аутентификации в GCP является использование служебных аккаунтов, когда все журналы аудита теряют ценность непостановки? Чтобы выяснить, что плохое дело сделал разработчик Джим, а не разработчик Салли, вам нужно, чтобы журнал аудита в StackDriver выглядел так:
authenticationInfo: {
principalEmail: "[email protected]"
}
Но поскольку разработчик Джим всегда следует лучшим практикам (или на самом деле единственному паттерну, поддерживаемому многими инструментами), он использует служебный аккаунт для развертывания изменений, и журнал аудита выглядит так:
authenticationInfo: {
principalEmail: "[email protected]"
}
С этой записью как можно сказать, кто что сделал?
Я неправильно интерпретирую рекомендуемую практику или эта практика действительно устраняет непостановку?
В Google Cloud есть два основных метода аутентификации: учетные данные пользователя и учетные данные служебного аккаунта. Я игнорирую API-ключи и т. д.
Причина, по которой Google рекомендует использовать служебные аккаунты (где это возможно), вместо учетных записей пользователей, заключается в том, что обработка учетных записей пользователей для Google гораздо более интенсивна. Процесс занимает больше времени, требуется больше проверок безопасности и т. д. Существует предел API на количество аутентификаций с учетными данными пользователя в определенный период времени. Точные цифры не опубликованы.
Служебные аккаунты содержат все компоненты, необходимые для аутентификации с Google Cloud, и требуют меньше взаимодействий для генерации OAuth-токенов.
JSON-файлы ключей служебного аккаунта предполагается запускать в безопасной среде. Учетные данные пользователя предполагается запускать в небезопасной среде.
Учетные данные служебного аккаунта обычно используются для аутентификации/авторизации сервисов, установленного программного обеспечения и т. д., что может происходить снова и снова.
Если вы используете один и тот же служебный аккаунт для каждого пользователя, то да, вы теряете часть следа аудита. Тем не менее, вы не должны распределять один JSON-ключ служебного аккаунта с приложением. Вы должны выдавать разные служебные аккаунты каждому пользователю. Ваш пример тогда становится [email protected]. Пользователь должен защищать учетные данные служебного аккаунта так же, как он бы защищал свои учетные данные электронной почты.
Ответ или решение
Использование сервисных аккаунтов (service accounts) в Google Cloud Platform (GCP) вместо пользовательских аккаунтов (user accounts) рекомендовано по нескольким причинам, связанным с безопасностью, управляемостью и эффективностью. Давайте рассмотрим эти аспекты более подробно.
1. Безопасность
Сервисные аккаунты предназначены для работы приложений и виртуальных машин (VM), а не для индивидуальных пользователей. Это позволяет изолировать доступ и повысить безопасность. Пользовательские аккаунты могут быть подвержены атакам, таким как фишинг, и могут быть ненадлежащим образом использованы. Сервисные аккаунты, в свою очередь, требуют меньше проверок безопасности и обеспечивают более простой процесс получения токенов OAuth, что снижает вероятность уязвимостей.
2. Управляемость
С использованием сервисных аккаунтов проще управлять доступом и правами. Вы можете создавать отдельные сервисные аккаунты для различных сервисов или приложений с четко определенными правами доступа. Это позволяет применять принцип наименьших привилегий (least privilege), который является важной практикой в области информационной безопасности. С пользовательскими аккаунтами такого уровня контроля обычно достичь сложнее.
3. Автоматизация и непрерывная интеграция
Сервисные аккаунты лучше подходят для сценариев автоматизации и CI/CD (непрерывной интеграции и доставки). Поскольку они могут бесшовно взаимодействовать с различными компонентами GCP и сторонними инструментами без необходимости постоянной авторизации пользователей, это значительно ускоряет процессы развертывания и управления ресурсами.
4. Потеря неотказуемости при использовании сервисных аккаунтов
Вы правильно отметили, что при использовании сервисных аккаунтов может возникнуть проблема с отслеживанием действий конкретного разработчика в журналах аудита. Это действительно важный аспект, поскольку если несколько разработчиков используют один и тот же сервисный аккаунт, идентифицировать, кто именно выполнил определенные действия, становится сложнее.
Тем не менее, существует ряд практик, которые можно использовать для минимизации этой проблемы:
- Четкое распределение аккаунтов: Создавайте отдельные сервисные аккаунты для различных приложений или групп пользователей, чтобы действия каждого аккаунта можно было прослеживать.
- Управление ключами: Для каждого сервисного аккаунта можно создавать уникальные ключи и управлять их доступностью. Это означает, что даже если один ключ будет скомпрометирован, другие останутся в безопасности.
- Инструменты для аудита: Использование инструментов мониторинга и аудита, которые могут дополнительно отслеживать действия пользователей и сервисов, чтобы дать более четкую картину действий в вашей системе.
Заключение
Сервисные аккаунты в GCP представляют собой лучший способ управления доступом и аутентификацией для автоматизированных процессов и приложений, однако важно правильно настраивать и управлять этими аккаунтами для обеспечения необходимого уровня безопасности и возможности аудита. Применяя данные рекомендации, вы сможете использовать преимущества сервисных аккаунтов, не жертвуя при этом возможностью отслеживания действий пользователей.