设为首页 - 加入收藏 ASP站长网(Aspzz.Cn)- 科技、建站、经验、云计算、5G、大数据,站长网!
热搜: 数据 手机 公司
当前位置: 首页 > 服务器 > 搭建环境 > Windows > 正文

拿来即用的企业级安全运维体系搭建指南(2)

发布时间:2018-09-14 22:14 所属栏目:117 来源:林伟壕
导读:堡垒机与VPN 使用堡垒机可实现运维入口统一化,也能做到集中访问控制和审计。 在登陆堡垒机时也需要拨入VPN,目前应用比较广泛的有IPSecVPN以及SSLVPN,像OpenVPN则部署维护简单、服务端较为灵活以及客户端支持丰富

堡垒机与VPN

  • 使用堡垒机可实现运维入口统一化,也能做到集中访问控制和审计。
  • 在登陆堡垒机时也需要拨入VPN,目前应用比较广泛的有IPSecVPN以及SSLVPN,像OpenVPN则部署维护简单、服务端较为灵活以及客户端支持丰富等优势目前被广泛应用。
  • 服务器ssh端口或者业务管理后台也可只对堡垒机与VPN Server开放白名单

2)基线审计与入侵检测

我认为基线审计与入侵检测是两个不同的概念,前者在于事后审计,看合不合格;后者在于事前预防与事中检测响应。在具体落地上,基线审计通常依赖堡垒机,入侵检测通常依赖安全agent。

堡垒机

通常堡垒机有访问控制、日志审计、操作行为审计、数据上传下载审计以及权限管理等功能。但系统补丁更新与应用版本更新等操作则不是堡垒机所能覆盖的。

对于堡垒机的落地,采购设备倒是其次,重点在于整合整套运维体系,对于有些年头的企业改造成本太大,而且大家也担心其性能与可用性。

安全agent

当然,前面说到的系统补丁更新与应用版本更新,都可以交给安全agent去做。入侵检测、基线审计,安全agent可全面覆盖。但因为要跑agent,通常没有愿意商用入侵检测系统跑在自己机器上的,如果自研则开发周期长,还会引起业务的担忧:服务器监控agent、数据上传agent等等之外还要再跑安全agent,万一agent崩了会不会引起雪崩?说到底,要取得产品的信任,还得自家底子够硬。

那么,什么样的解决方案才能众口皆调呢?在google提出beyondcorp之后,问题可能有了转机,那就是把使用轻量agent采集信息,把计算、分析、决策交给大数据后台。

当然,我们很难像google那样基于rpc协议去做访问控制、身份认证,那么在传统的堡垒机、vpn方案之上,结合轻量级agent,可能是一种更好的方式。

不过还是上面那句话,如果自家底子够硬,能取得大家信任,那就另当别论。

3)漏洞扫描

目前大中型企业谁没有自己的漏洞扫描器,不会开发购买商用的总行吧?但我觉得可能有个通病,就是漏洞扫描器做的太重。如果可以解放思路,或许可以尝试从扫描器的定位重新出发,在效率、覆盖面上进行选择,比如大型扫描器专门做周期长的、要求覆盖面广的扫描,而轻量级扫描器则定位于高效、定向扫描。

现在不光是waf在结合机器学习,漏洞扫描器也可以结合机器学习或者大数据分析,根据扫描日志或者已有的经验,做策略的自动生成,实现扫描规则的轻量化与精准化。

4)CI/CD安全

CI/CD是运维的重要一环。在CI/CD上出现的安全漏洞也多如牛毛。下面我们从如何安全的发布和应用部署来讨论。

敏感信息泄露

我们都知道发布代码应排除:源码文件和临时文件,如.py、.cc、*.swp(vim临时文件),上传版本管理相关的信息文件(如.svn/.git),以及打包/备份文件(如.gz/.bak)。这看起来更像是一种规范,其实不然,通过在代码分发系统增加钩子或者过滤模块,是可以提前发现敏感信息的上传的。比如代码提交了ssh私钥或者账号密码配置文件,只需要一个webhook就能检测到。实现上的成本与出问题付出的代价相比,其实不算什么。

代码或镜像的安全审计

随着Docker容器技术的广泛应用,CI/CD安全的落地更加充满希望。我们都知道,使用Docker容器需要经历编写dockerfile/docker-compose文件,docker build之后才有镜像,然后再docker pull、docker run部署服务,实际上可以结合Jenkins等CI/CD工具调CoreOS官方的Clair镜像安全审计工具进行漏洞扫描。此外,当然还有RASP等Runtime机制的动态检测机制,也有foritity或者Cobra等或商用或开源的代码审计工具,也可以结合使用。

5)认证授权

认证授权机制这块,主要分享的思路如下:

  • SSH不允许用密码登陆,必须用公钥登陆;
  • 建立个人帐号的概念,必须做到一人一个帐号,不允许多个人共用一个个人帐号;
  • 公共帐号要和个人帐号分开,不允许直接登陆;
  • 口令安全需要注意复杂度校验;
  • 无法通过网络层或应用层进行访问控制的,应增加认证授权机制;
  • RBAC:根据角色授权;
  • 最小权限原则:禁止给业务配置root/admin级别的数据库账号,根据业务需求授权相应权限;
  • 白名单机制:同时限制root/admin级别的数据库账号仅能通过白名单ip访问,如存在默认账号密码应同时删除;
  • 认证信息管理:说到Docker容器这块,目前Kubernetes提供了ConfigMap,可以用于传递认证配置路径或者其他间接变量,用于计算认证信息。也可以用Hashicorp Vault进行认证信息管理。

6)DDoS防御

DDoS防御按照网络架构,可分为云清洗或者IDC清洗两种模式,前者通过DNS或者反代将目标IP替换成云的VIP的方式引流,对应的防御流程分为:流量分析→流量采集→流量压制等几个步骤。

后者通过路由牵引模式引流,对应的防御流程分为:流量采集→流量分析→流量牵引→流量压制等几个步骤。

下面从流量采集、流量分析、流量牵引和攻击阻断与过滤简单介绍一下。

流量采集

云清洗

DNS:通常是Web服务,使用域名对外提供服务,只需要将dns A记录指向高防或者清洗VIP,或者dns cname到云清洗域名即可。

反向代理:配置反代,通常用于那些拿IP直接对外提供服务的,比如游戏。

IDC清洗

流量镜像/流量分光:这种方式要求IDC机房部署清洗或者高防集群,通过在网络设备上镜像流量或者分光拿去做异常流量检测。

流量分析

  • 数据包捕获和抓取、数据包分析、会话还原和重组:实际生产环境中建议用nDPI+PF_RING实现,当然,Intel DPDK技术也很成熟了,后者目前也越来越流行。
  • 应用层协议分析:据了解有公司使用Bro解析流量,测试结果显示峰值几十Gbps性能也还扛得住。当然,Bro也可以用PF_RING配合性能加速,也有插件可吐给Kafka分析。
  • 通过这里的流量分析识别出异常数据流,然后触发报警,进行下一步操作。

流量牵引

这个只针对IDC清洗有效,通常是清洗设备与IDC出口设备建立BGP协议,清洗设备向IDC出口下发牵引路由,那么,流往目标IP的所有流量都会被先送到清洗设备进行过滤。

攻击阻断与过滤

攻击阻断主要是黑洞路由,流量过滤主要使用适配清洗算法以及各种算法阈值,由此区分正常流量与异常流量,之后丢弃异常流量,回送正常流量。

7)数据安全

(编辑:ASP站长网)

网友评论
推荐文章
    热点阅读