> For the complete documentation index, see [llms.txt](https://docs.scepman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scepman.com/pt/outros/security-faq.md). # 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 utilizando os protocolos SCEP e EST para emissão e os protocolos OCSP e CRL para validação desses certificados. Cada **certificado de dispositivo** deve conter um identificador de dispositivo exclusivo. 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 de dispositivo O 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 * Agente do utilizador (informações do sistema operativo e do navegador) O Certificate Master mantém uma trilha de auditoria da atividade dos administradores (UPNs). ### 2. Que dados são armazenados persistentemente 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 e o certificado da CA do SCEPman, 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 numa Azure Storage Account - *excluindo chaves privadas*. * Para os dados que podem fazer parte de um certificado, consulte [pergunta 1](#id-1.-which-data-is-processed-by-scepman). * Este comportamento pode ser [desativado](/pt/configuracao-do-scepman/application-settings/basics.md#appconfig-enablecertificatestorage). * 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 secretos** e **não pessoais** dados para o nosso Log Analytics Workspace (LAW). Estes dados são utilizados para * fins de licenciamento. * Garantia de qualidade (por exemplo, monitorizar exceções globalmente ajuda-nos a reconhecer rapidamente problemas gerais e disseminados, permitindo-nos fornecer uma solução rápida aos nossos clientes e, assim, evitar 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 AG. Os nossos engenheiros de suporte podem solicitar [ativar](/pt/configuracao-do-scepman/application-settings/basics.md#appconfig-remotedebug) o recurso de depuração remota ao administrador do cliente, para auxiliar em pedidos de resolução de problemas. Nesses casos, informações sobre o pedido de certificado podem ser enviadas para a nossa conta LAW, possivelmente contendo dados pessoais, tais como (o cliente decide quais informações fazem parte do certificado): * Nome de utilizador * E-mail * UPN do Microsoft Entra ID (Azure AD) * Identificador de dispositivo Eliminamos periodicamente **todos os** dados registados num 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 em modelo de solução), ou seja, é implementado no Tenant Azure do cliente. Assim, a soberania dos dados, incluindo a escolha da localização geográfica do centro de dados de alojamento, está nas mãos e ao critério 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 licenças está localizado no **Europa Ocidental do Azure** centro de dados. ### 4. A que permissões de Tenant o administrador tem de consentir? O SCEPman utiliza Identidades Geridas 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 tem origem no Intune, sendo que 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 de dispositivo é originado por 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 o recurso [de revogação EndpointList](/pt/configuracao-do-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-devicedirectory). 4. Microsoft Graph `IdentityRiskyUser.Read.All`:\ \ Esta permissão permite que o SCEPman automaticamente [revogue certificados de utilizador se o Risco de Utilizador AAD exceder um limiar configurado](/pt/configuracao-do-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-userriskcheck). #### Jamf Pro 1. Permissões de leitura em 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 é originado por um utilizador ou dispositivo autorizado. #### Certificate Master 1. Microsoft Graph `User.Read` (através do Registo de Aplicação):\ \ 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 Identidade Gerida):\ \ 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 e outros MDMs genéricos. 2. API REST de inscrição * Permite que o Certificate Master solicite 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 reinscrição 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](/pt/configuracao-do-scepman/application-settings/crl.md). 6. API de validação * Permite que o Certificate Master avalie 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ó de leitura. * Pode ser desativado através de [configuração](/pt/configuracao-do-scepman/application-settings/basics.md#appconfig-anonymoushomepageaccess). 8. Ponto de extremidade de sonda 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 lista de certificados emitidos manualmente. 2. Ponto de extremidade de sonda do Certificate Master * Verificações de estado: Verificação de estado integrada do App Service ### 6. Como são protegidos os pontos de extremidade da pergunta 5? #### Serviço principal do SCEPman 1. Ponto(s) de extremidade SCEP * Intune: Protegido através da API de Desafio do Intune ([Documentação Microsoft](https://docs.microsoft.com/en-us/mem/intune/protect/scep-libraries-apis)) * Jamf Pro, DCs, outros MDMs genéricos: 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. Ponto de extremidade EST * Reinscrição 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 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](/pt/configuracao-do-scepman/rbac.md). 2. Ponto de extremidade de sonda do Certificate Master * Sem proteção. ### 7. Que portas e protocolos são utilizados 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, outros MDMs genéricos: HTTPS (TCP / 443) 2. API REST de inscrição * 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 utilizado por serviços externos. 7. Página inicial do SCEPman * HTTPS (TCP / 443) 8. Ponto de extremidade de sonda do SCEPman * HTTPS (TCP / 443) #### Certificate Master 1. Portal Web do Certificate Master * HTTPS (TCP / 443) 2. Ponto de extremidade de sonda do Certificate Master * HTTPS (TCP / 443) ## Identidade ### 1. Existem controlos de Conditional Access / controlo de acesso baseado em funções para proteger o SCEPman? * Sim. Pode ser utilizado o conjunto completo de políticas RBAC do Microsoft Entra ID (Azure AD). ### 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: Os utilizadores autorizados podem aceder ao desafio. ## Proteção de dados ### 1. Como são *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 for escolhido não armazenar os dados de configuração no Azure Key Vault, estes são armazenados no AppService (encriptação Bit-Locker) * 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](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#compliance) por predefinição). * A chave privada não pode ser lida nem exportada. * A chave privada é protegida contra eliminação por administradores maliciosos ([proteção contra limpeza e eliminação suave](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview) estão ativadas por predefinição). * O Azure Key Vault utiliza 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 superiores). #### Base de dados de certificados * A base de dados utiliza o serviço Table de uma Azure Storage Account. Portanto, a proteção depende dos mecanismos incorporados no Azure. * Em particular, o Azure utiliza o acesso baseado em funções para gerir permissões aos dados. * O Azure Storage utiliza encriptação de bases de dados e suporta chaves geridas pelo cliente. * A Azure Storage Account utiliza um ponto de extremidade privado e só pode ser acedida a partir do SCEPman (predefinição para instalações do SCEPman da versão 2.8 e superiores). #### Registos * Os registos são armazenados num espaço de trabalho do Log Analytics. * O Log Analytics utiliza encriptação de bases de dados e suporta chaves geridas pelo cliente. ### 2. Como são *dados em trânsito* protegidos contra acesso não autorizado? * SCEP: * Utiliza TLS por predefinição (TLS mínimo 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 ovo e galinha. * As respostas OCSP são assinadas pelo certificado da CA. * API REST de inscrição e EST: * Impõe TLS (TLS mínimo 1.2 - aplicam-se as políticas Microsoft). * Portal Web do Certificate Master: * Impõe TLS (TLS mínimo 1.2 - aplicam-se as políticas Microsoft). * Comunicação entre componentes Azure do SCEPman: * TLS (TLS mínimo 1.2 - aplicam-se as políticas Microsoft). ## Segurança desde a conceção ### 1. O SCEPman utiliza uma estratégia de defesa em profundidade? #### Componentes 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, as seguintes tecnologias são utilizadas 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 dispositivos Microsoft Entra ID (Azure AD) * Pontos de extremidade privados Como o SCEPman é construído sobre componentes Azure, pode utilizar 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, juntamente 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 conceção muito importante. Um elevado nível de segurança também requer um elevado nível de conveniência para o utilizador, pois 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 quando 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 através do Intune e Jamf Pro, o SCEPman faz isto automaticamente assim que são tomadas contramedidas comuns não específicas do SCEPman contra o ataque. Só tem de [eliminar o Intune correspondente](/pt/configuracao-do-scepman/device-directories.md) ou objeto Jamf Pro. Dependendo dos seus processos de desativação de dispositivos, pode adicionalmente configurar para [revogar certificados quando uma limpeza é acionada](/pt/configuracao-do-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationrevokecertificatesonwipe), quando [o Intune solicita a revogação](/pt/configuracao-do-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationdevicedirectory), dependendo da [conformidade do dispositivo](/pt/configuracao-do-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationcompliancecheck) ou [nível de risco do utilizador](/pt/configuracao-do-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationuserriskcheck), ou pode revogar manualmente certificados individuais através do componente Certificate Master. [Certificados criados manualmente](/pt/gestao-de-certificados/certificate-master.md) exigem sempre uma revogação manual. ### 2. Que tecnologias, pilhas e plataformas foram utilizadas para conceber o SCEPman? * `C#` * `ASP.NET Core MVC` * `API Crypto Bouncy Castle` * `Azure (App Service, Key Vault, Storage Account, 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 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 por SCEP, o Intune suporta chaves RSA até 4096 bits em todas as plataformas, 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 ponto de extremidade 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](https://www.bouncycastle.org/csharp/)). Para a chave da CA, o SCEPman suporta apenas RSA. RSA de 4096 bits é o tamanho de chave predefinido. Atualmente, 4096 bits é o máximo suportado pelo Azure Key Vault. Se utilizar um certificado de CA Intermédia, também pode utilizar 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, que suporta as seguintes curvas elípticas: P-256, secp256k1/P-256K, P-384, P-521. ### 4. A CA criada pelo SCEPman é exclusiva? Sim Detalhes: * O SCEPman gera o par de chaves privada-pública para a CA Raiz no Azure Key Vault no seu Tenant. Por conseguinte, a CA Raiz é exclusiva da sua instância pessoal do SCEPman e tem controlo total sobre a CA, o respetivo 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 desejar. Por predefinição, apenas a sua própria instância do SCEPman e mais ninguém (nem mesmo um administrador) pode utilizar o certificado, mas um administrador de subscrição pode conceder permissões adicionais. * Consequentemente, outros clientes do SCEPman não poderão ligar-se à sua VPN, independentemente de como configurarem o respetivo SCEPman. Se escolherem o mesmo nome de organização, continuarão a ter o seu próprio par de chaves e, por conseguinte, outro certificado de CA no qual o seu 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 estruturas de melhores práticas, como o [CIS Microsoft Azure Foundations Benchmark](https://www.cisecurity.org/benchmark/azure/). ### Contas de armazenamento #### 1. Pode `Permitir acesso público a Blob` ser desativado? *Sim*, isso já é, de facto, a predefinição para novas instalações do SCEPman. ### App Services #### 2. TLS: Pode o `Modo de certificado de cliente` ser definido como `Exigir`? *Não*, pois isto interromperia a funcionalidade do SCEPman. Isto ocorre porque o SCEPman inscreve certificados de cliente, pelo que os clientes ainda não têm certificados de cliente para se autenticarem (problema de ovo e galinha). No entanto, isto não é um problema de segurança, pois o protocolo SCEP utiliza os seus próprios mecanismos de autenticação através do desafio SCEP. Por isso, o SCEPman necessita de uma exceção às políticas que impõem TLS mútuo. O `Modo de certificado de cliente` deve 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, atualmente apenas suportamos a predefinida `HTTP 1.1` - principalmente devido à falta de testes. Ao alterar esta definição — por sua conta e risco —, considere 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 SO do Windows, macOS, iOS, iPadOS, os existentes em 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 interromperá a funcionalidade do respondedor OCSP do SCEPman em combinação com muitos clientes OCSP e equipamentos de fornecedores. OCSP é um protocolo que é mais frequentemente disponibilizado por HTTP do que por HTTPS. Uma das razões é que, se utilizasse TLS para verificação de revogação de certificados (transferência de CRLs ou OCSP), poderia ocorrer um problema de ovo e galinha, em que o cliente ou equipamento não consegue estabelecer a ligação TLS ao ponto de extremidade OCSP, porque o certificado do servidor precisa de ser verificado primeiro por OCSP. Também não acrescenta muita segurança, porque as respostas OCSP já são assinadas criptograficamente e, por isso, não podem ser falsificadas. Por isso, o SCEPman necessita 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 TLS Mínima de Entrada pode ser definida como 1.3? *Não* para o App Service do SCEPman, pois 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 (reinscrição simples EST), portanto, se definir TLS como 1.3, não poderá renovar os seus certificados utilizando 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 (ocorrerá um [erro durante a inscrição SCEP](/pt/outros/troubleshooting/general.md#some-windows-machines-do-not-enroll-or-renew-certificates)). **Nota:** Como apenas os navegadores acedem ao App Service do Certificate Master, recomenda-se definir a Versão TLS Mínima de Entrada como 1.3 para o Certificate Master. ## Conformidade ### 1. A glueckkanja possui certificação ISO 27001? Sim. O Sistema de Gestão de Segurança da Informação (ISMS) da glueckkanja AG é certificado de acordo com **ISO/IEC 27001:2022**. O âmbito da certificação abrange: * Desenvolvimento de produtos * Serviços geridos Pode consultar o certificado atual [aqui](https://www.glueckkanja.com/documents/general/gk-ISO27001Certificate-en.pdf). ### 2. A glueckkanja tem a sua segurança testada por especialistas externos? Sim. Em 2026, a glueckkanja AG contratou uma empresa independente e especializada em segurança ofensiva para realizar uma avaliação Red Team que abrange toda a nossa empresa. Escolhemos deliberadamente esta abordagem holística em vez de um teste de penetração clássico. Em vez de verificar sistemas ou pontos de extremidade individuais quanto a vulnerabilidades conhecidas, a Red Team simulou um ciberataque avançado e realista por um atacante interno à nossa infraestrutura de TI, encadeando técnicas da mesma forma que adversários reais fazem. A avaliação concentrou-se em: * identificar vulnerabilidades de alto impacto, * mapear percursos completos de ataque através do nosso ambiente, * avaliar vetores potenciais para obter acesso não autorizado a ambientes de clientes, * avaliar vetores potenciais para executar ataques à cadeia de fornecimento. Todas as conclusões foram documentadas juntamente com recomendações de mitigação e são tratadas como parte do nosso Sistema de Gestão de Segurança da Informação certificado pela ISO 27001. Repetiremos esta avaliação Red Team anualmente. ## RGPD e residência de dados ### 1. Os dados saem da Europa? * Isto depende da escolha do cliente quanto ao centro de dados Azure no qual o SCEPman e os seus componentes serão implementados. * É possível implementar totalmente o SCEPman, incluindo todos os seus componentes, em centros de dados Azure europeus. ### 2. Em que fornecedores de cloud de terceiros o SCEPman depende 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](/pt/implementacao-do-scepman/deployment-guides/enterprise-guide-1.md#overview-azure-resource). | | 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,

São 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 [Ciclo de Vida de Desenvolvimento de Segurança da Microsoft](https://www.microsoft.com/en-us/securityengineering/sdl/). A utilizaçã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 nosso desenvolvimento de produtos](#id-1.-is-glueckkanja-iso-27001-certified). ### 2. Como implementam práticas comuns de conceção segura? É assim que implementamos [Práticas de Conceção Segura recomendadas pelo SDL](https://www.microsoft.com/en-us/securityengineering/sdl/practices/secure-by-design): #### Conceção e Modelo de Ameaças em Equipa A nossa prática de Modelação de Ameaças baseia-se no [recomendações do Tufts Security and Privacy Lab](https://tsp.cs.tufts.edu/tmnt/threatmodeling.html). Discutimos decisões de design e ameaças STRIDE potenciais em uma equipe heterogênea de desenvolvedores, nossa [CSOC ](https://www.glueckkanja.com/en/security/cloud-security-operations-center/)e consultores de PKI e equipe de suporte. #### Prefira a segurança da plataforma ao código personalizado Sempre que possível, usamos funcionalidades do .NET ou bibliotecas consolidadas, de preferência de código aberto, 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 contamos com serviços do Azure como Key Vault para gerar chaves criptográficas, App Services para hospedagem de servidor web, Azure Monitor para registro de logs e Azure Storage como mecanismo de banco de dados. #### A Configuração Segura é o Padrão Para minimizar o potencial de erro humano, projetamos os produtos de modo que você tenha uma configuração segura se usar os padrões. Por exemplo, nossos [modelos ARM](https://github.com/scepman/install) e nosso [provedor Terraform ](https://registry.terraform.io/modules/scepman/scepman/)definem as configurações para usar chaves RSA de 4096 bits respaldadas por HSM e desativam todos os endpoints de inscrição, exceto Intune SCEP e Certificate Master (para os quais você precisa atribuir permissões explicitamente). #### Nunca confie em dados do cliente Como um software de PKI, decidir em quais dados confiar está no cerne de toda decisão. Afinal, o propósito dos certificados e de seus protocolos de inscrição é decidir em quais dados confiar. #### Assuma a violação Nosso registro baseado no Azure Monitor permite o monitoramento das operações do SCEPman. Ele se integra facilmente a sistemas SIEM como o Sentinel para detectar invasores bem-sucedidos, por exemplo, se eles conseguiram inscrever certificados sem autorização. Nossa integração com serviços do Azure permite aproveitar os serviços do Microsoft Defender for Cloud, por exemplo, o Defender for App Service. #### Aplicar o princípio do menor privilégio O modelo RBAC do Certificate Master permite atribuir aos usuários apenas as permissões de que precisam. O SCEPman usa Managed Identities que têm apenas [as permissões necessárias para a operação](#id-4.-which-tenant-permissions-does-the-admin-have-to-consent-to). #### Minimize o raio de impacto Nos esforçamos para minimizar os possíveis danos em caso de um ataque bem-sucedido. Por exemplo, nossa instalação padrão habilita o Key Vault[ recurso de Soft Delete com Purge Protection](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview) com uma [chave privada não exportável respaldada por HSM](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#hsm-protected-keys) para a Autoridade Certificadora. O Soft Delete com Purge Protection garante que nenhum administrador mal-intencionado nem nenhuma conta de administrador comprometida possa excluir a chave privada da CA. A chave privada pode ser restaurada em minutos para continuar com as operações normais, e nem mesmo um Global Admin pode eliminá-la antes de um período de 90 dias. A chave da CA não exportável respaldada por HSM garante que mesmo um atacante com os privilégios mais altos possíveis não possa roubar a chave da CA. #### Minimize a superfície de ataque Asseguramos expor apenas as interfaces necessárias para as operações do cliente. Se um endpoint SCEP não estiver configurado, as solicitações SCEP nem sequer são processadas. Usando [Pontos de extremidade privados](/pt/configuracao-do-azure/private-endpoints.md), garantimos que dois serviços dos quais o SCEPman depende, Azure Key Vault e Azure Storage, não sejam acessíveis pela internet. #### Considere casos de abuso Quando o SCEPman recebe uma solicitação de assinatura de certificado (CSR) autorizada, ele ainda está sujeito a várias restrições configuráveis. Por exemplo, a validade nunca pode exceder o [período máximo de validade configurado](/pt/configuracao-do-scepman/application-settings/certificates.md#appconfig-validityperioddays), mesmo que isso tenha sido solicitado. #### Monitore e emita alertas sobre eventos de segurança Quando o SCEPman detecta eventos de segurança, ele os registra no nível Warning ou Error. As integrações com Azure Monitor e Azure Event Hub permitem que você [configure alertas](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview) ou analise eventos com um SIEM. ### 3. Como vocês protegem o próprio ambiente de desenvolvimento? Como parte de uma empresa que também fornece serviços de CSOC e consultoria de segurança, temos altos padrões de segurança para nossos dispositivos, processos e conscientização dos usuários. Fazemos parte da Microsoft MISA, somos certificados pela ISO 27001 e fomos Microsoft Partner of the Year com nossas ofertas de Segurança. Nossos repositórios de código-fonte têm regras de Branch Protection e atribuímos apenas as entidades mínimas necessárias aos repositórios e pipelines de implantação das contas individuais dos desenvolvedores. Automatizamos testes e implantações sempre que possível para reduzir a superfície de ataque decorrente de contas comprometidas. ### 4. O SCEPman faz parte de um programa de bug bounty? Não. ### 5. Quais medidas de QA estão em vigor? * Fornecemos o SCEPman em um canal interno, beta e de produção * Cada versão de produção deve passar primeiro pelos canais interno e beta, atendendo aos critérios relevantes de QA como parte do nosso processo de CI * Testes unitários * Revisão por pares * Testes de integração * Testes de estresse * Testes baseados em experiência * Análise de código de terceiros, por exemplo, Sonar, Dependabot e outros ### 6. Vocês realizam testes de penetração regularmente? Não na forma de um teste de penetração clássico do SCEPman. Em vez disso, a glueckkanja AG passa por uma avaliação anual de Red Team conduzida por um especialista externo independente, que vai além de um teste de penetração clássico (veja [A glueckkanja tem sua segurança testada por especialistas externos?](#id-2.-does-glueckkanja-have-its-security-tested-by-external-experts)). Como parte de nossas Práticas de Desenvolvimento Seguro, empregamos ferramentas (por exemplo, análise estática de código) que verificam a base de código em busca de CVEs e outras explorações comuns (incluindo dependências como bibliotecas de terceiros) que possam impactar a segurança dos endpoints expostos pelo SCEPman. Antes de qualquer lançamento, quaisquer achados relevantes são avaliados e corrigidos, para garantir que o SCEPman permaneça livre de quaisquer vulnerabilidades conhecidas. Nós não realizamos testes de penetração nós mesmos, nem usamos 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 teste de penetração muitas vezes simplesmente verificam os endpoints expostos contra CVEs e outras explorações conhecidas, não vemos benefícios em relação às verificações que já realizamos usando análise estática de código. Em vez disso, contamos com uma abordagem holística: em 2026, uma Red Team independente simulou um ataque realista e avançado à glueckkanja AG, incluindo explicitamente caminhos de ataque para ambientes de clientes e ataques à cadeia de suprimentos. Em vez de testar endpoints isolados, essa avaliação examina caminhos de ataque completos em toda a nossa organização, o que consideramos muito mais significativo para a segurança de nossos clientes. Repetimos essa avaliação anualmente. Se você deseja realizar seus próprios testes de penetração, por favor [entre em contato conosco](https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29) e nos conte sobre seus requisitos. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.scepman.com/pt/outros/security-faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.