Guía ampliada

Solo para SCEPman Enterprise Edition

Esto le guiará a través de todos los pasos para implementar SCEPman en un entorno de nivel empresarial con requisitos avanzados, por ejemplo, convenciones de nomenclatura, redundancia o autoescalado.

Implementación en Azure

Comencemos con los requisitos y una vista general de los recursos. Tenga en cuenta que debe planificar un diseño útil de recursos de Azure.

Requisitos previos

Obligatorio

• Convención de nomenclatura de recursos de Azure.

• Suscripción de Azure (al menos permisos de Colaborador en esa suscripción).

• Permisos de propietario de Azure (al menos a nivel de grupo de recursos).

• Microsoft Entra ID (Azure AD) "Administrador global" (consentimiento para acceder a Graph API).

• Asegúrese de definir sus directivas de Azure según los requisitos de SCEPman (por ejemplo, no aplicar TLS).

• CNAME de dominio público (scepman.sudominio.com), solo si se utiliza geo-redundancia.

• Certificado SSL (o use Certificado administrado de App Service), solo si se utiliza geo-redundancia.

• Clave de licencia de SCEPman Enterprise Edition.

Opcional

• CNAME de dominio público (scepman.sudominio.com), solo si se utiliza un dominio personalizado.

• Certificado SSL (comodín) (o use Certificado administrado de App Service), solo si se utiliza un dominio personalizado.

Vista general de recursos de Azure

Se recomiendan los siguientes recursos para un entorno de producción.

Además, si está utilizando puntos de conexión privados, tiene siete recursos adicionales de Azure.

Pasos de configuración

1

Implementar los servicios base de SCEPman

Este es un paso obligatorio .

Decida si desea implementar con un Plan de App Service de Windows o Linux . Ambos métodos de implementación le permitirán elegir su sistema operativo.

Para comenzar con la implementación, debe seguir nuestras instrucciones de configuración utilizando una plantilla ARM

Implementación empresarial

o, alternativamente, nuestro script de Terraform :

Implementación con Terraform

2

Realizar pasos posteriores a la implementación (asignaciones de permisos)

Este es un paso obligatorio .

Para vincular correctamente todos los componentes de SCEPman, deben asignarse varios permisos. Siga estos pasos para establecer las conexiones correspondientes:

Identidades administradas

3

Agregar permisos del Certificate Master

Este es un paso obligatorio paso para clientes de la edición Enterprise . Los usuarios de Community Edition pueden omitir este paso.

Certificate Master es una funcionalidad de la edición Enterprise Edition que permite a los administradores generar y revocar certificados manualmente. Siga estos pasos para proporcionar acceso a Certificate Master.

RBAC de Certificate Master

4

Crear el certificado raíz

Este es un paso obligatorio .

Después de completar la implementación y la asignación de permisos, debe crear el certificado raíz para SCEPman:

CA raíz

5

Configurar un dominio personalizado y un certificado SSL

Este es un paso recomendado paso. Sin embargo, omita este paso si está implementando geo-redundancia.

Para tener SCEPman disponible bajo su dominio específico, debe crear un dominio personalizado en el App Service.

Dominio personalizado

6

Actualizaciones manuales

Este es un paso opcional .

Por defecto, SCEPman adopta un enfoque siempre actualizado para las actualizaciones. En caso de que necesite control total sobre las actualizaciones de SCEPman, configure un slot de implementación como se describe en la siguiente guía, en la sección Configuración del slot de implementación.

Estrategia de actualización

7

Implementar Application Insights

Este es recomendado .

Application Insights se puede usar para obtener una vista general del rendimiento de App Service y obtener información más profunda del procesamiento de solicitudes de SCEPman. Recomendamos configurar siempre Application Insights para supervisar, mantener y optimizar App Service.

Application Insights

8

Configurar la comprobación de estado

Este es recomendado .

Las comprobaciones de estado se pueden configurar para notificar a los administradores en caso de que el App Service de SCEPman no responda.

Comprobación de estado

9

Asegúrese de que SCEPman tenga recursos suficientes

Este es un paso obligatorio .

Una vez que traslade SCEPman a un entorno de producción, debe asegurarse de que SCEPman disponga de suficiente capacidad de procesamiento. Por lo tanto, revise nuestra guía de dimensionamiento de Azure y actualice el nivel de su Plan de App Service si es necesario. Puede posponer esto hasta después de su PoC o fase de prueba.

Dimensionamiento de App Service

10

