Seguridad y privacidad

Este capítulo proporciona una visión general de preguntas frecuentes sobre seguridad de la información, privacidad y aseguramiento de la calidad.

Procesamiento de datos y permisos

1. ¿Qué datos procesa SCEPman?

SCEPman procesa certificados X.509 usando los protocolos SCEP y EST para emitirlos y los protocolos OCSP y CRL para validar esos certificados. Cada certificado de dispositivo debe contener un identificador de dispositivo único. Además, para certificados de usuario, recomendamos configurar los siguientes valores como parte del certificado:

• Nombre de usuario

• Correo electrónico

• Microsoft Entra ID (Azure AD) UPN

• Identificador del dispositivo

SCEP, EST, OCSP y CRL se basan en HTTP(S), es decir, los siguientes datos son visibles para SCEPman:

• Dirección IP del cliente + puerto

• Agente de usuario (información del sistema operativo y navegador)

Certificate Master mantiene una pista de auditoría sobre la actividad de administradores (UPNs).

2. ¿Qué datos se almacenan de manera persistente por/en nombre de SCEPman y cómo?

1. Configuración

   • Los datos de configuración siempre contienen el par de claves pública/privada y el certificado de la CA de SCEPman, que se almacena de forma segura en Azure Key Vault.

   • Adicionalmente, los datos de configuración pueden contener secretos como desafíos SCEP estáticos o contraseñas. El propósito de esos parámetros se explica en la documentación de SCEPman.

   • Todos los parámetros de configuración pueden almacenarse en Azure Key Vault para mayor seguridad.

2. Certificados emitidos

   • Todos los certificados emitidos se almacenan en una cuenta de almacenamiento de Azure - excluyendo las claves privadas.

   • Para los datos que pueden formar parte de un certificado, por favor refiérase a pregunta 1.

   • Este comportamiento puede ser desactivado.

   • Al emitir certificados a través de Certificate Master, se almacena el solicitante (Microsoft Entra ID (Azure AD) UPN).

   • Al revocar certificados a través de Certificate Master, se almacena el estado de revocación del certificado y la identidad del usuario que lo revocó (Microsoft Entra ID (Azure AD) UPN).

3. Registro (Logging)

   Según la configuración del cliente para SCEPman, el registro puede activarse. Dependiendo del nivel de verbosidad configurado por el cliente, los registros pueden contener cualquier dato que SCEPman procese. El cliente configura la ubicación de almacenamiento de los registros.

4. Espacio de trabajo externo de Log Analytics

   SCEPman siempre envía una cantidad limitada de no secreta y no personal datos a nuestro espacio de trabajo de Log Analytics (LAW). Estos datos se usan para

   • fines de licencia.

   • Aseguramiento de calidad (por ejemplo, monitorizar excepciones a nivel global nos ayuda a reconocer problemas generales y extendidos rápidamente, permitiéndonos ofrecer remedio a nuestros clientes con rapidez y así prevenir costosos cortes del servicio).

   Por defecto, SCEPman no envía ningún dato personal a nuestro LAW.

   Dependiendo de la configuración de registro, la información de depuración y otra información se reenvía al LAW de glueckkanja-gab AG. Nuestros ingenieros de soporte pueden solicitar activar la función de depuración remota al administrador del cliente para apoyar las consultas de resolución de problemas. En tales casos, la información sobre la solicitud del certificado puede enviarse a nuestra cuenta de LAW, posiblemente (el cliente decide qué información forma parte del certificado) conteniendo datos personales tales como:

   • Nombre de usuario

   • Correo electrónico

   • Microsoft Entra ID (Azure AD) UPN

   • Identificador del dispositivo

   Periódicamente eliminamos todos los datos registrados en un intervalo de

   • 30 días

3. ¿Dónde (geográficamente) procesa y almacena datos SCEPman?

Por diseño, SCEPman está realizado como una aplicación de Azure (basada en plantilla de solución), es decir, se despliega en el tenant de Azure del cliente. Como tal, la soberanía de los datos, incluyendo la elección de la ubicación geográfica del centro de datos de alojamiento, está en manos y preferencias del cliente.

Espacio de trabajo externo de Log Analytics

