FDA 21 CFR Part 11是美国食品药品监督管理局（FDA）针对电子记录和电子签名的法规。其目的是确保电子记录和签名的真实性、完整性、可靠性能够等同于纸质记录和手写签名 。Part 11对于电子签名系统提出了多方面要求，主要包括：身份验证、审计追踪、数据完整性与防篡改、系统验证，以及用户权限和访问控制等。

身份验证机制（Authentication）

Part 11要求电子签名必须是唯一定义并可追溯到个人的，这意味着每位用户必须有唯一的身份（如用户名或账号），电子签名不得在不同人员间共用或重用 。同时，法规要求对签名者进行严格的身份验证。在非生物特征签名情况下（即不采用指纹、人脸等生物ID时），需采用至少两种独立的身份验证要素（例如用户名和密码组合）来执行电子签名 。也就是说，签名者登录系统时至少需要输入用户名/ID和密码两种凭证；如果在一次连续登录会话中执行多个签名，可以首次签名时用两种凭证，后续签名至少再次输入一种凭证（如再次输入密码） 。若签名者退出系统，则下次签名时又需提供全部两种凭证 。此外，法规还要求在授予用户电子签名权限之前必须验证用户身份（确保其是真实的人并有授权） 。

身份凭据管理也是身份验证机制的一部分。21 CFR 11.300条款规定：每个人的标识码/密码组合必须唯一，不得与他人共享 ；应有策略定期检查、更新密码（比如密码有效期要求） ；如果有令牌、智能卡等用于产生身份代码的设备，还需要有丢失管理程序（如挂失失效机制）和定期测试机制，防止未经授权的使用 。这些措施确保电子签名的身份凭据安全可靠，防止他人冒用。综上，电子签名系统需实现强身份认证：包括唯一账号、用户名/密码登陆、多因素认证（如双重验证）、密码定期更换和失效管理等，以满足法规对身份验证的要求。

审计追踪（Audit Trail）

审计追踪是Part 11的核心要求之一。法规11.10(e)明确规定：电子记录系统必须使用安全的、计算机生成的、带时间戳的审计追踪，独立记录对电子记录的创建、修改、删除等操作的日期、时间 。系统对记录的任何更改都不得覆盖原有信息，也就是说审计追踪应保留历史记录，不能被随意修改或删除 。同时，审计日志应保存至少与相应电子记录同样长的时间，并在需要时可供监管机构（如FDA）检查 。这一要求确保所有对电子记录的操作都有据可查，形成不可更改的操作历史。

具体而言，电子签名系统需要在后台自动记录每一次重要操作：例如用户登录/退出、创建文件、内容修改、审批签名、拒签、撤销等事件，并记录操作者身份、时间戳以及具体动作等信息 。审计日志应采取保护措施防止被篡改或删除——普通用户不应有直接编辑日志的权限，系统应保证日志以追加方式写入并防篡改保存。这些日志数据需要可以方便地查询和导出，以便内审或外部监管审核时能够审阅。在实践中，审计追踪通常以不可变更的日志文件或数据库形式实现，有的系统采用WORM介质（Write Once Read Many，只写多读）或区块链哈希链技术来确保日志记录一旦写入就无法修改，从而符合法规的完整性要求。

此外，法规还要求签名相关的信息需要在记录中体现（属于审计追踪的一部分）。每一个电子签名操作所对应的电子记录，都应清晰地包含签名者的姓名、签名的日期时间，以及签名的意义（例如“已审阅”、“已批准”等） 。这些信息通常会在签名附注或日志中自动记录，以便事后可以明确是谁在什么时间以什么目的进行了签署。这实际上也是审计追踪和签名完整性的一部分要求。

数据完整性与防篡改（Data Integrity and Security）

数据完整性要求电子记录在整个生命周期内保持其准确、可靠且未被不当修改。Part 11规定必须保护电子记录的完整性，确保其在保存期内可被准确地检索和呈现 。具体而言，系统应防止未授权的访问和修改，保证数据不会在传输或存储过程中被篡改或意外损坏。这通常需要多层面的技术手段：

• 防篡改技术：对于签署完成的电子记录，一旦签名完成，系统应对记录进行“锁定”，防止后续被不当修改。许多符合Part 11的电子签名系统会对最终文件应用数字签名或数字指纹封存。例如，使用加密哈希生成文件指纹，并由系统或可信证书机构对文件进行数字证书签名，从而在文件上生成一个不可见的“防篡改密封”。任何对签署文件的改动都会使数字签名失效，从而能被检测出来。这一措施确保签名后的电子记录不可被篡改且篡改可被发现。正如Adobe的解决方案所示，每份签署完的PDF文件顶端会显示一个蓝色的认证横幅，注明“已由Adobe Sign认证”，这表明该文件已附有Adobe的数字证书，一旦内容被改动用户将收到警告 。这种由可信第三方证书签署电子记录的方式，大大提高了文件的可信度和防抵赖性。

