> 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/es/otros/security-faq.md). # Seguridad y privacidad Este capítulo proporciona una descripción general de las 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 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 del 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 del administrador (UPNs). ### 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 un Azure Storage Account - *excluyendo las claves privadas*. * En cuanto a los datos que podrían formar parte de un certificado, consulte la [pregunta 1](#id-1.-which-data-is-processed-by-scepman). * Este comportamiento puede ser [desactivado](/es/configuracion-de-scepman/application-settings/basics.md#appconfig-enablecertificatestorage). * Al emitir certificados a través de Certificate Master, se almacena el solicitante (UPN de Microsoft Entra ID (Azure AD)). * 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ó (UPN de Microsoft Entra ID (Azure AD)). 3. Registro Según la configuración de SCEPman del cliente, el registro puede activarse. Dependiendo de los ajustes de verbosidad de registro del cliente, los registros pueden contener cualquier dato que SCEPman procese. El cliente configura la ubicación de almacenamiento de los registros. 4. External Log Analytics Workspace SCEPman siempre envía una cantidad limitada de **no secretos** y **no personales** datos a nuestro Log Analytics Workspace (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, permitiéndonos ofrecer una solución a nuestros clientes con rapidez y, así, evitar costosas interrupciones del servicio). De forma predeterminada, 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](/es/configuracion-de-scepman/application-settings/basics.md#appconfig-remotedebug) la función de depuración remota desde el administrador del cliente para ayudar con las consultas de solución de problemas. En tales casos, la información sobre la solicitud de certificado puede enviarse a nuestra cuenta LAW, pudiendo contener (el cliente decide qué información forma parte del certificado) datos personales como: * Nombre de usuario * Correo electrónico * Microsoft Entra ID (Azure AD) UPN * Identificador del dispositivo Eliminamos periódicamente **todos** los datos registrados con un intervalo de * 30 días ### 3. ¿Dónde (geográficamente) procesa y almacena SCEPman los datos? Por diseño, SCEPman está realizado como una Azure App (basada en una plantilla de solución), es decir, se despliega 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 alojamiento, queda en manos y preferencia del cliente. #### External Log Analytics Workspace El LAW externo que utilizamos para recopilar (de forma predeterminada **no personales** y **no secretos**) información de telemetría con fines de aplicación de licencias se encuentra en **el centro de datos de Europa Occidental de Azure** . ### 4. ¿Qué permisos del tenant debe consentir 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 proviene de 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 de dispositivo procede 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 usar la [función de revocación EndpointList](/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation.md#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](/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-userriskcheck). #### 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 de dispositivo procede de un usuario o dispositivo autorizado. #### Certificate Master 1. Microsoft Graph `User.Read` (mediante App Registration):\ \ Con este permiso, Certificate Master determina quién solicita o revoca manualmente un certificado. 2. Microsoft Graph `DeviceManagementManagedDevices.Read.All` y `DeviceManagementConfiguration.Read.All` (como Managed Identity):\ \ 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é endpoints accesibles externamente expone SCEPman? #### **Servicio central 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, MDMs genéricos y otros. 2. API REST de inscripción * Permite a Certificate Master solicitar certificados al servicio central de SCEPman. * Permite que aplicaciones personalizadas soliciten certificados al servicio central de SCEPman. 3. Punto de conexión EST * Invocado para solicitudes de reinscripción simple EST. Puede habilitarse mediante configuración. * Invocado para solicitudes de inscripción simple 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 endpoint. * Puede habilitarse mediante [configuración](/es/configuracion-de-scepman/application-settings/crl.md). 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](/es/configuracion-de-scepman/application-settings/basics.md#appconfig-anonymoushomepageaccess). 8. punto de verificación de SCEPman * Comprobaciones de estado: comprobación de estado integrada 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 de estado integrada de App Service ### 6. ¿Cómo están protegidos los endpoints de 5.? #### Servicio central 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, MDMs genéricos y otros: 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 requiere protección. 5. Punto de distribución de certificados (CDP) * Se requiere un 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 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](/es/configuracion-de-scepman/rbac.md). 2. punto de verificación de Certificate Master * Sin protección. ### 7. ¿Qué puertos y protocolos utilizan los endpoints de la pregunta 6? **Servicio central de SCEPman** 1. Punto(s) de conexión SCEP * Intune: HTTPS (TCP / 443) * Jamf Pro, DCs, MDMs genéricos y otros: 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 / controles de acceso basados en roles para proteger SCEPman? * Sí. Puede aprovecharse el conjunto completo de directivas RBAC de Microsoft Entra ID (Azure AD). ### 2. ¿Se pueden recuperar credenciales de acceso? En caso afirmativo, ¿cómo? * Credenciales de inicio de sesión: depende de las directivas de Microsoft Entra ID (Azure AD) configuradas 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 *datos en reposo* protegen 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 de Azure pertinentes. #### Claves criptográficas * La clave privada de la CA se almacena de forma segura en Azure Key Vault ([HSM validado por FIPS 140](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#compliance) de forma predeterminada). * La clave privada no se puede leer ni exportar. * La clave privada está protegida contra su eliminación por administradores malintencionados ([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 de forma predeterminada). * Azure Key Vault usa un punto de conexión privado y solo puede accederse a él desde SCEPman (predeterminado para instalaciones de SCEPman de la versión 2.8 y superiores). #### Base de datos de certificados * La base de datos usa el servicio Table de un Azure Storage Account. Por tanto, la protección se basa en los mecanismos integrados en Azure. * En particular, Azure emplea acceso basado en roles para gestionar los permisos a los datos. * Azure Storage usa cifrado de base de datos y admite claves administradas por el cliente. * El Azure Storage Account usa un punto de conexión privado y solo puede accederse a él desde SCEPman (predeterminado para instalaciones de SCEPman de la versión 2.8 y superiores). #### Registros * Los registros se almacenan en un Log Analytics Workspace. * Log Analytics usa cifrado de base de datos y admite claves administradas por el cliente. ### 2. ¿Cómo se *datos en tránsito* protegen contra el acceso no autorizado? * SCEP: * Usa TLS de forma predeterminada (mínimo TLS 1.2: se aplican las políticas de Microsoft). * Las solicitudes SCEP se cifran con el certificado de la CA y se firman con el certificado del cliente. * Las respuestas SCEP se cifran con el certificado del cliente y se firman con el certificado de la CA. * OCSP: * Las solicitudes OCSP no deben cifrarse para evitar problemas del huevo y la gallina. * 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 los componentes de SCEPman en Azure: * TLS (mínimo TLS 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 de seguridad externas reduciendo las interfaces externas al mínimo necesario. Además de esto, se utilizan las siguientes tecnologías para reconocer y mitigar amenazas internas y externas en diferentes capas: * Key Vault * App Insights * Verificación del alta de dispositivos en Intune * Comprobación de dispositivos de Microsoft Entra ID (Azure AD) * Puntos de conexión privados Dado que SCEPman se basa en 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 otorgan acceso a otros recursos. Por lo tanto, 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 comodidad para el usuario, 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 son necesarias, nos esforzamos por usar valores predeterminados razonables y seguros siempre que fue posible. Por lo tanto, si una clave privada se ve comprometida, SCEPman puede revocar el certificado correspondiente en tiempo real. Para los certificados inscritos mediante Intune y Jamf Pro, SCEPman hace esto automáticamente tan pronto como se toman contra el ataque contramedidas comunes no específicas de SCEPman. Solo tiene que [eliminar el objeto correspondiente de Intune](/es/configuracion-de-scepman/device-directories.md) o de Jamf Pro. Dependiendo de sus procesos de retirada de dispositivos, además puede configurar para [revocar certificados cuando se activa un borrado](/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationrevokecertificatesonwipe), cuando [Intune solicita la revocación](/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationdevicedirectory), en función de [la conformidad del dispositivo](/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationcompliancecheck) o [el nivel de riesgo del usuario](/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationuserriskcheck), o puede revocar manualmente certificados individuales mediante el componente Certificate Master. [Certificados creados manualmente](/es/administracion-de-certificados/certificate-master.md) siempre requieren una revocación manual. ### 2. ¿Qué tecnologías, pilas y plataformas se utilizaron 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 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 endpoint SCEP estático, se admiten todos los algoritmos y tamaños de clave comunes (específicamente 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 usa un certificado de CA intermedia, 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, puede crearse una CA ECC, compatible con 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 pública y privada de la CA raíz en Azure Key Vault de su tenant. Por lo tanto, la CA raíz es exclusiva de 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 directivas de acceso de Key Vault que usted 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, sin importar 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 VPN Gateway no confiará. ## CIS de Azure 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 mejores prácticas como el [CIS Microsoft Azure Foundations Benchmark](https://www.cisecurity.org/benchmark/azure/). ### Storage Accounts #### 1. ¿Se puede `Permitir acceso público a Blob` desactivar? *Sí*, de hecho, ese 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 eso 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 del huevo y la gallina). 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 excepción de las directivas 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 predeterminada `HTTP 1.1` —principalmente por falta de pruebas. Al cambiar esta configuración —bajo su propia responsabilidad— tenga en cuenta que no solo SCEPman debe admitir la nueva versión HTTP. Los distintos 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 e iPadOS, los de dispositivos IoT, los clientes OCSP en las mismas plataformas, pero también los NAC de distintos proveedores. #### 4. ¿Se puede `Solo HTTPS` 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 appliances de proveedores. OCSP es un protocolo que normalmente se proporciona más a menudo por HTTP que por HTTPS. Una de las razones es que, si usara TLS para la comprobación de revocación de certificados (descargando CRL u OCSP), podría producirse un problema del huevo y la gallina, en el que el cliente o appliance no pudiera establecer la conexión TLS con el endpoint OCSP porque primero hay que verificar el certificado del servidor mediante OCSP. Además, esto no añade mucha seguridad, porque las respuestas OCSP ya van firmadas criptográficamente y, por tanto, no pueden suplantarse. Por lo tanto, SCEPman necesita una excepción de las directivas que imponen TLS. **Nota:** **`Solo HTTPS`** no puede habilitarse para SCEPman App Service, pero debería habilitarse para Certificate Master App Service. #### 5. ¿Se puede establecer la versión mínima de TLS de entrada en 1.3? *No* para SCEPman App Service, ya que TLS 1.3 no admite 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 determinadas circunstancias (reinscripción simple de 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 del lado del cliente durante la inscripción SCEP](/es/otros/troubleshooting/general.md#some-windows-machines-do-not-enroll-or-renew-certificates)). **Nota:** Como solo los navegadores acceden al SCEPman App Service, se recomienda que Certificate Master establezca la versión mínima de TLS de entrada en 1.3. ## Cumplimiento ### 1. ¿glueckkanja tiene la certificación ISO 27001? Sí. El Sistema de Gestión de la Seguridad de la Información (SGSI) de glueckkanja AG está certificado según **ISO/IEC 27001:2022**. El alcance de la certificación cubre: * Desarrollo de productos * Servicios gestionados Puede ver el certificado actual [aquí](https://www.glueckkanja.com/documents/general/gk-ISO27001Certificate-en.pdf). ### 2. ¿glueckkanja somete su seguridad a pruebas por expertos externos? Sí. En 2026, glueckkanja AG encargó a una empresa independiente y especializada en seguridad ofensiva que realizara una evaluación Red Team que abarcó toda nuestra empresa. Elegimos deliberadamente este enfoque holístico en lugar de una prueba de penetración clásica. En lugar de comprobar sistemas o endpoints individuales frente a vulnerabilidades conocidas, el Red Team simuló un ciberataque avanzado y realista de un atacante interno contra nuestra infraestructura de TI, encadenando técnicas de la misma manera que lo harían adversarios reales. La evaluación se centró en: * identificar vulnerabilidades de alto impacto, * mapear rutas de ataque completas a través de nuestro entorno, * evaluar posibles vectores para obtener acceso no autorizado a entornos de clientes, * evaluar posibles vectores para ejecutar ataques a la cadena de suministro. Todos los hallazgos se documentaron junto con recomendaciones de mitigación y se abordan como parte de nuestro Sistema de Gestión de la Seguridad de la Información certificado ISO 27001. Repetiremos esta evaluación Red Team anualmente. ## 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 deben desplegarse SCEPman y sus componentes. * Es posible un despliegue completo de SCEPman, incluidos todos sus componentes, en centros de datos de Azure europeos. ### 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, Dublín,
Irlanda

