分类目录归档:架构

架构设计中的6种常见安全误区

自然世界中,先天有缺陷的生物总是容易被细菌病毒入侵,而健壮的生物更能抵抗细菌病毒的攻击,计算机系统也是一样,若有先天的架构设计安全缺陷,那 么在面临网络攻击的时候,就更容易被入侵或者破坏,甚至因为设计架构的原因,有些漏洞完全没有办法修复!本文将讲述架构设计中需要避免出现的安全误区,以 帮助我们研发人员设计出更安全健壮的软件架构。本文的举例既有硬件架构,也有软件架构,还有基础架构等等不同的架构,但其中原理适用于所有的架构设计。下 文将从兼容性设计误区,降低成本设计误区,数据和代码不分离的设计误区,封闭设计的误区,黑名单设计的误区,没有将安全列为设计目标之一的误区,总共6个 方面来探讨设计安全误区的问题。 

误区一:兼容性设计 

兼容性越好的架构越能适应未来变化的需要,所以架构设计者会非常关注架构的兼容性设计,但是有些兼容性设计会带来严重的安全漏洞,这些安全漏洞甚至无法以简单的漏洞补丁方式修复。 

以 苹果的USB-C接口设计为案例。USB-C这个接口不仅用来实现供电、还用于支持鼠标,键盘等设备的数据传输,起到了简化设计结构,方便用户的目的。谷 歌新款Chromebook Pixel也内置了USB-C接口,预示着业界对于MacBook的USB-C接口设计基本上是一致认可的。不过,安全专家却认为这是一个很糟糕的设计。 在2014年的黑帽技术大会上,安全专家演示了一次针对USB-C接口的攻击,只要将特制的U盘插入使用USB-C接口的苹果计算机,攻击者无需在做任何 操作,就可以将后门或是病毒自动植入苹果计算机,使计算机可以被攻击者远程控制或是通过病毒自动破坏计算机内的文件,非常可怕。更悲剧的还在后面,苹果一 直都没有办法修复该漏洞,为什么呢?这得从这个漏洞的利用方式说起,上文说到攻击需要特制的U盘,安全专家改变了U盘的硬件和软件结构和内容,当U盘插入 USB-C接口的苹果计算机时,电脑会识别U盘为一个键盘,再利用U盘中的芯片和存储的攻击代码,就可以伪装成键盘向主机发送控制命令,从而完全控制主 机,无论使用者是否开启自动播放,都可以成功。所以漏洞的关键在于U盘和键盘等设备可以共用同一类接口与计算机交互,在计算机系统上没有办法区分伪装成键 盘的U盘和真实的键盘,这样若不改变USB-C接口可以兼容U盘,键盘等各种硬件的设计,他们就不能修复该漏洞,而若要修复该漏洞就必须推翻原来的设计, 让USB接口不再兼容键盘,鼠标等输入硬件,输入类硬件仍然使用原来的PS/2接口或其它不同的接口。 

苹果的USB-C接口设计产生了 一个必须推翻自己才能修复的漏洞, 所以说这是一个糟糕的设计。对于软硬件的兼容性设计,第一,一定要注意兼容的对象是否为同一类,不同类的对象最好不要强容,苹果这个设计就没有将控制指令 的输入设备(键盘)与数据输入设备(U盘)这两类对象区分对待,导致了这个越权漏洞的产生;第二,兼容性设计者需要确保鉴权机制能够识别不同的对象输入, 对不同的对象输入走不同的处理,避免出现控制指令输入设备可以伪装数据输入设备,代码可以伪装成数据输入的漏洞,借用一句经典的话——“圈子不同,不要强 容”。 

误区二:降低成本设计 

架构设计者也会非常关注架构的成本,能以最少的成本实现系统是体现设计者水平的重要标志,所以架构设计者的设计总有降低软硬件成本的倾向,这种倾向本没有错,但如果在错误的地方降了成本,给系统带来极大的安全风险,就得不偿失了。 

