Saltar al contenido principal
Español (México)

La guía empresarial de SCEP: Implementación de Simple Certificate Enrollment Protocol para la seguridad automatizada de WiFi en campus

Esta guía de referencia técnica proporciona un diseño arquitectónico definitivo y una estrategia de implementación paso a paso para la implementación de certificados de WiFi empresariales mediante SCEP. Cubre las diferencias críticas entre SCEP y PKCS, la secuencia de implementación exacta requerida para el éxito y estrategias de mitigación de riesgos del mundo real para líderes de TI.

📖 6 min de lectura📝 1,270 palabras🔧 2 ejemplos resueltos❓ 3 preguntas de práctica📚 8 definiciones clave

Escucha esta guía

Ver transcripción del podcast
Good morning. If you're managing WiFi infrastructure across a hotel group, a retail estate, a stadium, or a university campus, this briefing is for you. We're going to cover SCEP - Simple Certificate Enrollment Protocol - and specifically how it solves one of the most persistent headaches in enterprise WiFi: getting certificates onto thousands of devices automatically, without your helpdesk drowning in tickets. [short pause] Let me set the scene. You've decided - correctly - that pre-shared keys are no longer acceptable for staff WiFi. A single compromised password exposes your entire network segment. You've moved, or you're moving, to 802.1X authentication. That's the IEEE standard that requires every device to prove its identity before it gets network access. The most secure flavour of 802.1X is EAP-TLS - Extensible Authentication Protocol with Transport Layer Security - which uses digital certificates rather than passwords. Certificates are cryptographically unique per device, they can't be shared, and they can be revoked instantly if a device is lost or an employee leaves. [short pause] So far, so good. The problem is distribution. How do you get a unique certificate onto every laptop, every phone, every tablet in your estate - across Windows, iOS, Android, macOS - without a technician touching each device? That's precisely what SCEP solves. [medium pause] SCEP was formalised by the Internet Engineering Task Force in RFC 8894 in 2020, though it's been in use in enterprise environments since the early 2000s. It's a protocol that lets a managed device request its own certificate directly from your Certificate Authority, using a pre-configured URL and a challenge password. The critical security point here: the private key is generated on the device itself, stored in the device's secure enclave - that's the TPM chip on Windows devices, or the Secure Enclave on Apple hardware - and it never travels across the network. The device generates a Certificate Signing Request, sends that to the SCEP gateway, the gateway validates the challenge, forwards the request to your Certificate Authority, the CA signs it, and the signed certificate comes back to the device. The whole process is invisible to the end user. [short pause] Now, in a Microsoft environment, the SCEP gateway is typically NDES - Network Device Enrollment Service - a Windows Server role that acts as the intermediary between your MDM platform and your CA. Microsoft Intune pushes the SCEP profile to managed devices, which tells them the NDES URL and the challenge password. Devices do the rest automatically. [medium pause] Let me walk you through what a real deployment looks like. Take a hotel group with 150 properties - think Premier Inn scale. They have a mix of Windows laptops for front-of-house staff, iOS devices for housekeeping supervisors, and Android tablets at the restaurant point-of-sale. Before SCEP, they were running WPA2-Personal with a shared password rotated quarterly. Every rotation generated a wave of helpdesk calls. With SCEP and Intune, they deploy three profiles in sequence. First, the Trusted Root Certificate profile - this tells every device to trust the company's Certificate Authority. Second, the SCEP Certificate profile - this instructs devices to go and collect their unique client certificate. Third, the WiFi profile - this configures the SSID, sets the security type to WPA2-Enterprise or WPA3-Enterprise, and points to the SCEP certificate for authentication. Deploy those three profiles to the same device group in Intune, and every managed device connects to the corporate SSID automatically, with a unique certificate, zero user interaction required. [short pause] The RADIUS server - typically Microsoft NPS or a cloud RADIUS service - receives the EAP-TLS authentication request, validates the certificate against the CA, checks the Certificate Revocation List, and grants or denies access. If an employee is terminated, you revoke their certificate in the CA. Their device loses WiFi access at the next authentication cycle. No password reset required. No waiting for a quarterly rotation. [medium pause] Now, people often ask about the difference between SCEP and PKCS - Public Key Cryptography Standards. Both work with Intune. The key difference is where the private key is generated. With SCEP, it's generated on the device. With PKCS, the CA generates both keys centrally and pushes the private key down to the device. That means the private key travels across the network, which introduces a theoretical interception risk. PKCS has its place - it's better suited for S/MIME email encryption where key escrow matters. For WiFi authentication, SCEP is the right choice. Every time. [short pause] Let me give you a second scenario - a retail estate. Imagine a fashion retailer with 200 stores across the UK, each running Cisco Meraki access points. Their point-of-sale systems are Windows-based, managed through Intune. They need PCI DSS compliance, which means network segmentation and strong authentication for any device handling cardholder data. SCEP-based EAP-TLS gives them device-level authentication on the staff SSID, with VLAN assignment driven by the RADIUS policy. The POS terminals land on the PCI-scoped VLAN automatically. Guest WiFi - handled separately through a platform like Purple - runs on a completely isolated SSID with its own authentication flow. The two networks never touch. Auditors are happy. The security team sleeps better. [medium pause] Right, let's talk about the pitfalls, because there are a few that catch teams out. [short pause] The most common failure mode is group targeting mismatches in Intune. Your Trusted Root profile, your SCEP profile, and your WiFi profile must all target the same Azure AD group. If the SCEP profile targets a User group and the WiFi profile targets a Device group, Intune can't resolve the dependency and the WiFi profile shows as an error. Check your assignments first - it's almost always the culprit. [short pause] Second pitfall: NDES server availability. Your NDES server needs to be reachable from the internet for remote devices to enrol before they arrive on-site. The secure way to do this is via Azure AD Application Proxy, which gives you remote access without opening inbound firewall ports. Don't expose NDES directly to the internet. [short pause] Third: CRL availability. Your RADIUS server checks the Certificate Revocation List every time a device authenticates. If the CRL Distribution Point is unreachable - maybe a server is down, or a firewall rule changed - authentication fails for everyone. Make your CRL endpoints highly available, and test them regularly. [short pause] Fourth: certificate template permissions. If your NDES connector service account doesn't have Read and Enroll permissions on the certificate template, devices get HTTP 403 errors when they try to collect their certificate. It's a simple permissions fix, but it's easy to miss during initial setup. [medium pause] Now for a rapid-fire round. [short pause] Can SCEP work with non-Microsoft MDMs? Yes - Jamf for Apple device fleets, VMware Workspace ONE, and most enterprise MDM platforms support SCEP profiles. The protocol is vendor-neutral. [short pause] Does SCEP work with cloud PKI? Yes. Microsoft's own cloud PKI in Intune Suite eliminates the need for an on-premises NDES server entirely. Third-party cloud PKI providers like SecureW2 and Keyfactor also offer cloud SCEP endpoints. [short pause] What about WPA3-Enterprise? WPA3-Enterprise uses the same 802.1X and EAP-TLS authentication stack. SCEP-issued certificates work identically. The upgrade is at the wireless protocol layer, not the certificate layer. [short pause] How long do certificates last? Typically one year, though you can configure shorter validity periods. Intune handles automatic renewal before expiry, so users never see an interruption. [medium pause] To summarise. SCEP automates certificate distribution at scale, eliminating the manual overhead of PKI deployment across large device fleets. The private key stays on the device - that's the security foundation of EAP-TLS. Deploy in sequence: Trusted Root first, SCEP profile second, WiFi profile third, all targeting the same group. Publish your NDES endpoint securely via Application Proxy. Keep your CRL endpoints highly available. And if you're starting fresh, evaluate cloud PKI to remove the on-premises NDES dependency entirely. [short pause] For guest WiFi - the separate, visitor-facing network - certificate-based authentication isn't the right model. Guests don't have managed devices. That's where a platform like Purple handles the authentication flow: captive portal, social login, email capture, or SMS verification, all feeding into a first-party data layer that your marketing team can actually use. The two approaches complement each other: SCEP for your managed staff estate, Purple for your guest network. Both running on the same hardware, cleanly segmented by VLAN. [short pause] That's your briefing on SCEP enterprise WiFi onboarding. The full written guide, with architecture diagrams, step-by-step Intune configuration, and worked examples, is available on the Purple website. Thanks for listening.

