各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 230期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。
话题抢先看
1. 日志采集过程中，如何确保日志数据的完整性，防止篡改和损坏？
2. 如何确保细粒度的访问控制，以防止未经授权的用户访问敏感日志数据？
3. 如何确保在灾难事件中快速有效地恢复服务？
4. 有没有能打乱代码结构的JS混淆工具？
话题一：日志采集过程中，如何确保日志数据的完整性，防止篡改和损坏？
A1：
舍得成本的话，就加密，数字签名，多机热备。我们是用了几台服务器专门做日志采集的，网络隔离非常严格，专机专用。
A2：
冗余备份：将日志数据存储在不止一个地方，以防止某一份数据的损坏或丢失；
数据校验：使用校验和、散列函数等技术来验证日志数据的完整性；
数据加密：使用加密技术来保护日志数据，以防日志数据被窃取或更改；
数据版本控制：使用版本控制系统来管理日志数据的修改，以便在遇到问题时回滚到以前的版本；
审计日志：记录所有对日志数据的操作，以便在遇到问题时进行审计和分析。
A3：
日志和业务服务器分离，确保业务服务器攻陷后不影响已经生成的日志。日志服务器自身做好加固和相关基线工作。
A4：
标准做法是在SIEM日志审计设备收集上来的日志做完整性签名，因为审计日志不是敏感数据所以暂不需要加密，只需要完整性保护。完整性保护需要给日志用签名与验证签名服务器和密钥进行SM2/SM3 的签名，和验证签名保证其完整性。并且日志审计设备在隔离的安全区域，通过加密隧道和认证才可以访问， 也符合相关的密码保护合规标准。
A5：
比如数据源那边优先使用TCP Syslog， 然后使用Agent采集的数据源做Agent监控，避免Agent长期离线。 数据库读取的随机时间范围内的日志条数做对比，另外日志存储服务器权限控制，管理员操作定期审计。
A6：
日志按照资产价值做相对应定期异地备份，可以在一定程度上缓解这个问题。
A7：
加密传输，日志备份、严格的读写权限、对日志收集传输进行监控审计。
Q：如何确保细粒度的访问控制，以防止未经授权的用户访问敏感日志数据？
A8：
这个就是做好权限管理和审计了。
A9：
只给固定的人员开启访问权限，其他访问必申请，这个应该还好，应该主动愿意看日志的人也不多。
A10：
细粒度的访问控制不太好搞，一般也就是ABAC\RBAC就行了。
A11：
ALC访问控制，再加个操作审核。
A12：
要求比较严格的话，日志服务器开启ACL控制，必要的时候上堡垒机审计。
A13：
控制权限划分，设置审计策略。
A14：
1. 网络控制，开白名单访问IP，限制到访问端口；
2. 权限控制到人，IP和MAC和人做绑定。
Q：如何确保在灾难事件中快速有效地恢复服务？
A15：
建立数据备份系统，制定灾难恢复计划，评审灾难恢复计划的可执行性并且每季度检查。
A16：
权限申请、审批，谁审批谁负责制。
A17：
这个问题要看场景的吧，不能这么绝对。审批的人应该负授权是否合理的责任，申请人负在权限范围内造成的敏感信息泄露的责任吧。
A18：
这个是的，不过宣贯要从这儿做起，出了事，分锅肯定是按照职能权限来的。不过在审批时候，就要对下对上都得承担一定的责任了。
A19：
审批也就是流程控制做卡点合规内控而已，想靠这个去限制其实不现实，很多流程到了也就点点就过，没负担。
A20：
应急预案，演练。保障恢复流程顺畅；冗余（多云，多节点）、备份保障恢复流程高效。持续改进，查漏补缺，保障流程和方案不断提升。大致这么多。
A21：
应急到最后，就看托底的备份是不是还存在，是否可用，数据缺失多少。
A22：
灾难不仅仅是数据丢失。
A23：
嗯，但领导关注的是业务连续，因为除了对社会影响大的安全事件，首先在企业内部就做了封闭，我们要做的应急是尽量内外上下都无感。
A24：
按照SLA的一些标准操作，我个人的理解是：
1. 建立灾难恢复计划，保证出现系统问题可以按照计划流程以及人员配置迅速进行修复和启动系统；
2. 提前做好数据备份，当因为勒索而系统无法使用时可以迅速还原数据，减少损失；
3. 用HA建立备份系统，备份系统数据与主系统数据保持同步，一旦发生问题可以切换到子系统；
4. 也可以使用云厂商提供的灾难恢复的产品功能进行恢复（节省时间和人力）。
话题二：有没有能打乱代码结构的JS混淆工具？
A1：
JScambler、JShaman（商业版，但是有在线免费版本）。
A2：
这两个不太行，要那种打乱结构的，不是替换关键词啥的。
A3：
UglifyJS、Terser、Jscrambler、Obfuscator。
A4：
这种都不行。这种主要慢慢打断点，还能调出密钥，就看看有没有直接打乱代码结构的。
A5：
那过于混淆了，我建议通过加密来解决。
A6：
把一些关系敏感信息或者整体的JS都进行加密，因为如果修改主体结构，可能会导致代码不可读的，稳定性、可用性很差，还有不好维护。不过商业化工具我没怎么了解过。
A7：
再怎么混淆了也不能避免被调试出密钥吧，只是增加了难度。
A8：
逆向还是可以的，就是难度问题。
A9：
是啊，现在难度还是不够，反调试都加了，就看看有没有更牛逼的方案。
A10：
你这个做了字符编码和字符串拼接吧？
A11：
这种就是var return，if啊太清晰了，代码结果很容易识别。然后就可以猜到大概的加密位置，慢慢打断点就能调出来。\x这种都是乱码再编码后的。
A12：
那你还是看看加密吧。
A13：
混淆跟加密有啥区别，有工具吗？还有种通过包含加密文件调用的方案，但是有的系统不适用，那个倒是无法调试。
A14：
混淆侧重代码更难以理解和修改，加密侧重将数据转换为不可读的加密信息。
A15：
而且加密信息在没有密钥情况下几乎不可逆向，我觉得你们的代码信息还不至于让人家用这么大算力去破解，还有时间。
A16：
前端加密就能防住前端的代码调试吗？
A17：
能防住，但是你说完全防住，谁也不敢保证。
A18：
话说你们总不能把对称密钥放在JS里吧，放进去再混淆也没用。前端加密方案不都是RSA加AES么。
A19：
单用的AES，很难受。
A20：
浏览器动态调试，结合请求啥的，大概位置还是挺好定位的。
A21：
对称就是AES、DES，非对称就常见RSA、DSA这些，看你们怎么使用。
A22：
我假设个场景，前端对数据包做验签，加签过程有使用到这个密钥。为了防止前端密钥泄露，如何使用RSA对这个密钥做非对称加密，让前端浏览器无法动态调试出这个密钥？
A23：
RSA加密密钥，发送到前端和前端浏览器-->在使用私钥进行解密加密的密钥-->使用密钥被解密，就可以使用密钥对数据包的加签，就算密钥泄露也是加密后的，无法解密，不过还是只是加大难度，总会有办法。
A24：
1. 如果是单向验签，是基于HMAC，公钥是公开的，不存在密钥泄露的问题；
2. 如果是双向的，因为前端调试必然会调试出私钥，为了保证安全就需要上硬件，如CA硬件。
A25：
AES密钥随机生成，RSA加密AES密钥。服务端RSA解密获取AES密钥，再解密数据。另外加入Nonce防止重放。应该大部分都是这么做的。
本期观点总结
在关于日志采集及访问的话题中，大家讨论得出确保日志数据的完整性、防止篡改和损坏的方法包括冗余备份、数据校验、数据加密、数据版本控制和审计日志。为了确保细粒度的访问控制，可以采取权限管理和审计措施。在灾难事件中，建立数据备份系统、制定灾难恢复计划、评审计划的可执行性、应急预案和演练、增加冗余和备份机制等措施可以快速有效地恢复服务。这些措施可以保障日志数据的完整性和安全，并在灾难事件中提供快速有效的恢复服务。
在关于JS代码混淆的话题中，诸如JScambler、JShaman、UglifyJS、Terser、Jscrambler和Obfuscator等工具虽然可以使代码结构更难以理解和修改，但并不能完全防止被调试出密钥。为了更强的保护，建议使用加密方案，如RSA加密AES密钥。总体而言，混淆和加密可以增加攻击者破解的难度，但并不能完全防止被逆向工程。选择适当的方案需要考虑安全性和可用性之间的平衡。
近期群内答疑解惑
Q：领导说今年重点工作是建立资产图谱，如何建立图谱？
A1：
公司规模多少？先根据资产数量，预估是上工具还是Excel表。
A2：
我们目前是Excel表，用来迎27001的。
A3：
那就继续Excel表，字段弄好，用共享看板的形式。
A4：
先自己确定一部分字段，最好结合漏扫需求比如重要性、区域之类的，再结合业务，最后和领导确认一下， 以领导意见为主。
Q：服务架构下大家是如何对众多API进行安全测试的，尤其是未授权访问这种漏洞？
A：
流量收集：接入层镜像收集流量；
流量检测：不要检测所有接口，聚焦敏感接口或者你关心的某类接口，做接口资源池和身份池，流量重放看返回是否一致，所有接口检测公共接口会大量误报；
白盒思路：看一下公司所有接口代码判断身份逻辑的代码，去匹配库里所有代码是否有接口未引用类和代码片段。
Q：公司内部的一个对象存储因为某个业务，领导让把对象存储发布到公网上，请问内部对象存储适合发布到公网上吗？有哪些比较好的防护措施？
A1：
分布式对象存储。
A2：
如果只是技术问题，那么：
1. 加密传输；
2. 身份验证和授权；
3. 访问控制；
4. 底层数据加密和备份；
5. 监控和日志；
6. 审计和漏扫；
7. 版本控制。A3：
互联网使用独立的Aksk，关闭该Aksk的所有List和删除等不必要权限，仅允许上传下载权限。对于具体的OSS对象，不开放永久公开访问，仅允许上述Aksk申请临时访问链接，一小时有效。
A4：
使用OSS存储，应该都可以满足。
A5：
Aksk放在服务端不能放在App端，服务端验证好用户身份和资源所属关系后，再申领临时URL下发给客户。
A6：
云上的OSS对象存储还好，关键是办公机房内部的一个分布式对象存储。
A7：
OSS的弊端主要在没有C端用户资源所属关系的管理模型，所以建议不能直接暴露给C端，要走个中间层进行资源的鉴权。
Q：考法对安全的助力是什么？
A1：
我觉得是转职做合规，当然是大型企业才需要吧，小型企业合规也是凑合。
A2：
1. 更好的司法解释；
2. 更好的保护企业利益，哪怕是在跟监管机构也可以引用法条有理有据；
3. 对司法流程更加理解透测；
4. 对立法精神更好的理解本源；
5. 你可以说自己是真正的企业在安全方面的责任人，有法律背书的。
甲方群最新动态
上期话题回顾：
活动回顾：
近期热点资讯
FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！
【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】
注：目前1群、2群已满，如有疑问，也可添加Kiki群助手微信：freebuf1024，备注：甲方会员
“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1300+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。
如有侵权请联系:admin#unsafe.sh