最好的样子 | 女性

知乎上有这样一个帖子:女性最好的样子应该是什么样的?吸引了很多人来贡献答案,众多的答案中有一个让我印象特别深刻:

我不年轻了,但是仍然觉得自己在最好的样子。生活是一场马拉松,跑到后面还不泄气才是真赢家。

对于这个问题,不同的人可能会有不同的答案,我自己也有深深的体会。

01 从运营管理到一线业务,开启最好的状态

18年初,我离开了中国区的管理团队,到业务的一线做了一名项目经理。

在管理团队的 6 年里,我做过人力资源管理,组建了资源协调团队,带领过内部IT项目团队,还做过全球能力变革项目的发起者和项目带头人,按照这个道路走下去,我的职业发展可能会和组织管理或者全球的某块业务相关。

但是我突然回到了一个很小的项目团队,这个决定让很多人不解,仿佛看到了一个长跑的人,已经跑出了很远,突然折返回来,回到了 6 年前的那个起点。

别人不解的背后其实是我思索很久的决定,在管理团队的最后两年里,尤其是休完产假回来后,有时候感觉自己迷茫找不到方向,有时候做起事来力不从心,尝试过一些调整后,仍然找不到持续的热情。

可能又到了做出重大改变的时候了。

如此重大的改变,最常规的做法是换个环境,换家公司,开启全新的职业发展阶段,但 6 年前的经验告诉我,既然能从一名测试工程师做人力资源总监,也可以从运营管理转做一线业务,这是一家支持变化的公司,所以我不需要换环境,所有的经验和技能都能在组织内部迁移。

和6年前不一样的是,这次我是主动出击,去找一些人聊我的想法,听取他们的建议,这也是我在这家公司待了10年多最深刻的一个收获,我们要对自己的需求负责,然后积极寻求别人的建议,和6 年前一样的是,我从别人那里得到了很多诚恳的建议和支持。

很多时候,想法有了,但离行动还会差一段距离,那距离便是决心和勇气。

年初的时候,中国区的管理团队决定做一次调整,根据新的业务形态重新规划团队结构,同时也吸纳一些新鲜血液,按照常规,有人加入,就要有人离开,听上去是一个带点伤感的决议,但在心里,我竟然有些期待。

因为这个决议能帮我鼓起勇气迈出这一步。

但我的内心是不安的,在管理团队待的 6 年多的时间里,业务领域的方法和技术迭代了好几次,业务和客户的复杂度也高了很多,我当时的担忧多于兴奋。

《少有人走的路》里面有这样一句话:“勇气是,尽管你感觉害怕,但仍能迎难而上;尽管你感觉痛苦,但仍能直接面对。”

那个时候,除了往前走,我没有给自己留任何退路。

后来,在四个月的时间里,我服务过三个客户,每个客户的挑战都不一样,项目上遇到的难题,合作的同事,解决问题的方法也都不一样;四个多月的时间,我没有过一个完整的周末,瘦了很多,体重比生孩子之前还要轻(也很欣喜);四个多月的时间,我产出了38篇文章,相当于一个周两篇,大多来自于项目和工作的感悟。

有一次和同事聊天,那个时候第一个项目刚结束,我们有相同的感慨,想想项目不过持续了两个月,但回想项目开始的那天,仿佛那是很久以前的事情。

因为两个月的时间里,我们经历了太多的事情,我们学到了很多的东西,每个人也都不是项目开始时的自己了。

现在想来,自己也很庆幸当初做的那个决定,尽管一线的工作很辛苦,但我的状态很好,也充满兴奋。

02 面对现实,接受自己的力所不能及

一线的很多项目在客户现场,这也就注定了出差是常态。

有一次晚上加完班十点多,在回酒店的出租车上,有位同事分享自己的感慨:女性在职场,要想拼,一定要在生孩子之前完成,否则会有太多的牵挂和力不从心。

她是一位刚休完产假回归职场的母亲,和我们所有人一样加班、熬夜、出差。

对她的感慨,我深有体会。

第一个项目出差前,我做了一些安排,把家里的小朋友送回到了老家,项目中期赶上五一假期,所以回老家把他接回北京。

我一直记得分别一个多月后他见到我的样子,眼睛里带着点惊恐,也闪烁着兴奋,他奔向我,既想亲近又掩饰不住陌生。

