![企业上公有云，网络架构层面有无最佳实践？如何管控dba登陆到本地的操作？有无更好的方法满足远控需要？| 总第144周]( "企业上公有云，网络架构层面有无最佳实践？如何管控dba登陆到本地的操作？有无更好的方法满足远控需要？| 总第144周")
![企业上公有云，网络架构层面有无最佳实践？如何管控dba登陆到本地的操作？有无更好的方法满足远控需要？| 总第144周]( "企业上公有云，网络架构层面有无最佳实践？如何管控dba登陆到本地的操作？有无更好的方法满足远控需要？| 总第144周")
0x1 本周话题TOP3
话题1: 现在企业上公有云，网络架构层面有啥最佳实践吗？比如传统IDC一般搞三个区，DMZ区，内网应用区，数据库区，三个区之间设立防火墙，流量按需开通， 这套逻辑能搬到云上去吗？或者说云上应该怎么搞呢？
A1:依赖企业安全组实现逻辑架构或者VPC模式，具体如下：
![企业上公有云，网络架构层面有无最佳实践？如何管控dba登陆到本地的操作？有无更好的方法满足远控需要？| 总第144周]( "企业上公有云，网络架构层面有无最佳实践？如何管控dba登陆到本地的操作？有无更好的方法满足远控需要？| 总第144周")
![企业上公有云，网络架构层面有无最佳实践？如何管控dba登陆到本地的操作？有无更好的方法满足远控需要？| 总第144周]( "企业上公有云，网络架构层面有无最佳实践？如何管控dba登陆到本地的操作？有无更好的方法满足远控需要？| 总第144周")
A2:看哪个公有云，有些公有云目前没有防火墙，只有安全组。我觉得还应该有个运维区。
A3:能不能把流量引入类似board leaf区域的物理防火墙？一般不都是生产环境上云吗？上图中开发环境和测试环境也上云？
A4:我看一些银行有啊，测试也有云的。另外一般公有云，默认提供安全组功能，防火墙功能要收费，不过安全组也可以实现近似防火墙的访问控制了。
A5:acl 的能力能通过等级保护么。明确的要求基于状态的acl。
A6:用单VPC+安全组方便些。多VPC隔离，除非是每个VPC尽量独立，没有流量，否则不建议划分太多VPC。有些云商VPC之间流量还会额外收费。基本上传统三区用安全组可以满足。安全组是基于状态的
Q:同样的问题，那k8s的话，怎么做安全分区分层？这个还真没研究过，传统linux上的iptables 不是基于状态的。
A7:开个公有云虚拟机试试就知道了。安全组可读性比较差，也不太利于维护。按照传统的网络划分那么严格，感觉用安全组会是个噩梦。
复杂度低还是可以用安全组，网络复杂后再用安全组，管不过来了。有的所谓私有云，新瓶装旧酒。没有多租户概念，还是传统五元组玩法。
A8:我本来想趁等保把边界防火墙弄起来，结果咨询公司和测评机构都没觉得安全组有问题，哪怕我反复跟咨询公司提醒。
A9:安全组是一种虚拟防火墙，用于控制安全组内ECS实例的入流量和出流量，从而提高ECS实例的安全性。安全组具备状态检测和数据包过滤能力，您可以基于安全组的特性和安全组规则的配置在云端划分安全域---某家产品的网站介绍，如果真如这个写的，好像是具有状态。性能是不是也不是问题了。
A10:安全组做单主机的acl, vpc的vswitch做大域acl. 不要想把一块蛋糕切几百份还不切乱的。
另外云上安全组不像云下防火墙流量可视化还可以抓包分析，安全组甚至没有流量日志。云防火墙还没用过。
A11:有vpc流量日志，不过存储、分析成本高而已，看有无资源做。
A12:正好这两天在讨论云墙的问题，对某产品的分析抛砖分享下：
-
双AZ容灾场景下高可用问题，目前尚未给出最终解决方案
-
（1）防火墙实例目前最多支持16个，支持32个实例还在测试中。
（2）可配置地址簿、策略上限太低，比交换机ACL功能强点有点，与各厂商物理防火墙相比差距较大。ACL中源地址、目的地址不能配置多个成员或者多个地址簿，会导致每条策略都需要定义新的地址簿，或者配置多条策略，导致需要配置的策略条目会远大于。目前云墙可定义的策略限制：IP地址薄上限 5000 端口地址薄上限 5000 每个组里最大可配置地址数 50 每个组里最大可配置端口数 2500 每条规则最大可拆解条目数 2000 最多可配置规则数 50000
-
（1）在产品使用过中，经常遇到各种问题，高速通道不能同步，防火墙实例无法创建、无法删除。
（3）ACL策略配置较为麻烦，源地址、目的地址无法增加多个成员，IP不支持范围格式，必须新增地址簿，增加地址簿，地址簿刷新也很慢。
（4）策略查询能力太弱，基本属于不可用状态：无法基于ip查询；界面每页最多显示6条。
（5）每次新增加策略后都得手动调整一下位置，还经常容易移错。
A13:大的网络区域间的管理还是推荐云防火墙，安全组只适用简单的访问规则，主要是规模大了很难管理维护，就像网络设备的acl一样，可维护性不好，太多策略性能也会受一定影响。
目前部分云有Vpc防火墙，安全组维护不了，做多vpc限制尚可。
A14:安全组的维护工作量不小。安全组开通没有标准规范，大致就是研发或业务找到运维，运维就给开了，要不就是开放的范围太大，没有一个规范。目前大部分企业也是这样相对比较粗放的管理。
A15:安全组基本可以类比于传统区域隔离吧，一般是分类考虑，有些区域之间是可以申请就开通，有些敏感区域是需要单独评估后特殊审批开通，特别是在违反安全组创建管控原则的时候，不会一概而论。
Q:如果把一个子公司作为一个租户，把每个分公司作为安全组（或者一套系统作为一个安全组），dns、ntp这类服务作为全局策略通的，这样管理相较于传统架构是不是会更清晰呢？横向攻击的风险会小一些，而且也容易监测到。
A16:一个系统作为安全组，横向是没问题了，纵向是不是差点意思，也有像这个事。
同时系统怎么切割也是个学问，南北向还是按传统的思路来，我是觉得云给安全带来了很多的管控能力（当然管好了也有很多维护工作量），可以研究应用下。
A17:云在设计的时候都是怎么想的资源池共享，弹性伸缩，和传统的安全架构理念上有很大的差别。内部不同的应用，接口访问控制主要都是靠API网关，注册中心的身份认证，签名来实现。
A18:安全组管控的颗粒度越细，变更和维护的工作量越大，趋向微隔离。在考虑云上做到什么颗粒度是比较优的解，云上的能力还是比传统管控稍微简单一些的，在自动化的过程中可以把安全的要求纳入进去。另外，对于微隔离，个人感觉还是通过平台做比传统通过主机做更科学。
A19:南北向互访通过安全设备控制，东西向互访落在主机安全侧控制较灵活些。
话题2：大佬们，咨询个问题，对于dba登陆到本地的操作是怎么管控的？
A1:堡垒机应该可以拿到交互的查询。另外本地这个用户是可以要求删除的，只保留远程登录。
A2:就是通过堡垒机登陆到操作系统在sqlplus进数据库的。虽然堡垒机可以限制禁用高危操作命令的，但堡垒机的限制很容易被绕过，限制要求很精细，没考虑到就绕过了。
Q:远程登陆影响dba的操作效率，dba登陆到本地是从哪里是用什么工具登陆到哪里呢？，另外都让他登录堡垒机了，那说明有授权了，要管什么呢？
A3:访问不该访问的，做了不该做的操作，存在操作风险。现在想不让dba登陆到本地，对高危操作管控起来，也不想影响dba效率。堡垒机这个只能管远远程，登陆到系统本地了就不行了。
A4:数据库防火墙？最近正好再做运维安全专项，堡垒机里面可以设置哪些是高危命令，但高危命令说起来容易，到底哪些绝对不能执行，信安圈也没有最佳实践。vi个文件，啥命令都执行了。
举个例子，操作系统层面，目前来看主要是 rm类比较敏感，但是这个需要加限制条件，命令还是需要允许使用的。数据库的drop命令敏感，也不能绝对禁止。
A5:所谓高危命令，都是防君子不防小人，防审计不防dba，注重的是常见高危，做还是要做的，要做实还得把运维平台化。执行的时候可考虑需要二次确认。
A6:前者是授权，随着操作审批走，在审批的时间窗口内对特定资源开放授权。后者是操作过程管理，双人临岗，操作符合，只靠堡垒机的命令限制是不够的。技术层面不难，实操落地难。
A7:看风险偏好了，觉得风险高，必须要在事前管住，那就走向双敲复核的路线。要不是主要矛盾，那就告警事后审计。突发事件怎么应对？这个也是需要面对的，双敲在日常都是双倍人员，这个投入更大。还是风险偏好，是恢复客户服务更着急，还是控制操作风险更着急？紧急情况必然有特殊通道。
Q:做到双敲的，人家的运维自动化水平必然很高了，双敲只是解决一些手工问题。
-
能不能把corp account转换成service account去执行dba所需要的操作。
-
能不能登陆堡垒之后，再使用生产账号去执行dba所需的操作。
-
能不能对2中的dba role做just in time管理。
-
如果3不能实现，等不能把dba所需要的entitlement按照root和非root做角色分割。
-
能不能对角色所包涵的entitlement做白名单管理。
-
能不能在bastion上做session管理，在目标服务器上做日志收集。
-
A9:和dba聊过，数据库的敏感操作主要也就是drop 操作，update和delete没带where限制这些情况，怎么能做到精细化管控目前还是有点难。这就和执行rm不是有问题，执行rm -rf *才是问题。
A10:我就想过某家厂商的数据库审计是带阻断功能的，能不能把阻断功能启用了。不过这好像就要agent。
A11:08年还在乙方时，那会就有db防火墙了，到现在这个产品也没有发展和广泛应用起来，说到底还是准确率问题。数据库审计基本上都是旁路部署和使用
A12:安全圈还是潜心研究的少，感慨一下，至少sql脚本现在有自动化审计平台，哪些语句有问题都能自动化发现（哪怕是语法类的），sh、python脚本目前没有看到有自动化检查安全性的产品或工具。
A13:dba把想执行的操作说清楚，从哪里访问哪里做什么操作，iam把对应的方法告诉他就行了。dba如果不清楚自己做什么操作，想清楚再谈怎么管控吧。
补充一点，数据库的审计日志（录屏或者脚本）要分开存储，防篡改。
A14:现在的DB防火墙，是不是还是主要依据规则库来进行检测？而且DB数据库有个很大的问题是，会各种误报误拦截，影响业务。开发人员的sql不规范，很容易被拦截的。
-
-
-
个人不能直接持有和使用OS账号，需要通过堡垒机托管和授权，安全管理员做堡垒机账号管理
-
DBA使用本地账号，考虑如何不能绕过主机管理员和堡垒机，这里可以对命令做检查和阻断
A16:不考虑对DB的高危命令直接阻断，考虑堡垒机上的高危命令做阻断，DB上需要考虑把业务账号和个人账号拆分，不允许混用。
A17:Dba日常运维怎么办？不是会涉及到drop这些命令的吗？
A18:不犯错和不作恶不是系统能避免的，是需要管理上考虑的。要把运维检查过程和修改过程分开，平时查运行态健康情况，要脚本化自动化工具化，dba看生成的报告来检查就行，发现问题要修改，事前审批明确步骤细化到命令行，事中有授权有复核，事后有审计。
话题3：各位，鉴于一些远控软件报出了漏洞安全，目前内网禁了如teamview、向日葵之类的软件。但又有远控这方面的需要，主要是一些设备电脑要供应商远程调试，有没有什么好的方法？
A1:QQ远程、飞书远程、这俩都有远程协助功能，当然有自己的vpn相对比较安全一些。
A2:VPN这个不见得可以覆盖所有场景，而且VPN的权限其实比远程协助开的口子更大，协助工具只是一台的权限，VPN是一个区域。
现在想在DMZ放一台堡垒机， 然后到终端是通过VNC远控。这样安全？
A3:已知常见所有国产vpn堡垒机都有0day，而且0day这个避免不了，得想着管控网络，限制网络出入口。
A4:对比0day和Nday，感觉Nday更让人头疼，关注度小的多，更容易被利用。有桌管的话，桌管也可以实现。我们内网远程协助使用安全客户端软件。互联网暂时也没有找到合适的方案。
A5:供应商的话可以给供应商开VPN，使用双因素。VPN连进来后只允许连接堡垒机，堡垒机再进行权限分配，审计。管理手段可以签保密协议。
A6:互联网 --> VPN-->堡垒机--->VPN-->pc。他这个需求应该是厂商远程调试，不是内部，外部厂商也没法用你们的终端管理系统啊，再说了，终端管理系统那么大权限，管控公司的所有PC，你直接给厂商，怕不是想离职了。
A7:互联网->VPN->堡垒机->服务器。VPN+堡垒机无法实现实时双方同时操作的远控特殊功能。其实也可以直接QQ之类的携带的远程协助功能，然后链接到PC，然后通过PC访问堡垒机，云桌面到其他区域。外部厂商操作需要内部人员陪同做二次确认，或者提供手册由内部人员执行。
A8:堡垒机账号鉴权啊或者专门一台给外部用的，想搞一台堡垒机单独给外面远控内网的PC用。
A9:对呀，QQ、飞书的远程协助，需要二次确认的，而且登录到其他区域，也需要内部员工帮忙登录，全程录屏或者看着，这样安全性，相对可以保障。
A10:有的产品能够实现把堡垒机网页访问的链接发给供应商，然后用户和供应商都能看相同的界面，一个人操作的另一个人能看到。这样不能用SSH访问，得用网页方式，也能审计啥的.
A11:相对这个是有较大成本投入的，并不是所有公司都能投入个产品搞这个的。
A12:堡垒机能实时监控。账号登录双因子，资产访问双人授权，运维过程实时监控，操作记录事后审计。这个堡垒机上都带有这样的功能，不过要人去看的话，这比较不现实。
A13:拨vpn访问内网堡垒机啊。VPN给账号对外，厂商可以主动登录的，如果仅仅是协助排查问题，是没必要下这么大成本的。如果是长期进行项目开发啥的，你给他VPN，划分独立的网络区域，这没问题。得区分开场景来开放权限呀，哥哥们，不能为了方便直接一个方案覆盖虽有场景，显然是不科学的。
A14:你拉一下你的设备运行报告上，还是会有国外的地址出现 ，并不是说你封掉了，国外的地址就不出现了。封掉的都被防火墙挡住在墙外了。
A15:报告上是有，但被拒绝。没有成功的国外的流量访问VPN啥的。提供两种，并制定流程和结合edr禁用措施，有漏洞的停用，只允许用新版，逼大家用安全版本。
A16:我不敢苟同，如果是甲方主导话，建议这类的远控软件尽可能杜绝掉，因为是有其他平替且安全的软件的，edr也好，流程也罢都覆盖有限的，如果是遇到攻击，这些都可以被绕过的。
A17:他是乙方厂商吧，如果是金融类的可能就直接现场了，监管都要求禁止远程维护的。像我们这种弱势甲方很依赖乙方的技术支持的。一刀切，会导致业务的运维受阻，信息部门面对使用部门的压力很大。
A18:这倒是。毕竟乙方的技术和专业性更高。如果有一个很便捷的，很稳定的远程解决方案也是可以的，我们也在测试一些零信任远程工具。安全的解决方案要不投钱，订制各种监控管理软件；要不投人，负责控制访问权限的人就得24小时standby。
A19:目前暂时外部远程选择的是视频会议的远程也能录屏控制功能，功能有限能满足基本的远程需求，如果需要比较复杂的操作那就得本地了不允许远程的。
本周群里共有 94 位群友参与讨论，群发言率为 20.80 %，群发言消息数为 332 条，人均发言数为 3.53 条。
本周群里共有 69 位群友参与讨论，群发言率为 20.41 %，群发言消息数为 268 条，人均发言数为 3.88 条。
--------------------------------------------------------------------------------
【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
实战攻防演习探讨：今年的演习会有哪些变化？我国需要怎样的攻防演习?越权类的攻击是否有好的检测思路？| 总第143周
如何进群？
原文始发于微信公众号（君哥的体历）：企业上公有云，网络架构层面有无最佳实践？如何管控dba登陆到本地的操作？有无更好的方法满足远控需要？| 总第144周
评论