浅谈云原生架构的 7 个原则 云安全

浅谈云原生架构的 7 个原则

作为一种架构模式,云原生架构通过若干原则来对应用架构进行核心控制。这些原则可以帮助技术主管和架构师在进行技术选型时更加高效、准确,下面将展开具体介绍。服务化原则在软件开发过程中,当代码数量与开发团队规模都扩张到一定程度后,就需要重构应用,通过模块化与组件化的手段分离关注点,降低应用的复杂度,提升软件的开发效率,降低维护成本。如图 1,随着业务的不断发展,单体应用能够承载的容量将逐渐到达上限,即使通过应用改造来突破垂直扩展(Scale Up)的瓶颈,并将其转化为支撑水平扩展(Scale Out)的能力,在全局并发访问的情况下,也依然会面临数据计算复杂度和存储容量的问题。因此,需要将单体应用进一步拆分,按业务边界重新划分成分布式应用,使应用与应用之间不再直接共享数据,而是通过约定好的契约进行通信,以提高扩展性。图 1 应用服务化扩展服务化设计原则是指通过服务化架构拆分不同生命周期的业务单元,实现业务单元的独立迭代,从而加快整体的迭代速度,保证迭代的稳定性。同时,服务化架构采用的是面向接口编程方式,增加了软件的复用程度,增强了水平扩展的能力。服务化设计原则还强调在架构层面抽象化业务模块之间的关系,从而帮助业务模块实现基于服务流量(而非网络流量)的策略控制和治理,而无须关注这些服务是基于何种编程语言开发的。有关服务化设计原则的实践在业界已有很多成功案例。其中影响最广、最为业界称道的是 Netflix 在生产系统上所进行的大规模微服务化实践。通过这次实践,Netflix 在全球不仅承接了多达 1.67 亿订阅用户以及全球互联网带宽容量 15% 以上的流量,而且在开源领域贡献了 Eureka、Zuul、Hystrix 等出色的微服务组件。不仅海外公司正在不断进行服务化实践,国内公司对服务化也有很高的认知。随着近几年互联网化的发展,无论是新锐互联网公司,还是传统大型企业,在服务化实践上都有很好的实践和成功案例。阿里巴巴的服务化实践发端于 2008 年的五彩石项目,历经 10 年的发展,稳定支撑历年大促活动。以 2019 年“双 11”当天数据为例,阿里巴巴的分布式系统创单峰值为每秒 54.4 万笔,实时计算处理为每秒 25.5 亿笔。阿里巴巴在服务化领域的实践,已通过 Apache Dubbo、Nacos、Sentinel、Seata、Chaos Blade 等开源项目分享给业界, 同时,这些组件与 Spring Cloud的集成 Spring Cloud Alibaba 已成为 Spring Cloud Netflix 的继任者。虽然随着云原生浪潮的兴起,服务化原则不断演进、落地于实际业务,但企业在实际落地过程中也会遇到不少的挑战。比如,与自建数据中心相比,公有云下的服务化可能存在巨大的资源池,使得机器错误率显著提高;按需付费增加了扩缩容的操作频度;新的环境要求应用启动更快、应用与应用之间无强依赖关系、应用能够在不同规格的节点之间随意调度等诸多需要考虑的实际问题。但可以预见的是,这些问题会随着云原生架构的不断演进而得到逐一解决。弹性原则弹性原则是指系统部署规模可以随着业务量变化自动调整大小,而无须根据事先的容量规划准备固定的硬件和软件资源。优秀的弹性能力不仅能够改变企业的 IT 成本模式,使得企业不用再考虑额外的软硬件资源成本支出(闲置成本),也能更好地支持业务规模的爆发式扩张,不再因为软硬件资源储备不足而留下遗憾。在云原生时代,企业构建 IT 系统的门槛大幅降低,这极大地提升了企业将业务规划落地为产品与服务的效率。这一点在移动互联网和游戏行业中显得尤为突出。一款应用成为爆款后,其用户数量呈现指数级增长的案例不在少数。而业务呈指数级增长会对企业 IT 系统的性能带来巨大考验。面对这样的挑战,在传统架构中,通常是开发人员、运维人员疲于调优系统性能,但是,即使他们使出浑身解数,也未必能够完全解决系统的瓶颈问题, 最终因系统无法应对不断涌入的海量用户而造成应用瘫痪。除了面临业务呈指数级增长的考验之外,业务的峰值特征将是另一个重要的挑战。比如,电影票订票系统下午时段的流量远超凌晨时段,而周末的流量相比工作日甚至会翻好几倍;还有外卖订餐系统,在午餐和晚餐前后往往会出现订单峰值时段。在传统架构中,为了应对这类具有明显峰值特征的场景,企业需要为峰值时段的流量提前准备大量的计算、存储及网络资源并为这些资源付费,而这些资源在大部分时间内却处于闲置状态。因此,在云原生时代,企业在构建 IT系统时,应该尽早考虑让应用架构具备弹性能力,以便在快速发展的业务规模面前灵活应对各种场景需求,充分利用云原生技术及成本优势。要想构建弹性的系统架构,需要遵循如下四个基本原则。按功能切割应用一个大型的复杂系统可能由成百上千个服务组成,架构师在设计架构时,需要遵循的原则是:将相关的逻辑放到一起,不相关的逻辑拆解到独立的服务中,各服务之间通过标准的服务发现(Service Discovery)找到对方,并使用标准的接口进行通信。各服务之间松耦合,这使得每一个服务能够各自独立地完成弹性伸缩,从而避免服务上下游关联故障的发生。支持水平切分按功能切割应用并没有完全解决弹性的问题。一个应用被拆解为众多服务后,随着用户流量的增长,单个服务最终也会遇到系统瓶颈。因此在设计上,每个服务都需要具备可水平切分的能力,以便将服务切分为不同的逻辑单元,由每个单元处理一部分用户流量,从而使服务自身具备良好的扩展能力。这其中最大的挑战在于数据库系统,因为数据库系统自身是有状态的,所以合理地切分数据并提供正确的事务机制将是一个非常复杂的工程。不过,在云原生时代,云平台所提供的云原生数据库服务可以解决大部分复杂的分布式系统问题,因此,如果企业是通过云平台提供的能力来构建弹性系统,自然就会拥有数据库系统的弹性能力。自动化部署系统突发流量通常无法预计,因此常用的解决方案是,通过人工扩容系统的方式,使系统具备支持更大规模用户访问的能力。在完成架构拆分之后,弹性系统还需要具备自动化部署能力,以便根据既定的规则或者外部流量突发信号触发系统的自动化扩容功能,满足系统对于缩短突发流量影响时长的及时性要求,同时在峰值时段结束后自动缩容系统,降低系统运行的资源占用成本。支持服务降级弹性系统需要提前设计异常应对方案,比如,对服务进行分级治理,在弹性机制失效、弹性资源不足或者流量峰值超出预期等异常情况下,系统架构需要具备服务降级的能力,通过降低部分非关键服务的质量,或者关闭部分增强功能来让出资源,并扩容重要功能对应的服务容量,以确保产品的主要功能不受影响。国内外已有很多成功构建大规模弹性系统的实践案例,其中最具代表性的是阿里巴巴一年一度的“双11”大促活动。为了应对相较于平时上百倍的流量峰值,阿里巴巴每年从阿里云采买弹性资源部署自己的应用,并在“双 11”活动之后释放这一批资源,按需付费,从而大幅降低大促活动的资源成本。另一个例子是新浪微博的弹性架构,在社会热点事件发生时,新浪微博通过弹性系统将应用容器扩容到阿里云,以应对热点事件导致的大量搜索和转发请求。系统通过分钟级的按需扩容响应能力,大幅降低了热搜所产生的资源成本。随着云原生技术的发展,FaaS、Serverless 等技术生态逐步成熟,构建大规模弹性系统的难度逐步降低。当企业以 FaaS、Serverless 等技术理念作为系统架构的设计原则时,系统就具备了弹性伸缩的能力,企业也就无须额外为“维护弹性系统自身”付出成本。可观测原则与监控、业务探活、APM(Application Performance Management,应用性能管理)等系统提供的被动能力不同,可观测性更强调主动性,在云计算这样的分布式系统中,主动通过日志、链路跟踪和度量等手段,让一次 App 点击所产生的多次服务调用耗时、返回值和参数都清晰可见,甚至可以下钻到每次第三方软件调用、SQL 请求、节点拓扑、网络响应等信息中。运维、开发和业务人员通过这样的观测能力可以实时掌握软件的运行情况,并获得前所未有的关联分析能力,以便不断优化业务的健康度和用户体验。随着云计算的全面发展,企业的应用架构发生了显著变化,正逐步从传统的单体应用向微服务过渡。在微服务架构中,各服务之间松耦合的设计方式使得版本迭代更快、周期更短;基础设施层中的 Kubernetes 等已经成为容器的默认平台;服务可以通过流水线实现持续集成与部署。这些变化可将服务的变更风险降到最低,提升了研发的效率。在微服务架构中,系统的故障点可能出现在任何地方,因此我们需要针对可观测性进行体系化设计,以降低 MTTR(故障平均修复时间)。要想构建可观测性体系,需要遵循如下三个基本原则。数据的全面采集指标(Metric)、链路跟踪(Tracing)和日志(Logging)这三类数据是构建一个完整的可观测性系统的“三大支柱”。而系统的可观测性就是需要完整地采集、分析和展示这三类数据。指标,指标是指在多个连续的时间周期里用于度量的 KPI 数值。一般情况下,指标会按软件架构进行分层,分为系统资源指标(如 CPU 使用率、磁盘使用率和网络带宽情况等)、应用指标(如出错率、服务等级协议 SLA、服务满意度 APDEX、平均延时等)、业务指标(如用户会话数、订单数量和营业额等)。链路跟踪,链路跟踪是指通过 TraceId 的唯一标识来记录并还原发生一次分布式调用的完整过程,贯穿数据从浏览器或移动端经过服务器处理,到执行 SQL 或发起远程调用的整个过程。日志,日志通常用来记录应用运行的执行过程、代码调试、错误异常等信息,如 Nginx 日志可以记录远端 IP、发生请求时间、数据大小等信息。日志数据需要集中化存储,并具备可检索的能力。数据的关联分析让各数据之间产生更多的关联,这一点对于一个可观测性系统而言尤为重要。出现故障时,有效的关联分析可以实现对故障的快速定界与定位,从而提升故障处理效率,减少不必要的损失。一般情况下,我们会将应用的服务器地址、服务接口等信息作为附加属性,与指标、调用链、日志等信息绑定,并且赋予可观测系统一定的定制能力,以便灵活满足更加复杂的运维场景需求。统一监控视图与展现多种形式、多个维度的监控视图可以帮助运维和开发人员快速发现系统瓶颈,消除系统隐患。监控数据的呈现形式应该不仅仅是指标趋势图表、柱状图等,还需要结合复杂的实际应用场景需要,让视图具备下钻分析和定制能力,以满足运维监控、版本发布管理、故障排除等多场景需求。随着云原生技术的发展,基于异构微服务架构的场景会越来越多、越来越复杂,而可观测性是一切自动化能力构建的基础。只有实现全面的可观测性,才能真正提升系统的稳定性、降低 MTTR。因此,如何构建系统资源、容器、网络、应用、业务的全栈可观测体系,是每个企业都需要思考的问题。韧性原则韧性是指当软件所依赖的软硬件组件出现异常时,软件所表现出来的抵御能力。这些异常通常包括硬件故障、硬件资源瓶颈(如 CPU 或网卡带宽耗尽)、业务流量超出软件设计承受能力、影响机房正常工作的故障或灾难、所依赖软件发生故障等可能造成业务不可用的潜在影响因素。业务上线之后,在运行期的大部分时间里,可能还会遇到各种不确定性输入和不稳定依赖的情况。当这些非正常场景出现时,业务需要尽可能地保证服务质量,满足当前以联网服务为代表的“永远在线”的要求。因此,韧性能力的核心设计理念是面向失败设计,即考虑如何在各种依赖不正常的情况下,减小异常对系统及服务质量的影响并尽快恢复正常。韧性原则的实践与常见架构主要包括服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、多 AZ(Availability Zone,可用区)的高可用、单元化、跨区域(Region)容灾、异地多活容灾等。下面结合具体案例详细说明如何在大型系统中进行韧性设计。“双 11”对于阿里巴巴来说是一场不能输的战役,因此其系统的设计在策略上需要严格遵循韧性原则。例如,在统一接入层通过流量清洗实现安全策略,防御黑产攻击;通过精细化限流策略确保峰值流量稳定,从而保障后端工作正常进行。为了提升全局的高可用能力,阿里巴巴通过单元化机制实现了跨区域多活容灾,通过同城容灾机制实现同城双活容灾,从而最大程度提升 IDC(Internet Data Center,互联网数据中心)的服务质量。在同一 IDC 内通过微服务和容器技术实现业务的无状态迁移;通过多副本部署提高高可用能力;通过消息完成微服务间的异步解耦以降低服务的依赖性,同时提升系统吞吐量。从每个应用的角度,做好自身依赖梳理,设置降级开关,并通过故障演练不断强化系统健壮性,保证阿里巴巴“双11”大促活动正常稳定进行。随着数字化进程的加快,越来越多的数字化业务成为整个社会经济正常运转的基础设施,但随着支撑这些数字化业务的系统越来越复杂,依赖服务质量不确定的风险正变得越来越高,因此系统必须进行充分的韧性设计,以便更好地应对各种不确定性。尤其是在涉及核心行业的核心业务链路(如金融的支付链路、电商的交易链路)、业务流量入口、依赖复杂链路时,韧性设计至关重要。所有过程自动化原则技术是把“双刃剑”,容器、微服务、DevOps 以及大量第三方组件的使用,在降低分布式复杂性和提升迭代速度的同时,也提高了软件技术栈的复杂度,加大了组件规模,从而不可避免地导致了软件交付的复杂性。如果控制不当,应用就会无法体会到云原生技术的优势。通过 IaC、GitOps、OAM、Operator 和大量自动化交付工具在 CI/CD(持续集成 /持续交付)流水线中的实践,企业可以标准化企业内部的软件交付过程,也可以在标准化的基础上实现自动化,即通过配置数据自描述和面向终态的交付过程,实现整个软件交付和运维的自动化。要想实现大规模的自动化,需要遵循如下四个基本原则。标准化实施自动化,首先要通过容器化、IaC、OAM 等手段,标准化业务运行的基础设施,并进一步标准化对应用的定义乃至交付的流程。只有实现了标准化,才能解除业务对特定的人员和平台的依赖,实现业务统一和大规模的自动化操作。面向终态面向终态是指声明式地描述基础设施和应用的期望配置,持续关注应用的实际运行状态,使系统自身反复地变更和调整直至趋近终态的一种思想。面向终态的原则强调应该避 免直接通过工单系统、工作流系统组装一系列过程式的命令来变更应用,而是通过设置终态,让系统自己决策如何执行变更。关注点分离自动化最终所能达到的效果不只取决于工具和系统的能力,更取决于为系统设置目标的人,因此要确保找到正确的目标设置人。在描述系统终态时,要将应用研发、应用运维、基础设施运维这几种主要角色所关注的配置分离开来,各个角色只需要设置自己所关注和擅长的系统配置,以便确保设定的系统终态是合理的。面向失败设计要想实现全部过程自动化,一定要保证自动化的过程是可控的,对系统的影响是可预期的。我们不能期望自动化系统不犯错误,但可以保证即使是在出现异常的情况下,错误的影响范围也是可控的、可接受的。因此,自动化系统在执行变更时,同样需要遵循人工变更的最佳实践,保证变更是可灰度执行的、执行结果是可观测的、变更是可快速回滚的、变更影响是可追溯的。业务实例的故障自愈是一个典型的过程自动化场景。业务迁移到云上后,云平台虽然通过各种技术手段大幅降低了服务器出故障的概率,但是却并不能消除业务本身的软件故障。软件故障既包括应用软件自身的缺陷导致的崩溃、资源不足导致的内存溢出(OOM)和负载过高导致的夯死等异常问题,也包括内核、守护进程(daemon 进程)等系统软件的问题,更包括混部的其他应用或作业的干扰问题。随着业务规模的增加,软件出现故障的风险正变得越来越高。传统的运维故障处理方式需要运维人员的介入,执行诸如重启或者腾挪之类的修复操作,但在大规模场景下,运维人员往往疲于应对各种故障,甚至需要连夜加班进行操作,服务质量很难保证,不管是客户,还是开发、运维人员,都无法满意。为了使故障能够实现自动化修复,云原生应用要求开发人员通过标准的声明式配置,描述应用健康的探测方法和应用的启动方法、应用启动后需要挂载和注册的服务发现以及配置管理数据库(Configuration Management Data Base,CMDB)信息。通过这些标准的配置,云平台可以反复探测应用,并在故障发生时执行自动化修复操作。另外,为了防止故障探测本身可能存在的误报问题,应用的运维人员还可以根据自身容量设置服务不可用实例的比例,让云平台能够在进行自动化故障恢复的同时保证业务可用性。实例故障自愈的实现,不仅把开发人员和运维人员从烦琐的运维操作中解放了出来,而且可以及时处理各种故障,保证业务的连续性和服务的高可用性。零信任原则基于边界模型的传统安全架构设计,是在可信和不可信的资源之间架设一道墙,例如,公司内网是可信的,而因特网则是不可信的。在这种安全架构设计模式下,一旦入侵者渗透到边界内,就能够随意访问边界内的资源了。而云原生架构的应用、员工远程办公模式的普及以及用手机等移动设备处理工作的现状,已经完全打破了传统安全架构下的物理边界。员工在家办公也可以实现与合作方共享数据,因为应用和数据被托管到了云上。如今,边界不再是由组织的物理位置来定义,而是已经扩展到了需要访问组织资源和服务的所有地方,传统的防火墙和 VPN 已经无法可靠且灵活地应对这种新边界。因此,我们需要一种全新的安全架构,来灵活适应云原生和移动时代环境的特性,不论员工在哪里办公,设备在哪里接入,应用部署在哪里,数据的安全性都能够得到有效保护。如果要实现这种新的安全架构,就要依托零信任模型。传统安全架构认为防火墙内的一切都是安全的,而零信任模型假设防火墙边界已经被攻破,且每个请求都来自于不可信网络,因此每个请求都需要经过验证。简单来说,“永不信任,永远验证”。在零信任模型下,每个请求都要经过强认证,并基于安全策略得到验证授权。与请求相关的用户身份、设备身份、应用身份等,都会作为核心信息来判断请求是否安全。如果我们围绕边界来讨论安全架构,那么传统安全架构的边界是物理网络,而零信任安全架构的边界则是身份,这个身份包括人的身份、设备的身份、应用的身份等。要想实现零信任安全架构,需要遵循如下三个基本原则。显式验证对每个访问请求都进行认证和授权。认证和授权需要基于用户身份、位置、设备信息、服务和工作负载信息以及数据分级和异常检测等信息来进行。例如,对于企业内部应用之间的通信,不能简单地判定来源 IP是内部...
阅读全文
企业安全痛点之员工行为难管控(一) 安全闲碎