把他带回北京后,我很快又出差了,因为晚上经常加班,所以几天才视频一次,先生告诉我,每次听见楼道里有响声,或者快递员敲门,他总是欢快地喊着“妈妈”去开门,但每次都是失望而归。

每当脑海中想起他失望的样子,心里就泛起一阵阵心酸。

人生到了这个阶段,我们有太多的责任和承诺,对工作,对家庭,甚至对社会,我们一边希望自己可以做尽可能多的事情,一边往往会为做不到事事尽善尽美而自责,愧疚,甚至灰心。

曾经和一位来自全球知名咨询公司的客户聊起女性在职场的发展,她说她所在的公司,非常重视也支持女性在职场的发展,但是一旦当了母亲,大部分女性仍然会选择离开,哪怕再喜欢那份工作,也不得不放弃,因为无法平衡的工作和家庭。

在这个男女平等还没有完全到来的社会,在职场,面对同样的工作,同样的职位,很多女性需要比男性付出更多的努力去证明自己的能力,需要表现出更多比男性对工作的重视,来证明自己不会被家庭所拖累。

我很欣赏这样的女性,也深知她们在追求事业成功的背后必然做出了很多迫不得已的决定。

看过这样一句话:知道自己力量的界限,这本身就是一种能力,要用一生去探索。

对我来讲,错过了小朋友成长的一些瞬间,也没有办法时刻陪伴着他,但我选择做一个和他一起成长的母亲,他学习走路,学习说话,慢慢长大,我学会面对现实,尽力而为的同时,接受自己的力所不能及。

03 之所以努力,是不想让自己那么快的老去

9月份,我会再次回到学校,去读MBA学位,这意味在接下来的两年,平时忙工作,周末忙学业,那将会是很大的挑战。

我有这个想法其实已有很多年,但是一直没有去行动,有时觉得是太忙,抽不出时间准备,有时又在思考即使学业有成,会有什么价值,在日复一日的犹豫里,我错过了最好的年纪。

记得几年前和一位职场前辈聊天,具体聊什么已经记不清了,隐约还在脑海留下一些词,事业追求、人生梦想,财富自由,中年危机。

那个时候还完全不知道这些词是什么意思,也觉得离他描述的那种场景很遥远。

转眼间,似乎自己就到了那个尴尬的年纪,对家庭有承诺,对工作有责任,自我成长越来越奢侈也渐渐成为前行的瓶颈。

有时候会在夜里突然醒来,感觉自己还有好多东西不懂,好多事情未做,惊出一身冷汗。

真的有种感觉,年龄越长,自己越无知,经历的越多,想学的也就越多。

还记得MBA面试的时候,主面试官问了我这样一个问题:对很多女性来说,有了孩子之后,兼顾工作与家庭已经非常困难,你已经不具备年龄优势,为什么在这个时候还选择来上学?

是一个很好的问题,他问出了很多女性在这个时期的无奈,可能每个人都有自己的原因。

我看着两鬓斑白的主面试官,他眼神凌厉,应该拿着这个问题问过很多和我经历相似的人,在他那云淡风轻的表情下已经有无数个答案了吧。

我说:以前我觉得一个人老去的标志是老成持重,沉稳避世,现在觉得是不敢让自己置身不熟悉的境地,放弃了学习,我只是不想让自己那么快的老去。

面试通过后,又顺利通过了笔试,等我真正接触到我的那批准同学,才发现,和我经历相似的女性不在少数。

我为能结识她们加入她们而欣喜。

前几天有同学在群里提问:我们这么努力,是为了什么?

很多同学出来分享自己的想法,有位同学说,人生一切努力的价值,就是为了成为美好的一部分。

颇有感触,我们之所以不停努力,或许就是为了发现美好,并且不遗余力的让自己成为这个世界美好的一部分。


最近在看吴军的《见识》,里面提到牛津大学圣埃德蒙(13世纪的坎特伯雷大主教)的一句话:“ Study as if you were to live forever, live as if you were to die tomorrow”,翻译成中文也许是“终身学习,向死而生”。

作为女性,如何保持最好的样子,这算是另外一种诠释了。


更多精彩洞见,请关注微信公众号:思特沃克

Share

当我们做区块链时,我们在做什么?

长话短说,我们在建链。

区块链是什么

关于区块链是什么,网络上的解释多如牛毛。这里,我从通常需求的角度总结一下:在记录保存(身份存证)时,它是分布式账本(分布式数据库);在交易或支付(跨境支付)时,它是信任机器。虽然这两种分类方法并不正交,但是对于理解区块链的应用领域有很大的好处。

