一篇全面介绍和了解“中台”概念的文章

zkbhj 发表了文章 • 0 个评论 • 1205 次浏览 • 2019-10-17 15:08 • 来自相关话题

从 15 年开始,到 19 年现在为止。各大公司都在吹捧中台理念。仿佛中台是业务复杂性的救世主。是某些架构师和 PM 的新出路。各种割韭菜的讲中台的课程层出不穷。

当然,吹牛逼的时候大家都是拣好的说,苦逼的东西就只有内部人士知道。中台到底靠谱还是不靠谱,只凭各路英雄的演讲内容,那看起来是靠谱的。

先来看看这些公开的观点,再以我(码农桃花源注:资深研发工程师)的视角还原“中台”的真相。
公开的观点

中台是什么

阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部,包含了用户中心、商品中心、交易中心、评价中心等十几个中心,而共享业务事业部正是“厚平台”的真实体现,为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。
钟华. 《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》


中台实际上是通用业务的下沉,企业在一个行业耕耘多年之后,一般都会形成一些公用的业务,而这些业务是可以像中间件那样进行下沉共享的。

再往前推一些,也就是比较早期人们常说的偏业务的基础服务。在概念上并不是创新。

为什么要做中台

中台解决了什么问题?

其实和把程序内的公用逻辑封装为 library 差不多,就是尽量避免重复造轮子。一个轮子造 100 遍,对部门是没有任何好处的。一个系统造 100 遍,对企业自然是没什么帮助的。

早期的企业经常借鉴腾讯经验,鼓励内部竞争。但内部竞争的度往往不好把握,经常会出现“所有部门都在造差不多的系统”的现象。

中台从公司战略角度,将这些行为进行了规范化,公共的部分交给公共系统部门去做。

中台给企业带来的收益

工程方面

就像上面提到的,首先是有效减少了重复造轮子、重复建系统的现象。有相对统一的业务收敛位置,并在公共服务上快速高效迭代出新的业务。

数据方面

有了统一的用户、订单系统,就不会再有各种恶心的数据打通问题,不会有跨部门的数据墙。

有了统一的中台,也就有了统一的数据规范。

对于大数据相关的需求,可以从相对唯一的数据出口进行业务迭代,不需要为每一个部门进行定制开发,浪费人力。

创新方面

这一项目也很好地诠释了之前所说的“点、线、面”的理论,在“点”上根本感知不到的问题,在“线”和“面”的平台上,更容易发现这些问题的本质,通过专业的技能解决这些问题,为企业带来实实在在的业务价值,这就是很好的创新!
钟华. 《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》


有了公共的中台,意味着有了相对全局的视角,更能发现单点观察难以发现的问题。在更大的业务层面进行一定的创新。听着很有道理。

真相

中台能解决问题么?是能解决的。中台能解决所有问题么?那显然是不能的。

就像微服务架构一样,架构师吹牛的时候天花乱坠,你做起来却发现这条路上全都是坑。

技术方面

公用业务下沉,这个理念其实很朴素。所有程序员都知道我们公用的逻辑要进行封装、抽象,变成 Library。中台的本质其实就是把这种朴素的思想进行了一定程度的推广。(码农桃花源注:新瓶装旧酒)

难以应对 Cross cutting concern

根据中台进行系统拆分和部门调整之后,还是会遇到 cross cutting concern,什么是 cross cutting concern:

The crosscutting concern is a concern which is applicable throughout the application and it affects the entire application. For example: logging, security and data transfer are the concerns which are needed in almost every module of an application, hence they are cross-cutting concerns.


有些需求难以避免地会影响整个流程中的所有系统。

比如从技术范畴进行的一些改造(如为了完成 tracing,所有系统增加 trace id,并在 log 中默认携带)。

比如从业务范畴进行的 i18n改造。(码农桃花源注:i18n 是国际化的意思,Internationalization 去掉头尾的 i 和 n 刚好还剩下 18 个字符,程序员的智慧)

这些改造需求一般天生就是跨系统、跨组、跨部门的,事情一带上“跨”的字眼,就不好搞了。(码农桃花源注:别人的地盘,你能做主?)

举一个典型的例子,某巨型互联网公司员工抱怨,在当前的微服务和中台架构前提下,做一个需求经常要改 20+ 个模块,苦不堪言,连上线顺序都不一定搞得清楚。

当这 20+ 个模块又是跨部门的时候,就更难了。想要推动其它部门做一些短期看起来没啥收益的事,太难了。

稳定性和灵活性的矛盾

对于一个系统来说,追求稳定性,那么必然会在修改和升级上较为消极;追求灵活性,那在功能迭代上一定会较为激进。这两方面的矛盾本来就是难以调和的。追求其中之一,在一定程度上就得放弃另一方面。

就像网友经常讲的不作死就不会死,没有代码才是真正的稳定之道。Google 程序员在 Github 上发起的行为艺术项目:nocode,没有 code,就没有 bug。可谓弃疗的典范。

有很多中台系统被剥离之后,因为用户众多,一旦出现技术上的问题,影响面巨大。从我的实际观察来看,中台部门的系统虽然初始立项的时候声势浩大,但基本也没什么人关注这些公共系统的代码质量或者测试质量。最终只不过是大家公用了一堆“垃圾”,“垃圾”在转过几手之后,后来的人基本就不太想对原来的代码进行修改了。

可能有人会讲你可以重构啊。嗯,重构的前提是系统有完善的测试用例和可以跑的测试。事实上一般都没有!在没有测试的情况下,我们可以根据过往的系统需求文档和 PRD(码农桃花源注:产品需求文档,Product Requirements Document)来还原当时的业务场景,并进行测试补充。

但你又发现,中台的性质(大多偏技术项目,基本没什么 PM 把关或者出文档)使其基本没有什么靠谱的、详尽的文档。写的复杂的中台,连业务流程都理不清楚,还想写测试,别做梦了哦。

中台与前台的模糊业务边界、距离

在实际实践时,中台与 FT 的边界往往划得不清不楚。比如用户服务、用户权益、用户在各种子系统中的状态,这些内容可能并不是用户服务本身关心的内容。但往往需求也会提给用户服务,这时候用户服务就只是进行字段存储,而状态机变化则完全在外部。

如果对系统内的个别数据不进行管理,那么有其它接入方接入时,就无法解释清楚字段的含义和使用场景。如果不接受这些不相干的数据接入,那么前台流程系统可能会在自己内部重新建立自己的数据系统,这部分系统又极有可能和中台有功能上的重叠。

如果想要把这些数据接管过来,那么中台又需要梳理所有业务场景。或者说明需要把所有对数据进行修改的逻辑全部收拢到中台内部,这往往又会产生与中台与前台业务边界的冲突。

难以给出有效的边界,就意味着无穷无尽的撕逼。这便是很多中台的两难:我接不是,不接也不是。

如果去问那些中台业务部门的系统开发负责人:某些业务要不要你们来做,连这些人自己都说不清楚。

