🕶️
安全架构要参:构建企业适用的安全架构
  • 声明
  • 序言
  • 第一部分:闲话安全工作
    • 1. 一些基本观点
    • 2. 认识业务
    • 3. 认识组织架构
    • 4. 阴与阳
  • 第二部分:浅谈安全架构
    • 5. 认识架构
    • 6. 认识企业安全
    • 7. 安全架构基础
    • 8. 解决方案
  • 第三部分:具体实施内容
    • 9. 持续服务
    • 10. 成为安全架构师
  • 附录A: 推荐阅读
  • 附录B: 案例
由 GitBook 提供支持
在本页
  • 定义
  • 目标
  • 规范
  • 质量[3]
  • 业务架构
  • 数据架构
  • 应用架构
  • 技术架构
  • 软件架构参考框架[11]

这有帮助吗?

  1. 第二部分:浅谈安全架构

5. 认识架构

一阴一阳之谓道,继之者善也,成之者性也。——《易经·系词上》

本章先是针对架构定义、目标、规范、质量进行介绍,其后分别针对业务架构、应用架构、数据架构、技术架构进行介绍。

定义

The art or science of building 一种关于构建的科学或者艺术

将构建目标的各种依赖[1](虚)拆解出来并将各对应组件(实)通过某种方式运转起来以符合目标需求的一种能力。[2]

目标

建立安全、可靠、高性能且符合成本控制的系统架构。

规范

需要具备使用指南、参考架构、以及经过审查的工具和代码,同时需要满足可操作性原则。

质量[3]

在评估架构质量时需要考虑的有以下范畴。通用的讲需

要满足三个方面:

  • 安全(Security)

  • 合规 (Legal & Regulatory)

  • 灾难恢复(DR)

针对外提供的服务需要满足可用性(Availability)、性能(Performance)、容量(Capacity)、隔离(Isolation)、可视化 (Visibility);

针对内部的或者说本地化的需要满足

  • 成本效率(Cost Efficiency)

  • 可扩展性(Extensibility)

  • 可操作性(Operability)

  • 可维护性(Maintainability)

  • 可伸缩性 (Scalability)

业务架构

Know your Business

业务架构[4]是代表整体的、多维的业务视图[5]。包含能力、端到端的价值交付、信息和组织架构、以及战略、产品、政策、计划和利益相关者之间的关系,并对业务流程功能进行分解。主要目标和原则为以下几点:

  • 遵守法律:企业政策是遵守法律、政策和法规。企业信息管理流程符合所有相关法律、政策和法规。企业必须注意遵守有关数据收集、保留和管理的法律、法规和外部政策。

  • 保持业务连续性:必须评估应用程序的关键性和对企业任务的影响,以确定需要何种程度的连续性以及需要何种相应的恢复计划。

  • 为企业带来最大利益:从企业范围的角度做出的决策比从任何特定组织角度做出的决策具有更大的长期价值。

  • 确保IT和业务相适应[6]:IT组织负责拥有和实施IT流程和基础架构,使解决方案能够满足用户定义的功能、服务级别、成本和交付时间要求。

下图阐释了个业务架构中各元素之间的具体依赖。

数据架构

Know your Data

通过组织架构,技术管理,流程控制,策略标准等更新迭代去实现数据治理。企业数据策略通过驱动数据治理以实现商业价值。针对数据管理,详参以下各个方面。

数据治理

  • 组织架构及运营模型

  • 策略及流程

  • 数据域模型及所有者

  • 数据问题管理

  • 数据变更管理

数据质量

  • 数据分析

  • 业务规则和阈值

  • 数据清洗

  • 数据补救

  • 数据质量报告

元数据

  • 业务分类

  • 数据字典

  • 元数据管理维护

  • 元数据访问

数据风险管理

  • 风险管理

数据保护

  • 数据安全

  • 数据隐私[7]

主从数据

  • 标准及聚合

  • 业务和数据规则

  • 数据中心和常用服务

  • 主从数据持久化

  • 主从数据访问

数据运营

  • 数据生命周期管理[8]

  • 数据供应及源认证

  • 数据转移和持久化

  • SLA管理

  • 数据认证

平台及架构

  • 数据模型

  • 数据管理平台

  • 数据整合

  • 数据架构

应用架构

Know your Services

此处主要针对单一系统[9]的应用架构进行介绍,在单一系统的应用架构中,实现了技术层面的

在类和代码的层级上有:

  • SRP(单一职责原则)

  • OCP(开闭原则)

  • LSP(里氏替换原则)

  • ISP(接口隔离原则)

  • DIP(依赖反转原则)

在组件的层级上有:

  • REP(复用、发布等同原则)

  • CCP(共同闭包原则)

  • CRP(共同复用原则)

处理组件依赖问题的三原则:

  • 无依赖环原则

  • 稳定依赖原则

  • 稳定抽象原则

技术架构

Know your Technology

技术架构一般是包含了整个技术范畴,在蓝图级别将整体的业务架构映射到具体的IT技术设施上。通常由架构师委员会[10]制定,包含了基础设施的技术栈(两种左右的编程语言,常用框架,数据库等),系统设计(Restful,SOA,SOAP,MicroService等),预研方向等。此处以金融支付类企业举例。

基础设施: 基础设施,数据平台,开发平台,集团服务等;

通用平台: 卡,风险,支付,认证,合规,金融,客户服务等;

产品线:具体到各个产品线等;

客户: 消费者,商户(小微,企业,合作伙伴),全球本地化等;

软件架构参考框架[11]

TOGAF[12]


[1] 依赖包含了逻辑上的所需而后映射到具体实际产品、组件,通过各种技术、流程将其运行起来以及持续运营并提供服务。

[2] 本定义是结合作者自身理解得出,仅供参考。

[3] 并非所有质量均需满足,读者需结合实际场景判断其需要支持的特性,随后采取对应技术支持该特性。例如保持HA,有负载均衡,有分级处理,有超时,有服务降级等。

[4] 另和业务架构一同提起的还有产品架构,属于是讲具体业务功能流程拆分后的产物。不在此赘述。

[5] 引用自https://cdn.ymaws.com/www.businessarchitectureguild.org/resource/resmgr/public_resources/Business_Architecture_Metamo.pdf

[6]这是CIO的主要职责之一。

[7] Data privacy is not about data, but about person.

[8] 主要包括收集、存储、使用、分享、销毁; 更多内容可参考DSMM模型,但实际治理不能仅以生命周期为主。

[9] 企业级应用架构实现了将业务流程映射到具体IT设施的过程。

[10] 参考第三章协作方式

[11] IT管理类框架、行业合规类框架,均不在此处阐述;Zachman亦不介绍了。

[12] 详细参考Opengroup官网https://pubs.opengroup.org/architecture/togaf9-doc/arch/pt1.html

上一页第二部分:浅谈安全架构下一页6. 认识企业安全

最后更新于3年前

这有帮助吗?