Segurança e privacidade

Este capítulo apresenta uma visão geral das perguntas frequentes sobre segurança da informação, privacidade e garantia de qualidade.

Processamento de Dados e Permissões

1. Quais dados são processados pelo SCEPman?

O SCEPman processa certificados X.509 usando os protocolos SCEP e EST para emissão e os protocolos OCSP e CRL para validar esses certificados. Cada certificado de dispositivo deve conter um identificador único do dispositivo. Além disso, para certificados de usuário, recomendamos configurar os seguintes valores como parte do certificado:

• Nome de usuário
• E-mail
• UPN do Microsoft Entra ID (Azure AD)
• Identificador do dispositivo

SCEP, EST, OCSP e CRL dependem de HTTP(S), ou seja, os seguintes dados ficam visíveis ao SCEPman:

• Endereço IP do cliente + porta
• User agent (informações do sistema operacional e do navegador)

O Certificate Master mantém um registo de auditoria da atividade do administrador (UPNs).

2. Quais dados são armazenados de forma persistente pelo/em nome do SCEPman e como?

1. Configuração

   • Os dados de configuração sempre contêm o par de chaves pública/privada da CA do SCEPman e o certificado, que são armazenados de forma segura no Azure Key Vault.
   • Além disso, os dados de configuração podem conter segredos, como desafios SCEP estáticos ou palavras-passe. A finalidade desses parâmetros é explicada na documentação do SCEPman.
   • Todos os parâmetros de configuração podem ser armazenados no Azure Key Vault para maior segurança.
2. Certificados emitidos

   • Todos os certificados emitidos são armazenados num Azure Storage Account - excluindo chaves privadas.
   • Para os dados que possam fazer parte de um certificado, consulte a pergunta 1.
   • Este comportamento pode ser desativado.
   • Ao emitir certificados através do Certificate Master, o solicitante (UPN do Microsoft Entra ID (Azure AD)) é armazenado.
   • Ao revogar certificados através do Certificate Master, o estado de revogação do certificado e a identidade do utilizador que o revogou (UPN do Microsoft Entra ID (Azure AD)) são armazenados.
3. Registo

   Com base na configuração do cliente do SCEPman, o registo pode ser ativado. Dependendo das definições de verbosidade do registo do cliente, os registos podem conter quaisquer dados que o SCEPman processe. O cliente configura o local de armazenamento dos registos.
4. Log Analytics Workspace externo

   O SCEPman envia sempre uma quantidade limitada de não secretos e não pessoais dados para o nosso Log Analytics Workspace (LAW). Estes dados são usados para

   • fins de licenciamento.
   • Garantia de qualidade (por exemplo, monitorizar exceções globalmente ajuda-nos a reconhecer rapidamente problemas gerais e amplamente გავრცელados, permitindo-nos fornecer soluções aos nossos clientes rapidamente, prevenindo assim interrupções de serviço dispendiosas).

   Por predefinição, o SCEPman não envia quaisquer dados pessoais para o nosso LAW.

   Dependendo das definições de registo, informações de depuração e outras são encaminhadas para o LAW da glueckkanja-gab AG. Os nossos engenheiros de suporte podem solicitar a ativação da funcionalidade de depuração remota ao administrador do cliente para ajudar em pedidos de resolução de problemas. Nesses casos, informações sobre o pedido de certificado podem ser enviadas para a nossa conta LAW, podendo conter (o cliente decide que informações fazem parte do certificado) dados pessoais como:

   • Nome de usuário
   • E-mail
   • UPN do Microsoft Entra ID (Azure AD)
   • Identificador do dispositivo

   Eliminamos periodicamente todos dados registados com um intervalo de

   • 30 dias

3. Onde (geograficamente) o SCEPman processa e armazena dados?

Por conceção, o SCEPman é implementado como uma aplicação Azure (baseada num modelo de solução), ou seja, é implantado no tenant Azure do cliente. Como tal, a soberania dos dados, incluindo a escolha da geo-localização do centro de dados de alojamento, está nas mãos e na preferência do cliente.

Log Analytics Workspace externo

O LAW externo que utilizamos para recolher (por predefinição não pessoais e não secretos) informações de telemetria para fins de aplicação de licenciamento está localizado no centro de dados Azure do Oeste da Europa .

