O Dell Command | Configuração segura do BIOS – Oferta SaaS via Microsoft Azure Marketplace

Produtos afetados:

• O Dell Command | Configuração segura do BIOS
• Dispositivos client comerciais da Dell (notebooks, desktops, workstations)

Sumário:

• Introdução
• Modelo de implementação -- hospedado pelo cliente no Azure
• DCSBC Cloud versus DCSBC no local (DCC)
• Infraestrutura as Code (Terraform)
• Pré-requisitos
• Como começar -- Acessando o portal em nuvem do DCSBC
• Criando políticas do BIOS
  • Fluxo de trabalho da política de autenticação
  • Fluxo de trabalho da política de configurações do BIOS
  • Fluxo de trabalho da política de desprovisionamento
• Requisitos e carregamento do certificado
• Políticas de publicação no Microsoft Intune
• Controles de segurança
• FAQs

Introdução

As interfaces de capacidade de gerenciamento dependem de interfaces abertas ou comandos autenticados por senha. A autenticação por senha é vulnerável a ataques de força bruta ou dicionário, portanto, menos segura em comparação com a autenticação baseada em chave. É necessária uma interface melhor de capacidade de gerenciamento autenticada para oferecer proteções de integridade e confidencialidade dos dados e comandos. O Dell Command | Secure BIOS Configuration (DCSBC) é uma abordagem para evitar a autenticação de comandos DACI com senhas do BIOS. O DCSBC fornece comunicação confiável criando uma interface que usa mecanismos de autenticação PKI (Public Key Infrastructure) e canais criptografados para passar mensagens entre a plataforma e um cliente. Essa abordagem fornece integridade e confidencialidade para proteger os dados do cliente.
O DCSBC Cloud estende esse recurso para um modelo SaaS hospedado na nuvem implementado na própria assinatura do Azure do cliente. Em vez de instalar e manter um servidor DCSBC no local com o Dell Command | Configure(DCC), os administradores de TI acessam um portal baseado na Web hospedado em seu próprio ambiente do Azure. Toda a infraestrutura é provisionada automaticamente via Terraform (Infraestrutura como Código). As políticas são criadas por meio de um portal da Web orientado passo a passo e publicadas diretamente no Microsoft Intune, sem configuração de servidor local, geração de SCE (Self-Contained Executable) e sem necessidade de instalação do agente de ponto de extremidade.

Principais benefícios da nuvem DCSBC:

• O cliente é dono dos dados —Toda a infraestrutura é executada na assinatura do Azure do cliente. As políticas do BIOS, as chaves criptográficas, os dados de configuração e os logs de auditoria permanecem sob total propriedade e controle do cliente. A Dell não tem acesso aos dados do cliente.
• Soberania e conformidade de dados — Os clientes escolhem a região do Azure para implementação, garantindo que os requisitos de residência de dados sejam atendidos. Todos os dados permanecem na região selecionada.
• Infraestrutura as Code - Toda a solução é provisionada via Terraform, fornecendo implementações de infraestrutura reproduzíveis, auditáveis e controladas por versão.
• Sem infraestrutura no local - Elimina a necessidade de instalar e manter um servidor DCSBC com o Dell Command | Configure.
• Gerenciamento de políticas baseado na Web — Crie e gerencie políticas do BIOS em qualquer navegador usando um assistente passo a passo intuitivo.
• Integração nativa do Intune — As políticas são publicadas diretamente no Microsoft Intune como aplicativos Win32 LOB com um único clique.
• Implementação sem agente — Nenhum agente necessário nos endpoints. O pacote implementado é independente.
• Assinatura HSM gerenciada do Azure — Todas as cargas do BIOS são assinadas criptograficamente usando o HSM gerenciado pelo Azure (RS384), garantindo que apenas as alterações autorizadas alcancem os dispositivos.
• Arquitetura Zero Trust - A confiança existe apenas entre o BIOS e o serviço DCSBC Cloud; Não é necessário confiar no client/endpoint.
• Prevenção integrada contra ataques de repetição — cada sessão do BIOS usa trocas de chaves temporárias e criptográficas exclusivas, garantindo que as cargas capturadas anteriormente não possam ser reutilizadas ou reproduzidas nos dispositivos.
• Payloads criptograficamente vinculadas a dispositivos : as cargas de configuração do BIOS são vinculadas criptograficamente a cada dispositivo individual durante o estabelecimento da sessão, impedindo que payloads destinadas a um dispositivo sejam aplicadas a outro.

