谈谈双活业务中心和异地容灾备份设计 安全闲碎

谈谈双活业务中心和异地容灾备份设计

今天谈下多数据中心和异地容灾备份方面的内容。在前面一篇文章里面我详细谈到过一个软件业务系统的高可用性设计,其中既包括了IT基础设施的高可用,也包括了业务软件系统设计方面的高可用性设计。对于高可用,我想再简单总结下,核心为三个方面的内容:高可靠:冗余性设计,无任何单点故障高性能:能够满足大数据量或海量并发访问下响应需求高扩展:能够动态水平弹性扩展 对于三者之间的关系,我前面整理过下面一个图来进一步说明:上图可以看到高可靠,高性能和高扩展性三者之间的关系。对于高可靠性来来说,传统的HA架构,冗余设计都可以满足高可靠性要求,但是并不代表系统具备了高性能和可扩展性能力。反过来说,当系统具备了高扩展性的时候,一般我们在设计扩展性的时候都会考虑到同时兼顾冗余和高可靠,比如我们常说的集群技术。对于高性能和高扩展性两点来说,高扩展性是高性能的必要条件,但是并不是充分条件。一个业务系统的高性能不是简单的具备扩展能力就可以,而是需要业务系统本身软件架构设计,代码编写各方面都满足高性能设计要求。对于高可靠和高性能,两者反而表现出来一种相互制约的关系,即在高性能支撑的状态下,往往是对系统的高可靠性形成严峻挑战,也正是这个原因我们会看到类似限流熔断,SLA服务降级等各种措施来控制异常状态下的大并发访问和调用。容灾备份概述前面谈高可靠性可以看到,我们更多的还是谈的在一个数据中心里面的冗余和集群设计,以确保整个IT基础设施架构没有任何的单点故障。但是如果整个数据中心都出现问题,那么我们的应用自然会受到影响处于不可用状态,同时我们的数据存储也存在丢失的问题。这也是我们谈容灾备份,很多大的集团企业建设自己的两地三中心的一个原因。什么是容灾备份?对于容灾,简单来说就是当数据中心发生各种未知灾难的时候,能够确保数据不丢失或少丢失,同时IT业务系统能够不间断运行或快速切换恢复。这里面实际上强调了两个重点, 即:数据本身不丢失或少丢失应用本身不间断或少间断整个容灾设计就是围绕这两个关键目标来实现。而对于容灾备份则是通过在异地建立和维护一个备份存储系统,利用地理上的分离来保证系统和数据对灾难性事件的抵御能力。根据容灾系统对灾难的抵抗程度,可分为数据容灾和应用容灾 。数据容灾是指建立一个异地的数据系统应用容灾比数据容灾层次更高,即在异地建立一套完整的、与本地系统相当的备份系统当前可以看到,我们更多的已经不再是间断的数据层面的容灾备份,而是需要具备保持业务连续性的应用级容灾能力。简单来说,就是我们需要设计要整体应用所涉及到的IT基础设施,数据库,应用中间件和应用部署包全部在2个数据中心进行部署。部署完成的架构需要确保即使某一个数据中心完全瘫痪,也不应该影响到业务系统的正常运行和连续性。对于容灾等级的定义可以参考下图:从图中可以看到,如果要实现业务系统本身的异地双活和不间断运行,那么就必须达到第七级的异地同步应用容灾的标准。即是:在异地建立一个与生产系统完全相同的备用系统,他们之间采用同步的方式进行数据复制。当生产中心发生灾难时,备用系统接替其工作。该级别的容灾,在发生灾难时,可以基本保证数据零丢失和业务的连续性。也正因为如此,我们看到,多数据中心之间的数据库同步复制能力将是构建一个异地同步容灾备份设计的关键内容。数据库同步复制技术前面已经谈到,要实现应用级的容灾备份,一个关键就是通过数据库的实时同步和复制,在A地出现机房故障和问题的时候可以平滑快速的迁移到B地。虽然这种远程数据复制和同步存在一定的延迟,但是基本已经可以满足业务连续性的需求。谈到数据库的实时复制,一般会谈到一个重要产品,即Oracle公司的GoldenGate,该软件是一种基于日志的结构化数据复制软件,它通过解析源数据库在线日志或归档日志获得数据的增删改变化,再将这些变化应用到目标数据库,实现源数据库与目标数据库同步、双活。GoldenGate可以在异构的IT基础结构(包括几乎所有常用操作系统平台和数据库平台)之间实现大量数据亚秒一级的实时复制。GoldenGate是一种基于软件的数据复制方式,它从数据库的日志解析数据的变化(数据量只有日志的四分之一左右)。该将数据变化转化为自己的格式,直接通过TCP/IP网络传输,无需依赖于数据库自身的传递方式,而且可以通过高达9:1的压缩率对数据进行压缩,可以大大降低带宽需求。在目标端,GoldenGate TDM可以通过交易重组,分批加载等技术手段大大加快数据投递的速度和效率,降低目标系统的资源占用,可以在亚秒级实现大量数据的复制。GoldenGate的工作原理可以用下图描述:在任何实时数据同步和复制中,需要考虑如下几个关键问题:事务一致性:在复制目标端需要按照源端相同的事务环境进行,确保目标上数据一致性。检查点机制:在抽取和装载时都需要记录检查点,确保网络故障下仍然能够完整复制。可靠数据传输:需要保证数据传输的完整性,请求和应答,同时提供数据加密压缩。对于数据实时同步和复制工具,其核心是需要基于日志来实现,这一方面是可以实现准实时的数据同步,一方面是基于日志实现不会要求数据库本身在设计和实现中带来任何额外的约束。我们也看到有些基于数据库表设计增加触发器或存储过程来实现的数据库复制,这些本身都是损耗了性能和增加了复杂度。对于数据库的实时同步和复制,阿里巴巴专门有一个开源项目,即otter来实现分布式数据库的同步复制,其核心思想仍然是通过获取数据库的增量数据日志,来进行准实时的同步复制。因此otter本身又依赖于另外一个开源项目即canal,该项目重点则是获取增量数据库同步日志信息。当前otter的重点是实现mysql间的数据库同步复制,其实这个在前面我一些文档里面谈到基于mysql数据库的dual-master架构的时候已经谈到过,基本即利用的类似技术来实现两个mysql数据库间的双向同步数据库复制。要注意这个双向本身指既可以A->B,也可以从B->A,在某个时间节点本身是单向的。对于otter的功能和支持的数据库比GoldenGate要少得多,除了支持mysql数据库间的实时数据同步和复制外,还支持mysql->oracle的单向数据同步和复制。但是不支持oracle->mysql的数据同步和复制。但是otter本身提供了一个很好的开源框架,我们可以基于该框架扩展对其它数据库的支持。在扩展的时候有一个重点,即数据库本身是否提供了增量数据日志,对于mysql数据库容易实现其主要原因还是mysql数据库提供了相当方便的binlog日志功能,这些log日志本身就很方便的转换为朝目标端执行的sql语句。而对于常见的数据库,在网上搜索下,可以看到一些做法。对于oracle,重点是监控oracle的redo log,即在线重做日志和归档日志。对于一些商用产品可以直接监控到redo log,仅仅依赖于该文件而不耗费其它资源。而如果我们来实现,则常用的方法还是基于oracle logminer来对redo log进行解析。虽然性能上稍微有差异,但是基本可以达到准实时的数据库解析和同步。对于Sql Server数据库的日志分析,首先可以看到网上有一个专门的商业工具,即log explorer,这个工具可以用来做sql server数据库的日志解析和分析。其中对于事务,检查点等都有详细的记录。其次可以使用fn_dblog解析Sql Server的数据库日志,网上有专门的方法在这里不展开,现在还没有具体测试过,但是整个方法思路是没有问题的。而对于sql server 之间的数据库同步和复制,则sql server本身就提供有方便的基于快照或基于事务的数据库同步复制工具,只需要经过简单的配置即可以实现。正因为这个原因,我们也看到,对于sql server数据库本身在日志解析和分析方面开放出来的能力本身是相当较弱的。随着国家对自主研发数据库和中间件技术的大力支持,当前还没一个能够实现国产数据库如人大金仓,达梦数据库同国外的oracle ,sql server数据库间的数据实时同步和复制工具。对于这类工具是可以基于开源otter产品的思路来进行定制开发和实现的,但是前提还是各个数据库厂家需要开放相应的日志采集和处理能力。基于GoldenGate实现数据库同步复制GoldenGate TDM(交易数据管理)软件是一种基于日志的结构化数据复制软件,它通过解析源数据库在线日志或归档日志获得数据的增删改变化,再将这些变化应用到目标数据库,实现源数据库与目标数据库同步、双活。GoldenGate TDM 软件可以在异构的IT基础结构(包括几乎所有常用操作系统平台和数据库平台)之间实现大量数据亚秒一级的实时复制,其复制过程简图如下:GoldenGate TDM的数据复制过程如下:利用捕捉进程(Capture Process)在源系统端读取Online Redo Log或Archive Log,然后进行解析,只提取其中数据的变化如增、删、改操作,并将相关信息转换为GoldenGate TDM自定义的中间格式存放在队列文件中。再利用传送进程将队列文件通过TCP/IP传送到目标系统。捕捉进程在每次读完log中的数据变化并在数据传送到目标系统后,会写检查点,记录当前完成捕捉的log位置,检查点的存在可以使捕捉进程在终止并恢复后可从检查点位置继续复制;目标系统接受数据变化并缓存到GoldenGate TDM队列当中,队列为一系列临时存储数据变化的文件,等待投递进程读取数据;GoldenGate TDM投递进程从队列中读取数据变化并创建对应的SQL语句,通过数据库的本地接口执行,提交到数据库成功后更新自己的检查点,记录已经完成复制的位置,数据的复制过程最终完成。由此可见,GoldenGate TDM是一种基于软件的数据复制方式,它从数据库的日志解析数据的变化(数据量只有日志的四分之一左右)。GoldenGate TDM将数据变化转化为自己的格式,直接通过TCP/IP网络传输,无需依赖于数据库自身的传递方式,而且可以通过高达9:1的压缩率对数据进行压缩,可以大大降低带宽需求。在目标端,GoldenGate TDM可以通过交易重组,分批加载等技术手段大大加快数据投递的速度和效率,降低目标系统的资源占用,可以在亚秒级实现大量数据的复制,并且目标端数据库是活动的GoldenGate TDM提供了灵活的应用方案,基于其先进、灵活的技术架构可以根据用户需求组成各种拓扑结构,如图所示:GoldenGate TDM 可以提供可靠的数据复制,主要体现在下面三点:保证事务一致性GoldenGate TDM 在灾备数据库应用复制数据库交易的顺序与在生产中心数据库上的顺序相同,并且按照相同的事务环境提交,确保在目标系统上数据的完整性和读一致性,为实时查询和事务处理创造了条件。检查点机制保障数据无丢失GoldenGate TDM的抽取和复制进程使用检查点机制记录完成复制的位置。对于抽取进程,其检查点记录当前已经抽取日志的位置和写队列文件的位置;对于投递进程,其检查点记录当前读取队列文件的位置。检查点机制可以保证在系统、网络或GoldenGate TDM进程故障重启后数据无丢失。可靠的数据传输机制GoldenGate TDM 用应答机制传输交易数据,只有在得到确认消息后才认为数据传输完成,否则将自动重新传输数据,从而保证了抽取出的所有数据都能发送到备份端。数据传输过程中支持128位加密和数据压缩功能。Oracle 公司的GoldenGate产品,可以在异构的IT基础结构之间实现大量数据的秒一级的数据捕捉、转换和投递。GoldenGate可以支持几乎所有常用操作系统如和数据库平台:操作系统支持:MS NT, 2000, XP, Linux, Sun Solaris, HP-UX, IBM AIX, HP NonStop, TRU64, IBM z/OS,OS/390 数据库支持:Oracle, DB2, MS SQL Server, MySQL, Enscribe, SQL/MP, SQL/MX, Sybase, Teradata, 其他ODBC 兼容数据库GoldenGate的应用场景-容灾和应急备份其中一主一备,快速恢复和切换,最小化数据损失,重新同步主备两端数据。主库数据变化能够实时的同步到备库,用途主要是在非计划性停机时候保持业务的连续性。GoldenGate的应用场景-减少计划内停机主要是保障业务零或近似零停机,在滚动升级中降低业务中断带来的损失。主要用途是保障系统/应用/数据库在升级,移植和维护期间业务的可用性。GoldenGate的应用场景-双业务中心主要是实现负载均衡(需要考虑全局多点的负载均衡,既提高性能,又避免业务中心的整体单点故障),提供系统整体性能。保障连续可用,快递的容灾接管,实现冲突的监测和处理。业务系统数据库双活和主备设计首先我们还是回顾下业务系统容灾备份设计的目标究竟是什么?简单来讲就是要避免在单个数据中心出现无预知灾难的时候,整个数据不丢失,整个应用仍然能够正常持续运行。而对于持续不间断运行,我们仍然可以分为两个层面。完全不间断,自动实现切换,对业务无感知短暂间断,需要人工手工切换负载均衡或IP地址完成对于生产运营类的企业IT系统需要做到完全不间断,而对于内部管理类的信息系统往往做到短暂间断也可以接受。比如我们常说的电信运营商的BSS域系统,那么就需要做到完全不间断自动切换,而对于MSS域围绕ERP管理系统等,能在30分钟内完成切换调整就可以满足需求。对于一个双业务中心的设计,可以看到里面有两个重点,一个就是数据库本身的双活设计,还有一个就是应用服务器集群本身的双活设计。数据库双活或主备设计对于数据库本身的技术种类,对双活读写的支持,数据延迟的大小,可靠性等可以参考上图进一步了解。在考虑双活数据库设计的时候可以重点参考。对于双业务中心和异地双活设计,前面我很多文章都已经谈到过,实际上最难的就是数据库如何保证双活,大部分的异地容灾方案数据库本身都是单活的,一个作为备份库。对于数据库双活和主备设计,实际上在数据库层面分为三个层面。数据库单活:一个做为备份库,平时不工作,在出现问题再动态切换数据库写单活,读双活:只有主库可以写,但是两个数据中心数据可以同时读数据库双活:即表格里面谈到的Oracle ASM Extended RAC方案,这个没怎么接触过对于应用服务器的Cluster集群,实际要做到双活就比较简单,由于不存在数据持久化的问题,因此只需要搭配上层的全局负载均衡往往就容易实现上层应用服务器集群的双活配置。方式1:通过GoldenGate来实现数据库单活设计对于GoldenGate既支持数据单向复制,也支持数据库双向同步复制。我们可以通过数据库单向复制来实现数据库的主备模式双活,即一个作为Master主节点数据库,一个作为Standby的备库。如下:当主库出现无法预知的灾难故障的时候,我们可以将访问切换到备库节点上,在主库节点恢复后备库节点重新返回备库模式,前端访问用户也重新连回到主库节点。也就是说在主库恢复后,实际上还有一个过程即:备库上所做出的修改和更新需要实时同步更新回主库。因此虽然说这种模式是数据库单向复制,实际上是指在某一个时点只允许一个方向的数据流。而不是说数据只能够从主节点朝备节点同步。方式2:通过GoldenGate来实现数据库双活设计对于数据库双活设计即可以采用GoldenGate数据库双向同步复制来实现。实际上我们并不建议这种方式,主要是以下几个方面的考虑。即在数据双向复制的情况下对应用系统本身的设计会有额外的要求,比如全局序列号的起始值的规划,如何防止数据循环复制,如果网络存在延迟,如何确保一个大的业务操作实时的数据一致性要求等。这些往往都是双活数据库本身存在的问题。其次,在数据库双活设计下,应用集群和数据库间往往存在两种方式如下:对于方式1即应用集群只固定访问同数据中心的数据库,对于方式2即应用集群全部访问上层两个数据库暴露的VIP地址,通过VIP来确定访问两个数据库。对于方式1我们看到,实际上在数据库中心A的数据库宕机后,由于应用集群可能没有宕机,那么全局负载均衡仍然会分发路由请求给应用集群A,这个时候实际仍然出现访问中断的情况。而对于方式2采用了数据库VIP后,虽然解决了上面的问题,但是很容易出现应用集群A要跨域访问到数据库中心B的数据库服务的情况。也就是在采用浮动VIP时候,希望是要做到应用集群A优先访问数据库A,只有当数据库A出现故障的时候才路由访问数据库B。方式3:不采用GoldenGate的思路如果不采用GoldenGate,那么我们就需要手工去处理以保证两个数据库间的数据同步复制。在我们实施ESB服务总线项目的时候,由于数据库实例本身无状态和一致性要求,因此我们完全可以采用晚上定时进行数据库增量脚本同步的方式来同步数据。其次,对于修改元数据的相关操作,则需要应用程序同时在两个数据中心的数据库同时进行操作,这个同时操作也可以通过应用自动实现,也可以人工同时操作,毕竟对元数据配置修改往往本身就是低频操作。全局负载均衡和智能DNS路由当我们谈双活数据中心的时候,前面更多谈的数据库的部署和同步方案,既然是双活,那么APP Server应用服务器就必须要做到能够同时工作。而对于应用服务器集群我们考虑的时候要注意,实际上在我们配置的时候,数据中心A和数据中心B两个集群都是操作数据中心A的数据库,否则就会出现数据库双向同步复制问题。要做到应用集群双活,在前面文章方案已经谈到,必须在数据库中心A和B上面还有一个全局的负载均衡设备进行全局负载均衡,同时全局负载均衡设备本身还需要HA配置确保无单点故障。对于最终用户的访问,我们企业DNS域名进行访问。同时在两个数据中心配置智能DNS设备,本身进行HA架构冗余设计,如下。智能DNS设备实际上要完成的事情很简单,就是用户通过域名访问,智能DNS能够返回具体某个数据中心的上层负载均衡IP地址信息。我们以单活架构来进行说明如下:用户通过域名访问,将请求发送给智能DNS解析设备智能DNS在主数据中心正常情况下返回主数据中心的负载均衡IP地址在获取到IP地址后,应用再发起对主数据中心的实际业务访问如果主数据中心本身出现灾难宕机。那么这个时候请问到DNS的时候则返回数据中心B的负载均衡IP地址信息。这个时候备库数据库自动变化为主库承担应用的读写任务。应用集群本身的Admin设置和应用部署对于应用服务器集群,往往会有一个Admin集群管理节点,通过Admin可以实现对应用集群内所有节点的状态监控,应用的部署,负载均衡等相关操作。即使我们采用了类似F5等负载均衡设备,往往集群仍然需要设置管理节点以方便集群监控和应用程序的部署。那么在启用双数据中心后可以看到,对于Admin节点建议仍然是在两个数据中心各自一套,即应用程序的更新和部署仍然在两个数据中心各自手工部署来完成。特别是在主备模式下,这种手工方式处理基本没有任何影响。但是如果在双活架构模式下,如果手工完成往往就存在一定的延迟性的问题。这个实际又有两种解决方案和思路。其一是通过一个Admin来管理两个数据库的所有集群节点其二是通过灰度发布策略等方法来控制部署时间上的延后对于第一种方式实际我们不建议,其本身增加了了两个数据中心集群的耦合度,同时本身管理的复杂度,集群本身的状态一致性保证复杂度都会增加。最好的方式仍然是通过灰度发布等策略控制来解决该问题。作者:人月神话  https://www.toutiao.com/i6874741202076303883/ 本文始发于微信公众号(释然IT杂谈):谈谈双活业务中心和异地容灾备份设计
阅读全文
原创 | 工控系统的“一个中心” 云安全