不论是分布式账本,还是信任机器,其底层的特性——不可篡改、透明、可追溯以及去中心化,最终导向的目的都只有一个,那就是信任。

区块链的可信度来自于人类对数学逻辑严密性的信任,数学理论和加密学实践可以确保链上数据和所有权的可靠程度。区块的确认基于共识算法、不可变的数据结构,再通过 Merkle Tree、Hash Pointer(哈希指针) 保证前向区块链的完整性,再加上经济、人心的博弈、理性经济人假设,共同构成一套完整的信任系统。

然而,企业间的联盟区块链有一些不同,它的信任更多地依赖于发起者品牌的背书。在这样的大环境下,联盟链的设计就变得相当灵活,比如最先腰斩的就是代币。

区块链的行业应用

在工信部最新发表的《2018 年中国区块链产业白皮书》中,区块链产业生态分成了产业应用(包含金融和实体领域),基础设施和平台(如公有链和BaaS),行业服务(如媒体)。而我们的关注点集中在产业应用当中。

金融领域由于本身数字化程度比较高,在证券化以及ABS交易所等方向都有落地案例。在实体产业当中,供应链溯源,身份存证等也多有应用。再加上区块链本身具有“信任穿透”的神奇功效,对于构建供应链金融征信体系,改善小微企业的融资困境也很有帮助。

总体来说,几乎各种产业场景都能应用区块链技术,因为这些场景里都有提升效率,降低成本,优化征信体系的诉求。

汽车金融区块链应用

汽车金融

汽车金融中的核心资产是汽车。汽车金融始终围绕车的生命周期发生金融活动。从零配件的生产,到主机厂制造整车,然后通过各个区域的销售公司将整车卖给各区域内的经销商。实际上在中国,经销商还可以分为不同层级的二三级经销商,最后才到顾客手中。而一旦新车完成销售,就迈入了后市场的广阔天地,以及二手车、三手车的再销售。

从汽车零配件的生产运输和组装到车卖给经销商,这些环节所涉及到的金融活动叫做供应链金融,而顾客通过金融活动来买车,不管是新车还是二手车,都属于消费金融的范畴。

汽车的生命周期和金融公司的参与环节:

它们的业务模式长这样:

通过分析现有业内的业务模式,我们发现:

财务对账成本高昂,且效率不高。这里的财务成本并非某家公司的财务成本,而是整个系统内的财务总成本。仅在中国区可能就有多家销售公司和金融公司,以及几百家经销商,即使每家公司只有两名财务和审计人员,那么财务审计人员都超过一千,更别提全球销售范围内了。

传统的对账方式是怎样的呢?

不同类型的机构进行在对账时,往往要从信息系统中导出电子表格,并用邮件发送。甚至需要打印表格、盖章后邮寄,对方收到后再与系统数据进行比对。

整个业务流程并不复杂,但是消耗了很多人力物力,且中心化的服务还由于对授权机制(多主体之间不太信任或者叫做弱信任)和信息安全等方面的考虑,而导致建设成本高昂,且制约了业务运行效率和用户体验的提升。区块链作为分布式账本,意味着任何机构之间互相发生债务往来的信息都是数据一致的,那么就可以近实时地进行对账。

而我们区块链要做的事情,一言以蔽之,汽车资产上链以及围绕汽车所发生的金融活动而产生的债务的记录。所以不难发现,分布式账本和信任机器在这个场景下都有涉及。

怎么建链

我们把这次建链过程大体总结为5个步骤:识别上链数据,智能合约设计,API设计,部署单元和网络拓扑架构。

  • 识别上链数据指的是识别将哪些交易记在链上;
  • 智能合约设计,指的是买卖车及其相关金融活动如何通过可编程的方式自动完成;
  • API设计,考虑如何对外暴露平台能力,同时限制控制主体;
  • 部署单元和网络部署架构属于实施范围,旨在解答分布式账本如何真正运行在企业当中。

整体技术架构是基于Corda这个分布式账本技术展开的,Corda准确来说不是区块链,而是一种受区块链启发的DLT,即分布式账本技术,它是由金融区块链联盟R3开发和维护的。

上链数据识别