| Ver [aquí](/es/despliegue-de-scepman/deployment-guides/enterprise-guide-1.md#overview-azure-resource). | | GitHub Inc (subsidiaria 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 [Microsoft Security Development Lifecycle](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 [2. ¿Cómo implementan las prácticas comunes de diseño seguro?](#id-1.-is-glueckkanja-iso-27001-certified). ### Así es como implementamos las Prácticas de diseño seguro recomendadas por el SDL [Diseño y modelo de amenazas en equipo](https://www.microsoft.com/en-us/securityengineering/sdl/practices/secure-by-design): #### Diseño y modelado de amenazas como equipo Nuestra práctica de modelado de amenazas se basa en el [recomendaciones del Tufts Security and Privacy Lab](https://tsp.cs.tufts.edu/tmnt/threatmodeling.html). Hablamos de decisiones de diseño y amenazas potenciales STRIDE en un equipo heterogéneo de desarrolladores, nuestro [CSOC ](https://www.glueckkanja.com/en/security/cloud-security-operations-center/)y consultores de PKI, y el equipo de soporte. #### Preferir la seguridad de la plataforma frente al código personalizado Cuando es posible, usamos funcionalidad de .NET o bibliotecas establecidas, preferiblemente de código abierto, 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 dependemos de servicios de Azure como Key Vault para generar claves criptográficas, App Services para alojar servidores 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 tengas una configuración segura si usas los valores predeterminados. Por ejemplo, nuestras [plantillas de ARM](https://github.com/scepman/install) y nuestro [proveedor de Terraform ](https://registry.terraform.io/modules/scepman/scepman/)establecen ajustes de configuración para usar claves RSA respaldadas por HSM de 4096 bits, y deshabilitan todos los puntos de conexión de inscripción excepto Intune SCEP y Certificate Master (para los que debes asignar permisos explícitamente). #### Nunca confíes en los datos del cliente Como software de PKI, decidir en qué datos confiar está en el centro mismo de cada decisión. Después de todo, el propósito de los certificados y sus protocolos de inscripción es decidir en qué datos confiar. #### Asumir una 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 que hayan tenido éxito, por ejemplo, si consiguieron inscribir certificados sin autorización. Nuestra integración con Azure Services permite aprovechar los servicios Microsoft Defender for Cloud, por ejemplo, Defender for App Service. #### Aplicar el mínimo privilegio El modelo RBAC de Certificate Master te permite asignar a los usuarios solo los permisos que necesitan. SCEPman utiliza identidades administradas que solo tienen [los permisos necesarios para su funcionamiento](#id-4.-which-tenant-permissions-does-the-admin-have-to-consent-to). #### Minimizar el radio de impacto Nos esforzamos por minimizar el posible daño en caso de un ataque exitoso. Por ejemplo, nuestra instalación predeterminada habilita la característica Soft Delete de Key Vault con Purge Protection[ la característica 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 deshonesto ni ninguna cuenta de administrador comprometida pueda eliminar la clave privada de la CA. La clave privada 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 no exportable respaldada por HSM 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 endpoint SCEP no está configurado, las solicitudes SCEP ni siquiera se procesan. Usando [Puntos de conexión privados](/es/configuracion-de-azure/private-endpoints.md), 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 (CSR) autorizada, sigue estando sujeta a varias restricciones configurables. Por ejemplo, la vigencia nunca puede superar el [período máximo de validez configurado](/es/configuracion-de-scepman/application-settings/certificates.md#appconfig-validityperioddays), incluso si esto se solicitó. #### Supervisar y alertar sobre eventos de seguridad Cuando SCEPman detecta eventos de seguridad, los registra con nivel Warning o Error. Las integraciones de Azure Monitor y Azure Event Hub te permiten [configurar alertas](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview) o analizar eventos con un SIEM. ### 3. ¿Cómo protegen 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, estamos certificados segú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ínimamente necesarios a los repositorios y las canalizaciones de implementación a cuentas de desarrollador individuales. Automatizamos las pruebas y las implementaciones cuando es posible para reducir la superficie de ataque de cuentas comprometidas. ### 4. ¿SCEPman forma parte de un programa de recompensas por errores? No. ### 5. ¿Qué medidas de QA están implementadas? * Ofrecemos 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 hitos 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 en forma de una prueba de penetración clásica de SCEPman. En su lugar, glueckkanja AG se somete a una evaluación anual de Red Team por parte de un especialista externo independiente, que va más allá de una prueba de penetración clásica (véase [¿glueckkanja somete su seguridad a pruebas por expertos externos?](#id-2.-does-glueckkanja-have-its-security-tested-by-external-experts)). Como parte de nuestras Prácticas de Desarrollo Seguro, empleamos herramientas (por ejemplo, análisis estático de código) que examinan 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 endpoints que SCEPman expone. Antes de cada 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 usamos herramientas de terceros de tipo "Penetration Test-as-a-Service". En el primer caso, vemos un conflicto de intereses inherente. En el segundo, dado que los servicios típicos de pruebas de penetración a menudo simplemente comprueban los endpoints expuestos frente a CVE y otros exploits conocidos, no vemos ninguna ventaja sobre las comprobaciones que ya realizamos usando análisis estático de código. En su lugar, confiamos en un enfoque holístico: En 2026, un Red Team independiente simuló un ataque realista y avanzado contra glueckkanja AG, incluyendo explícitamente rutas de ataque hacia entornos de clientes y ataques a la cadena de suministro. En lugar de probar endpoints aislados, esta evaluación analiza rutas de ataque completas a lo largo de nuestra organización, lo que consideramos mucho más significativo para la seguridad de nuestros clientes. Repetimos esta evaluación anualmente. Si desea realizar sus propias pruebas de penetración, por favor [contáctenos](https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29) y díganos cuáles son sus 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/es/otros/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.