header_image.png

Resumen ejecutivo

Para los entornos empresariales, ya sea un sector de hospitalidad dinámico, una operación minorista de múltiples sedes o un campus corporativo moderno, depender de claves precompartidas o de Captive Portals básicos para el WiFi del personal representa una vulnerabilidad de seguridad y un cuello de botella operativo. La arquitectura de red moderna exige autenticación 802.1X mediante EAP-TLS, lo que garantiza que cada dispositivo se verifique criptográficamente antes de acceder a la red.

El desafío radica en la distribución: ¿cómo implementar certificados de cliente únicos en miles de dispositivos Windows, iOS y Android sin saturar a su mesa de ayuda con tickets de soporte? Microsoft Intune y otras plataformas MDM resuelven esto mediante la gestión automatizada del ciclo de vida de los certificados. Al implementar perfiles de Simple Certificate Enrollment Protocol (SCEP), los equipos de TI envían de forma silenciosa certificados raíz y de cliente de confianza a los endpoints gestionados.

Esta guía proporciona un diseño arquitectónico definitivo y una estrategia de implementación paso a paso para la implementación de certificados de WiFi empresariales. Exploramos las diferencias críticas entre SCEP y PKCS, detallamos la secuencia de implementación exacta requerida para el éxito y esbozamos estrategias de mitigación de riesgos del mundo real para garantizar que su WiFi para invitados y sus redes corporativas sigan siendo seguras y eficientes.

