0x1本周话题
话题一：请教一下，证券公司数据安全治理，特别是办公环境和远程办公的安全控制访问，很多投研人员希望在办公环境访问组合持仓等信息，这种需求怎么做好安全控制的？
A1：云桌面或数据沙箱封装，水印威慑，应用侧做数据操作记录。
A2：这个不是安全问题，属于业务问题，是否允许。只读还是可以操作。目前监管对投研的远程办公有限制。
A3：我们的做法是前置化处理，在应用侧前面部署零信任应用数据安全网关，做入口统一管控，不用改造业务去实现几个目的。
收敛应用暴露面，包括办公网内的暴露面，防止被攻击，包括1day、0day防护；
做权限动态收敛，基于场景去收敛权限，比如远程访问时和内部访问时权限动态调整，实现最小化授权防止内部越权；
管控数据操作，比如跨网的应用在办公网不允许下载，交易网可以正常下载，防止不该出去的数据被下载；
人员行为审计，以人的视角对完整行为审计，人/部门访问什么应用获取了什么数据；
最后对数据处置，基于场景来动态处理数据，非安全区域访问增加水印和脱敏，交易区这种安全区域访问不做特殊数据处理。这样把数据的管控行为前置化，避免不该访问的数据被访问，不该在特定环境获取的数据被下载，完整行为被审计。对于必须下载的数据，在终端侧用VDI或是沙箱来防止数据外发。
A4：按照你的这个方案，业务方需要做如下动作：
业务系统配合反向代理接入数据网关；
结合业务场景和角色提供明确的授权配置以及环境依赖信息，用于做动态调整，比如人资数据，业务和角色的操作关系，合理时间段等；
需要代理文件流做劫持阻断，配合给出对应的文件数据类型用于网关配置规则；
提供脱敏数据字段用于配制规则；
安装终端沙箱用于落盘。
话题二:请教个web认证授权方面的问题：内网有个应用a http://a.xxx.com/，没有认证功能，互联网DMZ区有个java应用，https://d.xxx.com/d1/d2/带用户认证功能，d需要调用a，a返回的结果为url http://a.xxx.com/a1/a2/suijishu/，带用户交互反馈。
现在需要应用d的互联网用户，登录d后可以访问a的url页面，未经登录d不能访问a的url页面（最好a的页面不直接暴露在互联网）。请问有啥办法吗？【目前开发提供的方案】没有认证授权功能（说没法做），在d中web嵌入iframe让用户访问http://d.xxx.com/a1/a2/suijishu/
（实际以代理方式映射到http://a.xxx.com/a1/a2/suijishu/ 完全绕开d的认证），这样互联网侧就相当于无限制访问 http://a.xxx.com/a1/a2/suijishu/ 以及整个应用a。
A1：内网调互联网？可以在a的前面插一个ng，必须经过它，然后ng必须认证。
A2：是互联网应用，调用内网的页面。没明白，新的ng跟d是什么关系呢？怎么做认证？原文是这样，“希望应用d的互联网用户登录d后可以访问a的url页面，未经登录d不能访问a的url页面（最好a的页面不直接暴露在互联网）”。
A3：ng可以用跟d一样的授权系统，是sso就sso，把不可改造的外部系统转化成了可改造的系统，然后这个可控系统(ng)通过转发鉴权控制着每个uri的访问逻辑，没鉴权的拒绝访问。
A4：加一个中间层。不要通过 iframe 直接暴露a。
A5：可以参考这个。
https://blog.csdn.net/u010260632/article/details/139173856
A6：主要是iframe没用，后面出了问题还是安全来背锅。
A7：可以将a站点通过API网关暴露来解决，认证网关可以实现。如果没有网关，可以通过b站点包一层来实现认证。加网关其实更好了，相当于把请求单独处理了，内部解析交互数据，外部碰不到a。
A8：我单位现在也面临这种API对外暴露的情况，我在考虑这个方案是否有复用性。对于“b站点包一层来实现认证”再访问a，开发说不知道怎么做。
A9：API网关可以做认证、加签验签、限流等安全措施，对安全来说非常友好，可以统一做API安全管控。我感觉类似于用户和b站点交互，b站点再和a交互，b站点可以拦截请求做检查，但是这需要研发改代码。
也要视具体情况分析，这样的架构设计是否合理，研发运维是否接受，是否符合内部规范。
A10：现在在金融，研发自己就重视底线。以前在互联网，没有强制要求，但是有SRC，这种问题，最后都是要交钱的，结果是开发也重视、主动出解决方案、出过滤器、出统一网关 所谓不会，根本还是不想动，觉得不关自己事。
A11：感觉是b站点研发和a站点研发会扯皮了，b站点研发要负责解决a站点的认证问题。 长期建议建设统一的解决方案，再来一个c站点怎么办？
A12：这个对我们应该比较好做，如果没有理解错的话，可以把我们应用网关部署到前面，DNS引流过来，网关上判断请求是否来自互联网。
如果来自互联网就触发用户强制认证（网关来触发，应用不需要改造）内网或是其他地方访问，可以不用走交互认证（根据位置或是请求方式判断）。
如果需要经D认证，网关调用认证时使用D的认证方式来进行，这样实现会话一致性。
A13：不会就引入外部技术也是个解决方案。
A14：这个对我们是很成熟的方式，相当于在前面作为应用网关，请求过来后，基于条件和身份来判断，什么样的需要经过认证，什么样的不需要。
做业务访问入口后，业务接入进来后不用改造，通过网关的技术来动态帮业务完成认证、鉴权或是更深的数据控制的一些场景。
A15：鉴权要做成标准服务，可以通过SAML或者OAuth2.0进行对接的。
话题三：请教个技术问题。如果云上web公网暴露，通过域名cname到waf到透明模式fw到alb到ecs，这种架构下ecs安全组允许互联网访问到80/443的源ip是否都只允许云WAF回源ip，因为waf会将做公网源地址转换。
A1：应该要这样限制，不然可以绕过waf。ecs安全组是内网了，你这个应该LB上做访问控制。如果waf是私有化部署，那看LB是不是内网的，那就不存在这个问题了。
A2：不应该在那个ALB上做防护么？为啥要直接在ecs上做？
A3：fw也行。流量都会过透明fw。像公有云fw都会自己收集回源地址，不用太关注回源地址的变化。
A4：为什么alb接到一个公网的ecs上面的？alb（独立IP/动态IP）->vip（内网）->内网服务群。应该是这样才对吧。
A5：Ecs是内网的，用的是云waf。我是想确认，如果这种架构，是不是fw，alb，ecs上看到来自互联网的数据包，三层IP地址都是WAF回源的公网ip。
如果是这种，就可以把web server的入向安全组从允许0.0.0.0收成仅允许WAF回源的公网ip。
A6：fw或alb配waf回源ip，ecs的web端口只需要配alb的内网ip。alb的安全组入栈应该是waf的地址，ecs的安全组入栈应该是alb对应的vip。
A7：建议直接启用alb的waf透明模式。waf肯定会做源ip地址转换，alb是否做了源ip转换需要确认是吧。这个会产生什么效果呢？
A8：不需要配waf回源ip。
A9：这些制度要求需要员工签署吗？
A10：有个确认函，名称叫关于知悉公司规章制度及录用条件的确认函。你去网上搜一下模板，就是把公司相关的管理制度、安全制度啥的都写进去，然后关于这些制度的阅读位置存放位置都写进去，签署即表示阅读，即表示知悉。
0x2 群友分享
【安全资讯】
黎巴嫩驻联合国代表团：爆炸的通信设备抵黎前就被植入炸药！美媒爆料：以色列多年前设立空壳公司实施该计划
众议院听证会上，CrowdStrike 将蓝屏事件归咎于“多种因素叠加”
太“疯狂”！运营商“内鬼”搭建特殊通道，发送短信805万余条……
关于公开征求对《工业和信息化领域数据安全合规指引（征求意见稿）》意见的通知
【行业思考】
【安全技术】
由于微信修改了推送规则，需读者经常留言或点“在看”“点赞”，否则会逐渐收不到推送！如果你还想看到我们的推送，请点赞收藏周报，将【君哥的体历】加为星标或每次看完后点击一下页面下端的“在看”“点赞”。
