企业级运维安全体系搭建指南

这篇文章，我们将详细讲解如何解决问题。从问题出发，通过修复或培养良好的运维安全习惯，构建完整的运维安全技术体系。 1。养成良好的运维安全习惯

想要解决运维安全问题，首先要养成良好的运维安全习惯。这包括很多方面的实践，比如：

端口开放

• 默认内网或本地监控；
• 如果需要监控所有外部网络，可以添加iptables、密码和acl。 ？一种恢复标准 iptables 的方法。

权限管理

• 使用puppet、ansible或saltstack等集群管理工具统一管理操作系统权限；
• 临时需要高级权限时手动添加定时回收，量大时使用自动配置。

脚本安全

• 验证变量，尤其是高风险操作；
• 原则上不要授权sudo密码，也不要给脚本授予666权限。

密钥管理

• 不要让你的ssh私钥离开你的办公室电脑；
• 听取 IT 人员的意见并定期更改您的公司或域密码；
• 配置与代码分离的原因之一是：账号密码不能写在代码中。

服务管理

• 如果不用root也能启动，最好不要用root；
• 请勿将服务根目录放在您的主目录中。

代码管理

• 禁止将工作代码上传到github！ ！ ！
• 仔细学习如何使用git/svn等版本控制工具；
• 定义您的 .gitignore，特别是删除您的 .DS_Store。

选择应用程序

• 安全性是选择应用程序时的一个重要因素；
• 不要使用在修补漏洞和编码安全方面不太活跃的开源软件，无论它多么容易使用。

关注应用程序的安全配置文档

• 一般应用程序的官方文档都会包含安全配置的章节。部署时，需要按照最佳实践一步步配置安全部分，而不是问题太大就直接跳过。

安全体系是一个很大的名词。从流程规范到技术架构，这篇文章都没能讲清楚。因此，下面我们要讨论的企业级运维保障体系，将对我接触过或者已经实施过的解决方案进行一个总体的介绍。至于具体的实现，我后面会写一篇文章详细讨论。

首先，整个运维安全体系实际上是企业安全体系的一部分，所以总体思路并没有太大的不同。其次，运维安全更注重“运维”，业务风控、反欺诈、应用反编译等方面并未考虑。我们来看看一个完整的企业级运维安全体系是什么样的。 1。流程规范

操作和维护规范就像人类的法律。 “人人生而自由，却始终处于枷锁之中。”这套规范不仅约束和指导运维人员，也约束和指导开发和测试人员，以及围绕生产活动的所有参与者。

培训

这里的培训并不代替安全部门对员工进行的安全培训，也不代替对开发人员、测试人员的研发安全培训，而只是针对运维人员的意识培训和技术培训。例如，本文前面提到的安全不良习惯和安全习惯就可以作为意识培训的蓝本。后面将要讨论的技术体系可以作为技术培训的基础。此类培训可以包含在校招培训或沙龙部的讲座中。

审批+审查+评估

首先，检查或审批不是为了阻止业务发展，更不是为了发现问题，而是为了限制或避免人为因素导致过程中忽视安全。因此，权限请求必须经过主管批准，功能必须由安全人员或同组同事开放，并且功能必须经过安全人员评估和测试才能启动。

当然，实现方式可以灵活多样，比如标准浏览，可以根据产品或业务的需要启用审批和审核机制，然后将评估机制嵌入到业务上线流程中。审核通过后才能上线。对于安全部门比较强的公司或者是非常重视安全的公司来说，我相信上述机制都得到了很好的落实。

安全报告

安全的可视化、数字化非常重要，是体现安全价值的形式之一。与企业SRC或安全部门对接后，可以获得与运维相关的漏洞和安全事件统计，然后根据内部需求进行二次处理，定期向运维人员或部门负责人发送报告。或也由技术负责人进行审查，了解运行维护的安全情况。这种方法通常可以让他们看到安全缺陷，因此任何人都可以从数据中获得警告或引起上级的注意，从而获得更多资源或支持自上而下的安全法规的实施。

