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

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

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

• Direitos de owner do Azure (pelo menos ao nível de Resource Group).

• Microsoft Entra ID (Azure AD) "Global administrator" (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 do Domínio Público (scepman.yourdomain.com), apenas se for usada redundância geográfica.

• Certificado SSL (ou use App Service Managed Certificate), apenas se for usada redundância geográfica.

• SCEPman Enterprise Edition License Key.

Opcional

• CNAME do Domínio Público (scepman.yourdomain.com), apenas se for usado um domínio personalizado.

• Certificado SSL (Wildcard-) (ou use App Service Managed Certificate), 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, tem sete recursos adicionais do Azure.

Passos de configuração

1

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 empresarial

ou, alternativamente, o nosso Terraform script:

Implementação com Terraform

2

Realizar 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 geridas

3

Adicionar 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.

RBAC do Certificate Master

4

Criar 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 raiz

5

Configurar 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 personalizado

6

Atualizaçõ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ção

7

Implementar 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 Insights

8

Configurar 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 integridade

9

Certifique-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 Service

10

Configurar 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.

Escalonamento automático

11

Configurar 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-redundância

12

Configure 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 MDM

13

Emitir 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 Master

14

Emitir 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.

API REST de registo

15

Criar 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.