我们介绍IdM。 实施工程师的观点


之前我们讨论过IdM是什么,为什么需要它如何从财务上证明其实施等。 今天,我们将讨论在系统实施过程中可能出现的陷阱,以及如何解决这些陷阱,而不是让自己陷入困境。 假设我们知道在公司中存在可以使用IdM并希望解决的问题。 在公司中解决这些问题的方法在经济上是合理的,因为它将通过节省为新员工准备工作区所需的时间和资源,并协调和管理旧员工的权力,从而严重减轻IT部门的负担,提高整个公司的绩效指标。 实施IdM之后,IS员工将排在第七天,在按钮上生成大量的各种报告,这极大地简化了他们进行安全审核时的生活,使他们自己和管理人员高兴。 然后决定了-“接!”。

我们制定功能要求


首先要做的是起草一份称为“功能要求”的文件。 我认为本文档内容的可用性和素养的重要性毋庸置疑。 理想情况下,他应该在选择特定解决方案之前做好准备。 显然,在试点测试和预售活动中,多次讨论了不同的人,并解释了需要做的事情。 但是,项目范围应明确定义并固定在纸上。 功能需求是一种起点,客户和承包商双方都将在此过程中的所有参与者之间建立相互理解。

所需的系统功能应在逻辑上和财务上得到合理证明,实施并与其功能保持一致。 这本质上是对需要使用IdM实施自动化的业务流程的顶层描述。

为了清楚起见,请考虑一个简单的示例。 想象一下,您需要自动化以下人员流程:

  • 招募新员工(根据职位和单位创建具有主要权利的帐户)。
  • 要求为员工提供新的凭证(协调,自动和半自动执行应用程序)。
  • 员工调任(发布与新职位相对应的权力,确认或撤销旧权力)。
  • 解雇雇员(通过撤回所有职位来阻止其所有帐户)。

在“ 新员工接受”的功能要求过程中,值得编写以下内容: 系统从人事系统中读取有关新员工的信息,在Active Directory(AD)中创建一个帐户,按职位分配所需的组,在CRM中创建一个帐户,分配一个配置文件和角色按照公务。

当首席执行官进入办公室时,无需向首席执行官冲泡咖啡。 这不是IdM功能,尽管有了API,咖啡壶也是可以实现的:)

我们绘制了系统组件交互的示意图


在此阶段,除了实际的自动化流程之外,还确定了主要的可集成系统,确定了感兴趣的部门,并估计了企业内部信息环境中的全球IdM位置。 还确定了支持IdM所需的资源,使项目范围可见,并大致确定了实施的阶段和日期。

因此,我们意识到,为了在第一阶段实施这些自动化流程,您只需要与以下三个系统集成:

  • 人事系统1C:ZUP,
  • 使用Microsoft Active Directory作为企业基础结构中用户特权的主要提供者,
  • 根据订单,由第三方供应商编写和维护的主要CRM业务系统。

您需要立即想象未来系统各组件的交互方案。

如您所见,IdM处于中心位置,这不是巧合。 实施之后,IdM将成为“ alpha and omega”,其中包含有关公司员工,其在IdM集成系统中的所有帐户以及员工在这些系统中应扮演的角色,团体和权限的所有相关信息。 正是由于IdM的“触角”渗透到了与其连接的所有系统中,Ivanov Sergey Petrovich从会计部门转移到自动在人事信息系统中注册的公司法务部门的转移,才能自动更改其在AD中帐户的组和属性,并更改其在其他公司系统中的角色和资料,自动启动所有必要的批准和通知流程。 但是,只有当系统的所有组件都正确并正确地集成在一起时,所有这一切才起作用。 为了做到这一点,我重复一遍,您需要仔细考虑并设计所有内容。

带着这件行李,我们外出购物。

因此,选择IdM解决方案,定义实施承包商,购买许可证,支付工作费用,是时候实施它了。 我们将进一步讨论如何确保所有美好事业不会在没有真正诞生的情况下就死掉。

我们创建一个项目团队并进行项目前调查