Voltar ao início

Modelo de implementação -- hospedado pelo cliente no Azure

Ao contrário das ofertas tradicionais de SaaS, em que o fornecedor hospeda a infraestrutura, o DCSBC Cloud é implementado na própria assinatura do Microsoft Azure do cliente. Essa arquitetura oferece várias vantagens críticas:

• Propriedade e controle dos dados: Todos os recursos do Azure — computação, armazenamento, banco de dados, HSM, sistema de rede — são provisionados no grupo de usuários e na assinatura do Azure do cliente. As configurações de política do BIOS, as chaves de assinatura criptográficas, os dados de sessão e os logs de auditoria são armazenados no Banco de Dados SQL do Azure, no Cofre de Chaves do Azure/HSM gerenciado e na Conta de Armazenamento do Azure do próprio cliente. A Dell Technologies não tem acesso aos dados, às chaves ou à infraestrutura do cliente. O cliente mantém total controle administrativo.
• Soberania e conformidade de dados: O cliente seleciona a região do Azure para implementação (por exemplo, Leste dos EUA 2, Europa Ocidental, Leste da Austrália). Todos os recursos são provisionados nessa única região.
  O armazenamento usa o LRS (Locally Redundant Storage, armazenamento com redundância local) por padrão, garantindo que os dados não saiam da região selecionada. Isso pode ser configurado para armazenamento com redundância geográfica (GRS) ou armazenamento com redundância de zona (ZRS) com base nos requisitos do cliente. O modelo hospedado pelo cliente oferece suporte à conformidade com as normas de residência de dados (RGPD, leis de soberania de dados, mandatos específicos do setor), uma vez que o cliente controla onde os dados residem.
• Isolamento do grupo de usuários: Cada cliente obtém uma implementação totalmente isolada: seu próprio grupo de recursos, rede virtual, sub-redes, bancos de dados, cofres de chaves e todos os outros recursos. O isolamento de rede é imposto por meio de pontos de extremidade privados, grupos de segurança de rede e firewall do Azure.
• Transparência de custos: Todos os custos de recursos do Azure aparecem no faturamento do próprio Azure do cliente, fornecendo visibilidade total dos gastos com infraestrutura. O cliente pode aproveitar os compromissos existentes do Azure (MACC — Microsoft Azure Consumption Commitment) e instâncias reservadas.

Voltar ao início

DCSBC Cloud versus DCSBC no local (DCC)

Observação:
As duas soluções compartilham o mesmo protocolo subjacente no nível do BIOS, inclusive comandos baseados em sessão com troca de chaves Diffie-Hellman, proteção contra repetição baseada em terceiros e autenticação PKI. As políticas criadas com qualquer uma das soluções são compatíveis com as mesmas implementações de BIOS de clients comerciais da Dell.

Voltar ao início

Infraestrutura as Code (Terraform)

Toda a infraestrutura da DCSBC Cloud é provisionada usando Terraform (HashiCorp), fornecendo implantações repetíveis, auditáveis e controladas por versão. A configuração do Terraform é modular e parametrizada, permitindo que cada implementação do cliente seja personalizada para sua região do Azure, convenções de nomenclatura e requisitos de dimensionamento.
Visão geral da configuração do Terraform:

• Versão Terraform: >= 1,3.0
• Provedor do AzureRM: ~> 4.37.0
• Gerenciamento de estado: Estado remoto armazenado na conta de armazenamento do Azure (autenticação do Azure AD)
• Recursos provisionados do Azure: Os seguintes recursos são provisionados automaticamente na assinatura do Azure do cliente:

Voltar ao início

Pré-requisitos

Antes de usar o DCSBC Cloud, certifique-se de que os seguintes pré-requisitos sejam atendidos:

