Fundamentos de segurança do Azure Bicep

Escrito por

Mark Johnson

13 de dezembro de 2022

0 minutos de leitura

Este post foi escrito pelo embaixador da Snyk Mark Johnson (@tazmainiandevil). Tenha acesso antecipado à Snyk inscrevendo-se para se tornar um embaixador da Snyk.

O Azure Bicep está se tornando cada vez mais popular e rapidamente substituindo os modelos do Azure Resource Manager (ARM). Neste post, vou apresentar alguns fundamentos de segurança para usar o Bicep. Se você ainda não conhece o Bicep, recomendo consultar a documentação do Microsoft Learn para saber mais.

Mantenha os segredos fora do controle de versão

Todos sabemos que precisamos manter os segredos fora do controle de versão, mas é muito fácil deixá-los acidentalmente em arquivos, especialmente ao testar configurações do Bicep localmente.

Veja algumas maneiras de evitar o commit de segredos:

Passe parâmetros pela linha de comando.
Use um arquivo JSON de parâmetros ignorado pelo controle de versão. Por exemplo, se você usa Git, adicione-o ao arquivo .gitignore.

Proteja as entradas

Passar parâmetros externamente é uma coisa, mas como garantir que os segredos estejam protegidos e não apareçam nas saídas? O Bicep oferece o decorador @secure para parâmetros dos tipos String e Object. Por exemplo:

1@secure()
2param adminPassword string
3
4@secure()
5param adminCredentials object

Tenha cuidado com as saídas

Adicionar saídas aos módulos do Bicep é muito útil, mas há alguns pontos importantes. Se você definir uma saída que pareça conter um segredo, o Bicep emitirá um aviso de que possíveis segredos estão sendo expostos. A saída a seguir, com uma cadeia de conexão de uma conta de armazenamento, geraria esse aviso:

1output connection string = 'DefaultEndpointsProtocol=https;AccountName=${storageaccount.name};EndpointSuffix=${environment().suffixes.storage};AccountKey=${listKeys(storageaccount.id, storageaccount.apiVersion).keys[0].value}'

No entanto, se o valor fosse atribuído a uma variável antes de ser incluído na saída, nenhum aviso seria exibido, e isso poderia passar despercebido.

1var connectionString = 'DefaultEndpointsProtocol=https;AccountName=${storageaccount.name};EndpointSuffix=${environment().suffixes.storage};AccountKey=${listKeys(storageaccount.id, storageaccount.apiVersion).keys[0].value}'
2
3output connection string = connectionString

Agora, veja o que acontece quando um recurso de conta de armazenamento é implantado no Azure com a seguinte configuração:

1deploy.bicep
2param location string = resourceGroup().location
3param tags object = {}
4param storageName string = 'stsecureteststore'
5param sku string = 'Standard_LRS'
6
7module storageModule 'modules/storage.bicep' = {
8  name: 'StorageDeploy'
9  params: {
10    location: location
11    storageName: storageName
12    tags: tags
13    sku: sku
14  }
15}
16
17modules/storage.bicep
18
19@description('The storage account name')
20@minLength(3)
21@maxLength(24)
22param storageName string
23@description('The storage account location')
24param location string
25@description('The tags for the storage account')
26param tags object
27@description('The storage account sku') 
28@allowed([ 'Standard_LRS', 'Standard_GRS', 'Standard_GZRS', 'Standard_RAGRS', 'Standard_RAGZRS', 'Standard_ZRS', 'Premium_LRS', 'Premium_ZRS' ])
29param sku string = 'Standard_LRS'
30@description('The access tier for the blob services') 
31@allowed([ 'Hot', 'Cool' ]) 
32param accessTier string = 'Hot' 
33@description('Allow public access to blobs') 
34param allowBlobPublicAccess bool = false 
35
36resource storageaccount 'Microsoft.Storage/storageAccounts@2022-05-01' = {
37  name: storageName
38  location: location
39  kind: 'StorageV2'
40  tags: tags
41  sku: {
42    name: sku
43  }
44  properties: {
45    supportsHttpsTrafficOnly: true
46    minimumTlsVersion: 'TLS1_2'
47    accessTier: accessTier
48    allowBlobPublicAccess: allowBlobPublicAccess
49  }
50}
51
52var connectionString = 'DefaultEndpointsProtocol=https;AccountName=${storageaccount.name};EndpointSuffix=${environment().suffixes.storage};AccountKey=${listKeys(storageaccount.id, storageaccount.apiVersion).keys[0].value}'
53output connection string = connectionString

Todas as saídas definidas no Bicep podem ser visualizadas em Implantações, no grupo de recursos em que os recursos foram implantados:

Página Implantações do portal do Azure para o grupo de recursos rg-security-example, mostrando as implantações StorageDeploy e main com status Concluído