原创 | 工控系统的“一个中心”

作者 | 绿盟科技格物实验室 任心 [email protected]引言在信息技术高速发展的今天,网络技术不断的应用到工业控制系统中,利用网络技术改进了企业产品全生命周期的各个环节,淘汰落后的生产能力,提升企业核心自主创新能力。享受两化融合带来的效能与效益之余,保障企业工业控制系统中的网络安全成了企业所关注的焦点。鉴于安全形势,国家发布了《信息安全技术 网络安全等级保护基本要求》,新变革针对共性安全保护需求提出安全通用要求;针对云计算、移动互联、物联网、工业控制系统和大数据等新技术、新应用的保护需求提出安全扩展要求,形成新的网络安全等级保护标准,确保关键信息基础设施安全,强化了安全管理中心的概念,明确安全管理中心在系统网络架构上的独立地位,对管理传输链路通信安全性提出要求,同时要求具备对网络安全事件的分析和告警能力。那么安全管理中心在企业工业控制系统中是否能起到应有的作用?本文就说一说我们在企业工业控制系统中发现安全管理中心存在的问题。工控系统层级模型要想了解“一个中心”,首先要对工业控制系统层次模型有个基本概念。参考:IEC 62264-1的层次结构模型划分。L4企业资源层:主要包括ERP系统功能单元,用于为企业决策层员工提供决策运行手段。L3生产管理层:主要包括MES系统功能单元,用于对生产过程进行管理,如制造数据管理、生产调度管理等。L2过程监控层:主要包括监控服务器与HMI系统功能单元,用于对生产过程数据进行采集与监控,并利用HMI系统实现人机交互。L1现场控制层:主要包括各类控制器单元,如PLC、DCS控制单元等,用于对各执行设备进行控制。L0现场设备层:主要包括各类过程传感设备与执行设备单元,用于对生产过程进行感知与操作。“一个中心”是什么?工业控制系统根据被保护对象业务性质分区,针对功能层次技术特点实施信息安全等级保护设计,根据“一个中心”管理下的“三重防护”体系框架,“一个中心”就是安全管理中心,也就是构建在安全管理中心支持下的安全通信网络、安全区域边界、安全计算环境三重防御体系。安全管理中心的要求安全管理中心名称虽然看着像管理,但实际为技术部分。在《信息安全技术 网络安全等级保护基本要求》中主要要求包括系统管理、审计管理、安全管理和集中管控四个控制点。1) 系统管理要求:a) 应对系统管理员进行身份鉴别,只允许其通过特定的命令或操作界面进行系统管理操作,并对这些操作进行审计。b) 应通过系统管理员对系统的资源和运行进行配置、控制和管理,包括用户身份、系统资源配置、系统加载和启动、系统运行的异常处理、数据和设备的备份与恢复等。2) 审计管理要求:a) 应对审计管理员进行身份鉴别,只允许其通过特定的命令或操作界面进行安全审计操作,并对这些操作进行审计。b) 应通过审计管理员对审计记录应进行分析,并根据分析结果进行处理,包括根据安全审计策略对审计记录进行存储、管理和查询等。3) 安全管理要求a) 应对安全管理员进行身份鉴别,只允许其通过特定的命令或操作界面进行安全管理操作,并对这些操作进行审计。b) 应通过安全管理员对系统中的安全策略进行配置,包括安全参数的设置,主体、客体进行统一安全标记,对主体进行授权,配置可信验证策略等。4) 集中管控要求:a) 应能够建立一条安全的信息传输路径,对网络中的安全设备或安全组件进行管理。b) 应对网络链路、安全设备、网络设备和服务器等的运行状况进行集中监测。c) 应对分散在各个设备上的审计数据进行收集汇总和集中分析,并保证审计记录的留存时间符合法律法规要求。d) 应对安全策略、恶意代码、补丁升级等安全相关事项进行集中管理。e) 应能对网络中发生的各类安全事件进行识别、报警和分析。f) 应保证系统范围内的时间由唯一确定的时钟产生,以保证各种数据的管理和分析在时间上的一致性。为什么管?“一个中心,三重防护”的体系架构,目的是让工控系统通过安全策略建立边界防护体系,事前未雨绸缪;通过安全机制建立动态监控体系,事中风雨同舟;通过查处震慑建立信用体系,事后秋后算账。最后通过安全管理中心使整体具备安全运维、应急响应的能力,保证系统安全机制始终可管。管什么?由下图可见,安全管理中心应与第0-3层,也就是工控系统中所有参与通信的网络设备相连接。安全管理中心可以把分散的安全设备、安全策略、安全事件、安全风险、安全运维和系统中产生的日志集中统一的管理和运营起来。怎么管?要符合安全管理中心相应要求,通常要使用但不局限于以下安全产品。运维审计类产品:建立面向用户的集中、有序、主动的运维安全管控平台,通过基于唯一身份标识的集中账号与访问控制策略,与各服务器、网络设备等无缝连接。知道什么人,在什么时间,登录了什么设备,做了什么事情,实现集中精细化运维操作管控与审计。日志审计类产品:采集不同厂商的网络设备、主机、操作系统以及各种应用系统产生的日志信息,实现对工控系统整体安全状况的全面审计。集中管理类产品:对工控系统中的工业防火墙、安全审计、入侵检测、终端卫士等设备进行统一管理、配置、授权和响应。对安全设备的策略和安全事件进行集中、有效的管理。存在什么问题?通过上述描述相信大家也认识到了,安全通信网络、安全区域边界、安全计算环境覆盖工控系统的各层级。安全管理中心要服务于工控系统的各层级,网络的连通是必备条件,所以规划时多数会将安全管理中心放在生产管理层。工控系统中由于厂家、协议的繁杂,生产数据在L2(过程监控层)、L3(生产管理层)、L4(企业资源层)传递时多数在层级之间使用接口机。接口机也称为Buffer机,接口机通过与OPC服务器进行通讯,采集生产数据,起着数据缓冲、数据格式转换等作用。接口机通常采用多网卡收发数据,各层在数据传递时,网络路由是不可达的,这就导致了安全管理中心无法连接到接口机的另一侧网络,看不到想看的数据,管不到想管的设备,安全管理中心不能起到作用,那无疑会大大提高企业安全运维的成本。这直接导致企业只买不用,将安全产品堆在角落,沦落为应付合规性检查的工具。下面就简单列举一下我们实际发现的一些问题。问题1在我们调查的企业中,大多数企业往往因为担心破坏工控系统的稳定性,或因预算不足等原因不去建设安全专网,如果操作站安装日志采集代理、终端安全防护软件,是无法将日志、安全事件上传到安全管理中心的。这会使工控系统中所有安全组件各自为政。问题2还以这张图为例,可以看到虽然建设了安全专网,但若要管理操作站,只能将工控系统与安全专网连通,这样虽然可以统一管理,但会使安全管理中心变的不安全,我们还没有见到过将工控系统直接与安全专网打通的企业。问题3少数建设安全专网的企业中,安全专网打通了工控系统的各层网络,却没有按照工控安全框架对安全专网进行边界隔离,导致了新的安全问题出现,攻击者可通过安全专网进入安全管理中心,使攻击者更加容易的入侵工控系统。问题4很多企业在工控安全建设时,不会一步到位的去建设安全体系,会根据实际情况分期建设。由于每个厂家的安全产品接口不共享,自家产品只支持自家平台管理,如果后续建设中选用的安全产品与之前厂家不一样,会出现无法统一管理的问题。使用相同厂家安全产品,虽然可以统一管理,但会存在相同的编码问题,相同的通用组件等,这些问题会极大降低攻击者的攻击成本。解决思路要想安全管理中心起到作用,这些问题是当前阶段需要解决的,我们提出了一些解决思路。1、建立安全专网,这是毋庸置疑的。安全专网的架构需要与原有工控系统网络架构一样,在安全管理中心边界为之部署下一代防火墙,之所以不使用工业防火墙,因为工业防火墙设计更偏向于工业场景、工业协议,而安全专网中不存在工业协议,下一代防火墙更加适用在安全专网中。2、在工控系统中都应选择具备独立管理网口的安全产品,使业务与管理分离,互不干扰。3、对于安全管理中心无法管理,网络路由不可达的区域,建立安全专网组网,然后通过多级部署的方式进行管理,双网卡分别连接工控系统与安全专网,类似接口机方式,这样分离工控系统与安全专网,也可提高安全管理中心的安全性。4、尽可能选择不同厂家的安全产品,使部署在工控系统中的安全产品差异化。工控安全厂家应开放接口建立行业统一标准,使不同厂家的安全产品可以在一个平台上统一管理。5、要有专用的安全运维计算机,用于运维人员对安全管理中心的维护。也要对安全管理中心的所有产品进行安全加固,如设置复杂的登录密码,取消超级权限用户,满足三权分立要求。设置访问策略,只允许安全运维计算机访问安全产品等。总结在《信息安全技术 网络安全等级保护基本要求》中,已经要求安全管理中心建立一条安全的信息传输路径,对网络中的安全设备或安全组件进行管理。但工控系统网络结构复杂,节点较多,搭建一条真正安全的专网并不是一个简单的事情。安全管理中心是安全的大脑,但在企业眼里重视程度远不如边界安全、终端安全重要,这是一个值得思考的问题。工控安全已经从无到有,从有到优,如何从优到强,建立完善的安全管理中心,是当前阶段需要解决的问题。转载请注明来源:网络安全应急技术国家工程实验室 本文始发于微信公众号(网络安全应急技术国家工程实验室):原创 | 工控系统的“一个中心”
阅读全文
密码大兴峰会 | 白小勇:以数据为中心的实战化密码防护 云安全