El LAW externo que empleamos para recopilar (por defecto no personal y no secreta) información de telemetría con fines de cumplimiento de licencias se encuentra en el centro de datos Oeste de Europa de Azure .

4. ¿A qué permisos del tenant debe dar su consentimiento el administrador?

SCEPman aprovecha Identidades Administradas para implementar un modelo de permisos seguro en su tenant de Azure.

Intune

1. Intune scep_challenge_provider: Con este permiso SCEPman puede reenviar la solicitud de certificado a Intune y verificar que la solicitud de certificado se origina en Intune, lo que añade una capa adicional de seguridad.

2. Microsoft Graph Directory.Read.All: Con este permiso, SCEPman puede consultar Microsoft Entra ID (Azure AD) para comprobar si el certificado de usuario o dispositivo se origina en un usuario o dispositivo autorizado.

3. Microsoft Graph DeviceManagementManagedDevices.Read.All y DeviceManagementConfiguration.Read.All: Con estos permisos, SCEPman solicita la lista de certificados emitidos a través de Intune cuando se utiliza la función de revocación EndpointList.

4. Microsoft Graph IdentityRiskyUser.Read.All: Este permiso permite a SCEPman automáticamente revocar certificados de usuario si el riesgo de usuario en AAD excede un umbral configurado.

Jamf Pro

1. Permisos de lectura sobre usuarios, ordenadores y dispositivos Con estos permisos, SCEPman puede consultar Jamf Pro para comprobar si el certificado de usuario o dispositivo se origina en un usuario o dispositivo autorizado.

Certificate Master

1. Microsoft Graph User.Read (vía App Registration): Con este permiso, Certificate Master determina quién solicita o revoca manualmente un certificado.

2. Micrsoft Graph DeviceManagementManagedDevices.Read.All y DeviceManagementConfiguration.Read.All (como Identidad Administrada): Con estos permisos, Certificate Master solicita la lista de certificados emitidos a través de Intune. Los administradores pueden revisar y revocar manualmente estos certificados.

5. ¿Qué puntos finales accesibles externamente expone SCEPman?

Servicio núcleo de SCEPman

1. Punto(s) final(es) SCEP

   • Invocado para solicitudes SCEP.

   • Según la configuración, SCEPman puede exponer varios puntos finales SCEP para Intune, Jamf Pro, DCs, Otros MDMs genéricos.

2. API REST de registro (Enrollment REST API)

   • Permite a Certificate Master solicitar certificados del servicio núcleo de SCEPman.

   • Permite a aplicaciones personalizadas solicitar certificados del servicio núcleo de SCEPman.

3. Punto final EST

   • Invocado para solicitudes EST de re-inscripción simple. Puede habilitarse mediante configuración.

   • Invocado para solicitudes EST de inscripción simple.

4. Punto final OCSP

   • Invocado para solicitudes OCSP.

5. Punto de distribución de certificados (CDP)

   • La Lista de Revocación de Certificados (CRL) se pone a disposición a través de este endpoint.

   • Puede habilitarse mediante configuración.

6. API de validación

   • Permite a Certificate Master evaluar el estado de revocación automática de un certificado.

7. Página principal de SCEPman

   • Muestra públicamente la información básica de estado de SCEPman (sin secretos).

   • Solo lectura.

   • Puede desactivarse mediante configuración.

8. Punto final de sondeo de SCEPman

   • Comprobaciones de estado: Health Check integrado de App Service, sondeo de Traffic Manager, sondeo de Application Gateway.

Certificate Master

1. Portal web de Certificate Master

   • Emitir manualmente certificados de servidor y firmar CSRs.

   • Revocar manualmente certificados emitidos a través de Certificate Master.

   • Ver la lista de certificados emitidos manualmente.

2. Punto final de sondeo de Certificate Master

   • Comprobaciones de estado: Health Check integrado de App Service

6. ¿Cómo están protegidos los endpoints del punto 5?

Servicio núcleo de SCEPman

1. Punto(s) final(es) SCEP

   • Intune: Protegido vía Intune Challenge API (Microsoft Docs)

   • Jamf Pro, DCs, Otros MDMs genéricos: Protegidos con un desafío SCEP estático. Configurable por el cliente. Puede almacenarse en Azure Key Vault.

