> 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/otro/security-faq.md). # Seguridad y privacidad Este capítulo ofrece una visió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 mediante 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 almacenan 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 mayor seguridad. 2. Certificados emitidos * Todos los certificados emitidos se almacenan en un Storage Account de Azure - *excluyendo las claves privadas*. * Para los datos que puedan formar parte de un certificado, consulte [la pregunta 1](#id-1.-which-data-is-processed-by-scepman). * Este comportamiento puede [deshabilitarse](/es/configuracion-de-scepman/application-settings/basics.md#appconfig-enablecertificatestorage). * Al emitir certificados mediante Certificate Master, se almacena el solicitante (Microsoft Entra ID (Azure AD) UPN). * Al revocar certificados mediante 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 Según la configuración de SCEPman del cliente, el registro puede activarse. 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. External Log Analytics Workspace SCEPman siempre envía una cantidad limitada de **no secretos** y **no personales** de datos a nuestro Log Analytics Workspace (LAW). Estos datos se utilizan para * fines de licenciamiento. * Control de calidad (p. ej., supervisar excepciones globalmente nos ayuda a reconocer rápida y ampliamente problemas generales, lo que nos permite ofrecer soluciones a nuestros clientes con rapidez, evitando así 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 consultas de solución de problemas. En tales casos, la información sobre la solicitud de certificado puede enviarse a nuestra cuenta de 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 del dispositivo Eliminamos periódicamente **todos** los datos registrados cada * 30 días ### 3. ¿Dónde (geográficamente) procesa y almacena SCEPman los datos? Por diseño, SCEPman se implementa 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, incluida la elección de la geolocalización 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 para fines de cumplimiento de licencias se encuentra en **West Europe de Azure** centro de datos. ### 4. ¿A qué permisos del Tenant debe consentir el administrador? SCEPman aprovecha Managed Identities para implementar un modelo seguro de permisos en tu 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 este ú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 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 mediante Intune cuando se utiliza 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, equipos y dispositivos\ \ Con estos permisos, SCEPman puede consultar Jamf Pro para comprobar si el certificado de usuario o 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 mediante 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. endpoint(s) SCEP * Invocado para solicitudes SCEP. * Según la configuración, SCEPman puede exponer varios endpoints SCEP para Intune, Jamf Pro, DCs y otros MDM genéricos. 2. API REST de inscripción * Permite que Certificate Master solicite certificados del servicio principal de SCEPman. * Permite que las aplicaciones personalizadas soliciten certificados del servicio principal de SCEPman. 3. endpoint EST * Invocado para solicitudes de reinscripción simple EST. Puede habilitarse mediante configuración. * Invocado para solicitudes de inscripción simple EST. 4. endpoint 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 que Certificate Master evalúe 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](/es/configuracion-de-scepman/application-settings/basics.md#appconfig-anonymoushomepageaccess). 8. endpoint de sondeo 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 mediante Certificate Master. * Ver la lista de certificados emitidos manualmente. 2. endpoint de sondeo de Certificate Master * Comprobaciones de estado: comprobación de estado integrada de App Service ### 6. ¿Cómo están protegidos los puntos de conexión de la pregunta 5? #### Servicio principal de SCEPman 1. endpoint(s) 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. endpoint EST * Reinscripción simple: autenticación basada en certificados. * Inscripción simple: autenticación integrada de Microsoft Entra ID (Azure AD). 4. endpoint OCSP * No 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 se puede deshabilitar. 8. endpoint 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](/es/configuracion-de-scepman/rbac.md). 2. endpoint de sondeo de Certificate Master * Sin protección. ### 7. ¿Qué puertos y protocolos utilizan los endpoints de la pregunta 6? **Servicio principal de SCEPman** 1. endpoint(s) 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. endpoint EST * HTTPS (TCP / 443) 4. endpoint 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. endpoint de sondeo de SCEPman * HTTPS (TCP / 443) #### Certificate Master 1. Portal web de Certificate Master * HTTPS (TCP / 443) 2. endpoint de sondeo de Certificate Master * HTTPS (TCP / 443) ## Identidad ### 1. ¿Hay Conditional Access / controles de acceso basados en roles para proteger SCEPman? * Sí. Puede aprovecharse el conjunto completo de políticas RBAC de Microsoft Entra ID (Azure AD). ### 2. ¿Se pueden recuperar las credenciales de acceso? En caso afirmativo, ¿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 *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 AppService (cifrado BitLocker) * Solo los usuarios autorizados con los permisos de Azure pertinentes pueden acceder a cualquier dato de configuración (Azure Key Vault, App Services). #### 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) de forma predeterminada). * La clave privada no se puede leer ni exportar. * La clave privada está protegida contra la 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 endpoint privado y solo se puede acceder desde SCEPman (comportamiento predeterminado para instalaciones de SCEPman de la versión 2.8 y superiores). #### Base de datos de certificados * La base de datos utiliza el servicio Table de un Storage Account de Azure. Por lo tanto, la protección depende de los mecanismos integrados en Azure. * En particular, Azure emplea acceso basado en roles para administrar los permisos sobre los datos. * Azure Storage utiliza cifrado de base de datos y admite claves administradas por el cliente. * El Storage Account de Azure usa un endpoint privado y solo se puede acceder desde SCEPman (comportamiento predeterminado para instalaciones de SCEPman de la versión 2.8 y superiores). #### Registros * Los registros se almacenan en un espacio de trabajo de 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 para el certificado de la CA y se firman con el certificado del cliente. * Las respuestas SCEP se cifran para 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 componentes de Azure de SCEPman: * 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 registro de dispositivos en Intune * comprobación de dispositivos de Microsoft Entra ID (Azure AD) * Endpoints 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 conceden 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 es necesario, nos esforzamos por usar valores predeterminados razonables y seguros siempre que fue posible. Por lo tanto, si se compromete una clave privada, SCEPman puede revocar el certificado correspondiente en tiempo real. Para los certificados inscritos mediante Intune y Jamf Pro, SCEPman hace esto automáticamente en cuanto se toman contra el ataque las contramedidas comunes no específicas de SCEPman. Solo tiene que [eliminar el correspondiente objeto de Intune](/es/configuracion-de-scepman/device-directories.md) o de Jamf Pro. Según los procesos de retirada de dispositivos, además puede configurar para [revocar certificados cuando se desencadena 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), dependiendo 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. [Los certificados creados manualmente](/es/gestion-de-certificados/certificate-master.md) siempre requieren una revocación manual. ### 2. ¿Qué tecnologías, pilas, 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 admite SCEPman? Para las claves de los certificados emitidos, Certificate Master no tiene restricciones cuando se utiliza el método CSR. Para los certificados basados en formularios, RSA con 2048 o 4096 bits son los algoritmos y tamaños de clave compatibles. Para los certificados inscritos mediante SCEP, Intune admite claves RSA de hasta 4096 bits en todas las plataformas, lo que SCEPman también admite. Al usar el KSP de la plataforma (TPM), Windows admite como máximo claves RSA de 2048 bits. Al usar 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, se puede crear 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 para la CA raíz en Azure Key Vault de tu Tenant. Por lo tanto, la CA raíz es única para tu instancia personal de SCEPman y tienes control total sobre la CA, su certificado y la clave privada correspondiente. * El acceso a esta CA se controla mediante las directivas de acceso de Key Vault, que puedes cambiar si lo deseas. De forma predeterminada, solo tu 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 tu 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 tu VPN Gateway no confiará. ## Azure CIS Esta sección cubre las preguntas que surgen al definir políticas de ciberdefensa para tu 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/). ### Cuentas de almacenamiento #### 1. ¿Se puede `Permitir el acceso público a Blob` deshabilitar? *Sí*, que en realidad ya es el valor predeterminado para las nuevas instalaciones de SCEPman. ### App Services #### 2. TLS: ¿Puede `el modo de certificado de cliente` establecerse 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 del huevo y la gallina). Sin embargo, eso no es un problema de seguridad, ya que el protocolo SCEP utiliza sus propios mecanismos de autenticación mediante el desafío SCEP. Por lo tanto, SCEPman necesita una excepción a las políticas que aplican TLS mutuo. El `el modo de certificado de cliente` debe establecerse en `Ignorar` o `Opcional`. #### 3. ¿Puede la `versión HTTP` establecerse en `2.0`? Aunque SCEPman debería funcionar con cualquiera de las versiones HTTP disponibles, a día de hoy solo admitimos la versión 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 necesita admitir la versión HTTP más reciente. 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, iPadOS, los de dispositivos IoT, los clientes OCSP en las mismas plataformas, pero también los NAC de diferentes proveedores. #### 4. ¿Puede `Solo HTTPS` habilitarse? *No (no para el App Service de SCEPman)*, ya que esto romperá la funcionalidad de respondedor OCSP de SCEPman en combinación con muchos clientes OCSP y dispositivos de proveedores. OCSP es un protocolo que suele ofrecerse más comúnmente sobre HTTP que sobre HTTPS. Una de las razones es que, si se usara TLS para la comprobación de revocación de certificados (descarga de CRL u OCSP), podría producirse un problema del huevo y la gallina, en el que el cliente o el dispositivo no puede establecer la conexión TLS con el endpoint OCSP porque primero debe verificarse el certificado del servidor mediante OCSP. Tampoco añade mucha seguridad, porque las respuestas OCSP ya están firmadas criptográficamente y, por lo tanto, no pueden suplantarse. Por consiguiente, SCEPman necesita una excepción a las políticas que aplican 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 de TLS entrante en 1.3? *No* para el App Service de SCEPman, 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 algunas circunstancias (reinscripción simple EST), por lo que si establece TLS en 1.3, no podrá renovar sus certificados usando 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](/es/otro/troubleshooting/general.md#some-windows-machines-do-not-enroll-or-renew-certificates)). **Nota:** Como solo los navegadores acceden al App Service de Certificate Master, se recomienda que Certificate Master establezca la versión mínima de TLS entrante en 1.3. ## GDPR y residencia de los 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 SCEPman y sus componentes se desplegarán. * Es posible un despliegue completo de SCEPman, incluidos todos sus componentes, en centros de datos europeos de Azure. ### 2. ¿De qué proveedores de nube de terceros depende SCEPman y por qué? | Empresa | Servicios | Contacto | Finalidad | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Microsoft Corporation | Servicios en la nube (Azure) |

