当前位置: 首页 > 编程笔记 >

MySQL安全策略(MySQL安全注意事项)

刘狐若
2023-03-14
本文向大家介绍MySQL安全策略(MySQL安全注意事项),包括了MySQL安全策略(MySQL安全注意事项)的使用技巧和注意事项,需要的朋友参考一下

导读

MySQL被运用于越来越多的业务中,在关键业务中对数据安全性的要求也更高,如何保证MySQL的数据安全?

数据安全如果只靠MySQL应用层面显然是不够的,是需要在多个层面来保护的,包括网络、系统、逻辑应用层、数据库层等。
下面是我们可借鉴的一些安全策略。

1、网络、系统层面

   在这个层面可以做很多的事情,我们可以把这些安全要求作为新系统安装时的标准要求,放到自动化装机方案中。

把运行MySQL的服务器放在内网中,不要启用公网;
迫不得已启用公网的话,修改sshd端口到10000以上;
设置防火墙策略,只允许信任的服务器连接sshd和MySQL端口;

修改idrac/imm密码,设置GRUB密码;

设置密码安全策略,比如要求 PASS_MIN_LEN 不低于8位,其实最好是直接用一个复杂密码做MD5之后再作为正式密码,32位长度的安全程度够高吧;

将操作日志记入syslog并且发送到远程log server上,坚决不能只存储在本地;

除了必须的账号,其他的都设为无登入权限;

尽量把运行MySQL的服务器独立出来,不要和web server、app server放一起。必须放一起的话,也要设置好权限分离,不允许web server、app server进程的属主有直接访问MySQL datadir的权限;

禁用web server层的autoindex配置;

可能的话,采用https代替http;

关键应用保持更新,避免老版本的漏洞风险;

设置nginx、php等应用服务的安全策略,禁用危险函数等;

可以考虑购买运营商提供的一些安全防护、扫描器等产品;

坚决杜绝二逼行为,把关键配置文件上传到公共网络上(如把公司项目代码放在github上作为个人项目,内含内网账号密码信息)。

2、逻辑应用层

   在这个层面,等多的是依赖运营及开发人员的安全意识,很多本可以避免的低级安全漏洞完全可以在这个层面处理掉,比如下面提到的XSS、CSRF、SQL注入等漏洞。
尽量不要在公网上使用开源的cms、blog、论坛等系统,除非做过代码安全审计,或者事先做好安全策略。这类系统一般都是黑客重点研究对象,很容易被搞;

在web server层,可以用一些安全模块,比如nginx的WAF模块;

在app server层,可以做好代码安全审计、安全扫描,防止XSS攻击、CSRF攻击、SQL注入、文件上传攻击、绕过cookie检测等安全漏洞;

应用程序中涉及账号密码的地方例如JDBC连接串配置,尽量把明文密码采用加密方式存储,再利用内部私有的解密工具进行反解密后再使用。或者可以让应用程序先用中间账号连接proxy层,再由proxy连接MySQL,避免应用层直连MySQL;

应用层启用关键日志记录,例如交易日志,方便后续对账什么的。

3、MySQL数据库层

   前面几层如果都做的不够安全的话,在这层也几乎是岌岌可危了。但我们依然可以做些事情的。

启用 safe-update 选项,避免没有 WHERE 条件的全表数据被修改;

将 binlog 的保存周期加长,便于后续的审计、审查;

应用账号只赋予SELECT、UPDATE、INSERT权限,取消DELETE权限。把需要DELETE权限的逻辑改成用UPDATE实现,避免被物理删除;

需要真正删除时,交由DBA先备份后再物理删除;

可以采用Percona的SQL审计插件,据说还有macfee的插件;

还可以采用触发器来做一些辅助功能,比如防止黑客恶意篡改数据。

4、后记

   数据安全可以做的事情很多,本文也只是罗列了一些比较简单可快速实施的方案。每个企业应有自己的安全策略规范,每一位参与者都应该心怀敬畏,努力遵守这些必要的规范,不使信息安全成为空谈。

   真正的数据安全,是靠所有人的意识安全作为支撑的,没有这个意识靠机制、制度、工具都是不靠谱。于

 类似资料:
  • Web 应用通常面临所有种类的安全问题,并且很难把所有事做的正确。 Flask 试图 为你解决这些事情中的一些,但你仍需要关心更多的问题。 跨站脚本攻击(XSS) 跨站脚本攻击的概念是在一个网站的上下文中注入任意的 HTML (以及附带的 JavaScript )。开发者需要正确地转义文本,使其不能包含任意 HTML 标签来避免 这种攻击。更多的信息请阅读维基百科上关于 Cross-Site Sc

  • Security considerations (安全注意事项) Model REST APIs 隐藏REST模型的属性 CORS 防止 XSS 漏洞 Model REST APIs 默认情况, Loopback 的 Model 会创建 一套标准的HTTP端点 (增,删,改,查)操作, 在 modelName.json 的 public 属性中指定是否公开. 如果需要隐藏 模型的 REST API

  • 主要内容:命令配置密码,手动配置密码,指令安全,端口安全,SSH代理Redis 提供了诸多安全策略,比如为了保证数据安全,提供了设置密码的功能。Redis 密码设置主要有两种方式:一种是使用 命令来设置密码;另外一种则是手动修改 Redis 的配置文件。虽然看似前者更为简单,其实两种方式各有特点。本节将对它们进行介绍。 命令配置密码 通过执行以下命令查看是否设置了密码验证: 在默认情况下 requirepass 参数值为空的,表示无需通过密码验证就可以连接到 Re

  • 在这个世界上没有绝对的安全,我们说这台服务器安全并不是说它绝对不会有安全风险,不会受到损害。只能说明该台服务器的安全可信度高,不易受到侵害。相反,如果我们说这台服务器不安全,即可信度低,则这台服务器可能是一些服务的配置有安全漏洞或没有做数据冗余。每种环境、每种应用的可信度要求是有不同的,不能一概而论,如作为企业中心数据库服务器的可信度要求就比内部WEB服务器的可信度要求高。需投入更多的资金和时间对

  • PodSecurityPolicy 类型的对象能够控制,是否可以向 Pod 发送请求,该 Pod 能够影响被应用到 Pod 和容器的 SecurityContext。 查看 Pod 安全策略建议 获取更多信息。 什么是 Pod 安全策略? Pod 安全策略 是集群级别的资源,它能够控制 Pod 运行的行为,以及它具有访问什么的能力。 PodSecurityPolicy对象定义了一组条件,指示 Po

  • 我想知道,是否有人有更多的信息,什么具体的风险,使用的Chrome驱动程序所关注的这一声明。 “如果可能,请使用无法访问敏感本地或网络数据的测试帐户运行ChromeDriver。ChromeDriver不应使用特权帐户运行。” 想知道使用特权帐户的具体风险是什么,以及是否可以采取任何预防措施来防范这些风险。 提前谢谢!