企业安全痛点之员工行为难管控(一)

近期想讲一些我看到企业安全最严重威胁和运营痛点,不出意外,这会是一个系列,前面几篇先说问题,后面再说解决方案,讲到的所有观点和案例,都是通过实践而来,会基本覆盖我的核心安全观。每天只写1000字左右,没写完的痛点拆开写,文章后面附上一张我们给客户的安全意识墙面小贴士。 以往,不管是安全甲方还是乙方,安全工作都是围绕应用跟操作系统去做,比如WAF、IPS、SDL等,解决的都是系统跟应用的问题,所以应用跟操作系统的漏洞越来越少。而唯独只有我跳出来做一家公司解决人的问题,因为在近年我通过渗透测试服务发现,最大的问题不在于系统和应用,而在于人,一切问题都源自于人,人的行为和意识错误导致漏洞频出,今天就说说员工的行为难管控的问题。   员工行为难管控体现在如下几个方面,有没有发生过此类事件可自行对号: 1、滥用云笔记及网盘(重灾区)将vpn密码、wifi密码、服务器密码、阿里云或运营后台密码...记录在个人云笔记、网盘、icloud,技术岗位的人最爱干这事,而且这个行为一旦犯了就会导致企业被直接入侵,什么waf、ips在这种情况下都是摆设。互联网企业的员工,基本上70%以上的员工都会用这些东西,特别是权限多的研发、运维岗位,在以往给客户实施渗透测试服务时,通过这种方式屡试不爽,越是大公司在这块威胁越大,为什么?因为员工多啊,总有X一样的队友。如果员工在公司办公,则能在路由上就能对这些云服务进行禁止访问,但是有几个员工不会把电脑带回家办公呢?这种情况下很难限制员工的行为。 来看看乌云上的案例。a、极客学院某员工印象笔记 b、豌豆荚某员工印象笔记 2、将公司代码存储在Github、oschina、Bitbucket等。    这个行为是研发岗位常犯的错误,稍微大一点的互联网企业几乎无一幸免,可以去乌云网搜索一下“github”看看结果。这些泄露的代码有什么危害呢?代码里面包含的邮箱密码、数据库密码,一旦被搞渗透的人拿到,直接登陆企业邮箱,翻到VPN密码,连接数据库,轻轻松松就能把数据库给拖掉,这样的案例太多太多。 a、金立员工将代码存放到github。  3、员工企业邮箱与外部个人账号密码一致。 密码通用的习惯,据经验大概95%以上的人都这么干,在早之前曝光的网易5亿的会员数据泄露等此类事件,曝光的任何一份数据其实在N年前就已经在地下流传,只是有的人不多,民间有的人甚至将国内知名企业都入侵了个遍,手上偷回来的数据达大几十亿条。试想,中国网民才多少,也就意味着,你只要一出生,别人手里就拿着你的信息,你只要一上网,别人就知道你密码是多少!永远都不要在这些人面前谈隐私两个字,人家只会在心里呵呵一下。一个技术岗位的员工,像研发、运维、测试、安全,或者非技术岗位的客服、运营,员工入职的时候,交接文档有没有?交接文档里面有什么?服务器密码、后台地址密码、阿里云密码等等,不仅有,还注释的清清楚楚、明明白白。另外技术岗位基本都有VPN权限,邮件列表里面一搜“VPN”,密码妥妥的,就算没有,随便编个理由给网络负责人发个申请VPN的邮件,一会儿的时间妥妥的给你把VPN开通好。 今日结束,期待明日,敬请关注微信公众号【互联网安全与创业】。企业安全墙面小贴士: 本文始发于微信公众号(互联网安全与创业):企业安全痛点之员工行为难管控(一)
阅读全文
浅谈软件供应链安全治理与应用实践 安全闲碎

浅谈软件供应链安全治理与应用实践

随着容器、微服务等新技术日新月异,开源软件成为业界主流形态,软件行业快速发展。但同时,软件供应链也越来越趋于复杂化和多样化,软件供应链安全风险不断加剧,针对软件供应链薄弱环节的网络攻击随之增加,软件供应链成为影响软件安全的关键因素之一。近年来,全球针对软件供应链的安全事件频发,影响巨大,软件供应链安全已然成为一个全球性问题。全面、高效地保障软件供应链的安全对于我国软件行业发展、数字化进程推进具有重要意义。近日,在由中国信通院指导、悬镜安全主办的中国首届DevSecOps敏捷安全大会(DSO 2021)现场,《软件供应链安全白皮书(2021)》(以下简称“白皮书”)正式发布。本白皮书着重分析了软件供应链安全,梳理了软件供应链的安全现状,透过现状全面剖析软件供应链的安全风险及面临的安全挑战,有针对性地提出如何对软件供应链的安全风险进行防范与治理,系统阐述了软件供应链安全的防护体系及软件供应链安全的应用实践以供参考,最后白皮书结合现在软件供应链安全的发展趋势进行了全面的分析及展望。由于篇幅有限,仅摘选本报告“软件供应链安全治理”及“软件供应链应用实践”两部分进行分享。 图:《软件供应链安全白皮书》封面一、软件供应链安全治理目前,业界已充分认识到造成网络安全事件出现的主要原因之一,是由于软件开发者在开发过程中对开发工具、开发团队、开发生命周期和软件产品自身管理不当,致使软件存在着安全缺陷,破坏或影响最终用户的信息安全。 通过推进针对软件生命周期进行全流程安全管控的落地实践,有助于从软件生命周期的源头保障软件供应链安全。通过建立软件开发过程中保证软件供应链安全的体系化方法,为软件开发过程中尽可能避免和消除软件的安全缺陷、保证软件供应链安全奠定重要基础。从软件安全开发生命周期角度分析软件供应链安全的应用实践方法,主要有以下几个阶段。1、体系构建阶段SDL 软件安全开发生命周期 微软在21世纪初期的软件产品开发实践中,意识到无法通过技术层面彻底解决软件面临的安全风险。因此,微软尝试从流程和管理的角度解决这个问题,并探索在各个软件开发环节中加入安全过程、把控安全风险,确保每个环节交付到下一环节的交付物都安全可控。于是,针对传统的瀑布式模型微软提出了“SDL 软件安全开发生命周期” 这一概念。 软件安全开发生命周期(SDL),是一个在帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。SDL将软件开发生命周期划分为7 个阶段(如图所示),并提出了 17 项重要的安全活动,旨在将安全集成在软件开发的每一个阶段,以减少软件中漏洞的数量并将安全缺陷降低到最小程度。SDL更侧重的是软件开发的安全保障过程,旨在开发出安全的软件产品。  图 1 SDL 软件安全开发生命周期在 SDL 的 7 个阶段中(如图 1所示),SDL 要求前 6 个阶段的 16 项安全活动,为开发团队必须完成的安全活动。同时,SDL 认为开发团队应该保持灵活性,以便选择更多合适的安全活动,如人工代码分析、渗透测试、相似应 用程序的漏洞分析,以确保对某些软件组件进行更高级别的安全分析。SDL 重视各种工具的使用,重心在从需求阶段到测试阶段的工具集,如威胁建模、静态源代码分析等工具。SDL 的 7 个阶段主要的含义如下: 培训:针对开发团队进行安全意识与能力的培训,以确保 SDL 能有效实施并落地,同时针对新的安全问题与形势 持续提升团队的安全能力; 需求:通过安全需求分析,定义软件产品安全实现过程中所需要的安全标准和相关要求; 设计:通过分析攻击面,设计相对应的功能和策略,降低和减少不必要的安全风险。同时通过威胁建模,分析软 件的安全威胁,提出缓解措施; 实施:按设计要求,实现对应功能和策略,以及缓解措施涉及的安全功能和策略。同时通过安全编码和禁用不安 全的 API,减少实施时导致的安全问题,尽量避免引入编码级的安全漏洞,并通过代码审计等措施来确保安全编码规范的实行; 验证:通过安全测试检测软件的安全漏洞,并全面核查攻击面,各个关键因素上的威胁缓解措施是否得以验证; 发布:建立相应的响应计划,进行最终安全检查,确认所有安全活动均完成后将最终版本发送给客户; 响应:当出现安全事件与漏洞报告时,及时实施应急响应和漏洞修复。在此过程中新发现的问题和安全问题模式,可用于 SDL 的持续改进过程中。DevSecOps DevSecOps 是一种全新的安全理念和模式,由 DevOps 的概念延伸和演变而来。其核心理念是安全是整个 IT 团队 每个人的责任,需要贯穿从开发到运营整个业务生命周期每一个环节才能提供有效保障。 DevSecOps 覆盖编码阶段、测试阶段、预发布阶段、发布阶段、线上运营阶段,强调自动化与平台化,由 CI/CD 平台推动整个开发和运营流程自动化。DevSecOps 依赖于 DevOps 流程工具链(如图 2 所示),将威胁建模工具、安全编码工具、安全测试工具、容器安全检测工具、基线加固工具、漏洞管理工具等自动化工具无缝集成到 DevOps 流程中,进而实现开发 - 安全 - 运营一体化。 图 2 DevSecOps 工具链很多企业在向 DevSecOps 转型时,会发现很多传统的安全工具在集成性和实用性上都难以满足 DevSecOps 的需求, 因此,在 DevSecOps 的不同阶段需要采用不同的 DevSecOps 安全工具(如图 3 所示),这些安全工具主要的共同特点是高度自动化以及可集成性。图 3 DevSecOps 安全工具在不同阶段的自动化程度在软件供应链中每个阶段都在面临不同的安全风险,为了更好的对软件供应链进行风险治理,在 DevSecOps 模式 下,安全开发工具链需要尽量覆盖软件生命周期中的所有阶段(如图 4 所示)。 图 4DevSecOps 模式下软件生命周期除了以上所提到的工具之外,在 DevSecOps 的应用实践过程中,还有一些更为前瞻性的安全工具,具体可参考 DevSecOps 敏捷安全技术金字塔(如图 5所示)。该金字塔在《2020 DevSecOps 行业洞察报告》中首次被提出, 目前已发展到 2.0 版本。其描述了一组层次结构,金字塔底部是基础性技术,越上层的技术对 DevSecOps 实践成 熟度的要求越高。图 5 DevSecOps 敏捷安全技术金字塔 V2.0 版DevSecOps 敏捷安全技术金字塔的不断升级,是为了给业界更好的预测和参考,关于 DevSecOps 敏捷安全技术...
阅读全文
关于云原生应用,这些安全风险了解一下 云安全