工艺规范的落实包括但不限于以上几点，但我认为这几点是最重要的。？ x分为IDC物理内网、IDC虚拟内网和公有云虚拟内网。通过IGP互通，可以请求端口映射到外部网络；公网IP仅用于业务外网，开发测试环境禁止使用公网环境！

入口和出口统一访问控制

• 构建IDC级统一入口，并与NAT网关结合，实现入口和出口控制

目前BATJ有自己的企业级GW作为统一入口到应用层并使用 NAT 网关进行传出流量。 。 GW的开源实现方式有很多种。当成为企业级GW的时候，他还是要自己开发。关于NAT网关，可以购买具有API功能的分布式硬件防火墙或者自研的NAT网关，解决IDC RS内网没有外网IP的出站流量直接返回外网的问题，或者服务器直接向外界发起请求，然后采用统一系统管理的情况。这些天这个行业的分享很多，不难找到相关的想法。

• 灵敏的端口访问控制

一旦有了统一的输入输出，整个生产网络就像一个办公网络。对外保护敏感端口访问，对内限制出站流量，有效降低风险、拦截攻击。

应用层访问控制

常见的解决方案是通过WAF进行刷保护和限流。如果没有可用的WAF，您可以使用ACL自行控制，例如nginx的limit_rate或haproxy的acl。

堡垒主机与VPN

• 使用堡垒主机可以统一运维的投入，还可以实现集中的访问控制和审计。
• 登录堡垒主机时还需要连接到VPN。目前应用较为广泛的有IPSecVPN和SSLVPN。 OpenVPN因其易于部署和维护、灵活的服务器和丰富的客户端支持而目前得到广泛应用。
• Ssh服务器端口或者企业管理后台也可以只针对堡垒主机和VPN服务器开放白名单

基本审计和入侵检测

我认为基本审计和入侵检测是两个不同的概念，前者是然后审计它关于合规和取消资格；第二个涉及事前预防以及事件期间的发现和响应。在具体实现中，基本审计通常依赖于堡垒主机，入侵检测通常依赖于安全代理。

堡垒主机

堡垒主机通常具有访问控制、协议审计、操作行为审计、数据上传下载审计、权限管理等功能。但系统补丁更新、应用版本更新等操作不属于堡垒引擎的覆盖范围。

堡垒机的实现，技术的购买是第二要务。重点是整个运维系统的集成。对于一些公司来说，近年来转型成本太高，大家都担心它的性能和可用性。

安全代理

当然，上面提到的系统补丁更新和应用程序版本更新可以交给安全代理。入侵检测、基本审计和安全代理可以提供全面的覆盖。然而，由于需要运行代理，通常没有人愿意在自己的计算机上运行商业入侵检测系统。如果自己开发的话，开发周期会很长，而且还会引起业务担忧：除了服务器监控代理、数据上传代理等之外，还必须运行安全代理，如果代理崩溃了，会引起雪崩吗？最终，如果您想获得对产品的信心，您需要拥有坚实的基础。

那么，大家会同意什么解决方案呢？ Google在公司外部提出后，问题可以改变，即使用轻量级代理来收集信息，并将计算、分析和决策传递给大数据后端。

当然，我们很难像Google那样做基于RPC的访问控制和身份认证，所以将传统堡垒机和轻量级代理VPN解决方案结合起来可能是更好的方式。

不过我上面也说了，如果你的根基够扎实，能够得到大家的信任，那就另当别论了。

漏洞扫描

目前哪个大中型企业没有自己的漏洞扫描器？他们不会开发和购买营业场所，是吗？不过，我认为这里可能存在一个共同的问题，那就是漏洞扫描器的要求太高了。如果你能解放思想，可以尝试从扫描仪的位置开始，从效率和覆盖范围上进行选择。例如，大型扫描仪专门用于需要广泛覆盖范围的长周期扫描，而轻型扫描仪则定位于高效率。 ，定向扫描。

现在不仅WAF结合了机器学习，漏洞扫描器还可以与机器学习或大数据分析相结合，根据扫描日志或现有经验自动生成策略，从而实现简单、准确的扫描规则。

CI/CD 安全

CI/CD 是运维的重要组成部分。 CI/CD 还存在许多安全漏洞。我们来讨论一下如何安全地发布和部署应用程序。

