作者： 陈盛荣

题记：

安全是个技术+管理(人、流程)的问题。

技术解决的层次1. 基础安全服务 （认证、授权、审计） 2. 基础设施层（IPS, WAF） 3. 软件层  3.1 OS   3.2 应用APP (协议、漏洞)  4.安全服务（服务开发、管理、运营）

管理解决的层次 1. 人 （安全意识、社会工程学）   2. 流程、制度方法论   3. 物理隔离

IT安全架构概貌

一、IT安全架构来由

IT安全架构在企业中存在，存在即是合理，但是为什么存在？那么IT安全存在的理由是啥？为了解决事件！为了解决企业在实现赚钱过程中出现的一个个安全事件。通过IT安全架构的规范指导，建设和完善企业的IT系统与数据资产、流程；通过技术手段和流程来控制、降低业务流程中的风险，提高企业利润顺利达成率。下图IT安全实践流程演示了IT安全架构的重要位置。

IT安全实践流程

二、IT安全架构设计方法

安全这东西，要是没有发生些什么事故，往往是不会得到重视的。况且安全与方便往往也是相悖的，所以在设计过程中，总要互相权衡。在保证业务可用的情形下，实施安全策略。

1.       风险分析 (节点)  

目的是为了识别风险 （没有风险，安全防护就不存在了）

2.       安全架构设计通式

2.1    逻辑架构 （人+技术+流程）

安全边界、安全管理、安全情报CTR、安全响应、安全风险分析(big data analysis)、数据安全(隐私、泄密、灾难恢复)、应用安全(防病毒策略)、基础设施安全。

2.2    物理架构

网络拓扑 （IPS +TAP +WAF+FW +Router+ SW + host IP）。

网络场景（TAC、GRE、DMZ、Extranet、合资厂）。

3.       建立流程和规范

基于现在的业务场景考虑并且要着眼将来变化，trade off业务需求与安全考虑；流程可理解参考并且可实施。

4.       安全架构实施

资源（人力，财力），进行项目管理的方式，有timeline，有mile stone。

5.       安全可持续

5.1落实流程、安全变更走流程

  变更有申请、审批、测试以及验证，在实施过程中，有日志可审计，复核以及后续分析。

5.2 整合安全流程、安全指导，供参考

5.3 技术提供监督、监控手段 （信息上报 + 漏洞扫描器）

 

三、风险控制

3.1 事前安全

在发生安全事件前，我们必须对有IT风险有清晰的分析。正所谓无孔不入，安全的防护城墙如果是密不透风的，那倒是挺安全的。但是偏偏我们的服务要对外提供，跟外部必须要有数据交换，于是没有办法，在城墙上只能打孔钻洞（譬如web http 80/443），甚至开一个城门（城际DC专线）等。进而，我们必须在洞、城门上安排哨兵(防火墙FW)放哨，来保证城墙的安全。

3.1.1 风险点架构性分析与整改

1.       现状+场景描述

网络拓扑架构收集，以及外网Hosting IP收集。

对于外网IP的收集，企业能否有自动收集整个网络拓扑中的IP？可以借助用户终端的工具，服务器工具收集，其他通过分析防火墙策略进行识别。

2.       风险

A 部署位置是否对？譬如proxy部署在DMZ区

B 安装的OS

C patch是否更新

D 端口开放是否合理，（多开、错开）

E 是否应该物理隔离，逻辑隔离（不同的VLAN）？

F 是否增加硬件隔离（譬如是否要FW）

G 是否安装杀毒工具软件

H 网络通道是否要加密 （譬如VPN通道）

I  配置是否正确

J 是否有审计日志

K 是否有权限控制

L 环境安全（风火水电）

M 员工权限管理（初始化、激活、冻结、回收）

N 密码管理 （复杂度，周期变更）

3.       整改建议

A 调整产品部署位置

B 根据安装的OS，识别出高危漏洞

C… 针对风险一一给出破解的招数

3.1.2 工具保证

 1. 产品上线前扫描

   对上线的产品，进行配置与代码的自动扫描，给出建议，最常见的譬如产品字段的，危险函数，缓冲区溢出，数组越界等。

   对于Web类产品，通过CGI扫描器，对其进行常规漏洞测试，包括SQL Inject, XSS,Head, 跳转漏洞，弱密码，跨目录，CRLF攻击等等。

 2. 加固的系统镜像，自动给系统漏洞patch

 