要分析清楚的问题是车在什么时候转移,车在什么参与方之间转移,车在转移的过程中伴随了什么数据的变化。在分析这块业务的时候,我们通过事件风暴,分析了在各个法律参与实体之间发生车转移的业务事件,然后进行了事件排序,通过事件析出数据,包括交易参与方,车的详细信息,车的所有权和占有权以及债等等。这部分数据有一定的取舍,比如订单就不在我们的核心资产当中,所以不上链。

我们开始进行数据建模,在此之前,有必要介绍一下Corda的编程模型——State,因为它会直接影响我们后续的模型设计。Corda中核心概念之一就是State,State是分布式账本上的事实,它代表了交易参与方达成共识的结果。以IOU这个欠条为例,State其实就是欠条关键属性的集合,包含借款方,欠款方,金钱数量,还款截止日期。当欠款部分归还时,这个欠条的内容就会发生变化,变化的方式就是将老的欠条标记成历史的,进而生成包含新内容的欠条。

在我们应用场景中,核心的State就是车和债,因为Corda是运行在JVM上,开发首选语言是Kotlin,所以这里我们直接拿Kotlin中data class对车和债进行建模,而且统一继承了Corda内置的LinearState,LinearState拥有全局唯一ID,在数据演化的过程中不会发生改变。如果有人了解DDD相关概念的话,应该能自动映射到实体概念上。除此之外,Corda中还有一个核心State叫做Fungiable Asset,可以类比成值对象,例如:Cash。

State建模完成之后该怎么演化呢?这就不得不提一个UTXO的概念,UTXO全称 unspent transaction ouput,最开始是比特币网络引入的,它有很多好处,比如可以追溯到每一笔输出的源头,帮助验证是否存在双花现象,Corda一样继承了类似的好处。销售公司把车批发给经销商时,就会将所有权归属自己的车作为交易的输入,产生输出,输出中包含了所有权的变更以及债务的生成。而作为输入的车就会被标记成历史的。这笔交易本身也必须获取到交易双方的签名才能成立。

智能合约设计

上面我们聊到的都是链上的数据以及数据演化过程,不过这些过程都不是自动执行的。对于复杂的金融合约,往往会涉及到多种state的变化,这个时候就必须使用自动化的流程封装这些变化,封装这些变化的东西其实就是智能合约。还是以经销商批发车为例,一个可能的合约模板就是规定车转移的同时产生一笔债,以及对应的还款截止日期。这个合约强制state改变时,交易双方必须参与签名。

在进入智能合约实现之前,需要先了解一下Corda中flow和contract的概念。Flow是Corda中控制参与节点如何更新State的自动化流程,它对如何获取交易对手方的签名进行了封装。一个标准的flow流程包括获取链上数据,创建一笔交易,自签名之后发送到对手方进行交易验证,再签名,最终在双方的账本上分别提交事务。而Contract则是在交易验证环节提供验证所用的脚本。

在我们的应用场景中,智能合约长成这样,在flow中,先从链上取出原有车的数据,拷贝得到一个新的所有权发生转移的车以及对应一笔债;然后通过 txBuilder构建一笔交易,交易的输入是原车,而输出即是新车和债;最后就是验证和签名以及事务提交的过程。你可能已经注意到txBuilder中有个firstNotary的参数,这里提一下notary的概念,notary在corda中是一类特殊的节点,专门用于防止资产双花的问题。所以理论上,每笔交易都需要notary节点参与,并对交易进行签名。在交易验证环节中,我们定义的contract会被执行,这个contract非常简单,简单到只有一个叫做verify的纯函数。它的作用就是断言每一个state的更新是否符合要求。这种设计非常符合Trust But Verify的理念。

API设计

有了智能合约之后,我们就得考虑如何暴露平台的合约能力了。换句话说,从消费者的角度,我们该怎么利用平台提供的能力完成自己的业务。所以这里我们利用了REST API设计的思路,抽象出平台的能力作为资源呈现,定义以车为中心的URI,然后选择合适的HTTP动词,得出 REST api。

从数据上链识别,到智能合约设计,再到API设计,我们在不同层次利用Corda这个分布式账本技术。最底层的分布式账本记录每笔交易发生的事实,不可篡改可追溯;中间的智能合约层提供了合约抽象,甚至可以和现实中的合约一一对应;最上层的REST api以资源的方式呈现了平台的金融活动能力。

部署单元