敏感信息泄露

我们都知道发布代码应该排除：源代码文件和.py、.cc、*.swp等临时文件（vim临时文件）、上传与版本控制相关的信息文件（例如 .svn /.git）和包/备份文件（例如 .gz/.bak）。它看起来更像是常态，但事实并非如此。通过在代码分发系统中添加钩子或过滤模块，可以提前检测敏感信息的上传。例如，如果代码发送 SSH 私钥或帐户和密码配置文件，则只需要 webhook 即可检测到。与问题的成本相比，实施的成本实际上不算什么。

代码或镜像安全审计

随着Docker容器技术的广泛使用，CI/CD安全的实施前景更加广阔。我们都知道使用Docker容器需要编写dockerfile/docker-compose文件。该镜像仅在构建 docker 然后运行 ​​docker pull 和 docker 部署服务后才可用。 CoreOS 的官方 Clair 镜像实际上可以使用 Jenkins 等 CI/CD 工具进行修改。安全审核工具执行漏洞扫描。另外，RASP等运行时机制的动态检测机制，以及fority或Cobra等商业或开源代码审计工具，也可以组合使用，这是理所当然的。

认证与授权

关于认证与授权机制，分享的主要思路如下：

• SSH不允许密码登录，必须使用公钥登录；
• 建立个人账户的概念必须是每个个人账户一个，多人不得共用一个个人账户；
• 公共账号必须与个人账号分开，不允许直接登录；
• 密码安全需要复杂度验证；
• 无法通过网络层或应用层进行访问控制，需要添加认证和授权机制；
• RBAC：基于角色的授权；
• 最小权限原则：禁止为企业配置root/admin级别数据库账户，根据业务需要授权相关权限；机制
• 白名单机制：同时限制root/admin级别的数据库账号只能通过IP白名单访问。若有默认账户密码，应同时删除；
• 管理认证信息：对于Docker容器来说，Kubernetes目前提供了一个ConfigMap，可以用来传递认证配置路径或其他间接变量来计算认证信息。您还可以使用 Hashicorp Vault 来管理身份验证信息。

DDoS防御

DDoS防御根据网络架构可以分为云清洗或IDC清洗两种模式。第一种方法是通过 DNS 或反向生成将目标 IP 地址替换为云 VIP 地址来转移流量。相应的防御流程分为：流量分析→流量收集→流量抑制等步骤。

后者通过路由牵引方式进行流量分流，相应的防御流程分为几个步骤：流量采集→流量分析→流量牵引→流量抑制。

下面简单介绍一下流量收集、流量分析、流量牵引、阻塞和过滤攻击。

流量采集

• 云DNS清理：通常是使用域名对外提供服务的Web服务。您只需将DNS记录指向高防或清洗VIP或将DNS cname指向云清洗域名即可。

  反向代理：配置反向代理服务器，通常用于那些使用IP直接向外界提供服务的人，比如游戏。

• 流量清洗IDC镜像/流量分流：该方式需要IDC机房部署清洗或高防集群，通过对网络设备进行流量镜像或流量分流来检测异常流量。

流量分析

• 数据包捕获与捕获、数据包分析、会话恢复与重组：在实际生产环境中，建议使用nDPI+PF_RING来实现。当然，Intel DPDK技术也非常先进，而且后者现在也越来越流行。它变得越来越受欢迎。
• 应用层协议分析：据了解，该公司使用Bro进行流量分析，测试结果显示，几十Gbps的峰值性能仍然可以承受。当然，Bro也可以使用PF_RING来配合性能加速，并且有插件可以将数据吐到Kafka中进行分析。
• 这里通过流量分析识别出异常数据流，然后触发告警并进行下一步。

流量分流

仅适用于IDC清洗。通常，洗涤器将与IDC出口设备建立BGP协议，并且洗涤器将向IDC出口发出牵引路径。那么所有流向目标IP的流量都会被首先发送。进入净化装置进行过滤。

攻击拦截与过滤

攻击拦截主要是黑洞路由。流量过滤主要利用自适应清洗算法和不同的算法阈值来区分正常流量和异常流量。然后异常流量被丢弃，正常流量被发回。 。

