프로그래머를 위한 21 CFR Part 11용 프로그램 개발 지침C7%C1%B7%CE%B1%D7%B7%A1... · 2004-03-15 · 프로그래머를 위한 21 CFR Part 11용 프로그램 개발

프로그래머를 위한 21 CFR Part 11 용 프로그램 개발 지침

1/35쪽

프로그래머를 위한 21 CFR Part 11 용

프로그램 개발 지침

본 문서의 내용에 이의가 있거나 질문이 있으신 분은 연락해 주시기 바랍니다.

Version Date Remark

1.0 2004/3 New

IVS

유재훈

[email protected]

www.validation.co.kr


2/35쪽

목 차

1 서론 ................................................................................................................................................................. 3 2 목적/대상 ........................................................................................................................................................ 5 3 독자 ................................................................................................................................................................. 6 4 21 CFR Part 11 이란 무엇인가 ..................................................................................................................... 7 5 필요한 것은 무엇인가 ................................................................................................................................. 8 6 Closed System / Access Control ...................................................................................................................... 9

6.1 기본방향 : ID/Password ........................................................................................................................ 9 6.2 하드웨어 통제 ....................................................................................................................................... 9 6.3 네트워크 ................................................................................................................................................. 9 6.4 시스템 보안 구조 (System Security Architecture) .............................................................................. 9 6.5 ID/Password 유지정책......................................................................................................................... 10 6.6 Access Log ............................................................................................................................................ 11 6.7 인력관리 시스템(HR)과 연동 ........................................................................................................... 11 6.8 권한 할당 ............................................................................................................................................. 12

7 Electronic Record .......................................................................................................................................... 13 8 Audit Trail ..................................................................................................................................................... 14

8.1 Audit Trail ?........................................................................................................................................... 14 8.2 Audit Trail 구현방법 ........................................................................................................................... 14 8.3 Trigger 구성 ......................................................................................................................................... 15

8.3.1 Trigger 의 대상 ................................................................................................................................... 15 8.3.2 Audit Trail 용 Table............................................................................................................................. 15 8.3.3 Trigger Script........................................................................................................................................ 17

9 Electronic Signature ...................................................................................................................................... 19 9.1 Electronic Signature ?............................................................................................................................ 19 9.2 자료구조 ............................................................................................................................................... 20

9.2.1 자료저장방법 ..................................................................................................................................... 20 9.2.2 서명설정 Table (rtsignset) .................................................................................................................. 21 9.2.3 서명설정상세 Table (rtsignsetdt) ...................................................................................................... 21 9.2.4 서명 Table (rtsign).............................................................................................................................. 22 9.2.5 서명기록과 근거기록의 연결 ......................................................................................................... 22

9.3 전자서명과 ID/Password..................................................................................................................... 24 9.4 대리서명 ............................................................................................................................................... 24 9.5 전자서명의 표현 ................................................................................................................................. 24 9.6 전자서명 절차 순서도 ....................................................................................................................... 26

10 참고문헌 ................................................................................................................................................... 27 첨부 Part 11 조항................................................................................................................................................ 28


3/35쪽

1 서론

제약산업은 다른 업종에 비하여 규제조건이 까다로운 업종이다. 제약이란 인간은 생명과 직결된 사항이 많아 예전부터 제품에 대한 품질요구사항이 까다로웠으며, 국민의 건강을 위하여 정책적인 제재사항도 많았다.

특히 품질에 관련된 사항은 다른 산업에 비하여 요구사항이 매우 까다롭다. 이러한 것은 GMP 라는 용어로 대표되는 요구사항이며, 국내에서는 제도적으로 KGMP 라는 허가제도로 운영된다. 모든 산업분야에서 전산시스템을 많이 사용하면서 전자기록과 전자서명을 늘어났고, 앞으로도 늘어날 전망이다. 제약산업도 예외가 아니라 많은 제약회사가 전산시스템을 도입하고 있다. 제약업체가 따라야 하는 GMP 에서는 기록과 서명을 매우 중요시한다. 따라서 사용이 늘어나는 전자기록(Electronic Record 이하 ER1)과 전자서명(Electronic Signature 이하 ES)에 대한 특별한 요구사항이 나타나게 되었다. 현재 이러한 요구가 법으로 나타난 것은 미국 FDA 의 21 CFR Part 11 (이하 ‘Part11’)이다. 당연히 Part11 은 국내법이 아니며, 우리가 준수해야 할 필요는 없다. 그러나 미국 FDA 의 요구사항은 국내에 큰 영향을 미치며, 전세계적으로 제약산업에서 사용하는 전자기록과 전자서명에 대한 법으로는 Part11 이 현재로는 유일한 법이므로 Part11 의 중요성은 더욱 커졌다. 지금까지 국내에서는 Part11 을 준수하는 프로그램은 아주 제한적으로 개발되었고, 개발된 프로그램도 준수여부를 확신하기는 힘들다. 이러한 이유는 지금까지 제약산업은 GMP 에 대한 요구사항으로 다른 산업에 비하여 종이기록/종이서명 업무절차에서 전자기록/전자기록 업무절차로의 전환이 늦게 진행되었고, 국부적으로 사용되는 프로그램을 외산을 사용하였다. 따라서 국내의 프로그램업계는 GMP 나 Part11 에 관련된 요구사항을 접할 기회가 거의 없었다. 그러나, 최근 제약산업에서 도입된 일부 시스템(ERP 등)에서 GMP 나 Part11 과의 불일치가 나타나고 있다. 이러한 결과는 도입된 ERP 시스템이 다른 산업에서 사용되도록 개발된 프로그램으로 필연적으로 나타난 문제이다. 국내의 프로그램 수준은 세계적으로 매우 높으며, 국내 프로그램 개발업체는 많은 기업 시스템을 개발한 경험이 있다. 앞으로는 제약산업의 전산시스템도 국내에서 개발될 가능이 많다.

국내의 프로그램 개발업체는 제약업체의 요구사항에 직면하게 될 것이며, 제약업체의 요구사항에 심히 고생할 것이다. 제약업체는 프로그램 개발업체의 특성을 이해하지 못할 것이고, 그 반대도 동일할 것이다. 제약업체의 요구사항은 크게 두 가지로 요약될 것이다. 첫번째는 소프트웨어에 대한 Validation 이다. Validation 은 장치와 설비에 대하여 GMP 를 달

1 프로그래머 중에는 ER 이라 하면 Entity Relationship 으로 생각하여 용어의 혼동이 있을 수 있으나 본 글에서는 ER 은 Electronic Record 이다. 본 글에서는 ‘ER(Entity Relationship)’이란 용어를 사용하지 않고 ‘자료구조’라는 용어를 사용하므로 혼동이 없기를 바람


4/35쪽

성하는 핵심적인 실천 방안이다. 소프트웨어에 대한 Validation 은 주제가 너무 광범위 하며 본 글에서는 다루지 않는다. 소프트웨어 Validation 에 관련된 참고 도서에는 [ISPE GAMP Forum, ‘GAMP4’]라는 바이블과 같은 책이 있다. 깊은 이해를 원한다면 반드시 [GAMP4]를 읽어보기 바란다. 또 하나의 참고도서는 필자가 작성한 [유재훈, ‘Automated System Validation’] 이 있다. 이 문서는 한글로 간략하게 되어 있으니 생각보다 쉽게 내용을 파악할 수 있을 것이다. (정말 쉬운가 ?) 두번째는 전자기록과 전자서명을 다루는 프로그램이라면 Part11준수를 요구할 것이다. Part11준수를 위한 방법이 본 글의 주제이다. 본 글은 제약업체에서 사용하여 Part11 을 준수해야 하는 프로그램을 개발해야 하는 프로그래머를 위하여 작성하였다. 본 글이 도움이 되어 Part11 를 준수하는 성공적인 프로그램이 개발되기를 바란다. 프로그래머가 프로그램하는 것은 일종의 창작활동이다. 어떤 방법으로 구현하는가는 전적으로 프로그래머에 달려있다. 본 글에서 제시하는 방법은 Par11 준수를 위한 하나의 방법이고, 필자의 개인적인 의견이다. 본 글이 모방의 대상이 아니라 도움이 되는 글이 되기를 바란다.


5/35쪽

2 목적/대상

위의 내용과 같이 이 글은 Part11 을 준수하는 프로그램을 개발하는 프로그래머를 위하여 만들어 졌다. 구체적으로 다음과 같다.

• Part11은 무엇인가? • 준수를 위하여 필요한 것은 무엇인가? • Access 관리 • Electronic Record 관리 • Audit Trail • Electronic Signature 관리

