2017년 3월로 기재되어 있는데, 당시 21 CFR part 11 이 제정되면서 (ER/ES) 강조된 부분이 User access control 및 Security 와 연관된 사항입니다. 그로인해 많은 S/W 들이 기본적으로 기능을 반영한 것이 아래 사항들인데요.
- Password 유효기간 (보통 90일)
- Password 복잡성 기능 (대문자, 소문자, 영문, 특수 기호 포함 및 이전 P/W 사용 금지 기능 등)
- Password 도용 시도에 대한 action (PW 3번 틀릴 시, 계정 잠김 기능)
- Idle time (Inactivity) 경과 시 자동 Lock out 또는 Log out 기능 (보통 10분, 15분, 30분 이상 등 다양)
▼아래 표로 정리된 내용 참고하세요
물론 이러한 기능이 모두 Default 로 설정될 필요는 없으나, 일부 항목은 inspection 시에 반드시 요구되는 사항들 입니다.
(유효기간, 입력 시도 제한, Idle 시 자동 잠김 등)
그중에서,
Idle 후 Lockout 되는 시간에 대한 고민이 생기게 되는데요.
왜냐하면, 규정이나 가이드라인에서 명시한 특정 value 가 없기 때문입니다.
일반적으로는 15분을 필드에서 많이 쓰시는 걸 봤는데요. (근거는 없습니다)
제 경험으로 딱 한명의 auditor 가 15분이 길다는 지적을 했던 기억이 있습니다. (고객사 였는지 기관이었는지는 잘 기억이 안나네요...)
보안 기술 규정 규정 가이드 (STIG, Security Technical Implementation Guides)에서는 Windows 네트워크 machine inactivity limit 은 15분(설정값 900초) 으로 요구하고 있습니다.
▼참조내용
STIG(Security Technical Implementation Guide)는 미국 국방성의 DISA(Defense Information Systems Agency)에서 작성한 구성 표준입니다. STIG에는 시스템에 대한 계정 액세스를 제한하는 악성 컴퓨터 공격을 방어하기 위해 정보, 시스템 및 소프트웨어를 차단하는 기술적 지침이 포함됩니다. IIAS는 제조 및 설치 프로세스 중에 대부분의 STIG 규칙을 준수하도록 디자인되고 구성되었습니다.
이는 IT 보안 규정 가이드 사항으로, 제약산업에 동일하게 적용되어야 함은 아니나, 어느 정도 수준에서 기준 value 로 참고하심이 적합하겠습니다. 그러나, 30분 이상 (1시간) 의 idle timeout 설정의 경우에는 특정 계정이 로그인 된 상태에서 다른 사용자가 해당 시스템을 운용하거나, 데이터에 영향을 주는 행위를 하기에 Risk 가 높다는 생각입니다.
idle timeout 시간을 길게 설정하는 이유는 장비 운용자의 생산성 향상 (귀찮음 제거)을 위한 것 또는 특정 장비/설비가 운용 도중 lockout 이 되는 경우, operation 이 중단되는 특이한 case 가 있을 수 있습니다.
후자의 경우에는 해당 장비/설비에 대해서 해당 사유를 근거로한 적정 idle timeout 시간을 정할 수 있다고 판단되나, 전자의 경우라면 적절한 수준으로 시간을 조정하는 것이 적합하다고 생각합니다. (그렇다고해서 모든 장비/설비에 대한 idle timeout 시간을 정하기 위한 RA 까지는 불필요하다는 생각입니다)
DI관련 전략이나 적용 계획에 대한 사항은 아래 web page 통해 도움받으시기 바랍니다.
'데이터 완전성 (Data Integrity)' 카테고리의 다른 글
연구소 데이터완전성(Data Integrity) 는 필수?! (0) | 2023.11.13 |
---|---|
삼성바이오로직스 483 (DI 이슈) (0) | 2023.10.30 |
데이터 완전성 행정처분 사유 (0) | 2023.08.01 |
GMP 문서의 추적 관리 (2) | 2023.05.25 |
DI 교육은 어떻게 하나요? (0) | 2023.05.15 |
댓글