3.1.3 蜜罐诱饵的部署

 为了方便快速识别入侵者，部署蜜罐，守株待兔。

 

3.2   事中安全

安全看起来，好像只有事前，事后。就是事前整治，事后擦屁股，不关事中什么事。

但是话说回来，如果事中能做到立体监控，动态发现，对事件的及时发现与风险的有效控制是有极大的作用的。

1 权限Review

定期自动化的权限Review，识别僵死权限，回收无用、或者过度授权的权限

2 认证持续改进

认证持续改进有两方面，一是要考虑用户体验，提升用户达到认证可达的情况，使用产品用起来，“爽”。

另一方面是在攻防背景下，认证的堵漏和补缺，也可考虑借力大数据分析。

3 审计操作

数据分析是这个环节的重点，建立识别风险的模型。

4告警监控

建立立体监控的网络，包括软件、硬件、服务，甚至风火水电要素。

5人员培训 （责权明晰）

培训安全意思，让每人了解自己的角色和工作要点，在发生安全事件的时候，能快速的响应，信息能平顺的流转到各个节点（人员）。

3.3   事后安全

我们不希望发生安全事件，因为一旦发生，都会有人站出来承担。但是如果一直没有类似的事件的话，安全也难以发展与进步，最重要的是领导可能无法感知安全的风险，也就无法给予足够的重视。

 1 快速响应

         发生安全事件后，考量第一是快速响应，知会相干人，并且止血。

 2 加固

        加固是个大话题，大可以到网络的安全加固，小可以到apk dex的加固，甚至是几行代码级别的加固。反正就是有事做，安全加固的级别不同，工作量也就不同。

 3 总结

         回顾整个安全事件，由于。。。。导致。。。。。加强。。。。。保证下次不再发生。

         自动风险识别以及大数据结合的风险预警应该是不断前行的方向。

 

四、IT架构云方向

云计算是一种更方便的共享资源池（网络、服务、计算、存储、应用等）模型；一种支持按需扩容、缩容；保证高可用、可降低功耗的平台技术。

在云趋势的状况下，有专家建议是否企业网络边界的GRE区、DMZ区都迁移到公有云上，从而降低内网的安全风险。但同时对云安全的要求进一步提高了。

什么是云安全？参考《SymantecCloud Security Broker》的一个架构图：

云安全架构

构建云安全需要做下面四件事情：

1.       构建云的安全访问代理层 (Cloud AccessSecurity Broker)

从入口层级进行访问控制，可以更快的发现安全风险。

2.       构建云的数据保护层

云数据的安全是SaaS层的核心内容，通过DLP和Crypto等产品，识别核心数据资产，对数据进行分类，建立不同的数据安全等级。

3.       构建云风险发现平台

通过对IaaS层的workload&network，结合用户行为(UEBA  UserEntity Behavior Analytics)进行大数据分析、预测，构建风险识别模型。

4.       构建云可视化平台

Seeing isbelieving.

更加方便的云安全的运维，帮助非专业人士理解云安全。

  

尾记：      

        作为读者而言是不是感觉 安全知识知道的越多，越感觉不安全呢？哈哈。其实安全知识了解的越多，越会认同一个道理，那就是世界上没有绝对的安全。电影《方世玉》中一位师伯，嘴巴经常挂着“安全第一”，但最终还是挂了。。。说到底，安全是为企业生存和利润服务的，如果企业的生存和利润都无法保证，安全自然也就没有意义了。

         IT安全一直在进化和演进，从单机安全、集群安全到云安全，从主机物理化到虚拟化，技术在变化，安全也要跟上趟。

参考

1.http://www.opensecurityarchitecture.org/cms/foundations/osa-taxonomy

2.http://www.opensecurityarchitecture.org/cms/foundations/osa-landscape

3.http://aws.amazon.com/security

4. Get Your Headin the Cloud: A Practical Model for Enterprise CloudSecurity  http://www.rsaconference.com/writable/presentations/file_upload/spo1-w04-get-your-head-in-the-cloud-a-practical-model-for-enterprise-cloud-security.pdf

5.10条云计算安全成功之路 http://www.cloud-council.org/deliverables/CSCC-Security-for-Cloud-Computing-10-Steps-to-Ensure-Success.pdf

6. http://www.hwclouds.com

7. http://e.huawei.com/cn/allproduct