본 글에서 다루는 프로그램은 모든 프로그램이 아니다. 당연히 Part11 을 준수해야 하는 프로그램만 이다. Part11 을 준수해야 되는 프로그램은 전자기록을 관리하는 프로그램이다. Part11 에서 정의하는 전자기록에 대한 내용은 4 장에 자세히 나온다. 대부분의 프로그램은 직관적을 판단할 수 있다. 구분한 예는 다음과 같다.

구분 예 Part11 준수

필요여부

본 글의

대상여부

OS Windows, Unix × ×

프로그램 개발툴 C++, Java, MS Visual

Studio

× ×

단일 PC Application Excel, HWP, ZIP △ ×

Embedded Process Control System IC, 내장형 PLC × ×

Standalone Process Control System 독립형 PLC, SCADA,

BMS, DCS,

○ △

(DBMS 사용할때)

Enterprise Information System ERP, 인력관리 ○ ○

물론 파일시스템으로 Data를 관리하는 프로그램과 Data를 관리하는 단일 PC 프로그램을 생각할 수 있으나, 최근의 프로그램 추세를 볼 때 이런 프로그램을 개발될 가능이 매우 적고, 개발되더라도 소규모로 개발될 가능성이 높아서 대상에서 제외한다. Data 관리를 위하여 DBMS 를 사용한다면 당연히 네트워크 기반의 프로그램일 것이다. (DBMS 를 사용하면서 네트워크를 지원하지 않는 시스템은 생각하기 어렵다) 따라서 본 글은 DBMS 를 사용하는 네트워크 기반의 프로그램중에서 Part11 을 준수해야 하는 프로그램을 대상으로 한다.


6/35쪽

3 독자

본 글은 내용은 일반인을 대상으로 하는 범용적인 글이 아니며, 특정 주제를 다루고 있다. 본 글의 독자는 다음의 조건을 만족해야 한다.

• 기업용 프로그램개발 경험(프로그래머) • DBMS에 대한 지식 • RDB에 대한 지식 • GMP이해 • Validation 이해 • Part11 이해 (본 글에 일부 포함)


7/35쪽

4 21 CFR Part 11 이란 무엇인가

Part11에 대한 자세한 설명은 [유재훈, ‘21 CFR Part 11에 대한 고찰’]에 자세히 나와 있다.

간단하게 살펴보면 Part 11 은 1997 년 8 월 20 부터 발효된 미국의 법으로 미국식품안전청(FDA)에 규제를 받는 모든 산업분야에 적용된다.

Part11 의 목적은 전자기록, 전자서명이 신뢰성 있고, 기존 종이기록, 수기서명과 동일하기 위한 기준을 제시한다. 따라서 FDA 의 규정 내에서 만들어지고, 수정되고, 유지되고, 보관되고, 조회되고, 보내어지는 전자적인 형식의 기록에 적용된다. Part 11 의 조항을 살펴보면 총 41 개 조항이 있으며 중복을 포함하여 업무관련 조항이 23 조항, 기술관련 조항이 19 조항이다. 절반 이상이 업무관련 조항이다. Part 11 의 업무관련 조항은 대부분 일반적인 정보관리 지침이다. 사원의 신원확인, 업무에 맞는 권한, 부적절한 행위에 대한 징계 등 일반적인 정보관리 지침은 대부분의 회사에서 일부 수용하고 있는 것들이다. 이런 규정을 좀더 체계적이고 치밀하게 규정하여 Part 11 업무관련 조항을 충족시키면 된다. 하지만 업무관련 조항은 프로그래머가 고민할 부분이 아니다.

Part11의 조항에 대한 구체적인 내용은 [첨부 Part11 조항]에 나와있다. (법 조항은 언제나 딱딱하다. 고려해야 할 것은 5장에서 별도로 정리했으므로 머리가 아프다면 적당히 보기 바란다) 프로그래머가 구현해야 하는 것은 통제되는 시스템(Closed System)과 전자기록과 전자서명에 대한 무결성이다. 이러한 내용은 명확한 정의만 있다면 충분히 구현할 수 있는 것들이다.


8/35쪽

5 필요한 것은 무엇인가

프로그래머가 구현해야 할 사항을 정리하면 다음과 같다.

• 통제되는 시스템 구축 o 접근통제(Access Control) o ID/Password 체계 구축 o 권한의 할당

• 전자기록의 관리 • 전자기록의 Audit Trail • 전자서명의 관리

이후 각각에 대하여 상세하게 논의하겠다.


9/35쪽

6 Closed System / Access Control

6.1 기본방향 : ID/Password

통제되는 시스템(Closed System)이란 시스템 Access 를 전자기록에 대하여 책임 있는 사람에 의하여 통제되는 환경을 의미한다.[§ 11.3 (4)]

통제되는 시스템을 구현하는 가장 쉽고 좋은 방법은 ID/Password 에 의한 통제 방법이다. 대부분의 프로그래머라면 ID/Password 방법을 구현해본 경험이 있을 것이다. 기존에 구현한 방법과 유사하다. 어려운 부분이 아니다.

ID/Password 방법을 구현할 때 Password를 2개 이상 사용하는 것은 선택적인 사양이다.

간혹 지문인식과 홍체인식 등 생체인식(Biometrics) 방법을 사용하는 경우는 별도로 생체인식 방법이 완벽하다는 것을 보여줘야 한다.[§ 11.200 (b)] 생체인식 방법이 완벽하다는 것을 보여주는 것은 매우 힘든 작업이다.(작동방식, 알고리즘, 증거자료 등의 자료가 필요) 결국 생체인식 방법은 보조적인 수단으로 사용될 수는 있어도 생체인식 방법만을 독자적으로 사용하는 것은 권장하지 않는다.

6.2 하드웨어 통제

하드웨어의 통제는 일반적인 관행과 같다. 모든 하드웨어는 지정된 하드웨어를 사용해야 하며 지정된 위치에서 사용해야 한다. 특히 서버와 같은 중요한 하드웨어는 물리적으로 통제되는(서버실 등) 곳에 위치해야 한다. 그러나 하드웨어 통제에 관련 사항은 사용자 회사의 시스템관리자가 결정할 사항이며 프로그래머가 고민할 부분이 아니다.

6.3 네트워크

네트워크는 크게 구성과 보안으로 생각해 볼 필요가 있다.

네트워크는 구성은 사용자 회사의 시스템 관리자의 결정을 따르면 된다. 네트워크는 프로그램과 별도로 구축될 것이며 대부분 이미 구축되어 있을 것이다.

또 하나의 고려사항은 보안인데, 이것 또한 사용자 회사의 시스템 관리자의 결정을 따르면 된다. 특별히 고려할 사항은 인터넷을 통한 접근은 허용하지 않는 것이 바람직하다. 현재 FDA 는 인터넷 사용에 대하여 명확한 답변을 하고 있지 않으며, 잠정적으로는 반대하고 있다. 따라서, 내부 네트워크를 위하여 개발하는 것이 바람직하며, 또한 3-tier 용 클라이언트로 웹브라우저를 선택하지 않는 것이 바람직하다.

6.4 시스템 보안 구조 (System Security Architecture)


10/35쪽

ID/Password 로 구현되는 시스템은 일반적으로 초기 로그인 이후에 단위 프로그램마다 별도의 권한을 부여하는 방법으로 구현하면 된다.

필자가 제안하는 방법은 3단계에 접근 구조이다.

위와 같은 3 단계의 접근 구조이며 Part11 을 충분히 충족할 수 있을 것이라 생각된다. 만약 시스템이 전자서명을 사용한다면 3 단계 [읽기/쓰기 권한]이후에 4 단계로 [서명 권한]을 부여하거나, 3단계의 [읽기/쓰기 권한]을 [서명 권한]으로 아래와 같이 변경하는 것도 바람직하다.

또한 추가적인 보안정책으로 시스템이 Login 된 이후 일정시간 동안 사용하지 않는다면 시스템을 자동으로 종료 시키거나 Logout시키는 것이 바람직하다.

6.5 ID/Password 유지정책

ID/Password 유지정책이란 개개인의 ID/Password를 유지하는 방법이다.[§ 11.300] 대부분의 기

Main System

Unit Program

로그인

단위 프로그램

권한읽기/쓰기

권한

Main System

Unit Program

로그인

단위 프로그램

권한 (쓰기 포함)

서명 권한


11/35쪽

업 시스템에서 사용하는 방법이다. 예로 다음과 같은 것이다.

• ID/Password : 6자이상, 영문과 숫자 조합사용 • 한번 등록된 ID는 변경 불가 • Password는 1달에 한번씩 변경 • Password는 기존 Password 사용금지

