# Seguridad y privacidad ## Procesamiento de datos y permisos ### 1. ¿Qué datos procesa SCEPman? SCEPman procesa certificados X.509 utilizando los protocolos SCEP y EST para la emisión y los protocolos OCSP y CRL para validar esos certificados. Cada **certificado de dispositivo** debe contener un identificador único del dispositivo. 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 de dispositivo SCEP, EST, OCSP y CRL dependen de 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 del navegador) Certificate Master mantiene un registro de auditoría de la actividad de los administradores (UPN). ### 2. ¿Qué datos se almacenan de forma 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 de la CA de SCEPman y el certificado, que se almacena de forma segura en Azure Key Vault. * Además, 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 una seguridad mejorada. 2. Certificados emitidos * Todos los certificados emitidos se almacenan en una cuenta de Azure Storage - *excluyendo las claves privadas*. * Para los datos que puedan formar parte de un certificado, consulte [pregunta 1](#id-1.-which-data-is-processed-by-scepman). * Este comportamiento puede [deshabilitarse](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/basics#appconfig-enablecertificatestorage). * Al emitir certificados mediante Certificate Master, se almacena el solicitante (UPN de Microsoft Entra ID (Azure AD)). * Al revocar certificados mediante Certificate Master, se almacena el estado de revocación del certificado y la identidad del usuario que lo revocó (UPN de Microsoft Entra ID (Azure AD)). 3. Registro Según la configuración de SCEPman del cliente, se puede activar el registro. Dependiendo de la configuración de verbosidad del registro del cliente, los registros pueden contener cualquier dato que SCEPman procese. El cliente configura la ubicación de almacenamiento de los registros. 4. Área de trabajo externa de Log Analytics SCEPman siempre envía una cantidad limitada de **no secretos** y **no personales** datos a nuestro espacio de trabajo de Log Analytics (LAW). Estos datos se utilizan para * fines de licencia. * Aseguramiento de la calidad (por ejemplo, supervisar excepciones a nivel global nos ayuda a reconocer rápida y ampliamente problemas generales y extendidos, lo que nos permite ofrecer soluciones rápidamente a nuestros clientes, evitando así costosas interrupciones del servicio). Por defecto, SCEPman **no envía ningún dato personal** a nuestro LAW. Según la configuración de registro, la depuración y otra información se reenvían al LAW de glueckkanja-gab AG. Nuestros ingenieros de soporte pueden solicitar [activar](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/basics#appconfig-remotedebug) la función de depuración remota desde el administrador del cliente para ayudar a resolver incidencias. En tales casos, la información sobre la solicitud de certificado puede enviarse a nuestra cuenta LAW, posiblemente (el cliente decide qué información forma parte del certificado) conteniendo datos personales como: * Nombre de usuario * Correo electrónico * Microsoft Entra ID (Azure AD) UPN * Identificador de dispositivo Borramos periódicamente **todos** datos registrados con un intervalo de * 30 días ### 3. ¿Dónde (geográficamente) procesa y almacena SCEPman los datos? Por diseño, SCEPman se realiza como una aplicación de Azure (basada en plantilla de solución), es decir, se implementa en el tenant de Azure del cliente. Como tal, la soberanía de los datos, incluida la elección de la ubicación geográfica del centro de datos de hospedaje, está en manos y preferencia del cliente. #### Área de trabajo externa de Log Analytics El LAW externo que utilizamos para recopilar (por defecto **no personales** y **no secretos**) información de telemetría con fines de cumplimiento de licencias está ubicado en **el centro de datos de Europa Occidental de Azure** . ### 4. ¿A qué permisos del tenant debe consentir el administrador? SCEPman aprovecha Managed Identities 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, donde esto último 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 proviene de 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 al utilizar la [función de revocación EndpointList](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-devicedirectory). 4. Microsoft Graph `IdentityRiskyUser.Read.All`:\ \ Este permiso permite a SCEPman [revocar automáticamente certificados de usuario si el riesgo del usuario de AAD supera un umbral configurado](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-userriskcheck). #### Jamf Pro 1. Permisos de lectura sobre usuarios, equipos y dispositivos\ \ Con estos permisos, SCEPman puede consultar Jamf Pro para comprobar si el certificado de usuario o dispositivo proviene de un usuario o dispositivo autorizado. #### Certificate Master 1. Microsoft Graph `User.Read` (a través de 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 de conexión accesibles externamente expone SCEPman? #### **Servicio principal de SCEPman** 1. Punto(s) de conexión SCEP * Invocado para solicitudes SCEP. * Según la configuración, SCEPman puede exponer varios puntos de conexión SCEP para Intune, Jamf Pro, DCs y otros MDM genéricos. 2. API REST de inscripción * Permite a Certificate Master solicitar certificados del servicio principal de SCEPman. * Permite a aplicaciones personalizadas solicitar certificados del servicio principal de SCEPman. 3. Punto de conexión EST * Invocado para solicitudes de reinscripción simple de EST. Puede habilitarse mediante configuración. * Invocado para solicitudes de inscripción simple de EST. 4. Punto de conexión 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 punto de conexión. * Puede habilitarse mediante [configuración](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/crl). 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 deshabilitarse mediante [configuración](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/basics#appconfig-anonymoushomepageaccess). 8. Punto de verificación de SCEPman * Comprobaciones de estado: comprobación integrada de estado 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 CSR. * Revocar manualmente certificados emitidos a través de Certificate Master. * Ver la lista de certificados emitidos manualmente. 2. Punto de verificación de Certificate Master * Comprobaciones de estado: comprobación integrada de estado de App Service ### 6. ¿Cómo están protegidos los puntos de conexión de la pregunta 5? #### Servicio principal de SCEPman 1. Punto(s) de conexión SCEP * Intune: Protegido mediante la API de desafío de Intune ([Microsoft Docs](https://docs.microsoft.com/en-us/mem/intune/protect/scep-libraries-apis)) * Jamf Pro, DCs, otros MDM genéricos: Protegidos con un desafío SCEP estático. Configurable por el cliente. Puede almacenarse en Azure Key Vault. 2. API REST de inscripción * Autenticación integrada de Microsoft Entra ID (Azure AD). 3. Punto de conexión EST * Reinscripción simple: Autenticación basada en certificado. * Inscripción simple: Autenticación integrada de Microsoft Entra ID (Azure AD). 4. Punto de conexión 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 deshabilitarse. 8. Punto de verificación 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](https://docs.scepman.com/es/configuracion-de-scepman/rbac). 2. Punto de verificación de Certificate Master * Sin protección. ### 7. ¿Qué puertos y protocolos utilizan los puntos de conexión de la pregunta 6? **Servicio principal de SCEPman** 1. Punto(s) de conexión SCEP * Intune: HTTPS (TCP / 443) * Jamf Pro, DCs, otros MDM genéricos: HTTPS (TCP / 443) 2. API REST de inscripción * HTTPS (TCP / 443) 3. Punto de conexión EST * HTTPS (TCP / 443) 4. Punto de conexión OCSP * HTTP (TCP / 80) 5. Punto de distribución de certificados (CDP) * HTTP (TCP / 80) 6. API de validación * No utilizado por servicios externos. 7. Página principal de SCEPman * HTTPS (TCP / 443) 8. Punto de verificación de SCEPman * HTTPS (TCP / 443) #### Certificate Master 1. Portal web de Certificate Master * HTTPS (TCP / 443) 2. Punto de verificación 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: los 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 AppService (cifrado BitLocker) * Cualquier dato de configuración (Azure Key Vault, App Services) solo puede ser accedido por usuarios autorizados con los permisos de Azure relevantes. #### Claves criptográficas * La clave privada de la CA se almacena de forma segura en Azure Key Vault ([HSM validado FIPS 140](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#compliance) por defecto). * La clave privada no se puede leer ni exportar. * La clave privada está protegida contra la eliminación por administradores maliciosos ([la protección contra purga y la eliminación temporal](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview) están habilitadas por defecto). * Azure Key Vault usa un punto de conexión privado y solo se puede acceder desde SCEPman (valor predeterminado para instalaciones de SCEPman versión 2.8 y superiores). #### Base de datos de certificados * La base de datos utiliza el servicio Table de una cuenta de Azure Storage. Por lo tanto, la protección depende de los mecanismos integrados en Azure. * En particular, Azure emplea acceso basado en roles para gestionar los permisos a los datos. * Azure Storage utiliza cifrado de base de datos y admite claves administradas por el cliente. * La cuenta de Azure Storage usa un punto de conexión privado y solo se puede acceder desde SCEPman (valor predeterminado 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 admite claves administradas por el cliente. ### 2. ¿Cómo se *los datos en tránsito* contra el acceso no autorizado? * SCEP: * Usa TLS por defecto (mínimo TLS 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 gallina y huevo. * Las respuestas OCSP están firmadas por el certificado de la CA. * API REST de inscripción y EST: * Impone TLS (mínimo TLS 1.2 - se aplican las políticas de Microsoft). * Portal web de Certificate Master: * Impone TLS (mínimo TLS 1.2 - se aplican las políticas de Microsoft). * Comunicación entre componentes de Azure de SCEPman: * TLS (mínimo TLS 1.2 - se aplican las políticas de Microsoft). ## Seguridad desde el 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 de seguridad externas reduciendo las interfaces externas al mínimo necesario. Además, se utilizan 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 dispositivos en Intune * Comprobación de dispositivos de Microsoft Entra ID (Azure AD) * Puntos de conexión privados Dado que SCEPman está construido sobre componentes de Azure, puede usar herramientas de Microsoft Defender (MD) for Cloud como MD for App Service, MD for Storage o MD for Key Vault. #### Validez del certificado Como 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 conceden acceso a otros recursos. Por ello, 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 también requiere un alto nivel de facilidad de uso, porque los procesos complicados y poco transparentes tienen una mayor superficie de ataque y un mayor potencial de error humano. Aunque SCEPman ofrece muchas opciones de configuración si es necesario, nos hemos esforzado por usar valores predeterminados razonables y seguros siempre que ha sido posible. Por lo tanto, si una clave privada se ve comprometida, SCEPman puede revocar el certificado correspondiente en tiempo real. Para los certificados inscritos a través de Intune y Jamf Pro, SCEPman hace esto automáticamente tan pronto como se toman contramedidas comunes no específicas de SCEPman contra el ataque. Solo tiene que [eliminar el Intune correspondiente](https://docs.scepman.com/es/configuracion-de-scepman/device-directories) o el objeto de Jamf Pro. Según los procesos de retirada de dispositivos, también puede configurar adicionalmente para [revocar certificados cuando se desencadena un borrado](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation#appconfigintunevalidationrevokecertificatesonwipe), cuando [Intune solicita la revocación](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation#appconfigintunevalidationdevicedirectory), dependiendo de [cumplimiento del dispositivo](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation#appconfigintunevalidationcompliancecheck) o [nivel de riesgo del usuario](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation#appconfigintunevalidationuserriskcheck)o puede revocar manualmente certificados individuales a través del componente Certificate Master. [Los certificados creados manualmente](https://docs.scepman.com/es/administracion-de-certificados/certificate-master) siempre requieren una revocación manual. ### 2. ¿Qué tecnologías, pilas y plataformas se utilizaron para diseñar SCEPman? * `C#` * `ASP.NET Core MVC` * `API criptográfica Bouncy Castle` * `Azure (App Service, Key Vault, Storage Account, Log Analytics)` ### 3. ¿Qué algoritmos criptográficos y tamaños de clave admite SCEPman? Para las claves de los certificados emitidos, Certificate Master no tiene restricciones cuando se usa el método CSR. Para los certificados basados en formularios, RSA con 2048 o 4096 bits son los algoritmos y tamaños de clave admitidos. Para los certificados inscritos con SCEP, Intune admite claves RSA de hasta 4096 bits en todas las plataformas, lo que SCEPman también admite. Cuando se usa el KSP de la plataforma (TPM), Windows admite como máximo claves RSA de 2048 bits. Cuando se usa el punto de conexión SCEP estático, se admiten todos los algoritmos y tamaños de clave comunes (en concreto, aquellos que [la biblioteca criptográfica Bouncy Castle para C# admite](https://www.bouncycastle.org/csharp/)). Para la clave de la CA, SCEPman solo admite RSA. RSA de 4096 bits es el tamaño de clave predeterminado. 4096 bits es actualmente el máximo admitido por Azure Key Vault. Si utiliza un certificado de CA intermedio, también puede usar cualquier tamaño de clave admitido por Key Vault, pero debe ser una clave RSA. Para escenarios que no requieren SCEP, se puede crear una CA ECC que admita las siguientes curvas elípticas: P-256, secp256k1/P-256K, P-384, P-521. ### 4. ¿Es única la CA creada por SCEPman? Sí Detalles: * SCEPman genera el par de claves público-privada 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 puede cambiar si lo desea. De forma predeterminada, solo su propia instancia de SCEPman y nadie más (tampoco ningún administrador) puede usar el certificado, pero un administrador de la suscripción puede conceder permisos adicionales. * Por lo tanto, otros clientes de SCEPman no podrán conectarse a su VPN, independientemente de cómo configuren su SCEPman. Si eligen el mismo nombre de organización, seguirán teniendo su propio par de claves y, por tanto, otro certificado de CA en el que su puerta de enlace VPN no confiará. ## Azure CIS Esta sección cubre las 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](https://www.cisecurity.org/benchmark/azure/). ### Cuentas de almacenamiento #### 1. ¿Se puede `Permitir acceso público a Blob` deshabilitar? *Sí*, de hecho, eso ya es el valor predeterminado para las nuevas instalaciones de SCEPman. ### App Services #### 2. TLS: ¿Se puede `Modo de certificado de cliente` establecer en `Requerir`? *No*, ya que esto rompería la funcionalidad de SCEPman. Esto se debe a que SCEPman inscribe certificados de cliente, por lo que los clientes aún no tienen certificados de cliente con los que autenticarse (problema de gallina y huevo). Sin embargo, eso no es un problema de seguridad, ya que el protocolo SCEP utiliza sus propios mecanismos de autenticación a través del desafío SCEP. Por lo tanto, SCEPman necesita una excepción a las políticas que imponen TLS mutuo. El `Modo de certificado de cliente` debe establecerse en `Ignorar` o `Opcional`. #### 3. ¿Se puede `versión HTTP` establecer en `2.0`? Aunque SCEPman debería funcionar con cualquiera de las versiones HTTP disponibles, a día de hoy solo admitimos la `HTTP 1.1` predeterminada \- principalmente debido a la falta de pruebas.\ \ Al cambiar esta configuración, bajo su propia responsabilidad, tenga en cuenta que no solo SCEPman debe admitir la versión HTTP más reciente. Los diferentes tipos de clientes también deben admitir esa versión de HTTP, es decir, los clientes SCEP integrados en el sistema operativo de Windows, macOS, iOS, iPadOS, los de dispositivos IoT, los clientes OCSP en las mismas plataformas, pero también los NAC de distintos proveedores. #### 4. ¿Se puede `HTTPS Only` habilitar? *No (no para SCEPman App Service)*, ya que esto romperá la funcionalidad del respondedor 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 utilizara TLS para la comprobación de revocación de certificados (descargar CRL u OCSP), podría producirse un problema de gallina y huevo, donde el cliente o dispositivo no puede establecer la conexión TLS con el punto de conexión OCSP porque primero debe verificarse el certificado del servidor a través de OCSP. Tampoco añade mucha seguridad, porque las respuestas OCSP ya están firmadas criptográficamente y, por tanto, no pueden ser falsificadas. Por ello, SCEPman necesita una excepción a las políticas que imponen TLS. **Nota:** **`HTTPS Only`** no puede habilitarse para el SCEPman App Service, pero debería habilitarse para el Certificate Master App Service. #### 5. ¿Se puede establecer la versión mínima de TLS de entrada en 1.3? *No* para el SCEPman App Service, ya que TLS 1.3 no admite la renegociación. Esto significa que una vez establecida una 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 mediante EST. Además, no todos los clientes SCEP admiten TLS 1.3. Un ejemplo importante es el cliente SCEP integrado en Windows 8, 10 y 11, que a fecha de 2025-07 no admite TLS 1.3 (habrá un [error durante la inscripción SCEP](https://docs.scepman.com/es/troubleshooting/general#some-windows-machines-do-not-enroll-or-renew-certificates)). **Nota:** Como solo los navegadores acceden al Certificate Master App Service, se recomienda que Certificate Master establezca la versión mínima de TLS de entrada en 1.3. ## RGPD y residencia de los datos ### 1. ¿Salen datos 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 una implementación completa de SCEPman, incluidos todos sus componentes, en centros de datos de Azure europeos. ### 2. ¿De qué proveedores de nube externos 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, Dublín,
Irlanda

