Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
    • GP-001 Control of documents
    • GP-002 Quality planning
    • GP-003 Audits
    • GP-004 Vigilance system
    • GP-005 Human Resources and Training
    • GP-006 Non-conformity, Corrective and Preventive actions
    • GP-007 Post-market surveillance
    • GP-008 Product requirements
    • GP-009 Sales
    • GP-010 Purchases and suppliers evaluation
    • GP-011 Provision of service
    • GP-012 Design, Redesign and Development
    • GP-013 Risk management
    • GP-014 Feedback and complaints
    • GP-015 Clinical evaluation
    • GP-016 Traceability and identification
    • GP-017 Technical assistance service
    • GP-018 Infrastructure and facilities
    • GP-019 Software validation plan
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Cybersecurity
    • GP-025 Usability and Human Factors Engineering
    • GP-027 Corporate Governance
    • GP-050 Data Protection
    • GP-051 Security violations
    • GP-052 Data Privacy Impact Assessment (DPIA)
    • GP-100 Business Continuity (BCP) and Disaster Recovery plans (DRP)
    • GP-101 Information security
    • GP-200 Remote Data Acquisition in Clinical Investigations
    • GP-026 Market-specific product requirements
    • GP-110 Esquema Nacional de Seguridad
      • ORG Marco organizativo
      • OP Marco operacional
        • OP.PL Planificación
        • OP.ACC Control de acceso
          • OP.AAC.1 Identificación
          • OP.AAC.2 Requisitos de acceso
          • OP.AAC.3 Segregación de funciones y tareas
          • OP.AAC.4 Proceso de gestión de derechos de acceso
          • OP.AAC.5 Mecanismo de autenticación
          • OP.ACC.6 Acceso local
          • OP.ACC.7 Acceso remoto
        • OP.EXP Explotación
        • OP.EXT Servicios externos
        • OP.NUB Servicios en la nube
        • OP.CONT Continuidad del servicio
        • OP.MON Monitorización del sistema
      • MP Medidas de protección
      • Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad.
  • Records
  • Legit.Health Plus Version 1.1.0.0
  • Legit.Health Plus Version 1.1.0.1
  • Licenses and accreditations
  • External documentation
  • Procedures
  • GP-110 Esquema Nacional de Seguridad
  • OP Marco operacional
  • OP.ACC Control de acceso
  • OP.ACC.6 Acceso local

OP.ACC.6 Acceso local

Documentos de referencia​

  • Guías CCN-STIC:
    • Serie CCN-STIC-500 Guías para Entornos Windows
    • Serie CCN-STIC-600 Guías para otros Entornos
  • ISO/IEC 27000
    • 27002:2013:
      • 9.4.2 - Procedimientos seguros de inicio de sesión
  • NIST SP 800-53 rev4:
    • [AC-7] Unsuccessful Login Attempts
    • [AC-8] System Use Notification
    • [AC-9] Previous Login Notification
    • [IA-5] Authenticator Management
    • [IA-6] Authenticator Feedback
    • [SI-11] Error Handling

Guía de implantación​

  1. La mayor parte de las medidas requeridas se pueden conseguir simplemente configurando los puestos de usuario según se indica.
  • Como manera preventiva, la información que se visualiza antes de acceder a un sistema deberá procurar ser la menos posible para evitar dar a conocer qué información puede encontrar dentro alguien que pueda estar tentado de vulnerar el sistema. Por tanto, es recomendable que se muestre meramente el diálogo de acceso y en todo caso algo de información comercial sin valor relacionada con la información manejada. Por ejemplo, deberá evitarse texto de tipo advertencia por estar a punto de entrar a un portal o aplicación que contiene información confidencial de un determinado tipo, ya que habitualmente estas advertencias pueden atraer a usuarios no autorizados.
  • Limitar el número de intentos de acceso para bloquear la oportunidad de acceso una vez efectuados un cierto número de fallos consecutivos, ya sea mediante bloqueo de la cuenta o retardo de la solicitud de contraseña.
  • Guardar un registro o log de los accesos realizados a un sistema, tanto los accesos correctos como aquéllos realizados erróneamente. Esto último es especialmente importante de cara a detectar continuos intentos de vulnerar el sistema (mediante por ejemplo ataques de fuerza bruta), ya sea mediante revisiones periódicas de los registros (logs) o con herramientas automatizadas que detecten este tipo de eventos.
  • El usuario deberá tener conocimiento de las obligaciones tras acceder satisfactoriamente a un sistema (por ejemplo, una ventana emergente). En caso de que el sistema no permita notificar inmediatamente tras el acceso, deberá notificársele por otras vías compensatorias (por ejemplo, un correo electrónico tras el alta en el sistema).

  1. El sistema debe informar al usuario del último acceso con éxito realizado con su identidad (fecha y hora), una vez haya obtenido acceso. Este mecanismo (que puede ser implementado mediante diferentes mecanismos como: pop-up, correo electrónico, SMS, etc.) permitirá al usuario detectar si su cuenta de usuario ha sido comprometida y pueda activar el procedimiento de resolución de incidentes relacionados con contraseñas. Por ejemplo, tras un periodo de inactividad en la cuenta (vacaciones, bajas, etc.), si al usuario se le notifica un acceso reciente sabrá inmediatamente que alguien ha suplantado su identidad en el sistema.

  2. En caso de no ser posible la implementación de este aviso de manera proactiva por parte del sistema, se deberán establecer los mecanismos necesarios para que el usuario pueda consultar el registro de accesos.

  3. Se deberá controlar que el acceso a los sistemas se restrinja en determinados momentos (por ejemplo, días festivos, fin de la jornada laboral, etc.) y lugares (direcciones IP fuera del dominio de seguridad, teletrabajo, equipos no autorizados, etc.), para evitar accesos no supervisados que puedan generar modificaciones o fraudes clandestinos o no autorizados.

  4. No obstante, es posible que existan sistemas que no requieran limitar el acceso (por ejemplo, porque precisamente el propósito del sistema sea ser accesible en cualquier momento y lugar), pero deberá estar debidamente documentada esta casuística.

  5. El requisito de que en ciertos puntos se requiera una identificación singular no es alcanzable por medio de configuración del puesto del usuario, sino que requiere instrumentar workflow de los procesos. Como regla general, estos puntos deben ser pocos y el sistema no debe memorizar la identidad del usuario, sino que debe verificarla cada vez.

  6. Como ejemplo, piense en la firma electrónica que se exige en banca por Internet cada vez que queremos realizar una transferencia; esta ‘firma’ complementa la identificación y autenticación de la sesión de usuario. Esta verificación puntual acota la ventana de riesgo ante un posible robo de sesión.

Previous
OP.AAC.5 Mecanismo de autenticación
Next
OP.ACC.7 Acceso remoto
  • Documentos de referencia
  • Guía de implantación
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)