위의 예는 아주 단편적인 예에 불가하다. 어떤 방법으로 규정할 지는 사용자가 결정할 내용이다. 프로그래머가 결정할 사항이 아니므로 고민할 필요는 없다. 그러나 이 사항은 프로그램에 반영되어야 하며, Password 유지 정책에 따라 자료구조가 변경될 가능성도 있다. 그러므로 프로그래머는 반드시 사용자에게 유지 정책을 요청하여 받아야 한다. (나중에 추가작업을 하지 않으려면)

사용자 관리용 프로그램을 만들 때 관리자도 개개인의 비밀번호를 모르도록 하는 것이 올바르며, 또한 DBMS 에 저장되는 비밀번호는 암호화하여 DBMS 로 직접 접근하여 조회할 때도 알아볼 수 없도록 하는 것이 올바르다.

6.6 Access Log

Access Log 는 개념은 명확하지만 프로그래머가 구현하기는 어려운 문제이다. Login 되는 순간 기록을 남기고, Logout 되는 순간 기록을 남겨야 한다. 그러나 Access Log 에는 다음과 같은 문제점들이 있다.

• DB connection error에 의한 Login 실패 (login 기록불가) • 갑작스런 DBMS의 shutdown, DB 접근 불가 (logout 기록불가/모든 작업 불가) • 갑작스런 PC shutdown (logout 기록불가)

위의 오류중에서 가장 우려되는 것은 세번째 것으로 자주 발생된다. 이 문제가 발생되면 Access Log에 Login 기록은 있으나 Logout기록이 없어, 자료의 신뢰성에 문제를 발생시킨다. 현재로서 해결할 수 있는 좋은 대안은 없다. 프로그래머는 각자의 상황에 따라 사용자와 협의하여 진행하는 것이 바람직하다.

Part11을 만족하는 프로그램은 Audit Trail이 되야 하므로 Access Log는 필요 없는 기능일 수 있다. Audit Trail에 대해서는 8장에서 논의할 것이다.

6.7 인력관리 시스템(HR)과 연동

인력관리 시스템은 인력관리만을 목적으로 하기 때문에 회사내의 인력에 관련된 가장 최신의 정보를 보유하고 있는 시스템이다. 프로그래머나 사용자 모두 ID/Password 에 대하여 인력관리 시스템과의 연동을 고려할 것이다.

그러나 인력관리 시스템과의 연동은 매우 조심해야 한다. 국내 제약산업에서 사용하는 인력관리 시스템은 Validation이 안되었을 것이다. Validation이 되지 않아 신뢰성을 보장할 수 없는 시스템에서 Closed System 에서 가장 중요한 요소인 ID/Password 를 가져온다는 것을 생각할 수도 없다. 즉, 인력관리 시스템을 Validation 하던가 아니면 연동은 고려하지 말아야 한다. (이러한 타 시스템과의 연동은 ERP에서도 동일하게 적용된다.)


12/35쪽

6.8 권한 할당

단위 프로그램에 사용자별로 권한을 할당하는 문제는 원리는 간단하지만 구현에는 여러 가지 방법이 있다.

우선 기본적인 자료구조는 다음과 같이 단순하다.

Unit Program Table User Table

Program_Code Program_Name … User_ID User_Name Password …

Unit Program 권한할당 Table

Program_Code User_ID …

[User]Table 과 [Unit Program 권한할당]Table 의 프로그램 사용 도중에 자료의 삽입/수정/삭제가 가능한 Table이지만, [Unit Program]Table은 프로그램 개발전에 삽입되어야 하는 자료이다. 물론 프로그램 사용도중에 삽입/수정/삭제가 불가능하며, 프로그래머가 관리해야 되는 자료이다.

[Unit Program 권한할당]Table 을 이용하여 사용자별 권한을 제한하는 프로그램이 가능하다. 구현방법은 세가지 정도로 요약된다.

• 사용메뉴 중에서 권한이 없는 메뉴를 사용불가(음영)로 만든다. • 사용메뉴 중에서 권한이 없는 메뉴를 보이지 않도록 한다. • 사용자가 Unit Program을 실행할 때 각각의 권한을 검사하여 필요한 조치를 취한다.

필자는 개인적으로 첫번째 방법을 선호하는데, 사용자가 특별히 원하는 방법이 없다면, 프로그래머 개개인의 취향에 따라 구현하면 된다.

Unit Program별 Access Log를 고려할 수도 있는데, 특별한 요구사항이 없다면 구현하지 않는 것이 좋다고 생각한다.

6.4 장에서 논의한 것과 같이 3 단계 권한에 대하여는 첫번재 방법인 [읽기/쓰기] 권한을 별도로 부여한다면, [Unit Program 권한할당]Table에 [Write],[Read] column를 만들어 사용하면 된다.

3단계 권한에 대한 두번째 방법인 서명권한에 대하여는 9항에서 논의하도록 하겠다.


13/35쪽

7 Electronic Record

우선 Electronic Record가 무엇인지 생각해 보자. Part11의 조항을 보면 다음과 같다.

§ 11.3 Definitions (6) Electronic record means any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system. -- 해석하면 (6) 전자기록(Electronic record)은 컴퓨터 시스템에 의해 생성되고, 수정되고, 유지되고, 문서화되고, 조회되고, 배포되는 디지털 형식의 문자, 그림, 자료, 소리, 사진 또는 다른 정보의 모든 조합을 의미한다.

상당히 복잡하다. 항상 논쟁의 대상이 되는 골치 아픈 조항이다. 우리는 이것을 잊어버리고 단순하게 생각하자.

우선 Record 와 Data 의 차이를 생각해 보자. 대부분 동일한 용어로 사용되지만, 굳이 구분하자면 다음과 같이 구분할 수 있다.

• Data : 기록, 저장할 수 있는 알려진 사실 • Record : 기록된 Data

즉 Record 는 기록(보관)을 전재 조건으로 한다는 것이다. 즉, 프로그램을 위하여 돌아다는 수많은 신호와 변수 등은 전자기록이 아니다. 우리가 전자기록으로 고려할 것은 DBMS 에 저장되는 것만으로 국한하면 된다.

자료의 관리는 DBMS 가 책임진다. 요즘 시중에 판매되는 DBMS 는 매우 뛰어난 성능을 가지고 있다. 사용하는 DBMS 의 사용방법을 숙지하고 잘 관리하면 된다. 이러한 DBMS 의 관리 또한 사용자회사의 시스템 관리자의 책임이다. 결국 프로그래머는 DBMS 를 사용하면 그만이다.

프로그래머가 DBMS 의 관리까지 신경 쓸 필요는 없지만, 그래도 DBMS 관리의 중요사항을 생각해 보면 다음 같은 것이 있다.

• 지정된 관리자 • Backup (Backup 기능은 DBMS에서 제공한다. 필요한 것은 Backup 정책이다.) • Restore (Restore 기능은 DBMS에서 제공한다. 필요한 것은 Restore 정책이다.) • DBMS의 보안 (Super User 관리, 보안패치) • DBMS 서버 관리 (물리적 보안, 저장용량, 전원, 과부하)


14/35쪽

8 Audit Trail

8.1 Audit Trail ?

Audit Trail은 사건이 일어난 순서대로 논리적 경로로 연결된 자료형태로 일어날 활동/사건을 처음부터 끝까지 알 수 있는 기록이다. 이러한 기능은 대부분의 시스템에서 중요한 자료에 대하여 적용하고 있는 방법이며, 최근에는 보안을 위하여 특히 많이 사용되는 기능이다.

Audit Trail 은 Part 11 을 준수하는 시스템이라면 반드시 있어야 하는 기능이며 Audit Trail 에 대한 기술적 타당성 조사와 검증이 필요하다. 구체적으로 Part11이 요구하는 Audit Trail 요건은 다음과 같다.[§ 11.10 (e)]

• 전자기록의 삽입/수정/삭제할 때 생성 • 작업자의 조작 없이 자동적으로 생성 • 날짜와 시간 기록(time-stamp) • Audit Trail 대상 전자기록의 보존기간과 동일하게 보존 • 검토와 복사 가능

Audit Trail 은 전자기록의 등록, 변경내용을 확인할 수 있고, 부적절한 자료조작을 찾아낼 수 있고, 작업자의 부인방지를 불가능하도록 한다.

8.2 Audit Trail 구현방법

Audit Trail을 구현하는 방법은 두가지로 생각할 수 있다.

• 자료의 삽입/수정/삭제할 때 별도의 Script 를 이용하여 Audit Trail 용 Table 에 기록하는 방법

• 자료의 삽입/수정/삭제할 DBMS 의 Trigger 를 이용하여 Audit Trail 용 Table 에 기록하는 방법