例 如下面这个因为降成本设计导致服务器无法防范CC攻击的场景。很多设计者会将每台服务器的负载率设定得非常高,高达50%-70%,希望减少服务器的部署 以降低成本,但是在正常业务场景下就有这么高的负载,被CC攻击的时候会很容易被瘫痪,安全专家也没有办法在服务器上实施安全策略以防御攻击。 CC(Challenge Collapsar)是一种HTTP层的DDos攻击,它通过发送大量HTTP层的请求,以达到让被攻击的目标网站瘫痪的目的。Challenge Collapsar的中文意思是挑战黑洞,大家可能会觉得它的名字有点怪,这里涉及攻击命名者与一个防火墙产品的纠葛,黑洞是一款知名的防火墙产品,意思 很明显了,命名者想说黑洞防火墙也防不住他的这种攻击。目前国内领先的几家DDos清洗设备安全厂商可以基于特征防御一些普通的CC攻击,但是对于一些没 有数据段特征,并且有大量代理IP的CC攻击仍然没有办法。这个时候防御的重点战场就必须转移到服务器上来了,通过业务服务器上更多业务场景的数据,以及 更容易编程实现复杂的安全策略优势来检测攻击请求,举个例子,比如我们通常业务场景下,来自河南省的访问量很少,而攻击的时候该省的访问量上升10倍,我 们可以对该省的访问量丢掉80%,从而防御攻击,并且最大限度的降低对业务的影响。 

所以设计时保证一定的服务器冗余,能够降低攻击开始阶段系统就被攻击到瘫痪的概率,也为DDos安全专家的安全防御策略提供计算资源。如果有条件的话,最好是把业务部署在云上,这样被攻击的时候可以动态增加服务器数量,既能节省成本也能保障攻击的时候能够有效的防护。 

误区三:数据和代码不分离的设计 

数 据和代码不分离意味着数据可以被当成代码执行,而数据是可以由用户(攻击者)自己定义的,也就是说用户(攻击者)可以自定义在系统上执行的代码,那么攻击 者可以构造木马代码,作为数据输入给系统,系统执行这些木马代码后,系统就会被攻击者控制,这样的设计将给系统带来极大的风险。我们的系统开发过程中其实 有不少这样的案例,下面我们先看看一个设计导致的上传攻击漏洞的案例。 

例如一个导致上传攻击漏洞的设计案例,先简单描述一下上传攻击的 原理,大部分应用系统都有上传图片或文件的功能,攻击者利用这些功能上传一个网页木马,如果存放上传文件的目录有执行脚本的权限,那么攻击者就可以直接得 到一个WebShell,进而控制Web服务器。这个漏洞有两个必要条件,一是可以上传木马,二是存放上传文件的目录具备执行脚本的权限。上传是业务的功 能需要,即便有做各种安全过滤,限制木马上传,但也有各种绕过过滤的攻击方法,比较难以限制。所以漏洞的关键就在上传的目录是否具备执行脚本的权限上,很 多设计者会基于降低成本的考虑,将存储上传文件的位置与Web应用程序放在同一服务器,甚至同一目录下,这样上传的目录也和Web应用程序一样具备执行脚 本的权限,从而导致系统产生了一个高危上传漏洞。 

而如果将存储上传文件的位置设计在另一台只具备存储功能的文件服务器或数据库上,与Web应用服务器分开,这样即使木马被上传进来,也因为文件服务器不能执行脚本而没有办法实施攻击。 

误区四:封闭设计 

架 构师设计通常会遵循对扩展开放,对修改封闭的设计原则。对于修改封闭,就是说外部可以调用系统的接口使用系统的功能,但是看不到系统内部实现的代码,也不 能对内部实现的代码进行修改。这常常给设计者一种错觉,认为外部使用者不知道系统内部是怎么实现的,不知道存在的安全缺陷,从而放心大胆的在内部留下许多 安全隐患,最常见的就是使用私有加密算法。 

