运维是必需品,安全是奢侈品

安全 应用安全
安全,一直是大部分公司想引起重视,又不引起重视的存在。想引起重视的原因是安全问题不断出现,经常会听到某某云厂商的服务器不可用了,某某公司的服务器被入侵了,某某公司的数据库被前员工删了,层出不穷的安全问题让安全人员防不胜防。

最近在某群听到这句话:运维是必需品,安全是奢侈品。

安全,一直是大部分公司想引起重视,又不引起重视的存在。想引起重视的原因是安全问题不断出现,经常会听到某某云厂商的服务器不可用了,某某公司的服务器被入侵了,某某公司的数据库被前员工删了,层出不穷的安全问题让安全人员防不胜防。

就算如此,大部分公司还是不引起重视。我觉得主要有以下三种原因:

(1)公司并没有专业的安全人员,没有较强的安全意识,再加上没有发生太大的安全事故

(2)安全==花钱,要做安全,就要做好花钱的准备,并且价格不菲

(3)侥幸心里

我有段时间也曾抱着侥幸心里:这类事情应该不会发生在我身上。

但是,侥幸往往会在未来的某一时刻发生。今年,我负责的环境就发生了两次安全事故,虽然没有造成损失,但是给我敲了警钟。

(1)第一个安全事故是一台 Windows 系统被入侵,植入后门,我在《服务器中毒了——菜是原罪》中有阐述整个过程。

(2)第二个安全事故是一台 Linux 服务器被黑客利用应用软件漏洞植入恶意脚本进行挖矿

两件事情虽然都在第一时间去解决了,但是现在想想还是后背发凉,如果我这些服务器和其他服务器开了免密,那后果将是怎样的?

所幸的是,虽然我并没有买其他的安全产品,但是基础的安全规范还是做了,并没有造成太大的影响。

鉴于个人的能力水平有限,我总结整理了下面几个安全规范:

  • 端口安全
  • 系统安全
  • 应用安全
  • 网络安全
  • 数据安全

端口安全

现在的应用基本都是 TCP/IP 形式进行通信,如果想从外面环境进行访问,就需要放开相应的端口和 IP,比如常用的 HTTP/HTTPS 端口,SSH 端口,RDP 端口等,为了安全,我会遵从以下原则:

  • 除了 80 和 443 端口,都不对外开放
  • 远程维护端口要开白名单
  • 能用 443 的尽量不使用 80

如果是普通的服务器,可以使用 iptables 进行规则制定,如果是云服务器,可以通过云安全组进行访问控制。

系统安全

如果按着等保 3 级的标准,系统安全要做的就比较多,比如要开启防火墙,要备份审计日志,要配置各种策略。我一般只做下面几种:

  • 登录/密码管理
  • 漏洞管理
  • 基线检查

登录/密码管理

日常的服务器维护需要我们登录到目标服务器进行操作,那么就会涉及到密码、密钥等问题,我一般会遵从以下原则:

  • 提升密码复杂度
  • 设置密码失效时间
  • 定期修改密码
  • 设置密码重试次数
  • 检查系统是否存在空密码
  • 禁止空密码登录
  • 建议使用密钥进行登录管理
  • 通过堡垒机来做访问控制

漏洞管理

“漏洞是修不完的,我们只能查漏补缺”。

大部分公司现在都是以开源为主,而且大部分公司都是借助开源软件构造自己的业务体系,并没有对这些开源软件做太多的安全质量把控,以至于很多安全问题都是开源软件引起的。而且现在很多软件供应商对外售卖的商业软件中也大量采用了开源软件,但是安全责任并没有从开源代码提供者转移到软件供应商,这就导致最终还是由用户来承担了软件漏洞的安全风险。

就拿 CentOS 系统而言,企业会在服务器上安装各种软件,比如 ssh、mysql、redis 等,而这些应用软件又会有许多漏洞,这就导致我们的系统就像一个筛子:漏洞百出。如果被用心之人利用,损失将不可估量。

为此,我们一定要经常对系统进行漏洞扫描和修复,切记抱着侥幸心里。

如果你常用云,就算不买安全产品,它们也会提供基础的漏洞扫描能力,但是不会帮你修复,不然就要额外收费了。我们可以借助它把漏洞整理出来,自己修复。

基线检查

基线检查是一个日常检查维护,主要检查以下问题:

  • 弱口令
  • 账号权限
  • 身份鉴别
  • 密码策略
  • 访问控制
  • 安全审计
  • 入侵防范

安全并不是一劳永逸的事情,它需要每时每刻都投入心血、时间,而基线检查可以有效的指出安全问题,方便进行安全加固。

条件允许,建议购买商业的软件。退而求其次,就只能去找一些开源的软件了,比如百度推出的 OpenRASP。

应用安全

应用是业务的基石,应用是业务的载体。如果应用出问题,业务也不远了。

而且,现在很多开放人员都只关注业务实现与否,并不太关注应用的安全,这就会导致:

  • 在开发的过程中可能引入了有漏洞的组件
  • 涉及的用户密码没有做加密处理
  • 把用户密码直接放代码中,然后上传到公开仓库中

我就遇到过某开发人员将代码放到 Github,而里面有阿里云 OSS 的密钥,这就直接导致密钥泄漏。幸亏阿里在这方面的扫描能力很足,很快就发现并告警处理。

在应用安全这块,主要关注以下问题:

  • 应用漏洞扫描
  • 网站后门
  • 密钥泄漏
  • 入侵检测

这类基本需要借助商业软件来完成,比如 WAF。

网络安全

买买买。重要的事情说三遍。

网络防御这块,除了买,好像没什么其他的办法,比如 DDoS。

当然,除了 DDoS 这类攻击外,暴力破解也是常有的事,如果不嫌麻烦,可以自己去封禁 IP,其结果是真麻烦。

所以,最终都要以 RMB 破万法。

数据安全

数据安全牵扯的就比较多,常规主要以下几种:

  • 防止 SQL 注入
  • 敏感数据脱敏
  • 数据库审计
  • 访问控制
  • 备份冗余

这里以数据库为例,我们主要按以下规则进行处理:

  • 使用数据库堡垒机,所有操作都通过数据库堡垒机进行
  • 原则上不开放读写权限给个人用户
  • 应用建议一个应用一个账号原则
  • 要对敏感数据进行脱敏处理

最后

大家有没有发现,安全拼到最后都是 RMB,当 RMB 都不能解决的时候,就拼人脉了。

道路千万条,

安全第一条。

操作不规范,

运维两行泪。

责任编辑:武晓燕 来源: 运维开发故事
相关推荐

2016-09-19 17:37:20

2022-08-07 23:44:01

元宇宙奢侈品数字化转型

2011-07-06 10:10:18

云计算SOA

2010-01-26 13:54:47

多层交换技术

2020-07-28 10:31:22

5G网络技术

2016-11-14 14:53:25

大数据奢侈品消费金融

2011-09-16 10:39:52

云计算

2011-11-11 19:21:32

微软MSN

2010-09-30 15:23:32

DB2查询巡视器

2023-10-10 13:50:00

AI研究

2023-07-11 16:17:49

2021-07-26 13:27:39

数字韧性员工团队CIO

2020-12-21 20:46:07

奢侈品人工智能AR

2019-12-27 22:37:06

物联网大数据智能工厂

2022-04-13 09:33:33

疫情物联网IOT

2012-10-12 09:33:52

移动宽带宽带接入

2022-11-08 14:51:09

2017-05-12 15:17:01

互联网

2023-12-26 14:50:07

2010-01-18 10:49:53

点赞
收藏

51CTO技术栈公众号