关于云原生应用,这些安全风险了解一下

全文共8537字,阅读大约需要17分钟。摘要:云原生应用究竟和传统应用有何不同,安全风险上有何变化?本文将从传统应用风险、应用架构变革带来的风险、云计算模式带来的风险三个维度进行介绍。一.  概述随着云计算技术的不断发展,上云已经不再是一种选择,而是一种共识,是企业数字化转型的必要条件。在相应实践过程中,传统应用存在升级缓慢、架构臃肿、无法弹性扩展及快速迭代等问题,于是近年来云原生的概念应运而生,凭借着云原生弹性、敏捷、资源池和服务化等特性,解决了业务在开发、集成、分发和运行等整个生命周期中遇到的问题。云原生环境中,应用由传统的单体架构转向微服务架构,云计算模式也相应的从基础设施即服务(Infrastructure as a Service,IaaS)转向为容器即服务(Container as a Service,CaaS)和函数即服务(Function as a Service,FaaS)。应用架构和云计算模式的变革是否会导致进一步的风险,这些风险较之传统应用风险又有哪些区别?在讲述云原生应用具体风险前,首先列举以下三个观点,这些观点有助于大家更好地理解本文所讲述的内容。观点一 云原生应用继承了传统应用的风险和API的风险云原生应用源于传统应用,因而云原生应用风险也就继承了传统应用的风险。此外,由于云原生应用架构的变化进而导致应用API交互的增多,可以说云原生应用中大部分交互模式已从Web请求/响应转向各类API请求/响应 ,例如RESTful/HTTP、gRPC等,因而API风险也进一步提升。观点二 应用架构变革将会带来新的风险由于应用架构变革,云原生应用遵循面向微服务化的设计方式,从而导致功能组件化、服务数量激增、配置复杂等问题,进而为云原生应用和业务带来了新的风险。观点三 计算模式变革将会带来新的风险随着云计算的不断发展,企业在应用的微服务化后,会进一步聚焦于业务自身,并将功能函数化,因而出现了无服务器计算(Serverless Computing)这类新的云计算模式,进而引入了Serverless应用和Serverless平台的新风险。综上所述,可以看出云原生应用带来的风险是不容小觑的。本文将从传统应用风险、应用架构变革带来的新风险、云计算模式变革带来的新风险三个维度分别进行介绍,希望可以引发大家更多的思考。二. 传统应用面临的风险云原生应用风险可以参考传统应用风险。传统应用风险以Web应用风险为主,主要包括注入、敏感数据泄露、跨站脚本、使用含有已知漏洞的组件、不足的日志记录和监控等风险。此外,云原生环境中,应用的API交互模式逐渐由“人机交互”转变为“机机交互”,虽然API大量出现是云原生环境的一大特点,但本质上来说,API风险并无新的变化,因而其风险可以参考现有的API风险,主要包括安全性错误配置、注入、资产管理不当、资源缺失和速率限制等风险。有关传统应用风险和API风险的更多细节可以分别参考OWASP组织在2017和2019年发布的应用十大风险报告和API十大风险报告。三.  应用架构变革带来的新风险3.1 云原生应用带来的新风险云原生应用面临的新风险主要体现在:新应用架构的出现。新应用架构遵循微服务化的设计模式,通过应用的微服务化,我们能够构建容错性好、易于管理的松耦合系统,与此同时,新应用架构的出现也会引入新的风险,为了较为完整地对风险进行分析,本文将以信息系统安全等级三要素,即机密性(Confidentiality)、完整性(Integrity)、可用性(Availability)作为导向介绍应用架构变化带来的新风险。机密性受损的风险典型的如信息泄露风险,攻击者可通过利用资产脆弱性和嗅探、暴力破解等攻击方式窃取用户隐私数据,从而造成信息泄露风险。完整性受损的风险典型的如未授权访问风险,攻击者可通过利用资产脆弱性和中间人攻击等行为绕过系统的认证授权机制,执行越权操作,从而造成未授权访问的风险。可用性受损的风险典型的如系统被拒绝服务的风险,一方面,攻击者可通过畸形报文、SYN泛洪等攻击方式为目标系统提供非正常服务,另一方面,系统供不应求的场景也会导致系统遭受拒绝服务风险。本小节接下来的内容,将以信息泄露、未授权访问、拒绝服务为例,分别介绍上述三类风险。3.1.1   数据泄露的风险 云原生环境中,虽然造成应用数据泄露风险的原因有很多,但都离不开以下几个因素:应用漏洞:通过资产漏洞对应用数据进行窃取。密钥不规范管理:通过不规范的密钥管理对应用数据进行窃取。应用间通信未经加密:通过应用间通信未经加密的缺陷对传输中数据进行窃取,进而升级到对应用数据的窃取。3.1.1.1 应用漏洞带来的风险应用中存储的数据多是基于API进行访问,若应用中某API含有未授权访问漏洞,例如Redis未授权访问漏洞,攻击者便可利用此漏洞绕过Redis认证机制,访问到内部数据,进而导致了敏感信息泄露的风险。传统单体应用架构下,由于API访问范围为用户到应用,攻击者只能看到外部进入至应用的流量,无法看到应用内部的流量,所以针对恶意使用API漏洞进行数据窃取造成的损失范围通常是有限的。反观微服务化应用架构,当单体应用被拆分为若干个服务后,这些服务会根据业务情况进行相互访问,API访问范围变为服务到服务(Service to Service),若某服务因API漏洞导致攻击者有利可图,那么攻击者将会看到应用内部的流量,这无疑为攻击者提供了更多的攻击渠道,因而针对数据泄露的风险程度而言,微服务架构相比传统单体应用架构带来的风险更大。此外,随着服务数量达到一定规模,API数量将不断递增,进而扩大了攻击面,增大了数据泄露的风险。3.1.1.2 密钥不规范管理带来的风险在应用的开发过程中,开发者常疏于对密钥的管理从而导致数据泄露的风险,例如开发者将密钥信息、数据库连接密码等敏感信息硬编码在应用程序中,从而增大了诸如应用程序日志泄露、应用程序访问密钥泄露的风险。传统单体应用架构中,开发者常将配置连同应用一起打包,当需要修改配置时,只需登录至服务端进行相应修改,再对应用进行重启便可实现,这种单个集中式配置文件的存储方式从密钥管理风险的角度上讲是相对可控的。微服务应用架构中,应用的配置数量与服务数量的逐渐增多是成正比的,例如微服务应用中会存在各种服务、各种数据库访问、各种环境变量的配置,且各配置支持动态调整。同时,微服务应用架构对服务的配置管理也提出了更高的要求,例如代码与配置可分离、配置支持分布式、配置更新的实时性、配置可统一进行治理等,因而微服务下的配置管理更加复杂,对运维人员的要求更高,密钥管理的难度也在不断提升,最终会造成更大的数据泄露风险。3.1.1.3 应用通信未经加密带来的风险如果应用采用HTTP协议进行数据传输,那么HTTP页面的所有信息将都以纯文本形式进行传输,并且默认不提供任何加密措施。因而在数据传输过程中易被攻击者监听、截获和篡改,典型的攻击流程为攻击者通过Fiddler、Wireshark等抓包工具进行流量监听,截获传输的敏感信息(例如数据库密码、登录密码等),最后攻击者根据自身意图对敏感数据进行篡改并发送至服务端,进而导致数据泄露的风险。传统单体应用架构中,由于网络拓扑相对简单,且应用通信多基于HTTP/HTTPS,因而造成的数据泄露风险多是因为采用了HTTP协议。微服务应用架构中,网络拓扑相对复杂,因遵循分布式的特点,应用间的通信不仅采用HTTP/HTTPS协议,还采用gRPC等协议,由于gRPC协议默认不加密,因而将会导致攻击面的增多,为数据泄露带来了更多的风险。3.1.2  未授权访问的风险云原生环境中,应用未授权访问的风险多是由于应用自身漏洞或访问权限错误地配置导致。3.1.2.1 应用漏洞带来的风险应用漏洞是造成未授权访问的一大因素。未授权访问漏洞非常之多,较为常用的如Redis、MongoDB、Jenkins、Docker、Zookeeper、Hadoop等应用都曾曝光过相关漏洞,例如Docker曝出的Docker Remote API未授权访问漏洞,攻击者可通过Docker Client或HTTP请求直接访问Docker Remote API,进而对容器进行新建、删除、暂停等危险操作,甚至是获取宿主机shell权限。再如MongoDB未授权访问漏洞,该漏洞造成的根本原因在于MongoDB在启动时将认证信息默认设置为空口令,从而导致登录用户可通过默认端口无需密码对数据库进行任意操作并且可以远程访问数据库。从漏洞成因的出发点来看,认证及授权机制的薄弱是其主要原因,在单体应用架构下,应用作为一个整体对用户进行认证授权,且应用的访问来源相对单一,基本为浏览器,因而风险是相对可控的,微服务应用架构下,其包含的所有服务均需对各自的访问进行授权,从而明确当前用户的访问控制权限,此外,服务的访问来源除了用户外还包含内部的其他服务,因而在微服务架构下,应用的认证授权机制更为复杂,为云原生应用带来了更多的攻击面。3.1.2.2 访问权限错误配置带来的风险由于运维人员对用户的访问权限进行了错误配置,进而会增大被攻击者利用的风险。例如,运维人员对Web应用访问权限进行相应配置,针对普通用户,运维人员应只赋予其只读操作,若运维人员进行了错误的配置,例如为普通用户配置了写操作,那么攻击者便会利用此缺陷绕过认证访问机制对应用发起未授权访问攻击。传统应用架构中,应用由于设计相对单一,其访问权限也相对单一,几乎只涉及用户对应用的访问权限这一层面,因此对应的访问权限配置也相对简单。因为访问权限配置简单的特点,用户身份凭据等敏感信息常存储在应用的服务端,一旦攻击者利用配置的缺陷对应用发起未授权访问入侵,就有可能拿到所有保存在后端的数据,从而造成巨大风险。微服务应用架构下,由于访问权限还需涉及服务对服务这一层面,因此将会导致权限映射关系变得更加复杂,相应的权限配置难度也在同步增加,例如一个复杂应用被拆分为100个服务,运维人员需要严密地对每个服务赋予其应有的权限,如果因疏忽导致为某个服务配置了错误的权限,攻击者就有可能利用此缺陷对服务展开攻击,若该服务中包含漏洞,进而可能会导致单一漏洞扩展至整个应用的风险。所以如何对云原生应用的访问权限进行高效率管理成为了一个较难的问题,这也是导致其风险的关键因素。3.1.3 被拒绝服务的风险被拒绝服务是应用程序的面临的常见风险。造成拒绝服务的主要原因包括两方面,一方面是由于应用自身漏洞所致,例如ReDoS漏洞、Nginx拒绝服务漏洞等,另一方面是由于访问需求与资源能力不匹配所致,例如某电商平台的购买API由于处理请求能力有限,因而无法面对突如其来的大量购买请求,导致了平台资源(CPU、内存、网络)的耗尽甚至崩溃。这种场景往往不带有恶意企图,而带有恶意企图的则主要以ACK、SYNC泛洪攻击及CC(Challenge Collapsar)等攻击为主,其最终目的也是应用资源的耗尽。3.1.3.1应用漏洞带来的风险应用漏洞可以导致应用被拒绝服务,那么具体是如何导致的呢?以ReDoS(Regular expression Denial of Service)漏洞为例,ReDoS为正则表达式拒绝服务,攻击者对该漏洞的利用通常是这样的一个场景,应用程序为用户提供了正则表达式的输入类型又没有对具体的输入进行有效验证,那么攻击者便可通过构造解析效率极低的正则表达式作为输入进而在短时间内引发100%的CPU占用率,最终导致资源耗尽,甚至应用程序崩溃的风险。3.1.3.2访问需求与资源能力不匹配带来的风险此处以CC攻击举例,其攻击原理通常是攻击者通过控制僵尸网络、肉鸡或代理服务器不断地向目标主机发送大量合法请求,从而使正常用户的请求处理变得异常缓慢。传统Web场景中,攻击者利用代理服务器向受害者发起大量HTTP GET请求,该请求主要通过动态页面向数据库发送访问操作,通过大量的连接,数据库负载极高,超过其正常处理能力,从而无法响应正常请求,并最终导致服务器宕机。在微服务应用架构下,由于API数量会随着服务数量的递增而递增,因而可能将会导致单一请求生成数以万计的复杂中间层和后端服务调用,进而更容易引起被拒绝服务的风险,例如若微服务应用的API设计未考虑太多因单个API调用引起的耗时问题,那么当外部访问量突增时,将会导致访问需求与资源能力不匹配的问题,使服务端无法对请求作出及时的响应,造成页面卡死的现象,进而会引起系统崩溃的风险。3.2 云原生业务带来的新风险云原生应用业务风险和云原生应用风险有何区别?云原生应用风险主要是Web应用风险,即网络层面的风险,而云原生应用业务风险无明显的网络攻击特征,多是利用业务系统的漏洞或规则对业务系统进行攻击来牟利,从而造成一定的损失。此外,与传统应用架构中的业务风险不同,微服务应用架构中,若服务间的安全措施不完善,例如用户授权不恰当、请求来源校验不严格等,将会导致针对微服务业务层面的攻击变得更加容易,例如针对一个电商应用,攻击者可以对特定的服务进行攻击,例如通过API传入非法数据,或者直接修改服务的数据库系统等。攻击者可以绕过验证码服务,直接调用订单管理服务来进行薅羊毛等恶意操作。攻击者甚至可以通过直接修改订单管理和支付所对应的服务系统,绕过支付的步骤,直接成功购买商品等。综上,应用微服务化的设计模式带来的业务风险可包含两方面,一方面是未授权访问风险,典型场景为攻击者通过权限绕过对业务系统的关键参数进行修改从而造成业务损失,另一方面则是API滥用的风险,典型的是对业务系统的薅羊毛操作。3.2.1 未授权访问的风险在云原生业务环境中,造成未授权访问风险的原因,可以大致分为业务参数异常和业务逻辑异常两方面,为了更为清晰的说明上述异常如何导致未授权访问的风险,这里以一个微服务架构的电商系统举例说明。如图1所示:图 1某电商系统流程图3.2.1.1业务参数异常带来的风险API调用过程中往往会传递相关的参数。参数的取值根据业务场景的不同会有不同的取值范围。例如商品数量必须为非负整数,价格必须大于0等。若API对相应参数的监测机制不完善,那么攻击者便可通过输入异常参数导致业务系统受到损失。例如在图1所示的电商系统中,若商品价格只在商品介绍服务中进行校验,而未在订单管理和支付服务中进行校验,那么攻击者则可以通过直接调用订单管理和支付服务的API将订单价格修改为0元或者负值,从而给业务系统造成损失。3.2.1.2业务逻辑异常带来的风险相比于前一类异常,此类异常一般较为隐蔽。攻击者采用某些方法使API调用的逻辑顺序出现异常,包括关键调用步骤缺失、颠倒等。例如在图1所示的电商系统中,攻击者可以利用漏洞绕过支付的步骤直接提交订单。这样就会出现业务逻辑关键步骤缺失的情况,进而会为业务系统带来损失,例如验证码绕过异常就属于业务逻辑异常的一种。3.2.2 API滥用的风险针对此类风险,通常指的是攻击者对业务系统的薅羊毛操作,风险成因则是由于业务频率异常所致,这里以电商系统举例说明。业务频率异常主要指针对一个或一组API的频繁调用。业务系统往往通过图形验证码的方式来避免机器人刷单的操作。例如在图1所示的电商系统中,攻击者可以绕过验证码所对应的服务,直接对订单进行操作,进而实现机器刷单,对电商进行薅羊毛。四. 云计算模式变革带来的新风险作为一种新的云计算模式,Serverless具备许多特性,典型的主要有输入源的不确定性、服务器托管云服务商、供应商锁定等,这些特性可能会给Serverless带来新的风险。此外,由于Serverless最终呈现的还是多个函数组成的应用,且被Serverless提供的服务端运行,因此Serverless风险还应包括Serverless应用的风险及Serverless平台的风险。最后Serverless因购买、部署成本低、函数访问域名相对可信等将会使Serverless面临被滥用的风险。4.1 Serverless特征带来的风险4.1.1  输入源不确定带来的风险Serverless函数是由一系列事件触发的,如云存储事件(S3、Blobs和其他云存储)、流数据处理(如:AWS Kinesis)、通知(如:SMS、电子邮件、IoT)等,鉴于此特性,我们不应该把来自API调用的输入作为唯一攻击面。此外,我们不再控制源到资源间的这条线,如果函数被邮件或数据库触发,将无处可设置防火墙或任何其他控制措施来验证事件源。可见输入源的不确定性将可能导致一定的风险。在传统应用程序开发中,开发者根据自身实践经验,在数量有限的可能性中可判定出恶意输入来源,但Serverless模式下函数调用是由事件源触发,输入来源的不确定性限制了开发者的判定。例如当函数订阅一个事件源后,该函数在该类型的事件发生时被触发,这些事件可能来源于FaaS平台,也可能来源于未知的事件源,对于来源未知的事件源可以被标注为不受信任。在实际应用场景中,如果开发者没有良好的习惯对事件源进行分类,则会经常导致将不受信任的事件错认为是FaaS平台事件,进而将其视为受信任的输入来处理,最终带来了风险。 具体地,输入来源的不确定性会为Serverless应用带来注入的风险,与传统应用相同的是,注入攻击过程与并无太大区别,不同的是攻击向量的变化,传统应用中用于注入攻击的向量通常指攻击者可以控制或操纵应用输入的任何位置,但Serverless应用由于输入的不确定性因而带来了更大的攻击面。4.1.2 服务托管云服务厂商带来的风险传统应用中,例如Web应用常部署在本地/远程服务器上,关于服务端的操作系统漏洞修补、网络拓扑的安全、应用在服务端的访问日志及监控等均需要特定的运维人员去处理,而Serverless的服务器托管云服务商的特点将导致开发者无法感知到服务器的存在,实际上开发者也无须对服务器进行操作,只需关注应用本身的安全即可,服务器的安全则交由云厂商管理Serverless的这一特征实际上降低了安全风险。4.1.3  供应商锁定带来的风险“供应商锁定”是指用户依赖特定供应商提供的产品及服务,并且在不产生实质性转换成本或运营影响的情况下无法使用其他供应商的云服务,在Serverless中,“供应商锁定”是目前存在的一大问题,例如用户选择AWS作为应用的运行环境,由于一些原因,该应用需迁移至Microsoft Azure平台,但“供应商锁定”的问题导致无法轻易的将之前运行的应用及使用的相应资源如S3存储桶等平滑迁移至Microsoft Azure平台中,进而导致企业面临应用转换成本的风险。4.2 Serverless应用风险Serverless应用属于云原生应用,其应用本身与传统应用基本是相同的,唯一区别是应用代码编写需要参照云厂商提供的特有代码模版,而传统应用通常没有这个限制。Serverless应用属于云原生应用,云原生应用又源于传统应用,因而传统应用面临的风险几乎可以全面覆盖Serverless应用风险,关于风险分析部分可以参考之前传统应用风险的内容,更详细的内容可以参考OWASP组织在2017年发布的Serverless应用十大风险报告。4.3 Serverless平台风险Serverless平台主要指FaaS平台,目前主流的FaaS平台分为两种类型,一种是面向公有云提供商的FaaS平台,常见的有AWS Lambda、Microsoft Azure Functions、Google Cloud Functions等,另一方面则是面向私有云的FaaS平台,此类以开源项目居多,且均支持在Kubernetes上进行部署,常见的有Apache OpenWhisk、Kubeless、OpenFaaS、Fission等。类似在IaaS平台上运行虚机、PaaS平台上运行操作系统和应用,FaaS平台较之上述平台的主要区别为其运行的是一个个Serverless函数。FaaS平台自身负责云环境地安全管理,主要包括数据、存储、网络、计算、操作系统等。4.4 Serverless被滥用的风险Serverless被滥用具体是指攻击者通过恶意构建Serverless函数并利用其充当整个攻击中的一环,这种方式可在一定程度上规避安全设备的检测。导致Serverless被滥用的原因主要包括以下几点:1. 云厂商提供Serverless函数的免费试用近些年,各大云厂商为了用户体验,均对用户提供免费的Serverless套餐,包括每月免费的函数调用额度,这种方式虽然吸引了更多的用户去使用Serverless函数, 但也使得攻击者的攻击成本大幅降低。2. 用户部署Serverless函数的成本低由于Serverless服务端托管云厂商的机制,故用户只需实现函数的核心逻辑,而无须关心函数是如何被部署及执行的,利用这些特点,攻击者可以编写对其有利的Serverless函数并能省去部署的成本。3. Serverless函数访问域名可信当用户部署完Serverless函数后,需要通过触发器去触发函数的执行,通常用户使用云厂商提供的API网关作为触发器,创建API网关触发器之后,云厂商会为用户提供一个公网的域名,用于访问用户编写的Serverless函数。需要注意的是,该公网域名通常是云厂商域名相关的子域名,因而是相对可信的,鉴于此,攻击者可以利用函数访问域名的可信去隐藏其攻击资产,躲避安全设备的检测。五. 总结本文详细分析了云原生应用面临的风险,可以看出,云原生应用相比传统应用面临的风险主要为应用架构变革及新的云计算模式带来的风险,而针对应用本身的风险并无较大变化,因而对云原生应用架构和无服务器计算模式的深度理解将会有助于了解整个云原生应用安全。参考文献 https://owasp.org/www-project-top-ten/ https://owasp.org/www-project-api-security/  https://netflixtechblog.com/starting-the-avalanche-640e69b14a06  https://www.owasp.org/index.php/OWASP_Serverless_Top_10_Project  https://github.com/apache/openwhisk  https://github.com/kubeless/kubeless 
阅读全文
使用基于注意力的强化学习方法进行WEB应用测试 安全闲碎

