安全注意事项¶

本指南旨在协助 DHIS2 实施者和系统所有者采取合理适当的措施，识别和管理与 DHIS2 系统运行相关的风险。希望它对系统所有者特别有用，否则他们可能难以确定并对实施者施加技术限制。

DHIS2 由许多不同类型、不同规模和不同目的的组织实施。这里的主要系统所有者是政府卫生部门或部委，但许多指导原则也应适用于非政府组织和私营机构。

DHIS2 作为一个基于网络的系统，当卫生工作者可以使用任何设备并通过任何可用的网络连接提供商（如 4G 移动电话系统）通过开放的互联网访问该系统时，它就能发挥最大的潜力。我们已经看到，如果采用这种开放模式，就有可能在几个月而不是几年的时间内，在不同国家和项目间推广国家系统。

不幸的是，在同一时期，我们也看到来自犯罪分子和国家行为者对基于互联网的系统的威胁不断增加。攻击变得更加频繁和复杂。与 10 年前推出 DHIS2 第一批网络版时相比，现在更需要更加严格和精明。

全面的安全实践涉及数据的保密性、完整性和可用性。

在许多国家，DHIS2 作为国家卫生信息系统，特别是作为综合例行报告系统，在调整和维持方面取得了显著的成功。常规数据的保密性可以说并不是一个非常重要的问题，但随着时间的推移，系统的制度化程度越高，数据的**完整性**和**可用性**就变得越重要。数据丢失的影响尤其严重。

在 DHIS2 中收集的数据的性质也变得更加敏感。DHIS2 数据库越来越多地包含大量个人身份信息 (PII) 或个人数据。这可以是病人的人口统计数据，也可以是作为用户信息采集的卫生工作者的个人数据（电子邮件、电话、地址、信息）。需要采取适当的措施来保护这些数据的**机密性**和相关人员的隐私。