人方面

如果要做中台,那往往需要将业务部门的一部分系统进行下沉。下沉并不仅仅是一个技术问题。如果要把系统从一个部门变到另一个部门,这一定会带来人员的调动。从情感上来讲,人们都是讨厌这种部门变动的。因为“领导”会在部门调整中发生变化,同事也经常会随着部门调整而离职。只留自己在原地填坑给谁都不愿意。

也有些公司在调整中进行粗暴的系统交接,如果系统需要下沉,那我直接从原来的维护团队手里夺过来,交给中台部门来管理。这一样会引起双方的反感:
 

交接方:这是我们加班加点,辛辛苦苦开发出来的系统,凭什么交给别人?奋斗了半年难道就是为了给别人摘桃子?

被交接方:这个系统原来的维护团队水平极低,代码就是一堆“垃圾”,他们不想搞了就随便扔给我们?凭什么啊?我们又不是接盘侠。


即使贵司运气好,在系统交接过程中没有出现问题,那交接后也不好说。被交接的系统在交接后往往陷入消极维护状态,这时候前台业务接入中台会比以往更加困难,这种困难使前台业务的不满积累到一定程度之后,会再次催生前台部门重新造一套新的自己的中台,而部分或全部放弃原来的中台。这样,原来的中台部门便会陷入尴尬的境地。

生存空间被挤压,人也自然很难待得下去,各公司的中台部门,人跑的比香港记者都快。

部门、公司、组织架构方面

跨部门沟通障碍、跨部门目标差异

进行部门划分之后,每个业务部门会有自己的一套目标体系。部门与部门的目标(KPI)一般是不相同的,如果相同的话,那也就没必要分多个部门了。

而部门与部门之间的目标在某种程度上甚至可能有冲突,例如 A 部门 Feature Team 较多,主要负责业务功能迭代,需要更强的灵活性。而 B 部门负责中台数据,主要关心系统稳定性,也就是前文提到的灵活性和稳定性的矛盾。若此时出现 cross cutting concern,两个部门需要在矛盾上取得一定程度的平衡,这种平衡在个别情况下是不可得的。

例如在一段时间内,中台部门的目标是提高某个商业指标,让公司更赚钱/省钱。这时候前台业务提来了新的需求,这种需求是能使流程开发更加灵活的,但与中台部门的 KPI 不在一个航道上。

中台部门显然要把需求排排优先级,把任务排排主次。前台部门又会觉得中台支持个需求怎么这么龟速又唧唧歪歪,不如自己实现了。

前台业务也有自己的理由:“自闭环”嘛,这词真是好用。

公司利益分配

毫无疑问,距离业务近的地方比距离业务远的地方能分到更多公司增长的成果。中台看起来是业务,但又是公共业务,既然是公共业务,那基本上没办法分享到任一单一业务成功的红利。纵使其成功的原因中,中台的强大、便捷是重要原因。

这会导致什么问题呢?没有人愿意接手中台项目,中台项目变成烫手的山芋。大佬无法在中台项目上获得红利,小弟们没法在中台项目上获得利益。中台功能确定以后,只有出事故的时候大家才想起你来。稳定运行是应该的,出事就是你的锅!

利润中心?其实是成本中心

最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能,转变为基于企业核心业务和数据进行运营的团队,这个团队会更快、更好地支持业务发展的同时,逐渐掌握企业最核心的业务和数据,逐步培养出企业最稀缺的“既精通业务,又熟悉技术”的复合型人才。在接下来整个社会进入开放共享的时代,企业最大的价值将会是基于这些核心业务和数据进行对外开放的运营,到那个时候,这个部门将成为企业最为宝贵的资产。
钟华. 《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》


在大多数公司,中台部门和基础架构一样,会被当成是包袱而不是财富。可能有些人读到这里会不太爽。我们来看看,科技公司是怎么看待员工的呢?

在 DDD(码农桃花源注:领域驱动设计,Domain Driven Design)相关的书里提到两个概念:成本中心、利润中心。技术对业务参与不强的情况下,技术部门基本上都会被当作是成本中心。也就是老板要达成自己的目标,必须不情不愿地花钱去养你们这些技术团队。

对应业务侧开发来说,想要改变老板的这种看法,需要让业务系统和业务人员之间进行强联动,将一部分业务人员变成系统人员架构中的业务专家角色,或者是研发人员自己变成一个业务领域专家,就是有些人常说的你得跟老板穿一条裤子。

从这方面来讲,大多公司的基础架构角色就比较尴尬。业务驱动的公司,基础架构并不是其致胜要素。所以不管你做的再好,只要公司没有用技术赚钱,那么这部分的支出就只能被当作单纯的成本。

当然了很多做基础的大佬也根本不在乎,公司只是个练兵场,练成了带小弟们跳槽就好。(码农桃花源注:求带!)

中台也是一样的,从业务一线剥离到后方之后。中台离业务的距离越来越远。公司高层渐渐看不到继续对中台进行投入的价值,中台便渐渐变成了他们眼中纯粹的成本中心,是公司财务的包袱而不是财富。

行业方面

中台建设一般要考虑公司的实际情况,这样建设出来的系统可以应对一段时间内的公司业务变化。然而公司的压力有时并不来自于自己的业务方向,可能来自于行业内其它公司的模式挑战。

理论上来说,只要一个公司的业务系统架构建设完成了,便已经完成了一种架构上的 固化。这时行业内如果有新的模式获得了成功,公司肯定要进行跟进。但是新的模式一定意味着对原有系统、架构的挑战。

试想,原来系统架构是针对线上交易设计的,突然有一天,O2O 模式被证明有利可图,大多数公司都开始转向线下。原有的流程、模式当然想要复用,但是这时候复用的成本很可能比重新开发还要高。眼睁睁看着竞争对手们甩掉包袱,轻装上阵,以更低的成本更短的时间攻城略地,挤压自己的生存空间。

这时候怎么办呢?大多数公司给出的方案是成立新的业务部门,在新趋势新阵地冲锋陷阵。新部门肯定也要用到原来公司的老服务,又碰到了我们的老问题:跨部门合作。新部门的成功并不会让老部门多得到多少好处,配合自然不会太积极。(码农桃花源注:公司内部做事都是利益驱动)

如果新部门的尝试获得了初步成功,得到了公司资源的倾斜,获得了有效的人力资源补充。之后又会带来新一轮重复造轮子,互相不合作,互相撕逼的腥风血雨。

简直是一个轮回。

结语

经常有小伙伴说,国内某公司中台非常好,大家都在学。嗯,我倒是想问问了,如果真的做的好,某公司旗下的金融公司和电商公司还会需要两套完全一样的基础架构,和好几朵云?(码农桃花源注:曹大真敢怼!)

作为一个技术人员,在各种乌七八糟、花里胡哨的概念“轰炸”下,应该能够保持理智,不要被各种人带节奏。

