关于安全性:数据传输-如何开启-DTLE-的-HTTPS-访问模式

作者:刘安 爱可生测试团队成员,次要负责 DTLE 开源我的项目相干测试工作,善于 Python 自动化测试开发。 本文起源:原创投稿 *爱可生开源社区出品,原创内容未经受权不得随便应用,转载请分割小编并注明起源。 如何开启DTLE的HTTPS拜访模式DTLE默认提供的是HTTP的拜访模式,然而在应用DTLE的过程中未免要通过API提交诸如数据库的用户名、明码、IP、端口等信息。如果这些信息被第三方获取到,那么对于数据库的使用者几乎就是一场劫难。因而DTLE提供了HTTPS的拜访模式,爱护咱们的信息安全。 启用DLTE的HTTPS拜访模式须要SSL证书,如果你搭建的集群须要向外提供可信的服务能够向证书管理机构申请。本文应用本人生成的SSL证书来演示如何配置DTLE使HTTPS拜访模式失效。 1. 下载安装DTLE这里应用的是dtle-ce-4.22.01.0版本,留神先不要启动DTLE服务 shell> curl -O "https://github.com/actiontech/dtle/releases/download/v4.22.01.0/dtle-ce-4.22.01.0.x86_64.rpm"shell> rpm -ivh dtle-ce-4.22.01.0.x86_64.rpm --prefix=/opt/dtle2. 生成证书文件和私钥文件# 须要装置opensslshell> yum install openssl -yshell> cd /opt/dtle/etc/dtle/# 生成私钥文件shell> openssl genrsa -out server.key 1024Generating RSA private key, 1024 bit long modulus....++++++........++++++e is 65537 (0x10001)# 生成证书申请文件,此步骤能够全副回车,不输出任何信息shell> openssl req -new -key server.key -out server.csrYou are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) [XX]:CNState or Province Name (full name) []:ShanghaiLocality Name (eg, city) [Default City]:XuhuiOrganization Name (eg, company) [Default Company Ltd]:actiontechOrganizational Unit Name (eg, section) []:qaCommon Name (eg, your name or your server's hostname) []:dtleEmail Address []:852990221@qq.comPlease enter the following 'extra' attributesto be sent with your certificate requestA challenge password []:An optional company name []:# 生成证书文件shell> openssl x509 -req -in server.csr -out server.crt -signkey server.key -days 365Signature oksubject=/C=CN/ST=Shanghai/L=Xuhui/O=actiontech/OU=qa/CN=dtle/emailAddress=852990221@qq.comGetting Private keyshell> lsconsul.hcl nomad.hcl server.crt server.csr server.key3. 编辑nomad.hcl,配置证书文件和私钥文件shell> vi nomad.hcl... cert_file_path = "/opt/dtle/etc/dtle/server.crt" key_file_path = "/opt/dtle/etc/dtle/server.key"...4. 启动DTLEshell> systemctl start dtle-consul dtle-nomad5. 验证https开启胜利# 应用http拜访shell> curl -X POST "http://127.0.0.1:8190/v2/loginWithoutVerifyCode" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"password\": \"admin\", \"tenant\": \"platform\", \"username\": \"admin\"}"Client sent an HTTP request to an HTTPS server.# 应用https拜访,但咱们的证书没有通过CA认证shell> curl -X POST "https://127.0.0.1:8190/v2/loginWithoutVerifyCode" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"password\": \"admin\", \"tenant\": \"platform\", \"username\": \"admin\"}"curl: (60) Peer's certificate issuer has been marked as not trusted by the user.More details here: http://curl.haxx.se/docs/sslcerts.htmlcurl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option.If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.# 应用https拜访,减少-k参数跳过查看服务器的SSL证书是否正确shell> curl -s -k -X POST "https://127.0.0.1:8190/v2/loginWithoutVerifyCode" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"password\": \"admin\", \"tenant\": \"platform\", \"username\": \"admin\"}" | jq{ "message": "ok", "data": { "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2NTAxMjAzNjcsImdyb3VwIjoicGxhdGZvcm0iLCJuYW1lIjoiYWRtaW4ifQ.I1XDK7Ar1JLKLWlxWEHX0vCWG07dDqBHieCBmjEVz0E" }}shell> curl -s -k -X GET "https://127.0.0.1:8190/v2/nodes" -H "accept: application/json" -H "Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2NTAxMjA0MjYsImdyb3VwIjoicGxhdGZvcm0iLCJuYW1lIjoiYWRtaW4ifQ.PoPwOWQF09uaUf6vu0rTPQVpLfF59UIhq-lLBBVhTbc" | jq{ "nodes": [ { "node_address": "127.0.0.1", "node_name": "nomad0", "node_id": "21bd1636-0beb-e4c6-34fd-d35be32414e9", "node_status": "ready", "node_status_description": "", "datacenter": "dc1", "nomad_version": "1.1.2", "dtle_version": "4.22.01.0-4.22.01.x-952bb3d", "leader": true, "member": true } ], "message": "ok"}6. 抓包查看传输的信息应用https, 登录DTLE提交的信息是通过加密的: ...

April 26, 2022 · 3 min · jiezi

关于安全性:从十八线熬到一线网络安全行业的新故事

