Segurança & Privacidade

Este capítulo fornece uma visão geral sobre perguntas frequentes relacionadas à 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 validação desses certificados. Cada certificado do dispositivo deve conter um identificador único do dispositivo. Adicionalmente, para certificados de usuário, recomendamos configurar os seguintes valores como parte do certificado:

• Nome de utilizador

• Email

• Microsoft Entra ID (Azure AD) UPN

• Identificador do dispositivo

SCEP, EST, OCSP e CRL dependem de HTTP(S), ou seja, os seguintes dados são visíveis para o SCEPman:

• Endereço IP do cliente + Porta

• User agent (informações do sistema operativo e navegador)

O Certificate Master mantém um registo de auditoria sobre a actividade dos administradores (UPNs).

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

1. Configuração

   • Os dados de configuração contêm sempre o par de chaves pública/privada e o certificado da CA do SCEPman, que são armazenados de forma segura no Azure Key Vault.

   • Adicionalmente, os dados de configuração podem conter segredos como desafios SCEP estáticos ou palavras-passe. O propósito desses parâmetros é explicado 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 numa Conta de Armazenamento do Azure - excluindo chaves privadas.

   • Para os dados que podem fazer parte de um certificado, por favor consulte pergunta 1.

   • Este comportamento pode ser desativado.

   • Ao emitir certificados via Certificate Master, o requerente (Microsoft Entra ID (Azure AD) UPN) é armazenado.

   • Ao revogar certificados via Certificate Master, o estado de revogação do certificado e a identidade do utilizador que o revogou (Microsoft Entra ID (Azure AD) UPN) são armazenados.

3. Registos

   Dependendo da configuração do cliente do SCEPman, o registo (logging) pode ser ativado. Dependendo das definições de verbosidade de registo do cliente, os registos podem conter quaisquer dados que o SCEPman processe. O cliente configura o local de armazenamento dos registos.

4. Workspace externo do Log Analytics

   O SCEPman envia sempre uma quantidade limitada de não secreta e não pessoal 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 problemas gerais e disseminados rapidamente, permitindo-nos fornecer solução aos nossos clientes de forma rápida, evitando assim interrupções de serviço dispendiosas).

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

   Dependendo das definições de registo, informação de debug e outras informações são encaminhadas para o LAW da glueckkanja-gab AG. Os nossos engenheiros de suporte poderão solicitar activar a funcionalidade de depuração remota ao administrador do cliente em apoio a pedidos de resolução de problemas. Em tais casos, informação sobre o pedido de certificado pode ser enviada para a nossa conta LAW, possivelmente (o cliente decide que informação faz parte do certificado) contendo dados pessoais tais como:

   • Nome de utilizador

   • Email

   • Microsoft Entra ID (Azure AD) UPN

   • Identificador do dispositivo

   Eliminamos periodicamente todos os dados registados num intervalo de

   • 30 dias

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

Por design, o SCEPman é implementado como uma App Azure (baseada em modelo de solução), ou seja, é implantado no tenant Azure do cliente. Como tal, a soberania dos dados, incluindo a escolha da localização geográfica do centro de dados de hospedagem, está nas mãos e na preferência do cliente.

Workspace externo do Log Analytics

O LAW externo que usamos para recolher (por predefinição não pessoal e não secreta) informação de telemetria para fins de aplicação de licenças está localizado em o centro de dados West Europe da Azure .

4. Quais permissões de 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 que o pedido de certificado se originou no Intune, onde este último adiciona 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 se origina 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 o recurso de revogação EndpointList.

4. Microsoft Graph IdentityRiskyUser.Read.All: Esta permissão permite ao SCEPman automaticamente revogar certificados de utilizador se o Risco de Utilizador do 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 dispositivo se origina 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 via Intune. Os administradores podem rever e revogar manualmente estes certificados.

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

Serviço Core 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, outros MDMs genéricos.

2. REST API de Inscrição

   • Permite ao Certificate Master solicitar certificados ao serviço core do SCEPman.

   • Permite a aplicações personalizadas solicitar certificados ao serviço core do SCEPman.