设计者常会直观的认为私有算法拥有算法的秘密性,所以安全性要比公开常用加密算法更高些。但 其实私有算法的秘密性也是很难保障的首先,中国有句古语——“天下没有不透风的墙”,指不定什么时候你的算法就会通过队友泄露出去,如果你觉得这个说法太 虚了,举个实际的例子,开发人员都喜欢用GitHub,指不定哪个猪队友(有可能是自己)就会把你的算法全部上传到GitHub,黑客会放过这么好的机会 吗?当然不会,乌云上这些漏洞案例比比皆是。其次,如果算法没有泄露,黑客就不知道你的算法了吗?当然不是,黑客可以通过很多数学推导的方式,把加密的算 法推导出来,例如加密算法的公式通常如下所示: 

y= F(x) 其中F是加密算法,y是密文,x是明文 

但只要有足够多的 x,y 就可以推导出 F,比如下面一组【x,y】的数据: 

x=[0 0.9375 1.8750 2.8125 3.7500 4.6875 5.6250 6.5625 7.5000 

8.4375 9.3750 10.3125 11.2500 12.1875 13.1250 14.0625 15.0000]; 

y=[0.000000E+000 8.789063E-003 3.515625E-002 7.910156E-002 

1.406250E-001 2.197266E-001 3.164063E-001 4.306641E-001 

5.625000E-0017.119141E-001 8.789063E-001 1.063477E+000 

1.265625E+000 1.485352E+000 1.722656E+000 1.977539E+000 2.250000E+000]; 

通过matlab的最小二乘法就可以计算出F的公式如下: 

 

加密算法是这样,其它的设计也是这样,黑客总是可以通过各种方法收集到攻击目标的大量信息,要知道攻击的第一步就是情报收集。所以,使用私有加密 算法并不能保证加密算法的私密性,对安全性提升也微乎其微。再加上私有算法的数学复杂性难以达到和公开常用算法的一样水平(比如RSA算法利用的就是“将 两个大素数相乘十分容易,但是想要对其乘积进行因式分解却极其困难”的数学原理), 在算法的实现上也不如公开常用算法一样久经考验,因此即便封装了的私有加密算法也是不能使用的,加密应该用公开常用的加密算法,用密钥秘密性而不是算法的 秘密性来保障安全。 

所以,通过此类通过封闭设计隐藏软件的实现,从而隐藏一些安全隐患是非常不可取的!官方机构对此类行为也有过明确的 意见,反对采用执行或者实现的秘密性来保障产品的安全,美国国家标准与技术研究所(NIST)明文表示:“系统的安全性不应该依赖于执行或其部件的秘密 性。软件的设计应该假设是开放的——用户和黑客都知道软件是怎么样实现的,而且即便知道软件的实现也不会危害产品的安全,通过密钥或者鉴权因子就能保障产 品数据的安全。 

误区五:黑名单防御 

通常设计者都会知道需要防御sql注入和 XSS攻击等安全问题,但是在选择防御的方案时常常走入一些误区, 他们通常会选择用过滤的方法去防御sql注入和XSS攻击等攻击,这种类似黑名单的防御方式简单方便,修改量小,而且他们认为这样黑客已经攻不进来了。他 们低估了黑客们的智慧和毅力,事实证明凡是采用过滤方式防御sql注入和xss的产品,无一不被绕成狗的。 

乌云上这种被绕过的案例比比 皆是,目前还没有看到有一个不被绕过的硬件防火墙,云WAF或主机端的防护产品,即便最新宣称“永别了SQL注入”的SQLChop也很快在乌云被爆出存 在绕过的漏洞, 笔者也赞同SQLChop的用数据分析检测SQL注入的思路把防护水平提高了一个等级,但即便这样也依然逃脱不了被绕过的命运。这些如此专业的安全厂商设 计的产品都难逃被绕过的命运,那我们自己的研发人员自己在服务器上开发和部署的SQL注入和XSS攻击过滤功能,是不是会被绕得更惨呢?答案是肯定的。所 以对SQL注入漏洞应该用参数化查询的方式来解决,XSS漏洞应该用对输出进行编码的方式来解决,过滤的方法只能作为临时方案用来辅助做深度防御,而绝不 能单独作为防御攻击的安全解决方案。 