첫번째 방법은 행위에 대한 Audit Trail 로 작업자가 수행한 행위를 기록하는 것이다. 이것은 프로그램적으로 어떤 자료를 삽입/수정/삭제하는 SQL 뒤에 Audit Trail 하는 SQL 를 별도로 만들어야 한다. 이러한 방법은 모든 Script 에서 Audit Trail 용 SQL 을 만들어야 하고, Audit Trail하려는 행위에 대한 Code를 만들어 할당해야 되고, Transaction에 부담을 준다. 또한 유지보수를 할 때 하나의 SQL 을 수정하기 위하여 2 개의 SQL 을 변경해야 한다. 또한 Validation 을 위하여 각각의 경우마다 Audit Trail 이 이루어 지는지 검사해야 한다. 프로그래밍과 검사에 너무 많은 노력이 필요하다.

두번째 방법은 자료에 대한 Audit Trail 로 DBMS 의 기능인 Trigger 를 이용하여 삽입/수정/삭제마다 Audit Trail 용 Table 에 자료를 삽입하도록 하면 된다. 이 방법은 프로그래머가 Audit Trail 을 위한 별도의 Script 를 생각할 필요가 없다. 하지만 이 방법의 단점은 하나의 Record에 변경이 있을 때 마다 Audit Trail 하므로 원자료를 위하여 예상되는 저장매체의 크기보다 5배정도 큰 저장공간이 필요하다. 요즘 저장매체의 가격이 저렴하므로 큰 무리는 아닐 것으로 생각한다. 또 하나의 단점은 DBMS 가 Trigger 를 지원하지 않는 경우다.(MS Access 는 Trigger 가 없다. 생각하면, MS Access 를 이용하여 프로그램을 개발해야 하는 작은 프로젝트라면 참여하지 않는 것이 좋다.) Trigger가 지원되지 않는다면 별수 없이 Audit Trail용 Script


15/35쪽

를 구성해야 한다. 간혹, 프로그래머 중에는 Trigger 가 신뢰성이 없다고 생각하는 사람도 있을 것이다. 그러나 최신 버전의 DBMS 는 충분히 신뢰할 수 있다고 생각한다. 또한 Trigger의 서버부하도 생각할 수 있으나, 문제될만한 수준은 아니라고 생각한다.

Part11 의 조항의 문헌적 요구사항을 보면 Audit Trail 은 행위(Action)에 대한 것을 요구한다. 따라서 두번째 방법은 정확한 의미에서는 올바르지 않을 수도 있다. 그러나 자료에 대한 완벽한 Audit Trail 은 모든 행동을 추적할 수 있으므로 두번째 방법이 구현하기 쉽고 타당한 방법이라 생각된다.

8.3 Trigger 구성

두번째 방법인 Trigger에 대하여 좀더 자세히 살펴보자

8.3.1 Trigger 의 대상

Part11 은 Audit Trail 의 대상으로 모든 전자기록으로 규정하고 있다. 제약업계에서는 Audit Trail 양이 너무 많아서 부담스럽다는 의견을 FDA 에 제출했는데, FDA 의 답변은 Audit Trail의 범위를 판단하는 문서(Risk Assessment와 같은)를 만들어서 사용하라고 답변했다. 결국 문제를 만들지 않으려면 모든 전자기록에 대하여 Audit Trail하는 것 좋다. 사실 전자기록의 중요도나 절차적인 보호방법을 강구하는 것이 오히려 더 어렵다. 그러니 모든 것을 큰 하드디스크로 해결하는 것이 바람직하다.

8.3.2 Audit Trail 용 Table

생성되는 모든 Table마다 별도의 Audit Trail용 Table을 만들어야 한다.

Audit Trail용 Table은 대상 Table과 동일한 Table구조를 가지며 별도로 다음 column을 추가해야 한다.

추가 column 내용

log_id 로그 식별번호(일련번호)

log_type 로그 식별자 삽입(I), 수정(U), 삭제(D)

log_user_id 로그 USER ID

log_date 로그 시간

Audit Trail 용 Table 은 원본 Table 이 삭제되거나 손상이 있어도 유지되어야 하며, 원본 Table의 악의적인 조작에도 영향을 받지 말아야 한다. 따라서 Audit Trail용 Table과 원본 Table간의 Relation은 설정하지 않는 것이 타당하다.


16/35쪽

예) [원본 Table : rtuser] [Audit Trail용 Table : rtuser_at] - MS SQL 2000을 이용하여 만들어짐

SQL --- Audit Trail 용 Table 생성

if exists (select * from dbo.sysobjects where id = object_id('dbo.rtuser_at') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table dbo.rtuser_at GO SELECT * INTO dbo.rtuser_at FROM dbo.rtuser GO DELETE FROM dbo.rtuser_at GO ALTER TABLE dbo.rtuser_at ADD log_id int IDENTITY, --[로그 식별번호] log_type varchar(1) , --[로그 식별번호] log_user_id varchar(10) , --[로그 USER ID] log_date datetime --[로그 시간] GO ALTER TABLE dbo.rtuser_at ALTER COLUMN log_type varchar(1) NOT NULL ALTER TABLE dbo.rtuser_at ALTER COLUMN log_user_id varchar(10) NOT NULL ALTER TABLE dbo.rtuser_at ALTER COLUMN log_date datetime NOT NULL GO


17/35쪽

8.3.3 Trigger Script

Trigger Script 는 각 DBMS 에서 지원하는 SQL 로 작성하면 된다. 원본 Table 의 삽입/수정/삭제에 대하여 각각 3개씩 만들면 된다.

예) [원본 Table : rtuser] [Audit Trail용 Table : rtuser_at] - MS SQL 2000을 이용하여 만들어짐 - [log_id] column은 MS SQL의 속성을 이용했다.(Oracle을 사용한다면 Sequence 사용)

SQL --- Insert Audit Trail Trigger 생성

IF EXISTS (SELECT name FROM dbo.sysobjects WHERE name = 'rtr_rtuser_i' AND type = 'TR') DROP TRIGGER dbo.rtr_rtuser_i GO CREATE TRIGGER dbo.rtr_rtuser_i ON dbo.rtuser FOR INSERT AS ------------------------------------------------------------- -- 내용 : insert audit trail trigger -- 버전 : 1.0 -- 작성자 : 유재훈 -- 작성일 : 2002/09/13 ------------------------------------------------------------- BEGIN INSERT INTO rtuser_at SELECT * , 'I', MODIFY_ID, GETDATE() FROM inserted END GO

SQL --- Update Audit Trail Trigger 생성 IF EXISTS (SELECT name FROM dbo.sysobjects WHERE name = 'rtr_rtuser_u' AND type = 'TR') DROP TRIGGER dbo.rtr_rtuser_u GO CREATE TRIGGER dbo.rtr_rtuser_u ON dbo.rtuser FOR UPDATE AS ------------------------------------------------------------- -- 내용 : update audit trail trigger -- 버전 : 1.0 -- 작성자 : 유재훈 -- 작성일 : 2002/09/13 ------------------------------------------------------------- BEGIN INSERT INTO rtuser_at SELECT * , 'U', MODIFY_ID, GETDATE() FROM inserted END GO


18/35쪽

SQL --- Delete Audit Trail Trigger 생성 IF EXISTS (SELECT name FROM dbo.sysobjects WHERE name = 'rtr_rtuser_d' AND type = 'TR') DROP TRIGGER dbo.rtr_rtuser_d GO CREATE TRIGGER dbo.rtr_rtuser_d ON dbo.rtuser FOR DELETE AS ------------------------------------------------------------- -- 내용 : delete audit trail trigger -- 버전 : 1.0 -- 작성자 : 유재훈 -- 작성일 : 2002/09/13 ------------------------------------------------------------- BEGIN INSERT INTO rtuser_at SELECT * , 'D', MODIFY_ID, GETDATE() FROM deleted END GO


19/35쪽

9 Electronic Signature

9.1 Electronic Signature ?

전자서명(ES)이라고 하면 대부분의 프로그래머는 전자상거래에서 사용되는 암호화된 방법을 생각할 것이다. 그러나 Part11 에서 말하는 ES 는 단순하다. 단순이 서명을 했다는 플래그형 자료일 뿐이다. Part11 에서 요구하는 전자서명은 전자기록 관점에서 보면 단지 하나의 기록일 일뿐이다.

국내에서 통용되는 전자서명이란, Part11에서 디지털 서명(Digital Signature)[§ 11.3 (5)]으로 규정하고 있으며, 전자서명의 방식을 디지털 서명으로 구현하면 좋지만 디지털 서명은 Open System을 위한 보안적인 방법이다.