Escuche el resumen

Análisis técnico profundo: Arquitectura SCEP

Al diseñar su estrategia de implementación de certificados de WiFi empresariales, la primera decisión arquitectónica es seleccionar el mecanismo de entrega de certificados. Las plataformas de gestión de dispositivos móviles admiten tanto SCEP como PKCS, pero funcionan de manera fundamentalmente diferente.

Simple Certificate Enrollment Protocol (SCEP)

SCEP es el estándar de la industria para el registro de dispositivos empresariales. En un flujo de trabajo de SCEP, el servicio de gestión indica al endpoint que genere su propio par de claves pública y privada. El dispositivo crea una solicitud de firma de certificado (CSR) y la envía a través de un servidor del Servicio de registro de dispositivos de red (NDES) a su Autoridad de certificación (CA). La CA firma la solicitud y devuelve el certificado público al dispositivo.

La ventaja de seguridad crítica de SCEP es que la clave privada nunca sale del dispositivo. Se genera localmente, se almacena en el enclave seguro del dispositivo (como el TPM en Windows o el Secure Enclave en iOS) y nunca se transmite a través de la red. Esto hace que SCEP sea el enfoque altamente recomendado para la autenticación 802.1X.

scep_architecture_overview.png

Public Key Cryptography Standards (PKCS)

Por el contrario, con PKCS, la Autoridad de certificación genera tanto la clave pública como la privada de forma centralizada. El conector de certificados exporta de forma segura este par de claves y lo envía al dispositivo de destino.

Aunque PKCS elimina la necesidad de implementar y mantener un servidor NDES, lo que simplifica la infraestructura, introduce un riesgo de seguridad teórico porque la clave privada se transmite a través de la red. Por lo general, PKCS se adapta mejor a los casos de uso en los que se requiere el depósito de claves (key escrow), como el cifrado de correo electrónico S/MIME, en lugar de la autenticación de red.

scep_vs_pkcs_comparison.png

Guía de implementación: La secuencia de implementación

Configurar con éxito un perfil de WiFi gestionado para 802.1X requiere el cumplimiento estricto de una secuencia de implementación específica. Las dependencias del perfil dictan que se debe establecer la confianza antes de poder configurar la autenticación.

Paso 1: Implementar el perfil de certificado raíz de confianza

Antes de que cualquier dispositivo pueda solicitar un certificado de cliente o confiar en su servidor RADIUS, debe confiar en la Autoridad de certificación emisora.

  1. Exporte su certificado de CA raíz y cualquier certificado de CA intermedia como archivos .cer.
  2. En su consola de MDM, cree un nuevo perfil de configuración.
  3. Seleccione la plataforma de destino y elija el tipo de perfil de certificado de confianza.
  4. Suba el archivo .cer e implemente este perfil en sus grupos de dispositivos de destino.

Paso 2: Configurar el perfil de certificado SCEP