密码大兴峰会 | 白小勇:以数据为中心的实战化密码防护

4月20日,由北京市大兴区人民政府、中国电子学会指导,信息安全与通信保密杂志社、中关村中安高速密码产业联盟(筹)联合主办,国家新媒体产业基地、炼石网络、数盾科技、三未信安、渔翁、数观天下、商密在线承办,主题为“因密而安”的密码行业盛会“2021密码大兴峰会”,在北京国家新媒体产业基地举行,中关村中安高速密码产业联盟筹备启动仪式在会上召开,炼石作为联盟成员单位参与了联盟筹备启动盛典,并荣获“2020年度商密产业十强优秀企业”。本次峰会将围绕《密码法》的宣传普及,聚焦密码技术、密码产品与服务、密码应用市场及未来前景,汇集监管部门、专家学者、企业精英及产业同行,问诊密码行业问题和解决方案,共话密码产业成果和未来,致力建设密码行业产业链交流融合的平台,推动密码产业向更好、更快、更健康的方向发展。炼石网络CEO白小勇受邀参会并发表了主题演讲,从业务与数据的角度,探索实战化的数据安全防护体系,并分析了密码在新数据安全的广阔应用前景。(关注本公众号,了解更多密码及数据安全行业前沿思想和技术)本文共计2970字,预计阅读时间6分钟01从业务视角看数据安全边界传统认为,安全和业务是关联的,有时候对立。但换个角度,安全其实就是一种业务需求。“传统业务需求”侧重于“希望发生什么”,而“安全需求”则侧重于“不希望发生什么”,从而确保“发生什么”。“安全”在英文中对应Security(安全防攻击)、Safety(安全可靠)、Reliability(可靠性)、Trustiness(诚信度)、Sureness(确定性)等词汇,从业务角度来看,这些词汇都可以映射到相应的业务需求。从业务角度重新思考安全,安全产品的意义就是在“某个业务”中实现了“不希望发生什么”。数据这种新型生产要素,是实现业务价值的主要载体,数据只有在流动中才能体现价值,所以数据安全保护对象是有价值的数据。从业务视角出发,数据安全需求重点是数据的机密性和完整性。凡是有数据流转的业务场景,都会有数据安全的需求产生。结合到企业或机构的信息系统中,数据安全则来自于业务处理中的风险映射。从时间维度看,数据在流转的全生命周期中的每个环节都会有相应的安全需求;从空间维度看,数据在基础设施层、平台层以及应用层之间流转,不同层次会有不同颗粒度的防护需求。我们认为,数据安全的边界取决于业务边界,而企业真实的业务需求非常复杂,很难框定边界,因此对应的数据安全也几乎没有边界。所以在实施数据安全防护的时候,数据安全需要结合具体业务展开,很难有“一招鲜”的数据安全解决方案。02面向业务构建以数据为中心的防护体系传统的城防式数据安全,主要是保护被传统物理网络多层包围的数据,这种防护体系仅适用于保护静态数据。但当下,数据已成为新生产要素,数据被充分共享流转以产生价值,传统城防式数据安全已经难以满足需求。我们认为,数据与“网络/主机/数据库/应用”是正交关系,数据安全的本质就是在数据流转的多个层次环节中,通过重建业务规则,对数据施加主动式安全防护。针对数据进行安全防护的技术,我们先回顾经典网络安全攻击模型:ATT&CK是当前权威的网络安全技术模型,包括14个攻击战术、205个攻击技术以及573个攻击流程,覆盖了大多数网络攻击手段,从而给网络安全防护提供专业的技术参考。但是,ATT&CK模型更侧重网络攻防视角,从“主动式保护数据”的角度看,这个模型不太适用,比如ATT&CK没有针对内部业务人员威胁,也没有将数据进行分级分类等。在基于ATT&CK模型的攻防对抗思路下,传统“以网络为中心的安全”主要通过“防漏洞、堵漏洞”的方式去保护数据,而当下来看,网络漏洞在所难免,因此直接针对数据本身进行主动式加密等保护,是实现数据安全的最直接有效的手段。信息安全技术发展的大趋势也正从“以网络为中心的安全”转向为如今的“侧重以数据为中心的安全”,美国国防部也对这种理念非常认可并把防护重点从边界开始转向数据和服务。依据这个新思路,我们尝试从“以数据为中心”的角度提出新的数据安全技术框架,全称是:“Data-centric Tactics, Techniques And Common Knowledge”(简称DTTACK),“以数据为中心的战术、技术和通用知识”。DTTACK不是网络服务器或应用程序安全性的模型,它更强调数据本身的安全性,并从对数据的应对式防护,向主动式防护转变,重视从业务风险映射视角列举数据保护需求,也可以为信息化建设、企业业务架构设计提供数据安全能力参考。白小勇表示,我们团队在这方面进行过深入思考,结合了NIST安全能力模型和安全滑动标尺模型,发现这两者有交集、但也各有侧重。DTTACK当前版本选择了六大战术作为基本结构:IDENTIFY(识别)、PROTECT(防护)、DETECT(检测)、RESPOND(响应)、RECOVER(恢复)、COUNTER(反制)。数据安全技术列举方面,参考了工信部相关机构正在编制的行业标准《电信网和互联网数据安全管控平台技术要求和测试方法》,将114个具体技术流程分类并对号入座。我们期望DTTACK能够成为数据安全领域的专业权威技术框架,能给数据安全厂商提供通用知识库,也能为甲方用户的数据安全规划和技术对比提供参考依据。03以密码技术为核心的数据安全实战化密码技术为DTTACK六大战术提供了重要价值。比如:识别方面,密码可以为数据识别提供身份安全能力,为接口通道实现安全加密;防护方面,数据加密技术本身就是在开放式信道中,构建了强制的防护措施,并结合身份实现访问控制。检测、响应、恢复和反制方面,密码也能够为其分别提供身份鉴别、数据保护、水印追溯等不同能力。尤其对于流转数据防护,密码技术可以提供独特价值。共享流转的数据很难有边界,我们在做访问控制的时候,如果数据库或归档备份中的数据是明文,访问控制机制很容易被绕过。而通过数据加密技术,可以打造一个强防护场景,用户在正常访问应用的过程中数据才会解密,并结合身份访问控制、审计等安全技术,从而实现了“防绕过的访问控制”、以及“高置信度的审计”。密码技术为数据重新定义了虚拟的“防护边界”,从而更好的对数据实施防护与管控。综上所述,从业务视角看安全的边界,炼石认为安全就是一种业务需求,需要面向业务构建数据安全体系。然后对标ATT&CK模型,提出“以数据为中心的战术、技术和通用知识”(DTTACK框架),整理现有数据安全技术,最终将密码技术与多种安全技术融合,打造实战化的数据安全防护体系。炼石是一家基于密码与系统安全技术的新一代数据安全厂商,主要用户是政府、金融、教育医疗文旅、工业央企商业等,欢迎感兴趣的合作伙伴,随时和我们联系,共同掘金“新数据安全市场”。(DTTACK白皮书近期会发布,敬请关注本公众号及时获取)▼往期好文推荐▼ 一文读懂十大数据存储加密技术 一篇读懂22种密码应用模式                                                                                炼石网络是一家基于密码与系统安全技术的数据安全创新公司,提倡“以数据为中心的新安全理念”,自主研发了CASB业务数据安全平台和高性能国密产品,开创性的实现免开发改造应用、敏捷实施细粒度数据保护,该产品入选工信部2020年网络安全技术应用试点示范推荐项目,并夺得第七届互联网安全大会(ISC 2019)首届“创新独角兽沙盒大赛”总冠军。基于AOE面向切面数据安全技术,将安全与业务在技术上解耦、但又在能力上融合交织 ,实现主体到应用内用户、客体到字段级的防护,打造“以密码技术为核心,访问控制、审计等多种安全技术互相融合”的实战化数据安全防护体系。炼石为政府、金融、教育医疗文旅、工业央企商业等行业用户,提供个人信息保护、商业秘密保护以及国密合规改造方案,让数据共享更安全、更有价值。微信号:炼石网络CipherGateway 本文始发于微信公众号(炼石网络CipherGateway):密码大兴峰会 | 白小勇:以数据为中心的实战化密码防护
阅读全文
「议题前瞻」以数据为中心的安全治理实践丨FreeBuf企业安全俱乐部 云安全