그러나, Part11 은 전자서명을 구현하는 방법으로 많은 것을 요구하고 있으며 매우 구체적으로 우리에게 필요한 조항은 다음과 같다.

Part11 조항 내용

§ 11.50 (a) (1) 서명자의 인쇄된 이름 ( ID 뿐만 아니라)

§ 11.50 (a) (2) 서명이 실시된 날짜와 시간

§ 11.50 (a) (3) 서명과 관련되는 의미(비평, 승인, 책임 또는 저작 같은)

§ 11.50 (b) ER 과 동일한 제어가 필요하고 인간이 읽을 수 있는 형태의 일부로 포함되

어야 한다.

§ 11.70 ER 에 실행되는 ES 와 수기서명은 각각의 ER 과 연결되어야 한다. (ER –

ES Link)

§ 11.100 (a) 각 ES 는 각각 개인별로 유일해야 하며 다른 누군가가 재사용하거나 재서명

할 수 없다. (대리 서명을 할 경우, 대리자의 서명을 해야 한다.)

§ 11.200 (a) (1) ID 와 Password 같은 적어도 2 개 이상 별도의 식별 구성요소를 사용 해야

한다.

§ 11.200 (a) (1) (i) 한번 또는 연속적인 기간동안 여러 번 서명을 실시할 때, 첫번째 서명은 모

든 전자서명의 구성요소를 사용하여 실시되어야 한다: 이후의 서명은 하나

이상의 전자서명 구성요소를 이용하여 실시되어야 한다.

§ 11.200 (a) (1) (ii) 연속적이지 않은 기간동안 여러 번 서명을 실시했다면, 각 서명은 모든 전

자서명 구성요소를 이용하여 실시되어야 한다.

§ 11.200 (a) (2) 서명 구성요소의 진짜의 주인에 의해서만 사용되어야 한다.

§ 11.200 (a) (3) 진짜 주인이외의 누군가에 의해 개인의 전자서명 사용 시도에 두개 이상의

구성요소가 필요하다는 것을 확실히 하기 위하여 관리하고 실행한다.

많은 사람들이 오해하고 있는 것은 수기서명을 스캔한 서명그림파일에 대한 것이다. 서명그림파일은 전자서명과 아무런 관계가 없다. 사용자의 사진과 같은 사용자 정보의 일종이다. 이러한 서명그림파일을 종이출력의 적당한 위치에 출력해도 전자서명에 해당하는 아무런 효력이 없다. 전자서명은 위에서 열거한 요구조건을 충족시킬 때 유효성이 있다.


20/35쪽

9.2 자료구조

9.2.1 자료저장방법

서명에 대한 자료를 저장하는 방법은 크게 두가지로 생각할 수 있다. (이것은 직접적으로 [§ 11.70]과 관련된다.) 각각의 서명은 일련의 업무절차에서 발생되는 것으로 서명자료만 별도로 생성되는 것이 아니라 특정 업무를 위한 기록과 연결되어 있다. 각각의 기록과 연결될 수 있도록 저장하는 방법은 다음과 같이 두가지로 생각할 수 있다.

• 서명기록을 근거기록에 저장한다. (같은 자료(Table)이므로 연결할 필요가 없다.) • 서명기록과 근거기록을 분리하여 저장한다.(둘 사이에 유일한 연결 매개변수를 이용,

Table간 relation을 이용)

현재 고려되는 있는 프로그램은 DBMS 를 사용하는 방법이다. 우리가 사용할 DBMS 는 RDBMS 일 것이다. RDB 의 근본적인 원리인 entity 와 relation 을 고려한 DB Modeling 과 Normalization을 생각한다면 당연히 두번째 방법을 선택해야 한다.

따라서 업무기록에는 실시한 서명에 대한 서명고유번호만을 기록한다. 서명 Table 에서 서명고유번호를 Primary Key 하는 상세정보를 기록해야 한다. 이러한 일반적이서 추가적인 설명이 필요 없을 것이다.

좀더 심사숙고 할 것은 서명권한을 개개 사용자에게 부여할 수 있는 방법과(6.4 장의 두번째 방법) 실시된 서명정보를 저장할 방법이다. 요구조건을 반영할 수 있는 자료구조로는 3 개의 Table 을 이용한 방법을 생각할 수 있다. 3 개의 Table 을 각각 아래와 같이 명명하였다. 부여된 Table이름과 Column명/속성은 필자가 개인적으로 판단한 것이다. 참고하기 바란다. (이후 아래의 글에서는 필자가 제시한 Table 명과 Column 을 사용하여 설명할 것이므로 숙지하기 바란다.)

• 서명설정 Table : [rtsignset] • 서명설정상세(권한할당)Table : [rtsignsetdt] • 서명 Table : [rtsign]


21/35쪽

9.2.2 서명설정 Table (rtsignset)

우선 프로그램에서 사용되는 서명의 상세내역을 정의하는 [rtsignset]Table이 필요하다.

고유한 서명설정번호와 서명명칭, 각각의 서명이 사용될 때 서명자료가 입력될 Table, Column, 등의 특성 정보를 입력한다.

사용될 서명이 무엇인가는 프로그램의 개발과 밀접한 관계가 있다. 프로그래머는 프로그램하기 전에 사용자와 업무절차를 논의하여 필요한 서명을 규정해야 한다. [rtsignset]Table에 입력될 서명설정에 대한 자료는 프로그래머가 직접 만들어야 한다. 당연히 문서화해야 하고, DB 에 직접 입력해야 한다. [rtsignset]Table 의 자료는 프로그램의 구조/절차에 민감한 자료이므로 사용자가 변경할 수 없어야 한다.

9.2.3 서명설정상세 Table (rtsignsetdt)

서명설정상세[rtsignsetdt]Table 은 해당 정해진 서명을 할 수 있는 사용자를 등록하는 Table 이다. 즉, 서명권한을 등록하는 Table 이다. Part11 의 [§ 11.100 (a)]을 만족하기 위하여 [구분(kind)]column을 넣었다. [구분(kind)]column에는 등록되는 사용자가 책임자인지 대리자인지를 구별하는 column이다. 사용자의 서명권한은 시스템관리자가 조직의 변동에 따라 적절한 권한을 부여해야 하므로 관리할 수 있는 단위 프로그램을 개발해야 한다.


22/35쪽

Table간에 relation은 아래와 같이 고려해야 한다.

Primary Key Foreign Key

Rtsignset sign_set_no ┼────○<

rtsignsetdt sign_set_no

9.2.4 서명 Table (rtsign)

서명[rtsign]Table은 실시된 서명의 상세정보를 기록하는 Table이다. [서명번호(sign_no)]column 은 실시된 서명의 고유번호이다. 자동생성되야 한다. (max 방식 추천) [서명설정번호(sign_set_no)]와 [서명자(sign_id)]column 은 [rtsignsetdt]Table 에서 확인된 정보를 기록한다. [대리여부(deputy_yn)]column 은 [rtsignsetdt].[kind]에서 확인되 대리여부를 기록한다. 대리여부는 서명권한의 변경에 따라 [rtsignsetdt]Table 의 정보가 변하므로 [rtsign]Table 에 서명 실시 당시의 내용을 기록한다. [서명내용(content)]column 은 서명의 간략한 설명으로 [rtsignset].[sign_set_name]을 이용해도 되고 프로그래머가 적절한 내용을 삽입해도 된다. [rtsignsetdt]Table과 relation은 아래와 같이 고려할 수 있다.

Primary Key Foreign Key

rtsignsetdt sign_set_no rtsign sign_set_no

rtsignsetdt user_id

┼────○<

rtsign sign_id

그러나 [rtsignsetdt]Table 과의 relation 은 반드시 필요한 것은 아니며, 경우에 따라서는 필요 없다. [rtsignsetdt]Table 의 자료는 계속적으로 변경이 있을 수 있고, 삭제를 허용하는 방법으로 프로그래밍 한다면 relation 때문에 [rtsign]Table 에 영향을 줄 수 있으므로 조심해야 한다. 중요한 것은 [rtsign]Table 에 기록되는 자료는 서명이 실시되는 순간 [rtsignsetdt]Table 의 자료를 반영하지만 이후의 [rtsignsetdt]Table의 변경이 [rtsign]Table에 영향이 미치면 안된다.

9.2.5 서명기록과 근거기록의 연결

9.2.1 장에서 설명한 것과 같이, 서명기록과 근거기록의 연결은 명확하다. 근거기록에는 서명일련번호를 기록하고 서명 Table에 서명상세를 기록하면 된다.


23/35쪽

예) 자료구조

예) 실제사용


24/35쪽

