云架构在甲方的落地之路-番外篇之企业安全

Posted 2022-12-23 tenghaohua

本来准备直接就云架构定义开启新的篇章。但是在仔细斟酌之后发现，将一整套云基础架构搬出来讲解，从技术角度来说其实并不是难事，但是这样就体现不出甲方IT在设计架构整个过程中的考量。正如在背景篇中介绍的，一个甲方的IT在思考架构或者方案时必定需要和企业自身的组织架构，业务需求结合在一起，并不是看到别人上个新颖的概念或者系统我们就必须依样画葫芦。

在云架构的设计中有至关重要的一项那就是云安全。说到云安全，许多同志们我估计第一反应就是IPS，IDS，FW, DLP, anti-virus,WAF等一整套全家桶。从技术的角度来说的确没有错，这些countermeasures在企业安全中起到了极大的保障作用。但是这一切都只是为了达到安全目的的一些特定工具，而并不是企业安全最本质的东西。随便找一个懂一定技术的partner其实都能帮你搞定这些，那我们甲方还需要安全部门干啥呢？

作为一个甲方的安全从业人员，最重要的并不是你懂多少安全的技术和产品，那最多只能让你成为一名优秀的工程师而不是架构师或者管理者。因此我们首先需要改变自己的security mindset。所以在这篇博客中我不会介绍任何安全产品（在之后的云架构定义中会另外涉及），而是会提及一些安全方面的理念和思路，希望能对我们的IT同志以及业务的同事有所启发。

在解释安全之前，首先要澄清的是，企业安全并不是IT一个部门的职责，而是贯穿整个企业内部，由上至下的战略规划，战术设计以及维护实施。

我相信企业的IT管理层经常会受到来自业务部门的一系列灵魂拷问，而如何保证企业的信息安全也一定是其中之一。许多具有一定规模企业的安全部门一般都有单独设立的安全部门，有跨国企业可能会在本地有相关的安全负责人，另一些可能则没有。在之前的篇章中我有简单介提到了TOGAF的架构开发，其中必定是组织架构和业务驱动作为基准依次对业务架构，信息系统架构以及技术架构进行开发。安全架构的开发也是如此，企业的安全涉及面不仅仅是IT的信息安全，此外还有资产，法律，合规，治理，安全培训，业务流程等都是安全中不可缺少的环节。如果任何安全相关的事情只需要IT来搞定，那为何如此多的大企业会设置CSO和CPO这样的职位呢？一个CIO搞定一切不就够了么？一个安全架构成熟度高的企业其security部门的地位可以说是一人之下万人之上，在高危的安全风险面前不会为任何业务理由妥协自己的决策。因为任何一次严重的安全事故都会对公司业务造成毁灭性的打击。但是从另一个角度来讲，安全一定也不能是业务的绊脚石，而应该是保护企业更好去开展业务。在这种矛盾之下，往往要求不仅是IT，而是整个公司都需要有一定的security sense。可惜的是在大多数情况下，由于所处的领域不同，除了法务合规部门外的许多业务同事都会把关注点放在业务流程上，这也无可厚非。那作为安全的主要负责人，无论是安全还是IT部门，都需要在企业资产遇到风险时和业务的同事分析利弊，共同寻求一个相对降低风险也能开展业务的方案。在这个过程中所涉及的所有部门都应该来相互协作，而不是互相推诿。

  

说了那么多，那到底什么是安全？

首先安全的目标是对数据和资源提供可用性、完整性和机密性的保护。

 

 

 做IT的同事们一定知道可用性和完整性，部分应该对机密性有概念，但是我相信公司内的业务以及法务合规部门对机密性一定甚是了解。

那security object呢？一般大多数同志们想到的是业务数据之类的。那我们换一个名词来描述--资产（asset）--资产是指任何对企业有价值的东西，包括人员，合作伙伴，设备，设施，声誉和信息。每一个资产都是被安全的保护起来。

那么从企业的角度该怎么去保护我们的资产呢？一般大企业都会有整套的企业安全架构落地，行业中也有许多可以参考的标准，每一个标准都扩展开来都可以写出通篇的内容，在这里仅作抛砖引玉：