这样一个汽车金融平台是怎么跑起来的呢?借助Docker,我们把一个物理部署单元打包成了一个镜像,底层是一个全功能的Corda节点,所有的智能合约和state都以jar包的方式部署在这个节点上;同时利用SpringBoot通过RPC的方式连接到Corda节点,调用智能合约,对外暴露REST api;而Corda节点之间则通过消息的方式互相通信。

网络拓扑

打包成docker镜像之后,就可以部署到运行环境中,形成一个分布式账本的P2P网络。这里有2个节点需要留意,最左边的 permission service 是用于对每个入网节点进行证书签发,给予每个参与实体一个身份。中间的Network map类似于微服务中的 service discovery,Corda中节点的互相发现并不是通过广播的方式发生,而是通过注册Network map获取其它节点的信息,进而找到对方。

回顾

最后,我们回顾一下上面的三层架构,用价值的视角重新评估一下整个平台。传统的平台,通过api的方式暴露服务从而获得价值输入,但是区块链平台的核心资产其实在最底层的账本中。基于这些交易事实和债务或者支付记录,我们可以很方便清算各个法律实体的数字资产,计算实时的债务信息,进行车辆的价值溯源,而且未来结合大数据分析和AI,更有可能打造出一个完整的供应链生态。


推荐阅读


更多精彩洞见,请关注微信公众号思特沃克

Share

复用的着相

着相是佛家用语,指的是执着于外相偏离了本质。

仙剑奇侠传中有一个故事。讲的是一个成精了的佛珠。想要让更多的人向佛,于是施法,让这些人失去了记忆,只想一心礼佛。使人向佛,本来是好事,但强人所难,脱离了本质,便是着了相,也可以说反而是入了魔。

这个小故事告诉我们,在认知的世界里,我们很容易被表象所欺骗,忽略了本质。为此,佛家发明了这么一个名词来专门指出这种现象。

复用也是一样。复用本来是通过消除重复的方式。得到一系列可以复用的组件。从而在未来的开发工作中,更快速的响应需求变化,也就是所谓的提升响应力。

然而很多复用的结果,会造成代码是变少了,改起来却更难了。复用是增加了,可读性却下降了。考虑到软件开发是一个团队协作的工作,而我们这个行业的离职率又能到百分之二十之多。难以学习的代码确实是难以维护的,尽管你可以抱怨接手的人无能,但总之是降低了响应力,也就违背了复用的本质。

什么情况下会出现这样的场景呢?主要是因为视角的单一,只从自己单一的视角看到了重复而不是在做全局优化。这个说法可能稍微有些抽象,那我说几个相对具体的情况。

当我们只关注功能视角的时候

需求有很多的描述视角,可以只在功能角度描述,比如“网站要有任务卡,任务卡上有文字版学习内容,视频讲解、也有作业题。”也可以加入业务视角,比如“学生要报名特训营,才能参加特训营。学生进入特训营后,就看到了任务卡列表。学生在任务卡上阅读学习资料,阅读完学习资料后做题来验证他是否学到,做完后提交交由助教审阅。”当我们只看功能视角的时候,可能会忽视业务上的不同,变的在功能角度过分抽象,最后当业务变化的时候,反而响应速度比较弱。

一个简单的后台,我们看起来所有东西长得都一样,不过是列表页面,添加页面修改页面,再加点儿删除什么的功能。说穿了都是crud,干脆我把这事弄成一一个组件好了,每个页面只需要简单配置一下,就可以出来自己的一套增删改查页面。

这种视角完全没有考虑到,不同的实体,它们其实所在的业务是不一样的,关心它们的人也是不一样的。最后,彼此的演化方向也总会出现一些不同,你把它定义成一种东西,对于我每做一个修改,都要背负着其他所有实体的特异性。于是就逐渐拖慢了我改变的速度,降低了响应能力。

无谓的自动化

有追求的程序员一定会考虑提升工作效率,通过一些自动化的手段来缩短流程,提高效率。不过有时候,这种追求也会有害。

在我们的系统里有一个面包屑功能,就是典型的“页面A / 页面B / 页面C”那种面包屑。团队成员提出,一个个页面写面包屑好烦啊,干脆做一个根据URL生成面包屑的功能吧。乍一看好像提高了效率,但实际上URL上的名词和你想显示在面包屑上的名字是可能出现不同的。