9.3 전자서명과 ID/Password 전자서명과 ID/Password의 관계는 [§ 11.200 (a) (1) ]에 명확하게 나와있다. 전자서명이 필요한 순간에 ID/Password 를 이용하여 현 서명자를 확인하는 것이다. 확인해야 할 사항은 반드시 2 개 이상의 별도의 식별 구성요소를 사용해야 한다는 것이다. 서명을 하는 순간은 이미 Login 되어 있는 상태이므로 대부분의 시스템에서 Password 만 다시 확인하는 경향이 있지만, Part11를 만족하려면 2개 이상, 즉, ID/Password를 모두 사용하여 현 서명자를 확인해야 한다. [§ 11.200 (a) (1) (i)]과 [§ 11.200 (a) (1) (ii)]는 ID/Password의 사용에 모호함을 발생시킨다. 문구상으로는 연속적인 기간(continuous period)동안 사용되는 이후 서명(subsequent signings)은 하나의 식별요소(password)만을 사용할 수 있다고 정의하고 있다. 그러나 연속적인 기간(continuous period)이란 용어는 명확하게 구별할 수 없는 요소이다. 어떤 상태를 연속적인 기간으로 볼 것인가? 단지 처음 Login 이후 모두 연속적인 기간인가? 사용자가 작업중에 커피를 위하여 모니터 앞에서 잠시 자리를 비운다면 연속적인 기간인가? (어렵다) 이런 모호한 규정에 머리가 아프지만 고민을 뒤로하고, 모든 전자서명에 ID/Password 를 2 개 모두 사용한다면 문제는 해결된다. 서명순간에는 ID/Password 용 Popup 창을 이용하면 된다. 보안을 위하여 몇번이상 실패하면 프로그램을 종료시키거나 ID/Password를 잠그는(lock)것이 바람직하다.

9.4 대리서명 모든 곳에는 대리서명이 있다. 대리서명은 부적절하므로 허용하지 않는 것이 바람직하는 생각은 문제를 만드는 지름길이다. 현실적으로 발생하는 대리서명에 대하여 명확한 대응책을 구현하는 것이 바람직하다. Part11 조항에는 대리서명에 대한 내용은 없다. 그러나, [§ 11.100 (a)], [§ 11.100 (b)], [§ 11.200 (a) (2)]등을 이용하여 유추해석하면, 대리서명자는 대리서명자로 별도의 권한을 부여하는 것이 타당하다. (대리서명권한이 없이 상사의 ID/Password 를 이용하여 서명을 실시한다면 Part11을 위반하는 치명적인 결과를 야기할 것이다.) 대리서명권한의 할당은 9.2.3장에서와 같이 [rtsignsetdt]Table의 [구분(kind)]column을 이용하여 [책임]/[대리]를 구분하면 된다. 당연히 동일 서명에 대하여는 책임자는 한명이고 반드시 존재해야 한다.

9.5 전자서명의 표현

서명된 전자서명을 화면에 표시하거나 출력물로 나타낼 때 필요한 조건이 있다. 이러한 전자서명의 표현에 관한 문제는 저장되는 자료구조와 밀접하지만 반드시 일치하는 것은 아니다. Part11 에서 요구하는 것은 다음과 같다. 또한 대리서명과 관련해서 추가적인 내용이 필요하다.


25/35쪽

• 서명자 이름 [§ 11.50 (a) (1)] • 서명 날짜 & 시간 (Time-Stamp) [§ 11.50 (a) (2)] • 서명 관련 의미 [§ 11.50 (a) (3)] • 대리여부 • 대리서명이라면 책임자

이러한 내용을 확인해 볼 수 있는 좋은 자료가 있어 소개한다. 아래의 그림은 FDA 에서 자체적으로 사용중인 전자서명 시스템의 출력물이다.

위의 그림에서 보면 실제 서명은 없고 [/s/]라는 것으로 위치만 표시한다. (전자서명이므로 서명그림은 의미가 없다.) 서명자의 ID 도 없으며 이름을 사용한다. 서명이 실시된 날짜(Time-Stamp)가 있다. 서명에 대한 의미/목적은 없는데 아마도 이 문서는 FDA 에서 발행하는 ‘Warning Letter’로 서명자의 의견을 기술하는 편지형식의 문서로 서명과 관련되는 특별한 의미가 없는 것으로 생각된다. 또한 책임자 ‘Thomas W. Abrams’ 대신 ‘Barbara Chong’이 대신 서명한 것을 알 수 있다. 즉 책임자와 현재 서명자를 관계를 알 수 있다. 필자가 앞에서 구성한 자료구조 [rtsign]Table 은 위에 열거한 모든 것을 포함할 수 있다. 단 서명자의 이름대신 ID 만 있는데, ID 를 이용하여 [user]Table 과 join 하여 조회하면 서명자의 이름을 얻을 수 있다. 아래 그림은 [rtsign]Table을 이용하여 구현한 예이다.


26/35쪽

9.6 전자서명 절차 순서도 필자가 전자서명을 구현하기 위하여 위에서 설명한 내용을 순서도로 나타내면 다음과 같다.

서명설정 번호조회

서명설정사용가능여부

해당 서명설정권한자 조회

현재 로그인 사용자의 권한 유무

ID/Pass 재입력

현재 로그인 사용자와ID/Pass 일치여부

대리일 경우계속 진행여부

서명 일련번호 할당

서명 대장 저장

DataBase오류 메시지

YES

NO

YES

YES

YES

1

1

1

1

FAIL

FAIL

FAIL

FAIL

1

작업 실패 / Return2

2

2작업진쟁 불가능

오류 메시지

서명권한 없음오류 메시지

NO

서명자 권한의책임자 여부

YES

NO

2NO

3회 반복

YES

NO

프로그램 종료

2

Electronic Signature Process


27/35쪽

10 참고문헌

• FDA 21 CFR Part 11 Electronic Records; Electronic Signatures: Final Rule. • ISPE GAMP Forum, GAMP4, The Good Automated Manufacturing Practice(GAMP) Guide for

Validation of Automated System, ISPE, 2001.12 • 유재훈, ‘Automated System Validation’, www.validation.co.kr, 2002.12 • 유재훈, ‘21 CFR Part 11에 대한 고찰’, www.validation.co.kr, 2003. 3 • 유재훈, ‘GAMP 용어해석’, www.validation.co.kr, 2003. 2


28/35쪽

첨부 Part 11 조항

Section Sub. Content 11.1 Scope 11.1 Scope (a) The regulations in this part set forth the criteria under which the agency

considers electronic records, electronic signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records and handwritten signatures executed on paper. Part 11 은 전자기록, 전자서명, 전자기록에 행하여 지는 수기서명이 신뢰성 있고, 기존 종이기록, 수기서명과 동일하기 위한 기준이다.

11.1 Scope (b) This part applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted, under any records requirements set forth in agency regulations. This part also applies to electronic records submitted to the agency under requirements of the Federal Food, Drug, and Cosmetic Act and the Public Health Service Act, even if such records are not specifically identified in agency regulations. However, this part does not apply to paper records that are, or have been, transmitted by electronic means. Part 11 은 당국의 규정 내에서 만들어지고, 수정되고, 유지되고, 보관

되고, 조회되고, 보내어지는 전자적인 형식의 기록에 적용한다. Federal Food, Drug, and Cosmetic Act / Public Health Service Act 에 제출하는 전자기록에도 적용한다. 전자수단을 통하여 보내는 종이기록에는 적용하지 않는다. # 종이로 저장되고 유지되는 컴퓨터 시스템은 포함하지 않는다 – 워드프로세서 # 팩스는 적용되지 않는다.

11.1 Scope (c) Where electronic signatures and their associated electronic records meet the requirements of this part, the agency will consider the electronic signatures to be equivalent to full handwritten signatures, initials, and other general signings as required by agency regulations, unless specifically excepted by regulation(s) effective on or after August 20, 1997. Part 11 의 요구사항을 만족할 때, 수기서명과 동일하다고 판단할 것이다. (특히 1997 년 8 월 20 일에 이후부터 적용)

11.1 Scope (d) Electronic records that meet the requirements of this part may be used in lieu of paper records, in accordance with Sec. 11.2, unless paper records are specifically required. 종이 기록이 특별히 필요하지 않는 한, Sec. 11.2 에 따라, Part 11 의 요구사항에 일치하는 전자기록이 종이기록을 대신하여 사용될 것이

다. 11.1 Scope (e) Computer systems (including hardware and software), controls, and

attendant documentation maintained under this part shall be readily available for, and subject to, FDA inspection. Part 11 에 따라 유지되는 컴퓨터 시스템, 제어기, 관련문서는 FDA 실사에 이용할 수 있도록 준비되어야 한다.