4. Quais permissões do tenant o administrador tem de consentir?

O SCEPman utiliza Managed Identities para implementar um modelo de permissões seguro no seu tenant Azure.

Intune

1. Intune scep_challenge_provider: Com esta permissão, o SCEPman pode encaminhar o pedido de certificado para o Intune e verificar se o pedido de certificado se origina no Intune, o que acrescenta uma camada adicional de segurança.
2. Microsoft Graph Directory.Read.All: Com esta permissão, o SCEPman pode consultar o Microsoft Entra ID (Azure AD) para verificar se o certificado de utilizador ou de dispositivo provém de um utilizador ou dispositivo autorizado.
3. Microsoft Graph DeviceManagementManagedDevices.Read.All e DeviceManagementConfiguration.Read.All: Com estas permissões, o SCEPman solicita a lista de certificados emitidos através do Intune ao utilizar a funcionalidade de revogação EndpointList.
4. Microsoft Graph IdentityRiskyUser.Read.All: Esta permissão permite ao SCEPman revogar automaticamente certificados de utilizador se o risco do utilizador no AAD exceder um limiar configurado.

Jamf Pro

1. Permissões de leitura sobre utilizadores, computadores e dispositivos Com estas permissões, o SCEPman pode consultar o Jamf Pro para verificar se o certificado de utilizador ou de dispositivo provém de um utilizador ou dispositivo autorizado.

Certificate Master

1. Microsoft Graph User.Read (via App Registration): Com esta permissão, o Certificate Master determina quem solicita ou revoga manualmente um certificado.
2. Micrsoft Graph DeviceManagementManagedDevices.Read.All e DeviceManagementConfiguration.Read.All (como Managed Identity): Com estas permissões, o Certificate Master solicita a lista de certificados emitidos através do Intune. Os administradores podem rever e revogar manualmente estes certificados.

5. Que pontos de extremidade acessíveis externamente o SCEPman expõe?

Serviço Principal do SCEPman

1. ponto(s) de extremidade SCEP

   • Invocado para pedidos SCEP.
   • Com base na configuração, o SCEPman pode expor vários pontos de extremidade SCEP para Intune, Jamf Pro, DCs, MDMs genéricos e outros.
2. Enrollment REST API

   • Permite ao Certificate Master solicitar certificados ao serviço principal do SCEPman.
   • Permite que aplicações personalizadas solicitem certificados ao serviço principal do SCEPman.
3. ponto de extremidade EST

   • Invocado para pedidos de reenrolamento simples EST. Pode ser ativado através da configuração.
   • Invocado para pedidos de inscrição simples EST.
4. ponto de extremidade OCSP

   • Invocado para pedidos OCSP.
5. Ponto de Distribuição de Certificados (CDP)

   • A Lista de Revogação de Certificados (CRL) é disponibilizada através deste ponto de extremidade.
   • Pode ser ativado através da configuração.
6. API de Validação

   • Permite ao Certificate Master avaliar o estado de revogação automática de um certificado.
7. página inicial do SCEPman

   • Mostra publicamente as informações básicas de estado do SCEPman (sem segredos).
   • Apenas leitura.
   • Pode ser desativado através da configuração.
8. ponto de extremidade de verificação do SCEPman

   • Verificações de saúde: Verificação de saúde integrada do App Service, sondagem do Traffic Manager, sondagem do Application Gateway.

Certificate Master

1. portal web do Certificate Master

   • Emitir manualmente certificados de servidor e assinar CSRs.
   • Revogar manualmente certificados emitidos através do Certificate Master.
   • Ver a lista de certificados emitidos manualmente.
2. ponto de extremidade de verificação do Certificate Master

   • Verificações de saúde: Verificação de saúde integrada do App Service

6. Como são protegidos os pontos de extremidade de 5.?

Serviço Principal do SCEPman

1. ponto(s) de extremidade SCEP

   • Intune: Protegido através da Intune Challenge API (Microsoft Docs)
   • Jamf Pro, DCs, MDMs genéricos e outros: Protegido com um desafio SCEP estático. Configurável pelo cliente. Pode ser armazenado no Azure Key Vault.
2. Enrollment REST API

   • Autenticação integrada do Microsoft Entra ID (Azure AD).