• 访问控制和权限限制：防止未经授权的人接触或改动记录是保证完整性的前提。系统需严格区分用户权限（参见下文用户权限部分），仅授权人员才能查看或编辑相应记录，杜绝越权操作，从源头减少不当修改的可能性 。例如，只有具有签署权限的人才能对记录执行签名操作，只有管理员才能删除记录等 。

• 数据存储安全：电子记录和签名数据在存储时应采用安全存储措施，比如数据库写入时伴随完整性校验，重要记录存副本或定期备份，防止因系统故障或人为因素造成数据丢失或损毁。同时对数据库或文件进行加密存储也是常见措施，以保护机密性和完整性。传输过程中采用SSL/TLS加密通讯，防止数据被截获篡改。

• 记录留存和档案：法规要求电子记录及其审计追踪在规定的保存期内不可更改地保存 。因此系统需要实现可靠的备份与归档机制，确保哪怕系统更替或升级，历史签名记录仍然原样保存以备查验。此外对超过保存期的记录删除也需审慎管理，在删除前确保不再有法规要求保留的义务。

综上，数据完整性与防篡改要求电子签名系统具备防止未授权篡改、检测任何改动、保持记录原始性的能力。这通常通过数字签名、防篡改审计日志、严格权限、加密和备份等技术手段共同实现，确保电子记录从生成、签署到归档的全流程可信。

系统验证（System Validation）

系统验证是指对电子签名系统进行充分的验证测试，以证明其能够按照既定的用途可靠地运行。21 CFR 11.10(a)要求：使用电子记录/签名系统的单位应当验证系统，确保其具有准确性、可靠性、稳定的预期性能，并能够辨别出无效或被篡改的记录 。换言之，在投入正式使用前，要通过验证保证系统功能符合要求（比如只有授权用户才能签名，签名后记录不能再被修改但可正确读取，审计日志如实记录等），并在系统发生变更（如软件升级）时重新评估验证。

系统验证通常遵循计算机系统验证（CSV）的生命周期方法，包括制定验证计划、功能需求和风险评估，执行功能测试和用户接受测试，记录测试结果和缺陷处理，最后出具验证报告等。法规要求保留这些验证活动的书面记录，以备监管审查 。验证重点包括：关键功能测试（如多重身份验证是否有效、未授权用户是否无法访问、审计日志是否记录正确等），性能与可靠性测试（模拟高并发签署、断电恢复后数据完整性），安全控制测试（权限限制是否生效，密码策略是否有效）等。

除了初始验证外，法规也隐含要求持续的维护和再验证：当系统进行重大升级、配置更改时，应评估是否需要执行补充验证；日常还需监控系统性能，保证其持续符合预期用途 。同时，要版本控制系统文档并维护变更记录，以体现对系统更改的控制（这实际上对应11.10(k)关于系统文件的版本控制要求）。

因此，一个符合Part 11的电子签名系统在正式上线前和运行过程中，必须有完善的验证措施，确保系统始终“适用于预期用途（fit for intended use）”。这既是法规要求，也是保证系统品质和数据可靠性的必要手段。

用户权限和访问控制（User Access Control）

访问控制旨在保证只有适当授权的人员才能使用电子签名系统及其各项功能。21 CFR 11.10(d)要求限制系统访问，仅授权的个人可使用系统 。此外11.10(g)进一步要求建立权限检查（authority checks），确保只有被授权的人才能执行诸如电子签名、记录修改等操作 。简单来说，就是实施严格的用户权限管理。

在实践中，这意味着每位用户需要分配适当的角色和权限：例如系统管理员、记录创建者、审核者/签名者、只读查看者等，不同角色有不同操作权限。系统应当提供唯一的用户账号（通常使用用户名或邮件地址标识）和登录凭证，每个账号关联特定人员 。通过角色与权限设置，系统可以基于职责分离原则控制谁能访问哪些记录、执行哪些动作 。例如，文件的起草人可能没有最终审批签署权限，审批人可以签名但不能修改他人签名，普通用户不能删除审计日志等等。

为加强访问控制，系统通常要求用户凭证（如密码）不得共用，并辅以登录失败告警、自动登出等防未授权使用措施 。如果采用基于设备的令牌或证书登录，需定期检测这些设备确保未被篡改 。当员工离职或角色变更时，管理员需要及时更新或撤销其账户权限，以保持权限分配的准确性和最小权限原则。

总之，用户权限和访问控制要求电子签名系统具有用户账号管理、权限分配、认证防护等功能，保证系统的任何操作只能由正确的人在被授权的情况下进行。这既维护了数据和签名操作的安全性，也满足了法规对于“适当人员才能做适当事情”的合规要求 。

符合21 CFR Part 11的电子签名系统框架