购买IdM之后,要做的第一件事(不计算交易的庄严筹款)是创建一个项目团队。 是的,必须是客户方面项目团队 。 整个事件的成功取决于其组成。 它应该包括所有有兴趣的部门的代表,这些部门具有必要和足够的权力,可以迅速解决在实施过程中出现的各种技术性问题。

接下来是进行预设计调查的时候 -最重要的阶段,需要主要从客户那里进行设计活动的投入。

在这里,将需要客户项目团队的参与者非常必要和足够的权力来收集承包商的所有信息,并向承包商提供有关公司流程内部结构的所有必要信息。 这是关于公司流程的内部结构! 功能需求中描述的每个自动化过程都需要从头到尾进行彻底调查。 谁来进行信息的初始收集,信息的组成和格式,输入信息的系统,信息的传输方式,如何通过哪些协议,使用哪种软件? 谁需要这些信息以进行进一步的活动,以及他们需要什么形式的信息,在哪里应该有执行的操作的痕迹...总之,涉及每个被调查过程的所有,所有,一切。

我们写TK


在项目前调查的输出中,应该获得一份从实施的角度来看更重要的文件(甚至比功能要求更重要)-职责范围(TOR)。 应该是什么? 重要的是不要错过任何东西,并仔细考虑所有内容。 因为忽略细微的细微差别可能会导致在实施过程中出现大问题。

在这方面,当设计传统知识的实施解决方案时,要做的第一件事是彻底解决自动化流程本身。 几乎与功能需求中的要求相同,但更详细地说明,涵盖了进入每个过程输入的信息的整个生命周期,直到出现为止。

例如人员流程,在ToR中招募新员工的过程如下:

  1. HR职员将有关新员工的信息输入1C:ZUP HR系统。 必填项填写以下字段:...(列出了哪些字段)。
  2. IdM从人事系统1C:ZUP接收有关新员工的数据,确定新员工的职位和单位。 在IdM中创建新的员工资料。 根据这样的规则来形成登录名,根据这样的规则来形成密码。 新员工密码的登录信息通过这样的通信渠道在那里发送(指示IdM从何处获取地址)。
  3. IdM会在AD中自动创建一个帐户,该帐户的目录(OU-组织单位)中的属性(列表)与新员工的单位相对应。 根据这样的规则来形成登录名,根据这样的规则来形成密码。 新员工的登录名和密码上的数据通过这样的通信通道在那里发送(指示IdM从何处获取收件人以及该通信通道的参数)。
  4. 创建的AD帐户按组放置(我们列出或指示“根据角色模型”)。 还需要在单独的一章的ToR中考虑和描述角色模型。 此类小组的任命是与这些人(我们列出)达成的协议。 系统会生成有关向新员工分配权限的通知(指定收件人标识算法;单独描述批准途径),并向协调员发出有关协调应用程序的需求的提醒(指定收件人标识算法,提醒的开始,结束和频率)。
  5. 在AD中创建帐户后,IdM会为新员工启动Exchange邮箱的创建。 有关新邮箱的信息存储在IdM中,并显示在员工卡上。

以大致相同的方式,我们描述了系统与CRM的交互...

因此,在以这种方式考虑自动化过程的过程中,每个系统的对象模型,每种对象的属性的组成都变得清晰,形成了各种对象的属性之间数据的移动和转换的图片。 而且,对象之间的连接变得可见,显示了其他过程,例如维护所有系统中的数据一致性。

一个简单的例子:在人事系统中更改员工的姓名时,其姓名必须在连接到IdM的所有其他系统的配置文件中更改。 但是它可能不会更改,因为在某些系统中,名称根本不存储。

一个例子更加复杂:新雇员的AD帐户必须在与其单位对应的OU中创建。 出现了一个问题,如果在人事系统中建立了新单位,但尚未在AD中创建该单位怎么办? 因此,揭示了在AD中复制存储在人事系统中的组织结构的单独过程,这在ToR中也值得描述。

与系统集成


如您所见,TK的形成是一个反复的过程。 在确定了需要执行的对象和动作之后,就可以清楚必须在集成系统的连接器中实现的功能集。 在这里,我们顺利进行了IdM实施的另一个重要阶段- 与系统的实际集成 。 实际上,这一阶段对于IdM集成商和实施IdM基础架构的公司而言都是非常痛苦的。

