在本篇文章中,我们将介绍控制 A.8.02 – A.8.05 对敏感信息(包括源代码)的访问、限制访问和特权访问权限。我们还将介绍系统的安全身份验证。
A.8.02 特权访问权限
特权访问权限是向身份、角色或流程提供的访问权限,允许执行普通用户或流程无法执行的活动。最常见的例子是系统管理员角色,他们通常需要特权访问权限。
此控制旨在确保只有授权用户、软件组件和服务才享有特权访问权限。
与控制相结合A.5.15 关于访问权限,应通过授权流程控制特权的授予,在该流程中,权限在授予前必须申请并获得批准。还应定期审查这些权限。系统内基于角色和基于用户的访问权限应以相同的方式处理。
在确定哪些用户和帐户具有特权访问权限时,不要忘记包括任何管理帐户或可用于自动化任务的其他帐户,例如应用程序用户帐户。
具有特权访问权限的用户执行的所有操作都应记录下来以供审核之用。这可以作为 A.8.15 - 日志记录中实施的控制措施的一部分。
A.8.03 信息访问限制
此控制旨在确保只有授权用户和帐户才能访问信息和资产,并防止未经授权的访问。
首先要确定谁需要访问信息,这在一定程度上可以通过信息分类来评估。除此之外,还要考虑谁需要访问信息,并仅根据最小权限授予访问权限。
实施此控制时需要考虑的事项有:
- 确保用户需要经过身份验证并拥有适当的授权(例如组成员身份),然后才允许访问安全信息及其存储位置。您应该考虑如何限制应用程序内的任何敏感数据(例如 PII)。应用程序是否提供根据用户权限隐藏信息的功能?如果是,那就利用它吧!
- 这应该包括配置对这些安全位置的访问以控制访问,包括仅对所需身份或组进行读取、写入、删除和执行的能力。
- 访问控制用于隔离敏感应用程序、应用程序数据或系统。仅允许需要使用系统的人员访问系统及其内部信息。
A.8.04 – 访问源代码
此控制旨在防止引入未经授权的功能,避免无意或恶意的更改,并维护您的软件源代码(宝贵的知识产权)的机密性。
此控制扩展了 A.8.03 中的信息访问限制控制,具体指保护对作为业务一部分而生成的任何源代码和相关工具的访问。这包括软件设计、规范、测试和验证计划等文档以及 SDLC 中使用的工具,例如编译器、构建器、集成工具、测试环境和平台。
可以通过确保使用源代码管理系统控制源代码的中央存储库来实现此控制。这应包括建立一个程序来管理对源代码和库的访问,并根据业务需求授予访问权限。该程序应概述变更控制程序(在控制 A.8.32 中进一步概述),并且仅在收到适当授权后才执行变更。
此外,不应授予开发人员直接更改源代码的权限,而只应允许通过授权工具进行更改,并且该工具可进行配置以确保更改已通过变更控制程序进行。
与大多数其他变更控制程序一样,应保留审核日志以确保源代码变更的可追溯性。
A.8.05 安全认证
此控制是为了确保用户在访问系统和应用程序时得到安全的身份验证。
访问信息所需的身份验证强度应与信息的分类相适应。因此,对更敏感的数据和系统应要求更强的身份验证。
当需要强身份验证或身份验证时,应使用 MFA(多因素身份验证)。多因素身份验证涉及使用其他因素,例如询问您知道的其他信息,或使用其他设备(例如向手机发送短信),或使用身份验证器应用程序,例如更安全的 Google Authenticator。
作为 MFA 控制的一部分,您可能希望考虑在授权某些操作或访问应用程序内的数据之前要求进行额外的身份验证。例如,银行应用程序要求您在转账之前输入来自身份验证器应用程序的代码或通过短信发送的代码,即使您已经访问了该应用程序。
在设计系统登录程序时,应着重降低未经授权访问的风险。应考虑以下几点:
- 密码或其他敏感信息不应以明文形式显示在屏幕上,也不应以明文格式通过网络传输。
- 任何错误消息都不应向恶意用户透露哪些数据可能是正确的。例如,显示用户密码不正确会向恶意用户暗示用户名是正确的。
- 在一定次数的失败登录尝试后锁定帐户,以防止暴力尝试访问系统。
- 记录所有尝试,包括成功和失败的尝试,包括在检测到潜在登录控制漏洞时发出安全警报。例如,如果用户输入错误密码信息超过一定次数,或者有人通过自动化工具尝试登录时发生 DDoS 攻击。
- 限制高风险应用程序的连接时间,以减少未经授权访问的机会。
- 非活动会话应在非活动状态后安全地注销,特别是当从网络外部或用户设备访问系统时。