• Assinatura do Microsoft Azure - uma assinatura ativa do Azure com um locatário do Azure Entra ID (Azure AD).
• Microsoft Intune — um ambiente ativo do Microsoft Intune configurado para gerenciamento de dispositivos.
• Dispositivos de client comerciais da Dell : os dispositivos de destino devem ser notebooks, desktops ou workstations comerciais da Dell com BIOS compatível com DCSBC, registrados no Microsoft Intune.
• Azure Managed HSM ou Azure Key Vault - Uma instância do Azure Managed HSM ou Key Vault provisionada com chaves RSA-HSM que correspondem aos certificados usados para autenticação do BIOS. A chave privada deve residir no HSM; somente o certificado público (.pem) é carregado no portal DCSBC Cloud.
• Certificados X.509 : certificados RSA que atendem aos seguintes requisitos:
  • Comprimento da chave: RSA de 3.072 bits (exatamente)
  • Formato: PEM (extensão de arquivo .pem)
  • Versão: X.509 v3
  • Tamanho do arquivo: máximo 8 KB
  • Algoritmo: RSA (OID 1.2.840.113549.1.1.1)
• Navegador compatível - Um navegador da Web moderno (Microsoft Edge, Google Chrome, Mozilla Firefox).

Voltar ao início

Como começar -- Acessando o portal em nuvem do DCSBC

• Inscrever-se — Comprar o Dell Command | Secure BIOS Configuration Cloud por meio do Microsoft Azure Marketplace.
• Fazer login : navegue até a URL do portal em nuvem do DCSBC fornecida na assinatura. Entre com suas credenciais do Microsoft Entra ID (Azure AD). O portal usa a Microsoft Authentication Library (MSAL) para logon único.
• Página inicial - Após a autenticação, você será direcionado para o painel de indicadores de políticas do BIOS. Aqui você pode:
  • Exibir as políticas existentes do BIOS publicadas em seu grupo de usuários do Intune
  • Criar uma nova política usando o portal da Web passo a passo

Voltar ao início

Criando políticas do BIOS

Na página Políticas do BIOS, clique em Criar uma nova política. Você verá três tipos de política:

Selecione um tipo de política para iniciar o assistente guiado. Essas políticas são implantadas diretamente do Intune em seus endpoints sem exigir a instalação de nenhum agente de endpoint.

Nota:

Em qualquer instância, apenas uma chave de provisionamento pode ser provisionada em uma máquina client.

Nota:

Até sete chaves de comando podem ser provisionadas em uma máquina client em qualquer instância específica.

Fluxo de trabalho da política de autenticação

O assistente de política de autenticação tem três etapas:

Etapa 1 -- Nomeie sua política

• Digite um nome de política (obrigatório, máximo de 488 caracteres). Um prefixo AUTH_ e um sufixo de carimbo de data/hora _DD.MM.YY_HH:mm_UTC são adicionados automaticamente.
• Digite uma descrição opcional (máx. de 1.000 caracteres).
• O nome completo da política (incluindo prefixo e sufixo, máximo de 512 caracteres) é visualizado antes de continuar.
• Nomes de política duplicados são detectados automaticamente verificando as políticas publicadas existentes no Intune.

Etapa 2 -- Gerenciar a segurança do BIOS (upload do certificado)

• Faça upload de até 3 certificados no total:
  • 1 Certificado de provisionamento (obrigatório) — usado para autenticar a conectividade segura para operações de provisionamento.
  • Até 2 certificados de comando - usados para assinar payloads para alterações de configuração do BIOS.
• Para cada certificado, selecione: 
  • Tipo: Provisionamento ou comando
  • Ação política: Adicionar (provisionar uma nova chave)
• Os certificados são validados no lado do cliente (consulte Requisitos de certificado e upload).
• O botão Next é ativado quando:
  • Um certificado de provisionamento é carregado
  • 1 O certificado de comando é carregado

Etapa 3 -- Revisar e publicar

• Analise o nome, a descrição e o tipo da política.
• Clique em Publicar para publicar a política no Microsoft Intune (consulte Políticas de publicação no Microsoft Intune).

Voltar ao início

Fluxo de trabalho da política de configurações do BIOS

O assistente de Política de Configurações do BIOS tem 4 ou 5 etapas (dependendo se as políticas existentes do BIOS existem no Intune):

Etapa 1 — Copiar e editar ou Iniciar do zero (condicional — mostrado somente se existirem políticas existentes)

• Iniciar um arquivo de política em branco -- Começar com uma configuração vazia.
• Copiar e depois editar -- Copie os valores de atributos do BIOS de uma política publicada existente e modifique-os. Um modal mostra uma lista pesquisável, classificável e paginada de políticas existentes do BIOS.

Etapa 2 -- Nomeie sua política

• O mesmo que Política de autenticação, mas com o prefixo BIOS_.

Etapa 3 -- Escolha os atributos e valores do BIOS