符合21 CFR Part 11的电子签名系统需要集成多种技术组件，以确保从用户身份管理到签名数据存储的全过程都满足合规要求和安全性要求。下面将介绍系统的主要组件及其功能，并描述系统的运行流程。

系统架构与关键组件

为了实现Part 11规定的功能和控制，电子签名系统应包含以下关键技术模块（组件）：

上述架构中，各组件共同协作以实现全面的合规控制。例如，用户通过身份管理模块注册并分配权限；登录时经过身份验证模块的多因素认证；在使用过程中，权限控制模块确保其只能执行授权范围内的操作，而所有操作都会写入审计日志模块；当用户对文件进行电子签名时，电子签名模块生成数字签名并绑定相应信息，同时日志中记录签名事件；数据存储模块安全保存文件和日志，并由加密模块保障其防篡改；整个系统在上线前由系统验证模块进行过充分测试，并在运行中持续监控。

签署流程与系统运行步骤

一个典型的符合21 CFR Part 11的电子签名系统的运行流程如下：

1. 用户登录： 用户打开电子签名系统（如Web界面），输入其唯一的用户名/ID和密码进行登录。系统触发身份验证模块进行认证。如果启用了双重认证，用户还需提供第二要素（如手机OTP验证码）。只有身份验证通过且账号有相应权限的用户才能进入系统主界面 。

2. 发起签名请求： 授权用户（如文件起草人）上传或创建需要签署的电子文件。系统存储模块保存文件原始内容，并计算文件指纹作为防篡改基线。起草人选择签署流程（如指定签署人顺序、签名理由类别等），然后提交签署请求。权限控制模块会检查其是否有权限发起该签署流程（例如仅特定角色才能发起正式审批）。

3. 签名执行： 被指定的签署人收到签名待办通知后，登录系统查看文件内容。当签署人准备签署时，系统可以要求其再次验证身份（例如再次输入密码或使用指纹/人脸识别，如果系统支持生物特征）以确认签名操作者身份，这对应法规要求签名时的身份组件验证 。签署人还需要选择或输入签名意义/理由（比如“Approved 批准”或“Reviewed 审核”)，作为签名的一部分信息 。随后签署人通过点击“签署”按钮并应用电子签名（这可能以输入密码确认或按下数字签名令牌的形式实现）。

4. 生成电子签名记录： 当用户执行签名操作后，系统的电子签名模块会将该签名事件与文件内容绑定：在电子文件上记录签名者姓名、签名时间、签名理由等元数据（通常在签名页或签名区显示），并对文件内容计算哈希值，再由系统的数字证书对其进行签名，生成带有数字签名的PDF文件或记录 。此时文件即被“锁定”，任何改动都会使数字签名失效。系统也会将签名事件写入审计日志，包含“某用户在某时间对某文件进行了签名，理由X”等详细信息 。

5. 审计追踪记录： 审计日志模块在整个过程中自动工作。它记录下：用户登录（成功或失败）、文件创建、签名请求发送、签署人查看文件、签名人验证身份、签名动作本身以及签名后的文件哈希等一系列事件均有对应的时间戳和用户ID记录 。这些日志被安全地保存于日志数据库，不可由用户修改。管理员或审计员可在系统中查询该文件的审计报告，查看完整的签名过程历史。

6. 签名完成与文件发布： 当文件所有指定签署人都签名完成后，系统标记该流程结束。最终签署完成的文件可以提供给相关方下载或查看。由于文件带有数字签名证书，任何人打开文件（例如用Adobe Acrobat阅读）都可以看到签名的有效性状态。如果文件未被改动，阅读器会显示文件已由可信机构签名（例如显示一个蓝色签章和签名者信息）；若文件被改动，则会警告签名无效 。这样即使在系统外，电子记录本身也具备防篡改验证能力。

7. 归档和导出： 系统允许将签署后的文件及其审计报告一起归档保存。审计报告通常也可另存为PDF格式，并由系统进行数字签名以确保其不可篡改 。监管审核时，可以提供该签署文件和对应审计报告，证明符合Part 11的要求。系统可能提供一键导出整个签名包（包含签署文件、签名证书、审计日志）的功能，便于留存合规证据。

8. 系统维护： 在日常运行中，系统验证与监控模块持续发挥作用。管理员定期检查系统日志，关注是否有异常登录尝试（未授权访问企图） 或系统错误。对系统的任何配置更改或版本升级，都按照变更控制流程执行，并评估是否需补充验证测试。这样保证系统始终处于受控状态并持续符合法规要求。

通过上述流程，电子签名系统在用户身份->签名操作->记录保存->审计追踪的整个链条上都落实了21 CFR Part 11的要求：多人身份验证确保签名人确为其声称身份，数字签名技术确保签名后的记录不可悄然篡改，审计日志确保所有操作留痕可查，权限控制确保无授权不会发生违规操作，系统验证确保这一切功能本身可靠可信。