「议题前瞻」以数据为中心的安全治理实践丨FreeBuf企业安全俱乐部

数字化转型进入加速期,数据作为关键生产要素和战略资源,各行各业对数据安全建设的重视度不断提高。数据安全的保护对象是数据,只有对数据有基本认知才能有的放矢,实现针对性安全保障,对于不少企业而言,安全建设过程面临对自身数据资产盘不清、道不明、想不透、无抓手、周期长等问题,难以顺利开展,在此背景下,采取数据安全治理的建设思路显得尤为重要。4月28日,杭州美创科技有限公司副总裁蔡毅,将在「FreeBuf 企业安全俱乐部」系列沙龙活动「2021数据安全与数据治理高峰论坛」中分享议题《以数据为中心的安全治理实践》,剖析数据安全治理过程中需求不明、责任不清、管理不当、建设不力等问题的核心原因,并将结合多个行业的数据安全治理实际案例,提供端到端数据安全治理解决之道。蔡毅,杭州美创科技有限公司副总裁,中国信息协会信息安全专业委员会数据工作部技术专家,十三年信息化从业经验,主要从事数据管理、信息安全以及战略咨询工作,是行业信息化建设和数字化转型资深专家,曾参与多项标准、课题研究,在金融、政府、企业等多个行业有项目方案经验。报名入口点击底部【阅读原文】或者扫描下方二维码报名:关于FreeBuf 企业安全俱乐部作为网络安全行业门户,FreeBuf始终关注着国内企业信息安全态势。为推动企业信息安全体系建设管理,促进企业安全交流合作,FreeBuf推出企业级品牌沙龙活动——「FreeBuf企业安全俱乐部」,为企业搭建专业的信息安全交流平台。这也是FreeBuf继推出新媒体平台、FreeBuf公开课、FreeTalk沙龙等品牌活动后,进一步完善信息安全交流生态圈建设的重要环节。往期回顾2020金融安全前沿技术高峰论坛看点回顾数据治理与安全运营 | 企业安全俱乐部「上海站」看点回顾等级保护2.0研讨专场 | 企业安全俱乐部「北京站」精彩回顾等级保护2.0研讨专场 | 企业安全俱乐部「深圳站」干货回顾精彩推荐 本文始发于微信公众号(FreeBuf):「议题前瞻」以数据为中心的安全治理实践丨FreeBuf企业安全俱乐部
阅读全文
国家计算机病毒中心发现新型蠕虫 即时聊天要当心 lcx