安全规划方面一般用的比较多的是ISO27000。企业架构开发就比较多了，比如笔者刚学过的TOGAF，还有Zackman,DODAF,MODAF,SABSA，其中SABSA用的比较多来开发安全架构。安全控制开发有COBIT, NIST SP800-53, COSO等。还有过程管理开发，其中最多见的如ITIL, Six Sigma, CMMI等。

每一个标准和框架都有其对应的最佳应用场景，目前笔者也还没有时间去仔细研究，建议想从事安全的同志们可以深入学习下。

 安全最根本的定义是脆弱性（Vulnerability），威胁（Threat），风险（Risk）以及暴露(exposure)。每一个词都是安全领域中的风险所在。我们则要通过控制(control)，对策(countermeasure)和防护措施（safeguard)这些机制来降低这些风险。下图很好的解释了这些名词之间的互相联系

 

 

其次在整个安全控制中必定是预防，检测和纠正一起使用作为优先，一旦这些方法没有起到预想的效果就只能通过威慑，恢复以及事后的补偿了。

比如一般在我们入职一家公司都会签署NDA(Non-disclosure agreement)，这其实只是一个威慑，但并不能够从技术上去防止我们的内部员工或者合作伙伴来访问我们的数据。但是如果我们能有一系列的技术手段做到3A(authentication, authorization and accounting)，就可能在安全的优先控制阶段中把风险降低，而不是等真的发生数据披露再花更多的成本和精力走法律诉讼。

 说到这里就有另一个话题，就是风险。风险这块在PMP，TOGAF这些其他领域中都有过详细的解释，在安全中也是大同小异。在这里我就提出一点，由于便捷性和安全性在绝大多数情况都是对立面，那一定会产生在项目或者日常维护中出现例如业务流程的便利性产生了一定的安全风险，在这里我相信一定有同志会经常遇到有项目组或者业务的同事accept the risk 这种处理方式。首先这种方式并不是不可取的，当你的资产价值低于你所要采取的措施成本时，额外的安全投资其实是可以忽略。但是在接受风险的同时也要意识到企业是否可以承受由于该风险而导致的可能后果，以及事故发生时企业是否有额外的流程来处理和恢复业务。比如企业可以开发一套业务连续性计划来应对意外事故导致的业务中断，当然这一块其实也安全领域中的一部分，如果展开来讲也是一个比较大的话题，在这里就不深入挖掘了。

 

最后我在说一些资产安全的一些想法。之前也提过资产的涵盖范围比较广，那在保护资产的时候首先我们要认识到资产的价值，而这个价值可能会涉及到企业形象和声誉，竞争优势，运维成本，违规（法）成本，生产力等。然而这些资产的价值并不是我们IT的同事们可以赋予的，因此需要业务的同事让我们IT或者安全部门意识到所保护资产的重要程度如何，然后相关部门才能给出相对应的proposal。而不是一整套全家桶先上了再说，显得不专业也不实惠。

除了资产的赋值之外，资产的责任分层往往也是贯穿整个企业。比如系统数据的所有者（Data owner）以及 主管（supervisor）一般都来自业务部门，需要负责整个数据的业务流程以及终端用户的行为，如果是业务流程本身导致的数据泄露那Data Owner一般就只能自己把锅背上了，而IT更多的可能是系统所有者（system owner）,数据看管员(Data Custodian)，安全管理员(security administrator)，变更控制分析(Change Control Analyst)等。此外也会有内部或者外部的审计（auditor）来对我们的数据和系统进行周期性的安全合规检查。

由于篇幅有限，就只分享了一小部分安全领域的知识。总的来说，在一个甲方企业，安全这个事情谁都逃脱不了干系。整个安全的牵头人可以是安全部门也可以是IT，但是其他supporting以及业务部门都会在整个安全框架中担任其必要的角色。最后用下图作为一个总结和参考：

 

 在一些大的外企往往都会有完整的安全框架，当然由于林子太大可能不一定在每个地方都能落地的很好。而小到创业公司那就是会出现更多的是放飞自我操作。无论是大企业还是小公司，如果你轻视或者无视安全的管理，我相信或早或晚会有人让你交上可观的学费。现在任何一个初级IT爱好者都已经可以通过特定的套路和工具来侵入一个安全防护比较差的系统，更可况有时候威胁会来自于竞争对手或者公司内部。就像健身领域的一句名言--健身从健脑开始，安全亦是如此，先从改变我们的mindset做起来吧。