作者:码农桃花源
链接:http://www.imooc.com/article/292904
来源:慕课网
本文原创发布于慕课网 ,转载请注明出处,谢谢合作 查看全部
从 15 年开始,到 19 年现在为止。各大公司都在吹捧中台理念。仿佛中台是业务复杂性的救世主。是某些架构师和 PM 的新出路。各种割韭菜的讲中台的课程层出不穷。

当然,吹牛逼的时候大家都是拣好的说,苦逼的东西就只有内部人士知道。中台到底靠谱还是不靠谱,只凭各路英雄的演讲内容,那看起来是靠谱的。

先来看看这些公开的观点,再以我(码农桃花源注:资深研发工程师)的视角还原“中台”的真相。
公开的观点

中台是什么


阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部,包含了用户中心、商品中心、交易中心、评价中心等十几个中心,而共享业务事业部正是“厚平台”的真实体现,为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。
钟华. 《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》



中台实际上是通用业务的下沉,企业在一个行业耕耘多年之后,一般都会形成一些公用的业务,而这些业务是可以像中间件那样进行下沉共享的。

再往前推一些,也就是比较早期人们常说的偏业务的基础服务。在概念上并不是创新。

为什么要做中台

中台解决了什么问题?

其实和把程序内的公用逻辑封装为 library 差不多,就是尽量避免重复造轮子。一个轮子造 100 遍,对部门是没有任何好处的。一个系统造 100 遍,对企业自然是没什么帮助的。

早期的企业经常借鉴腾讯经验,鼓励内部竞争。但内部竞争的度往往不好把握,经常会出现“所有部门都在造差不多的系统”的现象。

中台从公司战略角度,将这些行为进行了规范化,公共的部分交给公共系统部门去做。

中台给企业带来的收益

工程方面

就像上面提到的,首先是有效减少了重复造轮子、重复建系统的现象。有相对统一的业务收敛位置,并在公共服务上快速高效迭代出新的业务。

数据方面

有了统一的用户、订单系统,就不会再有各种恶心的数据打通问题,不会有跨部门的数据墙。

有了统一的中台,也就有了统一的数据规范。

对于大数据相关的需求,可以从相对唯一的数据出口进行业务迭代,不需要为每一个部门进行定制开发,浪费人力。

创新方面


这一项目也很好地诠释了之前所说的“点、线、面”的理论,在“点”上根本感知不到的问题,在“线”和“面”的平台上,更容易发现这些问题的本质,通过专业的技能解决这些问题,为企业带来实实在在的业务价值,这就是很好的创新!
钟华. 《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》



有了公共的中台,意味着有了相对全局的视角,更能发现单点观察难以发现的问题。在更大的业务层面进行一定的创新。听着很有道理。

真相

中台能解决问题么?是能解决的。中台能解决所有问题么?那显然是不能的。

就像微服务架构一样,架构师吹牛的时候天花乱坠,你做起来却发现这条路上全都是坑。

技术方面

公用业务下沉,这个理念其实很朴素。所有程序员都知道我们公用的逻辑要进行封装、抽象,变成 Library。中台的本质其实就是把这种朴素的思想进行了一定程度的推广。(码农桃花源注:新瓶装旧酒)

难以应对 Cross cutting concern

根据中台进行系统拆分和部门调整之后,还是会遇到 cross cutting concern,什么是 cross cutting concern:


The crosscutting concern is a concern which is applicable throughout the application and it affects the entire application. For example: logging, security and data transfer are the concerns which are needed in almost every module of an application, hence they are cross-cutting concerns.



有些需求难以避免地会影响整个流程中的所有系统。

比如从技术范畴进行的一些改造(如为了完成 tracing,所有系统增加 trace id,并在 log 中默认携带)。

比如从业务范畴进行的 i18n改造。(码农桃花源注:i18n 是国际化的意思,Internationalization 去掉头尾的 i 和 n 刚好还剩下 18 个字符,程序员的智慧)

这些改造需求一般天生就是跨系统、跨组、跨部门的,事情一带上“跨”的字眼,就不好搞了。(码农桃花源注:别人的地盘,你能做主?)

举一个典型的例子,某巨型互联网公司员工抱怨,在当前的微服务和中台架构前提下,做一个需求经常要改 20+ 个模块,苦不堪言,连上线顺序都不一定搞得清楚。

当这 20+ 个模块又是跨部门的时候,就更难了。想要推动其它部门做一些短期看起来没啥收益的事,太难了。

稳定性和灵活性的矛盾

对于一个系统来说,追求稳定性,那么必然会在修改和升级上较为消极;追求灵活性,那在功能迭代上一定会较为激进。这两方面的矛盾本来就是难以调和的。追求其中之一,在一定程度上就得放弃另一方面。

就像网友经常讲的不作死就不会死,没有代码才是真正的稳定之道。Google 程序员在 Github 上发起的行为艺术项目:nocode,没有 code,就没有 bug。可谓弃疗的典范。

有很多中台系统被剥离之后,因为用户众多,一旦出现技术上的问题,影响面巨大。从我的实际观察来看,中台部门的系统虽然初始立项的时候声势浩大,但基本也没什么人关注这些公共系统的代码质量或者测试质量。最终只不过是大家公用了一堆“垃圾”,“垃圾”在转过几手之后,后来的人基本就不太想对原来的代码进行修改了。

可能有人会讲你可以重构啊。嗯,重构的前提是系统有完善的测试用例和可以跑的测试。事实上一般都没有!在没有测试的情况下,我们可以根据过往的系统需求文档和 PRD(码农桃花源注:产品需求文档,Product Requirements Document)来还原当时的业务场景,并进行测试补充。

但你又发现,中台的性质(大多偏技术项目,基本没什么 PM 把关或者出文档)使其基本没有什么靠谱的、详尽的文档。写的复杂的中台,连业务流程都理不清楚,还想写测试,别做梦了哦。

中台与前台的模糊业务边界、距离

在实际实践时,中台与 FT 的边界往往划得不清不楚。比如用户服务、用户权益、用户在各种子系统中的状态,这些内容可能并不是用户服务本身关心的内容。但往往需求也会提给用户服务,这时候用户服务就只是进行字段存储,而状态机变化则完全在外部。

如果对系统内的个别数据不进行管理,那么有其它接入方接入时,就无法解释清楚字段的含义和使用场景。如果不接受这些不相干的数据接入,那么前台流程系统可能会在自己内部重新建立自己的数据系统,这部分系统又极有可能和中台有功能上的重叠。

如果想要把这些数据接管过来,那么中台又需要梳理所有业务场景。或者说明需要把所有对数据进行修改的逻辑全部收拢到中台内部,这往往又会产生与中台与前台业务边界的冲突。

难以给出有效的边界,就意味着无穷无尽的撕逼。这便是很多中台的两难:我接不是,不接也不是。

如果去问那些中台业务部门的系统开发负责人:某些业务要不要你们来做,连这些人自己都说不清楚。

