Предоставить основному участнику Terraform Service, но удалить из Key Vault
Мы создаем решение в Azure для государственных организаций и будем использовать Terraform для развертывания решения. Кажется, что предпочтительным методом является создание субъекта-службы для Terraform с субъектом-службой, имеющим роль участника, привязанную к подписке.
Единственная проблема, которую мы пытаемся решить, заключается в том, что это дает плоскости управления субъекта-службы доступ к Key Vault ... поскольку он находится в подписке. С ролью Участник субъект-служба не может создавать новые политики доступа (назначать себе или другим разрешениям на уровне данных), но мы ищем способ, позволяющий удалить субъект-службу из любых разрешений плоскости управления.
Мы попытались установить блокировку ReadOnly на хранилище ключей перед созданием субъекта-службы, но эта блокировка не мешает субъекту службы получить разрешения участника в хранилище ключей.
Есть ли у кого-нибудь творческие идеи, которые могут помочь в достижении этой цели, помимо создания новой роли, в которой есть участник для всего, ЗА ИСКЛЮЧЕНИЕМ для Key Vault?
Ответы 1
Да, основная причина всех проблем с безопасностью заключается в том, что роль участника-участника-участника-службы назначается на уровне / области подписки, что позволяет ему наносить значительный ущерб, особенно если в одной подписке развернуто несколько приложений (например, удалить любую группу ресурсов).
Один из подходов:
- Подготовьте одна группа ресурсов для хранилища ключей Azure для конкретного приложения и региона (последнее в случае географически распределенных приложений).
- Подготовьте хранилище ключей Azure для группы ресурсов, созданной на предыдущем шаге.
In our case, the Security Office was responsible for the first 2 steps, where they had monitoring (e.g. email, text-messages, etc.) for any change in the Azure Key Vault (e.g. new keys/secrets/certificates added/deleted/changed, permission changes, etc.).
- Предоставление вторая группа ресурсов, которое будет служить контейнером для компонентов приложения (например, функции Azure, SQL Server / базы данных Azure, пространства имен / очереди служебной шины Azure и т. д.).
- Создайте субъекта-службы и назначить роль "Участник"
только группа ресурсов приложения, например:
scope = /subscriptions/{Subscription Id}/resourceGroups/{Resource Group Name}
Find a sample PS script to provision a Service Principal with custom scope at https://github.com/evandropaula/Azure/blob/master/ServicePrincipal/PS/Create-ServicePrincipal.ps1.
- Предоставьте соответствующие разрешения для субъекта-службы в Azure Key Vault. В нашем случае мы решили создать отдельный Сервис Учетные записи участников для развертывания (разрешения Читай пиши для ключей / секретов / сертификатов) и времени выполнения (разрешения Только чтение для ключей / секретов / сертификатов);
Find a sample PS script to set Service Principal permission on an Azure Key Vault at https://github.com/evandropaula/Azure/blob/master/KeyVault/PS/Set-ServicePrincipalPermissions.ps1.
Тем не менее, у этого подхода есть много неудобств, таких как:
- Процесс (например, через модуль Runbook) для подготовки хранилища ключей Azure (включая его группу ресурсов) и группы ресурсов приложения будет находиться за пределами основного шаблона Terraform, отвечающего за компоненты приложения, что требует координации с различными командами / процессами / инструментами и т. д.
- Активный сайт, предполагающий возможность подключения, часто предполагает координацию между несколькими командами для обеспечения достижения целей RTO и MTTM (среднее время смягчения последствий).
- Субъект службы сможет удалить - это специфическая для приложения группа ресурсов при выполнении терраформное разрушение, но он не сможет воссоздать при запуске терраформ применять после этого из-за отсутствия разрешений на уровне / области подписки. Вот ошибка:
provider.azurerm: Unable to list provider registration status, it is possible that this is due to invalid credentials or the service principal does not have permission to use the Resource Manager API, Azure error: resources.ProvidersClient#List: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code = "AuthorizationFailed" Message = "The client '' with object id '' does not have authorization to perform action 'Microsoft.Resources/subscriptions/providers/read' over scope '/subscriptions/{Subscription Id}'.".
Да, я знаю, это длинный ответ, но эта тема обычно требует большого количества межкомандных обсуждений / мозгового штурма, чтобы убедиться, что меры безопасности, установленные Управлением безопасности, соблюдены. графики выпуска и цели RTO / MTTM выполнены. Надеюсь, это немного поможет!