2. API REST de registro (Enrollment REST API)

   • Autenticación integrada de Microsoft Entra ID (Azure AD).

3. Punto final EST

   • Re-inscripción simple: Autenticación basada en certificados.

   • Inscripción simple: Autenticación integrada de Microsoft Entra ID (Azure AD).

4. Punto final OCSP

   • No se requiere protección.

5. Punto de distribución de certificados (CDP)

   • Se requiere token de acceso.

6. API de validación

   • Autenticación integrada de Microsoft Entra ID (Azure AD).

7. Página principal de SCEPman

   • Sin protección pero puede desactivarse.

8. Punto final de sondeo de SCEPman

   • Sin protección.

Certificate Master

1. Portal web de Certificate Master

   • Autenticación integrada de Microsoft Entra ID (Azure AD).

   • Microsoft Entra ID (Azure AD) Asignaciones de roles.

2. Punto final de sondeo de Certificate Master

   • Sin protección.

7. ¿Qué puertos y protocolos usan los endpoints de la pregunta 6?

Servicio núcleo de SCEPman

1. Punto(s) final(es) SCEP

   • Intune: HTTPS (TCP / 443)

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

2. API REST de registro (Enrollment REST API)

   • HTTPS (TCP / 443)

3. Punto final EST

   • HTTPS (TCP / 443)

4. Punto final OCSP

   • HTTP (TCP / 80)

5. Punto de distribución de certificados (CDP)

   • HTTP (TCP / 80)

6. API de validación

   • No usado por servicios externos.

7. Página principal de SCEPman

   • HTTPS (TCP / 443)

8. Punto final de sondeo de SCEPman

   • HTTPS (TCP / 443)

Certificate Master

1. Portal web de Certificate Master

   • HTTPS (TCP / 443)

2. Punto final de sondeo de Certificate Master

   • HTTPS (TCP / 443)

Identidad

1. ¿Existen controles de acceso condicional / basados en roles para proteger SCEPman?

• Sí. Se puede aprovechar el conjunto completo de políticas RBAC de Microsoft Entra ID (Azure AD).

2. ¿Se pueden recuperar las credenciales de acceso? Si es así, ¿cómo?

• Credenciales de inicio de sesión: Depende de las políticas configuradas de Microsoft Entra ID (Azure AD) en el tenant del cliente.

• Desafío SCEP estático: Usuarios autorizados pueden acceder al desafío.

Protección de datos

1. ¿Cómo se protege los datos en reposo contra el acceso no autorizado?

Datos de configuración

• Los datos de configuración pueden almacenarse de forma segura en Azure Key Vault (versión >= 1.7).

• Si se elige no almacenar los datos de configuración en Azure Key Vault, se almacenan en App Service (cifrado BitLocker).

• Cualquier dato de configuración (Azure Key Vault, App Services) solo puede ser accedido por usuarios autorizados con los permisos relevantes de Azure.

Claves criptográficas

• La clave privada de la CA se almacena de forma segura en Azure Key Vault (HSM validado FIPS 140 por defecto).

• La clave privada no puede leerse ni exportarse.

• La clave privada está protegida contra eliminación por administradores malintencionados (la protección contra purga y el borrado suave están habilitados por defecto).

• Azure Key Vault usa un endpoint privado y solo puede ser accedido desde SCEPman (por defecto para instalaciones de SCEPman versión 2.8 y superiores).

Base de datos de certificados

• La base de datos usa el servicio Table de una cuenta de almacenamiento de Azure. Por tanto, la protección depende de los mecanismos integrados en Azure.

• En particular, Azure emplea control de acceso basado en roles para gestionar permisos sobre los datos.

• Azure Storage utiliza cifrado de base de datos y soporta claves gestionadas por el cliente.

• La cuenta de almacenamiento de Azure utiliza un endpoint privado y solo puede ser accedida desde SCEPman (por defecto para instalaciones de SCEPman versión 2.8 y superiores).

Registros

• Los registros se almacenan en un espacio de trabajo de Log Analytics.

• Log Analytics utiliza cifrado de base de datos y soporta claves gestionadas por el cliente.

2. ¿Cómo se protegen los datos en tránsito contra el acceso no autorizado?