人方面

如果要做中台,那往往需要将业务部门的一部分系统进行下沉。下沉并不仅仅是一个技术问题。如果要把系统从一个部门变到另一个部门,这一定会带来人员的调动。从情感上来讲,人们都是讨厌这种部门变动的。因为“领导”会在部门调整中发生变化,同事也经常会随着部门调整而离职。只留自己在原地填坑给谁都不愿意。

也有些公司在调整中进行粗暴的系统交接,如果系统需要下沉,那我直接从原来的维护团队手里夺过来,交给中台部门来管理。这一样会引起双方的反感:
 


交接方:这是我们加班加点,辛辛苦苦开发出来的系统,凭什么交给别人?奋斗了半年难道就是为了给别人摘桃子?

被交接方:这个系统原来的维护团队水平极低,代码就是一堆“垃圾”,他们不想搞了就随便扔给我们?凭什么啊?我们又不是接盘侠。



即使贵司运气好,在系统交接过程中没有出现问题,那交接后也不好说。被交接的系统在交接后往往陷入消极维护状态,这时候前台业务接入中台会比以往更加困难,这种困难使前台业务的不满积累到一定程度之后,会再次催生前台部门重新造一套新的自己的中台,而部分或全部放弃原来的中台。这样,原来的中台部门便会陷入尴尬的境地。

生存空间被挤压,人也自然很难待得下去,各公司的中台部门,人跑的比香港记者都快。

部门、公司、组织架构方面

跨部门沟通障碍、跨部门目标差异

进行部门划分之后,每个业务部门会有自己的一套目标体系。部门与部门的目标(KPI)一般是不相同的,如果相同的话,那也就没必要分多个部门了。

而部门与部门之间的目标在某种程度上甚至可能有冲突,例如 A 部门 Feature Team 较多,主要负责业务功能迭代,需要更强的灵活性。而 B 部门负责中台数据,主要关心系统稳定性,也就是前文提到的灵活性和稳定性的矛盾。若此时出现 cross cutting concern,两个部门需要在矛盾上取得一定程度的平衡,这种平衡在个别情况下是不可得的。

例如在一段时间内,中台部门的目标是提高某个商业指标,让公司更赚钱/省钱。这时候前台业务提来了新的需求,这种需求是能使流程开发更加灵活的,但与中台部门的 KPI 不在一个航道上。

中台部门显然要把需求排排优先级,把任务排排主次。前台部门又会觉得中台支持个需求怎么这么龟速又唧唧歪歪,不如自己实现了。

前台业务也有自己的理由:“自闭环”嘛,这词真是好用。

公司利益分配

毫无疑问,距离业务近的地方比距离业务远的地方能分到更多公司增长的成果。中台看起来是业务,但又是公共业务,既然是公共业务,那基本上没办法分享到任一单一业务成功的红利。纵使其成功的原因中,中台的强大、便捷是重要原因。

这会导致什么问题呢?没有人愿意接手中台项目,中台项目变成烫手的山芋。大佬无法在中台项目上获得红利,小弟们没法在中台项目上获得利益。中台功能确定以后,只有出事故的时候大家才想起你来。稳定运行是应该的,出事就是你的锅!

利润中心?其实是成本中心


最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能,转变为基于企业核心业务和数据进行运营的团队,这个团队会更快、更好地支持业务发展的同时,逐渐掌握企业最核心的业务和数据,逐步培养出企业最稀缺的“既精通业务,又熟悉技术”的复合型人才。在接下来整个社会进入开放共享的时代,企业最大的价值将会是基于这些核心业务和数据进行对外开放的运营,到那个时候,这个部门将成为企业最为宝贵的资产。
钟华. 《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》



在大多数公司,中台部门和基础架构一样,会被当成是包袱而不是财富。可能有些人读到这里会不太爽。我们来看看,科技公司是怎么看待员工的呢?

在 DDD(码农桃花源注:领域驱动设计,Domain Driven Design)相关的书里提到两个概念:成本中心、利润中心。技术对业务参与不强的情况下,技术部门基本上都会被当作是成本中心。也就是老板要达成自己的目标,必须不情不愿地花钱去养你们这些技术团队。

对应业务侧开发来说,想要改变老板的这种看法,需要让业务系统和业务人员之间进行强联动,将一部分业务人员变成系统人员架构中的业务专家角色,或者是研发人员自己变成一个业务领域专家,就是有些人常说的你得跟老板穿一条裤子。

从这方面来讲,大多公司的基础架构角色就比较尴尬。业务驱动的公司,基础架构并不是其致胜要素。所以不管你做的再好,只要公司没有用技术赚钱,那么这部分的支出就只能被当作单纯的成本。

当然了很多做基础的大佬也根本不在乎,公司只是个练兵场,练成了带小弟们跳槽就好。(码农桃花源注:求带!)

中台也是一样的,从业务一线剥离到后方之后。中台离业务的距离越来越远。公司高层渐渐看不到继续对中台进行投入的价值,中台便渐渐变成了他们眼中纯粹的成本中心,是公司财务的包袱而不是财富。

行业方面

中台建设一般要考虑公司的实际情况,这样建设出来的系统可以应对一段时间内的公司业务变化。然而公司的压力有时并不来自于自己的业务方向,可能来自于行业内其它公司的模式挑战。

理论上来说,只要一个公司的业务系统架构建设完成了,便已经完成了一种架构上的 固化。这时行业内如果有新的模式获得了成功,公司肯定要进行跟进。但是新的模式一定意味着对原有系统、架构的挑战。

试想,原来系统架构是针对线上交易设计的,突然有一天,O2O 模式被证明有利可图,大多数公司都开始转向线下。原有的流程、模式当然想要复用,但是这时候复用的成本很可能比重新开发还要高。眼睁睁看着竞争对手们甩掉包袱,轻装上阵,以更低的成本更短的时间攻城略地,挤压自己的生存空间。

这时候怎么办呢?大多数公司给出的方案是成立新的业务部门,在新趋势新阵地冲锋陷阵。新部门肯定也要用到原来公司的老服务,又碰到了我们的老问题:跨部门合作。新部门的成功并不会让老部门多得到多少好处,配合自然不会太积极。(码农桃花源注:公司内部做事都是利益驱动)

如果新部门的尝试获得了初步成功,得到了公司资源的倾斜,获得了有效的人力资源补充。之后又会带来新一轮重复造轮子,互相不合作,互相撕逼的腥风血雨。

简直是一个轮回。

结语

经常有小伙伴说,国内某公司中台非常好,大家都在学。嗯,我倒是想问问了,如果真的做的好,某公司旗下的金融公司和电商公司还会需要两套完全一样的基础架构,和好几朵云?(码农桃花源注:曹大真敢怼!)

作为一个技术人员,在各种乌七八糟、花里胡哨的概念“轰炸”下,应该能够保持理智,不要被各种人带节奏。