3. Endpoint EST

   • Invocado para pedidos EST de re-registo simples. Pode ser ativado via configuração.

   • Invocado para pedidos EST de inscrição simples.

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 via 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

   • Exibe publicamente as informações básicas de estado do SCEPman (sem segredos).

   • Apenas leitura.

   • Pode ser desativada via configuração.

8. Endpoint de sonda do SCEPman

   • Verificações de integridade: Health Check integrado 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 via Certificate Master.

   • Ver lista de certificados emitidos manualmente.

2. Endpoint de sonda do Certificate Master

   • Verificações de integridade: Health Check integrado do App Service

6. Como são protegidos os endpoints do ponto 5.?

Serviço Core do SCEPman

1. Endpoint(s) SCEP

   • Intune: Protegido via Intune Challenge API (Microsoft Docs)

   • Jamf Pro, DCs, outros MDMs genéricos: Protegidos com um desafio SCEP estático. Configurável pelo cliente. Podem ser armazenados no Azure Key Vault.

2. REST API de Inscrição

   • Autenticação integrada do Microsoft Entra ID (Azure AD).

3. Endpoint EST

   • Re-registo simples: Autenticação baseada em certificado.

   • Inscrição simples: Autenticação integrada do Microsoft Entra ID (Azure AD).

4. Endpoint OCSP

   • Sem proteção necessária.

5. Ponto de Distribuição de Certificados (CDP)

   • Token de acesso exigido.

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 sonda 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. Endpoint de sonda do Certificate Master

   • Sem proteção.

7. Que portas e protocolos são utilizados pelos endpoints da Pergunta 6?

Serviço Core do SCEPman

1. Endpoint(s) SCEP

   • Intune: HTTPS (TCP / 443)

   • Jamf Pro, DCs, outros MDMs genéricos: HTTPS (TCP / 443)

2. REST API 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 sonda do SCEPman

   • HTTPS (TCP / 443)

Certificate Master

1. Portal web do Certificate Master

   • HTTPS (TCP / 443)

2. Endpoint de sonda 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 aproveitado.

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

• Credenciais de Login: 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 é que os dados em repouso sã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 os dados de configuração não forem armazenados no Azure Key Vault, 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 defeito).

• A chave privada não pode ser lida nem exportada.

• A chave privada é protegida contra eliminação por administradores maliciosos (a protecção contra purge e a eliminação suave são ativadas por defeito).

• O Azure Key Vault usa um endpoint privado e só pode ser acedido a partir do SCEPman (predefinição para instalações do SCEPman versão 2.8 e acima).

Base de Dados de Certificados

• A base de dados usa o serviço Table de uma Conta de Armazenamento do Azure. Assim, a protecção depende dos mecanismos incorporados no Azure.

• Em especial, o Azure emprega controlo de acesso baseado em funções para gerir permissões aos dados.

• O Azure Storage utiliza encriptação de base de dados e suporta chaves geridas pelo cliente.

• A Conta de Armazenamento do Azure usa um endpoint privado e só pode ser acedida a partir do SCEPman (predefinição para instalações do SCEPman versão 2.8 e acima).

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 é que os dados em trânsito são protegidos contra acesso não autorizado?

• SCEP:

  • Usa TLS por defeito (TLS mínimo 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 de galinha-e-ovo.

  • As respostas OCSP são assinadas pelo certificado da CA.

• REST API de Inscrição e EST:

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

• Portal web do Certificate Master:

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

• Comunicação entre os componentes Azure do SCEPman:

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

Segurança por Desenho

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

Componentes Azure

A filosofia de concepção do SCEPman segue a abordagem de minimizar a sua exposição a ameaças externas de segurança reduzindo as interfaces externas ao mínimo necessário. Para 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)

• Endpoints Privados

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

Validade do Certificado

Como uma PKI na cloud, o SCEPman é responsável pela emissão e revogação de certificados digitais. Esses certificados em conjunto com as respetivas chaves privadas autenticam dispositivos ou utilizadores e concedem acesso a outros recursos. Por conseguinte, 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 requer também 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 de erro humano. Embora o SCEPman ofereça muitas opções de configuração, quando 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 isto automaticamente assim que medidas de contra-ataque comuns não específicas ao SCEPman são tomadas contra o ataque. Você só tem de eliminar o correspondente objeto Intune ou objeto Jamf Pro.