• SCEP:

  • Usa TLS por defecto (TLS mínimo 1.2 - se aplican las políticas de Microsoft).

  • Las solicitudes SCEP se cifran al certificado de la CA y se firman con el certificado del cliente.

  • Las respuestas SCEP se cifran al certificado del cliente y se firman con el certificado de la CA.

• OCSP:

  • Las solicitudes OCSP no deben cifrarse para evitar problemas de tipo gallina-y-huevo.

  • Las respuestas OCSP están firmadas por el certificado de la CA.

• API REST de registro y EST:

  • Exige TLS (TLS mínimo 1.2 - se aplican las políticas de Microsoft).

• Portal web de Certificate Master:

  • Exige TLS (TLS mínimo 1.2 - se aplican las políticas de Microsoft).

• Comunicación entre los componentes de SCEPman en Azure:

  • TLS (TLS mínimo 1.2 - se aplican las políticas de Microsoft).

Seguridad por diseño

1. ¿Emplea SCEPman una estrategia de defensa en profundidad?

Componentes de Azure

La filosofía de diseño de SCEPman sigue el enfoque de minimizar su exposición a amenazas externas reduciendo las interfaces externas al mínimo requerido. Además de esto, se usan las siguientes tecnologías para reconocer y mitigar amenazas internas y externas en diferentes capas:

• Key Vault

• App Insights

• Verificación de inscripción de dispositivo en Intune

• Comprobación de dispositivo en Microsoft Entra ID (Azure AD)

• Endpoints privados

Dado que SCEPman se construye sobre componentes de Azure, puede usar herramientas de Microsoft Defender (MD) para Cloud como MD para App Service, MD para Storage o MD para Key Vault.

Validez del certificado

Como una PKI en la nube, SCEPman es responsable de la emisión y revocación de certificados digitales. Estos certificados junto con sus claves privadas autentican dispositivos o usuarios y otorgan acceso a otros recursos. Por ende, la seguridad de los procesos de emisión y revocación de certificados es un objetivo de diseño muy importante. Un alto nivel de seguridad requiere también un alto nivel de conveniencia para el usuario, ya que procesos complicados y poco transparentes tienen una mayor superficie de ataque y mayor potencial de error humano. Aunque SCEPman ofrece muchas opciones de configuración si es necesario, nos esforzamos por usar valores predeterminados razonables y seguros siempre que sea posible.

Así, si una clave privada se ve comprometida, SCEPman puede revocar el certificado correspondiente en tiempo real. Para certificados inscritos vía Intune y Jamf Pro, SCEPman hace esto automáticamente tan pronto como se toman las contramedidas comunes no específicas de SCEPman contra el ataque. Solo tiene que eliminar el correspondiente Intune u objeto de Jamf Pro.

Dependiendo de sus procesos de retiro de dispositivos, además puede configurar revocar certificados cuando se inicie un borrado, cuando Intune solicite la revocación, dependiendo de el cumplimiento del dispositivo o nivel de riesgo del usuario, o puede revocar manualmente certificados individuales a través del componente Certificate Master.

Los certificados creados manualmente siempre requieren una revocación manual.

2. ¿Qué tecnologías, stacks, plataformas se usaron para diseñar SCEPman?

• C#

• ASP.NET Core MVC

• Bouncy Castle Crypto API

• Azure (App Service, Key Vault, Storage Account, Log Analytics)

3. ¿Qué algoritmos criptográficos y tamaños de clave soporta SCEPman?

Para las claves de los certificados emitidos, Certificate Master no tiene restricciones cuando se usa el método CSR. Para certificados basados en formularios, RSA con 2048 o 4096 bits son los algoritmos y tamaños de clave soportados.