Una vez establecida la confianza, configure el perfil SCEP para indicar a los dispositivos cómo obtener su certificado de cliente.

  1. Cree un nuevo perfil de configuración y seleccione certificado SCEP.
  2. Configure el formato del nombre del sujeto. Para la autenticación basada en el usuario, CN={{UserPrincipalName}} es el estándar. Para la autenticación de dispositivos, use CN={{AAD_Device_ID}}.
  3. Establezca el uso de la clave para firma digital y cifrado de clave.
  4. En el uso extendido de la clave, especifique la autenticación del cliente (OID: 1.3.6.1.5.5.7.3.2).
  5. Vincule este perfil al perfil de certificado raíz de confianza creado en el Paso 1.
  6. Proporcione la URL externa de su puerta de enlace SCEP o servidor NDES.

Paso 3: Implementar el perfil de WiFi 802.1X

El paso final es enviar la configuración de WiFi que vincula los certificados al SSID de la red.

  1. Cree un perfil de configuración de WiFi.
  2. Ingrese el nombre de la red exactamente como lo transmiten sus puntos de acceso inalámbricos.
  3. Seleccione WPA2-Enterprise o WPA3-Enterprise como tipo de seguridad.
  4. Establezca el tipo de EAP en EAP-TLS.
  5. En la configuración de autenticacióngs, seleccione el perfil de certificado SCEP creado en el Paso 2 como el certificado de autenticación de cliente.
  6. Especifique el certificado raíz de confianza para la validación del servidor para garantizar que el dispositivo solo se conecte a su servidor RADIUS legítimo.

Mejores prácticas y estándares de la industria

Al implementar el despliegue de certificados SCEP, siga las siguientes mejores prácticas independientes del proveedor para garantizar el cumplimiento y la confiabilidad.

Ubicación y seguridad de la puerta de enlace SCEP

La puerta de enlace SCEP debe ser accesible desde internet para permitir que los dispositivos remotos aprovisionen certificados antes de llegar al sitio. Exponer un servidor interno directamente a internet representa un riesgo de seguridad significativo. Publique la URL de SCEP utilizando un proxy de aplicación o un proxy inverso. Esto proporciona un acceso remoto seguro sin abrir puertos de firewall entrantes y le permite aplicar políticas de acceso condicional al flujo de inscripción.

RADIUS y verificación de CRL

El despliegue de certificados es solo la mitad de la ecuación de seguridad; la revocación es igual de crítica. Si se rescinde el contrato de un empleado, deshabilitar su cuenta de directorio podría no revocar de inmediato su acceso a WiFi si su certificado de cliente sigue siendo válido y el servidor RADIUS no está verificando estrictamente la Lista de Revocación de Certificados (CRL).

Configure su servidor RADIUS para exigir una verificación estricta de CRL. Asegúrese de que sus puntos de distribución de CRL tengan una alta disponibilidad; si el servidor RADIUS no puede comunicarse con la CRL, la autenticación fallará, lo que provocará una interrupción generalizada.

Para consideraciones más amplias sobre la conectividad moderna, revise nuestra guía sobre Gestión de ancho de banda: una guía práctica para 2026 .

Resolución de problemas y mitigación de riesgos

Incluso con una planificación meticulosa, el despliegue de certificados puede presentar problemas. A continuación, se presentan los modos de falla comunes y las estrategias de mitigación.

El perfil de WiFi no se aplica

El dispositivo recibe los certificados SCEP y de raíz de confianza, pero el perfil de WiFi se muestra como un error o como no aplicable en la consola de MDM. Esto casi siempre se debe a una discrepancia en la asignación de grupos. Si el perfil SCEP está asignado a un grupo de usuarios, pero el perfil de WiFi está asignado a un grupo de dispositivos, el MDM no puede resolver la dependencia. Audite sus asignaciones. Asegúrese de que los perfiles de raíz de confianza, SCEP y WiFi estén desplegados exactamente en el mismo grupo.

Errores 403 Forbidden de la puerta de enlace

Los dispositivos no logran recuperar el certificado SCEP y los registros de la puerta de enlace muestran errores HTTP 403. La cuenta de servicio del conector carece de los permisos necesarios en la plantilla de certificado, o el filtrado de URL en su firewall está bloqueando los parámetros de cadena de consulta específicos utilizados por SCEP. Verifique que la cuenta del conector tenga permisos de lectura e inscripción en la plantilla de CA. Revise los registros del firewall para asegurarse de que no se estén bloqueando las URL que contienen ?operation=GetCACaps.