Building 3, Carmanhall Road Sandyford,
Industrial Estate 18, Dublin,
Ireland

| 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 un software seguro? Nuestro desarrollo de software se basa en el [Ciclo de vida del desarrollo de seguridad de Microsoft](https://www.microsoft.com/en-us/securityengineering/sdl/). El empleo de 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 nuestros productos.](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 el SDL](https://www.microsoft.com/en-us/securityengineering/sdl/practices/secure-by-design): #### Diseño y modelado de 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). Analizamos decisiones de diseño y posibles amenazas STRIDE en un equipo heterogéneo de desarrolladores, nuestros [CSOC ](https://www.glueckkanja.com/en/security/cloud-security-operations-center/)y consultores PKI, y el equipo de soporte. #### Prefiera la seguridad de la plataforma al código personalizado Siempre que es posible, usamos funcionalidad de .NET o bibliotecas consolidadas, 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 confiamos en servicios de Azure como Key Vault para generar claves criptográficas, App Services para el alojamiento de 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 el potencial de error humano, diseñamos los productos de forma que tenga una configuración segura si usa 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 configuraciones para usar claves RSA de 4096 bits respaldadas por HSM, y deshabilitan todos los endpoints de inscripción excepto Intune SCEP y Certificate Master (para los que debe asignar permisos explícitamente). #### Nunca confíe en los datos del cliente Como software PKI, decidir qué datos confiar es el núcleo mismo de cada decisión. Después de todo, el propósito de los certificados y sus protocolos de inscripción es decidir qué datos confiar. #### Asuma 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 exitosos, por ejemplo, si lograron inscribir certificados sin autorización. Nuestra integración con los servicios de Azure permite aprovechar los servicios Microsoft Defender for Cloud, por ejemplo, Defender for App Service. #### Hacer cumplir el mínimo privilegio El modelo RBAC de Certificate Master le permite asignar a los usuarios solo los permisos que necesitan. SCEPman usa identidades administradas que solo tienen [los permisos necesarios para la operación](#id-4.-which-tenant-permissions-does-the-admin-have-to-consent-to). #### Minimizar el radio de impacto Nos esforzamos por minimizar el daño posible en caso de un ataque exitoso. Por ejemplo, nuestra instalación predeterminada habilita el Key Vault[ la característica de 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 una 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 que transcurran 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 punto de conexión SCEP no está configurado, las solicitudes SCEP ni siquiera se procesan. Usando [Endpoints 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 autorizada de firma de certificado (CSR), sigue estando sujeta a varias restricciones configurables. Por ejemplo, la duración nunca puede superar el [período máximo de validez configurado](/es/configuracion-de-scepman/application-settings/certificates.md#appconfig-validityperioddays), incluso si esto fue solicitado. #### Supervisar y alertar sobre eventos de seguridad Cuando SCEPman detecta eventos de seguridad, los registra con nivel de Advertencia o Error. Las integraciones con Azure Monitor y Azure Event Hub le permiten [configurar alertas](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview) o analizar eventos con un SIEM. ### 3. ¿Cómo aseguran su propio entorno de desarrollo? Como parte de una empresa que también ofrece servicios de 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, contamos con 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 permisos mínimos necesarios a los repositorios y a las canalizaciones de implementación para cuentas individuales de desarrollador. Automatizamos las pruebas y los despliegues cuando es posible para reducir la superficie de ataque derivada 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 controles de QA pertinentes 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, p. ej., Sonar, Dependabot y otros ### 6. ¿Realizan pruebas de penetración con regularidad? No. Como parte de nuestras prácticas de desarrollo seguro, empleamos herramientas (p. ej., 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 endpoints que expone SCEPman. Antes de cualquier lanzamiento, cualquier hallazgo relevante se evalúa y se corrige para garantizar que SCEPman permanezca libre de vulnerabilidades conocidas. No realizamos pruebas de penetración nosotros mismos, ni utilizamos herramientas de terceros de tipo "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 puntos de conexión expuestos frente a CVE y otros exploits conocidos, no vemos ninguna ventaja frente 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 [contáctenos](https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29) y cuéntenos 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.scepman.com/es/otro/security-faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.