使用环境{ #context-of-use }¶

法律和监管背景{ #legal-and-regulatory-context }¶

没有一套普遍适用的法律、惯例和原则。例如，欧盟国家最近关于隐私的主要立法是GDPR (General Data Protection Regulation, in force from May 2018). This legislation introduces a set of guiding principles and accompanying terminology which differs in scope, justificatory narrative and intent from the U.S. HIPAA （《健康保险可携性与责任法案》），这是该国管理健康数据的主要立法。

这些都是相对较新且复杂的立法。正在使用 DHIS2 的国家通常不需要遵守 HIPAA 或 GDPR，但许多国家已经或正在制定该领域的国家立法，例如南非的《2013 年个人信息保护法》和印度的《2019 年个人数据保护法案》（草案）。实施者和系统所有者应努力全面熟悉其使用辖区的立法。联合国贸发会议](https://unctad.org/page/data-protection-and-privacy-legislation-worldwide) 有一个网页，提供世界各国的最新隐私立法。

对于公共部门的系统（可能是使用 DHIS2 的大多数情况），可能会有与系统和数据安全有关的额外政策和标准操作程序，这些政策和程序也具有法律效力。

在大多数情况下，以不了解法律为由进行抗辩并不能作为辩护理由。

在任何相关立法和政策范围之外开展工作都是困难的，但在现有监管环境已经过时或不足的情况下，需要在 DHIS2 系统本身的范围内通过协商一致建立适当的控制措施。

人文和组织背景{ #human-and-organisational-context }¶

高度发达的劳动分工是 "先进 "资本主义经济体的一个特征。我们在欧洲和美国的 IT 行业可以清楚地看到这一点，那里的系统管理员、程序员、网络工程师、信息终端用户之间有着非常明显的区别，同时还有高度发达的 IT 管理结构、角色和实践，尤其是在大型组织中。

期望在所有国家找到相同的结构和角色是愚蠢的，特别是在 DHIS2 可能是国家卫生部的第一个或至少是最重要的国家系统的情况下。在没有相对现代化的管理基础和熟练劳动力的情况下，实施像 DHIS2 这样复杂的网络系统会带来独特的风险和挑战。开发适当的组织形式来管理风险，使系统得以蓬勃发展和持续，至少与任何技术考虑同等重要。

如果政府部门、伙伴组织和捐助者之间的关系错综复杂，在安全和隐私方面的观点和优先事项可能不尽相同，那么挑战就会更加严峻。

措施{ #measures }¶

组织措施{ #organisational-measures }¶

面对系统所有者可能面临的组织挑战，系统所有者制定适当的系统安全管理计划就变得更加重要。以下是一小部分实用建议。

制定安全管理计划是对系统行使所有权的第一步。如果卫生部只是被动地使用由伙伴组织开发和管理的系统，那么他们就没有行使所有权。

安全是一个管理问题。你不能将其委托给组织中最低级、技术含量最高的人员（这很常见！），也不能将其外包给技术合作伙伴（这也很常见）。你几乎肯定会依靠这些资源，但动力应来自管理层。

在一个理想的世界里，可能会有一位首席安全官（CSO），他拥有许多安全和治理框架（TOGAF、ITIL、ISO27000x 等）的专业背景。但实际情况很可能并非如此，人们需要利用现有资源制定更加灵活的计划。随机应变是关键。有一个糟糕的安全管理计划，或者至少是制定不完善的计划，总比没有计划要好得多。薄弱的计划可以改进并进一步发展。

我们建议各组织采用类似 ISO27002（信息安全管理）的一些方法，但不一定非要走上符合 ISO27000 的道路。这至少意味着：

1. 你有一份总结组织安全态势的高层声明。一份只有一页纸的声明，应突出原则和意图，并表明高级管理层对这一过程的承诺。

2. 你已经在团队中明确了一个人（相当高级），他将负责制定、维护和实施安全计划。我们可以称之为安全经理。

3. 安全经理致力于识别、记录和降低风险的过程。这是一个持续的过程，通常围绕风险登记册的维护进行，并定期进行审查。

4.有定期对 DHIS2 部署、配置和元数据进行内部和/或外部审计的程序（包括 时间和预算），包括组织/机构的安全计划。

5.各方之间有数据共享协议，规定处理哪些数据、目的和方式，设定明确的限制和界限，以避免病人数据外泄，并保护数据的完整性和保密性。

6.为 DHIS2 系统确立数据和技术所有权。

ISO 27000 等框架中设想的许多其他工具和流程都可以从这个周期中自然产生。例如，如果没有灾难恢复计划或备份战略，登记簿中就会将其作为主要风险加以强调。组建和维护这样一个登记册，可以让团队确定需要完成的任务并排定优先次序，评估在实现更好的态势方面取得的进展。

作为任何安全计划的第一步，至少应创建以下文件： - 资产清单 - 风险评估/风险登记文件 - 备份政策 - 灾难恢复政策 - 事件响应计划 - 身份和访问管理计划

为了帮助实施者启动他们的安全计划，我们开发了一套模板，任何人都可以使用并根据自己的需要进行调整，这套模板被称为 Security Starter Kit。

系统配置措施{ #system-configuration-measures }¶

在 DHIS2 系统配置层面，也可以采取一些措施来提高安全性，例如与确保适当的系 统和数据访问有关的措施。这里列出了系统配置措施的建议优先级（前 10 位）清单：

系统管理

1.拥有超级用户（完全）访问权限的人数有限（少于 5 人）。 可以很容易地通过应用程序接口进行评估：/api/users.json?filter=userCredentials.userRoles.authorities:!in:[_ALL_]&filter=userCredentials.userRoles.authorities:in:\[ALL]。

2.系统管理员只有权执行与其系统管理角色相关的功能。 例如，负责管理图表和仪表盘的管理员不需要编辑组织单位的权限。

3.删除或禁用默认的 DHIS2 用户帐户（用户名 "admin"）。 管理员账户只应在首次启动 DHIS2 时使用，以设置个人超级用户。然后应将其禁用和/或删除。管理员账户的状态可通过以下 API 验证：/api/users.json?filter=userCredentials.username:eq:admin&fields=name,userCredentials\[name,disabled\]

用户管理

4.有相应的程序来禁用或删除离职人员的用户账户。 应该有明确的程序来禁用/删除离开（医疗）服务的用户账户。这一点可以从应用程序接口（API）中得到一些说明，方法是查看未被禁用且未登录系统的用户账户，例如在本年度：/api/users.json?filter=userCredentials.disabled:eq:false&filter=userCredentials.lastLogin:lt:2021。

5.系统中的所有用户账户都是个人账户，即不会被几个人共享。 用户账户不应由多人共享，否则无法进行审计。如果 Tracker 用于处理个人层面的数据，这一点尤为重要。

6.有明确定义的用户角色和用户组，并根据用户在（医疗卫生）服务中的职位，指导用户应使用哪些角色和组。

7.如果启用了用户自助注册功能，则赋予这些用户的用户角色应非常有限，例如只能查看公共仪表板。

8.禁用账户可能是限制某些被系统遗忘的用户访问的好方法。DHIS2 提供了一个自动执行的计划任务。不过要注意的是，这在使用安卓设备时可能会产生后果（导致数据丢失），详见官方文档。

跟踪器

9.通过适当使用共享和用户组，访问跟踪器数据仅限于对编辑/查看数据有合法需求的用户。用于记录单个人信息的跟踪程序均不配置公共访问权限。 跟踪器数据通常与个人相关联，因此应仅限于合法使用这些数据的用户。虽然所有用户都能访问汇总数据可能是个好主意，但跟踪器数据并非如此。

10.跟踪程序的配置使用户只能搜索和访问他们有合法理由查看的人的数据。 * 例如，在一个卫生机构工作的用户不应被分配到一个地区。如果使用，"跟踪实体搜索组织单位 "的设置不应超出实际需要。*

安卓系统

在 DHIS2 中使用移动设备（安卓）越来越普遍，因为它们具有离线和最后一英里的功能。然而，从安全角度看，这也带来了额外的要求，因为从一个包含信息的服务器传递到多个可能包含敏感信息的设备的风险会增加。

如果敏感信息存储在设备中，则应通过培训和/或文档来引起关注。系统管理员可能希望启用不同的措施，以帮助降低安卓设置 Web 应用程序 (ASWA) 所带来的风险。

ASWA 允许系统管理员（除其他外）进行以下操作：

在设备上强制执行 DHIS2 本地数据库加密，以防止恶意行为者在访问设备时泄漏数据。 允许/禁止屏幕截图功能，降低（但不限制）机密信息泄露的风险。

官方文档(DHIS2 Android App]中有一节详细介绍了所有这些功能。

在此基础上，安卓应用程序可单独配置为要求输入 PIN 码，作为用户名/密码对的另一层安全保护。

在存在设备丢失/被盗风险的应用中，系统管理员可能希望通过移动设备管理等工具增加另一层安全性，这些工具可以实现远程擦除、定位等功能。官方文档中提供了具体指南：管理移动设备 。

技术措施{ #technical-measures }¶

DHIS2 系统的配置方式有很多种，包括在不同的物理环境（内部部署、共同定位、私有云、公共云）中使用不同的操作系统、使用容器、负载分担、复制等。根据调配过程中的这些设计选择，可以并应该应用不同的安全控制措施。

从最一般的意义上说，我们可以认为应该有：

• 一套成文的技术控制措施
• 针对这些控制措施的审计程序

互联网安全中心(https://cisecurity.org)等组织为软件产品制定了详细的基准，可用于编制一套控制措施供你实施。在大多数情况下，你不会应用所有的基准，而是会选择最相关的基准。你应该从 https://www.cisecurity.org/cis-benchmarks/提供的列表中下载并研究 Apache Tomcat、Postgresql、nginx（或 Apache2）的基准。此外，根据您的技术选择，您可能会发现 Ubuntu linux、lxd、Docker 或 Microsoft Windows 的基准与您的实施相关。

拟议的高度优先（前 10 项）技术措施清单：

1.操作系统是 LTS（长期服务版）。

2.有一个应用操作系统安全补丁的自动程序。

3.配置基于主机和/或网络的防火墙，仅向网络提供必要的服务。

4.根据商定的良好做法，通过 SSH 对 DHIS2 服务器进行管理访问 - 仅密钥验证、无 root 访问、明确的用户允许列表、较少的最大验证尝试次数。

5.DHIS2 版本与最新版本的差距不超过 3 个版本。有定期打补丁的程序。

6.自动备份系统已就位并定期测试，包括异地测试。

7.Postgres 和系统用户遵循最小权限原则：只允许最小的权限和访问。

8.DHIS2 通过配置了 TLS/SSL 的网络代理服务器（必须在 ssllabs 中至少获得 A 级评分）公开。

9.数据库数据位于单独位置（数据分区、硬盘、云存储等），允许静态加密。

10.针对系统指标（至少包括 CPU、内存、磁盘、网络、数据库、网络代理）建立监控和警报系统，并配备适当的身份验证机制（如 2FA、SSO、强密码要求）和基于角色的访问。