본문 바로가기
데이터 완전성 (Data Integrity)

Windows 환경의 Data Integrity + Windows event viewer

by doing_right 2024. 2. 20.

Data Integrity 에 대한 준비를 시작할 때, 

가장 우선되는 것이 실험실 내의 데이터 관리 입니다. 

 

데이터 수명주기 (Lifecycle 혹은 전주기) 내에서 Integrity 를 유지하기 위해서

크게 신경 써야할 부분은 3가지 부분입니다. 

 

1) 데이터의 생성(Creation&Saving) 단계

2) 데이터의 운영 (Processing&Reporting) 단계

3) 데이터의 보관 단계 (Backup&Archive)

 

이전 글들에서 관련 내용을 기억날 때 마다 조금씩 썼던 것 같긴한데,

본 글에서는 1), 2), 3) 번 과정에서 주체가 되는 Application software level 이 아닌, 

더 하위 Level 인 Operating system level (=Windows or Windows server) 에서의 데이터 완전성에 대한 내용입니다. 

 

분석 장비를 예로 들면, 

분석 기기를 control 하고, 데이터를 저장, 처리, 출력하기 위한 Application S/W 가 존재 합니다.

이 S/W 는 Windows 운영체제 호환이 대부분이며, Stand alone 으로 설치되거나 Lab. Network 에 연결되어 설치될 수 있습니다. 

 

이 때, Stand alone 은 해당 PC 의 지정된 HDD 경로 내에 파일(또는 DB) 가 생성되며, 네트워크에 연결된 경우에는 Server HDD 의 지정된 경로에 설치됩니다. 

 

DB 방식의 데이터 파일은 데이터 접근이 해당 Application S/W 를 통해서만 access 될 수 있기 때문에 Windows 환경 (예: 탐색기, 메모장 등) 에서 Raw data 를 변형할 수 없습니다. (예: 분석 결과의 수정이나 샘플 이름 등의 변경)

 

하지만, DB 방식의 데이터가 아닌 Flat file 형태 (개별파일 생성 형태) 의 경우에는 Windows 탐색기를 통해 해당 분석 결과 파일들에 접근이 가능하고, 해당 파일의 이름을 변경하거나 심각한 경우에는 메모장을 통해 내부 value 를 편집가능한 경우도 있습니다 (아주 단순 결과 출력 기기이면서 구형 장비 중 드물게 존재)

 

이러한 데이터 변경 가능성으로 인한 DI 위험을 예방하기 위해서 제한되는 방법은 아래와 같습니다. 

 

1) 데이터가 저장되는 경로(폴더) 에 대한 User 접근 권한을 제한하는 방법

①폴더 자체를 User 가 접근하지 못하도록 사라지게 하는 것이 가능하며 (GPO 설정을 통해) 

②또는 해당 폴더 내 파일들을 읽기 전용으로 권한을 부여하는 것이 가능합니다. 

 

하지만, ① 의 경우에는 분석 이후 저장 경로를 선택해야하는 S/W 에서 저장 경로를 선택할 수 없게되는 경우가 특정 S/W 에서 발생하게 되고, ② 의 경우에는 폴더에 쓰기 권한이 없는 경우 Application S/W 에서 분석 진행 후 결과가 저장되지 않는 Case 가 발생할 수 있습니다.

 

2) 폴더/파일 권한을 건드리지 않고, 파일 수정, 삭제에 대한 이력을 관리하는 방법

1) 방법에 대한 조치가 System 마다 달라지는 불편함 때문에 파일/폴더 권한은 부여하되, 파일들에 대한 이력을 점검 (audit trail) 하는 방법으로 Windows event viewer 를 검토하는 방법이 있습니다.

 

모든 파일에 대해 수정/삭제 이력이 Event log 로 남지 않기 때문에 Logging 을 위한 audit policy 를 설정해야합니다. 

Group Policy (또는 GPO, Group Policy Object for AD server) 에서 정책 설정을 활성화 시켜야 하고, 해당 적책을 적용할 폴더에서도 auditing 되도록 설정을 해야 반영이 됩니다. 아래 잘 설명해주신 분의 글을 참고하시면 되겠습니다. 

 

https://ksmk.tistory.com/entry/Windows-%ED%8C%8C%EC%9D%BC-%EC%82%AD%EC%A0%9C-%EB%A1%9C%EA%B7%B8-%EB%82%A8%EA%B8%B0%EA%B8%B0

참고- https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-windows-event-collection

 