3. ponto de extremidade EST

   • Reenrolamento simples: Autenticação baseada em certificado.
   • Inscrição simples: Autenticação integrada do Microsoft Entra ID (Azure AD).
4. ponto de extremidade OCSP

   • Não é necessária proteção.
5. Ponto de Distribuição de Certificados (CDP)

   • É necessário token de acesso.
6. API de Validação

   • Autenticação integrada do Microsoft Entra ID (Azure AD).
7. página inicial do SCEPman

   • Sem proteção, mas pode ser desativado.
8. ponto de extremidade de verificação do SCEPman

   • Sem proteção.

Certificate Master

1. portal web do Certificate Master

   • Autenticação integrada do Microsoft Entra ID (Azure AD).
   • Microsoft Entra ID (Azure AD) Atribuições de função.
2. ponto de extremidade de verificação do Certificate Master

   • Sem proteção.

7. Que portas e protocolos são usados pelos pontos de extremidade da pergunta 6?

Serviço Principal do SCEPman

1. ponto(s) de extremidade SCEP

   • Intune: HTTPS (TCP / 443)
   • Jamf Pro, DCs, MDMs genéricos e outros: HTTPS (TCP / 443)
2. Enrollment REST API

   • HTTPS (TCP / 443)
3. ponto de extremidade EST

   • HTTPS (TCP / 443)
4. ponto de extremidade OCSP

   • HTTP (TCP / 80)
5. Ponto de Distribuição de Certificados (CDP)

   • HTTP (TCP / 80)
6. API de Validação

   • Não usado por serviços externos.
7. página inicial do SCEPman

   • HTTPS (TCP / 443)
8. ponto de extremidade de verificação do SCEPman

   • HTTPS (TCP / 443)

Certificate Master

1. portal web do Certificate Master

   • HTTPS (TCP / 443)
2. ponto de extremidade de verificação do Certificate Master

   • HTTPS (TCP / 443)

Identidade

1. Existem controlos de acesso condicional / baseados em funções para proteger o SCEPman?

• Sim. O conjunto completo de políticas RBAC do Microsoft Entra ID (Azure AD) pode ser utilizado.

2. As credenciais de acesso podem ser recuperadas? Se sim, como?

• Credenciais de início de sessão: depende das políticas configuradas do Microsoft Entra ID (Azure AD) no tenant do cliente.
• Desafio SCEP estático: utilizadores autorizados podem aceder ao desafio.

Proteção de Dados

1. Como os dados em repouso estão protegidos contra acesso não autorizado?

Dados de Configuração

• Os dados de configuração podem ser armazenados de forma segura no Azure Key Vault (versão >= 1.7).
• Se for escolhido não armazenar os dados de configuração no Azure Key Vault, eles são armazenados no AppService (encriptação BitLocker)
• Quaisquer dados de configuração (Azure Key Vault, App Services) só podem ser acedidos por utilizadores autorizados com as permissões Azure relevantes.

Chaves Criptográficas

• A chave privada da CA é armazenada de forma segura no Azure Key Vault (HSM validado FIPS 140 por predefinição).
• A chave privada não pode ser lida nem exportada.
• A chave privada está protegida contra eliminação por administradores mal-intencionados (proteção contra purga e eliminação suave estão ativadas por predefinição).
• O Azure Key Vault usa um ponto de extremidade privado e só pode ser acedido a partir do SCEPman (predefinição para instalações do SCEPman da versão 2.8 e superior).

Base de Dados de Certificados

• A base de dados usa o serviço Table de um Azure Storage Account. Assim, a proteção depende dos mecanismos incorporados no Azure.
• Em especial, o Azure utiliza acesso baseado em funções para gerir permissões aos dados.
• O Azure Storage usa encriptação de base de dados e suporta chaves geridas pelo cliente.
• O Azure Storage Account usa um ponto de extremidade privado e só pode ser acedido a partir do SCEPman (predefinição para instalações do SCEPman da versão 2.8 e superior).

Registos

• Os registos são armazenados num workspace do Log Analytics.
• O Log Analytics usa encriptação de base de dados e suporta chaves geridas pelo cliente.

2. Como os dados em trânsito estão protegidos contra acesso não autorizado?