作者:码农桃花源
链接:http://www.imooc.com/article/292904
来源:慕课网
本文原创发布于慕课网 ,转载请注明出处,谢谢合作

什么是波兰式?什么是逆波兰式?

回复

zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 3110 次浏览 • 2019-09-28 17:17 • 来自相关话题

两种数据序列化方案性能对比:Msgpack和Json

zkbhj 发表了文章 • 0 个评论 • 6583 次浏览 • 2019-01-23 11:00 • 来自相关话题

    MessagePack(简写msgpack)是一个高效的二进制序列化格式。它让你像JSON一样可以在各种语言之间交换数据。但是它比JSON更快、更小。小的整数会被编码成一个字节,短的字符串仅仅只需要比它的长度多一字节的大小。之前在lua脚本中使用过msgpack,因为有大量数据要入redis,而考虑到内存开销,使用了压缩比更大的msgpack。因为msgpack是一个二进制格式,所以没法像json后的字符串一样可直观地查看数据。
 
    msgpack的官网地址:http://pecl.php.net/package/msgpack 里面有各PHP版本windows下的dll扩展,也有源码包供linux下编译,所以像lua这样的脚本语言可以直接使用。msgpack和json_encode都是序列化存储数据,那么msgpack的效率与json的效率相比的话到底怎么样呢?看下面这个简单的对比程序:
//msgpack与json的性能对比
//1,数据拼凑
$data =array(
'youku' => '优酷视频', 'pptv' => 'PPTV', 'sohu' => '搜狐视频', 'qiyi' => '奇艺视频', 'letv' => '乐视视频',
'tencent' => '腾讯视频', 'sina' => '新浪视频', 'tudou' => '土豆视频', 'm1905' => '电影网', 'cntv' => 'CNTV',
);
$data = json_encode($data);
$newArr = array();
for($i = 1; $i<=500; $i++) //修改此处$i的最大值以控制数据的大小
{
$newArr [] =$data;
}

//数据大小对比
$msg_data = msgpack_pack($newArr);
echo "使用msgpack处理后大小:".strlen($msg_data);
$json_data = json_encode($newArr);
echo "<br>使用json处理后大小:".strlen($json_data);
echo "<br>msgpack处理后大小与json处理后大小比为1:".round((strlen($json_data)/strlen($msg_data)),2);

//计算1000次msgpack压缩用时
$time = microtime(true);
for($i = 1; $i<1000; $i++){
msgpack_pack($newArr);
}
echo '<br>1000次msgpack操作用时:'.(microtime(true)- $time);

//计算1000次json_encode压缩用时
$time1 = microtime(true);
for($i = 1; $i<1000; $i++){
json_encode($newArr);
}
echo '<br>1000次json_encode操作用时:'.(microtime(true)- $time1); 程序过程没什么可说的了,就是先拼凑了一个数组数据(用$i来控制它的大小)。然后对比对这个数组的处理用时,如果$i很小,假如为2,得到的结果如下:
使用msgpack处理后大小:609
使用json处理后大小:751
msgpack处理后大小与json处理后大小比为1:1.23
1000次msgpack操作用时:0.05400013923645
1000次json_encode操作用时:0.03600001335144 从上面的结果来看,msg_pack的效率根本不如json_encode的效率,只是msg_pack的压缩率大些而已。而当我把$i改大点,比如改到500后,结果就完全反转了:
使用msgpack处理后大小:152003
使用json处理后大小:187501
msgpack处理后大小与json处理后大小比为1:1.23
1000次msgpack操作用时:0.68599987030029
1000次json_encode操作用时:2.2000000476837     经过多次测试,最后做两个总结如下:    1,msg_pack的压缩效率比json_encode大是毫无疑问,但压缩比我这只看到提高了20%左右,可能和数据类型有关系,这个值只供参考。


    2,在数据量较小的情况下,msg_pack的效率不如json_encode.而在数据量较大时,msg_pack的效率就远大于json_encode。

    3,和数据序列化一样,对数据的反序列化上,也是数量量大时,msg_unpack的效率远大于json_decode.

    下面是进行反序列化时的结果:
1000次msgpack操作用时:0.80399990081787
1000次json_encode操作用时:2.6389999389648 查看全部
    MessagePack(简写msgpack)是一个高效的二进制序列化格式。它让你像JSON一样可以在各种语言之间交换数据。但是它比JSON更快、更小。小的整数会被编码成一个字节,短的字符串仅仅只需要比它的长度多一字节的大小。之前在lua脚本中使用过msgpack,因为有大量数据要入redis,而考虑到内存开销,使用了压缩比更大的msgpack。因为msgpack是一个二进制格式,所以没法像json后的字符串一样可直观地查看数据。
 
    msgpack的官网地址:http://pecl.php.net/package/msgpack 里面有各PHP版本windows下的dll扩展,也有源码包供linux下编译,所以像lua这样的脚本语言可以直接使用。msgpack和json_encode都是序列化存储数据,那么msgpack的效率与json的效率相比的话到底怎么样呢?看下面这个简单的对比程序:
//msgpack与json的性能对比
//1,数据拼凑
$data =array(
'youku' => '优酷视频', 'pptv' => 'PPTV', 'sohu' => '搜狐视频', 'qiyi' => '奇艺视频', 'letv' => '乐视视频',
'tencent' => '腾讯视频', 'sina' => '新浪视频', 'tudou' => '土豆视频', 'm1905' => '电影网', 'cntv' => 'CNTV',
);
$data = json_encode($data);
$newArr = array();
for($i = 1; $i<=500; $i++) //修改此处$i的最大值以控制数据的大小
{
$newArr [] =$data;
}

//数据大小对比
$msg_data = msgpack_pack($newArr);
echo "使用msgpack处理后大小:".strlen($msg_data);
$json_data = json_encode($newArr);
echo "<br>使用json处理后大小:".strlen($json_data);
echo "<br>msgpack处理后大小与json处理后大小比为1:".round((strlen($json_data)/strlen($msg_data)),2);

//计算1000次msgpack压缩用时
$time = microtime(true);
for($i = 1; $i<1000; $i++){
msgpack_pack($newArr);
}
echo '<br>1000次msgpack操作用时:'.(microtime(true)- $time);

//计算1000次json_encode压缩用时
$time1 = microtime(true);
for($i = 1; $i<1000; $i++){
json_encode($newArr);
}
echo '<br>1000次json_encode操作用时:'.(microtime(true)- $time1);
 程序过程没什么可说的了,就是先拼凑了一个数组数据(用$i来控制它的大小)。然后对比对这个数组的处理用时,如果$i很小,假如为2,得到的结果如下:
使用msgpack处理后大小:609
使用json处理后大小:751
msgpack处理后大小与json处理后大小比为1:1.23
1000次msgpack操作用时:0.05400013923645
1000次json_encode操作用时:0.03600001335144
 从上面的结果来看,msg_pack的效率根本不如json_encode的效率,只是msg_pack的压缩率大些而已。而当我把$i改大点,比如改到500后,结果就完全反转了:
