企业上公有云,网络架构层面有无最佳实践?如何管控dba登陆到本地的操作?有无更好的方法满足远控需要?| 总第144周

admin 2022年5月2日17:21:24云安全评论3 views6596字阅读21分59秒阅读模式

企业上公有云,网络架构层面有无最佳实践?如何管控dba登陆到本地的操作?有无更好的方法满足远控需要?| 总第144周


企业上公有云,网络架构层面有无最佳实践?如何管控dba登陆到本地的操作?有无更好的方法满足远控需要?| 总第144周


0x1 本周话题TOP3


话题1: 现在企业上公有云,网络架构层面有啥最佳实践吗?比如传统IDC一般搞三个区,DMZ区,内网应用区,数据库区,三个区之间设立防火墙,流量按需开通, 这套逻辑能搬到云上去吗?或者说云上应该怎么搞呢?


A1:依赖企业安全组实现逻辑架构或者VPC模式,具体如下:


企业上公有云,网络架构层面有无最佳实践?如何管控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, vpcvswitch做大域acl. 不要想把一块蛋糕切几百份还不切乱的。


另外云上安全组不像云下防火墙流量可视化还可以抓包分析,安全组甚至没有流量日志。云防火墙还没用过。


A11:vpc流量日志,不过存储、分析成本高而已,看有无资源做。