• SCEP:

  • Usa TLS por predefinição (mínimo TLS 1.2 - aplicam-se as políticas da Microsoft).
  • Os pedidos SCEP são encriptados para o certificado da CA e assinados com o certificado do cliente.
  • As respostas SCEP são encriptadas para o certificado do cliente e assinadas com o certificado da CA.
• OCSP:

  • Os pedidos OCSP não devem ser encriptados para evitar problemas do tipo galinha-e-ovo.
  • As respostas OCSP são assinadas pelo certificado da CA.
• API REST de inscrição e EST:

  • Impõe TLS (mínimo TLS 1.2 - aplicam-se as políticas da Microsoft).
• Portal web do Certificate Master:

  • Impõe TLS (mínimo TLS 1.2 - aplicam-se as políticas da Microsoft).
• Comunicação entre componentes Azure do SCEPman:

  • TLS (mínimo TLS 1.2 - aplicam-se as políticas da Microsoft).

Segurança por Conceção

1. O SCEPman utiliza uma estratégia de defesa em profundidade?

Componentes Azure

A filosofia de design do SCEPman segue a abordagem de minimizar a sua exposição a ameaças de segurança externas, reduzindo as interfaces externas ao mínimo necessário. Além disso, as seguintes tecnologias são usadas para reconhecer e mitigar ameaças internas e externas em diferentes camadas:

• Key Vault
• App Insights
• Verificação de inscrição de dispositivos Intune
• Verificação de dispositivo do Microsoft Entra ID (Azure AD)
• Pontos de Extremidade Privados

Como o SCEPman é construído sobre componentes Azure, pode usar ferramentas Microsoft Defender (MD) for Cloud como MD for App Service, MD for Storage ou MD for Key Vault.

Validade do Certificado

Como uma PKI na cloud, o SCEPman é responsável pela emissão e revogação de certificados digitais. Estes certificados, em conjunto com as suas chaves privadas, autenticam dispositivos ou utilizadores e concedem acesso a outros recursos. Por isso, a segurança dos processos de emissão e revogação de certificados é um objetivo de design muito importante. Um elevado nível de segurança também exige um elevado nível de conveniência para o utilizador, porque processos complicados e pouco transparentes têm uma superfície de ataque maior e maior potencial para erro humano. Embora o SCEPman ofereça muitas opções de configuração, se necessário, esforçámo-nos por usar predefinições razoáveis e seguras sempre que possível.

Assim, se uma chave privada for comprometida, o SCEPman pode revogar o certificado correspondente em tempo real. Para certificados inscritos via Intune e Jamf Pro, o SCEPman faz isso automaticamente assim que são tomadas contra o ataque as contramedidas comuns não específicas do SCEPman. Só tem de eliminar o objeto Intune correspondente ou o objeto Jamf Pro.

Dependendo dos seus processos de reforma de dispositivos, pode também configurar para revogar certificados quando é acionado um wipe, quando o Intune solicita a revogação, dependendo da conformidade do dispositivo ou nível de risco do utilizador, ou pode revogar manualmente certificados individuais através do componente Certificate Master.

Certificados criados manualmente exigem sempre uma revogação manual.

2. Que tecnologias, stacks, plataformas foram usadas para conceber o SCEPman?

• C#
• ASP.NET Core MVC
• Bouncy Castle Crypto API
• Azure (App Service, Key Vault, Storage Account, Log Analytics)

3. Que algoritmos criptográficos e tamanhos de chave o SCEPman suporta?

Para as chaves dos certificados emitidos, o Certificate Master não tem restrições ao usar o método CSR. Para certificados baseados em formulários, RSA com 2048 ou 4096 bits são os algoritmos e tamanhos de chave suportados.

