Guia Estendido
Apenas SCEPman Enterprise Edition
Isto o guiará por todas as etapas para implementar o SCEPman para um ambiente de nível empresarial com requisitos avançados, por exemplo, convenções de nomenclatura, redundância ou autoescalonamento.
Implantação no Azure
Vamos começar com os requisitos e uma visão geral dos recursos. Tenha em mente que precisa de planear um design útil dos recursos do Azure.
Pré-requisitos
Obrigatório
Opcional
Visão Geral dos Recursos do Azure
Os seguintes recursos são recomendados para um ambiente de produção.
Além disso, se estiver a usar Private Endpoints, tem sete recursos adicionais do Azure.
Passos de configuração
Implementar os serviços base do SCEPman
Este é um passo obrigatório.
Faça a sua escolha sobre se gostaria de implantar com um Windows ou Linux App Service Plan. Ambos os métodos de implantação permitirão escolher o seu Sistema Operativo.
Para começar a implantação, você precisa seguir as nossas instruções de configuração, utilizando um ARM Template
implementação Enterpriseou, alternativamente, o nosso Terraform script:
implementação do TerraformRealizar passos pós-implementação (atribuições de permissões)
Este é um passo obrigatório.
Para ligar corretamente todos os componentes do SCEPman, várias permissões precisam ser atribuídas. Siga estes passos para estabelecer as ligações relevantes:
Identidades gerenciadasAdicionar permissões do Certificate Master
Este é um passo passo para Enterprise Edition clientes. Community Edition utilizadores podem ignorar este passo.
O Certificate Master é uma funcionalidade da Enterprise Edition que permite aos administradores gerar e revogar certificados manualmente. Siga estes passos para conceder acesso ao Certificate Master.
Certificate Master RBACCriar Certificado Raiz
Este é um passo obrigatório.
Após a conclusão da implementação e da atribuição de permissões, precisa de criar o certificado raiz para o SCEPman:
CA raizConfigurar um Domínio Personalizado e um Certificado SSL
Este é um recomendado etapa. No entanto, ignore esta etapa se estiver a implementar redundância geográfica.
Para disponibilizar o seu SCEPman no seu domínio específico, precisa de criar um Domínio Personalizado no App Service.
Domínio PersonalizadoAtualizações manuais
Este é um opcional obrigatório.
Por predefinição, o SCEPman adota uma abordagem evergreen em relação às atualizações. Caso precise de controlo total sobre as suas atualizações do SCEPman, configure um deployment slot conforme descrito no guia seguinte na secção Configuração do Deployment Slot.
Estratégia de atualizaçãoImplementar o Application Insights
Isto é recomendado obrigatório.
O Application Insights pode ser usado para obter uma visão geral do desempenho do App Service e para obter informações mais detalhadas sobre o processamento de pedidos do SCEPman. Recomendamos configurar sempre o Application Insights para monitorizar, manter e otimizar o App Service.
Application InsightsConfigurar o Health Check
Isto é recomendado obrigatório.
Os Health Checks podem ser configurados para notificar os administradores no caso de o SCEPman App Service não responder.
Verificação de saúdeCertifique-se de que o SCEPman tem recursos suficientes
Este é um passo obrigatório.
Depois de mover o SCEPman para um ambiente de produção, deve garantir que o SCEPman está equipado com capacidade de processamento suficiente. Por isso, reveja o nosso guia de dimensionamento do Azure e atualize o nível do seu App Service Plan, se necessário. Pode adiar isto até depois da sua PoC ou da fase de avaliação.
Dimensionamento do App ServiceConfigurar Autoescalonamento
Este é um opcional obrigatório.
A solução SCEPman tem duas tarefas diferentes e requisitos de desempenho. Uma tarefa é o processo de emissão de certificados: Após a configuração da solução SCEPman, precisamos de implantar certificados em todos os dispositivos (certificados de utilizador e/ou dispositivo), mas esta é uma tarefa única e, após a implantação inicial, isso só acontece quando um novo dispositivo é inscrito ou os certificados precisam ser renovados. Nessas situações, o SCEPman enfrentará um pico de pedidos SCEP.
A segunda tarefa é a validação de certificados: Após implantarmos certificados nos dispositivos, esses certificados precisam de ser validados sempre que os utilizamos. Para cada autenticação baseada em certificado, os clientes, gateways ou o sistema RADIUS (depende do que você usa) enviarão um pedido OCSP para o SCEPman App Service. Isso causará uma carga permanente de pedidos no App Service.
Para ter um desempenho otimizado e controlar os custos, recomendamos configurar a funcionalidade de Autoescalonamento do App Service. Com esta funcionalidade, a sua aplicação pode escalar horizontalmente e reduzir a escala com base em métricas.
AutoscalingConfigurar Redundância Geográfica
Este é um opcional obrigatório.
Configurar uma instância redundante geograficamente para o SCEPman pode melhorar a disponibilidade do serviço e a resiliência, distribuindo cargas de trabalho por várias regiões do Azure.
No entanto, é importante notar que esta configuração pode levar a custos maiores no Azure devido aos recursos adicionais e à replicação de dados envolvidos. A Microsoft fornece um SLA de 99,95% para Azure App Services, o que é adequado na maioria dos cenários.
Geo-redudânciaConfigure os seus perfis de implementação de MDM
Este é um recomendado obrigatório.
Com a conclusão dos passos acima, temos uma implementação funcional do SCEPman e podemos agora implementar certificados nos dispositivos.
Utilize um (ou mais) dos artigos seguintes para implementar certificados com a sua solução MDM preferida:
Microsoft IntuneJamf ProOutras soluções MDMEmitir certificados manualmente ou assinar CSRs usando o Certificate Master
Este é um opcional obrigatório.
Siga o link abaixo para saber como emitir certificados de servidor TLS com base numa lista de FQDNs ou assinar qualquer CSR usando o componente Certificate Master.
Certificate MasterEmitir Certificados usando a Enrollment REST API
Este é um opcional obrigatório.
O SCEPman apresenta uma API REST para registar certificados. Esta é uma alternativa aos endpoints SCEP, que exigem o estilo de autenticação SCEP, enquanto a API REST usa identidades Microsoft para autenticação. O protocolo também é muito mais simples do que o SCEP.
Enrollment REST APICriar Bloqueios nos recursos do Azure do SCEPman
Este é um opcional obrigatório.
Por predefinição, o SCEPman não aplica quaisquer bloqueios aos recursos do Azure. Se utilizar bloqueios de recursos e quiser configurá-los, a lista seguinte descreve que tipos de bloqueio podem ser aplicados a cada recurso do SCEPman.
Key Vault: Soft Delete e Purge Protection já fornecem proteção contra eliminação acidental. O SCEPman não modifica o recurso após a criação da chave da CA, portanto um ReadOnlyLock é tecnicamente possível.
Storage Account: Apenas um DeleteLock é possível, pois o SCEPman precisa de escrever informações de certificados na tabela. Se um Storage Account for eliminado acidentalmente, você perde informações sobre certificados já emitidos.
App Services: Um ReadOnlyLock é teoricamente possível, mas tem de ser removido sempre que modificar a configuração do SCEPman. Um App Service eliminado pode ser facilmente reinstalado, mas terá apenas a configuração predefinida, pelo que todas as alterações manuais terão de ser reconfiguradas manualmente. Uma combinação de DeleteLock e ReadOnlyLock ajuda a mitigar este risco.
Log Analytics Workspace: Um DeleteLock é tecnicamente possível, mas você apenas perderia registos recolhidos durante o período de retenção, o que não afeta a disponibilidade do serviço SCEPman.
Outros Recursos do Azure: Estes não armazenam dados e podem ser recriados sem perda de informação. Um DeleteLock e ReadOnlyLock pode ser útil para alguns deles. Alguns não podem ser eliminados de forma alguma porque têm dependências num dos serviços principais mencionados acima.
Last updated
Was this helpful?