比如在我们的场景里,我们提供一个任务卡的预览功能,你的面包屑可能是“xx后台 / xx 训练营管理界面 / xx卡预览”,而学生正式使用任务卡的时候,他可能是 “ 学习中心 / xx 训练营 / xx卡 ”。而他们的url里可能都会出现’/programs/$pid/tasks/$tid’。同样的program、task翻译出来的文字完全不同。你为了支持这点不同,又要扩展一些额外功能来做这种区分,做来做去,可能还不如直接写来的方便,至多抽几个常量来简单的消除一下重复。

当我们只从代码上看重复性的时候

这个我就不举例子了,其实很多犯这个错误的人都是重构的支持者,不过学艺不太精。因为如果你仔细看的话,重构里好多怀味道都有一个跟他对立的怀味道,比如发散式变化和霰弹式修改。如果我们只看代码就会违背复用的本质——更好的响应变化。

这个跟我说的第一个场景,只关注功能视角是类似的问题,这个可能更具象一点,只关注代码。

无视上下文的时候

这个可以看作是只有功能视角的一种情况,很多功能我们觉得有重复性,提升成一个概念,然而其实根本是两个东西,他们只是刚好叫一个名字。

比如过去很多软件里,是有一个统一的用户组概念,不管你在哪个业务上下文里,你都需要扩展这个用户组的概念来管理用户的权限。这个带来的结果就是用户组变得越来越臃肿,每次修改都要改一下别的组的功能。在我们的网校数字平台里,学生学习有学习小组,老师出题有出题小组,这两个小组业务完全不一样,这个时候如果都用统一的用户组来管理的话,那就势必会造成无谓的耦合,损害响应力。

这些故事告诉我们,我们不是在真空里去做复用。我们做的软件都是有它的商业目的。我们的工程实践也都是为商业目的服务的。当我们说tech@core的时候,让我们说技术就是业务的时候。诚然,他给技术人员带来了更多的权利,然而权利越大,责任也越大。技术人员也需要跳出技术,具备更多的业务视角和体验视角。而不仅仅是沉浸在技术得自high当中。才能真正的发挥出各种实践的价值。


更多精彩洞见,请关注微信公众号:思特沃克

Share

数据安全在交付中的思考

2017年7月,Equifax用户数据泄露事件使得1亿4千300万个人信息(包括社会保障号码、出生日期、地址、驾照编号)和20万9千个用户的信用卡数据被盗。该事件直接导致1.43亿美国人的个人信息的破坏和泄露。CEO Richard Smith在数据泄露之后直接提出辞职,公司股价跌幅超过8%,市值蒸发35亿美元。

2016年9月,Yahoo宣布遭遇史上最严重的数据泄露,导致5亿用户的真实姓名、电邮地址、出生日期、电话号码的信息泄露。到了12月,新的数据泄露记录被打破,10亿账户数据被窃取,除了上述那些账户信息被盗外,连安全问题和答案也一起被盗。这两次的数据泄漏使得雅虎的售价降低了3亿5千万美元。

这些问题的原因距离我们并不遥远,Equifax将其数据泄露归咎于应用程序的安全问题,可能在于Java应用程序的开源Apache Struts框架中已知的安全漏洞,在这之前的数据泄露则很多来自SQL注入或者其他的业务逻辑漏洞。

伴随欧盟的通用数据保护条例和新的网络安全法的颁布,数据安全已经成为每个企业和IT从业者都必须要关注的一个话题。而我认为依赖于传统控制论基础上的主动防御和合规理论正在逐渐丧失其领导地位,要解决数据安全的问题,需要有一个场景化的方式,体系化的方案。接下来我们逐一解析。

重中之重的是数据安全的意识,意识是能力的基础,我们只有明确了这件事对于我们业务有价值之后,才能继续后面的方法和过程。上文中的数字已经说明,数据安全对于组织和个人来说都有价值且是必须的事情。Build Security In Our DNA, 我们需要不断增强我们在安全上的意识和理解。

在明确了意识在数据安全中的作用之后,我们需要去定义数据安全到底是什么,国际标准化组织(ISO)对计算机系统安全的定义是:为数据处理系统建立和采用的技术和管理的安全保护,保护计算机硬件、软件和数据不因偶然和恶意的原因遭到破坏、更改和泄露。由此计算机网络的安全可以理解为:通过采用各种技术和管理措施,使网络系统正常运行,从而确保网络数据的可用性、完整性和保密性。

狭义的数据安全是指直接围绕数据的防护技术,主要是指的是数据的访问控制,审计,加密,脱敏等。下面几个举措可以完善数据安全性在系统或者应用构建中的实践。在业务探索和系统设计的环节,我们需要建立以数据安全性为主的分析过程,下面几点需要重点关注一下。