Stand alone 에서는 개별적으로 모두 설정해야하고, Network 환경에서는 Windows Server 에서 정책 설정 후 해당 폴더들에 추가적으로 설정을 진행해야만 합니다. 설정을 정상적으로 진행하면, 파일 수정 및 삭제 시에 Event log 가 생성되고, 이를 Windows event viewer 에서 특정 Event ID 번호를 Filter 하여 확인할 수 있습니다. 

참고 - https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=564

 

이때,  Windows XP 와 이후 Windows 버전에서는 Event ID 가 상이하기 때문에 (XP 버전 세자리 --> 이후 4개 자리 번호) Windows 버전에 따라서 확인해야할 Event ID 번호가 달라지는 것을 유의해야 합니다. 

또한, Deleted 된 object 의 상세 내용을 포함하는 ID 번호와 Deleted 된 상태만 기록하는 ID 번호도 차이가 있으니 이를 잘 구분해 SOP 명시해야 합니다. 

 

그러나, Windows event viewer 를 Audit trail 목적으로 활용하는 데 가장 어려움이 있는 점은 Log 파일에 대한 관리(백업 및 보관) 입니다. 

Windows event log 설정에서 Event log 파일의 용량이 일정 크기에 도달 했을 때, 자동으로 저장되도록 하는 설정이 가능합니다. 특히, 기본 설정은 overwrite 되는 설정이기 때문에 overwrite 되지 않도록 하려면 꼭 설정을 변경해야 합니다. 주의 할 점은 Windows 버전 마다 최대 용량 설정 값이 상이하다는 것입니다. (XP 는 설정 가능한 최대 용량이 훨씬 작습니다)

 

 

참고 - https://learn.microsoft.com/it-IT/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd349798(v=ws.10)

 

1) 그룹 정책 설정

2) 개별 폴더 설정

3) Event log 백업 설정

 

위 설정들을 통해 Windows 내에서 일어나는 파일 변경/삭제 등을 Monitoring 할 수 있고, 추가로 이러한 정책 설정도 임의로 변경해서는 안 되므로 Policy change Event ID (612 / 4719) 등도 함께 모니터링 할 수 있겠습니다. 

 

여기서 고민이 되는 사항은 해당 Windows fuction (Event log 생성 및 Viwer 설정) 에 대한 사항을 Validation (검증) 해야하는 지에 대한 우려입니다. GAMP S/W 카테고리에서 Windows 는 Category 1 (Infrastructure) 이고, 변경관리 정도로 진행 가능하다고 할 수 있겠습니다만, 위에서 보셨고, 해보신 분들은 아시다시피 하나의 설정이라도 실수하거나 누락하는 경우에는 제대로 작동하지 않습니다. 

 

Event log 가 안 생기거나, 누락(Overwrite)되는 경우에 GMP 절차 내에서 어떻게 처리할지는 각 회사의 정책/절차에 따라서 하시면 되겠지만, 기능 검증이 안 된 기능을 GMP 목적으로 사용하는 사항에 대해 최소한의 Verification 및 문서화가 필요하다는 것이 개인적인 의견입니다. 

 

이러한 과정들은 신규 장비가 들어올 때 매번 적용해야하고, 기존 설정한 PC 에서 S/W 업그레이드나 변경 등으로 설정이 초기화되는 경우 등등으로 인해 제법 문제가 많이 발생할 수 있습니다. 

 

이 때문에 Windows 그룹 정책을 직접 다루는 대신 해당 작업을 좀 더 쉽게 handling 할 수 있는 Windows desktop secure 프로그램을 이용하는 방법또한 가능합니다. 다만, 이 또한 Application S/W 와의 호환성에 따라 개별 설정이 필요한 경우가 발생할 수 있으므로 회사의 규모나 시스템 수에 따라 장기적으로 유리한 solution 을 결정할 수 있겠습니다. 

 

실제로 Window event log 를 보여준 경우도 있고, 탐색기 환경에서 데이터 저장 폴더에 Txt 파일을 임의로 생성하고 삭제해보라는 inspector case 도 있었습니다.

 

 

 


👇같이 보는 글

 

https://doing-right.tistory.com/entry/Audit-trail-%EC%A0%90%EA%B2%80-%EA%B8%B0%EB%A1%9D-%EA%B2%80%ED%86%A0-%EC%A3%BC%EC%B2%B4%EC%99%80-%EC%A3%BC%EA%B8%B0-%EA%B2%B0%EC%A0%95

 

Audit trail (점검 기록) 검토 주체와 주기 결정

DI 지침 준비 단계에서 우선 적용이 필요한 순서는 Audit trail - Authority management - Data backup/restore - security 입니다. (Audit trail 은 식약처 지침 용어로는 '점검기록' 입니다. 개인적으로는 점검기록 용

doing-right.tistory.com

 

반응형

댓글