如何在您的业务应用程序中管理细粒度许可
- 删除应用程序孤岛并统一访问控制
- 基于权限的与基于角色的访问控制
- 从业务逻辑中分离访问逻辑
- 仔细选择访问权限的粒度
- 倾向于打开门，而不是关闭它们
- 最小化安全数据量
- 委派管理任务
- 跟踪重要的操作
- 分离开发，测试和生产的安全数据
- 建立一个安全和演变的基础设施
删除应用程序孤岛并统一访问控制
什么是筒仓？
信息系统是随着时间而建立的，通常包含多个独立的应用程序。每个应用程序都包含适当的解决方案来管理细粒度的权限，有时还包括自己的用户帐户，从而充当独立的Silo。
与筒仓合作
使用筒仓不起作用：
- 新规则不适用于每个系统的连贯和同步的方式
- 行政成本和错误风险很高
- 控制措施并不全面：很难为所有系统获得统一的信息
为什么筒仓不工作？
- 安全规则的传播过于复杂：应用新规则时，所有应用程序都无法以一致且同时的方式进行修改，因为它们依赖于不同的安全系统。
- 控制措施不全面; 审计师不是自主的，他们需要向每个团队询问他们的申请信息。他们有时会遇到开发人员不太可能回答他们的问题。另外，从一个应用程序到另一个应用程序传输的信息可以采用不同的格式，这使审计人员难以分析和整合。
- 管理安全性变得非常昂贵：系统越复杂，系统越多，它们的成本就越高。
- 某些组织尝试集成解决方案无法解决任何问题：允许交换用户信息和访问权限的连接器。但是异构系统的同步是非常昂贵的，缺乏稳健性。最重要的是，与同时管理多个安全系统相关的错误的成本和风险保持不变。
中央访问控制的预期收益：
- 安全规则的实施将在所有安全系统中立即生效。例如，如果销售团队不再能够查看员工的地址，则应该能够根据包含销售团队的用户组扣留功能许可。此功能权限将通过每个应用程序中预定义的技术操作立即传播（请参阅上面的功能权限）
- 用户帐户，其访问权限和执行的操作历史将集中在独立存储中。审计师将自动实时控制安全。他们可以横向查看所有应用程序，而无需以不同格式整合数据。
集中访问控制
预期收益：
-
- 管理员完成的每个操作都立即更新并统一公司中所有应用程序的安全性
- 行政成本和风险降低
- 审计很容易，实时交叉和控制安全
- 与安全相关的管理任务不再是系统间冗余，会占用更少的资源并产生更少的错误。
基于权限的与基于角色的访问控制
在讨论访问控制时，经常会出现基于角色的访问控制（RBAC）的概念。委托人由基于用户角色的访问权归属组成。因此，组织可以定义多个应用程序共有的用户帐户和角色，从而删除部分应用程序孤岛。
在大多数情况下，他们会让每个应用程序解释角色来定义他们自己的权限。Silo的一部分仍然关注细粒度权限的管理。因此，每个应用程序都可以开发特定的访问控制逻辑并独立于其他应用程序实现安全角色。
相反，基于权限的访问控制包括标准化所有应用程序的细粒度权限。因此，权限管理委托给负责访问控制的团队，并在开发团队的外围进行。
在这种情况下，权限将是函数类型（请参阅访问权限粒度）。例如，信息系统管理业务实体“客户”。我们定义了权限“CanViewClient”，“CanCreateClient”，“CanUpdateClient”......并将它们应用于客户端操作的所有应用程序。该解决方案允许将相同的访问控制规则即时应用于所有应用程序，从而消除了应用程序孤岛的负面影响。
从业务逻辑中分离访问逻辑
细粒度的权限应该从应用程序外部化：
降低成本
通过将访问控制系统从应用程序所有者手中带走，开发时间和成本显着降低（每个应用程序都不需要安全代码）。在多个应用程序和异构IT堆栈上部署统一的解决方案。
敏捷
访问策略和应用程序通常有两个非常不同的生命周期：
- 每隔几个月新的应用程序版本
- 访问策略每天都在发展
混合访问和业务逻辑会导致以下问题：
- 修复安全漏洞需要很长时间（等待新版本的应用程序）。
- 更改访问策略太昂贵，因为它意味着完整的开发周期。
2种可能的选项来外化应用程序权限：
1.动态权限：一些工具可以动态地启用/禁用应用程序功能，而无需更改代码。开发人员根本不用担心安全问题：它在安全人员开发之后进行管理，并在运行时动态执行。
动态权限
动态权限：此示例显示如何实施新策略“管理员可以读取合同”，而无需编写安全代码或事件来预测开发时的安全性。
2.静态权限：通过在应用程序的代码中放置钩子来预测安全性。之后利用这些挂钩来实现新的安全规则，而无需触摸代码。
静态权限
静态权限：本示例添加策略“管理员可以读取合同”，而不需要再次更改或部署代码。不过，开发人员必须通过测试应用程序中的权限来预测。
仔细选择访问权限的粒度
在应用程序内定义的所有权限都被视为细粒度权限。即便如此，仍然存在两种类型的应用程序权限，每一种具有不同的粒度和用途。
应用程序级别：技术权限
权限与应用程序的物理元素相关：菜单，按钮，数据列表，字段，属性，服务方法等。技术权限由开发人员定义，并且特定于应用程序，网站或服务。
技术权限
应用程序级权限
- 授予/撤销1技术许可只影响1个应用程序
- 开发人员为每个必须保护的项目声明1个权限（在上面的例子中，一个菜单）
- 安全管理员在向用户授予技术权限之前必须知道该应用程序
企业级：功能权限
权限与操作和工作实体相关联（创建报表，查阅合同...）。功能许可对于多个应用程序可能是共同的 他们是由那些专门从事工作和/或访问控制的人员定义的。然后，每个开发团队将功能权限分解为技术操作。例如，“CanViewContract”权限可以用于表单，菜单，按钮等，允许在多个应用程序中查询合同。
功能权限
企业级权限
立即授予/撤销1个功能许可可以保护多个应用程序：
- 安全管理员声明单一业务导向权限
- 每个开发团队都会将此权限转换为其应用程序中的特定更改
- 安全管理员在授予功能权限时不需要知道这些应用程序
哪个选项最好？
首先，不建议组合这两种类型的权限。这使得安全性的维护变得更加复杂，并且增加了权限之间冲突的可能性以及安全缺陷的创建。
然后，我们将根据组织需求选择一种粒度类型：
技术权限可以适用于简单情况，包括少量的访问权限。这就是为什么它们主要用于访问控制仅限于单个应用程序（应用程序级安全性）的情况。
对更重要的卷（企业级安全性）建议使用功能权限。他们允许您提高对功能级别的访问权限，独立于多个应用程序的信息系统的划分。
功能权限提供以下好处：
- 它们对应于新的管理方案和规则，公司必须不断适应。将权限转换为技术操作将由开发人员提前处理，并且不会妨碍访问控制的业务方面。整个信息系统的安全规则保持一致，并且更易于审计。
- 它们的数量也少于技术许可。这一点对于保护对安全规则的控制至关重要，管理员不可能掌握大量卷宗（请参阅“小心卷”），
- 日常管理的安全性更具响应性：管理员通过单一操作即时确保所有应用程序的安全。例如，我们添加规则“销售团队可以查阅报表”。我们将“CanViewInvoice”的功能许可授予角色“销售”。这条规则立即传播到整个信息系统。开发者不需要采取任何行动，所有的应用程序都理解“CanViewInvoice”权限自动保护。
倾向于打开门，而不是关闭它们
定义访问权限时有两种可能的哲学：
- 关闭门：默认情况下，所有功能都可访问。限制某些用户，限制他们访问敏感功能。
- 开门：默认情况下，不可访问任何功能。授权给某些用户某些功能。
另一方面，基于开门的策略提供了更好的安全性：
- 安全漏洞：'开门'策略将限制漏洞并便于检测：如果管理员忘记授权功能，用户将无法使用它并立即发出支持。相反，如果管理员忘记关闭门，则用户可以访问敏感特征并且具有安全风险。这些漏洞难以检测，因为用户没有意识到或不想标记它。然后，这些违规行为可能会在IT团队检测到它们之前长时间增长并持续。
- 访问权冲突：在分配给用户之前，访问权通常重新分组为数据包（角色或权限集）。两个数据包之间经常存在重叠（例如，两者都控制相同的功能时）。这可能导致冲突，例如一个数据包授权访问一个功能，而另一个限制访问 - 结果因此是不可预测和不连贯的，并且可能会产生新的安全漏洞。
在所有可能的组合中，只有授权数据包不会产生冲突。在最坏的情况下，您多次授权访问同一功能，这对安全性和用户体验都没有影响。
结论是：
- 如果所需的安全级别较低，权限较少（例如单个应用程序），并且它们是互斥的（无冲突风险），则可以限制用户的使用。
- 在其他所有情况下，特别是如果您不确定未来可能会出现什么需求，建议使用授权系统。
最小化安全数据量
当我们创建新系统的基础时，我们着眼于涵盖所有需求 - 现在和未来; 这可能会使事情变得非常复杂。开发人员可能会将重点放在短期问题上 - 系统的技术可行性 - 而不利于长期障碍，例如管理繁忙系统的重量。
这就是为什么管理安全系统的成本往往高于创建安全系统的成本; 该系统管理大量高安全性规则和数据，其中长期管理可能是一个真正的挑战。如果控制失败，则可能会出现安全漏洞。
如何避免这个问题？
- 避免人为干预是不可能的：仅凭这一点就能让您分析真实生活场景，做出正确的决策并找到安全系统和用户生产力之间的最佳折中方案。
- 我们可以在不降低系统效率的情况下降低安全数据量。这是本章提供的建议的目标。
- 我们还可以在多个管理员之间分发数据，以减少一人管理的数量（请参阅管理委派一章）
简单即美
我们举一个简单的例子：
- 由10个应用程序（桌面，网站或Web服务）
- 每个应用程序100个表单或函数
- 10个表单或功能的权限
该系统的权限总数为10 * 100 * 10 = 100,000。如果系统有1,000个用户，那么管理员需要监督用户和权限之间的1亿条可能的链接！在权限列表和用户不断发展的情况下很难想象。
因此，减少要监控的信息量至关重要。
我们可以按照以下方式进行：
- 将连贯数据包中的访问权限组合在一起：
- 简单案例的角色
- 复杂案例的权限集和角色层次结构
- 根据组织标准将用户分组（例如按职能部门）。用户组的层次结构反映了他们在公司内部的真实分布是非常重要的。与将用户归入组相关的工作将更加容易，从而降低出错和安全漏洞的风险。
- 根据组的角色分配访问权限。角色/组的数量将远少于权限/用户的数量，从而更易于管理和控制。
- 在不同的本地管理员之间分配用户（请参阅“委派管理操作”）
预期收益：
- 权限管理将更易于监督
- 管理成本将会降低
- 失去控制和安全漏洞的风险降低
委派管理任务
通过在不同人员之间分配访问控制任务（分布式管理模式），我们优化了管理的生产力和质量：
- 工作量已经分配，每个人对管理人员的信息量减少，从而减少了错误的风险。
- 我们通过利用每个特定合作者的知识来提高管理质量。例如，业务单位经理将更有能力了解用户以及他们在组织中的角色和权利。
管理任务分配的示例：
- 访问权限规定：功能/作业专家详细说明访问权限并将它们分组为相关数据包。
- 访问权限的执行：开发人员将访问权转移到技术操作中，包括以下应用程序：激活（或取消激活）控件，过滤数据等。
- 用户帐户的管理：
- 经理（部门经理，现场经理等）知道他的用户的需求，因此他将激活，停用或删除帐户传达给适当的管理员。
- 在某些情况下（例如公共网站），用户可以自行注册。根据所要求的安全级别，我们可以默认自动授予他们访问权限，或让管理员验证他们的帐户并授予他们访问权限。
- 出于安全原因，创建，修改，删除用户帐户的任务将交给负责业务目录的中央管理机构（例如AD管理）
- 如果系统预计用户数据（用户配置文件）的增长，我们可以将这个任务委派给那些最好解决这个问题的人：用户自己或他们的经理。
- 分配访问权限：
- 访问权限的分配给予业务经理，熟知每个用户，他们的职能和他们的用户权利。
- 必须保留一个主体：用户不能定义他们自己的权利。业务经理可以给予他的用户权利，但不能给予他自己。管理员的角色由负责应用安全的中央主管部门给予他。
跟踪重要的操作
为了满足SOX，HIPPA和类似标准的要求，您需要保存用户和管理员完成的操作日志。您还需要实时记录用户及其访问权限。
2017年，一家大型银行发现市场活动损失50亿欧元。管理层必须回答以下问题：谁造成了损失？谁让他这样做？而且，其他交易者能够做同样的事情吗？
更一般地说，规范要求涵盖以下3个问题：
- 谁做了什么，在哪个日期或哪个时间段？
- 谁授予了访问权，何时和谁？
- 今天谁能做什么？
为了使系统高效，示踪剂和审核机制必须是：
- 所有应用程序都集中并通用
- 独立于开发人员使用的技术
- 可通过所有应用程序访问（以便实时跟踪操作）
- 所有可随时审核系统的控制器直接使用，而不依赖于每个应用程序的所有者。
分离开发，测试和生产的安全数据
通常需要多个不同的环境：
- 当应用程序发展时，权限也是如此。开发人员则必须更新现有的权限集。他们在开发环境中这样做是为了不干扰生产。
- 人非圣贤孰能。每个监督或不正确的操作都可能产生安全漏洞。因此新的权限在测试环境中得以验证，以重现生产的特征。
- 验证之后，新的权限将被部署到生产中。然后，我们可以插入新的权限，而不会干扰生产中已有的安全数据（现有的用户帐户和访问权限）
- 出于安全原因，责任必须分开：开发人员可以修改权限，但不能将其部署到生产环境中。只有开发经理可以在测试人员验证之后做到这一点。
建立一个安全和演变的基础设施
相互依赖性和可扩展性
安全系统必须独立于依赖应用程序（当前和未来）的技术。我们可以公开所有应用程序均衡使用的Web服务，以对用户进行身份验证，加载其权限并跟踪其操作。一个好的文档和一个详细的API将促进甚至实现。
可扩展性和灵活性
安全系统应该是模块化的，以适应公司的所有体系结构和安全规则。根据XACML标准（可扩展访问控制标记语言），访问控制系统应包含以下组件：
- 策略执行点（PEP）：应用用户权限的区域。例如，当访问权限需要限制应用程序中的某些功能时。PEP保护安全应用程序。
- 政策决策点：安全系统的核心。PDP是对访问请求进行评估并与用户权限和安全规则进行比较的区域。
- 策略信息点（PIP）：连接到外部信息源（Active Directory，数据库...）的连接器，可能是处理某些访问请求所必需的。
例如：- 只有会计师可以创建报表
- 约翰要求创建报表
- PDP询问PIP：约翰是会计师吗？
- 策略检索点（PRP）：存储安全数据的组件（数据库，文件夹...）。
- 政策管理点（PAP）：这是一个管理工具。例如，权限被编辑并提供给用户的区域。
扫一扫
1419
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