使用基于注意力的强化学习方法进行WEB应用测试

原文作者:Yan Zheng, Yi Liu, Xiaofei Xie, Yepang Liu, Lei Ma, Jianye Hao, and Yang Liu原文标题:Automatic Web Testing Using Curiosity-Driven Reinforcement Learning原文链接:https://arxiv.org/pdf/2103.06018.pdf笔记作者:[email protected]简介该文为发表于ICSE 2021的Automatic Web Testing Using Curiosity-Driven Reinforcement Learning。其研究主要在于端到端对web应用程序进行自适应地测试。针对Web应用的测试一直被认为是一项困难的任务。即使在今天,web测试仍然严重依赖于人工操作,而自动化web测试远未达到人工的水平。在篇论文中,作者使用好奇心驱动的强化学习方法以生成满足时序逻辑关系的高质量测试用例,并测试过程中逐步构建了一个自动机,以提高测试效率。方法作者为他提出的web应用测试框架命名为WebExplor,其目的是自动化生成不同的操作序列,让测试覆盖到web应用的更多行为。为了实现这一目标,WebExplor主要采用好奇心驱动的强化学习(RL)来不断优化策略,并更够在线学习,不像传统的AI方案那样需要先训练好模型才能部署。如下图所示,WebExplor主要包括三大组件,分别是Web应用抽象化、基于强化学习的测试用例生成和有限自动机。状态提取首先,需要从Web程序中抽象出用于强化学习的状态集合,如果直接用网页来代表状态,那么由于现代web应用的动态特性,会得到一个巨大的状态集合,这在强化学习中是无法接受的。为了解决状态爆炸问题,WebExplor将相同业务逻辑的页面归结于同一个状态。举例来讲,如果一个页面中用表格来展示用户的购物车信息,尽管可以通过增添或减少商品来创建近乎无穷多个不同的页面,但是由于其业务逻辑相同,所以认为属于同一个状态。具体来讲,如果两个页面的URL相同且HTML内容相似,那么它们很可能属于同一业务逻辑。实际操作中,每遇到一个新页面,WebExplor会过滤部分页面内容,只保留可操作元素(按钮、输入框、选择器等),然后将该页面与之前以保存的所有状态进行匹配,如果URL不相同或页面元素相似度低于设定的阈值,则作为一个新的状态添加到状态集合中。好奇心驱动的强化学习之后,为了通过强化学习的方法训练一种生成不同测试用例的探索策略,需要定义一个有效的奖励函数来确定最优策略。在针对web应用的测试中,其目标为尽可能多地探索web应用程序的不同行为。由于目标模糊(相对与有明确奖励目标的任务,如电子游戏),WebExplor引入好奇心机制,这一机制是为了解决强化学习中中的粗略奖励问题而提出的。作者设计了一个好奇心驱动的奖励函数,它采用了一种通用的适应性机制来指导探索,从而可以达到不同的状态。基于好奇心机制的驱动,使用Q-Learning算法学习用例生成策略。有穷自动机宏观指导最后,对于一个较大的状态空间进行探索,强化学习可能会无法到达某一状态的问题。如下图所示,例如某办公系审核流程中,状态S0到状态Sm+1之间虽然每一步跳转的概率都是0.9,但是到达Sm+1的概率只有0.95。为了应对这一问题,WebExplor利用有穷自动机在宏观层面对web应用的探索过程进行指导。当探索一定次数仍未发现新的状态时,则使用有穷自动机找到一个好奇心度最高的目标状态,然后让强化学习的智能体直接过度到这一状态继续探索。实验在实验阶段,作者主要通过实验结果说明一下四个问题:WebExplor的代码覆盖率如何?WebExplor的故障探测率如何?有限自动机是否有效指导了针对web应用的探测过程?WebExplor在真实环境下效果如何?如下表所示,作者针对多个GIthub上多个流行项目(高于50 stars)进行测试,实验就过表明其代码覆盖率和故障探测率指标普遍优于其他无导航模型方法(Crawljax, Random)和基于导航模型的方法(DIG, SUBWEB),无论其导航模型时自动生成(APO)还是需要人工辅助(MPO)。此外,如下图所示,使用有穷自动机对WebExplor的探测过程进行宏观指导时,可以更早得获得更高的指标,以提高探测效率,并且最终结果也普遍由于不使用有穷自动机的WebExplor。安全学术圈招募队友-ing, 有兴趣加入学术圈的请联系secdr#qq.com 本文始发于微信公众号(安全学术圈):使用基于注意力的强化学习方法进行WEB应用测试
阅读全文
常见Web应用安全漏洞原理与防御介绍 安全闲碎

