Guia Estendido
Somente SCEPman Enterprise Edition
Isto irá guiá-lo por todas as etapas para implantar o SCEPman em um ambiente de nível empresarial com requisitos avançados, por exemplo convenções de nomes, 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 você precisa planejar um design útil de recursos do Azure.
Pré-requisitos
Obrigatório
Opcional
Visão geral dos Recursos do Azure
Todos esses recursos são recomendados para um ambiente de produção.
Além disso, se você estiver usando Pontos Finais Privados, você terá mais sete Recursos do Azure.
Etapas de Configuração
Implantar Serviços Base do SCEPman
Isto é um passo obrigatório .
Faça sua escolha sobre se deseja implantar com um Windows ou Linux Plano do App Service. Ambos os métodos de implantação permitirão que você escolha seu Sistema Operacional.
Para iniciar a implantação, você precisa seguir nossas instruções de configuração aproveitando um Template ARM
implantação empresarialou alternativamente nosso Terraform script:
implantação via TerraformExecutar Etapas Pós-Implantação (Atribuições de Permissão)
Isto é um passo obrigatório .
Para vincular corretamente todos os componentes do SCEPman, várias permissões precisam ser atribuídas. Por favor, siga estas etapas para estabelecer as conexões relevantes:
Identidades GerenciadasAdicionar Permissões do Certificate Master
Isto é um passo obrigatório etapa para clientes Enterprise Edition . Usuários da Community Edition podem pular esta etapa.
O Certificate Master é um recurso do Enterprise Edition que permite aos administradores gerar e revogar certificados manualmente. Por favor, siga estas etapas para fornecer acesso ao Certificate Master.
RBAC do Gerenciador de CertificadosCriar Certificado Raiz
Isto é um passo obrigatório .
Após a implantação e a atribuição de permissões serem concluídas, você precisa criar o certificado raiz para o SCEPman:
CA RaizConfigurar um Domínio Personalizado e Certificado SSL
Isto é um etapa recomendada . No entanto, pule esta etapa se você estiver implementando geo-redundância / alta disponibilidade.
Para ter seu SCEPman disponível sob seu domínio específico, você precisa criar um Domínio Personalizado no App Service.
Domínio PersonalizadoAtualizações Manuais
Isto é opcional . .
Por padrão, o SCEPman adota uma abordagem evergreen em relação às atualizações. Caso você exija controle total sobre suas atualizações do SCEPman, por favor configure um slot de implantação conforme descrito no guia a seguir na seção Configuração de Slot de Implantação.
Estratégia de AtualizaçãoImplantar Application Insights
Isto é etapa recomendada .
O Application Insights pode ser usado para obter uma visão geral do desempenho do App Service e para obter insights mais profundos do processamento de solicitações do SCEPman. Recomendamos sempre configurar o Application Insights para monitorar, manter e otimizar o App Service.
Application InsightsConfigurar Health Check
Isto é etapa recomendada .
Health Checks podem ser configurados para notificar administradores no caso do App Service do SCEPman ficar sem resposta.
Verificação de IntegridadeAssegure que o SCEPman tenha recursos suficientes
Isto é um passo obrigatório .
Quando você mover o SCEPman para um ambiente de produção, deve assegurar que o SCEPman esteja equipado com potência de computação suficiente. Portanto, por favor revise nosso guia de Dimensionamento para Azure e atualize o nível do seu Plano do App Service se necessário. Você pode postergar isso até depois da sua fase de PoC ou avaliação.
Dimensionamento do App ServiceConfigurar Autoscaling
Isto é opcional . .
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 implantar certificados em todos os dispositivos (certificados de usuário e/ou de dispositivo), mas isto é uma tarefa única e após a implantação inicial isso só ocorre quando um novo dispositivo é matriculado, ou os certificados precisam ser renovados. Nesses casos, o SCEPman enfrentará um pico de solicitações SCEP.
A segunda tarefa é a validação de certificados: Depois de implantarmos certificados nos dispositivos, esses certificados precisam ser validados cada vez que os utilizamos. Para cada autenticação baseada em certificado os clientes, gateways ou o sistema RADIUS (depende do que você usa) enviarão uma solicitação OCSP para o App Service do SCEPman. Isso causará uma carga permanente de solicitações no App Service.
Para ter um desempenho otimizado e controlar os custos, recomendamos configurar a funcionalidade de Autoscaling do App Service. Com esse recurso sua aplicação pode escalar horizontalmente e reduzir com base em métricas.
AutoescalonamentoConfigurar Geo-Redundância
Isto é opcional . .
Configurar uma instância geo-redundante para o SCEPman pode aumentar a disponibilidade e a resiliência do serviço ao distribuir cargas de trabalho por várias regiões do Azure.
No entanto, é importante notar que essa 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-RedundânciaConfigurar seus Perfis de Implantação MDM
Isto é um etapa recomendada .
Com a conclusão das etapas acima, temos uma implementação do SCEPman funcionando e agora podemos implantar certificados nos dispositivos.
Por favor, use um (ou mais) dos seguintes artigos para implantar certificados com sua solução MDM preferida:
Microsoft IntuneJamf ProOutras soluções MDMEmitir Certificados Manualmente ou assinar CSRs usando o Certificate Master
Isto é opcional . .
Por favor, siga o link abaixo para aprender como emitir certificados de servidor TLS baseados em uma lista de FQDNs ou assinar qualquer CSR usando o componente Certificate Master.
Gerenciador de CertificadosEmitir Certificados usando a Enrollment REST API
Isto é opcional . .
O SCEPman possui uma API REST para matricular certificados. Esta é uma alternativa aos endpoints SCEP que requerem o tipo de autenticação estilo SCEP, enquanto a API REST usa Identidades Microsoft para autenticação. O protocolo também é muito mais simples que o SCEP.
API REST de RegistroCriar Locks nos recursos do Azure do SCEPman
Isto é opcional . .
Por padrão, o SCEPman não aplica locks aos recursos do Azure. Se você usa locks de recurso e deseja configurá-los, a lista a seguir descreve quais tipos de lock podem ser aplicados a cada recurso do SCEPman.
Key Vault: Soft Delete e Purge Protection já fornecem proteção contra exclusão acidental. O SCEPman não modifica o recurso após a criação da chave da CA, então um ReadOnlyLock é tecnicamente possível.
Conta de Armazenamento: Apenas um DeleteLock é possível, pois o SCEPman precisa gravar informações de certificados na tabela. Se uma Conta de Armazenamento for excluída acidentalmente, você perde informações sobre certificados já emitidos.
App Services: Um ReadOnlyLock é teoricamente possível, mas ele deve ser removido cada vez que você modificar a configuração do SCEPman. Um App Service excluído pode ser facilmente reinstalado, mas terá apenas a configuração padrão, então todas as alterações manuais devem ser reconfiguradas manualmente. Uma combinação de DeleteLock e ReadOnlyLock ajuda a mitigar esse risco.
Log Analytics Workspace: Um DeleteLock é tecnicamente possível, mas você apenas perderia logs coletados durante o período de retenção, o que não impacta 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 excluídos de forma alguma porque têm dependências em um dos serviços principais mencionados acima.
Last updated
Was this helpful?