| Vea [aquí](https://docs.scepman.com/es/implementacion-de-scepman/deployment-guides/enterprise-guide-1#overview-azure-resource). | | GitHub Inc (filial de Microsoft Corporation) | repositorio de código git, integración, pruebas y automatización de lanzamientos, almacenamiento |

88 Colin P Kelly Jr St,

San Francisco,

CA 94107,

Estados Unidos

| Repositorio de código, canalización CI/CD, almacenamiento binario | ## Prácticas de desarrollo seguro ### 1. ¿Qué garantiza que SCEPman sea software seguro? Nuestro desarrollo de software se basa en el [Ciclo de Vida de Desarrollo de Seguridad de Microsoft](https://www.microsoft.com/en-us/securityengineering/sdl/). 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 el desarrollo de nuestro producto.](https://www.glueckkanja.com/documents/general/gk-ISO27001Certificate-en.pdf) ### 2. ¿Cómo implementan las prácticas comunes de diseño seguro? Así es como implementamos [las prácticas de diseño seguro recomendadas por SDL](https://www.microsoft.com/en-us/securityengineering/sdl/practices/secure-by-design): #### Diseñar y modelar amenazas en equipo Nuestra práctica de modelado de amenazas se basa en las [recomendaciones del Tufts Security and Privacy Lab](https://tsp.cs.tufts.edu/tmnt/threatmodeling.html). Discutimos las decisiones de diseño y las amenazas potenciales STRIDE en un equipo heterogéneo de desarrolladores, nuestro [CSOC ](https://www.glueckkanja.com/en/security/cloud-security-operations-center/)y consultores PKI, y personal de soporte. #### Preferir la seguridad de la plataforma al código personalizado Cuando es posible, utilizamos funcionalidades de .NET o bibliotecas consolidadas, preferiblemente de código abierto, en lugar de reinventar la rueda. Por ejemplo, utilizamos Legion of the Bouncy Castle C# para trabajar con estándares de datos criptográficos. También dependemos de servicios de Azure como Key Vault para generar claves criptográficas, App Services para el alojamiento del servidor web, Azure Monitor para el registro y Azure Storage como motor de base de datos. #### La configuración segura es la predeterminada Para minimizar la posibilidad de error humano, diseñamos los productos de forma que tenga una configuración segura si utiliza los valores predeterminados. Por ejemplo, nuestras [plantillas ARM](https://github.com/scepman/install) y nuestro [proveedor de Terraform ](https://registry.terraform.io/modules/scepman/scepman/)establecen los valores de configuración para usar claves RSA de 4096 bits respaldadas por HSM, y deshabilitan todos los puntos de conexión de inscripción excepto Intune SCEP y Certificate Master (para los que debe asignar permisos explícitamente). #### Nunca confiar en datos del cliente Como software PKI, decidir qué datos son de confianza está en el centro de cada decisión. Después de todo, el propósito de los certificados y sus protocolos de inscripción es decidir qué datos son de confianza. #### Asumir brecha Nuestro registro basado en Azure Monitor permite la supervisión de las operaciones de SCEPman. Se integra fácilmente con sistemas SIEM como Sentinel para detectar atacantes exitosos, por ejemplo, si lograron 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 mínimo privilegio Nuestro modelo RBAC para Certificate Master permite asignar a los usuarios solo los permisos que realmente necesitan. SCEPman usa identidades administradas que solo tienen [los permisos necesarios para operar](#id-4.-which-tenant-permissions-does-the-admin-have-to-consent-to). #### Minimizar el radio de explosión Nos esforzamos por minimizar el daño posible en caso de un ataque exitoso. Por ejemplo, nuestra instalación predeterminada habilita la función de Azure Key Vault[ Soft Delete con Purge Protection](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview) con una [clave privada no exportable respaldada por HSM](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#hsm-protected-keys) para la Autoridad de Certificación. Soft Delete con Purge Protection garantiza que ningún administrador malicioso 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 período de 90 días. La clave de CA respaldada por HSM no exportable garantiza que incluso un atacante con los privilegios más altos posibles 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 punto de conexión SCEP no está configurado, ni siquiera se procesan solicitudes SCEP. Usando [Puntos de conexión privados](https://docs.scepman.com/es/configuracion-de-azure/private-endpoints), nos aseguramos de que dos servicios de los que depende SCEPman, Azure Key Vault y Azure Storage, no sean accesibles a través de Internet. #### Considerar casos de abuso Cuando SCEPman recibe una solicitud de firma de certificado autorizada (CSR), sigue estando sujeto a varias restricciones configurables. Por ejemplo, la duración nunca puede exceder el [período máximo de validez configurado](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/certificates#appconfig-validityperioddays), incluso si se hubiera solicitado así. #### Supervisar y alertar sobre eventos de seguridad Si SCEPman detecta eventos de seguridad, se registrarán como advertencia o error en los registros. La integración con Azure Monitor y Azure Event Hub facilita [configurar alertas](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview) 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 ofrece servicios CSOC y consultoría de seguridad, tenemos altos estándares de seguridad para nuestros dispositivos, procesos y concienciación de los usuarios. Formamos parte de Microsoft MISA, tenemos la certificación 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 de las cuentas individuales de desarrollador. Automatizamos las pruebas y los despliegues cuando es posible para reducir la superficie de ataque usando cuentas comprometidas. ### 4. ¿Forma SCEPman parte de un programa de recompensas por errores? 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 con regularidad? 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 CVE y otros exploits comunes (incluidas dependencias como bibliotecas de terceros) que podrían afectar la seguridad de los puntos de conexión que expone SCEPman. Antes de cualquier lanzamiento, cualquier hallazgo relevante se evalúa y corrige, para garantizar que SCEPman siga libre de vulnerabilidades conocidas. No realizamos pruebas de penetración nosotros mismos, ni utilizamos herramientas de terceros de "Penetration Test-as-a-Service". Para lo primero, vemos un conflicto de intereses inherente. Para lo segundo, dado que los servicios de pruebas de penetración típicos a menudo simplemente verifican los puntos de conexión expuestos frente a CVE y otros exploits conocidos, no vemos ningún valor añadido respecto a las comprobaciones que ya realizamos mediante análisis estático de código. Si desea realizar sus propias pruebas de penetración, por favor [póngase en contacto con nosotros](https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29) y cuéntenos sus requisitos.