11.2 Implementation 11.2 Implementation (a) For records required to be maintained but not submitted to the agency,

persons may use electronic records in lieu of paper records or electronic signatures in lieu of traditional signatures, in whole or in part, provided that the requirements of this part are met.


29/35쪽

Section Sub. Content 당국에 제출하지 않지만 유지해야 하는 전자기록과 전자서명은 Part 11 의 요구사항을 만족해야 한다.

11.2 Implementation (b) For records submitted to the agency, persons may use electronic records in lieu of paper records or electronic signatures in lieu of traditional signatures, in whole or in part, provided that: 당국에 제출하는 전자기록과 전자서명은 다음과 같다.

11.2 Implementation (b) (1) The requirements of this part are met; and Part 11 의 요구사항을 만족해야 한다.

11.2 Implementation (b) (2) The document or parts of a document to be submitted have been identified in public docket No. 92S-0251 as being the type of submission the agency accepts in electronic form. This docket will identify specifically what types of documents or parts of documents are acceptable for submission in electronic form without paper records and the agency receiving unit(s) (e.g., specific center, office, division, branch) to which such submissions may be made. Documents to agency receiving unit(s) not specified in the public docket will not be considered as official if they are submitted in electronic form; paper forms of such documents will be considered as official and must accompany any electronic records. Persons are expected to consult with the intended agency receiving unit for details on how (e.g., method of transmission, media, file formats, and technical protocols) and whether to proceed with the electronic submission. 당국이 인정하는 전자형식의 제출물 형태가 docket(소송 사건 일람

표) No. 92S-0251 에 분류되어 있다. Docket 에는 허용되는 전자형태와 제출물의 접수처를 규정한다. Docket 에는 규정되지 않은 접수처로 수신된 전자적 형태의 문서는 인정되지 않는다 # 당국에 제출하는 문서도 전자기록과 전자서명이 가능하다.

11.3 Definitions 11.3 Definitions (a) The definitions and interpretations of terms contained in section 201 of

the act apply to those terms when used in this part. 법령 Section 201 에서 정의한 동일한 용어를 사용한다.

11.3 Definitions (b) The following definitions of terms also apply to this part: 또한 다음 용어를 적용한다

11.3 Definitions (1) Act means the Federal Food, Drug, and Cosmetic Act (secs. 201-903 (21 U.S.C. 321-393)). 법령(Act)은 Federal Food, Drug, and Cosmetic 법령을 의미한다.

11.3 Definitions (2) Agency means the Food and Drug Administration. 당국(Agency)은 FDA 를 의미한다

11.3 Definitions (3) Biometrics means a method of verifying an individual's identity based on measurement of the individual's physical feature(s) or repeatable action(s) where those features and/or actions are both unique to that individual and measurable. 생체인식(Biometrics)은 개인의 신체적 특징이나 독특하고 측정 가능

한 특징이나 행동에 근거한 표준적인 행위에 기초하여 개인의 신원

을 입증하는 방법을 의미한다. 11.3 Definitions (4) Closed system means an environment in which system access is

controlled by persons who are responsible for the content of electronic records that are on the system. 폐쇄계(Closed system)는 시스템의 접근이 시스템의 전자기록 내용에


30/35쪽

Section Sub. Content 대하여 책임이 있는 사람에 의하여 통제되는 환경을 의미한다. # 단지 물리적 통제만을 의미하는 것은 아니다. 따라서 공공라인(인터넷, 전화)을 통한 시스템도 관리자가 존재한다면 경우에 따라 폐쇄

계로 볼 수 있다. 그러나, 이럴 경우 부가적인 인증이 필요하다. 11.3 Definitions (5) Digital signature means an electronic signature based upon

cryptographic methods of originator authentication, computed by using a set of rules and a set of parameters such that the identity of the signer and the integrity of the data can be verified. 디지털서명(Digital signature)은 서명자 확인과 자료의 완전무결을 확인할 수 있는 일련의 규칙과 일련의 매개변수로 처리되어지며, originator 확인을 암호적 방법에 근거한 전자서명을 의미한다. # ‘전자서명’의 일부인 ‘디지털서명’을 ‘전자서명’과 동의어로 생각해서

는 안된다. 11.3 Definitions (6) Electronic record means any combination of text, graphics, data, audio,

pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system. 전자기록(Electronic record)은 컴퓨터 시스템에 의해 생성되고, 수정되

고, 유지되고, 문서화되고, 조회되고, 배포되는 디지털 형식의 문자, 그림, 자료, 소리, 사진 또는 다른 정보의 모든 조합을 의미한다.

11.3 Definitions (7) Electronic signature means a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual's handwritten signature. 전자서명(Electronic signature)은 개인의 수기 서명과 동일한 법적 구속력을 가지며, 개인에 의하여 실행, 채택 또는 인증되는 일련의 기호를 컴퓨터 데이터화 한 것을 의미한다.

11.3 Definitions (8) Handwritten signature means the scripted name or legal mark of an individual handwritten by that individual and executed or adopted with the present intention to authenticate a writing in a permanent form. The act of signing with a writing or marking instrument such as a pen or stylus is preserved. The scripted name or legal mark, while conventionally applied to paper, may also be applied to other devices that capture the name or mark. 수기서명(Handwritten signature)은 불변의 형태로서 본인임을 확인하

기 위해 현재 시행되거나 채택된 것으로 개인에 의해 수기로 작성된 서명 이름이나 법적 표시를 의미한다. # 만약 수기서명을 그림파일 등으로 관리할 경우 이것은 전자서명이 아니다. 그러나, 이럴 경우 이것은 전자기록으로 취급되어 전자기록

과 동일한 통제를 해야 한다. 11.3 Definitions (9) Open system means an environment in which system access is not

controlled by persons who are responsible for the content of electronic records that are on the system. 열린계(Open system)는 시스템의 접근이 시스템의 전자기록 내용에 대하여 책임이 있는 사람에 의하여 통제되지 않는 환경을 의미한다.

11.10 Controls for closed systems

Persons who use closed systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, when appropriate, the confidentiality of electronic records, and to ensure that the signer cannot readily repudiate the signed record as not genuine. Such procedures and controls shall include the following: 폐쇄계에서는 신뢰성, 무결성, 비밀성을 확실히 하고, 서명자가 자신

이 행한 전자기록을 부인할 수 없도록 설계된 절차와 통제에 따라


31/35쪽

Section Sub. Content 사용해야 한다. # 모든 생성되는 전자기록이 통제에 따라야 한다. # 단지 최종결과나 자료의 적합성만 통제대상이 아니다. # 컴퓨터 시스템의 내부감사가 필요하다.


(a) Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. 정확성, 신뢰성, 일관성 있는 수행, 무효한 것이나 수정된 기록을 인식하는 능력을 확실히 하기 위한 시스템 검증. # 모든 검증자료를 준비해야 한다. # 무효한 자료나 변경자료도 언제, 누가 어디서 처리했는지 알 수 있어야 한다


(b) The ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency. Persons should contact the agency if there are any questions regarding the ability of the agency to perform such review and copying of the electronic records. 당국에 의한 실사, 검토, 복사를 위해 인간이 판독 가능하고 적합한 전자형식으로 기록을 정확하고 완벽하게 생성시킬 수 있는 능력. # 폐기되거나 업그레이드된 시스템에서 반드시 구 시스템 장치를 유지할 필요는 없다. 그러나, 새로운 시스템에 완벽하게 자료를 이관하

고, 이를 검증해야 한다 11.10 Controls for closed systems

(c) Protection of records to enable their accurate and ready retrieval throughout the records retention period. 기록 보존기간 동안 정확하고 재빠른 조회를 가능하게 하는 기록의 보호


(d) Limiting system access to authorized individuals. 검증된 개인에게만 제한된 시스템 접근


(e) Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying. 전자기록을 생성, 수정, 삭제하는 조작자 행위를 날짜와 시간이 독립

적으로 기록되고(time-stamp 된), 컴퓨터로 자동 생성되는 audit trail. 기록변경은 이전에 기록정보를 손상시키면 안 된다. audit trail 문서는 최소한 해당 전자기록의 보존기간 동안 보존되어야 하며 당국의 감토와 복사가 가능해야 한다. # audit trail 은 사용자의 작업과 상관없이 작동해야 한다.


(f) Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate. 적절히 허가된 순차적인 순서와 업무로 실시되는 운영시스템 검사


(g) Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand. 오직 검증된 개인의 시스템 사용, 전자적 서명, 작업이나 컴퓨터 시스템의 입출력 장치의 접근, 기록의 수정, 직접 작업수행을 확인하는 인증검사.


32/35쪽

