Guia Estendido

Apenas SCEPman Enterprise Edition

Isto irá guiá-lo por todas as etapas para implementar o SCEPman num ambiente de nível empresarial com requisitos avançados, por exemplo, convenções de nomenclatura, redundância ou autoescalamento.

Implementação no Azure

Vamos começar com os requisitos e uma visão geral dos recursos. Tenha em mente que precisa planear um design útil dos recursos do Azure.

Pré-requisitos

Obrigatório

• Convenção de nomenclatura de recursos do Azure.

• Subscrição do Azure (pelo menos direitos de Contributor nessa subscrição).

• Direitos de proprietário no Azure (pelo menos ao nível do Resource Group).

• Microsoft Entra ID (Azure AD) "Administrador Global" (Consentimento para aceder à Graph API).

• Certifique-se de definir as suas políticas do Azure de acordo com os requisitos do SCEPman (por exemplo, não impor TLS).

• CNAME de domínio público (scepman.seudodominio.com), apenas se for usada geo-redundância.

• Certificado SSL (ou use Certificado Gerido pelo App Service), apenas se for usada geo-redundância.

• Chave de licença do SCEPman Enterprise Edition.

Opcional

• CNAME de domínio público (scepman.seudodominio.com), apenas se for usado um domínio personalizado.

• Certificado SSL (Wildcard-) (ou use Certificado Gerido pelo App Service), apenas se for usado um domínio personalizado.

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, terá sete recursos adicionais do Azure.

Etapas de Configuração

1

Implementar os Serviços Base do SCEPman

Esta é uma etapa obrigatória .

Faça a sua escolha sobre se pretende implementar com um Windows ou Linux App Service Plan. Ambos os métodos de implementação permitir-lhe-ão escolher o seu sistema operativo.

Para começar a implementação, precisa de seguir as nossas instruções de configuração, utilizando um Modelo ARM

Implementação empresarial

ou, em alternativa, o nosso script Terraform :

Implementação com Terraform

2

Executar as Etapas Pós-Implementação (Atribuições de Permissões)

Esta é uma etapa obrigatória .

Para ligar corretamente todos os componentes do SCEPman, é necessário atribuir várias permissões. Siga estes passos para estabelecer as ligações relevantes:

Identidades Geridas

3

Adicionar Permissões do Certificate Master

Esta é uma etapa obrigatória etapa para clientes da Enterprise Edition . Os utilizadores da Community Edition

poderão saltar esta etapa. Enterprise Edition O Certificate Master é uma funcionalidade da

RBAC do Certificate Master

4

Criar Certificado Raiz

Esta é uma etapa obrigatória .

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 Raiz

5

Configurar um Domínio Personalizado e um Certificado SSL

Esta é uma etapa recomendada etapa. No entanto, salte esta etapa se estiver a implementar geo-redundância.

Para ter o seu SCEPman disponível no seu domínio específico, precisa de criar um Domínio Personalizado no App Service.

Domínio Personalizado

6

Atualizações Manuais

Esta é uma opcional .

Por predefinição, o SCEPman adota uma abordagem evergreen em relação às atualizações. Caso necessite de controlo total sobre as atualizações do SCEPman, configure um deployment slot conforme descrito no seguinte guia, na secção Configuração do Deployment Slot.

Estratégia de Atualização

7

Implementar o Application Insights

Esta é recomendada .

O Application Insights pode ser usado para obter uma visão geral do desempenho do App Service e para obter informações mais profundas sobre o processamento de pedidos do SCEPman. Recomendamos configurar sempre o Application Insights para monitorizar, manter e otimizar o App Service.

Application Insights

8

Configurar a Verificação de Integridade

Esta é recomendada .

As Verificações de Integridade podem ser configuradas para notificar os administradores no caso de o App Service do SCEPman deixar de responder.

Verificação de Saúde

9

Garanta que o SCEPman tem recursos suficientes

Esta é uma etapa obrigatória .

Quando տեղափոխar o SCEPman para um ambiente de produção, deve garantir que o SCEPman está equipado com capacidade de computação 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 fase experimental.

Dimensionamento do App Service

10

Configurar Autoescalamento

Esta é uma 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 de implementar certificados para todos os dispositivos (certificados de utilizador e/ou dispositivo), mas esta é uma tarefa única e, após a implementação inicial, só acontece quando um novo dispositivo é inscrito, ou quando os certificados precisam de ser renovados. Nessas situações, o SCEPman enfrentará um pico de pedidos SCEP.

A segunda tarefa é a validação de certificados: Depois de implementarmos certificados nos dispositivos, esses certificados precisam de ser validados sempre que os utilizamos. Em cada autenticação baseada em certificados, os clientes, gateways ou sistema RADIUS (depende do que usar) enviarão um pedido OCSP para o App Service do SCEPman. Isto causará uma carga permanente de pedidos no App Service.

Para ter um desempenho otimizado e controlar os custos, recomendamos configurar a funcionalidade de Autoescalamento do App Service. Com esta funcionalidade, a sua aplicação pode aumentar e diminuir a escala com base em métricas.

Escalonamento automático

11

Configurar Geo-Redundância

Esta é uma opcional .

Configurar uma instância geo-redundante para o SCEPman pode melhorar a disponibilidade e a resiliência do serviço, distribuindo as cargas de trabalho por várias regiões do Azure.

No entanto, é importante notar que esta configuração pode levar a custos mais elevados no Azure devido aos recursos adicionais e à replicação de dados envolvidos. A Microsoft fornece um SLA de 99,95% para os Azure App Services, o que é adequado na maioria dos cenários.

Redundância Geográfica

12

Configure os seus Perfis de Implementação MDM

Esta é uma etapa recomendada .

Com a conclusão das etapas acima, temos uma implementação funcional do SCEPman e podemos agora emitir certificados para os dispositivos.

Por favor, use um (ou mais) dos seguintes artigos para implementar certificados com a sua solução MDM preferida:

Microsoft IntuneJamf ProOutras Soluções MDM

13

Emitir Certificados Manualmente ou assinar CSRs usando o Certificate Master

Esta é uma opcional .

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.

Master de Certificados

14

Emitir Certificados usando a API REST de Registo

Esta é uma opcional .

O SCEPman disponibiliza uma API REST para registar certificados. Esta é uma alternativa aos endpoints SCEP que requerem 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.

API REST de Registo

15

Criar Bloqueios nos recursos Azure do SCEPman

Esta é uma opcional .

Por predefinição, o SCEPman não aplica quaisquer bloqueios aos recursos do Azure. Se usar 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: A Eliminação Suave e a Proteção contra Purga já oferecem proteção contra eliminação acidental. O SCEPman não modifica o recurso após a criação da chave da CA, pelo que um Bloqueio de Leitura é tecnicamente possível.

• Conta de Armazenamento: Apenas um Bloqueio de Eliminação é possível, pois o SCEPman precisa de escrever informações do certificado na tabela. Se uma Conta de Armazenamento for eliminada acidentalmente, perderá informações sobre certificados já emitidos.

• App Services: Um Bloqueio de Leitura é 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 Bloqueio de Eliminação e Bloqueio de Leitura ajuda a mitigar este risco.

• Workspace do Log Analytics: Um Bloqueio de Eliminação é tecnicamente possível, mas só perderia os 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 Bloqueio de Eliminação e Bloqueio de Leitura pode ser útil para alguns deles. Alguns não podem ser eliminados de todo porque têm dependências num dos serviços principais mencionados acima.