误区六:没有将安全列为设计目标之一 

相比以 上误区,大部分设计最大的误区就是没有将安全列为设计的目标之一,这才是产生以上所有设计安全问题的根源。产生这样误区的主要原因有两个,第一,架构师或 设计者真心不觉得有人有能力和有耐心去攻击他们的产品。我在与架构师的沟通中,听到最多的一句话就是“不可能!”,不管是最优秀互联网企业的架构师,还是 最优秀传统企业的架构师都是这样。架构师或设计者们通常以自己的知识去判断是否能被攻击,但是大部分的架构师和设计者都不具备一定深度的安全知识,所以常 常作出错误的判断。黑客是最具极客精神的群体,为挖掘一个漏洞连续调试12小时,持续攻坚一个星期都不是什么稀奇的事情,所以在这样一个群体面前,绝不能 以己度人,听从靠谱安全架构师的意见会更安全。第二,存在安全漏洞并不一定立即发生安全事故。安全问题大多数情况下都只是风险,它转化为安全事故一般有一 段时间,而且很多情况下即便发生了安全事故,一些安全力量薄弱的公司甚至不能检测和感知到,所以表面的一片“和谐”给了我们的设计者一种错觉,不需要做安 全的设计,产品给我的需求都做不完,哪有时间”浪费”人力的做安全设计和开发! 

所以各种遗留下来的安全隐患积累到一定程度,或者被某个导火索事件引起安全事故的大爆发,导致企业的经营遭受重创!不管是架构师等研发人员,还是安全人员都不应该让企业走到这一步绝境,而应该在产品设计之初就避免出现严重的设计安全问题,为保障产品的安全水平打下基础。

原文:http://developer.51cto.com/art/201508/488625.htm

Mysql在大型网站的应用架构演变


写在最前:

本文主要描述在网站的不同的并发访问量级下,Mysql架构的演变

可扩展性

架构的可扩展性往往和并发是息息相关,没有并发的增长,也就没有必要做高可扩展性的架构,这里对可扩展性进行简单介绍一下,常用的扩展手段有以下两种
Scale-up :  纵向扩展,通过替换为更好的机器和资源来实现伸缩,提升服务能力
Scale-out : 横向扩展,  通过加节点(机器)来实现伸缩,提升服务能力

对于互联网的高并发应用来说,无疑Scale out才是出路,通过纵向的买更高端的机器一直是我们所避讳的问题,也不是长久之计,在scale out的理论下,可扩展性的理想状态是什么?

可扩展性的理想状态

一个服务,当面临更高的并发的时候,能够通过简单增加机器来提升服务支撑的并发度,且增加机器过程中对线上服务无影响(no down time),这就是可扩展性的理想状态!

 

架构的演变

V1.0  简单网站架构

一个简单的小型网站或者应用背后的架构可以非常简单,  数据存储只需要一个mysql instance就能满足数据读取和写入需求(这里忽略掉了数据备份的实例),处于这个时间段的网站,一般会把所有的信息存到一个database instance里面。

在这样的架构下,我们来看看数据存储的瓶颈是什么

1.数据量的总大小  一个机器放不下时

2.数据的索引(B+ Tree)一个机器的内存放不下时

3.访问量(读写混合)一个实例不能承受

只有当以上3件事情任何一件或多件满足时,我们才需要考虑往下一级演变。 从此我们可以看出,事实上对于很多小公司小应用,这种架构已经足够满足他们的需求了,初期数据量的准确评估是杜绝过度设计很重要的一环,毕竟没有人愿意为不可能发生的事情而浪费自己的经历。

这里简单举个我的例子,对于用户信息这类表 (3个索引),16G内存能放下大概2000W行数据的索引,简单的读和写混合访问量3000/s左右没有问题,你的应用场景是否

V2.0 垂直拆分

一般当V1.0 遇到瓶颈时,首先最简便的拆分方法就是垂直拆分,何谓垂直?就是从业务角度来看,将关联性不强的数据拆分到不同的instance上,从而达到消除瓶颈的目标。以图中的为例,将用户信息数据,和业务数据拆分到不同的三个实例上。对于重复读类型比较多的场景,我们还可以加一层cache,来减少对DB的压力。

在这样的架构下,我们来看看数据存储的瓶颈是什么?

1.单实例单业务 依然存在V1.0所述瓶颈

遇到瓶颈时可以考虑往本文更高V版本升级, 若是读请求导致达到性能瓶颈可以考虑往V3.0升级, 其他瓶颈考虑往V4.0升级

 

V3.0  主从架构

此类架构主要解决V2.0架构下的读问题,通过给Instance挂数据实时备份的思路来迁移读取的压力,在Mysql的场景下就是通过主从结构,主库抗写压力,通过从库来分担读压力,对于写少读多的应用,V3.0主从架构完全能够胜任

在这样的架构下,我们来看看数据存储的瓶颈是什么?

1.写入量主库不能承受

V4.0  水平拆分

对于V2.0 V3.0方案遇到瓶颈时,都可以通过水平拆分来解决,水平拆分和垂直拆分有较大区别,垂直拆分拆完的结果,在一个实例上是拥有全量数据的,而水平拆分之后,任何实例都只有全量的1/n的数据,以下图Userinfo的拆分为例,将userinfo拆分为3个cluster,每个cluster持有总量的1/3数据,3个cluster数据的总和等于一份完整数据(注:这里不再叫单个实例 而是叫一个cluster 代表包含主从的一个小mysql集群)

 

数据如何路由?

1.Range拆分

sharding key按连续区间段路由,一般用在有严格自增ID需求的场景上,如Userid, Userid Range的小例子:以userid 3000W 为Range进行拆分   1号cluster  userid 1-3000W  2号cluster  userid   3001W-6000W

2.List拆分

List拆分与Range拆分思路一样,都是通过给不同的sharding key来路由到不同的cluster,但是具体方法有些不同,List主要用来做sharding key不是连续区间的序列落到一个cluster的情况,如以下场景:

假定有20个音像店,分布在4个有经销权的地区,如下表所示:






地区 商店ID 号
北区 3, 5, 6, 9, 17
东区 1, 2, 10, 11, 19, 20
西区 4, 12, 13, 14, 18
中心区 7, 8, 15, 16

业务希望能够把一个地区的所有数据组织到一起来搜索,这种场景List拆分可以轻松搞定

3.Hash拆分

通过对sharding key 进行哈希的方式来进行拆分,常用的哈希方法有除余,字符串哈希等等,除余如按userid%n 的值来决定数据读写哪个cluster,其他哈希类算法这里就不细展开讲了。

数据拆分后引入的问题:

数据水平拆分引入的问题主要是只能通过sharding key来读写操作,例如以userid为sharding key的切分例子,读userid的详细信息时,一定需要先知道userid,这样才能推算出再哪个cluster进而进行查询,假设我需要按username进行检索用户信息,需要引入额外的反向索引机制(类似HBASE二级索引),如在redis上存储username->userid的映射,以username查询的例子变成了先通过查询username->userid,再通过userid查询相应的信息。

实际上这个做法很简单,但是我们不要忽略了一个额外的隐患,那就是数据不一致的隐患。存储在redis里的username->userid和存储在mysql里的userid->username必须需要是一致的,这个保证起来很多时候是一件比较困难的事情,举个例子来说,对于修改用户名这个场景,你需要同时修改redis和mysql,这两个东西是很难做到事务保证的,如mysql操作成功 但是redis却操作失败了(分布式事务引入成本较高),对于互联网应用来说,可用性是最重要的,一致性是其次,所以能够容忍小量的不一致出现.
毕竟从占比来说,这类的不一致的比例可以微乎其微到忽略不计(一般写更新也会采用mq来保证直到成功为止才停止重试操作)