• Uma tabela exibe todos os atributos disponíveis do BIOS no registro de atributos da Dell.
• Procure atributos por nome, filtre por categoria e alterne para mostrar apenas os atributos selecionados.
• Selecione um atributo clicando em sua caixa de seleção e, em seguida, configure seu valor:
  • Atributos de enum (por exemplo, SecureBoot, WakeOnLan) — Selecione em uma lista suspensa os valores permitidos.
  • Atributos inteiros (por exemplo, AutoOnHr, CustomChargeStart) -- Insira um número dentro do intervalo mínimo-máximo.
  • Atributos de string (por exemplo, AssetTag) — Digite o texto com até 80 caracteres.
  • Recursos personalizados (por exemplo, programação automática, configuração de carga da bateria, cor da luz de fundo do teclado) — clique em "View/Change" para abrir um modal de configuração dedicado.
• Um painel de visualização de código mostra uma visualização ao vivo da configuração selecionada no formato CCTK:

[cctk]

SecureBoot=Enabled

WakeOnLan=LanOnly

AutoOn=SelectDays

AutoOnMon=Enabled

AutoOnTue=Enabled

• O botão Next será desativado se nenhum atributo for selecionado ou se qualquer atributo selecionado tiver um valor inválido.

Etapa 4 -- Gerenciar a segurança do BIOS

• Carregue o mesmo certificado de comando que foi usado para a política de autenticação.
• Um certificado de comando é necessário para continuar.

Etapa 5 -- Revisar e publicar

• Analise e publique no Microsoft Intune.

Voltar ao início

Fluxo de trabalho da política de desprovisionamento

O assistente de política de desprovisionamento tem três etapas:

Etapa 1 -- Nomeie sua política

• Igual a outras políticas, com o prefixo DPRV_.

Etapa 2 -- Gerenciar a segurança do BIOS

• Carregue o mesmo certificado de provisionamento que foi usado para a política de autenticação.
• É necessário um certificado de provisionamento.
• Observação: Certificados expirados são permitidos para operações de desprovisionamento, já que o objetivo é remover o provisionamento dos dispositivos.

Etapa 3 -- Revisar e publicar

• Revisar e publicar. A política de desprovisionamento usa uma operação Limpar DACI para remover todas as chaves provisionadas dos dispositivos de destino.

Voltar ao início

Requisitos e carregamento do certificado

O DCSBC Cloud requer certificados X.509 no formato PEM para assinar payloads do BIOS. A chave privada deve ser armazenada no Azure Managed HSM ou no Azure Premium Key Vault; somente o certificado público é carregado no portal do DCSBC.

Regras de validação do certificado:

A validação é realizada no lado do cliente. Depois que um certificado é carregado, o portal exibe:

• Crachá de status de validação (sucesso/falha)
• Emitido na data
• Válido até a data (mostrado em vermelho se tiver expirado)
• Detalhes do emissor: Nome comum (CN), Unidade organizacional (OU), Organização (O), Localização (L)

Mensagens de erro:

• "Carregue um arquivo .pem válido." -- O arquivo não está no formato PEM ou tem extensão errada.
• "O nome do arquivo contém caracteres inválidos." -- Nome do arquivo contém espaços ou caracteres especiais.
• "File max size is 8KB" — O arquivo excede o limite de 8 KB.
• "Este arquivo é inválido, corrompido ou está vazio. Selecione outro arquivo com um certificado x509 válido e tente novamente." --O certificado não pôde ser analisado ou falha na validação X.509 v3/RSA/3072 bits.
• "Este certificado não pode ser usado." -- O certificado expirou e a ação da política é "Add".

Voltar ao início

Políticas de publicação no Microsoft Intune

Depois de concluir o assistente de política, clique no botão Publicar na etapa Revisar e Publicar. O portal executa um pipeline de publicação automatizado de 11 estágios:

Uma barra de progresso e um rastreador de estágio detalhado mostram o status da publicação em tempo real. Após a conclusão bem-sucedida:

• A mensagem "A política {policyName} foi publicada no Intune e estará disponível dentro de alguns minutos" é exibida.
• Exibir no Intune -- Abre o portal de administração do Microsoft Intune em uma nova guia.
• Back to Policies -- Retorna ao painel de indicadores de políticas do BIOS.

