运维安全下的技术体系（安全运营体系建设）

运维安全下的技术体系（安全运营体系建设）

1、访问控制

1.1、安全域划分下的网络隔离

网络层：192.168分为办公区、办公服务区与开发机网，部分隔离；10.x分为IDC物理内网、IDC虚拟内网与公有云虚拟内网，通过IGP互通，可申请端口映射外网；公网IP仅用于业务外网，开发测试环境禁止使用公网环境！系统层：装机镜像默认开启防火墙，仅开放ssh、rdp管理端口。ssh一律采用公钥登陆，禁止启用密码认证；按角色授权系统权限。应用层：数据库、缓存类应用部署在内网IP，管理接口禁止对外开放，按最小权限原则授权

1.2、统一出入口级访问控制

建设IDC级别统一入口，结合NAT网关实现出入向访问控制。

目前BATJ都有自己的企业级GW作为统一应用层入口，同时使用NAT网关走出向流量。GW的实现开源方式不少，一旦作为企业级GW仍需自研。而NAT网关，则可采购具备API功能的分布式硬件防火墙或者自研NAT网关，解决IDC内网出向流量RS直接回外网时无外网IP的问题，或者服务器直接对外发起请求的情况，然后再采用统一系统管理。目前业界多有分享，相关思路不难找到。

敏感端口访问控制

一旦有了统一的出入口，整个生产网就像办公网一样，可以对外屏蔽敏感端口访问，对内限制出向流量，在风险缓解和阻断上行之有效。

1.3、应用层访问控制

通过WAF防刷、限流是一种通用方案，如果没有WAF的可以应用的acl自行进行控制，比如nginx的limit_rate(限速)或者haproxy的acl。

1.4、堡垒机与VPN

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

1.5、基线审计与入侵检测

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

1.5.1、堡垒机

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

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

1.5.2、安全agent

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

那么，什么样的解决方案才能众口皆调呢？在google提出beyondcorp之后，问题可能有了转机，那就是把使用轻量agent采集信息，把计算、分析、决策交给大数据后台。当然，我们很难像google那样基于rpc协议去做访问控制、身份认证，那么在传统的堡垒机、vpn方案之上，结合轻量级agent，可能是一种更好的方式。当然，还是上面那句话，如果自家底子够硬，能取得大家信任，那就另当别论。

2、漏洞扫描

目前大中型企业谁没有自己的漏洞扫描器，不会开发购买商用的总行吧？但我觉得可能有个通病，就是漏洞扫描器做的太重。如果可以解放思路，或许可以尝试从扫描器的定位重新出发，在效率、覆盖面上进行选择，比如大型扫描器专门做周期长的、要求覆盖面广的扫描，而轻量级扫描器则定位于高效、定向扫描。现在不光是waf在结合机器学习，漏洞扫描器也可以结合机器学习或者大数据分析，根据扫描日志或者已有的经验，做策略的自动生成，实现扫描规则的轻量化与精准化。

3、CI/CD安全

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

3.1、敏感信息泄露

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

3.2、代码或镜像的安全审计

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

4、认证授权

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

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。