Cómo definir niveles de acceso, perfiles de acceso, zonas de seguridad, áreas restringidas y permisos en sistemas de control de acceso físico.
¡Descúbrelo!
Los niveles de acceso, los perfiles de acceso, las zonas de seguridad y los permisos de acceso son formas complementarias de convertir el riesgo físico de una instalación en reglas objetivas de autorización. En un sistema bien diseñado, la pregunta no es solo si una persona “tiene acceso”, sino a qué áreas, en qué sentido, bajo qué condiciones, con qué credencial, durante qué período y con qué excepciones.
Una arquitectura coherente comienza por la zonificación física y la criticidad de los activos. Las áreas públicas, controladas, restringidas y críticas no deben recibir el mismo tratamiento; cada transición entre zonas crea un punto en el que deben evaluarse identidad, autenticación y autorización. El perfil de acceso agrupa entonces permisos compatibles con una función, vínculo o necesidad operativa, evitando habilitar puertas individualmente sin una lógica trazable.
Este enfoque es especialmente importante en plantas industriales, edificios corporativos, hospitales, centros de datos, subestaciones, centros logísticos e instalaciones públicas. Cuanto mayor sea el número de personas, puertas, plantas, terceros y excepciones, mayor será el riesgo de que la política de permisos crezca de forma desordenada. El proyecto debe convertir la política de seguridad en una estructura verificable, documentada y comprobable.
Niveles de acceso, perfil de acceso, zona de seguridad y permiso: cuál es la diferencia
Los términos aparecen juntos, pero no significan lo mismo. Tratarlos como sinónimos produce ambigüedades que después reaparecen en la configuración del software, la matriz funcional, las pruebas de aceptación y la operación diaria.
| Concepto | Pregunta que responde | Ejemplo de aplicación |
| Zona de seguridad | ¿Qué nivel de protección exige un área física? | recepción, área administrativa, laboratorio, sala eléctrica, data hall |
| Área restringida | ¿Qué ambiente exige autorización específica para entrar? | centro de procesamiento de datos, archivo, sala técnica, almacén |
| Nivel de acceso | ¿Hasta dónde puede avanzar determinado grupo en la jerarquía física? | acceso general, restringido, crítico |
| Perfil de acceso | ¿Qué conjunto de permisos se asignará a una persona o función? | mantenimiento eléctrico, operación, limpieza, visitante acompañado |
| Permiso de acceso | ¿Qué acción concreta está autorizada? | entrar por la puerta P-023, utilizar el ascensor hasta la 8.ª planta, acceder al estacionamiento |
La zona describe el espacio y su criticidad. El perfil describe la regla asignada a la identidad. El permiso materializa esa regla en puntos de acceso, sentidos, plantas, horarios o funciones. El nivel de acceso es una forma de organizar la progresión entre áreas, pero no debe convertirse en una clasificación abstracta desconectada del riesgo real.
En instalaciones pequeñas, estos conceptos pueden parecer excesivos. Sin embargo, en entornos con decenas o cientos de puertas, son precisamente lo que evita que la autorización se administre como una lista manual de excepciones.
El proyecto debe comenzar por el riesgo y los activos, no por el organigrama
Las zonas y los perfiles no deben nacer de la configuración del sistema. El Proyecto de Control de Acceso debe convertir riesgos, flujos y activos en permisos trazables, evitando permisos excesivos y excepciones sin gobernanza.
Un error recurrente es crear perfiles directamente a partir de los departamentos de la empresa: “Finanzas”, “TI”, “Ingeniería”, “Mantenimiento” y así sucesivamente. El organigrama ayuda a comprender funciones, pero no sustituye el análisis físico.
Dos personas del mismo departamento pueden tener necesidades de acceso diferentes. Un ingeniero de mantenimiento puede necesitar entrar en salas eléctricas y áreas técnicas, mientras otro, con función administrativa, no. Del mismo modo, profesionales de áreas distintas pueden compartir una misma necesidad operativa, como acceder a un muelle o a un centro de operación.
El proceso de ingeniería debe seguir otra lógica:
Primero se identifican los activos, los procesos críticos, los requisitos regulatorios y las consecuencias de una entrada no prevista. Después se definen las zonas y sus fronteras. Solo entonces tiene sentido decidir qué funciones pueden atravesar cada frontera y bajo qué condiciones.
Esta secuencia evita dos problemas opuestos: permisos excesivos, cuando el perfil concede más de lo necesario, y fragmentación excesiva, cuando cada persona recibe una combinación casi única de puertas que se vuelve imposible de gobernar.
Cómo estructurar zonas de seguridad y áreas restringidas
Las zonas de seguridad son agrupaciones físicas con requisitos de protección similares. Pueden coincidir con plantas, sectores, edificios o perímetros, pero no necesitan seguir literalmente la arquitectura civil. Un mismo edificio puede contener varias zonas, y una zona puede abarcar ambientes físicamente separados si la política de protección es equivalente.
Una taxonomía práctica puede utilizar términos como pública, controlada, restringida y crítica, siempre que el proyecto deje claro que estas denominaciones son una convención de la instalación y no una escala normativa universal. Lo importante es la asociación entre riesgo, requisitos y controles.
Un área pública puede permitir circulación sin credencial hasta determinado punto. Un área controlada puede exigir identificación simple. Un área restringida puede exigir credencial individual y una regla de autorización. Un área crítica puede exigir autenticación multifactor, anti-passback, doble custodia, acompañamiento, mayor supervisión de eventos u otras medidas proporcionales al riesgo.
La zonificación también debe considerar las transiciones. Muchas fallas ocurren no dentro del área crítica, sino en el paso entre áreas con requisitos diferentes. En esa frontera el proyecto define lector, barrera, sentido controlado, sensor de puerta, autenticación, comportamiento de emergencia y evento esperado.
Evitar zonas que existen solo en el software
Una zona lógica solo es útil cuando corresponde a una realidad operativa verificable. Si el software posee una “Zona 4” pero nadie sabe qué puertas la delimitan, qué activos protege o qué regla de entrada aplica, la clasificación perdió su función de ingeniería.
Cada zona debe tener, como mínimo, una definición, una justificación, sus puntos de frontera y la relación de perfiles autorizados. En entornos críticos, también conviene registrar los responsables de la autorización y los criterios de revisión periódica.
Las áreas restringidas no son todas iguales
El término áreas restringidas aparece con frecuencia en políticas de seguridad, pero es amplio. Una sala de telecomunicaciones, una farmacia hospitalaria, un archivo, un laboratorio y una subestación pueden ser todas “restringidas” y, aun así, exigir controles diferentes.
El proyecto debe traducir la restricción en requisitos: quién autoriza, quién puede entrar, si se permite acceso sin acompañamiento, qué factores de autenticación se exigen, si existe límite temporal, si los eventos requieren video asociado, si hay anti-passback o si la entrada depende de otro estado operativo.
Cómo crear perfiles de acceso sin perder gobernanza
Un perfil de acceso es un paquete de permisos que puede asignarse a personas con necesidades similares. Esta abstracción reduce errores porque permite administrar reglas en el nivel de función, vínculo o actividad, en lugar de configurar puerta por puerta para cada usuario.
El modelo debe seguir el principio de mínimo privilegio físico: conceder solo el acceso necesario para la función y durante el tiempo necesario. El objetivo no es restringir por principio, sino reducir la superficie de exposición y hacer justificable cada autorización.
Los perfiles útiles suelen surgir de combinaciones como:
- función operativa;
- lugar de trabajo;
- criticidad de las áreas necesarias;
- vínculo — empleado, tercero, visitante, proveedor, auditor;
- necesidad de acceso fuera del horario estándar;
- necesidad de acceso sin acompañamiento;
- autorización para vehículos, muelles, ascensores o áreas técnicas;
- requisitos adicionales de autenticación.
El perfil genérico “mantenimiento” puede ser demasiado amplio. En una instalación compleja puede haber mantenimiento eléctrico, HVAC, telecomunicaciones, civil y seguridad, cada uno con necesidades diferentes. La granularidad debe ser suficiente para representar el riesgo sin crear cientos de perfiles casi idénticos.
Perfil base y excepciones controladas
Una buena práctica operativa es separar el perfil base de las excepciones. La persona recibe lo que su función exige normalmente; los permisos extraordinarios son temporales, justificados y, siempre que sea posible, cuentan con expiración automática.
Esto reduce la acumulación de privilegios: alguien cambia de función, recibe nuevos permisos y conserva los anteriores por falta de revisión. En integraciones con RR. HH. e IAM, los cambios de cargo o de unidad deben provocar una reevaluación del perfil, no simplemente añadir accesos.
Los perfiles por función no eliminan la aprobación
Automatizar la asignación a partir del cargo o grupo corporativo mejora la escala, pero no significa que todo mapeo deba ser automático. Las áreas críticas pueden exigir una segunda aprobación, comprobación de capacitación o autorización del responsable del activo.
La ingeniería debe definir qué permisos pueden derivarse automáticamente de una fuente de identidad y cuáles dependen de un workflow específico.
Los permisos de acceso deben expresarse de forma verificable
Un permiso no debería describirse simplemente como “acceso al edificio”. Para que sea comprobable, debe indicar dónde, en qué sentido, cuándo y bajo qué condiciones.
En una puerta, la regla puede definir entrada controlada y salida libre. En otra, tanto la entrada como la salida pueden exigir lectura para mantener el estado de presencia. En un torniquete, el perfil puede autorizar una dirección específica. En estacionamientos, la autorización puede depender de la relación entre vehículo y conductor. En ascensores, puede limitar las plantas disponibles.
Una estructura de permisos puede combinar:
| Dimensión | Ejemplos |
| Identidad | empleado, tercero, visitante, equipo de emergencia |
| Local | edificio, zona, área, puerta, torniquete, planta |
| Sentido | entrada, salida, ambos |
| Tiempo | días, turnos, ventanas, festivos, vigencia |
| Autenticación | tarjeta, PIN, biometría, dos factores |
| Estado | anti-passback válido, capacitación vigente, acompañamiento |
| Excepción | mantenimiento programado, contingencia, emergencia |
Esta descomposición convierte la política de seguridad en reglas que pueden implementarse y probarse. También facilita investigar un acceso denegado: es posible identificar si la causa fue el área, horario, factor, estado o vigencia.
Los niveles de acceso no deben ser una simple escala del 1 al 5
Es común encontrar instalaciones que clasifican a los usuarios como “nivel 1”, “nivel 2”, “nivel 3” y así sucesivamente. Esta estrategia parece simple, pero puede generar interpretaciones peligrosas si un número mayor significa automáticamente “accede a todo lo inferior”.
La realidad física rara vez es perfectamente jerárquica. Quien accede a un laboratorio de alta criticidad no necesariamente necesita acceder a tesorería. Un técnico de infraestructura puede entrar al centro de datos y no tener ninguna razón para acceder a archivos de RR. HH.
Por eso, los niveles pueden ayudar a comunicar criticidad, pero los permisos deben definirse por necesidad. El modelo más robusto combina zona + función + condición, y no una escalera universal de privilegios.
Cuando exista una jerarquía, debe documentarse explícitamente. El software no debe inferir que un perfil crítico concede acceso irrestricto a todas las áreas de la instalación sin que esto haya sido una decisión de proyecto.
Zonas, áreas y anti-passback deben compartir el mismo modelo espacial
Las reglas de anti-passback y presencia dependen de saber en qué área el sistema considera ubicada a la persona. Si las zonas utilizadas en la política de permisos no corresponden a las zonas configuradas para presencia, aparecen inconsistencias difíciles de operar.
Una puerta de transición entre Zona A y Zona B puede registrar el cambio de estado. Si una salida no se lee, existe una ruta alternativa o una puerta de emergencia evita el flujo normal, el sistema puede perder la coherencia del estado de presencia.
El proyecto debe decidir qué áreas realmente necesitan seguimiento de estado y cuáles son solo agrupaciones administrativas. No toda zona de seguridad necesita ser una zona de anti-passback y no toda regla de presencia exige un bloqueo hard.
Esta decisión debe aparecer en la matriz funcional y en el plan de pruebas. Un diagrama espacial o un plano con fronteras de zona también es mucho más útil que intentar reconstruir la lógica únicamente a partir de la configuración del software.
Horarios, calendarios y vigencia forman parte del permiso
El permiso físico no es necesariamente permanente. Un perfil puede ser válido solo en días laborables, durante un turno, en una ventana de mantenimiento o durante la vigencia de un contrato.
Por eso, el tiempo debe tratarse como una dimensión de la autorización. La misma persona puede estar autorizada a entrar en determinada área durante la jornada y necesitar aprobación adicional fuera de ella. Un tercero puede tener permiso hasta que termine la orden de servicio. Un visitante puede disponer de una ventana de pocas horas.
El sistema debe administrar estas reglas sin transformar excepciones temporales en derechos permanentes. La expiración automática es un control importante porque reduce la dependencia de una eliminación manual posterior.
La programación de horarios, turnos, calendarios y festivos merece una especificación propia, especialmente en instalaciones 24×7, porque los cambios de fecha, transición de turnos, festivos locales y operación offline pueden alterar el resultado de la autorización.
Visitantes, terceros y prestadores requieren perfiles propios
Copiar el perfil de un colaborador para un tercero es un atajo operativo peligroso. El vínculo externo tiene características propias: patrocinador, contrato, vigencia, necesidad de acompañamiento, capacitación, áreas permitidas y proceso de cierre.
Los visitantes tampoco deben heredar un “perfil de visitante” excesivamente amplio por simple conveniencia. El perfil puede depender del anfitrión, el lugar de la reunión, el período y el tipo de visita.
La política de permisos debe prever estos grupos desde el proyecto. De lo contrario, la operación crea perfiles improvisados después de la implantación, fuera de la trazabilidad original.
La integración con RR. HH., Active Directory e IAM cambia la escala de la gobernanza
En sistemas corporativos, la identidad puede originarse en RR. HH., directorios o plataformas de IAM. Esto permite automatizar parte del ciclo Joiner-Mover-Leaver: alta, cambio y baja.
La integración, sin embargo, debe definir claramente la fuente de verdad. RR. HH. puede ser responsable del vínculo laboral; IAM puede organizar funciones digitales; el sistema físico sigue siendo responsable de aplicar permisos a zonas y puntos de acceso.
El mapeo entre un grupo corporativo y un perfil físico debe estar versionado y ser auditable. Un cambio en un grupo de directorio no debería producir acceso a un área crítica sin que la regla haya sido previamente diseñada y aprobada.
También es necesario tratar los conflictos. Si una persona pertenece a dos grupos, ¿el resultado será la unión de permisos? ¿Existirá una regla de denegación explícita? ¿Una autorización temporal puede ampliar el perfil? ¿Quién revisa esas combinaciones? Estas decisiones forman parte de la arquitectura, no solo de la configuración del producto.
Cómo representar zonas y perfiles en la matriz funcional
Cuando la política necesita relacionar perfiles, zonas, sentidos, horarios, APB, integraciones y emergencia, la matriz funcional es el vínculo entre requisito, configuración y prueba. Esta documentación reduce la ambigüedad en la contratación y la aceptación.
La matriz funcional convierte la lógica conceptual en un requisito de proyecto. Cada punto de acceso debe relacionar origen, destino, sentido, lectores, sensores, eventos e integraciones. Para gobernar niveles y perfiles, la matriz puede complementarse con una matriz de autorización.
Un ejemplo simplificado:
| Perfil | Zona pública | Zona controlada | Zona restringida | Zona crítica |
| Visitante | permitido | acompañado | no | no |
| Administrativo | permitido | permitido | según función | no |
| Mantenimiento técnico | permitido | permitido | según disciplina | bajo autorización |
| Operación crítica | permitido | permitido | permitido | según función |
Esta tabla no debe interpretarse como un modelo universal. Demuestra la necesidad de registrar explícitamente la relación entre perfiles y zonas.
En un proyecto real, la granularidad puede aumentar hasta edificios, plantas, puertas, horarios, factores y excepciones. Lo importante es que la regla permanezca trazable desde el requisito hasta la prueba de aceptación.
La emergencia y la seguridad de la vida tienen precedencia sobre la política normal
Una autorización de seguridad física no puede aplicarse de manera que comprometa los requisitos de salida, evacuación, combate contra incendios u otras funciones de seguridad de la vida.
El sistema debe definir cómo se comportan puertas, torniquetes, esclusas y otros medios controlados durante una emergencia. La regla puede incluir liberación, desbloqueo local, interfaces con sistemas de incendio, accionamientos de emergencia y modos específicos de operación.
Estas condiciones no son “perfiles de usuario”. Son estados del sistema que pueden alterar temporalmente la política normal. Por eso deben tratarse en la matriz de causa y efecto y verificarse durante el comisionamiento.
Del mismo modo, los equipos de emergencia pueden tener autorizaciones específicas, pero esto no sustituye el comportamiento seguro exigido a la instalación.
La revisión periódica de permisos evita la acumulación de privilegios
Una arquitectura bien diseñada puede perder calidad con los años si nadie revisa quién todavía necesita acceder a cada área.
La revisión periódica debe observar perfiles, excepciones, usuarios inactivos, terceros cuyo vínculo terminó, credenciales no utilizadas y accesos críticos. En entornos de mayor riesgo, el responsable del área puede recertificar periódicamente la lista de personas autorizadas.
El control PE-2 de NIST SP 800-53 es una referencia útil para la lógica de mantener la lista de autorizados, revisar autorizaciones y retirar accesos que ya no son necesarios. La misma publicación también aborda la autorización por posición o función, concepto directamente relacionado con los perfiles de acceso físico.
La frecuencia de revisión debe ser proporcional al riesgo. Un área administrativa y una sala de activos críticos no necesitan necesariamente el mismo ciclo de recertificación.
Los registros y la auditoría deben explicar por qué se permitió o denegó el acceso
Registrar únicamente “acceso denegado” es insuficiente para una operación madura. Siempre que la plataforma lo permita, conviene diferenciar causas como credencial inválida, perfil sin permiso, horario fuera de la ventana, anti-passback, factor ausente, vigencia expirada o punto de acceso fuera de servicio.
Este nivel de evidencia ayuda a mantenimiento, seguridad, auditoría e investigación de incidentes. También permite comprobar si la política diseñada fue implementada correctamente.
La retención de los registros debe considerar finalidad, requisitos internos, investigación y protección de datos. No existe un único plazo universal válido para todas las instalaciones; el proyecto y la gobernanza deben justificar el período y controlar quién accede a esta información.
Cómo especificar niveles y perfiles sin vincular el proyecto a un fabricante
El requisito debe describir comportamiento, no nombres de pantallas o recursos propietarios. En lugar de exigir un menú específico, la especificación puede exigir que el sistema permita crear grupos de usuarios, perfiles de acceso, zonas, calendarios, excepciones, expiración y trazabilidad de auditoría con determinados criterios.
También debe exigir capacidad compatible con la escala: número de perfiles, usuarios, áreas, puntos, reglas temporales y eventos. Los límites de licenciamiento deben conocerse porque una arquitectura que funciona técnicamente puede volverse inviable si cada capacidad esencial exige módulos no previstos.
Para entornos multisite, debe definirse si los perfiles son globales, locales o híbridos. Una función corporativa puede tener permisos comunes en varias unidades y excepciones específicas en cada sitio.
La especificación por desempeño preserva la competencia y mantiene el foco en lo que la ingeniería debe demostrar durante la aceptación.
FAT, SAT y comisionamiento deben probar la política — no solo el lector
Comprobar que el lector reconoce una tarjeta no demuestra que el control de acceso sea correcto. El comisionamiento debe verificar la lógica de permisos.
Los casos de prueba deben incluir, por ejemplo:
- perfil autorizado en la zona y horario correctos;
- el mismo perfil intentando acceder a una zona no autorizada;
- credencial válida fuera del horario permitido;
- usuario con autorización temporal antes y después de la expiración;
- cambio de perfil después de una modificación de función;
- baja y revocación;
- operación offline de la controladora;
- excepción autorizada y posterior eliminación;
- evento de emergencia;
- registro de logs y correlación con la matriz funcional.
La prueba debe producir evidencia. De esta forma, requisito, configuración y aceptación permanecen vinculados y la política de acceso deja de depender de la interpretación de quien operó el software en ese momento.
Errores comunes al definir niveles de acceso y permisos
El primer error es crear un perfil “master” para facilitar la operación y distribuirlo ampliamente. El segundo es usar el organigrama como única referencia. El tercero es añadir excepciones sin expiración. El cuarto es no revisar permisos después de cambios de función.
También son frecuentes las zonas sin frontera clara, nombres de perfil que no explican la regla, duplicación de perfiles casi idénticos, permisos concedidos directamente al usuario sin justificación y configuraciones que no aparecen en ninguna documentación de proyecto.
Otro problema es confundir complejidad con seguridad. Crear decenas de niveles y cientos de perfiles no mejora el sistema si nadie puede administrarlos. La calidad está en representar el riesgo con la menor complejidad compatible con la operación.
Cómo contratar un proyecto de control de acceso con una política de permisos trazable
La contratación debe exigir que la ingeniería convierta levantamientos, riesgos, flujos, áreas y funciones en entregables verificables. Planos de puntos, diagramas, memoria de criterios, matriz funcional, matriz de autorización, requisitos de software, interfaces y plan de pruebas deben contar la misma historia.
Antes de la implantación, el contratante debe poder responder: qué zonas existen, qué áreas son restringidas, qué perfiles se definieron, quién aprueba cada perfil, qué permisos recibe cada uno, cómo funcionan las excepciones y cómo se probará todo.
Cuando estas respuestas aparecen únicamente durante la parametrización del integrador, el proyecto trasladó decisiones de ingeniería a la fase equivocada. Esto aumenta retrabajo, dependencia del fabricante y dificultad de fiscalización técnica.
Consideraciones finales
Los niveles de acceso, perfiles de acceso, zonas de seguridad, permisos de acceso y áreas restringidas son partes de un mismo modelo de autorización física. El punto central es convertir el riesgo y la necesidad operativa en reglas claras, mínimas, auditables y comprobables.
La arquitectura más robusta no es la que concede más niveles, sino la que puede explicar por qué cada persona puede entrar en cada área, durante cuánto tiempo y bajo qué condiciones. Cuando esta lógica nace en el proyecto y llega a la matriz, la configuración y el comisionamiento, el sistema deja de ser una colección de puertas y pasa a operar como una disciplina de ingeniería.
La aceptación debe demostrar la lógica completa de autorización. La ingeniería define casos positivos, negativos y de contingencia para confirmar que los niveles de acceso, perfiles y permisos implementados corresponden al proyecto.
Referencias técnicas
[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60839-11-1:2013 — Alarm and electronic security systems — Part 11-1: Electronic access control systems — System and components requirements. 2013. Disponible en: https://webstore.iec.ch/en/publication/3662.
[2] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60839-11-2:2014 — Alarm and electronic security systems — Part 11-2: Electronic access control systems — Application guidelines. 2014. Disponible en: https://webstore.iec.ch/en/publication/3663.
[3] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations. 2020. Disponible en: https://csrc.nist.gov/pubs/sp/800/53/r5/final.
[4] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Electronic Physical Access Control Systems — Security Control Overlay of SP 800-53 Revision 5. 2021. Disponible en: https://csrc.nist.gov/CSRC/media/Projects/risk-management/documents/overlayRepo/Electronic%20Physical%20Access%20Control%20Systems/ePACS%20Overlay_v1_SP800-53rev5-April2021.pdf.
Preguntas frecuentes
El nivel de acceso es una forma de organizar la criticidad o progresión entre áreas; el perfil de acceso es el conjunto concreto de permisos asignado a una función, vínculo o necesidad. En proyectos maduros, el perfil debe derivarse de las zonas y necesidades reales, no solo de una escala numérica.
Son agrupaciones de áreas físicas con requisitos de protección similares. El proyecto define sus fronteras, activos protegidos, puntos de transición y qué perfiles pueden acceder a ellas. Términos como pública, controlada, restringida y crítica pueden utilizarse como convención, siempre que estén claramente definidos.
El permiso debe especificar quién puede acceder a qué punto o área, en qué sentido, durante qué período, con qué factores de autenticación y bajo qué condiciones. Cuanto más verificable sea la regla, más fácil será implementarla, auditarla y probarla.
Es un área cuyo ingreso depende de una autorización específica. La restricción debe convertirse en requisitos de autenticación, perfil, vigencia, supervisión, acompañamiento y registro compatibles con el riesgo del ambiente.
No como regla general. El departamento puede ser un atributo, pero personas de la misma área organizativa pueden necesitar accesos físicos diferentes. El perfil debe representar función, ubicación, riesgo, vínculo y necesidad operativa.
Sí, siempre que el mapeo entre identidad corporativa y permiso físico esté diseñado, aprobado y sea auditable. Las áreas críticas pueden exigir aprobaciones adicionales incluso cuando la identidad y el cargo se reciben automáticamente.
El SAT debe incluir casos autorizados y denegados, horarios, expiración, cambio de perfil, revocación, operación offline, excepciones y emergencia. El objetivo es demostrar la política completa, no solo el funcionamiento del lector.
Estas decisiones deben formar parte del Proyecto de Control de Acceso porque dependen de riesgos, flujos, arquitectura, integración, documentación y criterios de aceptación. La configuración del software debe implementar requisitos previamente definidos y no sustituir al proyecto.
Materiales técnicos complementarios
Servicios relacionados
- Proyecto de Control de Acceso
- Proyecto de Seguridad Electrónica Integrada: CCTV, acceso, intrusión e integración
- Comisionamiento de Ingeniería: planificación, pruebas, preparación y handover
Contenidos principales sobre el tema
- Sistema de Control de Acceso: tipos, tecnologías, normas y proyecto
- Matriz funcional de control de acceso: cómo especificar cada punto
