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 utilizador, recomendamos configurar os seguintes valores como parte do certificado:

• Nome de utilizador
• 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 + porta do cliente
• Agente do utilizador (informações do sistema operativo 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 contêm sempre 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 Storage Account do Azure - excluindo as chaves privadas.
   • Para os dados que possam fazer parte de um certificado, consulte a questão 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, são armazenados o estado de revogação do certificado e a identidade do utilizador que o revogou (UPN do Microsoft Entra ID (Azure AD)).
3. Registo

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

   O SCEPman envia sempre uma quantidade limitada de não confidenciais 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 generalizados, permitindo-nos prestar rapidamente uma solução aos nossos clientes, evitando 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 informações 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 apoio a questões de resolução de problemas. Nesses casos, informações sobre o pedido de certificado podem ser enviadas para a nossa conta LAW, possivelmente (o cliente decide que informações fazem parte do certificado) contendo dados pessoais como:

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

   Apagamos periodicamente todos os dados registados com um intervalo de

   • 30 dias

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

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

Log Analytics Workspace externo

A LAW externa que utilizamos para recolher (por predefinição não pessoais e não confidenciais) informações de telemetria para fins de aplicação de licenças está localizada no centro de dados Oeste da Europa do Azure .

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, onde este último 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 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 via Intune ao usar 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 AAD exceder um limite 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 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. Microsoft Graph DeviceManagementManagedDevices.Read.All e DeviceManagementConfiguration.Read.All (como Managed Identity): Com estas permissões, o Certificate Master solicita a lista de certificados emitidos via Intune. Os administradores podem rever e revogar manualmente estes certificados.

5. Quais endpoints acessíveis externamente o SCEPman expõe?

Serviço Principal do SCEPman

1. endpoint(s) SCEP

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

   • Permite ao Certificate Master solicitar certificados do serviço principal do SCEPman.
   • Permite a aplicações personalizadas solicitar certificados do serviço principal do SCEPman.
3. endpoint EST

   • Invocado para pedidos simples de reinscrição EST. Pode ser ativado através da configuração.
   • Invocado para pedidos simples de inscrição EST.
4. endpoint 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 endpoint.
   • 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

   • Apresenta publicamente as informações básicas de estado do SCEPman (sem segredos).
   • Só leitura.
   • Pode ser desativado através de configuração.
8. endpoint de verificação do SCEPman

   • Verificações de estado: Verificação de estado 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. endpoint de verificação do Certificate Master

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

6. Como são protegidos os endpoints da questão 5?

Serviço Principal do SCEPman

1. endpoint(s) SCEP

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

   • autenticação integrada do Microsoft Entra ID (Azure AD).
3. endpoint EST

   • Reinscrição simples: Autenticação baseada em certificado.
   • Inscrição simples: autenticação integrada do Microsoft Entra ID (Azure AD).
4. endpoint 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. endpoint 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ções.
2. endpoint de verificação do Certificate Master

   • Sem proteção.

7. Que portas e protocolos são usados pelos endpoints da Questão 6?

Serviço Principal do SCEPman

1. endpoint(s) SCEP

   • Intune: HTTPS (TCP / 443)
   • Jamf Pro, DCs, MDMs genéricos e outros: HTTPS (TCP / 443)
2. API REST de inscrição

   • HTTPS (TCP / 443)
3. endpoint EST

   • HTTPS (TCP / 443)
4. endpoint OCSP

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

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

   • Não é utilizado por serviços externos.
7. Página inicial do SCEPman

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

   • HTTPS (TCP / 443)

Certificate Master

1. portal web do Certificate Master

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

   • HTTPS (TCP / 443)

Identidade

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

• Sim. Pode ser aproveitado o conjunto completo de políticas RBAC do Microsoft Entra ID (Azure AD).

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

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

Proteção de Dados

1. Como é dados em repouso 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 se optar por não armazenar os dados de configuração no Azure Key Vault, estes 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 segundo 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 desonestos (proteção contra eliminação definitiva e eliminação suave estão ativadas por predefinição).
• O Azure Key Vault usa um endpoint 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 Storage Account do Azure. Assim, a proteção depende dos mecanismos integrados no Azure.
• Em especial, o Azure utiliza acesso baseado em funções para gerir permissões aos dados.
• O Azure Storage usa encriptação da base de dados e suporta chaves geridas pelo cliente.
• O Azure Storage Account usa um endpoint 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 Log Analytics Workspace.
• O Log Analytics usa encriptação da base de dados e suporta chaves geridas pelo cliente.

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

• SCEP:

  • Usa TLS por predefinição (mínimo TLS 1.2 - aplicam-se as políticas 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 de 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 Microsoft).
• Portal web do Certificate Master:

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

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

Segurança por Conceção

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

Componentes do Azure

A filosofia de conceção 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, são utilizadas as seguintes tecnologias para reconhecer e atenuar 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)
• Private Endpoints