ROI e impacto comercial

La transición al despliegue de certificados 802.1X impulsado por SCEP ofrece retornos medibles en seguridad y operaciones.

  1. Reducción de tickets de soporte: El WiFi basado en contraseñas genera un volumen significativo de tickets de soporte relacionados con vencimientos de contraseñas, bloqueos de cuentas y errores de escritura. La autenticación basada en certificados es invisible para el usuario, lo que suele reducir el volumen de soporte relacionado con WiFi en un 70%.
  2. Postura de seguridad mejorada: EAP-TLS elimina el riesgo de robo de credenciales y ataques de intermediario (Man-in-the-Middle). Esto es fundamental para el cumplimiento de marcos como PCI DSS y GDPR, particularmente en entornos de Retail y Salud .
  3. Incorporación sin fricciones: Integrar el despliegue de certificados con los flujos de trabajo de MDM existentes garantiza una experiencia de aprovisionamiento unificada y "zero-touch" desde el primer día.

Mientras que SCEP protege sus dispositivos corporativos administrados, las redes de invitados y visitantes requieren un enfoque diferente. Para dispositivos no administrados, un Captive Portal con inicio de sesión de redes sociales o verificación por SMS alimenta una capa de datos de primera mano (first-party data), lo que le brinda información útil. Explore nuestra plataforma de WiFi Analytics para ver cómo estos datos impulsan los ingresos.

Definiciones clave

SCEP (Simple Certificate Enrollment Protocol)

A protocol that allows devices to request digital certificates from a Certificate Authority, where the private key is generated and stored securely on the device itself.

The recommended method for deploying WiFi authentication certificates due to its high security and scalability across enterprise fleets.

PKCS (Public Key Cryptography Standards)

A set of standards where both the public and private keys are generated by the Certificate Authority and then securely delivered to the endpoint.

Often used for S/MIME email encryption, but less ideal for WiFi authentication due to the network transmission of the private key.

NDES (Network Device Enrollment Service)

A Microsoft Windows Server role that acts as a bridge, allowing devices without domain credentials to obtain certificates via SCEP.

A required infrastructure component when implementing SCEP certificate deployment with on-premises Microsoft PKI.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

The most secure 802.1X authentication method, requiring both the server and the client to present valid digital certificates.

The target authentication protocol that MDM WiFi and certificate profiles are designed to enable, eliminating password-based access.

CRL (Certificate Revocation List)

A list published by the Certificate Authority containing the serial numbers of certificates that have been revoked before their scheduled expiration date.

RADIUS servers must check the CRL during authentication to ensure terminated employees cannot access the network using a previously valid certificate.

CSR (Certificate Signing Request)

A block of encoded text given to a Certificate Authority when applying for an SSL/TLS certificate, containing the public key and identity information.

Generated locally by the managed device during the SCEP flow to request its unique identity credential.

802.1X

An IEEE standard for port-based network access control that provides an authentication mechanism to devices wishing to attach to a LAN or WLAN.

The foundational framework that enforces the requirement for EAP-TLS certificate validation before granting network access.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralized authentication, authorization, and accounting management for users who connect and use a network service.

The server that evaluates the client certificate against the CA and CRL to make the final allow or deny decision for WiFi access.

Ejemplos resueltos

A 150-property hotel group needs to secure their staff network across a mix of Windows laptops for front-of-house, iOS devices for housekeeping, and Android tablets for restaurant point-of-sale. They currently use WPA2-Personal with a shared password rotated quarterly, generating massive helpdesk volume.

The hotel group deploys three Intune profiles in sequence to a unified device group. First, a Trusted Root Certificate profile establishes trust with the corporate CA. Second, a SCEP Certificate profile instructs devices to request a unique client certificate. Third, a WiFi profile configures the corporate SSID with WPA3-Enterprise and EAP-TLS, pointing to the SCEP certificate for authentication. The RADIUS server enforces strict CRL checking to revoke access instantly upon employee termination.

Comentario del examinador: This approach eliminates the quarterly password rotation overhead and secures the network against credential sharing. SCEP is chosen over PKCS to ensure the private key never leaves the individual devices, maintaining a zero-trust posture across diverse hardware.