国家计算机病毒中心发现新型蠕虫 即时聊天要当心

  新华网天津7月3日电(记者 张建新)国家计算机病毒应急处理中心通过对互联网的监测发现,近期出现新型蠕虫Worm_Zaflen,提醒用户小心谨防。   专家说,该蠕虫主要通过即时聊天工具、电子邮箱以及移动存储设备(如:U盘)等方式进行传播,一旦计算机用户通过手工编辑被该变种破坏的批处理文件,则受入侵感染的计算机系统会被强行关机。   蠕虫运行后,会将后缀名分别是bat、scr、com等3种类型的文件进行隐藏,导致计算机用户极容易点击运行一些系统文件,造成计算机系统的不稳定。该蠕虫为了达到自动运行的目的,对受感染的操作系统进行了一些参数设置的篡改,致使计算机用户无法进行正常的使用操作。   另外,如果该蠕虫对批处理的编辑更改成自动关机,那么就会使得计算机用户当前执行的程序未能正常关闭,一些重要的资料、数据文件等信息未能及时保存,甚至有可能造成操作系统中应用软件的损坏而无法正常被使用。   对已经感染该蠕虫的计算机用户,专家建议立即升级系统中的防病毒软件,进行全面杀毒。对未感染该蠕虫的用户,建议打开系统中防病毒软件的“系统监控”功能,从注册表、系统进程、内存、网络等多方面对各种操作进行主动防御。 留言评论(旧系统): 我叫罗玉凤! @ 2011-07-13 05:19:56 没错 没错,今天下午哥几个正在群里吹牛,突然有人发了一个图片 只听“啪”一声,你猜怎么着? 竟然没蓝屏!!ungelivable! 但是,各种内存CUP直飙近 50/50!!!! 恐怖啊 恐怖 本站回复: 详见:http://lcx.cc/?FoxNews=1573.html,巨型尺寸图片卡QQ、QQ群用 GIF 变色 卡QQ群 死机 卡QQ。 文章来源于lcx.cc:国家计算机病毒中心发现新型蠕虫 即时聊天要当心
阅读全文
服务注册中心 | 记一次Consul故障分析与优化 安全开发

服务注册中心 | 记一次Consul故障分析与优化

