事件响应机制探讨:合并SIM系统和IAM系统

安全 黑客攻防
如果将SIM系统(安全信息管理系统)的实时监控和报告功能和IAM系统(身份和访问管理系统)的访问控制连接起来,可以提供更有用的控制和更高的安全性...

如果将SIM系统(安全信息管理系统)的实时监控和报告功能和IAM系统(身份和访问管理系统)的访问控制连接起来,可以提供更有用的控制和更高的安全性。但是,这两个系统都是封闭的环境,这意味着他们都有非常具体的切入点,而且他们最初是被设计成独立工作的,因此,没人清楚该如何将这两个功能合并起来,而且如果在这样的情况下,贸然地将他们集合在一起,将会造成两个系统同时失去有效性的风险出现。

SIM系统的功能是监控并报告安全漏洞及策略违反的情况,这些系统包括一个策略执行引擎,它的功能是将信息保护策略转换成一些可操作的行动,以便进行监控和评分,它和扫描及报告组件协同工作,扫描及报告组件会在某个违反组织保护策略的活动发生时,通知IT安全人员。同时,IAM管理用户访问和授权,以便用户进行活动。为了管理这样的访问,IAM系统使用RBAC(基于角色的访问控制)。RBAC允许IT管理员在一个高级别的用户管理模型下来管理用户访问,而此模型是基于普通用户的功能和责任的。它可以用来同时管理大量用户,相对于单独管理每个用户的访问要更加有效得多。

这两个系统的封闭环境意味着两者的整合是非常困难的,那么为什么一个组织会想要将他们合并起来呢?有一点是很重要的,必须要认识到SIM系统的工具是用来处理信息和系统的,而不是针对人。在很多情况下,当一个IT安全人员接到由SIM系统发出的事件报告而要去进行处理时,他或她并不知道是否某个人引发或造成了这个事件,但是他或她可以在IAM系统里查询哪个人曾经访问过这个信息,因此如果有IAM系统的信息可以查询将会非常有利于正确地将事件分类和及时处理。

因此,应该如何合理地将一个独立的SIM系统整合进一个独立的IAM系统呢?首先,要进行分级处理。在现实情况中,SIM系统仍然是唯一的用来处理安全漏洞和风险评估的控制系统,同样地,SIM系统保留它的***等级控制系统的角色,而IAM系统则必须扮演一个奉献的角色,因为在将一个IAM系统整合进一个SIM系统的时候,很重要的一点是不应该给SIM系统加重负担以免影响它执行自己的正常功能,这意味着IAM系统应该作为一个事件分类模块的一部分被整合进来,而不是作为监控和报告功能模块的一部分。

IAM系统存储了用户信息,帐户访问权限,角色和权利,因此就事件分类模块而言,这些信息应该象下面这样使用:

识别问题中的信息→查看当前的保护→确定受影响的组件→确定访问此信息的用户角色→确定用户在此角色中的权利→确定用户的物理和虚拟访问→确定此信息是否处于风险中。

SIM分类组件使用通常存储在目录中的用户信息,比如LDAP(轻量级目录访问协议)或活动目录;由于IAM系统在存储用户访问和权限时使用相同的位置,在整合两个系统时,首先要做的是允许SIM系统可以访问目录树中IAM的分支,这样可以允许SIM系统来查询用户角色和访问权限。

另外一个整合点是,SIM需要使用IAM系统的验证服务,这个服务是用来验证某个用户是否具有根据他或她的工作职能而被赋有的正确角色。SIM系统如果可以做到这点,那它将可以寻找出一些没有被验证服务发现的职责分离情况以及其它违反策略的情况,因为它可以从一个系统级别的访问问题来分析,而不只是在信息级别的访问问题。

两个系统都提供的一个特征是,他们具有在各自的领域进行监控的能力,很多组织都犯一个错误,即没有在一个使用通用数据或操作中心的情况下分享由这些系统提供的观点。就象美国政府遇到的情况一样,美国政府具有各种情报中心,但却没有共享他们的发现,通过各自独立地监控IT安全活动和其它IT活动,使美国政府只能对发生的实际活动一知半解。将IT和安全数据,以及操作中心布置在一起,那么两个系统都可以进行监控,以便提供一个整合的IT安全前沿。

***,将由SIM系统来确定安全漏洞将被最小化,以及所有违反组织安全策略的行为都将被捕获。当IAM技术提供有价值的服务来管理用户访问和授权时,他们仍在敏感信息保护中扮演了一个次要的角色。通过帮助SIM系统获知谁曾经访问过出问题的信息,IAM能够提供有价值的信息来增强SIM工具的有效性,而且SIM系统也会反过来向IAM系统提供有价值的反馈,以便IAM系统更好地管理用户。通过将此两个服务合并成一个功能,而不只是简单地分别使用此两个服务,组织会获得一个更好的解决方案。

【编辑推荐】

  1. 上网行为管理IAM系统具备大规模部署的条件
  2. IAM技术2010年发展趋势可配置技术成重点
  3. 企业IP网络安全管理系统探讨
责任编辑:安泉 来源: TT中国
相关推荐

2010-07-01 11:59:21

2017-12-21 15:42:08

iOS传递机制

2015-04-14 09:55:40

2013-09-02 13:19:09

2023-10-12 22:44:16

iOS事件响应链

2024-01-09 09:40:23

2017-04-13 13:59:48

2020-12-23 07:37:17

浏览器HTML DOM0

2009-10-09 09:07:40

C#委托和事件

2009-06-17 15:43:03

Hibernate缓存

2024-04-03 08:47:49

隧道传播WPF冒泡传播

2009-09-25 15:05:39

Hibernate事件

2010-08-06 09:56:06

Flex事件机制

2010-08-06 10:03:42

Flex事件

2010-02-06 14:23:49

Android系统手机

2009-10-17 12:27:12

2021-06-03 08:03:13

网络

2010-11-22 14:18:32

MySQL锁机制

2020-02-26 09:00:00

Chatbot架构模型聊天机器人

2009-08-13 16:57:37

.NET缓存机制
点赞
收藏

51CTO技术栈公众号