数据安全

在数据安全方面，最好与业务发展和安全一起规划和设计解决方案。运维安全通常可以指访问控制、认证授权、备份、加密等。

• 访问控制 控制： 区分数据敏感度，实施不同级别的访问控制。但必须严格遵守将db放在内网的原则。
• 认证授权：基于RBAC的授权。如果是比较成熟的数据库或者大数据集群，还可以采用动态计算权限，只在需要的时候动态下发授权权限，用完后回收。
• 备份：本地备份和远程备份，业务需求决定备份是否需要加密。
• 加密传输：通道安全通常使用https来实现。关于 https 有两个最好的事情 -

  a。获取证书：对于开发测试环境或者非必要业务，可以使用免费的SSL证书Let's Encrypt。该方案支持全自动签发和续订，通过交叉证书实现大部分需求。客户端环境的兼容性。此外，您还可以使用 https://www.ssllabs.com/ 进行站点安全扫描和兼容性测试。

  b。证书部署：如果遇到站点访问CDN时需要将证书私钥插入CDN的问题，或者TLS链路消耗服务器性能，可能影响业务的情况，可以使用cloudflare的keyless解决方案将计算压力转移到专用服务器。集群可以利用Intel QAT硬件加速，进行有针对性的协议级优化，实现压力转移和性能优化。

  存储：一般在开发或企业安全层面考虑，但如果是作为运维安全来做，通常只在文件系统层面进行加密，例如使用企业级的ecryptfs方案。

• 脱敏：开发人员和测试人员需要从备份数据或日志中检索数据以供其他用途。这个时候就一定要注意麻木了。常用的方法有替换、添加和删除字段、删除元素、删除相关性等。

安全事件应急响应

以下是响应安全事件紧急情况的一般流程。显然，运维人员和安全人员要应对大量的工作。其中，需要注意：

• 保护站点，备份数据；
• 联系产品评估影响程度；
• 确认是否可以先屏蔽iptables来限制外网访问；
• 确认受感染计算机的基本审计和入侵检测状态；
• 确认是否存在数据泄露或者计算机是否被root、异常用户、异常进程、添加了crontab、打开了异常端口；
• 确认被感染电脑是否有内网IP，并查看监控是否被利用作为跳板；
• 创建运维工单，监控和控制漏洞的发生和解决。

运维安全从运维开始。在日常工作中，我与 IT、安全和网络部门有着非常密切的关系。与兄弟分会保持良好的沟通和信息共享非常重要。下面我们将探讨与他们合作的可能性。

与IT部门

主要是办公网络安全，特别是NAC：网络接入系统，通常是IT维护，但由于历史原因或者技术支持需要，NAC可能需要运维安全人员的技术支持。例如上面提到的VPN服务。

一个安全部门

运维保障是安全的一个部门，不属于安全部门管理，但与安全部门的联系极其密切。可以说，无论是业务安全还是运维安全都是“站在巨人身上”。

• 安全部门提供DDoS防御系统等基础设施和SRC等对外统一接口；
• 安全部门提供 SDL 支持。运维和产品部门比安全部门联系更紧密。很多时候，安全首先是运维需求，通过运维保障来支撑安全培训、安全架构设计与实施、渗透测试等任务的情况并不少见；
• 运维与此对应，安全也可以根据运维部门和产品的具体情况，改进漏洞操作，同时支持有效的漏洞修复。分开了很长一段时间，即使分开之后，两人合作的次数也是最多的。为了运维的安全，网络部门在访问控制、DDoS防御等方面的支持是非常必要的。
  • 访问控制如实现网络隔离、输入输出统一控制等。
  • DDoS防御网络开放、数据流量收集和数据共享，包括IP属性信息。

  我们从运维安全的理念出发，强调了运维安全的困境导致我们走到了这一步，我们也从安全意识和基础设施建设的角度分析了造成困境的原因，并然后讨论了这个问题，希望通过运维安全意识来培育、运维安全规范，构建运维安全技术体系，以保证整个安全体系的有效运行。运维，保障业务发展。