前言在微服务体系中,服务注册中心是最基础的组件,它的稳定性会直接影响整个服务体系的稳定性。本文主要介绍了爱奇艺微服务平台基于Consul的服务注册中心建设方式,与内部容器平台、API网关的集成情况,并重点记录了Consul遇到的一次故障,分析解决的过程,以及针对这次故障从架构上的优化调整措施。Consul 是近几年比较流行的服务发现工具,用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案相比Consul 的方案更“一站式”,使用起来也较 为简单。他的主要应用场景为:服务发现、服务隔离、服务配置。Consul传送门01.注册中心背景及Consul的使用从微服务平台的角度出发希望提供统一的服务注册中心,让任何的业务和团队只要使用这套基础设施,相互发现只需要协商好服务名即可;还需要支持业务做多DC部署和故障切换。由于在扩展性和多DC支持上的良好设计,我们选择了Consul,并采用了Consul推荐的架构,单个DC内有Consul Server和Consul Agent,DC之间是WAN模式并且相互对等,结构如下图所示。注:图中只画了四个DC,实际生产环境根据公司机房建设以及第三方云的接入情况,共有十几个DC。02.与 QAE 容器应用平台集成爱奇艺内部的容器应用平台QAE与Consul进行了集成。由于早期是基于Mesos/Marathon体系开发,没有POD容器组概念,无法友好的注入sidecar的容器,因此我们选择了微服务模式中的第三方注册模式,即由QAE系统实时向Consul同步注册信息,如下图所示;并且使用了Consul的external service模式,这样可以避免两个系统状态不一致时引起故障,例如Consul已经将节点或服务实例判定为不健康,但是QAE没有感知到,也就不会重启或重新调度,导致没有健康实例可用。其中QAE应用与服务的关系表示例如下:每个QAE应用代表一组容器,应用与服务的映射关系是松耦合的,根据应用实际所在的DC将其关联到对应Consul DC即可,后续应用容器的更新、扩缩容、失败重启等状态变化都会实时体现在Consul的注册数据中。03.与API网关集成微服务平台API网关是服务注册中心最重要的使用方之一。网关会根据地区、运营商等因素部署多个集群,每个网关集群会根据内网位置对应到一个Consul集群,并且从Consul查询最近的服务实例,如下图所示。这里我们使用了Consul的PreparedQuery功能,对所有服务优先返回本DC服务实例,如果本DC没有则根据DC间RTT由近到远查询其它DC数据。故障与分析优化01.Consul故障Consul从2016年底上线开始,已经稳定运行超过三年时间,但是最近我们却遇到了故障,收到了某个DC多台Consul Server不响应请求、大量Consul Agent连不上Server的告警,并且没有自动恢复。Server端观察到的现象主要有:1. raft协议不停选举失败,无法获得leader;2. HTTP&DNS查询接口大量超时,观察到有些超过几十秒才返回(正常应当是毫秒级别返回);3. goroutine快速线性上升,内存同步上升,最终触发系统OOM;在日志中没能找到明确的问题,从监控metrics则观察到PreparedQuery的执行耗时异常增大,如下图所示。此时API网关查询服务信息也超时失败,我们将对应的网关集群切到了其它DC,之后重启Consul进程,恢复正常。02.故障分析经过日志排查,发现故障前发生过DC间的网络抖动(RTT增加,伴随丢包),持续时间大约1分钟,我们初步分析是DC间网络抖动导致正常收到的PreparedQuery请求积压在Server中无法快速返回,随着时间积累越来越多,占用的goroutine和内存也越来越多,最终导致Server异常。跟随这个想法,尝试在测试环境复现,共有4个DC,单台Server 的PreparedQuery QPS为1.5K,每个PreparedQuery查询都会触发3次跨DC查询,然后使用tc-netem工具模拟DC间的RTT增加的情况,得到了以下结果:1. 当DC间RTT由正常的2ms变为800ms之后,Consul Server的goroutine、内存确实会线性增长,PreparedQuery执行耗时也线性增长,如下图所示;2. 虽然goroutine、内存在增长,但是在OOM之前,Consul Server的其它功能未受影响,raft协议工作正常,本DC的数据查询请求也能正常响应;3. 在DC间RTT恢复到2ms的一瞬间,Consul Server丢失leader,接着raft不停选举失败,无法恢复;以上操作能够稳定的复现故障,使分析工作有了方向。首先基本证实了goroutine和内存的增长是由于PreparedQuery请求积压导致的,而积压的原因在初期是网络请求阻塞,在网络恢复后仍然积压原因暂时未知,这时整个进程应当是处于异常状态;那么,为什么网络恢复之后Consul反而故障了呢?raft 只有DC内网络通信,为什么也异常了呢?是最让我们困惑的问题。最开始的时候将重点放在了raft问题上,通过跟踪社区issue,找到了hashicorp/raft#6852,其中描述到我们的版本在高负载、网络抖动情况下可能出现raft死锁,现象与我们十分相似。但是按照issue更新raft库以及Consul相关代码之后,测试环境复现时故障依然存在。之后尝试给raft库添加日志,以便看清楚raft工作的细节,这次我们发现raft成员从进入Candidate状态,到请求peer节点为自己投票,日志间隔了10s,而代码中仅仅是执行了一行metrics更新,如下图所示。因此怀疑metrics调用出现了阻塞,导致整个系统运行异常,之后我们在发布历史中找到了相关优化,低版本的armon/go-metrics在prometheus实现中采用了全局锁 sync.Mutex,所有metrics更新都需要先获取这个锁,而v0.3.3版本改用了sync.Map,每个metric作为字典的一个键,只在键初始化的时候需要获取全局锁,之后不同metric更新值的时候就不存在锁竞争,相同metric更新时使用sync.Atomic保证原子操作,整体上效率更高。更新对应的依赖库之后,复现网络抖动之后,Consul Server可以自行恢复正常。这样看来的确是由于metrics代码阻塞,导致了系统整体异常。但我们依然有疑问,复现环境下单台Server 的PreparedQuery QPS为1.5K,而稳定的网络环境下单台Server压测QPS到2.8K时依然工作正常。也就是说正常情况下原有代码是满足性能需求的,只有在故障时出现了性能问题。接下来的排查陷入了困境,经过反复试验,我们发现了一个有趣的现象:使用go1.9编译的版本(也是生产环境使用的版本)能复现出故障;同样的代码使用go1.14编译就无法复现出故障。经过仔细查看,我们在go的发布历史中找到了以下两条记录:根据代码我们找到了用户反馈在go1.9~1.13版本,在大量goroutine同时竞争一个sync.Mutex时,会出现性能急剧下降的情况,这能很好的解释我们的问题。由于Consul代码依赖了go1.9新增的内置库,我们无法用更低的版本编译,因此我们将go1.14中sync.Mutex相关的优化去掉,如下图所示,然后用这个版本的go编译Consul,果然又可以复现我们的故障了。回顾语言的更新历史,go1.9版本添加了公平锁特性,在原有normal模式上添加了starvation模式,来避免锁等待的长尾效应。但是normal模式下新的goroutine在运行时有较高的几率竞争锁成功,从而免去goroutine的切换,整体效率是较高的;而在starvation模式下,新的goroutine不会直接竞争锁,而是会把自己排到等待队列末端,然后休眠等待唤醒,锁按照等待队列FIFO分配,获取到锁的goroutine被调度执行,这样会增加goroutine调度、切换的成本。在go1.14中针对性能问题进行了改善,在starvation模式下,当goroutine执行解锁操作时,会直接将CPU时间让给下一个等待锁的goroutine执行,整体上会使得被锁保护部分的代码得到加速执行。到此故障的原因就清楚了,首先网络抖动,导致大量PreparedQuery请求积压在Server中,同时也造成了大量的goroutine和内存使用;在网络恢复之后,积压的PreparedQuery继续执行,在我们的复现场景下,积压的goroutine量会超过150K,这些goroutine在执行时都会更新metrics从而去获取全局的sync.Mutex,此时切换到starvation模式并且性能下降,大量时间都在等待sync.Mutex,请求阻塞超时;除了积压的goroutine,新的PreparedQuery还在不停接收,获取锁时同样被阻塞,结果是sync.Mutex保持在starvation模式无法自动恢复;另一方面raft代码运行会依赖定时器、超时、节点间消息的及时传递与处理,并且这些超时通常是秒、毫秒级别的,但metrics代码阻塞过久,直接导致时序相关的逻辑无法正常运行。接着生产环境中我们将发现的问题都进行了更新,升级到go1.14,armon/go-metrics v0.3.3,以及hashicorp/raft v1.1.2版本,使Consul达到一个稳定状态。此外还整理完善了监控指标,核心监控包括以下维度:1. 进程:CPU、内存、goroutine、连接数2. raft:成员状态变动、提交速率、提交耗时、同步心跳、同步延时3. RPC:连接数、跨DC请求数4. 写负载:注册&解注册速率5. 读负载:Catalog/Health/PreparedQuery请求量,执行耗时03.冗余注册根据Consul的故障期间的故障现象,我们对服务注册中心的架构进行了重新审视。在Consul的架构中,某个DC Consul Server全部故障了就代表这个DC故障,要靠其它DC来做灾备。但是实际情况中,很多不在关键路径上的服务、SLA要求不是特别高的服务并没有多DC部署,这时如果所在DC的Consul故障,那么整个服务就会故障。针对本身并没有做多DC部署的服务,如果可以在冗余DC注册,那么单个DC Consul故障时,其它DC还可以正常发现。因此我们修改了QAE注册关系表,对于本身只有单DC部署的服务,系统自动在其它DC也注册一份,如下图所示。QAE这种冗余注册相当于在上层做了数据多写操作。Consul本身不会在各DC间同步服务注册数据,因此直接通过Consul Agent方式注册的服务还没有较好的冗余注册方法,还是依赖服务本身做好多DC部署。04.保障API网关目前API网关的正常工作依赖于Consul PreparedQuery查询结果在本地的缓存,目前的交互方式有两方面问题:1. 网关缓存是lazy的,网关第一次用到时才会从Consul查询加载,Consul故障时查询失败会导致请求转发失败;2. PreparedQuery内部可能会涉及多次跨DC查询,耗时较多,属于复杂查询,由于每个网关节点需要单独构建缓存,并且缓存有TTL,会导致相同的PreparedQuery查询执行很多次,查询QPS会随着网关集群规模线性增长。为了提高网关查询Consul的稳定性和效率,我们选择为每个网关集群部署一个单独的Consul集群,如下图所示。图中红色的是原有的Consul集群,绿色的是为网关单独部署的Consul集群,它只在单DC内部工作。我们开发了Gateway-Consul-Sync组件,它会周期性的从公共Consul集群读取服务的PreparedQuery查询结果,然后写入到绿色的Consul集群,网关则直接访问绿色的Consul进行数据查询。这样改造之后有以下几方面好处:1. 从支持网关的角度看,公共集群的负载原来是随网关节点数线性增长,改造后变成随服务个数线性增长,并且单个服务在同步周期内只会执行一次PreparedQuery查询,整体负载会降低;2. 图中绿色Consul只供网关使用,其PreparedQuery执行时所有数据都在本地,不涉及跨DC查询,因此复杂度降低,不受跨DC网络影响,并且集群整体的读写负载更可控,稳定性更好;3. 当公共集群故障时,Gateway-Consul-Sync无法正常工作,但绿色的Consul仍然可以返回之前同步好的数据,网关还可以继续工作;4. 由于网关在改造前后查询Consul的接口和数据格式是完全一致的,当图中绿色Consul集群故障时,可以切回到公共Consul集群,作为一个备用方案。总结与展望作为统一的服务注册中心,稳定性、可靠性始终是我们的首要目标。一方面在保证服务注册中心本身的稳定性,另一方面也会在架构上通过部署、数据、组件等多维度的冗余来提高整个技术体系的稳定性。目前我们有了一系列监控指标,可以帮助我们评估系统整体的容量、饱和度。随着接入服务越来越多,还要继续完善服务维度的监控指标,当系统负载发生预期外的变化时,能够快速定位到具体的服务、节点。引用1.爱奇艺微服务API网关https://mp.weixin.qq.com/s/joaYcdmeelGZmpMcEo-mpw2.Consul raft deadlock https://github.com/hashicorp/consul/issues/68523.Consul prometheus update https://github.com/hashicorp/consul/pull/83724.Go sync.Mutex performance issue https://github.com/golang/go/issues/337475.Go sync.Mutex update https://go-review.googlesource.com/c/go/+/206180/也许你还想看基于微服务成熟度模型的高可用优化实践爱奇艺号基于Prometheus的微服务应用监控实践扫一扫下方二维码,更多精彩内容陪伴你! 本文始发于微信公众号(爱奇艺技术产品团队):服务注册中心 | 记一次Consul故障分析与优化
阅读全文
收藏 :社会科学数据资源汇总 安全闲碎

收藏 :社会科学数据资源汇总