Tratamento de erros: Se algum estágio falhar, uma mensagem de erro será exibida com um botão Retry (até três tentativas). Erros comuns incluem tempos de espera excedidos da API do Intune, falhas de carregamento de armazenamento e atrasos de confirmação de arquivos.

Voltar ao início

Controles de segurança

A DCSBC Cloud implementa segurança de defesa profunda em todas as camadas da infraestrutura. Como a solução é executada na assinatura do Azure do cliente, todos os controles de segurança são auditáveis e estão sob a governança do cliente.

Segurança de rede

• Os Pontos de extremidade privados garantem que o tráfego entre os serviços do Azure (banco de dados, cofre de chaves, HSM, armazenamento, serviços de aplicativo) nunca atravesse a Internet pública.
• O acesso à rede pública é desabilitado por padrão para todos os serviços de plano de dados. Somente o gateway de API e os endpoints da CDN são acessíveis publicamente.
• Os grupos de segurança de rede (NSGs) controlam o tráfego de entrada e saída para cada sub-rede com regras granulares.
• Isolamento de rede virtual — todos os recursos são implementados em uma única rede virtual com sub-redes segregadas para cada nível de serviço.

Segurança do aplicativo:

• O Web Application Firewall (WAF) com conjuntos de regras gerenciados pelo OWASP padrão do setor no modo Prevenção, fornecendo proteção contra explorações comuns da Web (injeção de SQL, XSS etc.).
• O firewall no nível da CDN fornece uma camada WAF adicional na borda.
• Limitação de taxa de API -- A limitação de taxa por operação baseada em IP protege os serviços de back-end contra ataques de abuso e negação de serviço.
• Validação de token JWT do Azure AD -- Todas as chamadas de API são validadas para tokens de autenticação do Azure AD, garantindo que apenas usuários autorizados possam acessar serviços de back-end.
• Restrições de CORS — As solicitações de origem cruzada são restritas apenas a origens autorizadas.

Encryption:

• Mínimo de TLS 1.2 aplicado em todos os serviços com apenas conjuntos de codificações fortes permitidos.
• HSM gerenciado pelo Azure -- As operações de assinatura criptográfica usam módulos de segurança de hardware validados pelo FIPS 140-2 Nível 3, garantindo que as chaves nunca sejam expostas no software.
• Os dados em repouso são criptografados usando a criptografia da plataforma Azure em todos os serviços de armazenamento.

Identidade e acesso:

• Identidades gerenciadas (zero credenciais armazenadas) — as Identidades Gerenciadas do Azure são usadas para todas as autenticações de serviço a serviço. Nenhuma senha, cadeia de conexão ou segredos são armazenados na configuração do aplicativo.
• RBAC least privilege -- a cada identidade gerenciada são atribuídas apenas as funções mínimas necessárias, seguindo o princípio de privilégio mínimo.
• Azure Bastion — acesso administrativo seguro a VMs de gerenciamento sem expor IPs públicos.

Alerta e monitoramento

• Alertas automatizados para eventos operacionais e de segurança críticos, inclusive violações de limitação de taxa, erros de back-end, tentativas de acesso não autorizado, padrões de bloqueio de WAF, anomalias de latência de API e falhas de assinatura de HSM.
• Registro de diagnóstico abrangente em todos os componentes da infraestrutura — API gateway, gateway de aplicativos, aplicativos Web, banco de dados, cofre de chaves e HSM — com registros coletados em um espaço de trabalho centralizado do Log Analytics.
• Dashboards para visibilidade operacional em tempo real e análise de tendências.

Governança:

• As verificações de política de pré-implementação (baseadas em OPA) impõem linhas de base de segurança antes que a infraestrutura seja provisionada, inclusive restrições de acesso à rede pública, versões mínimas de TLS, requisitos de proteção de descarte e controles de IP público.
• Os bloqueios de recursos impedem a exclusão acidental de armazenamentos de dados essenciais (cofres de chaves, bancos de dados, contas de armazenamento).

Voltar ao início

FAQs

P: Eu já uso o DCSBC com o Dell Command | Configure no local. Posso migrar para o DCSBC Cloud?

Sim. As duas soluções usam o mesmo protocolo subjacente no nível do BIOS (DACI com autenticação PKI). Os dispositivos provisionados com a solução no local podem ser gerenciados pelo DCSBC Cloud e vice-versa, desde que os mesmos certificados/chaves sejam usados. Você precisará carregar seus certificados existentes no portal do DCSBC Cloud e garantir que as chaves privadas correspondentes estejam disponíveis no HSM gerenciado pelo Azure ou no Cofre de Chaves.