使用msgpack处理后大小:152003
使用json处理后大小:187501
msgpack处理后大小与json处理后大小比为1:1.23
1000次msgpack操作用时:0.68599987030029
1000次json_encode操作用时:2.2000000476837
     经过多次测试,最后做两个总结如下:    1,msg_pack的压缩效率比json_encode大是毫无疑问,但压缩比我这只看到提高了20%左右,可能和数据类型有关系,这个值只供参考。


    2,在数据量较小的情况下,msg_pack的效率不如json_encode.而在数据量较大时,msg_pack的效率就远大于json_encode。

    3,和数据序列化一样,对数据的反序列化上,也是数量量大时,msg_unpack的效率远大于json_decode.

    下面是进行反序列化时的结果:
1000次msgpack操作用时:0.80399990081787
1000次json_encode操作用时:2.6389999389648

安全领域提到的payload是指什么?

回复

zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 3675 次浏览 • 2018-11-13 17:02 • 来自相关话题

经常会遇到导出数据的需求,那么导出的Excel和CSV格式有什么区别呢?

回复

zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 7856 次浏览 • 2018-10-09 14:33 • 来自相关话题

政府发布的白皮书是什么?

zkbhj 发表了文章 • 0 个评论 • 2652 次浏览 • 2018-09-25 19:28 • 来自相关话题

最近,我被一个老词汇所困扰,那就是在公司里常常见到的“白皮书”一词。与此对应的,我们还经常听到、看到“蓝皮书”、“红皮书”,还有“桔皮书”,等等,这些书都是什么意思,他们之间有区别吗?
和同事争论的时候,有的说白皮书就是产品介绍文档,有的说不是。那么在技术型公司里,白皮书究竟指的是什么呢?
为此,我到网上查找,中文的网页百度百科说:“白皮书”是政府或议会正式发表的以白色封面装帧的重要文件或报告书的别称。这多少让我有点失望,它并没有谈及商业上的白皮书。
后来又找到了维基百科,里面对白皮书是这样解释的,这多少让我找到了感觉。
一个白皮书(英文White paper或whitepaper)是一个权威性的报告或指南,常常阐述问题本身及其解决方法。白皮书被用来教育读者并帮助人们作出决定。常被用在政治、商业和技术领域。在商业领域,这个术语指的是作为市场或销售工具的商业文档。

政府白皮书

在英联邦国家,白皮书是议会文件的一种非正式名称,用来阐述政府政策;在英国,这些文件常被称为命令文件(Command Papers)。白皮书由政府发行,阐明在现时的问题上的政策,或建议采取的行动。尽管白皮书可能有时作为新法立法前的细节咨询,但是,透过白皮书,确实能看出政府有着清晰的意图:他们欲通过一部新法。
由欧洲委员会发表的白皮书,是欧盟在某一特定领域采取行动的建议文稿。他们有时紧随绿皮书发布其后,开展公众咨询过程。

这里有几个例子:
俄罗斯1号,关于俄罗斯布尔什维主义的报告汇编,1919年4月。这个报告汇编常被称作“白皮书”(The White Paper),是一本关于布尔什维克革命的电报信息的汇编,由英国在俄罗斯的官员撰写。丘吉尔白皮书,1922,计划为犹太人在巴勒斯坦设立一个国家1939年白皮书,呼吁建立统一的巴勒斯坦国,并限制犹太人移民和购买土地的能力。全民就业白皮书,1945。澳大利亚联邦承认让人民工作是国家的义务。国防白皮书,1964,导致创立并统一了现代化的加拿大军队。1966国防白皮书,取消了英国新航母和BAC TSR-2战术打击飞机。In Place of Strife, 1969 (后被弃)减少工会的权利。1969白皮书,1969(后被弃),在加拿大废弃“印第安人法”, 印第安人象加拿大其他少数民族一样被承认是这个国家的原住民,而不是特殊一族。白皮书,1966,美国国家研究理事会文件,导致在美国开发紧急医疗服务。
商业白皮书

自上世纪90年代早期,白皮书一词也用来指商业性的文件,作为市场宣传和销售的工具。这类白皮书阐明:某类技术或产品为解决特定领域问题带来的好处。
这类白皮书几乎总是用作市场沟通,目的是推销公司的解决方案和产品。作为市场宣传的工具,这些文件将突出对公司有利的信息。这样的白皮书常被用来发现销售线索、标榜领先地位、争取业务单子或纯粹是为了教育客户。

有三种主要的商业白皮书:
业务-利益:为某一特定的技术或方法争取业务定单。技术:描述一个技术是如何工作的。上面两者的混合:在一个文件里,将宏观的商业利益和微观的技术细节结合在一起。 查看全部
最近,我被一个老词汇所困扰,那就是在公司里常常见到的“白皮书”一词。与此对应的,我们还经常听到、看到“蓝皮书”、“红皮书”,还有“桔皮书”,等等,这些书都是什么意思,他们之间有区别吗?
和同事争论的时候,有的说白皮书就是产品介绍文档,有的说不是。那么在技术型公司里,白皮书究竟指的是什么呢?
为此,我到网上查找,中文的网页百度百科说:“白皮书”是政府或议会正式发表的以白色封面装帧的重要文件或报告书的别称。这多少让我有点失望,它并没有谈及商业上的白皮书。
后来又找到了维基百科,里面对白皮书是这样解释的,这多少让我找到了感觉。
一个白皮书(英文White paper或whitepaper)是一个权威性的报告或指南,常常阐述问题本身及其解决方法。白皮书被用来教育读者并帮助人们作出决定。常被用在政治、商业和技术领域。在商业领域,这个术语指的是作为市场或销售工具的商业文档。

政府白皮书

在英联邦国家,白皮书是议会文件的一种非正式名称,用来阐述政府政策;在英国,这些文件常被称为命令文件(Command Papers)。白皮书由政府发行,阐明在现时的问题上的政策,或建议采取的行动。尽管白皮书可能有时作为新法立法前的细节咨询,但是,透过白皮书,确实能看出政府有着清晰的意图:他们欲通过一部新法。
由欧洲委员会发表的白皮书,是欧盟在某一特定领域采取行动的建议文稿。他们有时紧随绿皮书发布其后,开展公众咨询过程。