Ao analisar as saídas de StorageDeploy, vemos que a conexão é exibida com a chave da conta em texto simples:

Página de saídas StorageDeploy do portal do Azure exibindo a saída de uma string de conexão de uma conta de armazenamento.

Isso significa que qualquer pessoa com acesso para visualizar os recursos no portal do Azure pode ver essas saídas. Para manter uma boa postura de segurança, recomendamos não retornar segredos como saídas no Bicep.

Esperamos que, no futuro, o Bicep ofereça suporte ao decorador @secure nas saídas para permitir o retorno seguro de segredos.

Segredos de recursos

Se retornar segredos do Bicep é um problema, como passar segredos de um módulo para outro? Uma opção é acessar um recurso existente usando a palavra-chave existing. Por exemplo:

1param storageName string
2
3resource storageaccount 'Microsoft.Storage/storageAccounts@2022-05-01' existing = {
4  name: storageName  
5}
6
7var connectionString = 'DefaultEndpointsProtocol=https;AccountName=${storageName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${listKeys(storageaccount.id, storageaccount.apiVersion).keys[0].value}'

Essa cadeia de conexão poderia então ser usada como entrada para outro recurso.

Segredos do Key Vault

Acessar recursos existentes é uma maneira de obter segredos, mas também há suporte para recuperá-los usando o Key Vault.

Observação: verifique se a configuração de acesso do Key Vault permite o acesso por meio de "Azure Resource Manager para implantação de modelos"

Configurações de acesso a recursos com o Azure Resource Manager selecionado para implantação de modelos, enquanto máquinas virtuais e criptografia de disco permanecem desmarcadas.

Os Key Vaults são acessados da mesma forma descrita na seção anterior, usando a palavra-chave existing. No entanto, há uma ressalva: o método getSecret só pode ser usado ao atribuir um parâmetro de módulo com o decorador @secure:

1deploy.bicep
2param location string = resourceGroup().location
3param tags object
4param sqlServerName string
5param keyVaultName string
6param keyVaultResourceGroupName string
7param subscriptionId string = subscription().subscriptionId
8
9resource vaultResource 'Microsoft.KeyVault/vaults@2022-07-01' existing = {
10  name: keyVaultName 
11  scope: resourceGroup(subscriptionId, keyVaultResourceGroupName  )
12}
13
14module sqlModule 'modules/sql.bicep' = {
15  name: 'SqlDeploy'
16  params: {
17    location: location
18    tags: tags
19    sqlServerName: sqlServerName
20    administratorLogin: vaultResource.getSecret('sqlUser')
21    administratorLoginPassword: vaultResource.getSecret('sqlPassword')
22  }  
23}
24
25modules/sql.bicep
26@description('The resource location')
27param location string
28@description('The tags for the resources')
29param tags object
30@description('The name for the SQL Server')
31param sqlServerName string
32@secure()
33@description('The SQL Administrator Login')
34param administratorLogin string
35@secure()
36@description('The SQL Administrator password')
37param administratorLoginPassword string
38
39resource sqlServerResource 'Microsoft.Sql/servers@2022-05-01-preview' = {
40  name: sqlServerName
41  location: location
42  tags:tags
43  properties: {
44    administratorLogin: administratorLogin
45    administratorLoginPassword: administratorLoginPassword
46  }
47}

Análise de segurança do Bicep

A análise de infraestrutura como código (IaC) está se tornando bastante popular, e é bom ver o interesse em identificar problemas de segurança o quanto antes. A Snyk oferece uma CLI gratuita que pode ser usada para analisar IaC localmente com base em padrões de segurança e conformidade. Embora não ofereça suporte direto ao formato Bicep, ela analisa modelos ARM, para os quais o Bicep é compilado.

Para compilar Bicep em ARM, você precisa ter a CLI do Bicep instalada. Para começar a usar a CLI da Snyk, crie uma conta gratuita e depois instale a CLI da Snyk usando npm. Se você tiver o Node.js instalado localmente, poderá instalá-la executando:

1npm install snyk@latest -g

Depois de instalar e configurar, execute o comando:

1az bicep build -f {file_name}.bicep

Isso vai gerar um arquivo JSON com o mesmo nome do arquivo Bicep. Em seguida, você poderá executar a análise da Snyk com o comando:

1snyk iac test {file_name}.json

Considerações finais

Todos precisamos pensar em segurança. Embora ela seja um alvo em constante mudança, quanto mais aprendemos, mais podemos fazer para proteger nossos recursos. Espero que este post tenha sido informativo e ajudado você a proteger suas configurações do Bicep.

Segurança de IaC pensada para quem desenvolve

A Snyk protege sua infraestrutura como código do ciclo de vida do desenvolvimento de software até a execução na nuvem, com um mecanismo unificado de políticas como código para que todas as equipes possam desenvolver, implantar e operar com segurança.

Agende uma demonstração ao vivo