为了使一切顺利,您需要了解一些在集成各种软件产品时适用的一般原则。 首先,您需要了解在集成系统中与IdM集成的API的重要性。 连接器和API是两件事。 如果集成商说他有连接到各种系统的连接器,或准备将连接器写到任何系统,则这并不意味着集成问题已完全解决,客户公司无需为此做任何事情。

我将举例说明。 为了将发电厂与熨斗连接以便为了执行其已知功能而对其进行加热,有必要使发电站具有插座,并且熨斗具有插头。 插座和插头。 2件事。 没有一个 通过使用电站侧面的插座和熨斗侧面的插头,将熨斗与电源系统集成在一起。 如果将IdM与任何其他系统集成,则还需要做两件事:IdM侧的连接器和系统侧的API。 这很重要! 否则,可能会发生各种不愉快的事件。 连接器的目的仅仅是以发送数据的形式从系统接收必要的数据,然后以IdM可以接收它们的形式将其传输到IdM。 相同的连接器的作用方向相反:它以IdM发出命令的形式从IdM接收命令和数据集,并将所有这些信息和数据集以系统理解其需要做什么的形式发送给系统。 但是! 原则上,该系统应能够生成IdM所需的数据并执行必要的命令以与IdM协同工作。 这是API的主要目的-提供IdM可以与连接器一起作用的接口,以在系统上执行各种操作。

通常,即使在出售IdM之前,一个负责任的集成商也会着眼于客户为所有与IdM连接的系统提供API的需求,并报告实现这些API的要求。 这本质上是带有输入和输出参数的函数的枚举。 例如:

  • 搜索所有系统帐户。 没有输入参数。 输出是具有所有属性的所有帐户的列表。
  • 通过ID搜索帐户。 输入参数是超声的标识符。 注销-符合搜索条件且具有所有属性的帐户。
  • 创建一个帐户。 输入参数-登录名,密码,全名...退出-新超声的标识符。
  • 帐户锁定。 输入参数-超声标识符。 没有输出参数。
  • 依此类推...

也就是说,API是与IdM交互所需的一组功能。 问题在于系统中这些功能的一部分可能根本无法以正确的形式实现。 仅因为这还没有必要。 可以实现部分功能,但需要一个复杂的,多层的,逐步的过程。 例如,在一个家庭银行自动系统中,在创建用户帐户之前,先用三个辅助属性和标志填充三个不同的目录。 或者,某些功能可以以简单的形式实现,但无法发布,也就是说,不能从外部使用这些功能。 因此,API旨在解决所有这些问题。 API是功能,它们以正确,正确的工作形式执行为其外部调用发布的,将集成系统与IdM集成所需的操作。 这样,任何不了解系统内部厨房的软件工程师都可以使用它们,轻松地完成所需的工作。

然后,通常会给客户带来问题,这会给IdM实施工程师带来痛苦的痛苦:为什么IdM集成商不能单独实现API集成器?

想象一下一个复杂的企业管理系统,其中现在必须使用IdM实施用户权限管理。 供应商从90年代就开始编写此系统。 在漫长的生命中,其架构已发生了四次更改。 用户权限管理子系统无法跟上系统本身功能的快速发展,它是由几代程序员根据他们对逻辑的理解和合理理解,并根据“我如何弄清楚自己”的原理(即以拐杖的方式)实现的。 无需谈论记录所有这些操作。 目前,一切都在以某种方式进行。 供应商的员工只有在迫切需要纠正一些可怕的错误时才不情愿地爬上系统的旧代码,进行了3​​次洗礼,并向显示器洒了圣水,并用铃鼓覆盖,所以上帝禁止不要破坏任何拐杖,以免一切都不会掉落。



现在,使用这种神奇产品的客户公司已经到了实施IdM的黄金时期。 提供了API要求,没有API。 客户不在乎谁会编写API。 他用拳头在桌子上敲打拳头,上面写着“我在哭成千上万,要这样做”,然后离开会议,故意砸门。 魔术软件的供应商也不在乎。 他不会免费做任何事情,但是他们忘了将预算投入到API的实现中,以实现生动的彩虹梦,即关于IdM引入后一切将变得多么酷的想法。 同时,签订合同,“钱已经付清”,狂野的跨越开始了。