A fashion retailer with 200 stores requires PCI DSS compliance for their Windows-based point-of-sale systems managed through Intune. They must ensure strong authentication and strict network segmentation for any device handling cardholder data.

The retailer implements SCEP-based EAP-TLS for device-level authentication on the staff SSID. The RADIUS policy drives VLAN assignment, placing authenticated POS terminals onto a strictly isolated, PCI-scoped VLAN automatically. Guest WiFi is handled on a completely separate SSID with its own captive portal authentication flow, ensuring the two networks never intersect.

Comentario del examinador: By tying network segmentation directly to certificate-based authentication, the retailer satisfies PCI DSS requirements without manual network configuration per store. The physical separation of the guest network using a platform like Purple prevents scope creep for the PCI audit.

Preguntas de práctica

Q1. Your Intune deployment shows the Trusted Root and SCEP profiles successfully applied to a user's laptop, but the WiFi profile shows an 'Error' state. The user cannot connect to the corporate SSID. What is the most likely architectural cause?

Sugerencia: Consider how MDM platforms resolve dependencies between related configuration profiles.

Ver respuesta modelo

A group targeting mismatch. The SCEP profile is likely assigned to a User group, while the WiFi profile is assigned to a Device group (or vice versa). Intune cannot resolve the dependency across different group types, causing the WiFi profile deployment to fail. Audit the assignments and ensure all three profiles target the exact same Azure AD group.

Q2. A newly acquired subsidiary requires 802.1X authentication for their staff devices. Their security team mandates that private keys must never traverse the network and must be generated within the hardware TPM of the endpoint. Which certificate deployment method must you use?

Sugerencia: Compare where the private key is generated in the SCEP workflow versus the PKCS workflow.

Ver respuesta modelo

You must use SCEP (Simple Certificate Enrollment Protocol). In a SCEP workflow, the device generates its own private and public key pair locally within its secure enclave (TPM) and only sends a Certificate Signing Request (CSR) across the network. PKCS generates the private key centrally on the CA and transmits it over the network, which violates the security team's mandate.

Q3. An employee is terminated and their Active Directory account is disabled. However, their laptop remains connected to the corporate WiFi network for several hours before losing access. How do you resolve this security gap?

Sugerencia: Disabling an account does not invalidate an existing certificate. What mechanism does the RADIUS server use to check certificate validity?

Ver respuesta modelo

You must configure the RADIUS server to enforce strict Certificate Revocation List (CRL) checking. When an employee is terminated, their certificate must be explicitly revoked in the Certificate Authority. The RADIUS server will then check the CRL during the next authentication cycle and immediately deny access, regardless of the Active Directory account status.

Continúe leyendo esta serie

¿Por qué no se conecta mi WiFi de invitados? Resolución de problemas de Captive Portal

Esta guía de referencia técnica autorizada explica la mecánica subyacente de la detección de Captive Portal y detalla los seis modos de falla principales que impiden que el WiFi de invitados se conecte. Proporciona a los gerentes de TI y arquitectos de red un marco de trabajo práctico para la resolución de problemas para resolver conflictos de redirección HTTP, DNS y desafíos de aleatorización de direcciones MAC.

Leer la guía →

Cómo implementar SCEP para la inscripción automatizada de certificados WiFi

Esta guía explica cómo implementar SCEP (Simple Certificate Enrollment Protocol) para la inscripción automatizada de certificados WiFi en entornos empresariales. Cubre el diseño arquitectónico completo, desde el diseño de PKI y la integración de MDM hasta la secuencia de implementación obligatoria de tres pasos, y muestra a los administradores de TI y arquitectos de red cómo eliminar las credenciales compartidas, automatizar la gestión del ciclo de vida de los certificados y cumplir con los requisitos de PCI DSS y GDPR a escala.

Leer la guía →

GDPR y Guest WiFi: Guía de cumplimiento para profesionales de marketing de recintos y TI

Esta guía proporciona a los gerentes de TI y operadores de recintos un marco práctico para garantizar que los servicios de Guest WiFi cumplan plenamente con el GDPR. Cubre la arquitectura técnica, la mecánica de consentimiento, la retención de datos y cómo transformar el cumplimiento en un activo seguro de datos de primera mano.

Leer la guía →