Mour
Mour
其实微服务架构相较传统架构而言的安全治理区别并非那么大。微服务架构的主要特点是： * 逻辑清晰 （单一服务抽象的模块当然逻辑清晰了） * 部署简单 （有编排工具） * 容易扩展 （ 基本是以容器为单元） * 灵活组合 (高内聚，低耦合） 那么你除了正常要关注的应用安全，网络安全，以及运维安全等等，还需要更加重点关注（其实还需要关注的内容也可以划分到这里面去） * **服务间鉴权** * **序列化与反序列化** （一般来说服务间通信主要两点： 传输协议，数据协议） * **容器安全** (docker 逃逸漏洞，k8s基线配置等等） * **代码审计**（由于代码量小，所以其实可以做到研发更安全，审计更容易） 当然，上面的内容分一分，其实还是落在了不同的安全团队里。当然如果能够像SRE一样为每个团队配备一个很懂安全的该多好？ 或者说为SRE附加安全知识。 或者是新生成一个角色去这么样做。
不算教程，只是随笔记下。 先说下SLS做的可视化报表和专有BI报表系统的区别（既然内部系统不具有普适性，所以先写个sls的吧）： 1. 缺乏完善的权限控制 2. 无法面向不同管理层释出 3. 查询语法并非标准的sql 4. 针对大量数据的跨度查询可能不准确 但同时sls拥有强大的实时检索能力，同时提供了大量的内置函数。作为监控报表（中的日志收集）可谓是不二之选。同时通过适当的运用嵌套，很快就能做出一个大盘分析以及针对对应条目的下钻分析（别问我啥叫下钻分析），这个可以说很实用了。 先看一个大图：  这个是waf的部分分析图表，可以看出waf的覆盖，每个域名面临的攻击，攻击的对应路径及对应方法，同时还有关于waf自身的心跳检测等。 当然这种属于大盘式的报表，还有针对特定用途的监控报表。再来看一个  （做监控只要自动刷新加全屏即可）  查询语法比较基础那么我们来看下简单的时序查询（注意日志量大的同时不适合横跨很多天数进行查询） ```sql select time_series(__time__, '1h', '%H:%m', '0') as t, count(1) hit group...
首先，知道业务有哪些，有多少资产，然后是数据的流向，知道要分析哪些流量。想要发现什么，阻止什么。其实Google的OKR也可以在这里应用。例如，安全架构的OKR可以这样： O: 发现入侵者，减缓或者阻断攻击，以及取证。 KR: 资产管理系统 --------- 19% KR: 入侵检测系统 --------- 19% KR: 日志收集系统 --------- 19% KR: 关联分析系统 --------- 19% KR: 应急响应系统 --------- 19% 但，即便都做了，也不能100%保证不出问题，还需要做定期的渗透测试。我们先按照这种思路，画出类似的OKR图 O: 日志收集 KR: 明确数据流向 --------- 50%...
之前在BTCC做安全评审的时候，记录过一些内容 #41 。 主要是集中在技术角度。而今站在新的视角下，看到的安全评审又是另外一种。 在此可认为有两种方式： * 一种是**技术角度**入手，切实到每个链条的实现环节。 * 一种是从**全局观**入手，切入点是当前系统的引入，对公司整体的稳定性，安全性。 前者比较适用于小公司或者一个团队内，一个人能够把握全局的。而对于后一种，就适用于大公司，因为无法落实到细节的实施上(这一块可以由开发规范去约束)。所以必须从架构上，和业务上，以及数据流和数据依赖上，针对其对公司的其他业务系统的访问，调用。当前选择的技术栈的支撑情况，数据库的支撑情况，等方面进行综合的考虑。从各个方面都考量着安全评审专家对整个公司系统的把控。也只专注到安全上。至于性能则是由架构师进行考虑。在此过程中，难免遇到的就是有许多人喜欢不懂装懂。或者喜欢钻牛角尖。钻牛角尖并不是不好，但是要分清楚在什么时候，开发人员的视野往往都具有一定的局限性。而架构师则能理解其中的缘由。因此，架构师需要在此充当一个稳定全局的角色。并支持安全评审的意见。当然如果是一个半吊子水准的架构师，则要听天由命了。 比如从全局观来说： * 新的系统依赖了哪些现有系统 * 需要从哪里鉴权 * 链路加密 * 鉴权的方式 * 数据库用了什么 * 技术支撑是否有 * 编程语言是什么，是否是主流的，架构是否支持 * 数据是否能回流 * 数据依赖是否可控 *...
我显然不是一个数据安全专家，但是我马上就要参加DSMM测评师培训了。先纪念一下。 但是根据爬取的一些JD来看。至少要： * 设计过水印系统 * 设计过KMS系统 * 熟悉加解密算法 * 熟悉数据安全模型 * 内容安全治理 * 熟悉等保测评 等吧。这个就先暂时放这吧。 以上是我3月14左右。 2019.04.09 Update: 经历了几天的集团DSMM测评师培训，明天就要考试了。先祈祷明天能过。下个结论，上面说的话显然有些得意洋洋了。想成为一名合格的数据安全专家何其之难。入门已经是不易了。看来还是自己之前太过不知天高地厚。之前心中还有轻视之心，至今晚方知是自己唐突了。 2019.04.13 Update: 考试第三部分的报告终于算是发出去了，等待结果吧。下面补一下相关的脑图及整理的资料。 数据安全人员能力  测评师测评  DSMM架构图  数据安全能力成熟度特征 ...
# 前言 如上一篇所言，采用BanIP的方式，以及限速的方式。当然还可以采用API网关进行限制。不过这些都不是要讨论的，这篇要讨论的是，怎么通过代码层，实现常规，但是又不是那么容易被破解的方式。去达到防刷防作弊的效果。让我们再思考一下其他的方式，如何更好的做到。 # 从JavaScript AntiDebug 开始 一般来讲是有以下几种技术: * 异常环境检测（我们只想自己的代码运行在浏览器中） * 调试工具检测 * 代码完整性检测 * 数据流完整性检测 * 反模拟 正好前两天研究反调试技术，顺便翻译了一篇，详情点击[此处](http://telegra.ph/Javascirpt-Anti-Debugging-08-02) # 设计及验证  POC验证,（请无视字段。。。。），当然前提是前端也要做好反调试和加密。   前后端接入之后，但依旧不能完全的阻止攻击，在攻击者花费一定时间之后还是有可能被攻破的。那么如何在后面的阶段检测到脚本作弊，则需要对用户行为进行分析。 # 用户行为分析 简单的鼠标行为记录，加上事件记录，单击，输入focus input，等等，将其序列化，做分类即可。这个方法目前正在测试环境收集用户行为日志，将其导入到s3,然后后期分析。...
首先专家的定义是指对某一事物/领域精通，并有独到见解的人。根据我自身经历我认为SDL专家起码应该具有以下这4点基本要求.(PS: 同事说，SDL专家就是扮演好一个保姆) * 一套规范的开发/发布流程， 并能针对公司现状(规模，环境等)进行适应性改变 * 安全领域内针对多个领域的专业技能,解决问题的硬实力以及踩坑经历 * 与人的沟通能力以及跨部门的协调能力 * 部门的管理能力以及推动方案落地的能力 首先只有熟悉了开发规范，并且具有专业输出能力，才有把整个事情做出来的基本能力。但同时整个流程是不可避免的涉及到多个部门间的合作，此时跨部门协调能力，以及沟通能力毋容置疑也是十分重要的。 SDL的防护，自古以来的说法是自上而下的推动。当然在小公司中，可能是需要先有安全人员的反馈才能产出，是一种自下向上的行为。不过这种行为，在大公司内的可行性几乎为0... 1. 熟悉开发流程   根据开发流程，找到对应的人员，咨询的，技术支持的，解决问题的，职责者，对应领导，手上的项目，项目的价值等等先要梳理清楚。(**安全的目标是保驾护航，不是去阻碍业务发展。**) 2. 了解流程中需要防护的地方 下图中的总结可能仍有疏漏，抛砖引玉之用。希望能够看到更为详细的在流程中所需面临的一些基础问题。  针对出现的问题风险，一个SDL专家需要做到什么程度。在不同的领域均有造诣？还是说清晰的逻辑思维？简要梳理了下图。真正的SDL专家需要了解的技能领域。  当然很大程度上，在具体的实施上。这些事情是没有办法一个人去完成的，所以这个时候需要体现出另一个职责:带队能力。 通过带领几个安全工程师，分别处理完成不同时间线上的问题。需要安全架构去评审的交给评审工程师。该安全开发培训的交由开发去培训，该进行安全运维的去安全运维，该运营SRC的运营SRC。 分门别类的完成对应的职责。将每一部分进行精细化的运营即可。这个时候专家还需要汇总，和整体把控一下。当然，很多情况下，小公司是不可能养得起一个安全团队的。 那么，你是专家，你尽量干。。。按优先级处理。(不过小公司也不会有这么个流程，被盯梢的几率也不大。即便出了问题，做好基本防护的话，影响也不会很大) # 思考:...
这是之前为即刻Anti-Spam，针对内容安全画的思维导图：  所有的阻挡应该是威胁的一层层缓解手段，直到屏障的方式无法穿透。 # 反垃圾注册 最近公司接收到了不少的垃圾账号注册，估计都是因为积分来薅羊毛的。这些账号会自动的进行其他api交互。完整的流程应将注册邮箱与黑产邮箱数据库进行比对，以及维护一份临时邮箱注册列表，不允许临时邮箱账号进行注册。同时对注册接口进行限速以及禁止机制。这样才能比较有效的完成反垃圾注册。 * splunk， nginx access log * web服务架构: Front ->cdn-> waf1 -> waf2 -> nginx reverse proxy -> WebServer 禁ip的坑： 第一次禁了ip就不能访问，发现是禁了waf2的，然后把waf2的地址配置为回源ip之后，发现过来的ip有一个将其禁掉之后，发现是来自cdn的ip，也就是说cdn的配置(携带真实ip入waf1)并未生效. 直接设置地洞进行动态ip访问限制，1分钟访问注册6次之上的禁用30分钟。 获取源ip:...
软件架构的过程中，SOA，微服务，基于领域驱动的架构设计，敏捷开发，一大堆的名词早已经听得不能再多了。(只有当你身临其境的参与到其中，才能真正的感受到)。 本文简要纪录一下架构图的设计。 一般来讲有以下两种方式(ps:此处就不贴出每张图的具体事例了)： * 4+1视图，分别为物理视图、逻辑视图、处理视图、场景视图和开发视图 * C4模型: 上下文（Context）、容器（Container）、组件（Component）和代码（Code） 但是需要明确的是，首先你要知道你画的图是给谁看的。你要告诉他什么。不同的人不可能看到同一个图去干活的，也不一定都能看的懂。逻辑视图给谁看，开发视图给谁看。只有在最初的时候明确了要传递什么样的意图给别人。才能去好好的画每张图。 (更官方的定义参考百科) 物理视图: 什么系统在什么位置。 逻辑视图: 这些系统干什么事，有哪些功能。 处理视图: 一个请求或者一个数据怎么流向，怎么结束一个流程。 场景视图: 实体和系统的交互 开发视图: 开发怎么完成具体的模块，具体技术栈，基于什么什么。 至于第二种，针对基于容器的微服务设计实现，主要针对于敏捷开发实现。单其实也有类似之处，比如可以样理解，明确你的上下文(场景),有哪些组件（处理，逻辑），然后需要实现什么样的代码(开发)。 至于更官方的可以参考其官网。 针对这些架构图呢，在饿了么以来，由于部门需要和阿里集团侧安全部门合作密切。所以需要梳理架构，在这个过程又思考到以前自己是怎么做的架构设计。结合ATA上的一些经典好文，逐渐产生反思。 总之一句话，知行合一。干了才知道，不干是不知道的。 # 参考 * [C4Model](https://c4model.com/) * [用于软件架构的...
负载均衡和多活
负载均衡可以做的地方很多，从以下几个层面可以看出其具体的实现。 * 路由层 多DNS服务器 * 站点层 多代理服务器，一般nginx有轮询，权重，url-hash, ip-hash,fair 这5种方式，ip-hash可以储存session状态，但是不建议在此处存储seession * 服务层 应用集群部署，多实例 * 数据层 数据库集群  关于多活的设计可以参考下图，是阿里李运华的。  至于同城多活和异地多活的优劣，可以参考下图。  # 引用 * [饿了么异地多活技术实现（一）总体介绍](https://zhuanlan.zhihu.com/p/32009822)