Section Sub. Content # 절차, 시스템의 논리적 접근통제, 정의된 전자서명뿐만 아니라 물리적인 접근통제도 관련된다.


(h) Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction. 적절히 자료입력이나 운영지시의 출처 유효성을 확인하는 장비검사


(i) Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks. 전자기록/전자서명 시스템을 개발하거나, 유지하거나, 사용하는 사람

들이 그들에게 할당된 일을 수행할 수 있는 교육, 훈련, 경험이 있어

야 한다. 11.10 Controls for closed systems

(j) The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record and signature falsification. 기록과 서명의 변조를 막기 위하여 자신의 전자서명으로 이루어진 행위에 대하여 각 개인이 책임이 있음을 문서화한 정책의 확립과 준수 # 타인이 전자서명을 할 경우도 해당 전자서명도 본인이 서명한 것과 동일한 책임이 있다.


(k) Use of appropriate controls over systems documentation including: 다음을 포함하는 시스템 문서에 대한 적절한 통제:


(k) (1) Adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance. 시스템 운영과 유지를 위하여 배포, 접근, 사용하는 문서의 적절한 통제.


(k) (2) Revision and change control procedures to maintain an audit trail that documents time-sequenced development and modification of systems documentation. 시스템 문서의 개발과 수정이 시간순서로 문서화되는 audit trail 이 유지되는 개정과 변경통제 절차. # 문서는 자동적으로 audit trail이 되어야 한다. # 문서관리 시스템을 사용하는 것이 바람직 하다.

11.30 Controls for open systems

Persons who use open systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, the confidentiality of electronic records from the point of their creation to the point of their receipt. Such procedures and controls shall include those identified in Sec. 11.10, as appropriate, and additional measures such as document encryption and use of appropriate digital signature standards to ensure, as necessary under the circumstances, record authenticity, integrity, and confidentiality. 전자기록을 생성하고, 수정하고, 유지하고, 전송하기 위하여 오픈 시스템을 사용하는 사람은 생성과 접수 시점까지 전자기록의 신뢰성, 무결성, 비밀성을 확실히 하기 위해 고안된 절차와 관리를 따라야 한다. 그러한 절차와 통제는 Section 11.10(Closed system 의 통제)에 있고, 기록의 신뢰성, 무결성, 비밀성을 확실히 하는 문서의 암호화와 적절

한 디지털 서명과 같은 추가적인 수단(open system 환경에서 필요

한)이 있다. 11.50 Signature manifestations


33/35쪽

Section Sub. Content 11.50 Signature manifestations

(a) Signed electronic records shall contain information associated with the signing that clearly indicates all of the following: 서명된 전자기록은 다음의 정보를 포함해야 된다:

11.50 Signature manifestations

(a) (1) The printed name of the signer; 서명자의 인쇄된 이름 # 서명자의 이름은 유일하지 않다. # ID 는 이름의 대용품이 아니다.


(a) (2) The date and time when the signature was executed; and 서명이 실시된 날짜와 시간


(a) (3) The meaning (such as review, approval, responsibility, or authorship) associated with the signature. 서명과 관련되는 의미(비평, 승인, 책임 또는 저작 같은)


(b) The items identified in paragraphs (a)(1), (a)(2), and (a)(3) of this section shall be subject to the same controls as for electronic records and shall be included as part of any human readable form of the electronic record (such as electronic display or printout). (b) (a)(1), (a)(2), (a)(3)에 분류된 항목은 전자기록과 동일한 제어가 필요하고 인간이 읽을 수 있는 형태(전자표시기 또는 인쇄물과 같은)의 일부로 포함되어야 한다. # 전자서명은 전자기록의 특수한 형태이다.

11.70 Signature/record linking

Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means. 전자기록에 실행되는 전자서명과 수기서명은 각각의 전자기록과 연결되어야 한다.

11.100 General requirements


(a) Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else. 각 전자서명은 각각 개인별로 유일해야 하며 다른 누군가가 재사용

하거나 재서명할 수 없다. # 대리 서명을 할 경우, 대리자의 서명을 해야 한다.


(b) Before an organization establishes, assigns, certifies, or otherwise sanctions an individual's electronic signature, or any element of such electronic signature, the organization shall verify the identity of the individual. 개개인의 전자서명 또는 전자서명의 모든 요소를 확립, 할당, 증명, 인증하기 전에 조직은 개개인의 신원을 확인해야 한다.


(c) Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding equivalent of traditional handwritten signatures. 전자서명을 사용할 사람은, 사용전이나 사용할 때, 그 전자서명 시스

템이 전통적인 수기서명과 법적 구속력이 동일하다는 것을 당국에 증명해야 한다. (1997 년 8 월 20 일 이후)


(c) (1) The certification shall be submitted in paper form and signed with a traditional handwritten signature, to the Office of Regional Operations (HFC-100), 5600 Fishers Lane, Rockville, MD 20857.


34/35쪽

Section Sub. Content 증명서는 종이형태로 전통적인 수기서명이 되어 the Office of Regional Operations (HFC-100), 5600 Fishers Lane, Rockville, MD 20857 로 제출되어야 한다.


(c) (2) Persons using electronic signatures shall, upon agency request, provide additional certification or testimony that a specific electronic signature is the legally binding equivalent of the signer's handwritten signature. 전자서명을 사용할 사람은, 당국의 요청에, 서명자의 수기서명과 법적 구속력이 동일하다는 전자서명 상세의 추가적인 증명서나 증명을 제출해야 한다.

11.200 Electronic signature components and controls


(a) Electronic signatures that are not based upon biometrics shall: 생체인식에 의거하지 않는 전자 서명은 다음과 같다:


(a) (1) Employ at least two distinct identification components such as an identification code and password. ID 와 암호 같은 적어도 2 개 이상 별도의 식별 구성요소를 사용한다. # 전자서명은 검토절차가 있어야 하며, 편리하면 안 된다. # 관리자도 암호를 알 수 없어야 한다.


(a) (1) (i) When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual. 한번 또는 연속적인 기간동안 여러 번 서명을 실시할 때, 첫번째 서명은 모든 전자서명의 구성요소를 사용하여 실시되어야 한다: 이후의 서명은 하나 이상의 전자서명 구성요소를 이용하여 실시되어야 한다.


(a) (1) (ii) When an individual executes one or more signings not performed during a single, continuous period of controlled system access, each signing shall be executed using all of the electronic signature components. 연속적이지 않은 기간동안 여러 번 서명을 실시했다면, 각 서명은 모든 전자서명 구성요소를 이용하여 실시되어야 한다.


(a) (2) Be used only by their genuine owners; and 서명 구성요소의 진짜의 주인에 의해서만 사용되어야 한다.


(a) (3) Be administered and executed to ensure that attempted use of an individual's electronic signature by anyone other than its genuine owner requires collaboration of two or more individuals. 진짜 주인이외의 누군가에 의해 개인의 전자서명 사용 시도에 두개 이상의 구성요소가 필요하다는 것을 확실히 하기 위하여 관리하고 실행한다.


(b) Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by anyone other than their genuine owners. 생체인식에 의거하는 전자서명은 그들이 진짜의 주인이외의 누군가

에 의해 사용할 수 없다는 것을 확실히 하기 위하여 설계되어야 한다.

11.300 Controls for identification codes/passwords

Persons who use electronic signatures based upon use of identification codes in combination with passwords shall employ controls to ensure their security and integrity. Such controls shall include:


35/35쪽

Section Sub. Content ID 와 암호의 조합에 의거한 전자서명을 사용하는 사람은 그들의 보안과 무결성을 확실히 하기 위하여 통제되어야 한다.


(a) Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password. 각 ID 와 암호의 조합의 유일성 보존.


(b) Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging). ID 와 암호 배포가 정기적으로 점검, 회수, 개정 (예를 들면, 암호기간 만료)


(c) Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identification code or password information, and to issue temporary or permanent replacements using suitable, rigorous controls. 전자적 미인증 분실, 도난, 행방불명, 잠재적 위험 토큰, 카드와 식별

코드와 암호정보를 생성하는 장치의 적절하고 엄격한 통제(분실관리 절차)


(d) Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management. ID 와 암호의 미승인 사용을 막고 미승인된 사용시도를 즉각적이고 긴급히 찾아내어 보고하는 취급보호 활동(조직적으로 관리) # password 오류 입력 3 회 이상일 때 id 사용금지 # login 후 5 분 이상 미 작업시 종료


(e) Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or password information to ensure that they function properly and have not been altered in an unauthorized manner. 올바르게 작동하고 미 승인된 방법으로 변경되어 질 수 없는 ID 와 암호정보를 생성하는 토큰이나 카드와 같은 장치의 초기화와 주기적

인 검사.