1995年,中国第一家网络安全企业——天融信公司成立(从有记录的工商信息查问得悉),掀开了中国网络安全行业倒退的尾声。尔后的短短数年,启明星辰、卫士通、绿盟科技等平安公司相继成立。这些公司成为了中国网络安全行业的“黄埔军校”,向互联网企业、平安厂商,乃至起初的云服务商,以及各行各业的平安岗位源源不断地输送平安人才,影响至今。 明天,乘着产业互联网浪潮和政策利好的东风,一群怀揣网络安全现实的年轻人开始摸索网络安全细分畛域,创建了一批“专精特新”企业,推动中国网络安全产业从“少而全”走向“多而专”。 中小平安企业的春天 2021年,注定是中国网络安全行业不平庸的一年。 国家从立法层面和政策领导层面继续晋升对网络安全的器重水平,《数据安全法》、《网络安全产业高质量倒退三年行动计划》、《要害信息基础设施平安管理条例》、《网络安全破绽治理方法》、《个人信息保护法》等重磅的政策法规都在这一年里密集公布。 网络安全行业“大动作”一直,A股市场雷厉风行,网络安全概念指数一度单月涨幅超30%,将行业推至千亿规模市场。 始终身居幕后的网络安全来到了台前。许多扎根平安圈多年的老炮儿,不禁感叹“终于从十八线行业熬成了一线”。 据CCIA(中国网络安全产业联盟)数据统计,2021年上半年我国共有4525家公司发展网络安全业务,相比上一年增长27%。2021年前三季度行业总体营业支出相较于2020年同比增长 23.31%。据IDC最新预测,2021年中国网络安全市场总体收入将达到102.2亿美元,并无望在2025年增长至187.9亿美元,增速继续领跑寰球。 政策驱动也催生了一批新兴的平安细分赛道,吸引守业公司退出。 2021年7月12日公布的《网络安全产业高质量倒退三年行动计划》首次把“专精特新”和“单项冠军”概念引入了网络安全产业。 《行动计划》重点提到,将针对网络安全产品细分市场优良企业,放慢培养网络安全单项冠军企业和专精特新“小伟人”企业。 如何了解网络安全行业这些“专精特新”企业? 经验了中国网络安全产业倒退历程的腾讯平安专家陈颢明打了一个比喻:如果把网络安全厂商比作“医院”,在过来二十多年工夫里,国内只有多数的“大型综合医院”,医治宽泛存在的基础性“疾病”。然而随着越来越多的企业步入数字化的轨道,“大型综合医院”曾经远远不能满足一劳永逸的需要和“疑难杂症”。因而,近年来诞生了各个垂直畛域的“专科医院”,例如专一威逼情报的“眼科医院”、专一加密的“骨科医院”等等。他们用本身的一技之长针对性解决问题,补救了市场空缺。 技术专业化、畛域精细化、产品特色化、计划新鲜化,就是网络安全行业的“专精特新”。 欧美的隐形冠军们 “专精特新”在国外有另外一个词,叫做“隐形冠军”,由德国管理学家赫尔曼·西蒙提出,指那些不为公众所熟知,却在某个细分行业或市场占据领先地位,领有外围竞争力和明确策略,其产品、服务难以被超过和模拟的中小型企业。 而在美国,网络安全产业倒退得更早,也更快进入成熟阶段,并催生了一批又一批隐形冠军。 美国的网络安全产业同样有大型综合企业和独立平安厂商。以微软(Microsoft)、谷歌(Google)、思科(Cisco)、IBM等为代表的网络巨头,在网络安全产业中扮演着地基的角色。 一年前的明天,国内网络安全行业正在热议一条重磅新闻。微软CEO发表微软在2020年的平安业务收入达到100亿美元,年增长率超过40%。彼时,这个数字简直等于中国网络安全行业企业一年支出的总和。“原来微软才是寰球最大的网络安全厂商”的声音一时在行业震荡。 只管起初有业界人士剖析祛魅,100亿美元蕴含了来自本身产品Office 365、Azure等服务所产生的支出,同时还有靠近40%支出来自纯渠道,30%来自渠道单干。然而仍然能够看出微软成熟的合作伙伴生态所带来的奉献。 巨头之外,则是网络安全产业的巨子们——赛门铁克(Symantec)、迈克菲(McAfee)、趋势科技(Trend micro)。此外,还有很多独立平安厂商,专一于系统安全、网络安全或其余平安技术的某个垂直畛域。他们不断创新迭代,提出产品概念,发明出了细分市场,在平安产品中成为独立品类的“隐形冠军”。这些独立平安厂商中,既有FireEye这样的超级新锐,也有NetScreen、Fortinet、Palo Alto Networks等公司实现概念接力、迭代翻新。 FireEye成立于2004年,采纳沙箱前置与流量产品联合的办法,跑出了一条全新品类的赛道,最终造成了本人独特的反APT和0day破绽的产品状态。FireEye的疾速崛起能够说是平安界的神话,在2012到2014年疾速成长,成为120亿美元网络安全市场中回升最快的一颗明星。 在一些新兴的畛域,同样有因业余技术而被青眼的企业。2022年伊始,据路透社报道,谷歌以约5亿美元的价格收买了一家以色列的网络安全初创公司Siemplify。Siemplify是少数几家独立的SOAR(平安编排、自动化与响应)提供商。近年来,许多企业开始须要各种不同的网络安全工具且无效联动并主动响应平安问题,SOAR产品因而变得越来越受欢迎。 这些网络安全企业,又是如何一步一步成为“隐形冠军”? 长年与钻研机构打交道的腾讯平安策略专家周奕良,从另一个角度答复这个问题。隐形冠军的诞生就是一个Gartner魔力象限从无到有,再挪动到魔力象限右上角的过程。 魔力象限 Gartner是一家权威的IT钻研与参谋征询公司。据介绍,Gartner早在1990年起,就开始关注网络安全产业,并继续关注一些新兴的垂直赛道,基于市场体现和钻研报告,输入一张细分畛域的魔力象限。魔力象限赋予新品类一个规范定义和方向,同时定期更新,挖掘出一批全新赛道的优良企业。 以后面提到的SOAR为例,SOAR是Gartner 2017年提出的新概念。过后,大中型企业都曾经建设了绝对比拟齐备的平安经营核心(SOC),然而经营过程中面临诸如:大量的安全事件须要人员染指、经营老本高、平安响应工夫长、人工染指多等问题。解决此类经营问题的全新赛道——SOAR应运而生。同时,一边是Gartner不断完善性能规范和测评规范,另一边是一直有厂商退出和送测,一轮一轮的魔力象限随之出炉。最终,跑到魔力象限右上角的厂商成为了“单项冠军”。 欧美市场用二十年的工夫,将网络安全产业从萌发到成熟,再孵化出一条条垂直赛道和一家家隐形冠军。回望国内,一群怀揣网络安全现实的年轻人也在摸索属于咱们本人的“专精特新”网络安全企业。 国内新锐公司的摸索之路 前文提到,2021年是网络安全政策频发的一年,行业一片利好。而上一次让平安圈个体“兴奋”,还要追溯到2014年。那一年的2月,地方网络安全和信息化领导小组第一次会议召开。行业内外耳熟能详的“没有网络安全就没有国家平安,没有信息化就没有现代化。”正是出自那次会议。 彼时,已在昆仑万维管理层的张福也判断到网络安全行业行将迎来微小的变动。半年后,张福从行将上市的昆仑万维到职。“那是好多好多钱呢。”衣着程序员标配格子衬衫的张福说,他算了一下,放弃的股权靠近3000万元。 紧接着,他用现实情怀感动了另外八位气味相投的技术宅男。开启“摸黑”守业之路,成立了青藤云平安。 只管过后并没有“专精特新”这样的词,更没听说过国外的“隐形冠军”。然而张福和他的青藤云平安自成立之初就把“自适应平安”当做了主赛道,并以主机平安作为重要的业务切口。蛰伏七年,青藤云平安终于和阿里云、腾讯云、华为云跻身中国云主机平安第一梯队,并在2021年6月发表实现6亿元C轮融资。 对产品和赛道的保持,让青藤云平安从无人问津到发展壮大。“如果没有走进去,至多咱们对于这条路的摸索是十分有意义的,给大家在这个方向上带一段路。将来肯定会有公司走进去,尽管不肯定是青藤。”张福在一次采访中说道。 张福 青藤云平安的胜利,让人们看到中国网络安全产业的更多可能性。其中包含不少从网络安全大厂到职的守业青年。 唐伽佳,一个典型的网络安全从业者,大学毕业后进入网络安全的“黄埔军校”绿盟科技,之后到网络安全大厂负责产品研发,随同了中国网络安全十余年的倒退变迁。在2020年的夏天,来到大厂,守业成立了一家专一XDR的公司——将来智安。 新冠疫情催熟了近程办公,间接带火了办公平安。其中,最火的概念莫过于“零信赖”,数据显示,2020年一年就有数十家企业研发和售卖“零信赖”产品。而同一年,唐伽佳却决然抉择了另外一条过后不太热门的赛道——XDR(扩大的威逼检测与响应)。 他察看到,长期以来威逼检测的流量侧、终端侧和攻打检测等技术一直倒退,但客户始终感觉存在比拟大的问题,容易陷入看不到残缺攻打事件、平安经营人员投入多效率低的窘境。唐伽佳长期和客户交换后发现,这些问题或者都有一个共性,如果在威逼检测和响应畛域能解决这些问题,那肯定是客户须要的。 XDR最早由Palo Alto Networks于2018年提出,在2020年被Gartner命名为第一大平安趋势,Gartner称XDR解决方案将无效进步检测准确性、平安经营效率。 据唐伽佳分享,他们合伙人团队都有十余年的威逼检测教训,见证了这个细分畛域的迭代、降级和自动化。有一天聚在一起探讨到如何更无效地解决中国企业客户的问题时,一拍即合,也就萌发了守业的念头。“过后不晓得国外曾经有这个概念,当咱们关注到Gartner的文章时才发现,它与咱们的想法不约而同。” 因为守业之初就有丰盛的技术和教训,加上对产品的专一和执着,将来智安在成立一年之内就推出了国内首款XDR产品,该产品将网络和终端的告警日志进行对立交融,用以放慢威逼响应速度,能够无效进步经营效率。同年7月取得红杉资本等近亿元的融资。 唐伽佳 同样从大厂到职守业的,还有曹静。入行十五年的曹静先后从神州泰岳到绿盟,再到互联网大厂,始终从事网络安全的相干工作,现在仍然放弃着对网络安全的激情和新鲜感。 2021年6月,曹静和几个合伙人成立了灰度平安,专一平安危险评估自动化。 谈到守业的契机,曹静认为是天时地利人和,“‘地利’是国家器重政策利好,加上行业认可度高;‘天时’是初创团队这么多年都扎根平安经营畛域,而以后很多企业正在从建设期曾经迈向经营期,须要自动化伎俩撑持;‘人和’则是可能聚拢一群领有共同理想的人。” 至于为什么抉择“平安危险评估自动化”,曹静解释道,“咱们次要联合国内客户需要,参考了国外的技术,中西联合造成了这一条新赛道。使用入侵攻打模仿、VTP等新技术,去从新定义‘平安危险评估自动化’。” 在过来多年的工作教训中,曹静粗浅感触到,很多企业曾经从平安建设期迈向了经营期。前些年,企业做平安根本是买买买,把该买的防护设施,检测设施都买齐了。然而当初,迈入经营期之后,如何让这些设施施展应有的效力,晋升平安进攻短板,是很多企业现阶段的困惑。甲方企业的平安经营所需的人员又投入过大,必然要靠自动化的伎俩实现降本增效。这也是她守业并抉择这一条赛道的初衷。 这一赛道的价值同样被行业所认可,灰度平安公司成立不久即取得了千万级天使轮融资,并在同年12月公布了第一款产品“先知”。该产品通过实战化伎俩,对企业的平安防御能力进行评估验证,度量平安危险。 曹静 资本青眼,但打铁还需本身硬 据《中国网络安全产业剖析报告》统计,2020-2021年,中等规模网络安全企业上市过程减速,广泛取得了资本青眼。泛滥初创企业涌现,并取得了晚期投资。从融资金额角度来看,2020年至今融资额度处于亿元以上的融资事件有65起,相较于2019年减少了42起,千万级以上融资事件数量超过70起。行业整体出现龙头领跑,新秀涌起的场面,更多的平安从业者迈入了网络安全守业的大潮。 将来智安投资方,红杉中国董事总经理翟佳在承受媒体采访时曾示意,网络安全是国家重点关注和倒退行业畛域,也是红杉资本重点关注的科技赛道。 在2021年的融资轮次中,种子轮、天使轮的融资事件共计18起。据平安419报道,多家资本方都曾走漏,目前在网络安全行业不偏向投天使轮,因而这也侧面通知咱们,这些胜利实现天使轮融资的企业占据了更加前沿的细分赛道和技术劣势,他们身上有着极大的发展潜力。 ...

February 14, 2022 · 1 min · jiezi

关于shiro:如何控制项目的访问权限来保证项目安全SpringBoot-集成-Spring-Security-安全框架使用指南