情报分析师全国警务人员和情报人员都在关注关注本文约4900字,建议阅读15分钟。本文汇总了社会科学数据的资源。目前中国社区、家庭、个人层面的微观数据库,分别有北大中国社会科学调查中心,中山大学社会科学调查中心、中国人民大学中国调查与数据中心、清华大学中国经济社会数据中心、上海大学上海科学调查中心、西南财经大学中国家庭金融调查与研究中心、复旦大学社会科学数据研究中心、中国社科院调查与数据信息中心等。下面就一起来看看微观经济数据库。目录:中国综合社会调查(CGSS)中国社会状况综合调查(CSS)中国劳动力动态调查(CLDS)中国家庭收入项目(CHIP)中国家庭追踪调查(CFPS)中国健康与养老追踪调查(CHARLS)中国家庭金融调查数据CHFS全国老年人口健康状况调查研究(CLHLS)中国健康与营养调查(CHNS)其他数据库欢迎大家补充调查中心(排名不分先后):北京大学中国社会科学调查中心(Institute of Social Science Survey, ISSS)成立于2006年9月,是北京大学社会科学的数据调查平台,也是北京大学开展中国社会问题实证研究的跨学科平台。中心目前承担两个大型社会调查项目——中国家庭动态跟踪调查和中国健康养老追踪调查。两个项目的目的均是收集反映我国民生状况的高质量微观数据,用以分析社会民生方面的问题,为政策制定提供依据,同时推动社会、经济、教育等跨学科研究工作。中国人民大学-中国调查与数据中心(National Survey Research Center at Renmin University of China, NSRC)是中国人民大学直属的跨学科、跨院系的综合性研究机构。中心的宗旨为科学、系统、全面地采集、整理、存储与开发中国经济与社会调查数据,进行调查方法与相关技术的研究开发,实施具有重大科学与现实意义的大型科研项目,为科学研究和政府决策提供数据支持。中国调查与数据中心(NSRC)围绕着中国的经济和社会数据,以数据采集、数据存储、数据开发为主要方向。中国调查与数据中心(NSRC)联合全国53所高校组成了“中国社会调查网络(CSSN)”,组织实施中国综合社会调查(CGSS)、中国教育追踪调查(CEPS)、中国宗教调查(CRS)、中国老年社会追踪调查(CLASS)、大学生成长追踪调查(CSDS)、千人百村调查等大型长期追踪调查项目,建成了大规模、全国性、全方位、多层次、连续性与自主性的社会科学基础数据采集平台。中国调查与数据中心(NSRC)受国家自然科学基金委托,建成了中国第一个社会科学调查数据资料库——中国国家调查数据库(CNSDA),开创了我国社会科学数据开放与共享的先河。中国社科院-社会学研究所、清华大学、中山大学、复旦大学、上海大学等也有各自的调查中心。中国综合社会调查数据CGSS中国综合社会调查(Chinese General Social Survey,CGSS)始于2003年,是我国最早的全国性、综合性、连续性学术调查项目。CGSS系统、全面地收集社会、社区、家庭、个人多个层次的数据,总结社会变迁的趋势,探讨具有重大科学和现实意义的议题,推动国内科学研究的开放与共享,为国际比较研究提供数据资料,充当多学科的经济与社会数据采集平台。目前,CGSS数据已成为研究中国社会最主要的数据来源,广泛地应用于科研、教学、政府决策之中。2003-2008年是CGSS项目的第一期,共完成5次年度调查(2007年没有执行),生产出5套高质量的年度数据。除2004年的调查数据,剩下的年度数据都已在中国国家调查数据库(China National Survey Data Archive,CNSDA)的网站(cnsda.ruc.edu.cn)上发布,到目前为止,用户可免费申请使用。执行机构丨中国人民大学中国调查与数据中心数据网址丨http://www.cnsda.org/index.php?r=site/datarecommendation开放数据年份丨2003、2005、2006、2008、2010、2011、2012、2013时间跨度丨分两期,第一期:2003年—2008年2008年,每年一次;第二期:2010年—2019年,每两年一次。最新公开数据:CGSS2013。数据类型丨截面数据分析单位丨个人、家庭覆盖区域丨中国28个省市核心问题丨中国社会变迁(文化、健康、家庭、劳动力、就业、消费、教育、心理、个性等)应用主题丨人口健康分析、劳动就业分析、消费储蓄分析、空间规划分析社会流动、幸福感、社会信任、教育回报、宗教信仰、政治参与等。中国社会状况综合调查(CSS)“中国社会状况综合调查”(Chinese Social Survey,简称CSS)是中国社会科学院社会学研究所于2005年发起的一项全国范围内的大型连续性抽样调查项目,目的是通过对全国公众的劳动就业、家庭及社会生活、社会态度等方面的长期纵贯调查,来获取转型时期中国社会变迁的数据资料,从而为社会科学研究和政府决策提供翔实而科学的基础信息。该调查是双年度的纵贯调查,采用概率抽样的入户访问方式,调查区域覆盖了全国31个省/自治区/直辖市,包括了151个区市县,604个村/居委会,每次调查访问7000到10000余个家庭。此调查有助于获取转型时期中国社会变迁的数据资料,其研究结果可推论全国年满18-69周岁的住户人口。 为了兼顾纵贯调查的连续性和社会议题的现实性, CSS的调查问卷在设计上分为基础模块、更替模块和热点模块三个部分。其中基础模块固定不变,包含了个人基础信息、劳动与就业、家庭结构、家庭经济状况等内容;更替模块如社会阶层地位流动、社会保障、休闲消费、社会价值观等,隔一定周期后重复调查;热点模块则与时俱进,目前已进行了社会群体利益关系、民生问题、城镇化等主题的研究。 数据下载方式http://css.cssn.cn/css_sy/中国劳动力动态调查数据CLDS执行机构丨中山大学社会科学调查中心数据下载丨可下载spss、stata格式的数据,下载的数据格式由数据原始格式决定。http://css.sysu.edu.cn/数据网址丨http://css.sysu.edu.cn/Data和http://cus.sysu.edu.cn/sjku.asp?id=887开放数据年份丨2011、2012、2014数据类型丨面板数据分析单位与调查规模丨社区、家庭、劳动;调查对象为样本家庭户中的全部劳动力(年龄15至64岁的家庭成员)。覆盖区域丨中国29个省市(港澳台、西藏、海南除外)核心问题丨系统地监测社区社会结构和家庭、劳动力个体的变化与相互影响应用主题丨人口健康分析、劳动就业分析、消费储蓄分析、空间规划分析中国家庭收入调查(CHIP)网址http://www.ciidbnu.org/chip/index.asp为了追踪中国收入分配的动态情况,中国家庭收入调查(CHIP)已经相继在1989年、1996年、2003年、2008年和2014年进行了五次入户调查。它们分别收集了1988、1995、2002、2007和2013年的收支信息,以及其他家庭和个人信息,分别编号为CHIP1988、CHIP1995、CHIP2002、CHIP2007和CHIP2013。这几次调查是由中外研究者共同组织的、关于“中国收入和不平等研究”的组成部分,并且在国家统计局的协助下完成。CHIP项目的参与者和其他学者分析了这四次调查数据,并且发表了涉及很多领域的文章、报告和学术书籍。所有的CHIP数据均包含针对城镇和农村住户的调查。鉴于农村向城镇迁移的日渐重要的现实意义,以及城镇和农村住户的子样本并不完全覆盖所有流动人口,2002年的调查增加了对流动人口的调查。因此,2002年CHIP调查包含了三个子样本。2007年的调查也采用了同样的方法,因此也由三个部分组成:城镇住户调查、农村住户调查和流动人口调查。这一结构反映了中国的城乡分割和近20年中不断增加的迁移到城镇地区的农村个体数量。中国家庭追踪调查数据CFPS执行机构丨北京大学中国社会科学调查中心数据网址丨http://www.isss.edu.cn/cfps/“中国家庭追踪调查“(CFPS)重点关注中国居民的经济与非经济福利,以及包括经济活动、教育成果、家庭关系与家庭动态、人口迁移、健康等在内的诸多研究主题,是一项全国性、大规模、多学科的社会跟踪调查项目。CFPS样本覆盖25个省/市/自治区,目标样本规模为16000户,调查对象包含样本家户中的全部家庭成员。CFPS在2008、2009两年在北京、上海、广东三地分别开展了初访与追访的测试调查,并于2010年正式开展访问。经2010年基线调查界定出来的所有基线家庭成员及其今后的血缘/领养子女将作为CFPS的基因成员,成为永久追踪对象。开放数据年份丨2008、2009(测试性调查,北京、上海、广东);2010(基线调查);2011(维护调查);2012年以后每年一次跟踪调查。最新公开数据:CFPS2016(追访)调查数据。数据类型丨面板数据分析单位与调查规模丨社区、家庭、个人(成人、少儿);基线调查为16000户。CFPS调查问卷共有社区问卷、家庭问卷、成人问卷和少儿问卷四种主体问卷类型,并在此基础上不断发展出针对不同性质家庭成员的长问卷、短问卷、代答问卷、电访问卷等多种问卷类型。覆盖区域丨中国25个省市,2010年在全国(西藏、青海、新疆、宁夏、内蒙古、海南、香港、澳门、台湾不在其列)正式实施。核心问题丨中国社会、经济、人口、教育和健康的变迁应用主题丨人口健康分析、劳动就业分析、消费储蓄分析、空间规划分析、质量管理主要调查项目:家庭:生活条件、家户各类收入与支出、住房、金融资产等成人:基本信息、教育、婚姻、工作、健康、退休与养老、认知、宗教等少儿:基本信息、日常生活、健康、教育、培训辅导、认知能力等其中,村/居问卷的调查内容包括:村/居基础设施概况、人口和劳动力资源概况、自身及周边环境、基层选举、财政收入与支出,以及日常消费品价格等。家庭问卷的调查内容包括:家庭成员结构、日常生活基本设施、社会交往、住房、家庭经济、农业生产与销售等。成人问卷的调查内容包括:教育、婚姻、职业、日常生活、健康、养老、社会保障、社会交往、价值观、以及基准测试等。少儿问卷的调查内容包括:学业情况、日常生活、健康、职业期望、与父母关系、成长环境、社会交往、价值观、以及基准测试等。中国健康与养老追踪调查(CHARLS)执行机构丨北京大学中国社会科学调查中心数据网址丨http://charls.pku.edu.cn/zh-CN开放数据年份丨2008、2012(两省),2011、2013、2014(全国)2011年(基线调查);以后每两年追踪一次,调查结束1年后,数据对外界公开。2013年(追踪调查);2014年(“中国中老年生命历程调查”专项)。最新公开数据:2015年CHARLS全国追踪调查数据。数据类型丨面板数据分析单位丨个人、家庭覆盖区域丨基线调查在全国28个省的150个县区的450个村、居展开。浙江、甘肃两省(2008、2012),中国28个省市(2011、2013、2014)核心问题丨我国人口老龄化问题应用主题丨人口健康分析、消费储蓄分析分析单位与调查规模丨家户、个人(45岁及以上);2015年全国追访时,其样本已覆盖总计1.24万户家庭中的2.3万名受访者。主要调查项目丨个人基本信息,家庭结构和经济支持,健康状况,体格测量,医疗服务利用和医疗保险,工作、退休和养老金、收入、消费、资产,以及社区基本情况等。研究主题丨人口老龄化问题、劳动经济学(婚姻、彩礼等)、社会保障、人口经济学、卫生经济学等。中国家庭金融调查数据CHFS执行机构丨西南财经大学数据网址丨http://chfs.swufe.edu.cn/开放数据年份丨2011年开始首轮调查,每两年进行一次追踪调查。目前可利用数据CHFS2011、CHFS2013、CHFS2015。数据类型丨截面数据分析单位丨家庭覆盖区域丨25个省市(2011),29个省市(2013)以CFPS2013为例,除追访2011年访问的8438户家庭、29000个个体外,样本进行首次扩展,最终共计调查来自全国29个省市、自治区(新疆、西藏除外)262个县区的28241个家庭,93000个个体。核心问题丨家庭金融状况、收入支出、社会保障、商业保险等应用主题丨人口健康分析、劳动就业分析、消费储蓄分析、金融与投资分析全国老年人口健康状况调查研究(CLHLS)全国老年人口健康状况调查研究(CLHLS),是由北京大学健康老龄与发展研究中心/国家发展研究院组织的老年人追踪调查,调查范围覆盖全国23个省区市,调查对象为65岁及以上老年人和35-64岁成年子女,调查问卷分为存活被访者问卷和死亡老人家属问卷两种。存活被访者问卷的调查内容包括老人及家庭基本状况、社会经济背景及家庭结构、经济来源和经济状况、健康和生活质量自评、认知功能、性格心理特征、日常活动能力、生活方 式、生活照料、疾病治疗和医疗费承担;死亡老人家属问卷的调查内容包括死亡时间、死因等内容。中国健康与营养调查(CHNS)中国健康与营养调查(China Health and Nutrition Survey, CHNS)是由北卡罗来纳大学人口研究中心(The Carolina Population Center at the University of North Carolina at Chapel Hill)﹑美国国家营养与食物安全研究所(The National Institute of Nutrition and Food Safety)和中国疾病与预防控制中心(The Chinese Center for Disease Control and Prevention)合作开展的调查项目。该调查旨在检验健康﹑营养和计划生育政策的影响以及研究中国社会经济的转变如何作用于整个人口健康和营养状况。到目前为止,该调查一共进行了7次,分别是1989﹑1991﹑1993﹑1997﹑2000﹑2004和2006年。该调查采用多阶段整群抽样的方法,其中有几年因为一些原因,调查的省份发生了变化,最新的2006年的调查范围涉及辽宁﹑黑龙江﹑江苏﹑山东﹑河南﹑湖北﹑湖南﹑广西和贵州9个省(自治区),调查内容涉及住户、营养、健康、成人、儿童、社区等。本期编辑:糖来源:计量经济学服务中心如有侵权,请联系管理员删除普及情报思维 传播情报文化长 按 关 注【投稿邮箱】[email protected]
阅读全文
美国联邦政府如何提升安全运营中心的效能? 安全新闻