A12:正好这两天在讨论云墙的问题,对某产品的分析抛砖分享下:

  • AZ容灾场景下高可用问题,目前尚未给出最终解决方案
  • 性能、产品瓶颈问题
    1)防火墙实例目前最多支持16个,支持32个实例还在测试中。
    2)可配置地址簿、策略上限太低,比交换机ACL功能强点有点,与各厂商物理防火墙相比差距较大。ACL中源地址、目的地址不能配置多个成员或者多个地址簿,会导致每条策略都需要定义新的地址簿,或者配置多条策略,导致需要配置的策略条目会远大于。目前云墙可定义的策略限制:IP地址薄上限 5000  端口地址薄上限 5000  每个组里最大可配置地址数 50  每个组里最大可配置端口数 2500   每条规则最大可拆解条目数 2000   最多可配置规则数 50000
  • 产品使用问题
    1)在产品使用过中,经常遇到各种问题,高速通道不能同步,防火墙实例无法创建、无法删除。
    2)页面刷新较慢,经常弹出错误
  (3ACL策略配置较为麻烦,源地址、目的地址无法增加多个成员,IP不支持范围格式,必须新增地址簿,增加地址簿,地址簿刷新也很慢。
  (4)策略查询能力太弱,基本属于不可用状态:无法基于ip查询;界面每页最多显示6条。
  (5)每次新增加策略后都得手动调整一下位置,还经常容易移错。

A13:大的网络区域间的管理还是推荐云防火墙,安全组只适用简单的访问规则,主要是规模大了很难管理维护,就像网络设备的acl一样,可维护性不好,太多策略性能也会受一定影响

目前部分云有Vpc防火墙,安全组维护不了,做多vpc限制尚可。

A14:安全组的维护工作量不小。安全组开通没有标准规范,大致就是研发或业务找到运维,运维就给开了,要不就是开放的范围太大,没有一个规范。目前大部分企业也是这样相对比较粗放的管理。

A15:安全组基本可以类比于传统区域隔离吧,一般是分类考虑,有些区域之间是可以申请就开通,有些敏感区域是需要单独评估后特殊审批开通,特别是在违反安全组创建管控原则的时候,不会一概而论

Q:如果把一个子公司作为一个租户,把每个分公司作为安全组(或者一套系统作为一个安全组),dnsntp这类服务作为全局策略通的,这样管理相较于传统架构是不是会更清晰呢?横向攻击的风险会小一些,而且也容易监测到。

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:做到双敲的,人家的运维自动化水平必然很高了,双敲只是解决一些手工问题。
  1. 能不能把corp account转换成service account去执行dba所需要的操作。
  2. 能不能登陆堡垒之后,再使用生产账号去执行dba所需的操作。
  3. 能不能对2中的dba role做just in time管理。
  4. 如果3不能实现,等不能把dba所需要的entitlement按照root和非root做角色分割。
  5. 能不能对角色所包涵的entitlement做白名单管理。
  6. 能不能在bastion上做session管理,在目标服务器上做日志收集。
  7. dba的每一个操作能不能符合变更管理流程。

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不规范,很容易被拦截的。

A15:可以考虑 
  • 远程管理端口,限制只能通过堡垒机
  • OS账号是主机管理员负责,不是DBA管理
  • 个人不能直接持有和使用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:堡垒机能实时监控。账号登录双因子,资产访问双人授权,运维过程实时监控,操作记录事后审计。这个堡垒机上都带有这样的功能,不过要人去看的话,这比较不现实。

Q:堡垒机直接对外么?

A13:拨vpn访问内网堡垒机啊。VPN给账号对外,厂商可以主动登录的,如果仅仅是协助排查问题,是没必要下这么大成本的。如果是长期进行项目开发啥的,你给他VPN,划分独立的网络区域,这没问题。得区分开场景来开放权限呀,哥哥们,不能为了方便直接一个方案覆盖虽有场景,显然是不科学的。

A14:你拉一下你的设备运行报告上,还是会有国外的地址出现 ,并不是说你封掉了,国外的地址就不出现了。封掉的都被防火墙挡住在墙外了。

A15:报告上是有,但被拒绝。没有成功的国外的流量访问VPN啥的。提供两种,并制定流程和结合edr禁用措施,有漏洞的停用,只允许用新版,逼大家用安全版本。

A16:我不敢苟同,如果是甲方主导话,建议这类的远控软件尽可能杜绝掉,因为是有其他平替且安全的软件的,edr也好,流程也罢都覆盖有限的,如果是遇到攻击,这些都可以被绕过的

A17:他是乙方厂商吧,如果是金融类的可能就直接现场了,监管都要求禁止远程维护的。像我们这种弱势甲方很依赖乙方的技术支持的。一刀切,会导致业务的运维受阻,信息部门面对使用部门的压力很大。

A18:这倒是。毕竟乙方的技术和专业性更高。如果有一个很便捷的,很稳定的远程解决方案也是可以的,我们也在测试一些零信任远程工具。安全的解决方案要不投钱,订制各种监控管理软件;要不投人,负责控制访问权限的人就得24小时standby。

A19:目前暂时外部远程选择的是视频会议的远程也能录屏控制功能,功能有限能满足基本的远程需求,如果需要比较复杂的操作那就得本地了不允许远程的。

0x2 本周精粹

金融实践群精华回顾之四-测试环境安全管理漫谈

0x3 2022年第16周运营数据

金融业企业安全建设实践群 | 第144期
本周群里共有 94 位群友参与讨论,群发言率为 20.80 %,群发言消息数为 332 条,人均发言数为 3.53 条。

企业安全建设实践群 | 第69期
本周群里共有 69 位群友参与讨论,群发言率为 20.41 %,群发言消息数为 268 条,人均发言数为 3.88 条。 

0x4 群友分享

【安全资讯】

数世咨询《API安全研究报告2022》正式发布 附下载

【安全圈】拖动文件就能触发 7-Zip 安全漏洞,波及所有版本

GB/T 20984-2022 信息安全技术 信息安全风险评估方法 正式发布

【安全管理】

浅谈攻防演练

200页幻灯片图解典型行业与省市数据法规要求(附下载)

专题研讨 | 工业领域数据安全的重点工作方向、工作内容以及如何结合当下监管要求开展工作?

--------------------------------------------------------------------------------

【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送(每周)。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球,方便大家查阅。

往期群周报:

实战攻防演习探讨:今年的演习会有哪些变化?我国需要怎样的攻防演习?越权类的攻击是否有好的检测思路?| 总第143周

突发灾难状况下单位的开发工作如何解决?安全远程办公方案暨大数据分析技术栈ELK vs clickhouse探讨| 总第142周

如何用量化指标梳理网络安全等级保护系统定级?疫情形势下怎样确保远程工作安全?算法备案与算法安全管理制度建设探讨 | 总第141周

如何进群?

如何下载群周报完整版?
请见下图:

企业上公有云,网络架构层面有无最佳实践?如何管控dba登陆到本地的操作?有无更好的方法满足远控需要?| 总第144周

原文始发于微信公众号(君哥的体历):企业上公有云,网络架构层面有无最佳实践?如何管控dba登陆到本地的操作?有无更好的方法满足远控需要?| 总第144周

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年5月2日17:21:24
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  企业上公有云,网络架构层面有无最佳实践?如何管控dba登陆到本地的操作?有无更好的方法满足远控需要?| 总第144周 http://cn-sec.com/archives/968754.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: