qconshanghai2013-[王凯]-[公有云用户如何应对云计算安全风险]

《qconshanghai2013-[王凯]-[公有云用户如何应对云计算安全风险]》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、QCon北京2014大会4月17—19日QConShanghai2013-@InfoQinfoqchina特别感谢QCon上海合作伙伴食遇TM美食社交私人助理公有云用户如何应对云计算安全风险Author:Ken/王凯Email:k@ishiyu.cn云计算开发者和使用者提纲•从云计算业务模型谈云计算安全风险•公有云用户面临的安全挑战有哪些•谁应该负责云计算安全•自力更生——食遇都使用了哪些安全措施•总结公有云用户如何规避与防御安全攻击•从安全角度看如何选择公有云服务提供商影响安全的因素：技术架构、业务模式、部署方式安全是一个系统工程，各司其云计算安全威

2、胁模型职Threat#1:AbuseandNefariousUseofCloudComputing恶意滥用云计算Threat#2:InsecureInterfacesandAPIs不安全的接口／APIsThreat#3:MaliciousInsidersThreat#4:SharedTechnologyIssues共享技术产生的问题Threat#5:DataLossorLeakage数据泄漏Threat#6:AccountorServiceHijacking帐号/服务劫持Threat#7:UnknownRiskProfile其他未知风险Source:C

3、SATOPthreats公有云用户：整个系统可见度、可控性降低公有云用户面临的安全挑战有哪些•Multi-tenancyrisks多租户－来自邻居的攻击e.g.SSH弱口令暴力破解,sniffer嗅探•DataLeakage数据泄露－Datamanagementatrest磁盘镜像文件管理－Dataretention数据留存－DataSanitization数据清除•EncryptionKEYmanagement加密KEY管理•AccessControl访问控制－SSH,webconsoleaccount,Firewall•Lackoftranspar

4、ency缺乏透明度－Businesseshavelimitedcontrolandvisibility－管理不规范，缺少公开的流程与制度，SLA•Securityresponsibility安全职责不清晰：用户vs厂商谁应该负责安全保障工作？谁应该对安全负责——众说纷纭Responsibility数据是我们自己的！35%33%SharedProviderUser32%Source:PonemonInstitute,2013谁应该负责云计算安全——各司其职，多层防御•PhysicalandEnvironmentalSecurity•TheHypervis

5、or－InstanceIsolation•CPU,MEM.•Network•Storage•HostOS－AdministratorsofCloudProvider•GuestOS－Customerhavefullrootaccess•Updating&Patching•Certificate‐basedSSHv2Fig.AmazonAWSEC2MultipleLayersofSecurity•Encryption&Backup如何应对——食遇安全实践食遇能做什么：食欲——相遇——食遇约会聚餐：去哪吃、吃什么？怎么通知大家？不知吃什么？食遇——美食社交

6、私人助理（约会聚餐不再愁）通过它可以发现美食、以食会友，轻松分享美食与乐趣，及时了解朋友口味，从此不再为请客聚餐吃什么发愁123✚✚WeChatAPPServer食遇产品构成三元素食遇——技术架构食遇服务端：构件在公有云基础实施之上IAAS食遇安全实践——访问控制远程管理——SSH暴力破解（来自邻居的攻击）也许那不会发生在我身上……结合社工库进行暴力破解效果惊人！！！三步防范SSH暴力破解1.修改SSH默认端口22为其他2.配置证书访问/etc/ssh/sshd_config－RSAAuthenticationyes－PubkeyAuthenticat

7、ionyes－AuthorizedKeysFile.ssh/authorized_keys－PasswordAuthenticationno3.DenyHosts–自动阻断暴力破解尝试－DenyHostsisalog-basedintrusionpreventionsecuritytoolforSSHserverswritteninPython－http://denyhosts.sourceforge.net/－SECURE_LOG=/var/log/secure－HOSTS_DENY=/etc/hosts.deny－BLOCK_SERVICE=ssh

8、d－DENY_THRESHOLD_INVALID=3食遇安全实践——传输安全•保证传输安全－S