平安框架shiroSpring Security应用程序的两个次要区域:认证和受权(这两个次要区域是Spring Security的两个指标) 认证(Authentication): 建设一个申明的主体过程一个[主体]个别是指[用户],[设施]或一些能够[在应用程序中执行动作的其它零碎]受权(Authorization): 访问控制确定一个主体是否容许在你的应用程序执行一个动作的过程为了到达须要受权的点,主体身份曾经有认证过程的建设 Spring Security针对Spring我的项目的平安框架,是Spring Boot底层平安模块默认的技术选型能够实现web安全控制,只须要引入spring-boot-starter-security依赖配置即可Spring Security中的类: WebSecurityConfigurerAdapter: 自定义Security策略AuthenticationManagerBuilder: 自定义认证策略@EnableWebSecurity: 开启WebSecurity模式 1.引入spring-boot-starter-security依赖2.编写SpringSecurity配置类2.1 定制申请的受权规定2.2 开启主动配置的登录性能(/login来到登录页;重庆向到/login?error示意登录失败)2.3 开启主动配置的登记性能(拜访/logout申请,示意用户登记并清空session;登记胜利返回/login?logout)2.4 开启主动配置的记住明码性能(http.rememberMe();)-登录胜利当前,将Cookie发送给浏览器保留,能够实现记住明码性能;点击登记会删除Cookie,就没有记住明码性能默认post模式的/login代表解决登录2.5定义认证规定@EnableSecuritypublic class MySecurityConfig extends WebSecurityConfigureAdapter{@Overrideprotected void configure(HttpSecurity http) throws Exception{ // 定制申请的受权规定 http.authorizeRequest().antMatches("/").permitAll() .antMatches("/level/**").hasRole("VIP"); // 开启主动配置的登录性能,如果没有权限就会跳转到登录页面 http.formLogin().loginPage("/"); // 跳转到自定义登录页 http.logout().logoutSuccessUrl("/"); // 登记胜利返回首页 http.rememberMe().rememberMeParameter("remember"); // 开启主动配置的记住明码性能}@Overrideprotected void configure(AuthenticationManagerBuilder auth) throws Exception{ auth.inMemoryAuthentication().withUser("username").password("password").roles("role1","role2") .and() .withUser("username").password("password").roles("role1","role2")}3.管制申请的拜访权限Thymeleaf Extras Springsecurity4

April 25, 2021 · 1 min · jiezi

关于安全性:安全杂记

最近,因为负责得一个网站受到3次网络攻击。间接敞开服务了。所以这两周就主攻平安了。以前对平安的确理解太少了。趁着这个机会放松学起来。O(∩_∩)O1、CIA准则机密性(Confidentiality)、完整性(Integrity)、可用性(Availability),咱们能够简称为 CIA 三元组,是平安的根本准则。实践上来说,一个残缺的平安保障体系,应该充分考虑到所有的 CIA 准则。机密性用一句话来说就是,确保数据只被受权的主体拜访,不被任何未受权的主体拜访。 简略用一个词总结就是“不可见”。完整性就是确保数据只被受权的主体进行受权的批改,简略来说,就是“不可改”。可用性就是确保数据可能被受权的主体拜访到 ,简略来说,就是“可读”。

April 19, 2021 · 1 min · jiezi

关于小程序:能力更新|升级营销短信和安全风控能力快手小程序-SDK-内测招募中

近期通晓云的版本更新告诉频率低于去年,但咱们的产品经理和工程师始终在致力地迭代产品,更是时刻关注大家反馈的问题和需要,始终致力于为企业、集体开发者提供更好用的产品和服务。  明天通晓妹将把本月的更新内容进行大汇总,让你能够疾速理解:通晓云近期有哪些新能力已上线,正在做哪些大家期待已久的性能。 本月更新内容多平台能力通晓云行将反对快手小程序平台的接入,登录接入跟微信、QQ 等其它小程序一样简略。你能够在快手生态内,以快手小程序为载体,基于内容、服务的供应,或短视频、直播内容的生产连贯用户,实现本身业务的价值实现。  目前内测炽热招募中,如果你已有或筹备开发快手小程序,速来申请,优先体验。咱们将继续助力大家打造全平台产品体系,让业务没有死角。  Ps:反对通晓推送、客服音讯等能力也曾经安顿在路上,不日将与大家见面,敬请期待。 营销能力1、订阅音讯减少短信补充发送性能。当向用户发送订阅音讯失败时,你就能够通过小程序外链短信营销性能来告诉他们,防止用户错过任何一条重要音讯,用户触达更全面、更轻松。2、优化营销短信配置和发送流程。简化签名和短信模板审核流程,进步经营人员的工作效率。搭配小程序外链,用户增长成果更显著。3、小程序码减少下载按钮,不便经营人员下载曾经设置好的小程序码。小程序码反对自定义设置页面名称、页面门路、款式,以便用户快速访问指定页面,用户留存与转化更无效。 平安风控1、微信加密数据解密。当调用微信小程序接口获取敏感信息时,返回的数据往往是通过加密的,开发者如需获取这些敏感数据,须要对接口返回的加密数据进行对称解密。详见开发文档2、新增微信小程序平安风控接口的接入。微信针对小程序各利用场景中可能存在的歹意注册、营销舞弊等黑产危险和平安问题,公布了平安风控接口,帮助开发者应答刷单、虚伪交易、歹意骗取补贴等营销舞弊危险和批量注册、伪造身份等注册黑产危险,以便开发者保护小程序经营秩序和平安。即刻接入,让你的小程序安全系数更高。详见开发文档:微信小程序-开发文档、云函数-开发文档 其余更新1、模板音讯资源包新增 ¥40 / 50 万条的套餐,抉择更多、优惠力度更大。 版本更新预报1、基于企业微信的社群经营解决方案,助力企业打造私域流量体系。 2、快手小程序反对通晓推送、客服音讯。 3、公布新版微信小程序 SDK,同步调整获取用户信息的相干接口。详见微信官网文档 近期平台流动通晓云和 QQ 小程序携手推出校园助力打算,带来官网的生态能力,一站式赋能在校学生开发和经营小程序。7 月 31 日前报名申请,将有机会取得腾讯 QQ 小程序和通晓云的技术领导和经营赋能。立刻报名 一张图带你通晓咱们 3 月份做了哪些事

March 26, 2021 · 1 min · jiezi

【实战教程】只需三步,用云函数又快又安全地实现小程序支付

本文主要侧重于讲述小程序在线支付功能中的编程思想和编程模式,并在必要的地方提供关键代码示例。(文末也将附上关键的 js 代码)为方便演示,这里将实现一个最简单的虚拟商品的订单支付功能,订单略去了收货地址和多规格、多数量的情况,示例中仅讨论在商品详情页中直接创建订单并发起支付的情况。需要分别定义 Product 表和 Order 表进行数据存取,在 BaaS 后台中创建两张数据表。一、数据表结构设计Product 表:数据表录入权限:所有人数据行读写权限:创建者可写,所有人可读Order 表:数据表录入权限:所有人数据行读写权限:创建者可写,创建者可读商品的订单结算和支付流程一般包括“创建订单 -> 支付 -> 更新订单状态”三个步骤。下文中将分析几种实现该流程的方案,供我们一起探讨。二、客户端创建订单,客户端更新订单状态我们先来看下只在客户端中如何处理这些逻辑。1) 创建订单:Order 表中创建一条新记录,status 字段默认值为 “no_paid”,保存订单金额,商品快照和商品 id 以及订单创建者,其中订单创建者由 BaaS 的用户系统自动处理,值为创建订单的用户 id:/** * 创建订单处理函数 /createOrderHandle() { const orderTableId = 12345678 const tableObject = new wx.BaaS.TableObject(orderTableId) const createObject = tableObject.create() const product = this.data.product const data = { product_id: product.id, product_snapshot: product, total_cost: product.price, status: ’no_paid’, } // 客户端创建订单,客户端更新订单状态 return createObject.set(data).save().then(res => { this.order = res.data || {} return this.pay(this.order) }).then(transactionNo => { return this.updateOrder(transactionNo) }).then(res => { wx.navigateTo({ url: ‘../order/order’ }) })2)支付:调用 BaaS SDK 提供的支付方法 wx.BaaS.pay,调起微信支付:/* * 发起微信支付 * @param {Object} order /pay(order) { const product = this.data.product const orderTableId = 12345678 const params = { totalCost: order.total_cost, merchandiseDescription: product.title, merchandiseSchemaID: orderTableId, merchandiseRecordID: order.id, merchandiseSnapshot: product, } return wx.BaaS.pay(params).then(res => { return res.transaction_no })}3)更新订单状态:支付成功后,更新 status 字段值为 “paid”,并更新微信支付序列号:/* * 更新订单状态 * 仅在由客户端更新订单状态时使用 * @param {String} transaction_no 支付成功后由微信返回的微信支付序列号 /updateOrder(transaction_no) { const orderTableId = 12345678 const tableObject = new wx.BaaS.TableObject(orderTableId) const recordId = this.order.id const record = tableObject.getWithoutData(recordId) record.set(‘status’, ‘paid’) record.set(’transaction_no’, transaction_no) return record.update()}我们从整体上来看支付流程,便能发现订单状态实质上是由客户端中 updateOrder 方法发起请求来进行更新的。而这一情况将导致极大的安全隐患。因为从原则上来说,我们认为来自客户端的信息都是不可信的,订单状态很容易被伪造出的一个请求跳过支付直接将状态更新为 ‘paid’,并更新一个假的 transaction_no。这意味着,不花一分钱也能将订单变为已支付。在生产环境中,任何情下都不应该使用这种支付流程。三、客户端创建订单,触发器更新订单状态基于这种情况,你或许会想:既然由客户端来更新订单状态会引起安全问题,又没有后端开发者参与,要怎么做?BaaS 平台中触发器和云函数可以帮你解决这个问题。它们可以完成这种非客户端的处理逻辑,同时使用它们的时候跟开发后端应用又有很大的不同。首先来看一下触发器(Trigger),触发器是一种当触发条件被满足,将会执行触发器中的事先定义的动作,定义好的动作可以是操作数据库或者调用云函数。我们希望当支付完成之后,触发器可以帮我们自动地操作数据库,更新订单对应的 status 和 transaction_no 字段。触发器设置如下:「触发类型」选择微信支付回调,条件是支付成功后执行触发器。一般触发器类型常见的还有操作数据表,定时任务等,分别对应操作数据表后触发和定时触发。「动作」定义了触发器将要执行的操作,这里是更新 Order 数据表对应的 status、total_cost 和 transaction_no 字段。更多触发器的具体细节,不同平台的实现有所不同,在此不展开讨论。借助触发器,客户端创建订单成功后不需要再调 updateOrder 方法,Order 订单的数据会自动更新成支付成功对应的状态:/* * 创建订单处理函数 /createOrderHandle() { … // 与上文相同 // 客户端创建订单,触发器自动更新订单状态 return createObject.set(data).save().then(res => { this.order = res.data || {} return this.pay(this.order) }).then(res => { wx.navigateTo({ url: ‘../order/order’ }) })}值得注意的是,上面介绍的第一种方案中 Order 表的 ACL 数据行读写权限是创建者可写的,意味着创建者可以对数据进行任意操作,将更新订单状态的工作交给触发器后,Order 表的 ACL 数据行读写权限应设置为「不可写」,保证 Order 表的数据创建后不会由外部更改,提高了数据的安全性。四、云函数创建订单,触发器更新订单状态细心的读者可能发现了除了 status 和 transacton_no 字段外,还由触发器自动更新了 total_cost 字段,保存的是实际支付的金额。这就引出了另外一个问题,虽然现在不能通过客户端修改订单状态,但是创建订单的所有数据仍是由客户端发起请求,在请求参数中定义的,这种方式同样很容易被人篡改数据,比如 1000 元的商品可以被更改成 1 元甚至 0 元,造成只需要花很少的钱就可以买到高价值的商品。使用触发器自动根据微信支付回调更新 total_cost 可以保证无论何种情况下,数据中保存的都是最终用户实际支付的金额。虽然这种方式可以事后帮助我们发现订单金额异常的问题,但还是不能解决在创建订单时金额被篡改的问题,这又要如何解决呢?这时候创建订单的功能应该交给后端逻辑去做了,在 BaaS 平台中就需要用到云函数了,云函数又被称为 FaaS(Functions as a Service)函数即服务。云函数是一段可以部署在服务端的代码,关键词是一段代码,而不是一整套的后端逻辑,它本质上就是函数而已,特别是对于运行在 node.js 环境下的云函数来说,它跟平常所写的 JavaScript 代码几乎一模一样,对前端开发者来说非常容易上手。云函数可以由 SDK 或触发器调用,也可以在云函数之间相互调用。为了避免创建订单时客户端数据篡改或商品信息不能实时同步的问题,我们将创建订单的逻辑迁移到 BaaS 平台的云函数中:关注「知晓云」微信公众号,在微信后台回复「创建订单」,获取完整的【创建订单】云函数源码。调用该云函数时传入商品 id,云函数先查出此商品的具体信息,再使用该商品信息来创建订单,整个过程在 BaaS 平台的云函数系统中完成,保证了数据的准确性。支付完成后,触发器同样会自动更新订单状态。客户端中使用 invokeFunction 方法调用云函数:/* * 创建订单处理函数 /createOrderHandle() { … // 与上文相同 // 使用云函数创建订单,触发器更新订单状态 wx.BaaS.invokeFunction(‘createOrder’, { product_id: this.data.product.id }).then(res => { this.order = res.data || {} return this.pay(this.order) }).then(res => { wx.navigateTo({ url: ‘../order/order’ }) })}由于创建订单和更新订单的操作已经分别交由云函数和触发器处理了,为了更好的安全性,Order 表的数据创建权限和修改权限都不应该对客户端开放。需要额外说明的是,而触发器和云函数系统级别的操作,相当于拥有最高权限,所以我们这里相当于禁止了客户端中除了读取数据外的所有操作,也就使得 Order 表的权限控制和数据的准确性得到了安全的保障。五、云函数创建订单,云函数校验并更新订单状态我们再来研究一下代码,在 pay 这个方法中 wx.BaaS.pay(params) 所做的事情实际上是发起一个请求,获取 BaaS 系统返回的支付解密数据,然后使用这些支付解密数据调用微信客户端的支付功能,最终由用户输入密码完成支付。同理,根据客户端提供的数据都不可信的原则,这个请求中 params 参数时的数据同样可以被伪造,比如修改掉 totalCost 的值,也会导致最终支付的金额跟实际应该支付的金额不一值,根据之前触发器的设定,虽然会如实地记录了最终支付的金额,可以为后台追溯金额异常的订单提供依据,但是并不会阻止订单更新为已支付的状态。当用户支付成功后,我们更希望在更新订单状态前可以先进行支付数据的校验,校验不通过则不更新订单状态。想要实现这个功能,则要将触发器和云函数进行搭配使用了。先将触发器的动作类型改为云函数:微信支付成功后会触发调用 verifyPayment 云函数:客户端的代码保持不变,此时整个流程是:调用 createOrder 云函数创建订单,拿到创建订单成功的回调数据后,发起支付,支付成功之后,由触发器自动调用 verifyPayment 云函数,校验实付金额是否跟该商品的价格一致,若一致则更新该订单为已支付状态。在 verifyPayment 云函数中只考虑了校验实付金额这一个维度,在实际开发中应综合考虑更多维度来确保数据准确,在此不再展开讨论。至此,本文完成了一个小程序在线支付的案例,介绍了如何借助 BaaS 平台最快地实现小程序在线支付功能,通过开发过程中发现的各种安全问题,迭代出四种不同的实现方案,一步步完善支付功能的安全性,最后得出一个最快最安全实现小程序在线支付的方案。六、商品详情页和云函数 js 代码商品详情页 js 代码/* 商品详情页 js 代码 /const productTableId = 12345678const orderTableId = 123456789Page({ data: { product: {} }, onLoad(options) { // 设置默认的商品 id,方便调试 const productId = options.id || ‘5ade97135acfb521865bf766’ this.getProductDetail(productId) }, / * 获取商品详情信息 * @param {String} id / getProductDetail(id) { const tableObject = new wx.BaaS.TableObject(productTableId) const query = new wx.BaaS.Query() query.compare(‘id’, ‘=’, id) tableObject.setQuery(query).find().then(res => { const objects = res.data.objects || [] const product = objects[0] || {} this.setData({ product }) }) }, /* * 点击立即购买按钮事件 / createOrder(e) { wx.getSetting({ success: res => { if (res.authSetting[‘scope.userInfo’]) { this.createOrderHandle() } else { wx.BaaS.login() } } }) }, /* * 创建订单处理函数 / createOrderHandle() { const tableObject = new wx.BaaS.TableObject(orderTableId) const createObject = tableObject.create() const product = this.data.product const data = { product_id: product.id, product_snapshot: product, total_cost: product.price, status: ’no_paid’, } // 客户端创建订单,客户端更新订单状态 // return createObject.set(data).save().then(res => { // this.order = res.data || {} // return this.pay(this.order) // }).then(transactionNo => { // return this.updateOrder(transactionNo) // }).then(res => { // wx.navigateTo({ url: ‘../order/order’ }) // }) // 客户端创建订单,触发器更新订单状态 // return createObject.set(data).save().then(res => { // this.order = res.data || {} // return this.pay(this.order) // }).then(res => { // wx.navigateTo({ url: ‘../order/order’ }) // }) // 使用云函数创建订单,触发器或云函数更新订单状态 wx.BaaS.invokeFunction(‘createOrder’, { product_id: this.data.product.id }).then(res => { this.order = res.data || {} return this.pay(this.order) }).then(res => { wx.navigateTo({ url: ‘../order/order’ }) }) }, /* * 发起微信支付 * @param {Object} order / pay(order) { const product = this.data.product const params = { totalCost: order.total_cost, merchandiseDescription: product.title, merchandiseSchemaID: orderTableId, merchandiseRecordID: order.id, merchandiseSnapshot: product, } return wx.BaaS.pay(params).then(res => { return res.transaction_no }) }, /* * 更新订单状态 * @param {String} transaction_no 支付成功后返回的微信支付订单号 / updateOrder(transaction_no) { const tableObject = new wx.BaaS.TableObject(orderTableId) const recordId = this.order.id const record = tableObject.getWithoutData(recordId) record.set(‘status’, ‘paid’) record.set(’transaction_no’, transaction_no) return record.update() }})创建订单云函数/* 创建订单云函数 /const productTableId = 12345678const orderTableId = 123456789exports.main = function createOrder(event, callback) { const {product_id} = event.data const user_id = event.request.user.id getProductDetail(product_id).then(product => { return createOrderHandel(product, user_id) }).then(res => { const order = res.data || {} callback(null, order) }).catch(err => { callback(err) })}function getProductDetail(id) { const tableObject = new BaaS.TableObject(productTableId) const query = new BaaS.Query() query.compare(‘id’, ‘=’, id) return tableObject.setQuery(query).find().then(res => { const objects = res.data.objects || [] const product = objects[0] || {} return product })}function createOrderHandel(product, user_id) { const tableObject = new BaaS.TableObject(orderTableId) const createObject = tableObject.create() const data = { product_id: product.id, product_snapshot: product, total_cost: product.price, status: ’no_paid’, created_by: user_id } return createObject.set(data).save()}校验并更新订单状态云函数/ 校验并更新订单状态云函数 **/const productTableId = 12345678const orderTableId = 123456789exports.main = function verifyPayment(event, callback) { const data = event.data const totalCost = data.total_cost const orderId = data.merchandise_record_id const transactionNo = data.transaction_no const merchandiseSnapshot = data.merchandise_snapshot const productId = merchandiseSnapshot.id getProductDetail(productId).then(product => { if (product.price === totalCost) { updateOrder(orderId, transactionNo) } })}function getProductDetail(id) { const tableObject = new BaaS.TableObject(productTableId) const query = new BaaS.Query() query.compare(‘id’, ‘=’, id) return tableObject.setQuery(query).find().then(res => { const objects = res.data.objects || [] const product = objects[0] || {} return product })}function updateOrder(orderId, transaction_no) { const tableObject = new BaaS.TableObject(orderTableId) const recordId = orderId const record = tableObject.getWithoutData(recordId) record.set(‘status’, ‘paid’) record.set(’transaction_no’, transaction_no) return record.update()}知晓云是国内首家专注于小程序开发的后端云服务。使用知晓云,小程序开发快人一步。 ...

March 25, 2019 · 4 min · jiezi

热点账户问题和常用解决方案【上】

热点账户问题由来已久,一直是账户系统设计中的一个难点和瓶颈!小拽将通过上中下三篇文章,分别介绍下热点账户的产生,解决方案和延伸应用!本篇主要介绍下什么是热点账户?通用财务账户系统如何设计?以及其中的幂等健和链式设计等一、热点账户问题1.1 什么是热点账户热点账户:顾名思义,热点账户就是会被高频操作的账户!相较于普通的账户,热点账户数量不多,但操作频率极高!热点账户从产生来源可分两大类:富二代型:从产生之初就是热点账户,非常稳定。例如财务中公司的账户,每一笔资金操作都要经过公司出金账户,自然而然操作就会灰常频繁,此类账户还包括:大V账户,大KA账户等等,此类账户所引起的问题是本文重点要解决的暴发户型:本身是普通账户,由于热点问题变为热点帐户。例如微博出轨女猪脚账户,诺贝尔奖获得者等等,由于热点事件造成的短时间内访问暴增!此类热点账户防不胜防,超出本文的攻击范围,暂不讨论。1.2 热点账户问题热点账户一旦产生便伴随着高并发,流量分布不均匀,高一致性等等问题。在实际场景中是热点账户必然存在,常常成为用户系统的瓶颈!同时,热点账户问题也是高并发问题的延展,由于热点的不规则性,如何在高并发情况下,削峰填谷,弹性抗压也是很有挑战性的一个方向!1.3 热点账户通用解决方案的价值热点账户除了是账户体系的一个通用问题,在高并发,流量分布不均匀,异常峰值等其他问题上,也有一定的通用性。例如微博热点问题,支付宝双11弹性变更,高频抢购问题等等。期望通过学习热点账户的八种解决方案,能够举一反三,应用于不同场景!二、如何设计一个财务账户在解决热点账户问题之前,先来看下如何设计一个简单的财务账户,来保障资金记账的安全!2.1 业务场景分析从业务上看,财务账户需要准确记录用户的资金变动过程和结果!因此设计一个简单财务账户至少要能包括两个部分:账户余额和账户流水便于理解,来张传统的账本,看下什么是流水,什么是余额账户流水:账户流水也就是通俗意义上的帐或者账单!针对某个账户,每一笔资金的变更都需要记录下来,并且保障准确,不可更改!同时如图所示,流水中需要包含单据产生的原因,来源,变更额等等账户余额:账户余额记录用户某个场景账户的当前资金额度!在复杂的业务场景中往往需要拆分出不同的子账户和账户模型。例如,未结算子账户,可提现子账户,冻结子账户,授信账户等等。从业务场景上一个账户系统核心需要准确记录余额和流水,同时,必须保障记录的准确,完备,不可变更!2.2 技术层面拆解2.2.1 基本表方案通过业务场景初步分析,基本的账户系统,需要三张基本表账户基本信息:账户信息表子账户余额信息:账户余额表账户流水信息:账户流水表三张表基本关系账户信息表 1:N 账户余额表账户余额表 1:N 账户流水表## 具体账户和用户的关联可以参考三户模型 2.2.2 表字段设计从技术层面看,设计具体表细节关键要解决以下几个问题防重:幂等健设计防改:链式设计防错:销账设计先上结果,简单的,能够满足上述需求的设计可以参考innodb mvcc,核心表字段如下2.2.3 表字段解读2.2.3.1 幂等健设计通过三个属性资金凭证号+版本号+rollback三个字段作为uniq key来保证幂等!资金凭证号:来自业务方,业务方发起资金操作的唯一财务凭证,必须可追溯上游凭证和对账!版本号:每次获取DB最新流水n后,版本号n+1插入,保障在并发情况下,每个子账户只有唯一一个版本号:n+1条记录能够插入成功!rollback:回滚标识,保证每条记录能且只能销账一次!对于幂等建设计此处有三条小技巧上游产生:每一个幂等健如果可能的话,尽可能的上游产生,这样可以最大限度的避免自产生幂等健的重复问题。如果确实不能上游产生,例如订单ID,提现单ID,那么也尽可能的分阶段产生,例如提现时,先生成提现单ID,真正提现操作的时候,一定是带着提现单ID和信息来的,防止重复造成资损!业务关联:幂等健的产生可以用ice生成,但是,最好能够和业务关联,因为通过业务强关联的幂等健可以无限回溯来容灾!比如,a用户的b订单进行c操作,uniq_key = a_b_c的话,也就是在任何情况下,无论多少次回溯,重试也只会有一个唯一的a_b_c,而ice生成则可能造成自回溯的时候插入多条!写库保证:这条原则是高一致高并发的基本原则!因为读取a,校验a,然后插入,必然会存在读写之间a变了,或者主从延时a已经变了,读了历史a。因此,幂等一定要通过写库保证或者最底层保证2.2.3.2 链式设计链式设计是保证操作精准不可篡改的非常有效手段!通过资金的before info,after info,版本号三个要素来保证一条资金记录一旦插入成功,前后置信息固化!链式设计的情况下单条修改是不可能的,多条修改需要在保证条目不变的情况下重组资金,但是,整体资金不可变解决多条修改的一般方案:分布式存储,选举来判定最终正确的链,来确认是否某条链发生了过程修改,这种设计有一个很时髦的名字:区块链!而每条流水的核心信息加密后也有了一个更加时髦的名字:比特币!2.2.3.3 销账设计销账设计在账户系统中是一直存在的,现实财务系统可以红销蓝抵,线上财务系统加了链式之后,基本上就只能采用蓝抵通过增加rollback字段,并且严格限制0|1,保证一条账务流水只能被抵销一次!具体三张表详细字段,需要脱敏,就不贴了,参考上面,其中索引,字段大小,联合索引等设计根据自身业务场景兼容即可!小结:欲知后事如何,且听下回分解本部分简单介绍了什么是热点账户和账户的基本设计,涵盖幂等健设计,链式设计等等!下一篇重点分析下热点账户在链式设计下的问题,产生原因和八种基本解决方案【转载请注明:热点账户问题和常用解决方案【上】 | 公众号:靠谱崔小拽 |】

February 13, 2019 · 1 min · jiezi

简介:CII最佳实践徽章 - CNCF毕业标准要求之一

从沙箱或孵化状态毕业,或者作为一个新项目加入作为一个毕业项目,项目必须符合孵化阶段标准以及:有来自至少两个机构的提交者。已经实现并维护了核心基础结构计划(CII)的最佳实践徽章。采用CNCF行为准则。明确定义项目治理和提交者流程。这最好在GOVERNANCE.md文件中进行,并引用OWNERS.md文件显示当前和荣誉提交者。至少在主要仓库提供项目采用者的公开列表(例如,ADOPTERS.md文件或项目网站上的徽标)。获得TOC的绝对多数选票进入毕业阶段。如果项目能够表现出足够的成熟度,项目可以尝试直接从沙箱移动到毕业。项目可以无限期地保持在孵化状态,但通常预计在两年内毕业。这里介绍一下其中的核心基础结构计划(CII)的最佳实践徽章。CII最佳实践徽章计划Linux基金会(LF)的核心基础设施计划(Core Infrastructure Initiative,CII)最佳实践徽章是Free/Libre和开源软件(FLOSS)项目用于表明它们遵循最佳实践的一种方式。项目可以自愿进行自我认证,通过使用此Web应用程序来解释他们如何遵循每种最佳实践。CII最佳实践徽章的灵感来自GitHub项目众多可获得的徽章系统。徽章的使用者可以快速评估哪些FLOSS项目遵循最佳实践,因而更有可能生成更高质量的安全软件。最佳实践标准“合格”(“passing”)级别摘要这是合格标准的摘要,有关详细信息,请参阅完整的标准列表:有一个稳定的网站,说名:它做什么如何获得如何提供反馈如何贡献和首选风格明确指定FLOSS许可证项目网站支持HTTPS文档记录如何安装和运行(安全地)以及任何API有分布式公共版本控制系统,包括版本之间的变化:使用语义版本控制格式为每个发布提供唯一版本提供每个发布的更改摘要,识别任何已修复的漏洞允许提交、存档和跟踪错误报告:确认/响应错误和增强请求,而不是忽略它们有安全的、记录在案的流程来报告漏洞在14天内回复,并在60天内修复漏洞,如果漏洞是公开的使用标准的开源工具作有效的构建启用(并修复)编译器警告和类似lint的检查执行其他静态分析工具并修复可被攻击利用的问题拥有涵盖大部分代码/功能的自动化测试套件,并正式要求对新代码进行新的测试自动运行所有更改的测试,并应用动态检查:执行内存/行为分析工具(sanitizers/Valgrind等)执行模糊测试器(fuzzer)或Web扫描程序有开发者了解安全软件和常见漏洞错误如果使用加密:使用公共协议/算法不要重新实现标准功能使用开源加密技术使用保持安全的密钥长度不要使用已知损坏或已知弱算法使用具有前向保密性的算法使用密钥拉伸算法,使用迭代、加盐和哈希值存储任何密码使用加密随机数源Kubernetes的最佳实践徽章https://bestpractices.coreinf…Prometheus的最佳实践徽章https://bestpractices.coreinf…Envoy的最佳实践徽章https://bestpractices.coreinf…2019年KubeCon + CloudNativeCon中国论坛提案征集(CFP)现已开放KubeCon + CloudNativeCon 论坛让用户、开发人员、从业人员汇聚一堂,面对面进行交流合作。与会人员有 Kubernetes、Prometheus 及其他云原生计算基金会 (CNCF) 主办项目的领导,和我们一同探讨云原生生态系统发展方向。2019年中国开源峰会提案征集(CFP)现已开放在中国开源峰会上,与会者将共同合作及共享信息,了解最新和最有趣的开源技术,包括 Linux、容器、云技术、网络、微服务等;并获得如何在开源社区中导向和引领的信息。大会日期:提案征集截止日期:太平洋标准时间 2 月 15 日,星期五,晚上 11:59提案征集通知日期:2019 年 4 月 1 日会议日程通告日期:2019 年 4 月 3 日幻灯片提交截止日期:6 月 17 日,星期一会议活动举办日期:2019 年 6 月 24 至 26 日2019年KubeCon + CloudNativeCon + Open Source Summit China赞助方案出炉啦

January 24, 2019 · 1 min · jiezi

制定通用的标准:评估 PoW 共识协议的安全性

Nervos 研究员张韧博士在 Master Workshop 中发表了题为「Lay Down the Common Metrics:Evaluating Proof-of-Work Consensus Protocols’Security」的主题演讲,该主题演讲本身是关于多个共识协议。基于可行性的考虑,张韧博士选取了 6 个共识协议在此做讲解。在 Nakamoto 共识协议(Nakamoto Consensus 图片中简称 NC)中,为解决分叉问题,矿工们被要求在可能的情况下选择最长的链;在没有最长链时,矿工选择第一个接收到的区块加入到主链中。在发放奖励方面,主链区块会获得全部奖励,而孤块什么也得不到。这样是否足够安全?Nakamoto 共识的原始分析倾向于认为区块链本身具备完美的链质量,即低于全网 50% 算力的攻击者是无法修改区块链的。然而实际上攻击者完全可以有非常高的成功率去修改区块链。有三种攻击方式会修改区块链:自私挖矿(Selfish Mining)、双花(Double Spending)和审查攻击(Censorship Attack)。其中,自私挖矿的攻击者可以获得与其算力不成正比的、不公平的区块奖励。他们可以将挖矿算力集中起来去获得更高的相对区块奖励,从而破坏区块链的去中心化特性;在双花攻击中,攻击者可以逆转已确认的交易,将自己利益最大化;审查攻击情况下,攻击者阻止交易被确认,造成诚实矿工的经济损失。三种攻击自私挖矿红色方块表示块被传播到网络的时间,然后橙色圆圈表示攻击者的区块,三角形表示被诚实矿工挖出的区块。攻击者很幸运地找到了第一个区块,但没有将其发布到网络上,而是选择了扣留这个区块。当诚实矿工找到一个块时,攻击者会在这时候抢在诚实矿工之前广播之前扣留的区块,则之后所有的矿工都将在攻击者的区块而不是诚实矿工的区块上挖矿。如果攻击者足够幸运,能够连续找到多个区块,那么攻击者就可以毫无风险地孤立一个诚实区块。在这种情况下,攻击者的的链变得更长,并且全网的算力会到它的链上挖矿。通过这种方式,攻击者成功地增加了在整体区块奖励中获得的相对比例。双花攻击双花攻击与自私挖矿攻击非常相似,是通过秘密挖矿来获得额外奖励。如比特币中,按照惯例有 6 个区块确认交易后基本是完全确认了。如果攻击者秘密地扣留了 6 个区块,并一次性将它们广播到网络中,他就能够在收到商品或者服务之后逆转这个交易。审查攻击审查攻击试图孤立所有不符合审查要求的块,即我要广播我要审查的这些交易,如果你不听从我的命令,我会尽力孤立你的块。两种解决方法下面我们来说说解决 Nakamoto 共识安全问题的两种方法。第一大类我们称之为「更佳链质量」协议。如图所示这一大类中有很多协议,这些协议声称它们可以提高链的质量。这次我将重点介绍「最小哈希平局打破协议(Smallest hash tie-breaking protocol ,简称 SHTB)」 和 「不可预测的确定性平局打破协议(Unpredictable deterministic tie-breaking,简称 UDTB)」。第二大类称为「抗攻击」(Attack-resistant protocols)协议。这些协议声称,他们可以在链的质量并不完美的情况下抵御攻击,因此他们不需要提高链的质量。抗攻击协议的三种类型第一种是「全部奖励」(Reward-all)协议。这类协议给大多数最近做了工作量证明的以奖励, 符合要求的块无论如何都会获得奖励,如此攻击者无法进行自私挖矿攻击来迫使诚实矿工的奖励无效,从而攻击者没有动机进行自私挖矿攻击。 第二个被称为「惩罚」(Punishment)协议。这些协议将没收那些可疑的区块的奖励。惩罚规则希望通过损失厌恶, 让所有人不得不遵守协议。 第三个被称为「幸运奖励」(Reward-lucky)协议。这些协议根据区块内容对某些幸运区块进行奖励,希望这些幸运区块作为稳定网络的「锚点」。 接下来让我们更深入地了解这些协议。 首先我们分析 「更佳链质量」这一类协议,首先是「最小哈希平局打破协议」。在这个协议中,每当有平局时,协议都要求所有矿工选择哈希最小的块,不管它首先接收的是谁。 第二个称为「不可预测的确定性平局打破协议」。该协议规定,每当有平局时,每个人都使用不可预知的确定性伪随机函数来计算所有参与竞争链的顺序,而不管首先接收哪一个块。不可预测的确定性协议背后的原理是,由于攻击者无法预测他是否会以超过 50% 的几率赢得整块竞争,进行自私挖矿攻击是不明智的(因此不会选择这么做)。对于抗攻击协议,我会从每种技术方法中选择一种协议来分析。对于「全部奖励」协议我们来分析水果链。在水果链中,对两种不同的产品使用了相同的挖矿程序。如果一个候选区块的哈希值最前面的 k bits 小于某个阈值,那么就判断它是一个块;如果某个候选区块的哈希值最后的 k bits 小于某个阈值,那么就判断它是水果。因此,当你运行哈希算法时,你可能会得到一个区块,也可能是得到一个水果。该协议和 Nakamoto 共识一样,遵循最长链原则,并且根据最先收到的区块打破平局。对于所有抵抗攻击协议,我们使用 Nakamoto 共识作为其分叉解决的规则。因此,当我们分析他们的攻击抗性时,他们被置于同一规则下。水果是嵌入在区块中的。你可以把水果想象成 Nakamoto 共识中的交易,这个交易只是被嵌入到了水果中。每个水果都有一个指针块,这是一个最近的块,水果矿工不会被孤立 。图中香蕉块的指针就是这样一个案例,如果指针块在主链中,则水果是有效的。如果指针块是孤块,就像图上的番茄一样,那么这个水果不再是有效的水果。还有一个额外的规则,即水果出块的间隔需要小于预定义的超时阈值。间隔定义为主区块和指针区块之间的区块高度差。比如,香蕉的间隔就是 2,这是因为主区块比指针区块晚 2 个区块。因此有效水果获得全额奖励,而区块则没有获得任何奖励。对于惩罚协议,我们选择 DECOR 协议修改版本作为案例来讲解。在我们的修改版本中,我们将其称为「奖励分配」(Reward-Splitting ,简称 RS)协议,顾名思义,奖励在所有相同高度的竞争区块之间平分。这个协议允许一个区块引用之前的孤块为叔块,如果其间隔是低于超时阈值的,那么这个叔块就是有效的(也会获得一定的奖励)。这是在奖励分配协议中间隔的定义和水果链类似。不同在于,在此协议中,间隔被定义为主区块和叔块的高度差,而不是主区块和指针区块的高度差。所以我们不考虑区块的亲缘关系,只考虑该区块本身的高度。每个区块奖励在相同高度的竞争区块和叔块之间平均分配。例如,在这个图中,区块 B 和区块 C 分别得到了一半的区块奖励,区块 A 和区块 D 则获得全部的区块奖励。最后一个是子链。子链也是采用相同的挖矿程序,但是是两种不同的产品。子链中的出块规则和比特币相同,如果候选区块的哈希低于某个特定阈值,那判断这个块有效。如果候选区块的哈希值大于块阈值但小于另一个阈值,我们将其视为弱块(Weak Block)。弱块也计入链长度,也执行交易确认的功能。但是,弱块不会收到任何块奖励。只有区块能获得块奖励。衡量协议安全性的共同指标我非常激动,因为下面我们要一起设定一些衡量协议安全性的共同指标。你声称这是最安全的协议,你要向我证明它,就需要从这几个指标的维度来衡量你的协议有多安全。在这个研究中共有四个指标,我们来分析一下。第一个指标我们称之为链质量(Chain Quality),是指主链上诚实矿工的区块的最小百分比。在这个例子中,链质量是六分之三,因为主链中有六个区块,其中三个来自诚实矿工。第二个称之为激励相容度(Incentive Compatibility),用来衡量对自私挖矿攻击的抗性,被定义为诚实矿工区块奖励的最小百分比。在这种情况下,由于六个主链区块中有三个区块来自于诚实矿工,因此激励相容度是 50%。在 Nakamoto 共识中,这两个指标(指链质量和激励相容度)是相等的。但是,对于其他协议,这两个指标并不相同。链质量只是用来评估拜占庭敌手(也就是作恶节点),但激励相容度则把奖励也考虑在内。第三个指标是另一个攻击抗性的指标,称为「作恶收益」(Subversion Gain),衡量抗双花攻击的性能。它被定义为「平均每个出块间隔能够获得的区块奖励加上双花奖励的最大值」。在这种情况下,假设每隔 10 分钟能找到一个块,如果总共有 8 个块,那么总共需要 80 分钟(其中攻击者有 3 个块)。在这个例子里,平均每 10 分钟,攻击者获得 3/8 个区块奖励。双花奖励为 0,因为双花奖励需要连续孤立六个块。因为在抗双花攻击中没有完整的百分比奖励,因此指标设定为「平均每个出块间隔获得区块奖励的最大值」。在这张图上,没有双花攻击奖励,因为你需要连续出孤立至少 6 个区块才能获得双花奖励。最后一个指标称为「审查敏感性」(Censorship Susceptibility),即因为拒绝审查者的要求,导致诚实矿工的奖励损失的最大百分比。因为如果我拒绝审查请求,攻击者将开始孤立我的区块。此指标用来衡量我的区块可以被孤立的百分比。在这个案例中,有 5 个诚实的块,其中 2 个是孤块,所以审查敏感性是 2/5。评估结果现在我们来看看评估结果。在这次分享中我分析了 5 个协议,我们来看看第一个指标链质量。我们先定义一个变量 ,它是在平局情况下,在攻击者的链上挖矿的诚实矿工算力占所有诚实矿工算力的百分比。如果 等于零,那么所有诚实矿工的算力都会用在挖诚实矿工的链上,没有诚实矿工的算力在攻击者的链上挖矿。如果 等于1,则所有诚实矿工的算力将在攻击者链上挖矿,并且没有人会在诚实矿工的链上挖矿。这是是用来评估 Nakamoto 共识的通用参数。这里有五个情况,分别是在 = 0,0.5,1 情况下的 Nakamoto 共识、最小哈希平局打破协议(SHTB)和 不可预测的确定性平局打破协议(UDTB) ,哪一个是链质量最佳的?在这五个协议中,最小哈希平局打破协议(SHTB) 和 不可预测的确定性平局打破协议(UDTB) 仅关注如何打破平局。所以你并不能比 = 0 的平局的情况下的 Nakamoto 共识做的更好。因为当 = 0 的时候,所有的挖矿算力将会在诚实的链上。并且你不能比 = 1 的情况下的 Nakamoto 共识更差了,攻击者在这种情况下可以赢得所有的平局。所以在剩下的三个协议里(SHTB、UDTB、 = 0.5 的 Nakamoto 协议)哪一个是表现最差的?其实是最小哈希平局打破协议。那么对于剩下两个协议(UDTB、 = 0.5 的 Nakamoto 协议)哪一个更好呢?我来揭开这个答案。 = 0.5 的 Nakamoto 共识是更好的。为什么?举例来说,在不可预测的确定性平局打破协议(UDTB)中,当一个攻击者找到了一个区块,但是此时诚实的矿工打包了这个区块并且先于攻击者将它广播了出去,那么有可能这个攻击者会计算伪随机函数并意识到如果他发布了他的区块,是没有人会继续在他的区块之上挖矿的,因为他在出块竞争的平局中失败了。那么这个攻击者能够做什么?在 Nakamoto 共识中,攻击者注定会失败,因为最先收到的区块打破平局的规则,如果你不尽快把区块发布出去,没有人会在你的区块上面挖矿。但是在 UDTB 中则不同,即使下一个区块都被挖出来了,攻击者还是能够在这个区块之上继续挖矿,只要攻击者能够赢得下一个出块权,那么成功之后这个攻击者就能够在诚实矿工的区块之后同时发布两个区块。如果这个伪随机函数表明攻击者赢得了出块竞赛,攻击者就能拿到出块奖励。因为 UDTB 允许一个称为“后发制人“的特殊攻击行为,因此 UDTB 的安全性会比 = 0.5 的 Nakamoto 共识更差。那为什么最小哈希平局打破协议安全性那么差?因为当攻击者找到一个区块并且这个哈希值的确非常小的时候,攻击者会有大约 99% 的可能性,不论其他人的哈希是多少,他都能够赢得这个出块权。不论我先广播哪一个区块,我都能准确的预测出我能够赢得这个平局的可能性。这就允许攻击者在他足够幸运的时候能够发动扣块攻击。当诚实的矿工找到下一个区块的时候,因为攻击者区块的哈希是足够小的,他有很高的可能性能够赢得出块权,因此他能够发布区块并且获得这个出块权。下一次当攻击者没有这么幸运的时候,他拿到的区块的哈希相对来说比较大,攻击者能够发布这个区块并直接获得奖励。更佳链质量协议的一般性结论下面是我们研究更佳链质量协议的一些一般性结论。当攻击者所占算力 > 1/4 时,没有一个协议能够达到一个理想的区块链的质量。只要攻击者的算力超过了全网算力的 1/4,它的收益就能够比它按照算力份额计算的正常收益更高。只要攻击者的算力超过了全网算力的 1/4 ,它的收益就能够比它按照算力份额计算的正常收益更高。 对于任何一个 的值,在 = 0 的情况下,没有一个协议在安全性上表现比 Nakamoto 共识更好。可能对于某一特定情况,某个协议在安全性上会比 Nakamoto 共识更好,但是在整体上 Nakamoto 共识在安全性上是最好的。这是为什么?因为协议并不能区分诚实的区块和攻击者的区块。为什么协议不能区分这些区块?这是因为信息的不对称。攻击者是基于所有可得信息来行动的,也就是说他知道他发布了多少个区块,有多少个扣留的区块,我什么时候发布这些区块等等,攻击者是都知道的。然而诚实的矿工仅基于有限的公开信息来行动。这又是为什么?这是因为 PoW 的安全假设较弱。他们试图异步操作,规定所有的矿工只对非常有限的公开信息采取行动/进行操作。那么现在我们来针对 Nakamoto 共识、水果链、奖励分配(Reward-Splitting,RS)协议、和子链来分析一下他们攻击抗性,首先是激励相容性。 其中奖励分配协议(执行)表现最好,因为惩罚总是激励正确行为的最有效方式。子链表现最差。水果链表现有时比 Nakamoto 共识好,有时更糟。子链允许攻击者使用无价值的弱区块来使诚实的区块失效。如果所有东西都是有价值的,那么攻击者扣留区块则是有风险的。但是弱区块本身毫无价值,攻击者可以扣留这个弱区块,而不会有失去区块奖励的风险。既然无风险,那么为什么不尝试更大胆的扣留区块的行为?更多的弱区块,协议行为越糟糕。所以更多的弱区块实际上使事情变得更糟。最好的情况就是不去使用弱区块。当水果链的超时值小的时候,它的表现比 Nakamoto 共识差。攻击者可以使用无用的区块使他的水果失效。这也有类似的问题出现,因为区块在水果链中没有任何奖励,所以攻击者没有发布区块的动机,因为扣留区块也并无风险,结果是攻击者可以尝试更大胆的扣留区块行为。结果是攻击者可以尝试更大胆的持有行为。如果有更多的水果,那么情况会稍微好一点。有一个著名的 Newton-Pepys 问题,它是说一个概率问题,即A. 6 个正常的骰子独立投掷,至少出现 1 个 6B. 12 个正常的骰子独立投掷,至少出现 2 个 6如果你掷 6 次骰子,得到 1 个 6 的概率比你掷 12 次骰子得到 2 个 6 的概率要大。在水果链中有四种挖矿产品:诚实水果,诚实区块,攻击水果,攻击区块。我们可以将「攻击者比诚实矿工拥有 1 个超时区块」——即攻击者可以成功地孤立一些水果——看作是一个条件事件。此事件完全独立于水果生成(fruit generation),因为它仅考虑区块。我们可以把它作为 Newton-Pepy’s 问题中的条件去看待——因为它是独立的,所以我们可以直接把它扔掉。但当条件满足时,如果水果较少,则“攻击者有更多水果”的概率非常低。更多的水果意味着更多的攻击者水果。因为攻击者是少数派,如果水果的总数更多,这意味着攻击者的水果的总占比会比实际上多一些。这里用赌博来做类比更好理解,因为我们有更多的水果,这意味着当攻击者有更多的水果, 那么他就会更少参与赌博。 人们更愿意在没有什么可失去的情况下赌博, 但如果有更多的资本可能会失去, 他就不想赌, 这意味着更多的水果稍微有助于提高激励相容性。接下来在攻击抵抗性中我们分析攻击「作恶收益」,这个指标是越小越好的,如图所示,奖励分配协议优于 Nakamoto 共识,优于水果链,优于子链。我们分析了另一个有趣的衡量方法,称为「作恶赏金」。我们定义其为最低双花奖励,来研究激励偏差。(也就是说,在双花攻击的奖励大于作恶赏金时,攻击者才有动力作恶)。( 图中右下角的表格,分别是 Nakamoto 共识和奖励分配协议在区块确认数 3 或 6 , (攻击者算力占比在 0.1 ~ 0.4 的情况下,计算出来的作恶赏金)。通过计算各个协议的「作恶赏金」可以发现,基本上可以零成本破坏水果链和子链,甚至可以尝试无奖励双花,因为毫无风险。我们可以看到,随着交易确认次数的增加,对于一个弱攻击者,作恶赏金的增长几乎呈指数增长。这意味着更多的交易确认确实有助于抵抗双花,但是对于强攻击者来说效果就不那么明显了。对于抗审查能力, 我们计算所有的数字和排名如下:对于小 ,也就是攻击者算力占比较低的情况下, 水果链是最好的, 然后是 Nakamoto 共识, 再然后是奖励分配协议和子链。 对于大 ,也就是攻击者算力占比较高的情况下,奖励分配协议变成了最好的, 然后是水果链, Nakamoto 共识, 和子链。 显而易见的是,对于水果链来说, 如果你想使其他块无效, 要比其他协议要困难得多, 因为它们是在多个条件下获得奖励, 即使你是孤块也是如此。 为什么当 足够大的时候, 也就是攻击者算力占比较高的时候,奖励分配协议会比水果链更好呢?因为在水果链上, 间隔被定义为主区块和指针块之间的区块高度差。而在奖励分配协议中, 间隔被定义为主区块和区块本身之间的区块高度差。 因此在水果链中,若攻击者在长期的出块竞争中都获胜了,那么诚实的水果的奖励都会被拿走因为他们的指针块都被孤立了。也就是说如果你把他们的指针都孤立了,那么对他们来说就玩完了。然而在奖励分发协议中,最后的几个诚实的区块还是能够获得一些奖励。如果想要让诚实矿工失去所有奖励,将他们的指针孤立是不够的,你需要将大量连续的区块孤立起来才行。(这给攻击者增加了阻碍)。这些图片能够说明这些问题。在水果链中,如果你孤立了指针,那么你能够安心地获得所有的奖励。然而在奖励分配协议中,即使你在出块竞争中长期孤立了这些区块,但是这些区块还是会指向回主链。因为关键关系并没有考虑进去,这个区块仍会分走攻击者一半的出块奖励,这让它更能抵抗审查攻击。(因为就算被审查,诚实矿工还是能获得一部分奖励。)抵抗攻击协议的通用结论下面谈一下研究中对于抵抗攻击协议的一些通用结论。合理的设置更长的区块确认时间和更大的带宽会增加安全性。有一个两难困境,我们称为“奖励坏人,惩罚好人”的机制。这对于大家来有点颠覆对协议奖励的认知。因为在这里即使你分叉你仍然能够获得出块奖励,你分叉是没有风险的。所以这反而激励了攻击者去分叉和发动双花攻击。在惩罚性协议中,因为审查攻击者不在乎他们自己的出块奖励,你的惩罚规则反而给攻击者另一个工具,来让诚实的矿工放弃出块奖励。而对于幸运奖励协议,如果你不打破信息不对称,那么幸运并不意味着好。有时候幸运的块反而是坏的块,让事情变得更糟。结论就是,想要解决所有的攻击,我们需要在底层规则中超越奖励。(奖励规则并不能很好解决攻击的问题)具体怎么做?我提出一些想法和大家讨论一下。我们不应该设计一个太复杂、太难分析的协议。我们需要设计一个设计者能够分析的协议。简单就是好的,复杂是安全的敌人。仅针对单一攻击策略的安全性分析是很危险的。对于很多协议来说,它们的设计者经过模拟说他们的协议能够抵抗某种特定的攻击方式,但是这样的协议却启发了攻击者去研究其他的攻击策略。仅针对单一攻击动机的安全性分析也是很危险的。攻击者可能会着眼于短期利益,长期利益或者损害其他矿工的利益。为了抵抗某一种攻击,你就可能启发了攻击者基于另一个目标发动另一种形式的攻击。在你的模型中你需要考虑到所有不同动机的攻击者。 ...

January 23, 2019 · 2 min · jiezi

每个人都必须遵循的九项Kubernetes安全最佳实践

作者:StackRox产品经理Connor Gilbert上个月,Kubernetes(世界上最受欢迎的容器编排器)生态系统因发现Kubernetes的第一个主要安全漏洞而动摇。该漏洞(CVE-2018-1002105)使攻击者能够通过Kubernetes API服务器破坏集群,允许他们运行代码来安装恶意软件等恶意活动。今年早些时候,Tesla遭遇了复杂的加密货币挖掘恶意软件感染,由Kubernetes控制台错误配置引起。攻击者利用了特定Kubernetes控制台没有密码保护的事实,允许他们访问其中一个包含Tesla大型AWS环境访问凭据的pod。随着组织加速采用容器和容器编排器,他们需要采取必要措施来保护计算基础架构中的这一关键部分。为了帮助完成这项工作,请查看这九项根据客户意见的Kubernetes安全最佳实践,你应遵循以帮助保护你的基础架构。1.升级到最新版本每个季度更新都会添加新的安全功能,而不仅仅是错误修复,为了充分利用它们,我们建议你运行最新的稳定版本。最好的办法是使用最新版本运行最新补丁,特别是考虑到CVE-2018-1002105的发现。越是落后升级和支持可能会越难,所以计划每季度至少升级一次。使用托管的Kubernetes供应商可以非常轻松地进行升级。2.启用基于角色的访问控制(RBAC)基于角色的访问控制(RBAC)控制谁可以访问Kubernetes API以及他们的权限。默认情况下,RBAC通常在Kubernetes 1.6及更高版本中启用(某些托管供应商稍迟),但如果你从那时起进行了升级并且未更改配置,则需要仔细检查你的设置。由于Kubernetes授权控制器的组合方式,你必须同时启用RBAC,并禁用传统的基于属性的访问控制(ABAC)。一旦实施了RBAC,你仍然需要有效地使用它。通常应避免使用集群范围的权限,而使用特定于命名空间的权限。避免给予任何集群管理员权限,即使是为了调试,仅在需要的情况下,根据具体情况授予访问权限会更安全。你可以使用kubectl get clusterrolebinding或kubectl get rolebinding -all-namespaces来探索集群角色和角色。 快速检查谁被授予特殊的“cluster-admin”角色,在这个例子中,它只是“masters”群:如果你的应用程序需要访问Kubernetes API,请单独创建服务帐户,并为每个使用站点提供所需的最小权限集。这比为命名空间的默认帐户授予过宽的权限要好。大多数应用程序根本不需要访问API,对于这些可以将automountServiceAccountToken设置为“false”。3.使用命名空间建立安全边界创建单独的命名空间是组件之间重要的第一级隔离。当不同类型的工作负载部署在不同的命名空间中时,我们发现应用安全控制(如网络策略)要容易得多。你的团队是否有效地使用命名空间?通过检查任何非默认命名空间来立即查找:4.隔离敏感的工作负载为了限制受损的潜在影响,最好在一组专用计算机上运行敏感的工作负载。此方法降低了通过共享容器运行时(runtime)或主机,安全性较低的应用程序访问敏感应用程序的风险。例如,受损节点的kubelet凭证,通常只有在机密内容安装到该节点上安排的pod中时,才能访问机密内容。如果重要机密被安排到整个集群中的许多节点上,则攻击者将有更多机会窃取它们。你可以使用节点池(在云或本地)和Kubernetes命名空间、污点(taint)、容差和其他控件来实现隔离。5.保障云元数据访问安全敏感元数据(例如kubelet管理员凭据)有时会被盗或被滥用以升级集群中的权限。例如,最近的Shopify错误赏金(bug bounty)披露,详细说明了用户如何通过混淆微服务,泄漏云供应商的元数据服务信息来升级权限。GKE的元数据隐藏功能会更改集群部署机制以避免此暴露,我们建议使用它直到有永久解决方案。在其他环境中可能需要类似的对策。6.创建和定义集群网络策略网络策略允许你控制进出容器化应用程序的网络访问。要使用它们,你需要确保拥有支持此资源的网络提供程序,对于一些托管的Kubernetes供应商,例如Google Kubernetes Engine(GKE),你需要选择启用。(如果你的集群已经存在,在GKE中启用网络策略将需要进行简短的滚动升级。)一旦到位,请从一些基本默认网络策略开始,例如默认阻止来自其他命名空间的流量。如果你在Google容器引擎中运行,可以检查集群是否在启用了策略支持的情况下运行:7.运行集群范围的Pod安全策略Pod安全策略设置在集群中允许运行工作负载的默认值。考虑定义策略,并启用Pod安全策略许可控制器,指令因云供应商或部署模型而异。首先,你可以要求部署删除NET_RAW功能,以抵御某些类型的网络欺骗攻击。8.加固节点安全你可以按照以下三个步骤来改进节点上的安全状态:确保主机安全且配置正确。其一方法是根据CIS基准检查你的配置。许多产品都有自动检查器,可以自动评估这些标准的符合性。控制对敏感端口的网络访问。确保你的网络阻止访问kubelet使用的端口,包括10250和10255。考虑除了可信网络以外限制对Kubernetes API服务器的访问。恶意用户滥用对这些端口的访问权限,在未配置为需要在kubelet API服务器上进行身份验证和授权的集群中运行加密货币挖掘。限制对Kubernetes节点的管理访问。通常应限制对集群中节点的访问。调试和其他任务通常可以在不直接访问节点的情况下处理。9.启用审核日志记录确保你已启用审核日志,并监视它们是否存在异常或不需要的API调用,尤其是任何授权失败,这些日志条目将显示状态消息“禁止(Forbidden)”。授权失败可能意味着攻击者试图滥用被盗的凭据。托管Kubernetes供应商(包括GKE),在其云控制台中提供此数据,并允许你设置授权失败警报。下一步遵循这些建议以获得更安全的Kubernetes集群。请记住,即使你按照这些提示安全地配置Kubernetes集群,你仍然需要在容器配置的其他方面及其运行时操作中构建安全性。在提高技术堆栈的安全性时,寻找能够为容器部署提供中心治理点的工具,并为容器和云原生应用程序提供持续监控和保护。2019年KubeCon + CloudNativeCon中国论坛提案征集(CFP)现已开放KubeCon + CloudNativeCon 论坛让用户、开发人员、从业人员汇聚一堂,面对面进行交流合作。与会人员有 Kubernetes、Prometheus 及其他云原生计算基金会 (CNCF) 主办项目的领导,和我们一同探讨云原生生态系统发展方向。2019年中国开源峰会提案征集(CFP)现已开放在中国开源峰会上,与会者将共同合作及共享信息,了解最新和最有趣的开源技术,包括 Linux、容器、云技术、网络、微服务等;并获得如何在开源社区中导向和引领的信息。大会日期:提案征集截止日期:太平洋标准时间 2 月 15 日,星期五,晚上 11:59提案征集通知日期:2019 年 4 月 1 日会议日程通告日期:2019 年 4 月 3 日幻灯片提交截止日期:6 月 17 日,星期一会议活动举办日期:2019 年 6 月 24 至 26 日

January 15, 2019 · 1 min · jiezi

以太坊开发时如何保证DApp本地存储localStorage的安全性?

部署去中心化应用程序dapp会引入一些有趣的安全性考虑因素,这些因素可能不会出现在更传统的开发中。我们如何保证dApp本地存储的安全性?提出这个问题的原因是我们在使用Colony dApp时遇到的一个重要障碍,那就是如何应对在使用IPFS或Swarm等分布式存储系统保持本地存储的dApp数据安全挑战。在本文中,我将从dApp开发人员的角度来看一下这个问题,然后研究一些可能的解决方案。共享本地存储localStorage的问题IPFS运行本地节点node,它与Web服务器捆绑在一起。捆绑的Web服务器使节点可以轻松地相互连接并共享网络中其他位置可能需要的数据。作为一个去中心化的应用程序构建器,你将依赖该Web服务器将你的内容从一个节点推送到另一个节点,从而使其可以根据需要立即供最终用户使用。假设你正在完全去中心化full decentralized并且正在避免使用DNS或Web代理等任何内容来跟踪你的内容在网络上的位置,那么访问dApp的方式通常是通过浏览器使用其查询本地节点哈希,如:http://localhost:8080/QmcefGgoVLMEPyVKZU48XB91T3zmtpLowbMK6TBM1q4Dw/现在,假设在正常使用期间,你的应用程序将在浏览器的localStorage保存数据:可能需要传递一些数据,或者保持本地用户交互的队列,以最大限度地减少链上交易并节省gas成本。浏览器中的本地存储仅限于特定的地址上下文(域和端口)。IPFS节点是获取此上下文的,这意味着通过IPFS Web服务器运行的任何去中心化应用程序将使用具有读写访问权限的相同localStorage。这可能是一个大问题。默认情况下,dApp的某些helper依赖项使用localStorage临时将密钥保存在纯文本中。这些数据不应该被看到的一天。另一个潜在的泄漏问题是保存其内存状态的软件包,以便以后可以恢复。类似Flux-like的库通常(相对)安全,因为它们只在内存中运行,但启用持久性状态会将该内存状态放入localStorage,从而将其打开给潜在的攻击者。缓解问题的策略不幸的是,安全没有灵丹妙药:作为一名dApp开发人员,为安全起见所做的任何调整都可能需要在开发的其他方面做出一些让步。以下是你可以做出的一些妥协:不存储任何数据这当然是最安全的方法,但它有点像烧毁你的房子来摆脱蟑螂。在本地存储数据的dApp中有许多功能和基本行为,删除太多后可能没有应用程序存在的意义了。此外,有许多库默认使用localStorage,你必须手动检查每个依赖项并删除任何需要它的库,否则就得自己修改库。加密一切这在理论上更有前途,特别是因为大多数dApp开发人员已经在看板上保持默认加密。加密的local storage值实际上,加密所有本地存储有点麻烦。要加密数据,必须有一个密钥:但是用户不能将该密钥存储在dApp中,因为它将被放在localStorage,这样做你就将回到原点。一种解决方案是使用钱包:你的dApp可能会以某种方式与区块链进行交互,要求用户解锁其钱包以发送和签署交易。由于无论如何都需要钱包与dApp交互,因此可以使用每个帐户的私钥privatekey来加密本地存储。然而,这也有一些缺点:每次想要与localStorage交互时,您都必须询问用户的纯文本私钥。像MetaMask这样的密钥管理软件不起作用,因为它永远不会暴露用户的私钥。使用Swarm和MistMist是作为dApp和以太坊浏览器构建的,因此它为该问题提供了一些特殊优势。默认情况下,Mist支持Swarm的bzz协议,因此你可以设置一个ens地址指向dApp的哈希值,然后使用Mist无需担心地浏览你的dApp。不幸的是,这只会解决通过Mist访问dApp的用户的问题。运行本地Swarm节点的用户仍然必须通过localhost访问,localhost仍然(可能)将数据泄露给其他dApp。为你的dApp创建一个浏览器扩展通过浏览器扩展程序运行你的应用程序将导致它获得单独的上下文(它将不再在localhost:8080),但它有点减弱了去中心化应用程序的目的,必须要依赖于像Chrome网络商店这样的中央权威机构用于管理和分配。此外,现在你必须为要支持的每个浏览器创建和维护单独的扩展,并通过其自己的特定集中式应用商店进行更新。不爽。创建一个独立的桌面应用程序和以前一样,创建独立应用程序是将dApp分离到自己的上下文的一种方式,这意味着它将获得自己的包装器(在本例中为electron)。独立的桌面应用程序具有额外的好处,可以捆绑外部库和你可能需要的任何其他内容,包括IPFS本身的单独实例。和以前说的一样,要有一些让步:除非你想要专门在bittorrent上分发应用程序,否则你需要找到一个集中托管的解决方案来进行分发和维护。你必须为electron桌面应用程序维护一个单独的存储库。如果你想将IPFS用于任何其他服务,你可能最终会在同一台计算机上运行多个节点,这可能会变得混乱。将你的应用代理到域名通过使用其他Web服务器代理本地节点,有两个优点:首先,现在你的dApp有一个友好的友好的人类可读地址,而不是一个冗长的哈希。其次,你的应用程序将拥有自己的上下文,并且不会共享localStorage。然而,代理确实跨越了“真正的”去中心化,用户将再次不得不依靠中央服务器来访问去中心化的服务。哎。对于去中心化的应用程序开发人员来说,现在还处于早期阶段。这种问题在新兴的“去中心化协议栈”中无处不在“:而且在我们提出更优雅的解决方案之前可能还需要一段时间。将来,在浏览器中支持本机IPFS或Swarm节点可以解决这个问题,并且无需将Web服务器与去中心化的文件存储捆绑在一起。用户可以输入类似ipfs://QmcefGgoVLMEPyVKZU48XB91T3zmtpLowbMK6TBM1q4Dw/并直接访问dApp,并为每个唯一的哈希分配自己的上下文。Mist和IPFS团队意识到了这个问题,并希望将未来版本中的解决方案纳入其中。但是现在,找到我们可以采用的解决方法并与社区的其他人分享它们会很有帮助。如果你是一名开发自己的去中心化应用程序dapp的开发人员,希望本文对没构建代码以避免数据泄漏有所帮助,如果你设计了另一个上面未提及的解决方案,请分享它!感谢Alex Rea和Griffin Hotchkiss帮助起草本文。======================================================================分享一些以太坊、EOS、比特币等区块链相关的交互式在线编程实战教程:java以太坊开发教程,主要是针对java和android程序员进行区块链以太坊开发的web3j详解。python以太坊,主要是针对python工程师使用web3.py进行区块链以太坊开发的详解。php以太坊,主要是介绍使用php进行智能合约开发交互,进行账号创建、交易、转账、代币开发以及过滤器和交易等内容。以太坊入门教程,主要介绍智能合约与dapp应用开发,适合入门。以太坊开发进阶教程,主要是介绍使用node.js、mongodb、区块链、ipfs实现去中心化电商DApp实战,适合进阶。C#以太坊,主要讲解如何使用C#开发基于.Net的以太坊应用,包括账户管理、状态与交易、智能合约开发与交互、过滤器和交易等。EOS教程,本课程帮助你快速入门EOS区块链去中心化应用的开发,内容涵盖EOS工具链、账户与钱包、发行代币、智能合约开发与部署、使用代码与智能合约交互等核心知识点,最后综合运用各知识点完成一个便签DApp的开发。java比特币开发教程,本课程面向初学者,内容即涵盖比特币的核心概念,例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等,同时也详细讲解如何在Java代码中集成比特币支持功能,例如创建地址、管理钱包、构造裸交易等,是Java工程师不可多得的比特币开发学习课程。php比特币开发教程,本课程面向初学者,内容即涵盖比特币的核心概念,例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等,同时也详细讲解如何在Php代码中集成比特币支持功能,例如创建地址、管理钱包、构造裸交易等,是Php工程师不可多得的比特币开发学习课程。tendermint区块链开发详解,本课程适合希望使用tendermint进行区块链开发的工程师,课程内容即包括tendermint应用开发模型中的核心概念,例如ABCI接口、默克尔树、多版本状态库等,也包括代币发行等丰富的实操代码,是go语言工程师快速入门区块链开发的最佳选择。汇智网原创翻译,转载请标明出处。这里是原文

December 18, 2018 · 1 min · jiezi