这里有几个例子:
  • 俄罗斯1号,关于俄罗斯布尔什维主义的报告汇编,1919年4月。这个报告汇编常被称作“白皮书”(The White Paper),是一本关于布尔什维克革命的电报信息的汇编,由英国在俄罗斯的官员撰写。
  • 丘吉尔白皮书,1922,计划为犹太人在巴勒斯坦设立一个国家
  • 1939年白皮书,呼吁建立统一的巴勒斯坦国,并限制犹太人移民和购买土地的能力。
  • 全民就业白皮书,1945。澳大利亚联邦承认让人民工作是国家的义务。
  • 国防白皮书,1964,导致创立并统一了现代化的加拿大军队。
  • 1966国防白皮书,取消了英国新航母和BAC TSR-2战术打击飞机。
  • In Place of Strife, 1969 (后被弃)减少工会的权利。
  • 1969白皮书,1969(后被弃),在加拿大废弃“印第安人法”, 印第安人象加拿大其他少数民族一样被承认是这个国家的原住民,而不是特殊一族。
  • 白皮书,1966,美国国家研究理事会文件,导致在美国开发紧急医疗服务。

商业白皮书

自上世纪90年代早期,白皮书一词也用来指商业性的文件,作为市场宣传和销售的工具。这类白皮书阐明:某类技术或产品为解决特定领域问题带来的好处。
这类白皮书几乎总是用作市场沟通,目的是推销公司的解决方案和产品。作为市场宣传的工具,这些文件将突出对公司有利的信息。这样的白皮书常被用来发现销售线索、标榜领先地位、争取业务单子或纯粹是为了教育客户。

有三种主要的商业白皮书:
  • 业务-利益:为某一特定的技术或方法争取业务定单。
  • 技术:描述一个技术是如何工作的。
  • 上面两者的混合:在一个文件里,将宏观的商业利益和微观的技术细节结合在一起。

什么是双因子认证?双因子认证的好处是什么?

zkbhj 发表了文章 • 1 个评论 • 6458 次浏览 • 2018-09-19 15:08 • 来自相关话题

双因子认证(2FA)是指结合密码以及实物(信用卡、SMS手机、令牌或指纹等生物标志)两种条件对用户的身份进行认证的方法。这种方法已经得到了企业的广泛采用,特别是在对数据进行远程访问时,但在其它领域应用还十分有限。双因子身份认证的推广之所以受阻,主要是由于其需要使用额外的工具,而这一条件为IT和技术支持人员带来了不小的负担。其批评者还指出,这种安全保障措施仍然很容易遭受攻击,即在非常小的时间周期内,这种技术很容易受到中间人(man-in-the-middle)攻击(这也是采用严格SSL处理的主要原因)。实际上,除了这些障碍以外,现在我们已经开始认识到,不采用双因子认证所带来的隐含成本远远比采用双因子认证所需要的成本高得多。






双因子身份认证是确保远程访问安全性的最佳实践方式,但是这种技术也给了一些网络犯罪分子可乘之机。如果攻击者在获取到了大量身份凭证的情况下,他们就可以伪装成合法用户,而且还可以躲避安全防护软件的检测。很多公司都认为双因子认证机制是绝对可靠的,而且也没有采取一定的安全预防措施来防御攻击者的攻击以及系统后门。

在这篇文章中,我们将会站在攻击者的角度来对双因子身份验证机制进行从浅至深的分析,我们希望这篇文章能够帮助安全研究人员解决这项技术中目前所存在的一些问题。我将会对远程绕过双因子身份验证技术进行讨论,并且向大家描述如何绕过远程访问设备的双因子身份验证机制,并从内部网络环境的设备中窃取数据。

1)K.I.S.S-简单,有效

入侵设备的远程访问控制是攻击者首要解决的问题,因为它可以给攻击者提供设备的访问权限,并且降低被监测到的可能性。在合法远程访问工具的帮助下,攻击者不仅可以在目标主机中执行控制命令,而且还可以在身份验证机制的掩护下进行其他的一些攻击活动。

在某些较为困难的情况下,我们可以使用一些比较直接的方法来获取到我们所需的凭证:让目标用户代替我们来进行操作。我们只需进行一些简单的设置就可以制作一个完美的陷阱。

在下图中,我们可以看到两个不同的VPN登录页面。其中一个是公司的合法登录网站,另一个是由攻击者伪造的虚假登录页面。你能发现这两者之间的区别吗?





 
分辨不出吗?没错,你的客户也一样分辨不出。在社会工程学工具(SET)的帮助下,任何人都可以快速地复制出一个外部页面来欺骗用户(攻击者只需要将HTML页面中的本地资源地址(“/home/image/logo.png”)修改成外部引用地址(“mycompany.com/home/image/logo.png”)就可以了)。在一次完美的网络钓鱼攻击中,你可以引诱目标用户访问你所克隆出的虚假VPN身份验证页面,并且得到所有你需要的信息:用户名,密码,甚至是令牌码!

如果攻击者的操作速度足够快,那么他们还可以将凭证提交至虚假的VPN页面,然后利用这些信息来登录真实的VPN。如下图所示,攻击者可以将登录提交请求重定向至一个PHP脚本,然后这个脚本就会将提交过来的用户名,密码,以及其他的一些元数据写入服务器的日志文件中,这样攻击者就可以检测并获取到用户所提交的双因子身份验证信息了。




当攻击者通过了VPN的身份验证之后,他们就可以在安全检测软件检测到钓鱼攻击并进行安全响应之前,在目标主机中实现提权并获取到敏感数据。

2)电子邮件就是我们的敌人

数字令牌通常会需要一个同步代码,而为了保证其有效性,每一名用户的令牌都只会有一个唯一的同步码与之对应。同步码和算法是保证令牌安全性的因素,而且这两个因素也可以确保用户令牌能够与身份验证服务器的要求所匹配。当用户的VPN访问请求通过批准之后,很多公司会选择使用一种简单和友好的方式来向用户发送通知类的电子邮件。这些电子邮件中通常会包含有“seed“密钥和安装说明。但对于安全团队来说不幸的是,用户通常在阅读完这类电子邮件之后,却忘记将其删除了,这些电子邮件就这样躺在了用户的收件箱之中,等待着攻击者前来窃取。

攻击者可以在用户的电子邮箱中搜索敏感文件和有价值的信息(包括硬盘中的.PST和.OST文件)。在大多数情况下,攻击者只需要使用一个简单的PowerShell脚本就可以搜索用户邮箱中的敏感文件以及与RSA软令牌相关的.sdtid文件了。

3)双因子身份验证机制中的紧急模式

在很多的双因子身份验证产品中,都提供有一个名为“紧急访问”的代码,这种运行模式实际上是一种身份验证机制,如果用户丢失了令牌,但是又急需对数据进行远程访问,那么这种机制也可以允许用户进行临时性的VPN访问。下图显示的就是紧急访问模式的操作界面截图:




如上图所示,系统提供了一个身份验证的修复机制。对于攻击者而言,攻击者可以利用这种机制来远程访问目标系统。这些紧急访问码是非常不安全的,因为他们的有效日期可以被修改,这样一来,攻击者就可以利用这些紧急访问码来获取到目标系统的永久访问权限了。

总结

对于一名经验丰富的攻击者来说,他们有很多种方法可以对目标进行攻击,并绕过那些所谓的“安全防护措施“。