Dependendo dos seus processos de aposentação de dispositivos, pode adicionalmente configurar para revogar certificados quando for acionada uma limpeza (wipe), quando o Intune solicita a revogação, dependendo de 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 requerem 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, Conta de Armazenamento, Log Analytics)

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

Para as chaves de 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 até chaves RSA de 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 usar o endpoint SCEP estático, todos os algoritmos e tamanhos de chave comuns 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 utilizar um certificado CA intermédio, 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 Root CA no Azure Key Vault no seu tenant. Portanto, a Root CA é única para a sua instância pessoal do SCEPman e você tem controlo total sobre a CA, o seu certificado e a correspondente chave privada.

• O acesso a esta CA é controlado através de políticas de acesso do Key Vault que pode alterar se desejar. Por defeito, apenas a sua própria instância do SCEPman e mais ninguém (nem sequer um administrador) pode usar o certificado, mas um administrador de subscrição pode conceder permissões adicionais.

• Assim, outros clientes SCEPman não poderão ligar-se à sua VPN, não importa como configurem o seu SCEPman. Se escolherem o mesmo nome de organização, ainda terão o seu próprio par de chaves e, portanto, outro certificado CA que o seu Gateway VPN não confiará.

Azure CIS

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

Contas de Armazenamento

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

Sim, que na verdade 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 isto quebraria a funcionalidade do SCEPman. Isto porque o SCEPman inscreve certificados de cliente, portanto os clientes ainda não têm certificados de cliente para autenticar (problema de galinha-e-ovo). Isso não é um problema de segurança, no entanto, pois o protocolo SCEP usa os seus próprios mecanismos de autenticação através do desafio SCEP. Assim, o SCEPman necessita de uma isenção das políticas que aplicam mutual TLS. 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é à data, suportamos apenas a predefinição HTTP 1.1 - principalmente devido à falta de testes.

Ao alterar esta configuração - por sua conta e risco - por favor considere que não é apenas o SCEPman que precisa suportar a nova versão HTTP. Os diferentes tipos de clientes também precisam suportar essa versão de HTTP, ou seja, os clientes SCEP integrados nos SOs Windows, macOS, iOS, iPadOS, os dos dispositivos IoT, os clientes OCSP nas mesmas plataformas, mas também NACs de diferentes fornecedores.

4. Pode Apenas HTTPS ser ativado?

Não (não para o App Service do SCEPman), pois isto quebraria a funcionalidade do respondedores OCSP do SCEPman em combinação com muitos clientes OCSP e appliances de fornecedores. OCSP é um protocolo que é mais comumente fornecido sobre HTTP do que HTTPS. Uma das razões é que, se usasse TLS para verificação de revogação de certificados (download de CRLs ou OCSP), poderia haver um problema de galinha-e-ovo, onde o cliente ou appliance não consegue estabelecer a ligação TLS ao endpoint OCSP, porque o certificado do servidor precisa de ser verificado via OCSP primeiro. Além disso, não acrescenta muita segurança, porque as respostas OCSP são assinadas criptograficamente de qualquer forma e, portanto, não podem ser falsificadas. Assim, o SCEPman necessita de uma isenção das políticas que aplicam 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. Pode a Versão Mínima TLS de Entrada 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, 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), portanto se definir o TLS para 1.3, não poderá renovar os seus certificados usando EST.

Adicionalmente, 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 do lado do cliente durante a inscrição SCEP).

Nota: Como apenas navegadores acedem ao App Service do Certificate Master, é recomendado para o Certificate Master definir a Versão Mínima TLS de Entrada para 1.3.

RGPD e Residência de Dados

1. Os dados saem da Europa?

• Isto depende da escolha do cliente sobre o centro de dados Azure no qual o SCEPman e os seus componentes serão implantados.

• Uma implementação completa do SCEPman incluindo todos os seus componentes em centros de dados Azure europeus é possível.

2. De que fornecedores de cloud de terceiros o SCEPman depende e porquê?

