精华内容
下载资源
问答
  • 第4章 网络安全体系与网络安全模型

    千次阅读 2021-09-05 19:58:24
    第4章 网络安全体系与网络安全模型第4章 网络安全体系与网络安全模型1. 网络安全体系概述1.1 概念1.2 特征1.3 用途2. 网络安全体系相关模型[2.1 BLP机密性模型]...

    第4章 网络安全体系与网络安全模型

    1. 网络安全体系概述

    1.1 概念

    • 网络安全体系是网络安全保障系统的最高层概念抽象,由各种网络安全单元(安全策略、安全技术、安全管理等)按照一定规则组成,共同实现网络安全目标

    1.2 特征

    • 整体性

      • 全局、长远角度实现安全保障,各单元相互作用、约束、依赖,形成人机物一体化
    • 全面性

      • 基于多维度、多层面对安全威胁进行管控,构建防护、检测、响应、恢复等网络安全功能
    • 协同性

      • 各种安全机制相互作用,构建系统性的网络安保方案
    • 过程性

      • 针对保护对象,提供一种过程式网络安保机制,覆盖保护对象全生命周期
    • 适应性

      • 动态演变,适应网络安全威胁的变化和需求

    1.3 用途

    • 有利于系统性化解网络安全风险,确保业务持续开展并将损失降到最低限度
    • 有利于强化工作人员的网络安全意识,规范组织、个人的网络安全行为
    • 有利于对组织的网络资产进行全面系统的保护,维持竞争优势
    • 有利于组织的商业合作
    • 有利于组织的网络安全管理体系认证,证明组织有能力保障重要信息,提高组织的知名度与信任度

    2. 网络安全体系相关模型

    2.1 BLP机密性模型

    • 强制访问控制MAC模型

    • 下读、上写;信息自下而上流动;侧重于保护数据的机密性和对客体的受控访问

    • 两个特性

      • 简单安全特性

        • 下读:主体对客体进行读访问的必要条件是主体的安全级别不低于客体的安全级别,主体的范畴集合包含客体的全部范畴集合
      • *特性

        • 上写:一个主体对客体进行写访问的必要条件是客体的安全级支配主体的安全级,即客体的保密级别不低于主体的保密级别,客体的范畴集合包含主体的全部范畴
    • 为实现军事安全策略,计算机系统的用户和信息都分配一个访问类,由两部分组成

      • 安全级:公开<秘密<机密<绝密
      • Security Rating:Unclassified<Confidential<Secret<Top Secret
      • 范畴集
      • 文件F访问类:{机密:人事处、财务处}

    2.2BiBa完整性模型

    • 强制访问控制MAC模型;侧重于保护数据完整性

    • 上读、下写;信息自上而下流动

    • 三个安全特性

      • 简单安全特性

        • 上读:主体不能从较低完整性级别读取数据
      • *特性

        • 下写:主体不能修改较高完整性级别的数据
      • 调用特性

        • 主体不能调用较高完整性级别的主体

    2.3 信息流模型

    • 访问控制模型的一种变形,不检查主体对客体的读取,而是根据两个客体的安全属性控制从一个客体向另一个客体的信息传输
    • 用于分析系统的隐蔽通道,防止敏感信息通过隐蔽通道泄露

    2.4 信息保障模型

    • PDRR模型

      • 保护Protection

        • 加密、签名、访问控制、认证、信息隐藏、防火墙
      • 检测Detection

        • 入侵检测、系统脆弱性检测、数据完整性检测、攻击性检测
      • 恢复Recovery

        • 数据备份、恢复、系统恢复
      • 响应Response

        • 应急策略、应急机制、应急手段、入侵过程分析、安全状态评估
      • [单选] 我国提出了信息系统安全保障体系PDRR模型,该模型中的响应是指(A)。
        A . 对危及安全的事件做出处理,杜绝危害的进一步扩大 Response
        B . 保障信息的保密性、完整性、可用性 Protection
        C . 系统遭到破坏后,可尽快恢复系统功能Recovery
        D . 检测系统存在的安全漏洞,阻止网络攻击Detection

    • P2DR模型

      • 安全策略Policy

        • 安全策略描述系统的安全需求,以及如何组织各种安全机制实现系统的安全需求
      • 防护Protection

      • 检测Detection

      • 响应Response

      • 进一步演变 P2DR2 增加了“恢复Recovery”

    • WPDRRC模型

      • 预警warning、防护Protection、检测Detection、响应Response、恢复Recovery、反击Crack

    2.5 能力成熟度模型

    • SSE-CMM

      • 系统安全能力成熟度模型SSE-CMM Systems Security Engineering-Capability Maturity Model

      • 五个级别

        • 1级-非正式执行

          • 具备随机、无序、被动的过程;混乱
        • 2级-计划跟踪

          • 具备主动、非体系化过程;项目层面
        • 3级-充分定义

          • 具备正式的、规范的过程;组织机构层面、标准规范、定性
        • 4级-量化控制

          • 具备可量化的过程;定量
        • 5级-持续优化

          • 具备可持续优化的过程
      • 包括三个过程类型

        • 工程过程类Engineering

          • 工程过程Engineering:产品或服务
          • 风险过程Risk:风险信息
          • 保证过程Assurance:保证论据
        • 项目过程类Project

        • 组织过程类Organization

      • SSE-CMM的工程质量来自于保证过程

    • 数据安全能力成熟度模型

      • 数据生命周期

        • 采集
        • 存储
        • 传输
        • 处理
        • 交换
        • 销毁
      • 安全能力维度

        • 组织建设

          • 数据安全组织机构的架构建立、职责分配和沟通合作
        • 制度流程

          • 组织机构关键数据安全领域的制度规范和流程落地建设
        • 技术工具

          • 通过技术手段和产品工具固化安全要求或自动化实现安全工作
        • 人员能力

          • 执行数据安全工作的人员的意识及专业能力
      • 能力成熟度

        • 1级-非正式执行
        • 2级-计划跟踪
        • 3级-充分定义
        • 4级-量化控制
        • 5级-持续优化
    • 软件安全能力成熟度模型

      • CMM1级-补丁修补
      • CMM2级-渗透测试、安全代码评审
      • CMM3级-漏洞评估、代码分析、安全编码标准
      • CMM4级-软件安全风险识别、SDLD实施不同安全检查点
      • CMM5-改进软件安全风险覆盖率、评估安全差距

    2.6 纵深防护模型

    • 4道防护线

      • 安全保护

        • 阻止对网络的入侵和危害
      • 安全监测

        • 及时发现入侵和破坏
      • 实时响应

        • 当攻击发生时维持网络“打不垮”
      • 安全恢复

        • 网络在遭受攻击后以最快速度“恢复”,最大限度降低损失

    2.7 分层防护模型

    • 针对单独保护节点,以OSI 7层模型为参考,对保护对象进行层次化保护

    • 典型分层

      • 物理层、网络层、系统层、应用层、用户层

    2.8 等级保护模型

    2.9 网络生存模型

    • 网络生存性是指网络信息系统遭受入侵情形下,仍能提供持续必要服务的能力

    • 3R建立方法

      • 抵抗Resistance
      • 识别Recognition
      • 恢复Recovery

    3. 网络安全体系建设原则与安全策略

    建设原则

    • 系统性和动态性原则

      • 木桶原理;系统整体安全性;安全防范动态性,不断调整安全措施
    • 纵深防护和协作性原则

      • 安全评估机制

        • 识别网络系统风险,分析网络风险,制定风险控制策略
      • 安全防护机制

      • 安全监测机制

      • 安全应急响应机制

    • 网络安全风险和分级保护原则

      • 正确处理需求、风险与代价关系,做到安全性与可用性相容
      • 根据网络资产安全级别采取合适等级保护做到适度防护
    • 标准化和一致性原则

    • 技术和管理相结合原则

    • 安全第一,预防为主原则

    • 安全与发展同步,业务与安全等同

      • 三同:同步规划、同步建设、同步运行
      • 四统一:统一谋划、统一部署、统一推进、统一实施
    • 人机物融合和产业发展融合

      • 网络安全体系建设要依托网络信息产业发展,做到自主可控、安全可信,建立持续稳定发展的网络安全生态,支撑网络安全体系的关键要素可控

    安全策略

    • 安全策略文件具备以下内容

      • 涉及范围、有效期、所有者、责任、参考文件、策略主体内容、复查、违规处理

    4. 网络安全体系框架主要组成和建设内容

    网络安全组织的建立是网络安全管理工作开展的前提

    网络安全组织机构

    • 领导层
    • 管理层
    • 执行层
    • 外部协作层

    网络安全管理体系涉及5个方面内容

    • 管理目标
    • 管理手段
    • 管理主体
    • 管理依据
    • 管理资源

    在人员安全的工作安排方面,应该遵守以下三个原则

    • 多人负责原则

      • 每一项与安全有关的活动,至少两人在场
    • 任期有限原则

    • 职责分离原则

    5. 网络安全体系建设参考案例

    网络安全等级保护体系应用

    • 网络安全等保工作

      • 定级

        • 定级工作

          • 业务信息安全等级

            • 确定遭受破坏时侵犯的客体
            • 综合评定对客体侵害程度
            • 业务信息安全等级
          • 系统服务安全定级

          • 取二者最高的级别为最终定级

      • 备案

        • 二级及其以上到公安机关备案
      • 建设整改

      • 等级测评

      • 监督检查

    • 网络安全等保5个等级

      • 1级用户自助保护级
      • 2级系统保护审计级
      • 3级安全标记保护级
      • 4级结构化保护级
      • 5级访问验证保护级
    • 等保2.0体系框架

      • 风险管理体系
      • 安全管理体系
      • 安全技术体系
      • 网络信任体系
      • 法律法规体系
      • 政策标准体系
    • 等级保护对象

      • 网络基础设施
      • 信息系统
      • 大数据
      • 互联网
      • 云计算平台
      • 移动互联网和智能设备
    • 网络安全等保2.0的三个变化

      • 扩大保护对象

      • 提出在安全通信网络、安全计算环境、安全区域边界、安全管理中心支持下的三重防护体系

      • 强化可信计算技术使用的要求,各级增加科信验证控制点

        • 一级:设备的引导程序、系统程序进行可信验证
        • 二级:重要参数和应用程序进行可信验证,并将验证结果形成审计记录送至安全管理中心
        • 三级:应用程序关键执行环节进行动态可信验证
        • 四级:应用程序所有环节进行动态可信验证

    智慧城市安全体系应用

    • 智慧城市安全体系框架5要素

      • 安全战略保障

        • 法律法规、政策文件、标准规范
      • 安全技术保障

        • 技术功能要素

          • 防护、检测、响应、恢复
        • 分层安全

          • 应用层安全
          • 数据与服务融合层安全
          • 计算与存储安全
          • 网络通信层安全
          • 物联感知层安全
      • 安全管理保障

        • 决策规划
        • 组织管理
        • 协调监督
        • 评价改进
      • 安全建设与运营保障

        • 工程实施
        • 监测预警
        • 应急处理
        • 灾难恢复
      • 安全基础支撑

        • 密钥与整数、身份管理等基础性支撑
        • 认证、评估、检测、审查、设计等基础支撑服务

    智能交通网络安全体系应用

    • 智能交通网络安全技术体系参考WPDRRC信息安全模型

    • 智能交通网络安全运营体系由三要素组成

      • 运营管理

      • 网络安全事件周期管理

        • 预防(事前)
        • 监控(事中)
        • 响应(事后)
        • 自主有效闭环
      • 工具

    ISO 27000信息安全管理体系应用

    • PDCA循环、戴明环

      • Plan计划
      • Do 执行
      • Check 检查
      • Act处理修正

    NIST网络安全框架体系应用

    • 美国国家标准与技术研究研发布《提升关键基础设施网络安全的框架》

    • 5个核心功能

      • 识别 Identify

        • 对数据、系统、资产和网络所面临的安全风险的认识和确认
        • ID.AM 资产管理;ID.RA风险评估;ID.RM风险管理策略
      • 保护Protect

        • 制定和实施合适安全措施保护关键基础设施
        • PR.AC访问控制;PR.AT意识和培训;PR.DS数据安全
      • 检测Detect

        • 制定和实施恰当行动以发现网络安全时间
        • DE.AE异常事件;DE.CM安全持续监测;DE.DP检测处理
      • 响应Response

        • 对已发现的网络安全时间采取合适行动
        • RS.RP响应计划;RS.CO通信;RS.MI缓解;RS.IM改进Improvements Mitigation Analysis
      • 恢复Recover

        • 以弹性容忍安全事件出现并修复受损功能或服务
        • RC.RP恢复计划;RC.IM改进;RC.CO通信

    6. 思维导图

    思维导图

    展开全文
  • 关于记录方式做了一些思考,本章开始对于一些偏向于套话的东西将进行大幅缩减,概念性的东西只会记录...本章是网络安全体系与网络安全模型,这里只记录重点 BLP机密模型 有两个特性,简单安全特性和*特性 ...

    关于记录方式做了一些思考,本章开始对于一些偏向于套话的东西将进行大幅缩减,概念性的东西只会记录重要技术和必备特征,考纲覆盖的太过完整但是考虑到考试只会考选择题,所以会面向考选择的方式进行记录,同时改变记录方式,先阅读一遍回头复习性的补上笔记。

    本章是网络安全体系与网络安全模型,本章开始只记录可以出题的重点

    网络安全体系相关安全模型

    • BLP机密模型
      • 主要用于防止消息扩散,注重机密性
      • 简单安全特性:指只有高安全级别的主体可以对低安全级别的主体进行读操作
      • *特性指:只有低安全级别的主体可以对高安全级别的主体进行写操作
      • 这俩说的有点乱,其实简单安全特性就是高级别可以访问低级,就像军队一样,高军衔可以命令低军衔。而*特性要从数据流的角度看,即数据流只能从低级往高级流,不能从高级往低级流,因为如果高级别往低级别流会导致高级别信息被低级别获取。
    • Biba完整性模型
      • 主要用于防止非授权修改信息,来保护完整性
      • 简单安全特性:主体对客体进行修改访问的必要条件是主体完整性级别不小于客体
      • *特性:主体完整性级别小于客体的完整性级别,就不能修改客体,即主体不能往上写
      • 调用特性:主题完整性小于另一个主体完整性级别,就不能调用
    • 这两个模型书里写的很笼统,查阅资料后给一个总结
      • BLP模型注重机密性,即高权限的可以访问低权限,低权限不能访问高权限。
      • Biba模型注重完整性,高完整性的可以被随意访问,但是只有高完整性的可以修改低完整性的数据,低完整性不能修改高完整性数据。比如机密等级1,2,3。1是最高级,可以被任何人看见,但是不能修改它,但是2可以读1来生成2级的信息。
      • 所以这俩是一个相反的关系
    • 信息流模型
      • 它是访问控制模型的变形,简称FM(flow model)
      • 不检查主客体的存取关系,而是通过客体的安全属性来控制传输
      • 一般用N表示客体集,P表示进程集(protocol),sv表示安全类型(这个没咋细说,看一眼就行)
      • 它主要是用来分析系统的隐蔽通道,防止低安全等级对高安全等级的间接读取
    • 信息保障模型
      • PDRR模型
        • protecion,detection,recovery,response的缩写
        • protection(保护):包含加密,数据签名,访问控制,认证,防火墙等机制
        • detection(检测):包含入侵检测,系统脆弱性,数据完整性,攻击性检测(就是一堆检测)
        • recovery(恢复):主要内容有数据备份,数据修复,系统恢复等(就是备份恢复)
        • response(响应):应急策略,应急机制,应急手段,入侵过程分析,全状态评估等(就是应急响应)
      • P2DR模型
        • ​​​​​​​policy,protection,detection,response
        • 对比之前少了一个recovery,多了一个policy(策略)
        • 策略就是描述了下安全需求
      • WPDRRC模型
        • ​​​​​​​不出意外就是warning(预警),protection(保护),detection,recovery,response,counterattack(反击)这几个单词混起来的
        • 多了个预警反击,注意这里的反击counterattack,也可以翻译成逆袭哦
      • 这几个认清对应单词就行
    • 能力成熟模型
      • ​​​​​​​简称CMM,Capability Maturity Model
      • 是对一个组织机构能力进行成熟度评估的模型,一般分五级
        • 1级-非正式执行:具备随机的、无序的、被动的过程
        • 2级-计划跟踪:具备主动的非体系化的过程
        • 3级-充分定义:具备正式的规范的过程
        • 4级-量化控制:具备可量化的过程
        • 5级-持续优化:具备可持续优化的过程
      • 主要有SSE-CCM,数据安全成熟度模型,软件安全能力成熟度模型,感觉挺难考到,不多做赘述
    • 纵深防御模型
      • ​​​​​​​基本思路是把多个保护措施有机集合,形成多道防线,各保护措施之间能够互相支持和补救,主要有四道防线
        • 第一道:安全保护,组织入侵和危害
        • 第二道:安全检测,及时发现入侵和破坏
        • 第三道:实时响应,攻击发生时维持网络打不垮
        • 第四道:恢复,遭受攻击后迅速恢复
        • 总结就是先保护,让他进不来,进来了要早点发现,发现了要赶紧反应对抗,被打垮了要能缓过来
    • 分层防护模型
      • ​​​​​​​针对单独保护节点,参考OSI 7层模型,分为物理层,网络层,系统层,应用层,用户层,管理层(7层变6层),对各层进行安全防护
    • 等级保护模型
      • ​​​​​​​只要记住是根据系统重要程度来制定不同策略就行
    • 网络生存模型
      • ​​​​​​​是指在网络信息系统遭受入侵情况下,仍然能够持续提供必要服务的能力。
      • 遵循3R的建立方法,即resistance抵抗,recognition识别,recovery恢复
      • 针对攻击方式根据以上三点给出策略

    网络安全体系建设原则与安全策略

    • 网络安全原则
      • 系统性和动态性原则
        • 系统性主要提到了木桶效应,即薄弱点容易受攻击,要注意整体安全性。
        • 动态性是因为每个月都会有新弱点发现,所以要及时更新安全策略。
      • 纵深防护与协作性策略
        • 结合之前的纵深防御模型理解即可
      • 网络安全风险和分级保护策略
        • 提到了一个网络安全不是绝对的,要正确处理需求,平衡安全性和可用性
        • 分级保护策略结合之前分级模型理解
      • 标准化与一致性原则
        • 标准化能确保系统一致性,不多做解释
      • 技术与管理相结合
        • 因为安全体系涉及到人,技术,操作多个要素。有的东西单纯靠技术不能实现,要和管理结合
      • 安全第一,预防为主
        • 听烂了
      • 安全与发展同步,业务与安全相等
        • 有政治课那味了
      • 人机物融合和产业发展原则
        • 人是信息系统中最活跃要素,体系建设要分析人的需求,然后就是思政课的套话了
      • 总结就是看一下就行,八成不会考
    • 网络安全策略
      • 策略文件应该包含以下内容:涉及范围,有效期,所有者,责任,参考文件,策略主体内容,复查,违规处理
      • 感觉这玩意是用来查的

    网络安全体系框架主要组成和建设内容

    • 组成部件有
      • 网络安全法律法规
      • 网络安全策略
      • 网络安全组织
      • 网络安全管理
      • 网络安全基础设施和服务
      • 网络安全技术
      • 网络信息科技和产业生态
      • 网络安全教育和培训
      • 网络安全标准和规范
      • 网络安全运营和应急响应
      • 网络安全投入和建设
      • 这个我就打一遍打死不背考了算我倒霉
    • 策略建设内容略掉
    • 网络安全组织体系构建内容
      • 分为领导层,管理层,执行层外部协作层
    • 网络安全管理体系构建内容
      • 网络安全管理策略
      • 第三方安全管理
        • 根据第三方业务需求进行风险评估
        • 与第三方签订安全协议或合同
        • 对第三方访问人员身份进行识别和授权
      • 网络系统资产分类和控制
        • 硬件:计算机,网络设备,传输介质和转换器,输入输出
        • 软件:操作系统,软件等
        • 存储介质:光盘,硬盘,各种盘
        • 信息资产:文字信息,数字信息,各种信息
        • 网络服务和业务系统:电子邮件,web服务等
        • 支持保障系统:消防,动力,空调之类的
        • 同时分级为公开,内部,机密,限制
      • 人员安全
        • 多人负责原则
        • 任期有限原则
        • 职责分离原则
      • 网络物理与环境安全
      • 网络通信与运行
      • 网络访问控制
      • 网络应用系统开发和维护
      • 网络系统可持续运行
      • 网络安全合规性管理
      • 看看就好
      • 后面不想打了,看了看都好没意思

    总结:这一章有太多冗长无聊的规定,唯一值得记忆的只有一开始的几个模型,参考案例由于太过冗长不好描述可以自己看书p84,而原则和建设内容部分实在是让人兴趣缺缺,下一章是物理与环境安全技术,更加贴合生活一点,希望能写的舒服点。

     

     

     

     

     

    展开全文
  • 信息安全技术体系

    2021-01-29 10:40:39
    信息安全技术体系 这是一个学习安全的大框架,正好碰到了就记录下来,如果有发现遗漏,欢迎留言补充 核心基础安全技术:包括密码技术、信息隐藏技术 安全基础设施技术:包括标识与认证技术、授权与访问控制技术等 ...

    信息安全技术体系

    这是一个学习安全的大框架,正好碰到了就记录下来,如果有发现遗漏,欢迎留言补充

    • 核心基础安全技术:包括密码技术、信息隐藏技术
    • 安全基础设施技术:包括标识与认证技术、授权与访问控制技术等
    • 基础设施安全技术:包括主机系统安全技术、网络系统安全技术等
    • 应用安全技术:包括网络与系统攻击技术、网络与系统安全防护与应急响应技术、安全审计与责任认定技术、恶意代码检测与防范技术、内容安全技术等
    • 支援安全技术:包括信息安全技术框架、信息安全测评与管理技术
    展开全文
  • 运维体系框架标准化模型简介

    千次阅读 2018-02-01 11:05:49
    同时,如果说上次我们讲的基础设施和应用标准化是运维团队职责的话,那今天的内容就是架构、开发和运维共同的职责。 常见的分布式基础架构组件 让我们先一起列一下,微服务的分布式架构下,涉及到的主要...

    为什么要做标准化?

    标准化的过程实际上就是对运维对象的识别和建模过程。形成统一的对象模型后,各方在统一的认识下展开有效协作,然后针对不同的运维对象,再抽取出它们所对应的运维场景,接下来才是运维场景的自动化实现。

    这有点像我们学的面向对象编程的思想,其实我们就是需要遵循这样一个思路,我们面对的就是一个个实体和逻辑运维对象。

    在标准化的过程中,先识别出各个运维对象,然后我们日常做的所有运维工作,都应该是针对这些对象的运维。如果运维操作脱离了对象,那就没有任何意义。同样,没有理清楚对象,运维自然不得章法。

    比如我们说扩容,那就要先确定这里到底是服务器的扩容,还是应用的扩容,还是其它对象的扩容。你会发现,对象不同,扩容这个场景所实施的动作是完全不一样的。

    如果把服务器的扩容套用到应用的扩容上去,必然会导致流程错乱。同时对于对象理解上的不一致,也会徒增无谓的沟通成本,造成效率低下。自然地,这种情况下的运维自动化不但不能提升效率,还会越自动越混乱。

    这就是为什么我每次都会连续强调三遍“标准先行”的原因。虽然这个事情比较枯燥和繁琐,但是于纷繁复杂中抽象出标准规范的东西,是我们后续一系列自动化和稳定性保障的基础。万丈高楼平地起,所以请你一定不要忽略这个工作。

    好,总结一下标准化的套路:

    • 第一步,识别对象
    • 第二步,识别对象属性
    • 第三步,识别对象关系
    • 第四步,识别对象场景

    接下来我们就按照上面这个思路,一起来分析从基础设施层面和应用层面应该识别出哪些运维对象。

    基础设施层面的标准化

    基础设施层面的运维对象应该不难识别,因为都是一个个物理存在的实体,我们可以进行如下分析。

    • 第一步,识别实体对象,主要有服务器、网络、IDC、机柜、存储、配件等。
    • 第二步,识别对象的属性,比如服务器就会有 SN 序列号、IP 地址、厂商、硬件配置(如 CPU、内存、硬盘、网卡、PCIE、BIOS)、维保信息等;网络设备如交换机也会有厂商、型号、带宽等信息。
    • 第三步,识别对象之间的关联关系,比如服务器所在的机柜,虚拟机所在的宿主机、机柜所在 IDC 等简单关系;复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系等,这些相对复杂一些,也就是我们常说的网络拓扑关系

    把以上信息梳理清楚,通过 ER 建模工具进行数据建模,再将以上的信息固化到 DB 中,一个资源层面的信息管理平台就基本成型了。

    以服务器为例简单展示一下,我们的视角就是下面这样的:

    但是,信息固化不是目的,也没有价值,只有信息动态流转起来才有价值。接下来我们需要做的事情,就是识别出针对运维对象所实施的日常运维操作有哪些,也就是识别出运维场景是什么

    • 第四步,还是以服务器为例,我们针对服务器的日常操作有采购、入库、安装、配置、上线、下线、维修等等。另外,可能还会有可视化和查询的场景,如拓扑关系的可视化和动态展示,交换机与服务器之间的级联关系、状态(正常 or 故障)的展示等,这样可以很直观地关注到资源节点的状态。

    完成了这些工作,接下来才是对上述运维场景的自动化开发。所以你看,在真正执行去做工具和自动化平台之前,其实是需要先做好大量的基础准备工作的。我要再次强调这一点,一定不能忽视。

    应用层面的标准化

    下面我们再一起看一个逻辑上的对象,就是我们前面经常提到的运维的核心:应用。对这个逻辑对象的建模会相对复杂一些,不过我们依然可以按照上面的套路来。

    • 第一步,识别对象。

    我们前面讲过,这个识别过程是在做微服务架构设计或拆分的时候就确定下来的。所以严格地讲,它不应该是运维阶段才被识别出来的,而是在之前设计阶段就被识别和确认下来,然后延伸到运维这里才对。

    • 第二步,识别对象属性。

    一个应用是业务的抽象逻辑,所以会有业务和运维两个维度的属性。业务属性在业务架构时确定,这主要是需要业务架构师去识别的,但是它的运维属性就应该由运维来识别了。

    下面我们一起来看一下,一个应用应该具备哪些基本的运维属性。

    * 应用的元数据属性,也就是简单直接地描述一个应用的信息,如应用名、应用 Owner、所属业务、是否核心链路应用以及应用功能说明等,这里的关键是应用名;

    * 应用代码属性,主要是编程语言及版本(决定了后续的构建方式),GitLab 地址;

    * 应用部署模式,涉及到基础软件包,如语言包 Java、C++、Go 等;容器如 Tomcat、JBoss 等;

    * 应用目录信息,如运维脚本目录、日志目录、应用包目录、临时目录等;

    * 应用运行脚本,如启停脚本、健康监测脚本;

    * 应用运行时的参数配置,如运行端口、Java 的 JVM 参数 GC 方式、新生代、老生代、永生代的堆内存大小配置等。

    从应用属性的视角,应该是下面这样一个视图(简单示例,不完整):

    • 第三步,识别对象关系。

    也就是应用与外部的关系,概括起来有三大类:

    第一类是应用与基础设施的关系,包括应用与资源、应用与 VIP、应用与 DNS 等等的关系;

    第二类是平行层面的应用与应用之间的关系,这里再细分下去就是应用服务或 API 与其它应用服务和 API 的依赖关系。如果你有相关的经验,应该会联想到全链路这样的工具平台了,没错,这样的平台就是用来处理应用间关系管理的。

    第三类是应用与各类基础组件之间的关系,比如应用与缓存,应用与消息、应用与 DB 等等之间的关系。

    • 第四步,识别应用的运维场景。

    这个就会比较多了,比如应用创建、持续集成、持续发布、扩容、缩容、监控等;再复杂点的比如容量评估、压测、限流降级等。

    好,这里我们先收一下,聚焦到标准化的层面,通过基础设施和应用层面标准化的示例,我想你应该可以掌握基本的建模思路了,这样的思路可以应用到其它的运维对象上 。

    同时,通过上面这些内容,你应该可以比较清晰地看到,我们的每一个运维操作都是针对某个运维对象的,这一点在规划运维体系时非常重要。

    而在这些对象中,应用又是重中之重,是微服务架构下的核心运维对象

    从应用标准化的过程中我们也可以看到,针对应用的识别和建模,明显复杂很多。所以,后面我还会从理论和实践的角度来继续强化和分析这个概念。

    今天,我继续跟你聊基础架构标准化的问题,但是今天我计划不谈如何进行架构标准化的细节,而是想强调一下基础架构标准化的重要性,因为从我个人的经历和我实际观察到的情况来看,这块的问题会更普遍一些,而这一部分又影响着后续一系列效率和稳定性平台的建设方案。

    同时,如果说上次我们讲的基础设施和应用标准化是运维团队职责的话,那今天的内容就是架构、开发和运维共同的职责。

    常见的分布式基础架构组件

    让我们先一起列一下,微服务的分布式架构下,涉及到的主要基础架构组件有哪些。

    • 分布式服务化框架 ,业界开源产品比如Dubbo、Spring Cloud这样的框架;
    • 分布式缓存及框架 ,业界如Redis、Memcache,框架如Codis和Redis Cluster;
    • 数据库及分布式数据库框架 ,这两者是密不可分的,数据库如MySQL,MariaDB等,中间件如淘宝TDDL(现在叫DRDS)、Sharding-JDBC等。当前非常火热的TiDB,就直接实现了分布式数据库的功能,不再额外选择中间件框架;
    • 分布式的消息中间件 ,业界如Kafka、RabbitMQ、ActiveMQ以及RocketMQ等;
    • 前端接入层部分 ,如四层负载LVS,七层负载Nginx或Apache,再比如硬件负载F5等。

    上面是几类主要的基础架构组件,为了便于理解我以开源产品举例。但在实际场景中,很多公司为了满足业务上的个性化需求,会自己研发一些基础组件,比如服务化框架、消息中间件等,这个情况在有一定技术实力的公司里比较常见。不过大部分情况下,我们会基于这些开源产品做一些封装或局部的改造,以适应我们的业务。

    基础架构组件的选型问题

    关于基础架构组件,业界可供我们选择的解决方案和产品是非常多的,但是选择多了就容易挑花眼,反而不知道从何入手。我们大概都会遇到同样的问题,是自研还是选择开源产品?有这么多的开源产品到底该选哪一个?

    按正常的思路,一定是先组织选型调研,然后进行方案验证和对比,最后确认统一的解决方案。

    但是,由于开源产品的便利性,以及开发同学对技术探索的好奇心,实际情况往往是,整个大的技术团队中,不同的开发团队,甚至不同的开发人员,会根据开发的需要或个人喜好,选择不同的开源产品,在没有严格限制的情况下,甚至会尝试去自研。

    按照我的观察, 这个问题特别容易出现在微服务架构引入初 期。在这个阶段,团队组织架构按照业务领域进行切分,产生一个个与业务架构匹配的小规模技术团队。每个小团队所负责的业务相对独立,自主权就会变大,如果这个时候整个团队中没有一个强有力的架构师角色去做端到端的约束,就极其容易出现上面的这个问题,并且会一直扩散蔓延下去。

    相比之下,成规模的大公司在这一点上做得就相对严格一些,当然也可能是因为之前尝过苦头,所以后来变得越来越规范了。所以这一点也是每个技术团队在引入微服务架构时要提前关注的。

    我们以分布式服务化框架为例,我之前遇到的一个实际情况就是,整个大的技术团队选型时以Java技术栈为主,毕竟这块有很多的业界经验和产品可以借鉴参考。但是有的团队对PHP特别精通熟悉,就想用PHP去做微服务,有的团队对Go感兴趣,就想尝试Go的微服务。

    从单纯的技术选型上来看,选择什么语言并没有严格的标准。而且在技术团队中,我们也应该鼓励技术多样性和尝试新技术。不过这里要有个度,我暂时先不细说这个度在哪里,我们先来看看,假设没有统一标准的约束会带来什么问题。

    技术的应用,一般都会随着应用场景的逐步深入和业务体量的增长,逐步暴露出各种各样的问题,我们分两个层面来看。


    展开全文
  • 网络安全从来都不只是漏洞,安全必须要融合企业的业务运营和管理,安全必须要进行体系化的建设。网络安全,任重而道远。 安全牛整合多位资深安全顾问的一线咨询经验,首次公开发布《网络安全体系方法论》,旨在给...
  • /导读/自动驾驶公司Aurora于2021年8月推出了有史以来第一个适用于自动驾驶卡车和乘用车的安全案例框架(Safety Case Framework)初始版本,解决了自动驾驶卡车和...
  • 其中以数据安全治理为核心的数据安全能力框架2.0和零信任身份安全解决方案动态细粒度访问控制能力和业务应用控制相结合,实现对数据流转的精准控制,做到主体的数字身份可信,行为操作合规以及计算环境和数据实体...
  • 公众号回复:干货,领取价值58元/套IT管理体系文档公众号回复:ITIL教材,领取最新ITIL4中文教材正文各行业许多企业都根据业务所需选择不同的国际、国内标准搭建了信息安全管理体系(IS...
  • 它们之间以及框架安全体系结构方法论之间存在很多困惑。这是我从网上收集到的那些主题的一些讨论,我相信在某些时候,这些澄清了我的一些困惑。 网络安全框架是基于风险的准则汇编,旨在帮助组织评估当前能力并...
  • 点击上方蓝字关注我们广东省数字政府网络安全评估体系与实践高尚省, 郭勇, 高智伟, 钟世敏, 刘丕群, 刘婷1 引言《2020联合国电子政务调查报告》显示,全球电子政务整体发展水平不断提升...
  • 物联网安全防护框架与评估模型

    千次阅读 2017-07-21 14:18:33
    原文链接:物联网安全防护框架与评估模型 物联网发展速度到底有多快?我们看看下面这张图就知道了。图中可以看到2008年是一个转折点:全球物联网设备数量超过了全球人口。相比于电力和电话,物联网的普及率是他们的...
  • 4.1 23种设计模式知识要点 单例模式 工厂模式 抽象工厂模式 模板方法模式 建造者模式 代理模式 原型模式 中介者模式 命令模式 责任链模式 4.2设计模式学习路线思维导图 5.美团面试官问的并发编程问题 Java中有几种...
  • 人员层面 PSC_09: 用户责任(角色) 车辆的HMI要清晰显示当前驾驶模式,驾驶员应该清晰驾驶职责; HMI设计(遵循ALKS法规) PSC_10: 驾驶员接管 驾驶员控制权优先; 驾驶员权限第一,控制器和执行器的仲裁设计; ...
  • 原标题:Linux多安全策略和动态安全策略框架模块代码分析报告(3)对于对象管理器,其用来对系统中的对象进行管理,因此其有责任定义一种机制来标记它所管理的对象,即主体和客体。当某个主体要访问某个客体时,此时...
  • 腾讯云凭借多年来在容器安全以及云原生安全领域的研究和实践运营经验,同时结合腾讯云容器平台 TKE 千万级核心规模容器集群治理经验,提出云原生容器安全体系框架,助力用户安全的实现云原生落地。 概述 容器作为...
  • 编辑 | 宋慧 供稿 | 山石网科 头图 | 蒋东毅在 ISC 2021...以零信任防控、智能威胁治理、数据生命周期安全治理三个框架为基础,以云端情报赋能,云端运营平台支撑,由安全运营团队提供全方位专业化安全运营,是山石网.
  • 本文原文《石油石化行业网络安全治理保障体系》刊登于《2021中国石油石化企业信息技术交流大会论文集》作者:王哲 徐春蕾 冀强 /北京知道创宇信息技术股份有限公司摘要:2021年是十四五规...
  • 数据安全能力成熟度模型----DSMM:规定了数据采集安全、数据传输安全、数据存储安全、数据处理安全、数据交换安全、数据销毁安全、通用安全的成熟度等级要求。 术语与定义: 1、数据安全:通过管理和技术措施,确保...
  • Java——主流开发框架

    2021-02-28 12:24:25
    Spring框架Spring框架是一个分层架构,由7个定义良好的模块组成。Spring框架构建在核心容器之上,核心容器定义了创建、配置和管理bean的方式,如下图所示:Spring框架的7个模块组成Spring框架的每个模块(或组件)都...
  • 全人教育、均衡发展课程体系介绍

    千次阅读 2020-12-30 16:33:24
    原标题:全人教育、均衡发展课程体系介绍一、《世界大百科之中国》全人教育均衡发展示意图 二、《世界大百科之中国》全人教育均衡发展课程简介 幼儿园课程是实现幼儿园教育的手段与目的,是帮助幼儿获得有益的学习...
  • 安全架构的设计

    千次阅读 2021-03-17 14:27:02
    安全职责划分-共同担责 软件即服务SAAS 云服务厂家几乎负责所有的安全性,因为租户只能访问、管理和使用其提供的应用程序,但无法对应用程序做破坏性操作。例如:SAAS服务厂家提供安全、日志、运维、审计、应用...
  • 数据治理系列1:数据治理框架【解读分析】

    万次阅读 多人点赞 2019-05-08 14:58:56
    有效的数据治理计划会通过改进决策、缩减成本、降低风险和提高安全合规等方式,将价值回馈于业务,并最终体现为增加收入和利润。 笔者认为:所有为提高数据质量而展开的业务、技术和管理活动都属于数据治理范畴。...
  • 什么是网络安全等级保护

    千次阅读 2021-09-19 21:24:14
    一、等级保护体系设计的主要工作要求 等级保护体系设计的主要工作要求包括: (1)等级保护体系设计应包含技术和管理两方面的内容;...2021最新整理网络安全/渗透测试/安全学习/100份src技术文档(全套视频、大厂面经
  • ( ) 咽鼓管的主要生理作用是 4 ~5岁儿童学习科学的特点 (5.0分) 4 ~5岁儿童学习科学的特点 (5.0分) 15、一个”对齐上缘”类型的框架,应该包括_______个HTML文件 唐代陆羽《茶经》的问世 , 是茶文化 ( ) 的重要标志。...
  • 数据中台通用体系架构包含数据存储框架、数据采集框架、数据处理框架、数据治理框架、数据安全框架及数据运营框架等 6 大部分。 1、数据存储框架 数据中台的核心是数据,数据通过采集系统获取,然后数据经过处理框架...
  • 看来看去觉得未来安全上能有比较大作为的还是Azure,根本原因有很多,包括Azure Active Directory的身份联动、安全产品的丰富度、Office远程办公安全、ToB的安全基因、安全研发SDL体系等。回归本着能改变云安全,为...
  • 公众号回复:干货,领取价值58元/套IT管理体系文档公众号回复:ITIL教材,领取最新ITIL4中文教材正文昨天对刚发布的数据安全法进行了图解说明,由于小部分内容不够精准今天更新一个更精准...
  • DGI数据治理框架 全面解读

    千次阅读 2021-03-18 21:20:14
    在上一篇《DGI数据治理框架介绍 全文翻译》中有朋友反应说这个治理框架的确很实用,但是英文翻译过来的内容读起来有点费劲,希望谈数据能通俗的解读一下,于是就有了这篇。 01 DGI组织介绍 数据治理研究所...
  • 4.1 23种设计模式知识要点 单例模式 工厂模式 抽象工厂模式 模板方法模式 建造者模式 代理模式 原型模式 中介者模式 命令模式 责任链模式 4.2设计模式学习路线思维导图 5.美团面试官问的并发编程问题 Java中有几种...
  • 可以说,一个框架是一个可复用的设计构件,它规定了应用的体系结构,阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程,表现为一组抽象类以及其实例之间协作的方法,它为构件复用提

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 29,213
精华内容 11,685
关键字:

安全责任体系框架

友情链接: CustomDataGridDemo.rar