常见Web应用安全漏洞原理与防御介绍

    Web应用是指采用B/S架构、通过HTTP/HTTPS协议提供服务的统称。随着互联网的普及,Web应用已经融入到我们生活中的方方面面。在企业信息化的过程中,越来越多的应用也都架设在Web平台上。在这些Web访问中,大多数应用不是静态的网页浏览,而是涉及到服务器侧的动态处理。此时,如果技术人员的安全意识不足,例如对程序参数输入等检查不严格,就会导致Web应用安全问题层出不穷。轻则篡改网页内容,重则窃取重要内部数据,更为严重的则是在网页中植入恶意代码,使得网站访问者受到侵害。这使得越来越多的用户关注应用层的安全问题,Web应用安全的关注度也逐渐升温。    本文根据当前Web应用的安全情况,列举了Web应用程序常见的攻击原理及危害,并给出如何避免遭受Web攻击的建议。SQL注入    当应用程序将用户输入的内容,拼接到SQL语句中,一起提交给数据库执行时,就会产生SQL注入威胁。由于用户的输入,也是SQL语句的一部分,所以攻击者可以利用这部分可以控制的内容,注入自己定义的语句,改变SQL语句执行逻辑,让数据库执行任意自己需要的指令。通过控制部分SQL语句,攻击者可以查洵数据库中任何自己需要的数据,利用数据库的一些特性,可以直接获取数据库服务器的系统权限。    本来SQL注入攻击需要攻击者对SQL语句非常了解,所以对攻击者的技术有一定要求。但是现在已经出现了大量SQL注入利用工具,可以让任何攻击者,只要点几下鼠标,就能达到攻击效果,这使得SQL注入的威胁极大增加。XSS    跨站脚本攻击(Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets,    CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意html 代码,当用户浏览该页之时,嵌入其中Web里面的html代码会被执行,从而达到恶意攻击用户的特殊目的。反射型跨站脚本攻击    攻击者会通过社会工程学手段,发送一个URL连接给用户打开,在用户打开页面的同时,浏览器会执行页面中嵌入的恶意脚本。存储型跨站脚本攻击    攻击者利用web应用程序提供的录入或修改数据功能,将数据存储到服务器或用户 cookie中,当其他用户浏览展示该数据的页面时,浏览器会执行页面中嵌入的恶意脚本。所有浏览者都会受到攻击。命令注入    命令注入和SQL注入差不多,只不过SQL注入是针对数据库的,而OS命令注入是针对操作系统的。OS命令注入攻击指通过Web应用,执行非法的操作系统命令达到攻击的目的。只要在能调用Shell函数的地方就有存在被攻击的风险。倘若调用Shell时存在疏漏,就可以执行插入的非法命令。    命令注入攻击可以向Shell发送命令,让Windows或Linux操作系统的命令行启动程序。也就是说,通过命令注入攻击可执行操作系统上安装着的各种程序。跨站请求伪造    CSRF(Cross Site Request Forgery),利用已登录的用户身份,以用户的名义发送恶意请求,完成非法操作。    例如,如果用户浏览并信任具有CSRF漏洞的网站A,则浏览器会生成相应的cookie,并且用户访问危险的网站B而不退出网站。危险网站B要求访问网站A并提出要求。浏览器使用用户的cookie信息访问网站A。由于网站A不知道是用户自身发出的请求还是危险网站B发出的请求,因此将处理危险网站B的请求,从而完成了用户操作目的的模拟。这是CSRF攻击的基本思路。越权访问    越权漏洞是指应用在检查授权(Authorization)时存在纰漏,使得攻击者在获得低权限用户帐后后,可以利用一些方式绕过权限检查,访问或者操作到原本无权访问的高权限功能。在实际的代码安全审查中,这类漏洞往往很难通过工具进行自动化检测,因此在实际应用中危害很大。其与未授权访问有一定差别。目前存在着两种越权操作类型:垂直越权操作和水平越权操作。    垂直越权漏洞,也称为权限提升,是一种“基于URL的访问控制”设计缺陷引起的漏洞。由于Web应用程序没有做权限控制或者仅在菜单上做了权限控制,导致恶意用户只要猜测其他管理页面的URL,就可以访问或控制其他角色拥有的数据或页面,达到权限提升的目的。    水平越权漏洞,是一种“基于数据的访问控制”设计缺陷引起的漏洞。由于服务器端在接收到请求数据进行操作时没有判断数据的所属人而导致的越权数据访问漏洞。如服务器端从客户端提交的request参数(用户能够控制的数据)中获取用户id,恶意攻击者通过变换请求ID的值,查看或修改不属于本人的数据。    随着互联网和Web技术的广泛使用,Web应用安全所面临的挑战日益严峻,Web系统时时刻刻都在遭受各种攻击的威胁。因此,像BI这种典型的Web应用,需要制定一个完整的Web攻击防御解决方案。在这里以Smartbi安全性为例,向大家介绍怎么做到防患于未然。    首先,Smartbi通过软件自带的安全补丁工具包定期进行补丁文件的更新,并且支持热修复;其次,Smartbi从Web端、源码、组件等方面对产品进行安全问题自查,同时也通过与“补天众测平台”和“广东赛评检测中心”等第三方机构进行合作,定期对产品进行安全扫描,并积极配合解决发现的漏洞。最后,通过官方的技术支持渠道,及时响应用户对安全问题的咨询和求助。    由此可见,Smartbi正是通过建立全方位的安全漏洞防御机制来确保用户信息的安全。但是,Web攻击防御是一个长期持续的工作,随着Web技术的发展和更新,Web攻击手段也不断发展,针对这些最新的安全威胁,需要及时调整Web安全防御策略,使Web应用在一个安全的环境中为企业服务。好文推荐应急响应的基本流程(建议收藏)渗透测试面试近期热门题干货|安全工程师面试题汇总渗透工程师常用命令速查手册Web常见漏洞描述及修复建议流量分析与日志溯源的个人理解规范报告中的漏洞名称以及修复建议应急响应 | 7款WebShell扫描检测查杀工具11个步骤完美排查Linux机器是否已经被入侵欢迎关注 系统安全运维五年甲方安全经验,每日坚持学习与分享,麻烦各位师傅文章底部给点个“再看”,感激不尽 原文始发于微信公众号(系统安全运维):常见Web应用安全漏洞原理与防御介绍
阅读全文
Mac自制应用+图标 安全闲碎

Mac自制应用+图标

    咳咳,前两天刚说完不再发文章了就发现电脑还有一篇存货,然后今天正好发出来,还有上篇文章说的割韭菜的事情,我前年还是去年搞了个靶场,貌似叫多啦吧,然后就有个“大佬”朋友圈喷我,还有前几天写的一篇针对大学生的,我记得文章里有一句话是:“要认清自己的情况及认清自己的能力,做事要做与自己能力相等的事情,要酬劳要与自己能力相等,起码不要超出太多的吧”。    可是为什么喷我的人都看不到这句话呢?这也是我退圈一个小原因吧,太多人容易被带节奏了,也有太多人不会认真去看一篇文章说甚至一段话,很喜欢断章取义。    骂我的,喷我的,我很少去反驳,第一就是人太特么多了,我喷不过来。第二就是没意义,我感觉你们喷我都是被带节奏的喷我,一点实质性的东西都没有,还有之前说我线下培训收了人家8000块钱只教人家python的那个兄台,哥们,8000块钱住一俩月三层独栋大别墅,每天都有肉吃,吃喝拉撒都有人照顾,出去玩有人花钱,每周1-2次按摩有人花钱,每周2-3次网吧有人花钱,你乐意么?    还有不是我只教python,是我用了俩三个月都没讲明白python,两个人,一个人一俩星期就学会了,另一个俩三月没学明白,我能怎么办?而且没学明白的那哥们也没给我学费,从哪来的我坑人家学费这一说呢?所以喷我喷的我都很无语了好吧,凭空捏造凭空想象?    至于谁传的这事我心里也知道是谁,毕竟就那么几个人,你这么搞我说实话也没意义,和我熟悉的人都知道我人品,我自己被坑了我都不乐意让我身边的人被坑,你感觉我不好那只能说我跟你根本不熟,那些认识我两三年 三四年的哥们可以找找问问看吧。    你搞我心态我还得对外说你人品不好,我对你也不差,你给我背后来一刀子我肯定咽不下这口气的好吧?    然后还有个事情就是本人想找工作,渗透方面的叭,地区的话离河北越近越好,有招聘需求的可以联系一下我微信:backxyh 点击下图中的“自动操作”启动应用。启动后点击“应用程序”,然后点击“选取即可”左边拉到最下面找到“运行shell脚本”,然后拖拉到右边填写burp目录地址,然后换行输入运行命令(换行就可以了,不需要添加分隔符),点击右上角的“运行”,如果运行成功就可以储存到“应用程序”里边啦之后在应用程序中找到你的脚本:右键显示简介,然后把文件夹内的icns图标拖到左上角搞定~其他的也是一样的操作哦~ 本文始发于微信公众号(云剑侠心):Mac自制应用+图标
阅读全文
商用密码应用安全性评估测评系列材料【补充 】 未分类

商用密码应用安全性评估测评系列材料【补充 】

《商用密码应用安全性评估管理办法》《商用密码应用安全性测评机构管理办法》《信息系统密码应用基本要求》《信息系统密码应用测评要求》https://www.oscca.gov.cn/sca/xwdt/2020-12/08/1060792/files/d2f1665e78bb4c658ca06bfaaa16eae1.pdf《商用密码应用安全性评估测评作业指导书(试行)》《信息系统密码应用测评过程指南》https://www.oscca.gov.cn/sca/xwdt/2020-12/08/1060792/files/f84f69611d764ab8be17ea1be3332b5b.pdf《信息系统密码应用高风险判定指引》https://www.oscca.gov.cn/sca/xwdt/2020-12/08/1060792/files/c45eb79325bd44e2a768c90527261d30.pdf《商用密码应用安全性评估量化评估规则》https://www.oscca.gov.cn/sca/xwdt/2020-12/08/1060792/files/b3efec60b86b47788c2eee258fd904eb.pdf《商用密码应用安全性评估报告模板(2020版)》https://www.oscca.gov.cn/sca/xwdt/2020-12/08/1060792/files/7ff1dcf8091c4f1d88b9353874ab4911.docx《商用密码应用安全性评估对象基本情况调研表》文件下载地址:https://www.oscca.gov.cn/sca/xwdt/2020-12/08/content_1060792.shtml《信息系统密码应用测评要求》等5项 密码应用与安全性评估指导性文件发布发布日期:2020-12-08来源:国家密码管理局【字体:大 中 小】打印     依据《中华人民共和国密码法》等法律法规,中国密码学会密评联委会组织编制了《信息系统密码应用测评要求》等5项指导性文件,现已公开发布,可供相关单位开展商用密码应用与安全性评估工作参考。有关问题建议,可发送邮件至[email protected]。附件:1.信息系统密码应用测评要求   2.信息系统密码应用测评过程指南   3.信息系统密码应用高风险判定指引   4.商用密码应用安全性评估量化评估规则   5.商用密码应用安全性评估报告模板(2020版)《商用密码应用方案》http://www.tjgmj.gov.cn/aRCtrl/toCryAppScheme.do《政务信息系统密码应用与安全性评估工作指南》https://www.oscca.gov.cn/sca/xwdt/2020-09/16/1060781/files/e96db2ce62e24aa4866bad73ee4f21ce.pdfhttps://www.oscca.gov.cn/sca/xwdt/2020-09/16/content_1060781.shtml《政务信息系统密码应用与安全性评估工作指南》公开发布 发布日期:2020-09-16来源:国家密码管理局【字体:大 中 小】打印     根据《国家政务信息化项目建设管理办法》(国办发〔2019〕57号)密码应用与安全性评估要求,依据《中华人民共和国密码法》及商用密码管理规定,中国密码学会密评联委会组织编制的《政务信息系统密码应用与安全性评估工作指南》(2020版)已于日前发布,用于引导非涉密国家政务信息系统建设单位和使用单位规范开展商用密码应用与安全性评估工作。附件:《政务信息系统密码应用与安全性评估工作指南》(2020版)政务网站系统国产密码应用方案1. 概述根据有关资料,截止2018年6月1日,我国正在运行的政府网站有22206家。截止2019年3月18日,天津市在线运行政府网站共113个。根据CNCERT/CC 2018年年报,2018年,CNCERT/CC自主监测发现约5.3万个针对我国境内网站的仿冒页面,页面数量较2017年增长了7.2%。其中,仿冒政务类网站数量明显上升,占比高达25.2%。2018年,被篡改的政府网站216个(2017年为618个)。由此可见,政务类网站的安全性不容忽视。政务类网站建设可参照GB/T 31506-2015 《信息安全技术政府门户网站系统安全技术指南》,其安全基础设施包括可信路径、公钥基础设施等。政府门户网站系统逻辑结构示意图2. 政务网站密码安全需求对存储的网页进行完整性保护,避免非法篡改对访问系统的管理员身份进行鉴别,以确保管理员身份的真实性,避免非法管理员进入系统;对系统重要日志进行完整性保护,避免非法人员篡改日志记录。3. 政务网站密码应用方案3.1 总体架构3.2 部署示例3.3 密码应用技术方案物理和环境安全依托于现有的机房环境和办公环境的安全措施,利用电子门禁系统对人员身份进行确认,防止非法人员进入;利用视频监控系统对人员行为进行记录。选用符合GM/T 0036标准的电子门禁系统,并对人员进出记录等数据进行完整生保护。在视频监控系统中部署视频采集加密系统,对视频监控音像记录等数据进行保护。网络和通信安全网络与通信的安全防护实施要点是保证信意内容的完整性。安全接入网关(SSL VPN产品)对网络通信进行保护,实现对网站自身身份的认证,防止网站系统的内容在传输过程中网站内容被篡改。设备和计算安全部署终端安全防护系统,结合管理员USBKey+数字证书方式,对登录计算机终端操作系统的用户身份进行鉴别,对用户登录的日志信息进行完整生保护,并对终端操作系统进行防护。应用与数据安全管理员身份鉴别、可信内容发布用户访问密钥管理方案采用某电子政务电子认证服务机构提供的电子认证服务。密钥均由商用密码产品负责全生命周期管理。网站管理员在安全接入网关投入使用前,按照密码操作规程在用户环境中对设备进行初始化,完成密钥生成。在密码产品运维管理过程中,按照密码操作规程对密钥进行备份(恢复)、归档、销毁等管理操作。密码管理人员应按照密码操作规程对密钥存储介质进行安全管理。安全管理方案密码安全管理制度和操作规范执行记录应急处置方案4. 密码设备和系统的选择应选择具有国家密码管理局颁发的商用密码产品型号证书的USBKey、SSL VPN安全网关、安全浏览器等。5. 密码算法配置与使用使用的密码产品需配置使用国产密码算法SM2/SM3/SM4。政务云系统国产密码应用方案1. 概述政务云用于承载各级政务部门公共服务、社会管理业务信息和数据,并满足跨部门业务协同、数据交换与共享的需要,提供IaaS、 PaaS和SaaS云计算服务。政务云建设涉及云建设单位、密码建设单位、政务云运营单位、政务云使用单位、云服务提供商、政务云监管以及云上的角色(党政机关用户及其业务使用者等)。政务云平台以建设和提供方的需求与服务能力,分为以提供基础设施即服务(IaaS)的政务云平台、提供平台即服务(PaaS)的政务云平台以及提供软件即服务(SaaS)的政务云平台。本方案以选择提供PaaS能力的政务云平台建设和提供方为示例政务云平台建设框架2. 密码安全需求设备和计算安全不同虚拟机之间、虚拟机与宿主机之间应进行安全隔离。虚拟机的镜像和快照应进行安全保护,保证数据的完整性。数据与应用安全数据资源及所在的网络、系统平台等需要具备详细的访问控制和审计措施来防止数据泄露。对文件系统、存储和数据库等采用加密措施,保证数据的机密性。网络、系统平台自身需要具备足够的控制和监视手段来防止信息被篡改。管理安全基础设施、密码设施的管理和使用,采用基于密码技术的多因素身份鉴别机制。采用安全的网络通信协议,保证数据的保密性和完整性。制度和人员安全云平台需具有相关的制度保证操作的规范性,避免因非法操作或误操作导致的密钥删除、密钥泄露等重大安全问题产生。3. 密码应用简要方案物理和环境安全依托于现有的机房环境的安全措施,利用电子门禁系统对人员身份进行确认,防止非法人员进入;利用视频监控系统对人员行为进行记录。选用符合GM/T 0036标准的电子门禁系统,并对人员进出记录等数据进行完整性保护。在视频监控系统中部署视频采集加密系统,对视频监控音像记录等数据进行保护。网络和通信安全远程管理采用VPN建立安全通道实现安全远程管理。VPN设备遵循GM/T 0024《SSLVPN技术规范》或GM/T 0022《IPSec VPN技术规范》等标准。设备和计算安全基础防护利用密码技术对登录虚拟化操作系统用户的身份鉴别(采用数字证书+USBKey)和访问控制以及对日志数据的完整性等进行保护。对安全能力要求高的政务云平台,应采用基于商密系列算法设计的政务云平台。密码计算资源池以实体机或利用虚拟化技术的虚拟机,为信息系统提供数据加解密、签名验签、杂凑等密码运算服务,实现信息的机密性、完整性、真实性和不可否认性保护。密码机与云密码机管理需要采用安全浏览器,可基于SM2标准SSL VPN协议,实现身份鉴别及通信的保密性和完整性。设备管理与业务管理分开,采用各级管理员基于角色的管理体系,各自具有不交叉的权限,提供证书加智能密码钥匙/智能IC卡等多因素认证手段。提供可追溯的审计记录,使用密码技术保证审计记录的完整性;保证管理员利用网络对设备进行远程管理时的身份鉴别,防止身份信息泄露。应用和数据安全数据库加密采用数据库加密系统或数据库加密网关解决数据库加密问题,并对数据库操作日志进行保护。加解密密钥由硬件密码卡/密码机产生。若采用数据库加密网关会极大的影响网络性能,涉及安全性要求较高的数据库环境,采用HSM和数据库加密软件共同完成对主密钥的保护;采用SM4算法和随机密钥对数据或字段进行加密。采用密钥管理系统实现对云中多租户、多存储类型加密需求的密码保护和管理能力。数据存储加密操作系统中部署存储加密系统软件或直接部署存储加密网关,实现对存储资源、虚拟存储、文件系统、文件数据等的加解密功能。对不同的文件和目录/文件系统/云磁盘应采用不同的加密密钥进行加密;采用SM4算法和随机密钥对数据或字段进行加密。采用密钥管理系统实现对云中多租户、多存储类型加密需求的密码保护和管理能力。应用安全在代码和应用设计部分采用符合国家相关要求的商密算法以保证其自身的安全性和健壮性。需要采用密码技术对信息系统的访问控制策略(如安全策略、资源访问控制列表等)、重要信息资源(如数据标签)等进行保护,防止被非法篡改。对重要应用程序(如重要业务系统、关键应用系统)的加载和卸载,需要采用密码技术进行控制,防止重要应用程序在加载过程中被非法篡改。密钥管理方案数字证书均通过外部电子认证服务机构统一发放和管理。密码管理人员在密码设备投入使用前,按照密码操作规程在用户环境中对设备进行初始化,完成密钥生成。在密码产品运维管理过程中,按照密码操作规程对密钥进行备份(恢复)、归档、销毁等管理操作。密钥管理系统为云计算平台、云密码功能服务、云密码业务服务、密码系统、应用终端等提供密钥管理相关的支持活动,如加密密钥托管、密钥安全隔离和存储、密钥安全访问、密钥高可用等服务的一种密钥管理基础设施。密码管理人员应按照密码操作规程对密钥存储介质进行安全管理。用户/终端私钥:用户/终端私钥可采用智能密码钥匙等硬件密码产品或软件密码产品进行保护。云服务端私钥:云服务端密钥存放在云密码资源池的硬件密码设备中。密钥加密密钥:密钥加密密钥存放在安全的硬件密码设备中或受密码设备内其他密钥加密密钥加密保护。数据加密密钥:数据加密密钥指用于数据加密存储或数据加密传输的对称密钥。数据加密密钥包括会话密钥和存储加密密钥。安全管理方案密码安全管理制度和操作规范执行记录应急处置方案4. 密码设备和系统的选择应选择具有国家密码管理局颁发的商用密码产品型号证书的服务器密码机、云密码机、密钥管理系统、USBKey、SSL VPN安全网关、数据库加密系统、安全浏览器等。5. 密码算法配置与使用使用的密码产品需配置使用国产密码算法SM2/SM3/SM4。政府机关移动办公安全解决方案1.方案背景       随着 Internet 技术和移动技术的不断发展,越来越多的政府机关已依托互联 网组建了自己的网上办公系统与业务应用系统,多数单位也已应用了移动 APP 使移动办公成为可能。       在此过程中,如何解决基于开放系统互联下的移动办公数据及文件的安全性、 个人身份认证、以及网络数据传输的安全性成为政府机关首要考虑的迫切问题。       2.安全需求分析       根据政府机关对网络信息系统建设的需要,在实现移动办公安全接入的同时, 结合国家政策对相关网络通讯协议和加密算法的要求,其安全接入需求主要如下 所述:       (1)业务系统机密数据安全保密性需求       在移动办公或移动业务操作过程中,因终端的种类较多,有各种移动 PC、 移动平板和移动手机,对于办公系统或业务系统的敏感机密数据的安全保密性要 求较高。要保障这些数据对移动终端是隔离的、安全的,并且不在移动终端设备 上存储敏感机密信息(一旦存储即存在被窃取或主动/被动数据泄露的可能)。       (2)网络通讯协议及加密算法的合规性需求       网络传输通讯协议必须符合国家密码管理局颁布的相关国家技术标准,符合 《SSL VPN 技术规范》的要求。       加密算法必须使用国家密码管理局颁布的加密算法。对数据加密的对称算法 应使用 SM1 或 SM4 算法;用于证书认证的非对称算法应使用 SM2 算法,摘要 算法应使用 SM3 算法。       (3)移动设备、网关设备与用户的管理与安全性需求       对所有移动设备、网关设备和移动用户采用统一、严格的身份认证和集中管 理;需实现实时监控网关设备及用户工作状态,并进行详细日志记录;对移动设 备上的用户操作进行详细记录;整个系统安装方便、快捷,便于维护和管理。       3.方案综述       3.1 移动办公安全解决方案说明       根据政府机关的移动办公及移动业务操作的实际需求,我们采用经国密局鉴 定通过的 VPN 密码机、支持 SM2 证书的 CA 服务器,以及虚拟手机服务器的组 合应用解决方案,解决政府机关在移动办公及移动业务操作过程中的数据及文件 的安全保密、网络传输安全保密、人员身份认证、设备集中管理及访问控制等。具体的网络拓扑图及解决方案如下(本方案旨在表述“移动安全接入”,整体完 备的信息安全解决方案不再此表述):图 3-1    移动办公安全解决方案网络拓扑图       在政府机关内网的互联网出口处部署高端 IPSEC/SSL VPN 综合网关作为安 全接入网关。VPN 密码机内置硬件加密卡,支持 SM1、SM2、SM3、SM4 等国 产密码算法,符合国密局 VPN 技术规范要求。同时,VPN 综合安全网关集成的 防火墙功能可进行网络访问控制及网络安全防护。VPN 综合安全网关对移动用 户提供统一的基于 SM2 证书的身份认证、访问授权及隧道通讯服务。当用户通 过身份认证后,根据其角色确定相应的访问控制列表,并向终端推送授权的虚拟 手机设备连接配置以访问不同的业务系统。       在政府机关内网部署 CA 服务器,为所有移动用户签发 SM2 算法的证书, 使用证书方式对移动用户的远程接入进行身份认证。CA 服务器需符合国密局 《SM2 数字证书规范》。       在政府机关内网部署虚拟手机服务器,提供虚拟手机池为移动用户接入使用。支持虚拟手机设备的统一管理,移动应用的统一管理,移动用户使用虚拟手机的 行为安全策略管理。可根据策略让虚拟手机池中的虚拟手机设备安装不同的应用,...
阅读全文
牛逼!Java学习路线图来了 未分类

牛逼!Java学习路线图来了

查看文章尾部参与赠书活动 众所周知,Java是市场上占有率排名前三的编程语言,Java作为企业级应用开发的首选,不仅在很多企业得到应用,也深受互联网大厂的青睐。对于求职找工作的朋友来说,Java可能仍然是后端工程师的优选,虽然Golang和Python一直在追赶,但是Java作为老牌语言,在企业中的地位很重要,它的市场空间仍然是很难撼动的。 学习Java,就是为了更好地开发应用,不论是开发Web应用,还是开发中间件,亦或是微服务,都是Java语言所擅长的,加上Java生态的丰富多彩,对于企业级应用的全方位支持,使用Java的开发大型应用的成本相对还是比较低的。   想从Java小白进阶到Java架构师,这一篇Java学习路线汇总内容不容错过!   小编搜罗了各大主流公司面试和使用的技术,整理出了Java学习路线图,适合于初、中、高级别的Java程序员,建议收藏。   01 第一阶段 Java编程基础 基础不牢,地动山摇,做Java开发,Java基础是最需要下功夫的一项。以后能达到什么高度,完全取决于基础掌握到什么水平。   想要基础扎实,看书沉淀是必须的,建议有一些编程基础的朋友好好研究一下《Java核心技术 卷1》,书里面详细讲解了JavaSE所有内容的原理,如果你能把这本书研究透,以后会有很高的技术造诣。   如果是非科班出身的零基础小白,可以先在网上找些视频看,有助于理解,网络上视频资源虽然很多,但大多不够系统,所以拥有一本Java编程基础的书籍,仍是你系统学习Java所必备的资源。   《Java核心技术》曾获Jolt大奖,是每个Java工程师案头必备的技术手册,阅读时可以跳过图形界面程序设计、Swing、以及部分日志章节。并发的知识比较深入,在基础阶段大致了解即可。(第11版根据JavaSE 9-11全面更新) 《Java语言程序设计 基础篇 原书第12版》被世界各地的大学选作教材,全球畅销20余年,第12版根据Java9-11更新。本书通过示例讲解问题求解技巧,提供大量的程序清单,每章配有丰富的复习题和编程练习题,帮助读者掌握编程技术并解决实际开发中遇到的问题。 02 第二阶段 数据库 数据库技术是做业务系统必备技能,是一门公共的学科。Java、C、python、C#等程序员都需要学习数据库。主流的数据库有MySQL、Oracle、SQL Server等等,银行、政府使用oracle的较多;互联网公司、一般企业使用MySQL较多。你只需要搞定一个就可以了,知识都是相通的,一通百通。 学习数据库技术后,可以应对日常工作的增删改查、复杂业务表结构设计规范、使用Java语言和数据库打交道。 《数据库系统内幕》 高效内功修炼必备,从数据库开发者角度,全景式解读现代数据库技术 03 第三阶段 JavaWeb JavaWeb是一系列技术的综合,也是大多数Java学习者日后的技术方向。及早的了解JavaWeb也有利于更深层面理解,Java在完整的应用中,是如何与各个模块交互并发挥作用的。   Web前端技术 虽然目前各大公司基本上确实已经前后端分离了,但是想成为一名优秀的程序员前端技术还是要了解的,了解了前端界面和后端数据是怎样交互的,在与前端工程师沟通合作时也会更加顺畅,理解项目更通透,解决问题准确迅速。另外,像一些小公司仍要求全栈,希望招来的后端开发也能做一些前端的工作,省一些人力成本。   前端三大件:CSS+HTML+JavaScript也是必会的内容,这些学完后,为了做出更好、更炫的交互式体验效果,我们还需要学习Vue/React,以及打包工具Webpack等等。     Web后端技术 掌握前端技术只能做静态网站,但它页面数据不会因业务而动态变化,而动态网站可以根据后端数据库中存储的数据实现不同的内容展示,应用更广泛,因此程序员必须要学会做动态网站。使用Java做动态网站,我们需要学习Servlet、Filter、Session、Cookie、EL表达式、JSTL等做动态网站的完整知识体系,重点要理解Servlet的原理以及生命周期。学完可简单做个OA系统、内容网站、BBS等。 04 第四阶段 Java编程强化 1、Java进阶 在做完一个简单完整的JavaWeb项目后,我们对代码的认知和理解会提高不少,这对接下来的深入学习打下基础。Java圣经:《Java编程思想》值得仔细品读,作者的功力十分深厚,即使很多内容还无法理解,但每次读完一定会有所收获。这是一本伴随我们技术成长的好书,买一本放在旁边,摸着就有底气。   Java学习必读经典,殿堂级著作!《Java编程思想》赢得了全球程序员的广泛赞誉,即使是晦涩的概念,在BruceEckel的文字亲和力和小而直接的编程示例面前也会化解于无形。从Java的基础语法到高级特性(深入的面向对象概念、多线程、自动项目构建、单元测试和调试等),本书都能逐步指导你轻松掌握。 读完Java编程思想,建议写一个有一定复杂度和代码量的后台项目。可以是一个http服务器,一个大型聊天室,要强化我们的Java基础,同时也为日后的招聘积累项目经验。   做完项目我们又该看书沉淀技术了,此时推荐阅读《Effective Java(原书第3版)》,这本书并不厚但是干货十足,作者讲述Java的最佳实践和经验规则。它能帮助我们写出清晰、健壮、高效的代码,同时这本书涵盖了非常多的面试考点,一定要牢记于心! “我很希望我10年前就能拥有这本书。有人可能认为我不需要任何Java方面的书籍,但是我需要这本书。”——Java之父James Gosling 你是否正在寻找一本能够更加深入地了解Java编程语言的书,以便编写出更清晰、更正确、更健壮且更易于重用的代码?本书再适合不过了!这是一本分享经验并指引你少走弯路的经典著作,针对如何编写高效、设计优良的程序提出了最实用、最权威的指导方针,通过90条经验法则,探索新的设计模式和语言习惯用法,帮你更加有效地使用Java编程语言及其基本类库。适合已经掌握Java核心技术的程序员,想更加深入地了解Java编程语言的开发者阅读。 《Java核心技术卷2:高级特征》全面覆盖Java技术的高级主题,对Java技术的阐述精确到位,叙述方式深入浅出,并包含大量示例,从而帮助读者充分理解Java语言以及Java类库的相关特性。 2、并发 前面学了JavaSE基础,但它在企业级应用中程序处理业务的效率并不高、扩展差,我们还要针对性的提高程序处理业务的执行效率、增强程序扩展性。就要学习设计模式、Java并发包原理、线程的内存模型、JVM调优等。学完以后,能增加一个中级程序员的知识储备,无论在面试过程中还是将来技术的深入打一个良好的基础。   Java并发编程里程碑著作!10年畅销100000+册。从并发编程的基本理论入手,逐步介绍了在设计Java并发程序时各种重要的设计原则、设计模式以及思维模式,使得开发人员能够更快地领悟Java并发编程的要领,快速地构建大规模的并发应用程序。 3、JVM   对于Java 程序员来说,JVM 帮助我们做了很多事情,比如内存管理、垃圾回收等等。JVM是 Java 后端面试(大厂)中非常重要的一环。不论是应届还是社招,面试国内的一些大厂,你都会被问到很多 JVM 相关的问题.只有搞懂了JVM 才有可能真正把 Java 语言 "吃透"。学习 JVM这部分的内容,一定要注意要实战和理论结合。学习JVM,看周志明老师的《深入理解Java虚拟机:JVM高级特性与最佳实践(第3版)》足以。   大厂面试通关宝典全新升级!第三版大幅更新50%以上内容,周志明从Java技术体系、自动内存管理、虚拟机执行子系统、程序编译与代码优化、高效并发5个维度全面剖析虚拟机。以实战为导向,通过大量实际案例,分享解决各种Java技术难题的方案和技巧。几乎涵盖大厂面试全部知识点。值得所有Java技术人员一读再读。 4、热门技术框架 企业中广泛使用一些优秀的框架技术来解决开发效率低、代码量大、开发周期长、开发成本高的问题。因此我们还需要学习框架技术,项目开发中主流的Java框架技术有SpringMVC、Spring、SpringBoot、MyBatis、MyBatis Plus等。这些框架技术都是一个优秀程序员所必备的技能。学完 Java Web 框架,还需要看看 JVM 原理,GC、类加载机制这些,大厂都爱问。   5、数据结构和算法 数据结构是算法的基础,一定要清晰明了。算法则是笔试面试中无法绕过的难关,推荐去LeetCode刷题,积累一定题量之后,做算法题会很快找到类型方法。   数据结构与算法分析:Java语言描述(原书第3版)是国际著名计算机教育专家Weiss数据结构与算法Java描述经典教材新版,把算法分析与高效率的Java程序的开发有机地结合起来,深入分析每种算法。 6、其他知识 作为一个优秀Java工程师,多线程、高并发、异步、服务器中间件、服务器技术、容器技术、软件项目管理知识也要一并掌握,文前导图有推荐书目,这里就不一一展开了。   05 第五阶段 分布式架构 企业发展过程中,业务量和用户量逐渐增加,为了保证系统的可用性,系统越做越复杂,研发人员增多,大家很难共同维护一个复杂的系统,往往修改部分内容,导致牵一发而动全身,所以我们需要升级系统架构,需要用到分布式微服务的技术。学习完该阶段内容,可以具备大型SOA架构和微服务架构能力,能掌握大型微服务项目必备技术和实际经验。  ...
阅读全文
送15本经典书籍《Java核心技术》《Java编程思想》《架构之道》等 未分类

送15本经典书籍《Java核心技术》《Java编程思想》《架构之道》等

查看文章尾部参与赠书活动 众所周知,Java是市场上占有率排名前三的编程语言,Java作为企业级应用开发的首选,不仅在很多企业得到应用,也深受互联网大厂的青睐。对于求职找工作的朋友来说,Java可能仍然是后端工程师的优选,虽然Golang和Python一直在追赶,但是Java作为老牌语言,在企业中的地位很重要,它的市场空间仍然是很难撼动的。 学习Java,就是为了更好地开发应用,不论是开发Web应用,还是开发中间件,亦或是微服务,都是Java语言所擅长的,加上Java生态的丰富多彩,对于企业级应用的全方位支持,使用Java的开发大型应用的成本相对还是比较低的。   想从Java小白进阶到Java架构师,这一篇Java学习路线汇总内容不容错过!   小编搜罗了各大主流公司面试和使用的技术,整理出了Java学习路线图,适合于初、中、高级别的Java程序员,建议收藏。   01 第一阶段 Java编程基础 基础不牢,地动山摇,做Java开发,Java基础是最需要下功夫的一项。以后能达到什么高度,完全取决于基础掌握到什么水平。   想要基础扎实,看书沉淀是必须的,建议有一些编程基础的朋友好好研究一下《Java核心技术 卷1》,书里面详细讲解了JavaSE所有内容的原理,如果你能把这本书研究透,以后会有很高的技术造诣。   如果是非科班出身的零基础小白,可以先在网上找些视频看,有助于理解,网络上视频资源虽然很多,但大多不够系统,所以拥有一本Java编程基础的书籍,仍是你系统学习Java所必备的资源。   《Java核心技术》曾获Jolt大奖,是每个Java工程师案头必备的技术手册,阅读时可以跳过图形界面程序设计、Swing、以及部分日志章节。并发的知识比较深入,在基础阶段大致了解即可。(第11版根据JavaSE 9-11全面更新) 《Java语言程序设计 基础篇 原书第12版》被世界各地的大学选作教材,全球畅销20余年,第12版根据Java9-11更新。本书通过示例讲解问题求解技巧,提供大量的程序清单,每章配有丰富的复习题和编程练习题,帮助读者掌握编程技术并解决实际开发中遇到的问题。 02 第二阶段 数据库 数据库技术是做业务系统必备技能,是一门公共的学科。Java、C、python、C#等程序员都需要学习数据库。主流的数据库有MySQL、Oracle、SQL Server等等,银行、政府使用oracle的较多;互联网公司、一般企业使用MySQL较多。你只需要搞定一个就可以了,知识都是相通的,一通百通。 学习数据库技术后,可以应对日常工作的增删改查、复杂业务表结构设计规范、使用Java语言和数据库打交道。 《数据库系统内幕》 高效内功修炼必备,从数据库开发者角度,全景式解读现代数据库技术 03 第三阶段 JavaWeb JavaWeb是一系列技术的综合,也是大多数Java学习者日后的技术方向。及早的了解JavaWeb也有利于更深层面理解,Java在完整的应用中,是如何与各个模块交互并发挥作用的。   Web前端技术 虽然目前各大公司基本上确实已经前后端分离了,但是想成为一名优秀的程序员前端技术还是要了解的,了解了前端界面和后端数据是怎样交互的,在与前端工程师沟通合作时也会更加顺畅,理解项目更通透,解决问题准确迅速。另外,像一些小公司仍要求全栈,希望招来的后端开发也能做一些前端的工作,省一些人力成本。   前端三大件:CSS+HTML+JavaScript也是必会的内容,这些学完后,为了做出更好、更炫的交互式体验效果,我们还需要学习Vue/React,以及打包工具Webpack等等。     Web后端技术 掌握前端技术只能做静态网站,但它页面数据不会因业务而动态变化,而动态网站可以根据后端数据库中存储的数据实现不同的内容展示,应用更广泛,因此程序员必须要学会做动态网站。使用Java做动态网站,我们需要学习Servlet、Filter、Session、Cookie、EL表达式、JSTL等做动态网站的完整知识体系,重点要理解Servlet的原理以及生命周期。学完可简单做个OA系统、内容网站、BBS等。 04 第四阶段 Java编程强化 1、Java进阶 在做完一个简单完整的JavaWeb项目后,我们对代码的认知和理解会提高不少,这对接下来的深入学习打下基础。Java圣经:《Java编程思想》值得仔细品读,作者的功力十分深厚,即使很多内容还无法理解,但每次读完一定会有所收获。这是一本伴随我们技术成长的好书,买一本放在旁边,摸着就有底气。   Java学习必读经典,殿堂级著作!《Java编程思想》赢得了全球程序员的广泛赞誉,即使是晦涩的概念,在BruceEckel的文字亲和力和小而直接的编程示例面前也会化解于无形。从Java的基础语法到高级特性(深入的面向对象概念、多线程、自动项目构建、单元测试和调试等),本书都能逐步指导你轻松掌握。 读完Java编程思想,建议写一个有一定复杂度和代码量的后台项目。可以是一个http服务器,一个大型聊天室,要强化我们的Java基础,同时也为日后的招聘积累项目经验。   做完项目我们又该看书沉淀技术了,此时推荐阅读《Effective Java(原书第3版)》,这本书并不厚但是干货十足,作者讲述Java的最佳实践和经验规则。它能帮助我们写出清晰、健壮、高效的代码,同时这本书涵盖了非常多的面试考点,一定要牢记于心! “我很希望我10年前就能拥有这本书。有人可能认为我不需要任何Java方面的书籍,但是我需要这本书。”——Java之父James Gosling 你是否正在寻找一本能够更加深入地了解Java编程语言的书,以便编写出更清晰、更正确、更健壮且更易于重用的代码?本书再适合不过了!这是一本分享经验并指引你少走弯路的经典著作,针对如何编写高效、设计优良的程序提出了最实用、最权威的指导方针,通过90条经验法则,探索新的设计模式和语言习惯用法,帮你更加有效地使用Java编程语言及其基本类库。适合已经掌握Java核心技术的程序员,想更加深入地了解Java编程语言的开发者阅读。 《Java核心技术卷2:高级特征》全面覆盖Java技术的高级主题,对Java技术的阐述精确到位,叙述方式深入浅出,并包含大量示例,从而帮助读者充分理解Java语言以及Java类库的相关特性。 2、并发 前面学了JavaSE基础,但它在企业级应用中程序处理业务的效率并不高、扩展差,我们还要针对性的提高程序处理业务的执行效率、增强程序扩展性。就要学习设计模式、Java并发包原理、线程的内存模型、JVM调优等。学完以后,能增加一个中级程序员的知识储备,无论在面试过程中还是将来技术的深入打一个良好的基础。   Java并发编程里程碑著作!10年畅销100000+册。从并发编程的基本理论入手,逐步介绍了在设计Java并发程序时各种重要的设计原则、设计模式以及思维模式,使得开发人员能够更快地领悟Java并发编程的要领,快速地构建大规模的并发应用程序。 3、JVM   对于Java 程序员来说,JVM 帮助我们做了很多事情,比如内存管理、垃圾回收等等。JVM是 Java 后端面试(大厂)中非常重要的一环。不论是应届还是社招,面试国内的一些大厂,你都会被问到很多 JVM 相关的问题.只有搞懂了JVM 才有可能真正把 Java 语言 "吃透"。学习 JVM这部分的内容,一定要注意要实战和理论结合。学习JVM,看周志明老师的《深入理解Java虚拟机:JVM高级特性与最佳实践(第3版)》足以。   大厂面试通关宝典全新升级!第三版大幅更新50%以上内容,周志明从Java技术体系、自动内存管理、虚拟机执行子系统、程序编译与代码优化、高效并发5个维度全面剖析虚拟机。以实战为导向,通过大量实际案例,分享解决各种Java技术难题的方案和技巧。几乎涵盖大厂面试全部知识点。值得所有Java技术人员一读再读。 4、热门技术框架 企业中广泛使用一些优秀的框架技术来解决开发效率低、代码量大、开发周期长、开发成本高的问题。因此我们还需要学习框架技术,项目开发中主流的Java框架技术有SpringMVC、Spring、SpringBoot、MyBatis、MyBatis Plus等。这些框架技术都是一个优秀程序员所必备的技能。学完 Java Web 框架,还需要看看 JVM 原理,GC、类加载机制这些,大厂都爱问。   5、数据结构和算法 数据结构是算法的基础,一定要清晰明了。算法则是笔试面试中无法绕过的难关,推荐去LeetCode刷题,积累一定题量之后,做算法题会很快找到类型方法。   数据结构与算法分析:Java语言描述(原书第3版)是国际著名计算机教育专家Weiss数据结构与算法Java描述经典教材新版,把算法分析与高效率的Java程序的开发有机地结合起来,深入分析每种算法。 6、其他知识 作为一个优秀Java工程师,多线程、高并发、异步、服务器中间件、服务器技术、容器技术、软件项目管理知识也要一并掌握,文前导图有推荐书目,这里就不一一展开了。   05 第五阶段 分布式架构 企业发展过程中,业务量和用户量逐渐增加,为了保证系统的可用性,系统越做越复杂,研发人员增多,大家很难共同维护一个复杂的系统,往往修改部分内容,导致牵一发而动全身,所以我们需要升级系统架构,需要用到分布式微服务的技术。学习完该阶段内容,可以具备大型SOA架构和微服务架构能力,能掌握大型微服务项目必备技术和实际经验。  ...
阅读全文
为何安全可视化对公有云安全如此重要? 云安全

为何安全可视化对公有云安全如此重要?

传统数据中心的架构并非为了保护现代云应用而建。我们现在正在经历一次应用开发的“复兴期”,组织正在改变应用的开发和运行方式。▶ 公有云上的应用随着企业加速他们的云端迁移,应用正在越来越快地在公有云平台完成开发。公有云让开发者在应用的开发和部署上有更多的灵活性。结构就产生了以下的变化:虚拟机或者基于用例的应用基于容器的应用不急于服务器的应用▶ 基于业务的应用不仅仅应用的部署位置发生了改变,应用的开发方式也发生了变化——或者说现在的应用是从业务出发进行开发了。越来越多的应用通过被详细定义的API进行微服务沟通的方式开发。这些API通常是远程或者外部的。这就意味着一个应用可以用多种方式达成一个工作,包括:通过Twilio发送信息通过AWS S3储存和追溯图像通过Mailchimp发送电子邮件通过 Snowflake储存和追溯整排数据通过Datadog记录日志(图片来自DarkReading)▶ 一种新类型的流量应用位置的改变(公有云)和应用开发方式的改变(基于服务)就带来了一种新的流量:应用发起的向SaaS、PaaS和公网的连接。一般而言,应用连接指向的服务终端一般都会基于一个完全限定域名(fully qualified domain name, FQDN)或者URL进行识别,而在解析的时候会被转化成成百上千的IP地址。这些IP地址列表是动态的。同时,云服务商的本地安全控制,比如ACL、安全组、路由表等,都是基于IP地址的。因此,如果要稳定地使用这些公有云的各类连接,安全控制必须要允许连接指向任何IP地址——这就会造成攻击面远远超过企业愿意承受的大小。在企业完全开发这些控制之前,通向外部的传输被限制在一部分安全名单中的IP地址和IP范围。因此,如果一个应用或者计算资源遭到攻击,它能传输的范围依然会被限制在一部分安全目标内。但是现在,如果这些针对出口流量能够连接到任何IP地址,一个被攻陷的应用用例会造成以下的结果:成为C2服务器的一部分,并且进行恶意活动,如传播恶意软件、挖矿、终端运作、DDoS攻击等。从VPC中窃取数据。毫无疑问,企业需要针对这些由应用和机器发起的出口流量有更好的管理和控制。简而言之,企业必须有一个完整安全策略图谱,可以直接用于应用和DevOps团队;图谱不应该过于复杂,或者需要安全团队对每个应用和场景都来回进行协助。▶ 安全从可视化起步鉴于人们无法按保护自己看不见的东西,企业该如何获得公有云里出口流量的可视化能力呢?在以前的数据中心世界,网络安全解决方案有一条清晰的边界进行划分。这些结构往往会有一个定义明确的解决方案,通过占据所有流量必经之路的方式达成可视化效果。(图片来自DarkReading)但是,公有云是没有一个明确的边界的。任何资源都能在一键之中暴露到公网上,无论是一个公开安全组规则,或者是ACL、公开路由表条目、接口的公共IP地址——任何一个或是几个的组合。想要在公有云中找到一个必经之路不仅仅是困难而已,在某些时候,这根本就不可能做到。举个例子,当应用发起连接到外部地址的时候,第一步是解析目标的DNS。在公有云,没有任何资源可以接入该流量——因为一般都是由云服务商处理DSN解析。因此,任何设计用于传统数据中心的运营方案,在公有云中都毫无作用。这就是传统网络监控和安全厂商无法提供一个同时有公有云可视化和实现能力的完整解决方案的原因。 (图片来自DarkReading)▶ 基于准确的假设解决可视化和控制问题毫无疑问,应用开发和架构的未来在公有云——甚至对很多组织而言,这不是未来,这就是当下。在新环境中保护数据、应用和服务对企业防范数据泄露和经济损失而言至关重要。传统的数据中心解决方案都是基于了大量不再现实的假设而创建的,在公有云中毫无办法。企业必须基于准确的假设,在公有云时代针对云端,开发和实现从云端诞生的解决方案。数世点评:摸清家底只是安全防范的第一步——摸清家底以后,家里发生了什么,对外在进行怎样的交互是新的挑战。云端的复杂化境、安全边界的模糊、以及攻击面的扩大无不对云端可视化能力提出了极大的挑战——而挑战往往也带来了新的机遇。云端的安全可视化能力会逐渐成为企业关注的焦点。关键词:安全可视化;云安全管理▶ 相关文章2021顶级云访问安全供应商【调查】大型云服务提供商比企业自身更安全云原生带来的云安全机遇云安全风险为何转向身份与授权?多云战略的杀手锏:云不可知 云原生业务艰难维系安全 本文始发于微信公众号(数世咨询):为何安全可视化对公有云安全如此重要?
阅读全文
Ulauncher:一个超级实用的 Linux 应用启动器 | Linux 中国 安全工具

Ulauncher:一个超级实用的 Linux 应用启动器 | Linux 中国

 导读:Ulauncher 是一个快速应用启动器,支持扩展和快捷方式,帮助你在 Linux 中快速访问应用和文件。本文字数:1719,阅读时长大约:2分钟https://linux.cn/article-13743-1.html作者:Ankush Das译者:geekpi应用启动器可以让你快速访问或打开一个应用,而无需在应用菜单图标上徘徊。在默认情况下,我发现 Pop!_OS 的应用启动器超级方便。但是,并不是每个 Linux 发行版都提供开箱即用的应用启动器。幸运的是,有一个你可以在大多数流行的发行版中添加应用启动器的方案。Ulauncher:开源应用启动器Ulauncher 是一个使用 Python 还有 GTK+ 构建的快速应用启动器。它提供了相当数量的自定义和控制选项来进行调整。总的来说,你可以调整它的行为和体验以适应你的喜好。让我来说一下你可以期待它的一些功能。Ulauncher 功能Ulauncher 中的选项非常非常易于访问且易于定制。一些关键的亮点包括:◈ 模糊搜索算法可以让你即使拼错了,也能找到应用◈ 可以记住你在同一会话中最后搜索的应用◈ 显示经常使用的应用(可选)◈ 自定义颜色主题◈ 预设颜色主题,包括一个黑暗主题◈ 召唤启动器的快捷方式可以轻松定制◈ 浏览文件和目录◈ 支持扩展,以获得额外的功能(表情符号、天气、速度测试、笔记、密码管理器等)◈ 浏览谷歌、维基百科和 Stack Overflow 等网站的快捷方式它几乎提供了你在一个应用启动器中所期望的所有有用的能力,甚至更好。如何在 Linux 中使用 Ulauncher?默认情况下,首次从应用菜单中打开应用启动器后,你需要按 Ctrl + Space 打开应用启动器。输入以搜索一个应用。如果你正在寻找一个文件或目录,输入以 ~ 或者 / 开始。有一些默认的快捷键,如 g XYZ,其中 “XYZ” 是你想在谷歌中搜索的搜索词。同样,你可以通过 wiki 和 so 快捷键,直接在维基百科或 Stack Overflow 搜索。在没有任何扩展的情况下,你也可以直接计算内容,并将结果直接复制到剪贴板。这在快速计算时应该很方便,不需要单独启动计算器应用。你可以前往它的 扩展页面🔗 ext.ulauncher.io,浏览有用的扩展,以及指导你如何使用它的截图。要改变它的工作方式,启用显示经常使用的应用,并调整主题,请点击启动器右侧的齿轮图标。你可以把它设置为自动启动。但是,如果它在你的支持 Systemd 的发行版上不工作,你可以参考它的 GitHub 页面,把它添加到服务管理器中。这些选项是非常直观,且易于定制,如下图所示。在 Linux 中安装 UlauncherUlauncher 为基于 Debian 或 Ubuntu 的发行版提供了一个 deb 包。如果你是 Linux 新手,你可以了解一下 如何安装 Deb 文件🔗 itsfoss.com 。在这两种情况下,你也可以添加它的 PPA,并通过终端按照下面的命令来安装它:sudo add-apt-repository ppa:agornostal/ulaunchersudo apt updatesudo apt install ulauncher你也可以在 AUR🔗 itsfoss.com 中找到它,用于 Arch 和 Fedora 的默认仓库。对于更多信息,你可以前往其官方网站或 GitHub 页面🔗 github.com。◈ Ulauncher🔗 ulauncher.ioUlauncher 应该是任何 Linux 发行版中一个令人印象深刻的补充。特别是,如果你想要一个像 Pop!_OS 提供的快速启动器的功能,这是一个值得考虑的奇妙选择。你试过 Ulauncher了吗?欢迎你就如何帮助你快速完成工作分享你的想法。via: https://itsfoss.com/ulauncher/作者:Ankush Das 选题:lujun9972 译者:geekpi 校对:wxy本文由 LCTT 原创编译,Linux中国 荣誉推出欢迎遵照 CC-BY-NC-SA 协议规定转载,如需转载,请在文章下留言 “转载:公众号名称”,我们将为您添加白名单,授权“转载文章时可以修改”。 本文始发于微信公众号(Linux中国):Ulauncher:一个超级实用的 Linux 应用启动器 | Linux 中国
阅读全文