Para certificados inscritos vía SCEP, Intune soporta hasta claves RSA de 4096 bits en todas las plataformas, lo que SCEPman también soporta. Al usar el KSP de la plataforma (TPM), Windows soporta como máximo claves RSA de 2048 bits. Al usar el endpoint SCEP estático, se soportan todos los algoritmos y tamaños de clave comunes (específicamente aquellos que la biblioteca criptográfica Bouncy Castle para C# soporta).

Para la clave de la CA, SCEPman soporta solo RSA. RSA de 4096 bits es el tamaño de clave por defecto. 4096 bits es actualmente el máximo soportado por Azure Key Vault. Si usa un certificado de CA intermedia, también puede usar cualquier tamaño de clave soportado por Key Vault, pero debe ser una clave RSA.

Para escenarios que no requieren SCEP, se puede crear una CA ECC, soportando las siguientes curvas elípticas: P-256, secp256k1/P-256K, P-384, P-521.

4. ¿La CA creada por SCEPman es única?

Sí

Detalles:

• SCEPman genera el par de claves privada-pública para la CA raíz en Azure Key Vault en su tenant. Por lo tanto, la CA raíz es única para su instancia personal de SCEPman y usted tiene control total sobre la CA, su certificado y la clave privada correspondiente.

• El acceso a esta CA se controla mediante políticas de acceso de Key Vault que usted puede cambiar si lo desea. Por defecto, solo su propia instancia de SCEPman y nadie más (tampoco un administrador) puede usar el certificado, pero un administrador de suscripción puede conceder permisos adicionales.

• Por lo tanto, otros clientes de SCEPman no podrán conectarse a su VPN, sin importar cómo configuren su SCEPman. Si eligen el mismo nombre de organización, aun así tendrán su propio par de claves y por ende otro certificado de CA que su VPN Gateway no confiará.

Azure CIS

Esta sección cubre preguntas que surgen al definir políticas de ciberdefensa para su entorno de Azure o al trabajar con marcos de buenas prácticas como el CIS Microsoft Azure Foundations Benchmark.

Cuentas de almacenamiento

1. ¿Se puede Permitir acceso público a blobs desactivar?

Sí, eso ya es el valor predeterminado para nuevas instalaciones de SCEPman.

App Services

2. TLS: ¿Se puede Modo de certificado de cliente configurar en Requerir?

No, ya que esto rompería la funcionalidad de SCEPman. Esto es porque SCEPman inscribe certificados de cliente, por lo que los clientes aún no tienen certificados de cliente para autenticarse (problema gallina-y-huevo). Sin embargo, eso no es un problema de seguridad, ya que el protocolo SCEP usa sus propios mecanismos de autenticación mediante el desafío SCEP. Por lo tanto, SCEPman necesita una exención de las políticas que exigen TLS mutuo. El Modo de certificado de cliente debe configurarse en Ignorar o Opcional.

3. ¿Se puede configurar la versión de HTTP configurar en 2.0?

Aunque SCEPman debería funcionar con cualquiera de las versiones HTTP disponibles, a día de hoy solo soportamos la versión por defecto HTTP 1.1 - principalmente por falta de pruebas.

Al cambiar esta configuración - bajo su propio riesgo - tenga en cuenta que no solo SCEPman necesita soportar la nueva versión HTTP. Los diferentes tipos de clientes también deben soportar esa versión de HTTP, es decir, los clientes SCEP integrados en los SO de Windows, macOS, iOS, iPadOS, los de dispositivos IoT, los clientes OCSP en las mismas plataformas, pero también NACs de diferentes proveedores.

4. ¿Se puede Solo HTTPS habilitar?

No (no para el App Service de SCEPman), ya que esto rompería la funcionalidad del respondededor OCSP de SCEPman en combinación con muchos clientes OCSP y dispositivos de proveedores. OCSP es un protocolo que se proporciona más comúnmente sobre HTTP que sobre HTTPS. Una de las razones es que si se usa TLS para la comprobación de revocación de certificados (descargando CRLs u OCSP), podría aparecer un problema de tipo gallina-y-huevo, donde el cliente o dispositivo no puede establecer la conexión TLS al endpoint OCSP, porque el certificado del servidor necesita verificarse mediante OCSP primero. Tampoco añade mucha seguridad, ya que las respuestas OCSP están firmadas criptográficamente de todos modos y por tanto no pueden ser suplantadas. Por lo tanto, SCEPman necesita una exención de las políticas que exigen TLS.

Nota: Solo HTTPS no puede habilitarse para el App Service de SCEPman, pero debería habilitarse para el App Service de Certificate Master.

5. ¿Se puede establecer la versión mínima TLS entrante a 1.3?

No para el App Service de SCEPman, ya que TLS 1.3 no soporta renegociación. Esto significa que una vez establecida la conexión, el servidor no puede pedir al cliente que presente un certificado de cliente. Queremos que el cliente se autentique con un certificado en algunas circunstancias (reinscripción simple EST), por lo que si establece TLS en 1.3, no podrá renovar sus certificados usando EST.

Adicionalmente, no todos los clientes SCEP soportan TLS 1.3. Un ejemplo importante es el cliente SCEP integrado en Windows 8, 10 y 11, que a fecha 2025-07 no soporta TLS 1.3 (habrá un error del lado del cliente durante la inscripción SCEP).

Nota: Dado que solo los navegadores acceden al App Service de Certificate Master, se recomienda que Certificate Master establezca la versión mínima TLS entrante a 1.3.

RGPD y residencia de datos

1. ¿Los datos salen de Europa?

• Esto depende de la elección del cliente sobre el centro de datos de Azure en el que se desplegarán SCEPman y sus componentes.

• Es posible un despliegue completo de SCEPman incluyendo todos sus componentes en centros de datos de Azure en Europa.

2. ¿De qué proveedores de nube de terceros depende SCEPman y por qué?

Empresa	Servicios	Contacto	Propósito
Microsoft Corporation	Servicios en la nube (Azure)	Building 3, Carmanhall Road Sandyford, Industrial Estate 18, Dublin, Irelandia	Véase aquí.
GitHub Inc (subsidiaria de Microsoft Corporation)	repositorio de código git, integración, pruebas y automatización de lanzamiento, almacenamiento	88 Colin P Kelly Jr St, San Francisco, CA 94107, Estados Unidos	Repositorio de código, canal CI/CD, almacenamiento de binarios

Prácticas de desarrollo seguro

1. ¿Qué asegura que SCEPman es software seguro?

Nuestro desarrollo de software se basa en el Microsoft Security Development Lifecycle. Emplear prácticas SDL nos ayuda a crear código y despliegues seguros. Contamos con la certificación de seguridad de la información ISO 27001 para nuestro desarrollo de producto.

2. ¿Cómo implementan prácticas comunes de diseño seguro?

Así es como implementamos Prácticas de Diseño Seguro recomendadas por el SDL:

Diseñar y modelar amenazas en equipo

Nuestra práctica de modelado de amenazas se fundamenta en las recomendaciones del Tufts Security and Privacy Lab. Discutimos decisiones de diseño y amenazas potenciales STRIDE en un equipo heterogéneo de desarrolladores, nuestro CSOC y consultores PKI, y personal de soporte.

Preferir la seguridad de la plataforma al código personalizado

Cuando es posible, usamos funcionalidades de .NET o bibliotecas establecidas, preferentemente Open Source, en lugar de reinventar la rueda. Por ejemplo, usamos Legion of the Bouncy Castle C# para trabajar con estándares de datos criptográficos. También confiamos en servicios de Azure como Key Vault para generar claves criptográficas, App Services para alojamiento de servidores web, Azure Monitor para registro, y Azure Storage como motor de base de datos.

La configuración segura es la predeterminada

Para minimizar el potencial de error humano, diseñamos los productos de modo que tenga una configuración segura si usa los valores predeterminados. Por ejemplo, nuestras plantillas ARM y nuestro proveedor Terraform configuran ajustes para usar claves RSA respaldadas por HSM de 4096 bits y deshabilitan todos los endpoints de inscripción excepto Intune SCEP y Certificate Master (para los cuales debe asignar permisos explícitamente).

Nunca confiar en datos del cliente

Como software PKI, decidir qué datos confiar está en el corazón de cada decisión. Al fin y al cabo, el propósito de los certificados y sus protocolos de inscripción es decidir qué datos confiar.

Asumir una brecha

Nuestros registros basados en Azure Monitor permiten la vigilancia de las operaciones de SCEPman. Se integran fácilmente con sistemas SIEM como Sentinel para detectar atacantes exitosos, por ejemplo si consiguieron inscribir certificados sin autorización. Nuestra integración con servicios de Azure permite aprovechar los servicios de Microsoft Defender for Cloud, por ejemplo Defender for App Service.

Aplicar el principio de menor privilegio

Nuestro modelo RBAC para Certificate Master permite asignar solo los permisos que los usuarios realmente necesitan.

SCEPman usa Identidades Administradas que solo tienen los permisos necesarios para la operación.

Minimizar el radio de impacto

Nos esforzamos por minimizar el posible daño en caso de un ataque exitoso. Por ejemplo, nuestra instalación por defecto habilita la función Soft Delete de Key Vault con protección contra purga con una clave privada respaldada por HSM no exportable para la Autoridad de Certificación. Soft Delete con protección contra purga asegura que ningún administrador malintencionado o cuenta de administrador comprometida pueda eliminar la clave privada de la CA: puede restaurarse en minutos para continuar con las operaciones normales y ni siquiera un Administrador Global puede purgarla antes de un periodo de 90 días. La clave de CA respaldada por HSM y no exportable asegura que incluso un atacante con los privilegios más altos no pueda robar la clave de la CA.

Minimizar la superficie de ataque

Nos aseguramos de exponer solo aquellas interfaces requeridas para las operaciones por parte del cliente. Si un endpoint SCEP no está configurado, las solicitudes SCEP ni siquiera se procesan.

Usando Endpoints privados, nos aseguramos de que dos servicios de los que depende SCEPman, Azure Key Vault y Azure Storage, no sean alcanzables a través de Internet.

Considerar casos de abuso

Cuando SCEPman recibe solicitudes de firma de certificados (CSRs) autorizadas, aún está sujeto a varias restricciones configurables. Por ejemplo, la duración nunca puede exceder el periodo máximo de validez configurado, incluso si esto fue solicitado.

Monitorizar y alertar sobre eventos de seguridad

Si SCEPman detecta eventos de seguridad, se registrarán como Warning o Error en los registros. La integración con Azure Monitor y Azure Event Hub facilita configurar alertas o analizar estos eventos de seguridad con un SIEM.

3. ¿Cómo aseguran su propio entorno de desarrollo?

Como parte de una empresa que también proporciona servicios CSOC y consultoría de seguridad, tenemos altos estándares de seguridad para nuestros dispositivos, procesos y concienciación de usuarios. Formamos parte de Microsoft MISA, estamos certificados ISO 27001 y somos Microsoft Partner of the Year con nuestras ofertas de Seguridad.

Nuestros repositorios de código fuente tienen reglas de protección de ramas y asignamos solo los principios mínimos necesarios a los repositorios y canalizaciones de despliegue a cuentas de desarrolladores individuales. Automatizamos pruebas y despliegues donde es posible para reducir la superficie de ataque por cuentas comprometidas.

4. ¿SCEPman forma parte de un programa de recompensas por errores (bug-bounty)?

No.

5. ¿Qué medidas de QA están implementadas?

• Proporcionamos SCEPman en un canal interno, beta y de producción

• Cada versión de producción debe pasar primero por los canales interno y beta, superando los obstáculos de QA relevantes como parte de nuestro proceso de CI

  • Pruebas unitarias

  • Revisión por pares

  • Pruebas de integración

  • Pruebas de estrés

  • Pruebas basadas en la experiencia

  • Análisis de código de terceros, por ejemplo Sonar, Dependabot y otros

6. ¿Realizan pruebas de penetración regularmente?

No.

Como parte de nuestras prácticas de desarrollo seguro, empleamos herramientas (por ejemplo análisis estático de código) que escanean la base de código en busca de CVEs y otros exploits comunes (incluyendo dependencias como bibliotecas de terceros) que podrían afectar la seguridad de los endpoints que SCEPman expone. Antes de cualquier lanzamiento, se evalúan y remedian los hallazgos relevantes para asegurar que SCEPman permanezca libre de vulnerabilidades conocidas. No realizamos pruebas de penetración nosotros mismos, ni usamos herramientas de terceros de "Penetration Test-as-a-Service". En cuanto a lo primero, vemos un conflicto de intereses inherente. En cuanto a lo segundo, dado que los servicios típicos de pruebas de penetración a menudo simplemente comprueban los endpoints expuestos contra CVEs y otros exploits conocidos, no vemos valor añadido frente a las comprobaciones que ya realizamos usando análisis estático de código. Si desea realizar sus propias pruebas de penetración, por favor contáctenos y cuéntenos sus requisitos.