Uma vez que o SCEPman é construído com base em componentes Azure, pode utilizar o Microsoft Defender (MD) for Cloud, como MD for App Service, MD for Storage ou MD for Key Vault.

Validade do Certificado

Como uma cloud PKI, 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. Assim, a segurança dos processos de emissão e revogação de certificados é um objetivo de conceção muito importante. Um elevado nível de segurança também requer 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 utilizar 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 medidas contramedidas comuns não específicas do SCEPman contra o ataque. Só tem de eliminar o correspondente objeto Intune ou Jamf Pro.

Dependendo dos seus processos de desativação de dispositivos, também pode configurar para revogar certificados quando é desencadeada uma limpeza, 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
• API Criptográfica Bouncy Castle
• Azure (App Service, Key Vault, Storage Account, Log Analytics)

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

Para as chaves dos certificados emitidos, o Certificate Master não tem restrições quando se utiliza 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 chaves RSA até 4096 bits em todas as plataformas, o que o SCEPman também suporta. Ao utilizar o KSP da plataforma (TPM), o Windows suporta no máximo chaves RSA de 2048 bits. Ao utilizar o endpoint SCEP estático, são suportados todos os algoritmos e tamanhos de chave comuns (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 utilizar 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 pública-privada para a CA raiz no Azure Key Vault no seu tenant. Portanto, a CA raiz é única para a sua instância pessoal do SCEPman e tem controlo total sobre a CA, o seu certificado e a respetiva chave privada.
• 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.
• Por isso, outros clientes do SCEPman não conseguirão ligar-se à sua VPN, independentemente da forma como configurarem o seu SCEPman. Se escolherem o mesmo nome de organização, continuarão a ter o seu próprio par de chaves e, portanto, outro certificado de CA que o gateway VPN não confiará.

Azure CIS

Esta secção abrange 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.

Storage Accounts

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

Sim, que já é de facto a predefinição para novas instalações do SCEPman.

App Services

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

Não, pois isso quebraria a funcionalidade do SCEPman. Isto deve-se ao facto de o SCEPman inscrever certificados de cliente, pelo que os clientes ainda não têm certificados de cliente para autenticar-se com eles (problema da galinha e do ovo). Isso não é um problema de segurança, no entanto, 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 mTLS. O Modo de certificado do cliente tem de ser definido como Ignorar ou Opcional.

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

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

Ao alterar esta definição - por sua conta e risco - tenha em conta 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 NACs de diferentes fornecedores.

4. Pode HTTPS Only ser ativado?

Não (não para o App Service do SCEPman), pois isso quebrará a funcionalidade de respondedor OCSP do SCEPman em combinação com muitos clientes OCSP e appliances de fornecedores. OCSP é um protocolo que é mais frequentemente fornecido por HTTP do que por HTTPS. Uma das razões é que, se usasse TLS para verificação de revogação de certificados (descarregar CRLs ou OCSP), poderia haver um problema da galinha e do ovo, em que o cliente ou appliance não consegue estabelecer a ligação TLS ao endpoint OCSP, porque o certificado do servidor precisa de ser verificado primeiro via OCSP. 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: HTTPS Only não pode ser ativado para o App Service do SCEPman, mas deve ser ativado para o App Service do Certificate Master.

5. O Minimum Inbound TLS Version pode ser definido 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, uma vez estabelecida uma ligação, 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 (EST simple reenroll), pelo que, 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, em 2025-07, não suporta TLS 1.3 (haverá um erro no lado do cliente durante a inscrição SCEP).

Nota: Uma vez que apenas os navegadores acedem ao App Service do Certificate Master, recomenda-se definir o Minimum Inbound TLS Version do Certificate Master para 1.3.

RGPD e residência dos dados

1. Os dados saem da Europa?

• Isto depende da escolha do cliente em relação 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 provedores de cloud de 3.ª parte 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, Irlanda	Ver 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 desenvolvimento do nosso software baseia-se no Ciclo de Vida de Desenvolvimento de Segurança da Microsoft. A aplicação de práticas SDL ajuda-nos a criar código e implementações seguras. Temos a certificação de segurança da informação ISO 27001 para o desenvolvimento do nosso produto.

2. Como implementam práticas comuns de Conceção Segura?

É assim que implementamos Práticas de Conceção Segura recomendadas pelo SDL:

Conceber e Modelar 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 conceção e ameaças STRIDE potenciais numa equipa heterogénea de programadores, o nosso CSOC e consultores PKI, e a equipa de suporte.

Preferir Segurança da Plataforma a Código Personalizado

Sempre que possível, utilizamos funcionalidade do .NET ou bibliotecas estabelecidas, de preferência Open Source, em vez de reinventar a roda. Por exemplo, usamos Legion of the Bouncy Castle C# para trabalhar com padrões de dados criptográficos. Também dependemos de 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 utilizar as predefinições. Por exemplo, os nossos modelos ARM e o nosso provider Terraform definem as definições de configuração para usar chaves RSA de 4096 bits suportadas por HSM, e desativam todos os endpoints de inscrição exceto o SCEP do Intune 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 cerne de cada decisão. Afinal, o objetivo 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 vigilância das operações do SCEPman. Integra-se facilmente com sistemas SIEM como o Sentinel para detetar atacantes bem-sucedidos, por exemplo, se conseguiram inscrever certificados sem autorização. A nossa integração com serviços Azure permite aproveitar os serviços Microsoft Defender for Cloud, por exemplo, Defender for App Service.

Aplicar o Princípio do Menor Privilégio

O modelo RBAC do Certificate Master permite atribuir aos utilizadores apenas as permissões de que necessitam.

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

Minimizar o raio de impacto

Esforçamo-nos por minimizar os possíveis danos em caso de um ataque bem-sucedido. Por exemplo, a nossa instalação predefinida ativa o Key Vault funcionalidade de Eliminação Suave com Proteção contra Eliminação Permanente com uma chave privada não exportável suportada por HSM para a Autoridade de Certificação. A Eliminação Suave com Proteção contra Eliminação Permanente garante que nenhum administrador malicioso ou conta de administrador comprometida possa eliminar a chave privada da CA. A chave privada pode ser restaurada em minutos para continuar com as operações normais, e nem sequer um Administrador Global a pode eliminar permanentemente antes de um período de 90 dias. A chave de CA não exportável suportada por HSM garante que, mesmo um atacante com os privilégios mais elevados possíveis, não consegue roubar a chave da CA.

Minimizar a superfície de ataque

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

Ao utilizar Private Endpoints, garantimos que dois serviços dos quais o SCEPman depende, Azure Key Vault e Azure Storage, não fiquem acessíveis pela Internet.

Considerar casos de abuso

Quando o SCEPman recebe um pedido de assinatura de certificado autorizado (CSR), este 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

Quando o SCEPman deteta eventos de segurança, regista-os com o nível Warning ou Error. As integrações com Azure Monitor e Azure Event Hub permitem-lhe configurar alertas ou analisar eventos com um SIEM.

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

Como parte de uma empresa que também presta serviços de 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, temos certificação ISO 27001 e somos Microsoft Partner of the Year com as nossas ofertas de Segurança.

Os nossos repositórios de código-fonte têm regras de Proteção de Branch e atribuímos apenas os privilégios mínimos necessários aos repositórios e pipelines de implementação de contas de programador individuais. Automatizamos testes e implementações sempre que possível para reduzir a superfície de ataque 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 versão de produção tem de passar primeiro pelos canais interno e beta, cumprindo os requisitos de QA relevantes 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 Práticas de Desenvolvimento Seguro, utilizamos ferramentas (por exemplo, análise estática de código) que analisam a base de código à procura de CVEs e outros exploits comuns (incluindo dependências como bibliotecas de terceiros) que possam afetar a segurança dos pontos finais que o SCEPman expõe. Antes de qualquer lançamento, quaisquer resultados relevantes são avaliados e corrigidos, para garantir que o SCEPman permanece livre de quaisquer 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, uma vez que os serviços típicos de testes de penetração muitas vezes apenas verificam os pontos finais expostos contra CVEs e outros exploits conhecidos, não vemos quaisquer benefícios face às verificações que já realizamos utilizando análise estática de código. Se pretender realizar os seus próprios testes de penetração, por favor entre em contacto connosco e diga-nos quais são os seus requisitos.