Para certificados inscritos via SCEP, o Intune suporta até chaves RSA de 4096 bits em todas as plataformas, o que o SCEPman também suporta. Ao usar o KSP da plataforma (TPM), o Windows suporta no máximo chaves RSA de 2048 bits. Ao usar o ponto de extremidade SCEP estático, todos os algoritmos comuns e tamanhos de chave são suportados (especificamente aqueles que a biblioteca criptográfica Bouncy Castle para C# suporta).

Para a chave da CA, o SCEPman suporta apenas RSA. RSA de 4096 bits é o tamanho de chave predefinido. 4096 bits é atualmente o máximo suportado pelo Azure Key Vault. Se usar um certificado de CA Intermédia, também pode usar qualquer tamanho de chave suportado pelo Key Vault, mas tem de ser uma chave RSA.

Para cenários que não requerem SCEP, pode ser criada uma CA ECC, suportando as seguintes curvas elípticas: P-256, secp256k1/P-256K, P-384, P-521.

4. A CA criada pelo SCEPman é única?

Sim

Detalhes:

• O SCEPman gera o par de chaves privada-pública para a CA Raiz no Azure Key Vault no seu tenant. Portanto, a CA Raiz é exclusiva da sua instância pessoal do SCEPman e tem controlo total sobre a CA, o seu certificado e a chave privada correspondente.
• O acesso a esta CA é controlado através de políticas de acesso do Key Vault que pode alterar se quiser. Por predefinição, apenas a sua própria instância do SCEPman e mais ninguém (nem mesmo um administrador) pode usar o certificado, mas um administrador da subscrição pode conceder permissões adicionais.
• Assim, outros clientes do SCEPman não conseguirão ligar-se à sua VPN, independentemente de como configurarem o seu SCEPman. Se escolherem o mesmo nome de organização, ainda assim terão o seu próprio par de chaves e, portanto, outro certificado de CA em que o seu VPN Gateway não confiará.

Azure CIS

Esta secção aborda questões que surgem ao definir políticas de ciberdefesa para o seu ambiente Azure ou ao trabalhar com frameworks de melhores práticas como o CIS Microsoft Azure Foundations Benchmark.

Contas de Armazenamento

1. Pode Permitir acesso público a Blob ser desativado?

Sim, na verdade, isso já é o padrão para novas instalações do SCEPman.

App Services

2. TLS: Pode Modo de certificado do cliente ser definido para Exigir?

Não, pois isso quebraria a funcionalidade do SCEPman. Isto acontece porque o SCEPman inscreve certificados de cliente, pelo que os clientes ainda não têm certificados de cliente para se autenticarem (problema da galinha e do ovo). No entanto, isso não é um problema de segurança, porque o protocolo SCEP usa os seus próprios mecanismos de autenticação através do desafio SCEP. Assim, o SCEPman precisa de uma exceção às políticas que impõem TLS mútuo. O Modo de certificado do cliente deve ser definido para Ignorar ou Opcional.

3. Pode a versão HTTP ser definido para 2.0?

Embora o SCEPman deva funcionar com qualquer uma das versões HTTP disponíveis, até ao momento só suportamos a predefinida HTTP 1.1 - principalmente devido à falta de testes.

Ao alterar esta definição - por sua conta e risco - tenha em consideração que não é apenas o SCEPman que precisa de suportar a versão HTTP mais recente. Os diferentes tipos de clientes também precisam de suportar essa versão de HTTP, ou seja, os clientes SCEP integrados no sistema operativo de Windows, macOS, iOS, iPadOS, os de dispositivos IoT, os clientes OCSP nas mesmas plataformas, mas também os NACs de diferentes fornecedores.

4. Pode Apenas HTTPS ser ativado?

Não (não para o App Service do SCEPman), pois isso quebraria a funcionalidade do responder OCSP do SCEPman em combinação com muitos clientes OCSP e appliances de fornecedores. OCSP é um protocolo que é mais comum ser fornecido por HTTP do que por HTTPS. Uma das razões é que, se usasse TLS para verificação de revogação de certificados (download de CRLs ou OCSP), poderia ocorrer um problema da galinha e do ovo, em que o cliente ou appliance não consegue estabelecer a ligação TLS ao ponto de extremidade OCSP porque o certificado do servidor precisa de ser verificado primeiro via OCSP. Isso também não acrescenta muita segurança, porque as respostas OCSP são criptograficamente assinadas de qualquer forma e, portanto, não podem ser falsificadas. Assim, o SCEPman precisa de uma exceção às políticas que impõem TLS.

Nota: Apenas HTTPS não pode ser ativado para o App Service do SCEPman, mas deve ser ativado para o App Service do Certificate Master.

5. A Versão Mínima de TLS de Entrada pode ser definida para 1.3?

Não para o App Service do SCEPman, uma vez que o TLS 1.3 não suporta renegociação. Isto significa que, depois de uma ligação ser estabelecida, o servidor não pode pedir ao cliente que apresente um certificado de cliente. Queremos que o cliente se autentique com um certificado em algumas circunstâncias (reenrolamento simples EST), por isso, se definir o TLS para 1.3, não conseguirá renovar os seus certificados usando EST.

Além disso, nem todos os clientes SCEP suportam TLS 1.3. Um exemplo importante é o cliente SCEP integrado no Windows 8, 10 e 11, que, até 2025-07, não suporta TLS 1.3 (haverá um erro no lado do cliente durante a inscrição SCEP).

Nota: Como apenas os navegadores acedem ao App Service do Certificate Master, recomenda-se que, para o Certificate Master, seja definida a Versão Mínima de TLS de Entrada para 1.3.

RGPD e residência dos dados

1. Os dados saem da Europa?

• Isto depende da escolha do cliente relativamente ao centro de dados Azure no qual o SCEPman e os seus componentes devem ser implementados.
• É possível uma implementação completa do SCEPman, incluindo todos os seus componentes, em centros de dados Azure europeus.

2. Em que fornecedores de cloud de terceiros o SCEPman se baseia e porquê?

Empresa	Serviços	Contacto	Finalidade
Microsoft Corporation	Serviços de Cloud (Azure)	Building 3, Carmanhall Road Sandyford, Industrial Estate 18, Dublin, Ireland	Veja aqui.
GitHub Inc (subsidiária da Microsoft Corporation)	repositório de código git, integração, testes e automatização de lançamentos, armazenamento	88 Colin P Kelly Jr St, San Francisco, CA 94107, Estados Unidos	Repositório de código, pipeline CI/CD, armazenamento binário

Práticas de Desenvolvimento Seguro

1. O que garante que o SCEPman é software seguro?

O nosso desenvolvimento de software baseia-se no Microsoft Security Development Lifecycle. A aplicação de práticas SDL ajuda-nos a criar código e implementações seguros. Temos a certificação de segurança da informação ISO 27001 para o desenvolvimento do nosso produto.

2. Como implementa práticas comuns de Design Seguro?

É assim que implementamos as Secure Design Practices recomendadas pelo SDL:

Design e Modelo de Ameaças em Equipa

A nossa prática de modelação de ameaças baseia-se nas recomendações do Tufts Security and Privacy Lab. Discutimos decisões de design e potenciais ameaças STRIDE numa equipa heterogénea de developers, os nossos CSOC e consultores PKI, e equipa de suporte.

Preferir Segurança da Plataforma a Código Personalizado

Sempre que possível, usamos funcionalidades do .NET ou bibliotecas estabelecidas, de preferência Open Source, em vez de reinventar a roda. Por exemplo, usamos a Legion of the Bouncy Castle C# para trabalhar com padrões de dados criptográficos. Também confiamos em serviços Azure como o Key Vault para gerar chaves criptográficas, App Services para alojamento de servidores web, Azure Monitor para registo e Azure Storage como motor de base de dados.

A Configuração Segura é a Predefinição

Para minimizar o potencial de erro humano, concebemos os produtos de forma a que tenha uma configuração segura se usar as predefinições. Por exemplo, os nossos modelos ARM e o nosso fornecedor Terraform definem as definições de configuração para usar chaves RSA de 4096 bits suportadas por HSM, e desativam todos os pontos de extremidade de inscrição, exceto o Intune SCEP e o Certificate Master (para os quais tem de atribuir permissões explicitamente).

Nunca Confiar em Dados do Cliente

Como software PKI, decidir em que dados confiar está no centro de cada decisão. Afinal, o propósito dos certificados e dos seus protocolos de inscrição é decidir em que dados confiar.

Assumir Violação

O nosso registo baseado no Azure Monitor permite a supervisão das operações do SCEPman. Integra-se facilmente com sistemas SIEM como o Sentinel para detetar atacantes bem-sucedidos, por exemplo, se conseguirem inscrever certificados sem autorização. A nossa integração com os Serviços Azure permite aproveitar os serviços Microsoft Defender for Cloud, por exemplo, o Defender for App Service.

Aplicar o Privilégio Mínimo

O nosso modelo RBAC para o Certificate Master permite atribuir aos utilizadores apenas as permissões de que realmente necessitam.

O SCEPman usa Managed Identities que têm apenas as permissões necessárias para a operação.

Minimizar o Raio de Explosão

Esforçamo-nos por minimizar os danos possíveis em caso de ataque bem-sucedido. Por exemplo, a nossa instalação predefinida ativa a funcionalidade Key Vault Soft Delete com Purge Protection com uma chave privada não exportável suportada por HSM para a Autoridade de Certificação. O Soft Delete com Purge Protection garante que nenhum administrador mal-intencionado ou conta de administrador comprometida possa eliminar a chave privada da CA -- ela pode ser restaurada em minutos para retomar as operações normais e nem mesmo um Global Admin a pode purgar antes de um período de 90 dias. A chave CA suportada por HSM e não exportável garante que mesmo um atacante com os maiores privilégios possíveis não possa roubar a chave da CA.

Minimizar a Superfície de Ataque

Certificamo-nos de expor apenas as interfaces necessárias para as operações do cliente. Se um ponto de extremidade SCEP não estiver configurado, os pedidos SCEP nem sequer são processados.

Ao usar Pontos de Extremidade Privados, certificamo-nos de que dois serviços dos quais o SCEPman depende, Azure Key Vault e Azure Storage, não estão acessíveis através da internet.

Considerar Casos de Abuso

Quando o SCEPman recebe pedidos autorizados de assinatura de certificados (CSRs), continua sujeito a várias restrições configuráveis. Por exemplo, a validade nunca pode exceder o período máximo de validade configurado, mesmo que isso tenha sido solicitado.

Monitorizar e Alertar sobre Eventos de Segurança

Se o SCEPman detetar Eventos de Segurança, estes serão registados como Warning ou Error nos registos. A integração com o Azure Monitor e o Azure Event Hub facilita a configuração de alertas ou a análise destes Eventos de Segurança com um SIEM.

3. Como protege o seu próprio ambiente de desenvolvimento?

Como parte de uma empresa que também fornece serviços CSOC e consultoria de segurança, temos elevados padrões de segurança para os nossos dispositivos, processos e sensibilização dos utilizadores. Fazemos parte do Microsoft MISA, somos certificados ISO 27001 e Microsoft Partner of the Year com as nossas ofertas de Segurança.

Os nossos repositórios de origem têm regras de Branch Protection e atribuímos apenas os princípios menos necessários aos repositórios e pipelines de implementação em contas de programador individuais. Automatizamos testes e implementações sempre que possível para reduzir a superfície de ataque através de contas comprometidas.

4. O SCEPman faz parte de um programa de bug bounty?

Não.

5. Que medidas de QA estão em vigor?

• Disponibilizamos o SCEPman num canal interno, beta e de produção
• Cada lançamento de produção tem de passar primeiro pelos canais interno e beta, ultrapassando os respetivos obstáculos de QA como parte do nosso processo de CI

  • Testes unitários
  • Revisão por pares
  • Testes de integração
  • Testes de stress
  • Testes baseados na experiência
  • Análise de código de terceiros, por exemplo Sonar, Dependabot e outros

6. Realizam regularmente testes de penetração?

Não.

Como parte das nossas Secure Development Practices, utilizamos ferramentas (por exemplo, análise estática de código) que examinam a base de código em busca de CVEs e outros exploits comuns (incluindo dependências como bibliotecas de terceiros) que possam afetar a segurança dos pontos de extremidade que o SCEPman expõe. Antes de qualquer lançamento, quaisquer conclusões relevantes são avaliadas e corrigidas, para garantir que o SCEPman se mantém livre de vulnerabilidades conhecidas. Não realizamos testes de penetração nós próprios, nem utilizamos ferramentas de terceiros de "Penetration Test-as-a-Service". No primeiro caso, vemos um conflito de interesses inerente. No segundo, como os serviços típicos de testes de penetração muitas vezes apenas verificam os pontos de extremidade expostos contra CVEs e outros exploits conhecidos, não vemos valor acrescentado aos controlos que já realizamos usando análise estática de código. Se desejar realizar os seus próprios testes de penetração, por favor contacte-nos e diga-nos quais são os seus requisitos.