Configurar el autoescalado

Este es un paso opcional .

La solución SCEPman tiene dos tareas distintas y diferentes requisitos de rendimiento. Una tarea es el proceso de emisión de certificados: después de la configuración de la solución SCEPman necesitamos implementar certificados en todos los dispositivos (certificados de usuario y/o de dispositivo), pero esta es una tarea única y, después de la implementación inicial, solo ocurre cuando se registra un nuevo dispositivo o cuando los certificados deben renovarse. En esas situaciones, SCEPman se enfrentará a un pico de solicitudes SCEP.

La segunda tarea es la validación de certificados: después de haber implementado certificados en los dispositivos, esos certificados deben validarse cada vez que los usamos. Para cada autenticación basada en certificados, los clientes, las pasarelas o el sistema RADIUS (depende de lo que utilice) enviarán una solicitud OCSP al App Service de SCEPman. Esto provocará una carga permanente de solicitudes en App Service.

Para tener un rendimiento optimizado y controlar los costes, recomendamos configurar la funcionalidad de autoescalado de App Service. Con esta característica, su aplicación puede escalar horizontalmente y reducirse según las métricas.

Autescalado

11

Configurar geo-redundancia

Este es un paso opcional .

Configurar una instancia geo-redundante para SCEPman puede mejorar la disponibilidad y la resiliencia del servicio al distribuir las cargas de trabajo entre varias regiones de Azure.

Sin embargo, es importante tener en cuenta que esta configuración puede dar lugar a mayores costes de Azure debido a los recursos adicionales y a la replicación de datos implicados. Microsoft proporciona un SLA del 99,95 % para Azure App Services, lo cual es adecuado en la mayoría de los escenarios.

Geo-redundancia

12

Configurar sus perfiles de implementación de MDM

Este es un paso recomendado .

Una vez completados los pasos anteriores, tenemos una implementación funcional de SCEPman y ahora podemos desplegar certificados en los dispositivos.

Utilice uno (o más) de los siguientes artículos para desplegar certificados con su solución MDM preferida:

Microsoft IntuneJamf ProOtras soluciones MDM

13

Emitir certificados manualmente o firmar CSR usando el Certificate Master

Este es un paso opcional .

Siga el enlace a continuación para aprender cómo emitir certificados TLS de servidor basados en una lista de FQDN o firmar cualquier CSR usando el componente Certificate Master.

Certificate Master

14

Emitir certificados usando la API REST de inscripción

Este es un paso opcional .

SCEPman incluye una API REST para inscribir certificados. Esta es una alternativa a los endpoints SCEP que requieren el estilo de autenticación SCEP, mientras que la API REST usa identidades de Microsoft para autenticación. El protocolo también es mucho más simple que SCEP.

API REST de inscripción

15

Crear bloqueos en los recursos de Azure de SCEPman

Este es un paso opcional .

De forma predeterminada, SCEPman no aplica bloqueos a los recursos de Azure. Si usa bloqueos de recursos y desea configurarlos, la siguiente lista describe qué tipos de bloqueo se pueden aplicar a cada recurso de SCEPman.

• Key Vault: Soft Delete y Purge Protection ya proporcionan protección contra eliminaciones accidentales. SCEPman no modifica el recurso después de la creación de la clave de la CA, por lo que un ReadOnlyLock es técnicamente posible.

• Cuenta de almacenamiento: Solo un DeleteLock es posible, ya que SCEPman necesita escribir información del certificado en la tabla. Si una cuenta de almacenamiento se elimina accidentalmente, perderá la información sobre los certificados ya emitidos.

• App Services: Un ReadOnlyLock es teóricamente posible, pero debe eliminarse cada vez que modifique la configuración de SCEPman. Un App Service eliminado puede reinstalarse fácilmente, pero solo tendrá la configuración predeterminada, por lo que todos los cambios manuales deben reconfigurarse manualmente. Una combinación de DeleteLock y ReadOnlyLock ayuda a mitigar este riesgo.

• Área de trabajo de Log Analytics: Un DeleteLock es técnicamente posible, pero solo perdería los registros recopilados durante el período de retención, lo que no afecta a la disponibilidad del servicio SCEPman.

• Otros recursos de Azure: Estos no almacenan datos y pueden recrearse sin pérdida de información. Un DeleteLock y ReadOnlyLock puede ser útil para algunos de ellos. Algunos no se pueden eliminar en absoluto porque tienen dependencias de uno de los servicios principales mencionados anteriormente.