首先,需要明确在当前场景下法律法规的约束和要求

本文以《网络安全法》中的数据安全要求为例。涉及到技术和管理两个方面,概括起来有如下几点:

  1. 对数据访问的日志进行审计,且日志留存时间不低于六个月。
  2. 对数据进行分类,将敏感数据和普通数据区别化处理。
  3. 对重要的数据进行备份,容灾。(第21,34条)
  4. 对重要数据进行加密(第21条,31条)
  5. 对个人信息进行脱敏(第42条)

第二,需要结合数据安全目标和构建整个交付项目的数据安全评估体系

思路如下:

  1. 了解场景,做影响性评估
  2. 数据收集和数据处理的分析
  3. 数据安全实现评估
  4. 数据安全的验证和补救

第三,安全虽然现在已经逐渐和业务紧密结合,出现像态势感知、自适应安全等新的方式,但是从总体上来说,它还是来源于体系化的控制,其核心是识别风险,做出改变。

那整体的业务风险我们需要一个框架来做诠释,这其中包括:

  1. 安全的策略和架构:数据安全在设立之初应该了解到组织对于数据安全的要求,明确哪些是敏感的,哪些是隐私数据,对待不同的数据资产,组织的态度是什么。
  2. 风险,业务连续性和合规:这是控制的方式和目标,在识别差异化之后,我们要了解一些业务上的风险,这部分可以用风险分析的方法了解到业务上的风险所产生的问题,结合与具体应用的场景,需要将风险和技术威胁结合起来。
  3. 数据安全运维:这部分需要在运维或者DevOps阶段考虑到,由于数据本身有生命周期的概念,那作为运维人员,需要考虑更多来自数据完整性上的要求,需要在DevOps和运维环节定期备份数据,需要有如下的措施,第一,在生产环境中要防止机密数据的丢失,第二,需要保护和备份敏感数据。第三,需要能够通过脱敏或者其他措施屏蔽或者加密某些字段。第四,要满足个人数据隐私保护法规的要求,对于个人数据的部分进行删除和屏蔽。
  4. 数据的获取,存储,传输和接入。这是数据生命周期中的主体,也是数据保护的难点,这部分会是我们考虑的重点。
  5. 在数据获取方面我们需要关注所要处理的一些敏感数据,这些数据包括一些敏感的生产数据,知识产权,个人身份识别或受保护的信息。我们在做Discovery和Inception的过程中要处理这些不同的数据,将其分类和定义。过程大概如下,需要对元数据进行分类解析,包括PCI,PII,PHI等等,这些数据的分类和获取,需要经过客户或者用户的同意(注意:GDPR当中已经对这部分有明确的立法)。其次作为敏感的数据以及一些合规数据和日志,这部分的存取和处理,也需格外关注。第三,管理敏感数据的访问方式,谁授予访问,修改和共享敏感数据的权限需要被关注到,这其中包括对于系统用户的验证和授权,还包括对于用户的行为提供监控和审核。这部分在系统设计的时候需要重点考虑。认证方面包括服务器和服务器之间的认证,客户端之间以及用户之间的认证。而在授权方需要对不同的阶段和用户进行响应的认证,在秘钥管理以及用户身份侧进行处理。比如,应用系统采用专用的登录控制模块,对登录用户进行身份标识和鉴别,具有用户身份唯一标识和鉴别信息复杂度检查功能,保证应用系统中不存在重复的用户身份标识,身份鉴别信息不易被冒用。应对同一个用户采用两种或两种以上组合鉴别技术实现用户身份鉴别。
  6. 在云计算环境中,安全问题的形势会变得特别严峻。数据安全和隐私保护是用户关注云技术的两个主要因素。尽管学术界和行业研究了许多关于云计算主题的技术,但数据安全和隐私保护对于政府,工业和商业中的云计算技术的未来发展变得越来越重要。数据安全和隐私保护问题与云架构中的硬件和软件相关。

最后,我想总结一下数据安全策略上的理解和认识,数据安全是通过完整性和机密性的控制来实现总体安全性上的目标,所采用的方案包括身份认证,访问授权和安全审计等措施,在用户,服务以及主机端完成的数据传输的一系列实践。


更多精彩洞见,请关注微信公众号:思特沃克

Share