IdM集成商的一名员工,可怜的Pasha程序员,正试图让他们惊恐地了解必须采取什么蹲法才能从系统中获得正常反应。 它研究公共资源,st,过时的文档,了解未知系统的源代码并破坏供应商的电话。 经过几周的磨难后,他意识到蹲下是不够的,需要弹跳,甚至还需要翻筋斗,但这并不是事实会有所帮助的事实......一个月后,连接器出现了,某种或多或少都在起作用。 轻微的故障,如何发生。 集成人员中的可怜的Pasha程序员在编写时变成了灰色。 魔术系统已集成,但是问题在于创建的帐户不是很正确,系统管理员必须手动将帐户“回滚”到工作状态。 密码每隔一段时间就会更改一次,而记账的“幸运”玛丽娜·伊万诺夫娜却一直封锁她的帐户。 “企业”的员工充斥着技术支持,并提出了恶毒的抱怨:“要持续多长时间?”,“不可能工作!”,“照原样做……”首先,客户要求修理所有东西,并用拖鞋砸桌子,使它到达已经秃顶的Pasha程序员。 然后,由于频繁的故障和业务部门之间不断增长的不满情绪,IdM与魔术系统的集成被中断了。

你会在这里做什么? 谁该怪? 如果不是系统供应商,那么谁应该从目录,函数,标牌,触发器,标志和拐杖中找出他所做的所有混乱呢? IdM集成商? 他如何知道如何在供应商无法弄清楚的系统中正确实现功能? 如果可以,那么花一些钱? 是的,现在我的色彩很浓。 当系统不是很复杂时,会有一些例外,您可以在不使用特殊API的情况下将其集成。 但是要合理。 如果目标是避免不必要的问题,帮助企业发展并实现利润(我认为这是任何公司的IT部门的主要目标)并享受所有系统的平稳运行,请考虑与系统集成的方法。 将预算中用于研究整合机会和有效实施缺失组件的必要费用。 Avaricious支付两次,甚至三次。 保存到最后,Pasha程序员:D。 他几乎秃了。 并且不要忘记修复TK中的集成方法!



我们建立公司的榜样


我还要特别注意公司的榜样的形成。 事实是,每个系统都有其自己独有的所谓“权威”实体集-这些对象在系统中提供用户特权。 可以将各种组,角色,配置文件,用途,目录,特权,操作类型等分配给此类对象...权限的划分可能非常深,因此,我们获得了大量的托管对象。 例如,AD中的某些安全组可以是数百甚至数千。 在某些财务管理系统中,可以向每个用户分配帐户表中一百万个帐户中的每个帐户的专有权限。 如果我们与SAP集成? 原子权的数量可以用数十万甚至数百万来衡量。

另外,该系统可以支持分层嵌套以及不同类型的授权实体之间的复杂关系。 这本身就对系统中管理用户权限的可能性进行了单独研究。 因此, 在设计家庭中的IdM实施方案之前,必须根据项目的目标,决定要通过IdM管理的权限和粒度级别。 最主要的是及时停止。 一切都应该是必要和充分的。 如果要为系统中的每个帐户管理单独的用户权限,请准备适当的工作量以协调和撤销帐户表中的每个更改的用户权限。

处理角色模型时,必须确定:

  • IdM中访问权限对象的来源,即角色本身。 .
  • . IdM , « ».
  • . .


好吧,也许是时候四舍五入了。我想谈的还有很多:关于访问权限的差异,关于测试环境的质量,关于确保容错的方法。只有一个结论:在设计阶段解决方案的高质量开发是整个企业成功的50%。此类需求的早期文档将以所需的形式帮助您以最小的成本和损失实现所有流程的自动化,而不会像集成商所想的那样。这将显着加快IdM配置过程,使程序逻辑在其操作和支持阶段透明。

不要害羞,最重要的是不要懒惰地理解一切。我们将为您提供帮助。

由Solar inRights实施工程师Maria Tyurina发布

Source: https://habr.com/ru/post/zh-CN461181/


All Articles