不幸的是,很多公司太过于相信那些所谓的安全解决方案了,例如双因子身份验证。如果安全技术人员没有采取一些必要的安全保障措施,那么这种安全技术也不能保证公司的安全。如果安全技术人员忽略了这一点,那么攻击者就可以利用如上文所述的一些攻击方法破坏双因子身份验证技术本该带来的安全性。

在此,我还需要感谢Andrew Burkhardt, Evan Peña, 以及Justin Prosco为这篇文章所做出的贡献。
 
文章原文:https://www.fireeye.com/blog/t ... .html 查看全部
双因子认证(2FA)是指结合密码以及实物(信用卡、SMS手机、令牌或指纹等生物标志)两种条件对用户的身份进行认证的方法。这种方法已经得到了企业的广泛采用,特别是在对数据进行远程访问时,但在其它领域应用还十分有限。双因子身份认证的推广之所以受阻,主要是由于其需要使用额外的工具,而这一条件为IT和技术支持人员带来了不小的负担。其批评者还指出,这种安全保障措施仍然很容易遭受攻击,即在非常小的时间周期内,这种技术很容易受到中间人(man-in-the-middle)攻击(这也是采用严格SSL处理的主要原因)。实际上,除了这些障碍以外,现在我们已经开始认识到,不采用双因子认证所带来的隐含成本远远比采用双因子认证所需要的成本高得多。

t01fc4acdc6ee66ec6e.jpg


双因子身份认证是确保远程访问安全性的最佳实践方式,但是这种技术也给了一些网络犯罪分子可乘之机。如果攻击者在获取到了大量身份凭证的情况下,他们就可以伪装成合法用户,而且还可以躲避安全防护软件的检测。很多公司都认为双因子认证机制是绝对可靠的,而且也没有采取一定的安全预防措施来防御攻击者的攻击以及系统后门。

在这篇文章中,我们将会站在攻击者的角度来对双因子身份验证机制进行从浅至深的分析,我们希望这篇文章能够帮助安全研究人员解决这项技术中目前所存在的一些问题。我将会对远程绕过双因子身份验证技术进行讨论,并且向大家描述如何绕过远程访问设备的双因子身份验证机制,并从内部网络环境的设备中窃取数据。

1)K.I.S.S-简单,有效

入侵设备的远程访问控制是攻击者首要解决的问题,因为它可以给攻击者提供设备的访问权限,并且降低被监测到的可能性。在合法远程访问工具的帮助下,攻击者不仅可以在目标主机中执行控制命令,而且还可以在身份验证机制的掩护下进行其他的一些攻击活动。

在某些较为困难的情况下,我们可以使用一些比较直接的方法来获取到我们所需的凭证:让目标用户代替我们来进行操作。我们只需进行一些简单的设置就可以制作一个完美的陷阱。

在下图中,我们可以看到两个不同的VPN登录页面。其中一个是公司的合法登录网站,另一个是由攻击者伪造的虚假登录页面。你能发现这两者之间的区别吗?

t01775f75e07e0a35a7.png

 
分辨不出吗?没错,你的客户也一样分辨不出。在社会工程学工具(SET)的帮助下,任何人都可以快速地复制出一个外部页面来欺骗用户(攻击者只需要将HTML页面中的本地资源地址(“/home/image/logo.png”)修改成外部引用地址(“mycompany.com/home/image/logo.png”)就可以了)。在一次完美的网络钓鱼攻击中,你可以引诱目标用户访问你所克隆出的虚假VPN身份验证页面,并且得到所有你需要的信息:用户名,密码,甚至是令牌码!

如果攻击者的操作速度足够快,那么他们还可以将凭证提交至虚假的VPN页面,然后利用这些信息来登录真实的VPN。如下图所示,攻击者可以将登录提交请求重定向至一个PHP脚本,然后这个脚本就会将提交过来的用户名,密码,以及其他的一些元数据写入服务器的日志文件中,这样攻击者就可以检测并获取到用户所提交的双因子身份验证信息了。
fig2.png

当攻击者通过了VPN的身份验证之后,他们就可以在安全检测软件检测到钓鱼攻击并进行安全响应之前,在目标主机中实现提权并获取到敏感数据。

2)电子邮件就是我们的敌人

数字令牌通常会需要一个同步代码,而为了保证其有效性,每一名用户的令牌都只会有一个唯一的同步码与之对应。同步码和算法是保证令牌安全性的因素,而且这两个因素也可以确保用户令牌能够与身份验证服务器的要求所匹配。当用户的VPN访问请求通过批准之后,很多公司会选择使用一种简单和友好的方式来向用户发送通知类的电子邮件。这些电子邮件中通常会包含有“seed“密钥和安装说明。但对于安全团队来说不幸的是,用户通常在阅读完这类电子邮件之后,却忘记将其删除了,这些电子邮件就这样躺在了用户的收件箱之中,等待着攻击者前来窃取。

攻击者可以在用户的电子邮箱中搜索敏感文件和有价值的信息(包括硬盘中的.PST和.OST文件)。在大多数情况下,攻击者只需要使用一个简单的PowerShell脚本就可以搜索用户邮箱中的敏感文件以及与RSA软令牌相关的.sdtid文件了。

3)双因子身份验证机制中的紧急模式

在很多的双因子身份验证产品中,都提供有一个名为“紧急访问”的代码,这种运行模式实际上是一种身份验证机制,如果用户丢失了令牌,但是又急需对数据进行远程访问,那么这种机制也可以允许用户进行临时性的VPN访问。下图显示的就是紧急访问模式的操作界面截图:
fig9.png

如上图所示,系统提供了一个身份验证的修复机制。对于攻击者而言,攻击者可以利用这种机制来远程访问目标系统。这些紧急访问码是非常不安全的,因为他们的有效日期可以被修改,这样一来,攻击者就可以利用这些紧急访问码来获取到目标系统的永久访问权限了。

总结

对于一名经验丰富的攻击者来说,他们有很多种方法可以对目标进行攻击,并绕过那些所谓的“安全防护措施“。

不幸的是,很多公司太过于相信那些所谓的安全解决方案了,例如双因子身份验证。如果安全技术人员没有采取一些必要的安全保障措施,那么这种安全技术也不能保证公司的安全。如果安全技术人员忽略了这一点,那么攻击者就可以利用如上文所述的一些攻击方法破坏双因子身份验证技术本该带来的安全性。

在此,我还需要感谢Andrew Burkhardt, Evan Peña, 以及Justin Prosco为这篇文章所做出的贡献。
 
文章原文:https://www.fireeye.com/blog/t ... .html

“银弹”指的是什么意思?

回复

zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 3959 次浏览 • 2018-09-09 20:49 • 来自相关话题

相似文档查找算法之 simHash

zkbhj 发表了文章 • 0 个评论 • 1725 次浏览 • 2018-09-05 14:50 • 来自相关话题

什么是SSRF攻击?

回复

zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 3168 次浏览 • 2018-08-08 15:14 • 来自相关话题