美国联邦政府如何提升安全运营中心的效能?

点击蓝字关注我们美国白宫管理与预算办公室已经推动至少两轮尝试,旨在敦促各政府机构合并及优化其安全运营中心(SOC)。目前,美国政府下属的一些部门中包含了8个甚至10个安全运营中心,这使得部门首席信息安全官(CISO)、国土安全部乃至管理与预算办公室根本无法了解到实际情况。美国联邦政府首席信息安全官Grant Schneider表示,新一轮提升安全运营中心价值、削减机构数量正在努力推进中。Grant Schneider, 联邦政府首席信息安全官Schneider在最近接受采访时表示,“我们一直在努力推动各级政府机构提高网络安全标准。我们也很清楚,实现此项目标的一项重要手段,在于高度关注共享服务。通过安全运营中心即服务(SOC-as-a-Service,SOCaaS),国土安全部将为这一领域当中的所有服务提供方设定执行标准与发展目标。当然,国土安全部并不是这项工作中的唯一服务提供方,司法部也参与进来了,可为其他机构提供强有力的专业知识支持。” 今年5月,管理与预算办公室将国土安全部任命为网络安全质量服务管理办公室(QSMO),而安全运营中心即服务也由此成为联邦政府推动共享服务全覆盖中的三大初始核心议题之一。肩负质量网络安全服务管理办公室(QSMO)的职责,国土安全部将提供三项核心服务:安全运营中心标准化漏洞管理标准化域名服务(DNS)解析服务其未来的服务方案中可能将包括网络防御、事件管理、威胁情报、网络供应链风险管理和其它服务等。Schneider表示,QSMO将从2021财年开始陆续推出安全运营中心即服务(SOCaaS)项目。“我们希望通过两种方式实现服务供应。首先,可能通过司法部或国土安全部等相关政府机构提供这些服务;第二,国土安全部还将与总务管理局紧密合作,保证我们能够获得新的服务能力并将网络安全行业带入其中。国土安全部的QSMO职责,在于保证所有这些功能都将达到统一的服务水平与实施标准。我们也非常明确地意识到,网安行业将在这一领域中扮演重要角色。”管理和预算办公室于2018年发布了首份网络风险定性报告,其中回顾了96个部门在管理和解决这些挑战时采取的具体方法,而建立QSMO的必要性也由此得到证明。这份报告指出:“相当一部分联邦机构报告称,他们缺少具备操作安全运营中心所需核心技能的全职员工;某些机构的内部安全运营中心之间甚至采用完全不同的流程与技术方案。结果就是,安全网络的可见性差、运营效率低下且缺乏实际效用。对于下辖多个安全运营中心的机构而言,CISO们往往报告称这些中心之间互不交流、彼此隔绝,根本谈不上共享威胁信息及情报。尽管管理和预算办公室之前曾要求各机构指定单一主中心以缓解这方面问题,主中心将负责管理各机构内的所有安全事件响应活动。但从结果来看,问题仍然存在。”通过CyberStat项目施加压力Schneider表示,QSMO主要解决安全运营中心面临的部分技术挑战,而行政层面的难题则交给管理和预算办公室负责处理。他解释道,“我们去年曾要求各级机构制定安全运营中心成熟度计划,而且一直在与这些机构合作商讨计划细节。目前,不少机构内部设有多个安全运营中心,我们在着力进行合并,或者至少要保证在其中指定主中心,保证所有安全事件内容得到高效汇总,并作为集中且可见的结论用于指导机构运营。”至于管理和预算办公室要如何实现运营中心的发展与合并目标,并逐步转向共享服务的新形态,则将由CyberState项目给出答案。管理和预算办公室于2011年启动CyberStat项目,旨在向各级政府机关施加直接压力,借此解决种种系统性网络安全问题。但到2018年,CyberStat早已毫无存在感。政府问责办公室在今年5月的公开建议报告中指出,管理和预算办公室正着手恢复这一监督流程。后者正在“更新对起草中的运营文件进行概念更新。为了全面落实此项建议,管理和预算办公室将最终确定并发布CyberStat运营文件概念大纲,并要求各机构更积极地参与CyberStat组织的安全会议。”Schneider还表示,经过改进的CyberStat流程将通过多种具体方式发挥重要作用。他指出,“各级政府所习惯的、以一对一形式进行的传统沟通方式当然需要整改。但除此之外,我们也在尝试推动更多新思路,希望借此让安全运营中心重新焕发活力。我们正与各级机构共商特定议题,并对各级机构与国土安全部在实践中的经验教训做出总结,整理出更多普遍适用的网安专业知识。”Schneider表示,除了SOCaaS与重振CyberStat之外,联邦政府CISO理事会还将继续关注政策变化,例如需要在漏洞披露方面做出的收尾性调整。为供应链管理制定最终过渡规则联邦CISO理事会关注的另一个领域,在于供应链的风险管理。Schneider自己正是联邦政府采购安全委员会的负责人,他表示当前的目标,在于切实运用国会在《安全技术法》中赋予他们的权利。他解释道,“距离理事会讨论已经过去一年之久。在关于建立理事会的立法中,除了授予我们新的权利之外,也为我们指定了诸多实际任务。我们已经向国会提交了战略规划与FASC章程。目前,我们需要为供应链管理制定最终过渡规则,其中的核心内容,在于指导理事会如何着眼于几项根本任务制定执行流程与规程。我们需要在政府内部共享供应链信息管理信息,概述如何实现这一信息共享能力,并在适当时将结论与网安行业分享。我们还需要确定应如何对这类共享文章进行评估与核查,而后向国防部、国土安全部以及国家情报局局长提出建议,帮助他们判断是否有必要发出撤销令。”在谈到供应链风险管理时,Schneider表示,他目前正在密切关注国防部发布的网络安全成熟度模型认证(CMMC)标准。“我期待看到这项标准的进展以及将要实现的效果。我们也已经对可行的应用方式进行了思考,但目前还很难判断要不要将此项标准全面推广到整个联邦政府范围内。”原文链接:https://federalnewsnetwork.com/ask-the-cio/2020/08/federal-ciso-schneider-plans-to-reinvigorate-cyberstat-in-fiscal-2021/扫描二维码关注我们互 联 网 安 全 内 参网络安全首席知识官转载申请:hui033463翻译供稿:security4投稿邮箱:[email protected]
阅读全文