Empresa	Serviços	Contacto	Propósito
Microsoft Corporation	Serviços 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 automação de releases, armazenamento	88 Colin P Kelly Jr St, San Francisco, CA 94107, Estados Unidos	Repositório de código, pipeline CI/CD, armazenamento de binários

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 adopção de práticas SDL ajuda-nos a criar código e implantações seguras. Temos a certificação de segurança da informação ISO 27001 para o nosso desenvolvimento de 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 Modelo de Ameaças em Equipa

A nossa prática de Modelagem de Ameaças baseia-se nas recomendações do Tufts Security and Privacy Lab. Discutimos decisões de concepção e potenciais ameaças STRIDE numa equipa heterogénea de desenvolvedores, o nosso 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, preferencialmente Open Source, em vez de reinventar a roda. Por exemplo, usamos a Legion of the Bouncy Castle C# para trabalhar com standards de dados criptográficos. Também dependemos de serviços Azure como Key Vault para gerar chaves criptográficas, App Services para hospedagem de servidores web, Azure Monitor para logging, e Azure Storage como motor de base de dados.

Configuração Segura é a Predefinição

Para minimizar o potencial de erro humano, desenhamos os produtos de forma que tenha uma configuração segura se usar as predefinições. Por exemplo, os nossos templates ARM e o nosso provider Terraform definem configurações para usar chaves RSA de 4096 bits suportadas por HSM, e desativam todos os endpoints de inscrição excepto o SCEP do Intune e o Certificate Master (para o qual tem de atribuir permissões explicitamente).

Nunca confiar em dados do cliente

Como software PKI, decidir quais os dados em que se deve confiar está no cerne 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 logging baseado no Azure Monitor permite a vigilância das operações do SCEPman. Integra-se facilmente com sistemas SIEM como o Sentinel para detectar atacantes bem sucedidos, por exemplo, se conseguirem 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 nosso modelo RBAC para o Certificate Master permite atribuir apenas as permissões que os utilizadores realmente necessitam.

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

Minimizar o Raio de Impacto

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

Minimizar Superfície de Ataque

Asseguramos expor apenas as interfaces necessárias para operações pelo cliente. Se um endpoint SCEP não estiver configurado, pedidos SCEP nem sequer são processados.

Usando Endpoints Privados, asseguramos que dois serviços dos quais o SCEPman depende, Azure Key Vault e Azure Storage, não são alcançáveis pela internet.

Considerar Casos de Abuso

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

Monitorizar e Alertar sobre Eventos de Segurança

Se o SCEPman detectar Eventos de Segurança, eles serão registados como Aviso ou Erro nos registos. A integração com Azure Monitor e Azure Event Hub torna simples configurar alertas ou analisar estes 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 código têm regras de Proteção de Branch e atribuímos apenas os princípios estritamente necessários aos repositórios e pipelines de implantação para contas individuais de desenvolvedores. Automatizamos testes e implantaçõ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 recompensa por bugs (bug-bounty)?

Não.

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

• Fornecemos o SCEPman em canais interno, beta e produção

• Cada release de produção deve passar primeiro pelos canais interno e beta, superando os obstáculos de QA relevantes como parte do nosso processo CI

  • Testes unitários

  • Revisão por pares

  • Testes de integração

  • Testes de stress

  • Testes baseados em experiência

  • Análise de código por terceiros, por ex. Sonar, Dependabot e outros

6. Realizam testes de penetração regularmente?

Não.

Como parte das nossas Práticas de Desenvolvimento Seguro, empregamos ferramentas (por ex. análise estática de código) que escaneiam a base de código em busca de CVEs e outros exploits comuns (incluindo dependências como bibliotecas de terceiros) que possam impactar a segurança dos endpoints que o SCEPman expõe. Antes de qualquer release, quaisquer descobertas relevantes são avaliadas e remediadas, para garantir que o SCEPman permaneça livre de vulnerabilidades conhecidas. Não realizamos testes de penetração internamente, nem usamos ferramentas de terceiros “Penetration Test-as-a-Service”. Para o primeiro, vemos um conflito de interesses inerente. Para o segundo, uma vez que serviços típicos de testes de penetração frequentemente verificam apenas os endpoints expostos contra CVEs e outros exploits conhecidos, não vemos valor acrescentado às verificações 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 os seus requisitos.