在这样的架构下,我们来看看数据存储的瓶颈是什么?

在这个拆分理念上搭建起来的架构,理论上不存在瓶颈(sharding key能确保各cluster流量相对均衡的前提下),不过确有一件恶心的事情,那就是cluster扩容的时候重做数据的成本,如我原来有3个cluster,但是现在我的数据增长比较快,我需要6个cluster,那么我们需要将每个cluster 一拆为二,一般的做法是

1.摘下一个slave,停同步,

2.对写记录增量log(实现上可以业务方对写操作 多一次写持久化mq  或者mysql主创建trigger记录写 等等方式)

3.开始对静态slave做数据, 一拆为二

4.回放增量写入,直到追上的所有增量,与原cluster基本保持同步

5.写入切换,由原3 cluster 切换为6cluster

有没有类似飞机空中加油的感觉,这是一个脏活,累活,容易出问题的活,为了避免这个,我们一般在最开始的时候,设计足够多的sharding cluster来防止可能的cluster扩容这件事情

V5.0  云计算 腾飞(云数据库)

云计算现在是各大IT公司内部作为节约成本的一个突破口,对于数据存储的mysql来说,如何让其成为一个saas(Software as a Service)是关键点。在MS的官方文档中,把构建一个足够成熟的SAAS(MS简单列出了SAAS应用的4级成熟度)所面临的3个主要挑战:可配置性,可扩展性,多用户存储结构设计称为”three headed monster”. 可配置性和多用户存储结构设计在Mysql saas这个问题中并不是特别难办的一件事情,所以这里重点说一下可扩展性。

Mysql作为一个saas服务,在架构演变为V4.0之后,依赖良好的sharding key设计, 已经不再存在扩展性问题,只是他在面对扩容缩容时,有一些脏活需要干,而作为saas,并不能避免扩容缩容这个问题,所以只要能把V4.0的脏活变成 1. 扩容缩容对前端APP透明(业务代码不需要任何改动)  2.扩容缩容全自动化且对在线服务无影响 那么他就拿到了作为Saas的门票.

对于架构实现的关键点,需要满足对业务透明,扩容缩容对业务不需要任何改动,那么就必须eat our own dog food,在你mysql saas内部解决这个问题,一般的做法是我们需要引入一个Proxy,Proxy来解析sql协议,按sharding key 来寻找cluster, 判断是读操作还是写操作来请求主 或者 从,这一切内部的细节都由proxy来屏蔽。

这里借淘宝的图来列举一下proxy需要干哪些事情

百度公开的技术方案中也有类似的解决方案,见文章最后资料部分链接

对于架构实现的关键点,扩容缩容全自动化且对在线服务无影响; 扩容缩容对应到的数据操作即为数据拆分和数据合并,要做到完全自动化有非常多不同的实现方式,总体思路和V4.0介绍的瓶颈部分有关,目前来看这个问题比较好的方案就是实现一个伪装slave的sync slave, 解析mysql同步协议,然后实现数据拆分逻辑,把全量数据进行拆分。具体架构见下图:

其中Sync slave对于Original Master来说,和一个普通的Mysql Slave没有任何区别,也不需要任何额外的区分对待。需要扩容/缩容时,挂上一个Sync slave,开始全量同步+增量同步,等待一段时间追数据。以扩容为例,若扩容后的服务和扩容前数据已经基本同步了,这时候如何做到切换对业务无影响? 其实关键点还是在引入的proxy,这个问题转换为了如何让proxy做热切换后端的问题。这已经变成一个非常好处理的问题了.

另外值得关注的是:2014年5月28日——为了满足当下对Web及云应用需求,甲骨文宣布推出MySQL Fabric,在对应的资料部分我也放了很多Fabric的资料,有兴趣的可以看看,说不定会是以后的一个解决云数据库扩容缩容的手段。