P: Onde o DCSBC Cloud é executado? Ele é hospedado pela Dell?

Não. O DCSBC Cloud é implementado em sua própria assinatura do Microsoft Azure. Toda a infraestrutura — computação, armazenamento, banco de dados, HSM e sistema de rede — é executada em seu grupo de usuários do Azure. A Dell não hospeda nem tem acesso aos seus dados ou infraestrutura. Toda a solução é provisionada automaticamente usando o Terraform.

P: A Dell tem acesso às minhas políticas, chaves ou dados de configuração do BIOS?

Não. Como o DCSBC Cloud é executado inteiramente em sua assinatura do Azure, todos os dados permanecem sob sua propriedade e controle. A Dell fornece o software e os modelos Terraform, mas não acessa, armazena nem processa seus dados.

P: Posso escolher em qual região do Azure implementar?

Sim. A região do Azure é um parâmetro na configuração do Terraform. Você pode implementar em qualquer região do Azure compatível para atender aos seus requisitos de conformidade e residência de dados. Todos os recursos são provisionados na única região selecionada.

P: preciso instalar o Dell Command | Configurar no servidor em nuvem DCSBC?

Não. Não há servidor no local. A infraestrutura é provisionada em sua assinatura do Azure por meio do Terraform, e o aplicativo é executado como serviços gerenciados pelo Azure (Serviço de Aplicativo, Aplicativo de Função, Aplicativo Web Estático).

P: Preciso instalar algum software Dell nos dispositivos endpoint?

Não. Os pacotes .intunewin implementados por meio do Intune são independentes e incluem todos os componentes necessários. Nenhuma instalação do agente de endpoint é necessária.

P: Quais consoles de implementação são compatíveis?

Atualmente, a DCSBC Cloud oferece suporte ao Microsoft Intune como o console de implementação. O DCSBC no local com DCC também é compatível com SCCM e WorkspaceONE.

P: Posso usar meu próprio provedor de HSM em vez do HSM gerenciado pelo Azure?

O DCSBC Cloud foi projetado para funcionar com o Azure Managed HSM ou o Azure Key Vault. Se você precisar de um provedor HSM diferente, considere usar o DCSBC no local com o DCC, que oferece suporte a HSM independente de fornecedor por meio do script de HSMSigning.bat configurável.

P: Quais tamanhos de chaves RSA são compatíveis?

A DCSBC Cloud requer exatamente chaves RSA de 3.072 bits . Chaves de outros tamanhos (2048 bits, 4096 bits etc.) serão rejeitadas durante a validação do certificado.

P: Posso usar o mesmo certificado para as soluções DCSBC no local e na nuvem?

Sim, desde que a chave privada esteja acessível em ambos os ambientes -- armazenados em seu HSM/armazenamento de certificados local para a solução local e no HSM gerenciado pelo Azure ou no Cofre de Chaves para a solução de nuvem.

P: O que acontece se meu certificado expirar?

Certificados expirados não podem ser usados para operações de "Add" (provisionamento). No entanto, certificados expirados são aceitos para operações de desprovisionamento, já que a intenção é remover o provisionamento dos dispositivos.

P: Quais configurações do BIOS posso configurar?

O DCSBC Cloud inclui um registro abrangente de atributos do BIOS que abrange categorias como segurança, gerenciamento de energia e desempenho, configuração do sistema, vídeo e configurações avançadas. Os exemplos incluem SecureBoot, WakeOnLan, ordem de inicialização, programação automática de ativação, configuração da carga da bateria, cor de fundo do teclado e muito mais.

P: Qual versão do Terraform é necessária para implementar o DCSBC Cloud?

Terraform >= 1.3.0 é obrigatório, com o provedor AzureRM ~> 4.37.0.

P: Posso personalizar a implementação da Terraform (por exemplo, tamanhos de SKU, dimensionamento, redundância de armazenamento)?

Sim. A configuração do Terraform é totalmente parametrizada através de variáveis. Você pode personalizar a SKU do plano de serviço de aplicativo, o nível do banco de dados, o tipo de replicação de armazenamento (LRS/GRS/ZRS), as configurações de dimensionamento automático do gateway de aplicativos e muito mais com base em seus requisitos de escala e disponibilidade.