linux系统的应用领域

Linux 是一个开源的操作系统，广泛应用于服务器、移动设备、嵌入式系统等领域。以下是一些 Linux 应用场景：

服务器：Linux 作为服务器操作系统的使用非常普遍，因为它是一个稳定、安全、可靠的操作系统，而且很容易定制和管理。许多企业使用 Linux 作为服务器操作系统，例如谷歌、Facebook、Twitter、亚马逊等。

移动设备：Linux 也可以运行在移动设备上，例如 Android 操作系统就是基于 Linux 内核的，目前在智能手机和平板电脑等设备上应用广泛。

嵌入式系统：Linux 内核非常灵活，可以运行在各种嵌入式设备上，例如智能家居、机器人、工业自动化等领域。

虚拟化：Linux 也被广泛应用于虚拟化技术中，例如容器技术 Docker 就是基于 Linux 的。

桌面应用：虽然 Linux 在桌面应用方面的使用比较少，但是也有许多人选择使用 Linux 作为桌面操作系统，因为它开源、免费、安全、可定制等特点。

开发和科学计算：Linux 提供了丰富的开发和科学计算工具，例如编译器、文本编辑器、调试器、数据分析工具等，因此在开发和科学计算领域也得到了广泛应用。

1） Linux运维岗位及工作内容

互联网Linux运维工程师是一个融合多学科(网络、系统、开发、数据库、安全、存储等)的综合性技术岗位，甚至还需要沟通、为人处世、培训、销售、管理等非技术能力，这给运维工程师提供了一个广阔的发展空间。

2) Linux运维工程师岗位职责

一般从企业入门到中级Linux运维工程师的工作大致有：挑选IDC机房及带宽、购买物理服务器或云服务、购买及使用CDN服务、搭建部署程序开发及用户的访问系统环境(例如:网站运行环境)、对数据进行备份及恢复、处理网站运行中的各种故障（例如：硬件故障、软件故障、服务故障、数据损坏及丢失等）、对网站的故障进行监控、解决网站运行的潜在安全问题、开发自动化脚本程序提高工作效率、规划网站架构、程序发布流程和规范，制定运维工作制度和规范、配合开发人员部署及调试产品研发需要的测试环境、代码发布等工作需求，公司如果较小可能还会兼职网管、网络工程师、数据库管理员、安全工程师、技术支持等职责。

涉及到的Linux平台上的运维工具有：Linux系统,Linux基础命令,Nginx,Apache,MySQL,PHP,Tomcat,Lvs,Keepalived,SSH,Ansible,Rsync,NFS,Inotify,Sersync,Drbd,PPTP,Open***,NTP,Kickstart/Cobbler,KVM,OpenStack,Docker,，K8S，Mongodb,Redis,Memcached,Iptables,SVN,GIT,Jenkins,网络基础,Shell/Python开发基础等，除此之外还可能涉及到交换机、路由器、存储、安全、开发等知识。

运维工程师还包括一些低端的岗位，例：网络管理员、监控运维、IDC运维，值班运维

职业发展方向：Linux运维工程师、系统架构师、数据库工程师、运维开发工程师、系统网络安全工程师、运维经理、运维总监

3) Linux中级运维工程师应用软件阶段。

Linux系统,Linux基础命令,Nginx,Apache,MySQL,PHP,Tomcat,Lvs,Keepalived,SSH,Ansible,Rsync,NFS,Inotify,Sersync,Drbd,PPTP,Open***,NTP,Kickstart/Cobbler,KVM,OpenStack,Docker,Mongodb,Redis,Memcached,Iptables,SVN,GIT,Jenkins,网络基础,Shell/Python开发基础

4)Linux运维架构师岗位职责

运维架构师是运维工程师的高级阶段，并没有明确的岗位界限区分，运维架构师一般来说是除了对运维工程师应用的开源工具熟练掌握之外，更多的是用思想来运维了，即DevOps的落地，各种企业运行过程中的解决方案提出和执行，例如：根据公司的现状可以设计各类运维解决方案的能力：

1、自动化代码上线（SVN/GIT+Jenkins+MVN）解决方案；

2、云计算部署架构及Docker微服务架构方案；

3、服务自动化扩容方案（KVM/OpenStack/Docker+Ansible+Zabbix）；

4、10万并发的网站架构、秒杀系统的架构及解决发你个案；

5、多IDC机房互联方案、全网数据备份解决方案、账号统一认证方案；

6、数据库、存储及各重要服务节点的集群和高可用方案。

7、各网络服务的极端优化方案、服务解耦/拆分。

8、运维流程、制度、规范等的建设和推行。

9、沟通能力、培训能力、项目管理、业务需求分析及落地执行力等。

这里仅举几个例子，实际工作中会有更多，运维架构师的工作，其实就是解决企业中的用户访问量不断增大带来的痛点，最终达到高效、优质的为客户提供网站及业务服务。

总的来说：Linux运维架构师更多的是根据企业日益增长的访问量需求，利用若干运维工具组合加上经验思想，形成解决业务需求方案的阶段，当然也不排除对运维工具进行二次开发以及可视化展示运维数据的阶段（开发软件平台），这个阶段涉及的工具会非常多，几乎市面好用的开源工具都在备选之列，在一线城市互联网公司的薪资范围15000-50000/月。

职业方向：高级数据库工程师、运维开发工程师、运维经理、运维总监、技术总监

运维架构师：将多个工具组合，加上思想经验，形成方案，用思想和经验赚钱的阶段。

技术的提升仅是量的积累，思想的提升才是质的飞跃！——老男孩

5)数据库运维工程师

众所周知，数据几乎是所有企业的生命线，所以数据库工程师的地位和薪水一般会比普通运维工程师高一些，主要工作内容就是保证数据库数据的安全以及高效地为用户提供各种服务。工作内容主要有：数据库环境搭建、数据库优化、数据库

云计算是一种服务;虚拟化和分布式系统都是用来实现云计算的关键技术之一。

目前来讲虚拟化主要常用两个核心技术：服务器虚拟化，与应用虚拟化

目前来讲分布式系统主要用到的两个核心技术：分布式存储，与分布式计算

云计算可以理解为一种租借式的服务，即你可以对IT系统内部的原理什么都不懂，也不需要买到手，但是随时可以使用公共的IT资源为自己服务，比如baidu，比如QQ，比如163邮箱

我认为对虚拟化技术最好的定义就是可以让IT系统的物理拓扑图与逻辑拓扑图无关，即解耦

我们暂时以商用虚拟化系统vmware举例

为了实现拓扑解耦，它做的第一点就是让一台机器可以同时跑多个操作系统，即虚拟机，而且虚拟机还可以在物理机间来回转移，高可用，这样我们的操作系统就从物理机上彻底解放出来了，你可以把同一个虚拟机随时放到其他物理机上，实现了对硬件的高效资源利用，和系统的高度灵活，解除了大量人工劳动，便于实现大规模系统的方便管理，这种就是服务器虚拟化（vSphere）。

光系统分开还不行，你有时还需要各种方式访问虚拟机系统，于是你就会是用远程桌面等方式去访问这些后台的虚拟机，这种就是应用虚拟化（view）。

当然还有网络虚拟化，存储虚拟化等各种其他虚拟化技术正在慢慢成长，不过相对于前两者无论是商用还是开源，都还不太成熟，暂不讨论。

我认为对分布式系统比较合适的定义是把所有IT资源看成为一个整体来使用，而不是去独立的看某个机器某个系统，即资源池

我们暂时以开源Hadoop为例

为实现将IT资源变成整体，它要做到的第一点就是将一个巨大的文件拆开放在多个地方，你可以用一大堆很普通的计算机用网络连在用来存放这一个巨型文件，这样即使很多很小硬盘的机器也可以通过连在一起当成一个很大的存储空间来用，这种就是分布式存储（HDFS）。

光文件存放合在一起不行，计算能力也要合在一起，所以它还要满足一个任务分给多个物理机来处理，这样即便一堆老破电脑，通过这种方式连在一起，只要足够多，也能当超级计算机用，这种就使分布式计算（MapReduce）。

当然Hbase等其他的技术也在逐渐成熟，总的来讲都是为了解决建立巨型资源池需要的技术。

由此可以看出虚拟化主要是把大块拆成小块儿，分布式系统主要是把小块组合成大块儿，IT资源经过这样的揉碎再组合，变成了一个十分灵活的系统，在这几个基本技术的基础上，在通过某种调度和经营，就可以实现云计算的服务模式了。

所以，这并不是概念炒作~

vxlan和vlan区别是：

VXLAN是一种网络虚拟化技术，可以改进大型云计算在部署时的扩展问题，是对VLAN的一种扩展。VXLAN是一种功能强大的工具，可以穿透三层网络对二层进行扩展。它可通过封装流量并将其扩展到第三层网关，以此来解决VMS（虚拟内存系统）的可移植性限制，使其可以访问在外部IP子网上的服务器。

VLAN（Virtual Local Area Network）的中文名为"虚拟局域网"。

虚拟局域网（VLAN）是一组逻辑上的设备和用户，这些设备和用户并不受物理位置的限制，可以根据功能、部门及应用等因素将它们组织起来，相互之间的通信就好像它们在同一个网段中一样，由此得名虚拟局域网。

基本原理

VXLAN（Virtual eXtensible Local Area Network）是一种隧道技术，能在三层网络的基础上建立二层以太网网络隧道，从而实现跨地域的二层互连。

VXLAN采取了将原始以太网报文封装在UDP数据包里的封装格式。将原来的二层数据帧加上VXLAN头部一起封装在一个UDP数据包里。

VXLAN头部包含有一个VXLAN标识（即VNI，VXLAN Network Identifier），只有在同一个VXLAN上的虚拟机之间才能相互通信。VNI在数据包之中占24比特，故可支持1600万个VXLAN的同时存在，远多于VLAN的4094个，因此可适应大规模租户的部署。

VXLAN一般通过安装在服务器上的软件实现报文的封装与解封装，网络只要IP路由可达即可。VXLAN实现了应用与物理网络的解耦，但网络与虚拟机还是相互独立的。业界一般通过网络控制器（如SDN，Software Defined Network）实现VXLAN网络与云业务的联动。

当虚拟机发生迁移后，虚机/存储控制器会把虚拟机迁移信息通知给网络控制器，网络控制器根据虚拟机迁移的新位置，重新调整网络配置，从而实现网络与云业务的联动。也就是说，物理网络可以是传统的三层IP网络，路由可达即可。

虚拟机可跨三层IP网络远距离迁移，不再受限于二层技术。物理网络也无需允许所有VLAN通过。接入交换机需要学习的MAC地址的数量也大大减少，削弱了网络设备MAC地址表项规格对虚拟机规模的约束。

1 概述

我们在考虑MySQL数据库的高可用的架构时，主要要考虑如下几方面：

如果数据库发生了宕机或者意外中断等故障，能尽快恢复数据库的可用性，尽可能的减少停机时间，保证业务不会因为数据库的故障而中断。

用作备份、只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致。

当业务发生数据库切换时，切换前后的数据库内容应当一致，不会因为数据缺失或者数据不一致而影响业务。

关于对高可用的分级在这里我们不做详细的讨论，这里只讨论常用高可用方案的优缺点以及高可用方案的选型。

2 高可用方案

21 主从或主主半同步复制

使用双节点数据库，搭建单向或者双向的半同步复制。在57以后的版本中，由于lossless replication、logical多线程复制等一些列新特性的引入，使得MySQL原生半同步复制更加可靠。

常见架构如下：

通常会和proxy、keepalived等第三方软件同时使用，即可以用来监控数据库的 健康 ，又可以执行一系列管理命令。如果主库发生故障，切换到备库后仍然可以继续使用数据库。

优点：

架构比较简单，使用原生半同步复制作为数据同步的依据；

双节点，没有主机宕机后的选主问题，直接切换即可；

双节点，需求资源少，部署简单；

缺点：

完全依赖于半同步复制，如果半同步复制退化为异步复制，数据一致性无法得到保证；

需要额外考虑haproxy、keepalived的高可用机制。

22 半同步复制优化

半同步复制机制是可靠的。如果半同步复制一直是生效的，那么便可以认为数据是一致的。但是由于网络波动等一些客观原因，导致半同步复制发生超时而切换为异步复制，那么这时便不能保证数据的一致性。所以尽可能的保证半同步复制，便可提高数据的一致性。

该方案同样使用双节点架构，但是在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。

可参考的优化方案如下：

221 双通道复制

半同步复制由于发生超时后，复制断开，当再次建立起复制时，同时建立两条通道，其中一条半同步复制通道从当前位置开始复制，保证从机知道当前主机执行的进度。另外一条异步复制通道开始追补从机落后的数据。当异步复制通道追赶到半同步复制的起始位置时，恢复半同步复制。

222 binlog文件服务器

搭建两条半同步复制通道，其中连接文件服务器的半同步通道正常情况下不启用，当主从的半同步复制发生网络问题退化后，启动与文件服务器的半同步复制通道。当主从半同步复制恢复后，关闭与文件服务器的半同步复制通道。

优点：

双节点，需求资源少，部署简单；

架构简单，没有选主的问题，直接切换即可;

相比于原生复制，优化后的半同步复制更能保证数据的一致性。

缺点：

需要修改内核源码或者使用mysql通信协议。需要对源码有一定的了解，并能做一定程度的二次开发。

依旧依赖于半同步复制，没有从根本上解决数据一致性问题。

23 高可用架构优化

将双节点数据库扩展到多节点数据库，或者多节点数据库集群。可以根据自己的需要选择一主两从、一主多从或者多主多从的集群。

由于半同步复制，存在接收到一个从机的成功应答即认为半同步复制成功的特性，所以多从半同步复制的可靠性要优于单从半同步复制的可靠性。并且多节点同时宕机的几率也要小于单节点宕机的几率，所以多节点架构在一定程度上可以认为高可用性是好于双节点架构。

但是由于数据库数量较多，所以需要数据库管理软件来保证数据库的可维护性。可以选择MMM、MHA或者各个版本的proxy等等。常见方案如下：

231 MHA+多节点集群

MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。

MHA Node运行在每台MySQL服务器上，主要作用是切换时处理二进制日志，确保切换尽量少丢数据。

MHA也可以扩展到如下的多节点集群：

优点：

可以进行故障的自动检测和转移;

可扩展性较好，可以根据需要扩展MySQL的节点数量和结构;

相比于双节点的MySQL复制，三节点/多节点的MySQL发生不可用的概率更低

缺点：

至少需要三节点，相对于双节点需要更多的资源;

逻辑较为复杂，发生故障后排查问题，定位问题更加困难;

数据一致性仍然靠原生半同步复制保证，仍然存在数据不一致的风险;

可能因为网络分区发生脑裂现象;

232 zookeeper+proxy

Zookeeper使用分布式算法保证集群数据的一致性，使用zookeeper可以有效的保证proxy的高可用性，可以较好的避免网络分区现象的产生。

优点：

较好的保证了整个系统的高可用性，包括proxy、MySQL;

扩展性较好，可以扩展为大规模集群;

缺点：

数据一致性仍然依赖于原生的mysql半同步复制;

引入zk，整个系统的逻辑变得更加复杂;

24 共享存储

共享存储实现了数据库服务器和存储设备的解耦，不同数据库之间的数据同步不再依赖于MySQL的原生复制功能，而是通过磁盘数据同步的手段，来保证数据的一致性。

241 SAN共享储存

SAN的概念是允许存储设备和处理器（服务器）之间建立直接的高速网络（与LAN相比）连接，通过这种连接实现数据的集中式存储。常用架构如下：

使用共享存储时，MySQL服务器能够正常挂载文件系统并操作，如果主库发生宕机，备库可以挂载相同的文件系统，保证主库和备库使用相同的数据。

优点：

两节点即可，部署简单，切换逻辑简单；

很好的保证数据的强一致性；

不会因为MySQL的逻辑错误发生数据不一致的情况；

缺点：

需要考虑共享存储的高可用；

价格昂贵；

242 DRBD磁盘复制

DRBD是一种基于软件、基于网络的块复制存储解决方案，主要用于对服务器之间的磁盘、分区、逻辑卷等进行数据镜像，当用户将数据写入本地磁盘时，还会将数据发送到网络中另一台主机的磁盘上，这样的本地主机(主节点)与远程主机(备节点)的数据就可以保证实时同步。常用架构如下：

当本地主机出现问题，远程主机上还保留着一份相同的数据，可以继续使用，保证了数据的安全。

DRBD是linux内核模块实现的快级别的同步复制技术，可以与SAN达到相同的共享存储效果。

优点：

两节点即可，部署简单，切换逻辑简单；

相比于SAN储存网络，价格低廉；

保证数据的强一致性；

缺点：

对io性能影响较大；

从库不提供读操作；

25 分布式协议

分布式协议可以很好解决数据一致性问题。比较常见的方案如下：

251 MySQL cluster

MySQL cluster是官方集群的部署方案，通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。

优点：

全部使用官方组件，不依赖于第三方软件；

可以实现数据的强一致性；

缺点：

国内使用的较少；

配置较复杂，需要使用NDB储存引擎，与MySQL常规引擎存在一定差异；

至少三节点；

252 Galera

基于Galera的MySQL高可用集群， 是多主数据同步的MySQL集群解决方案，使用简单，没有单点故障，可用性高。常见架构如下：

优点：

多主写入，无延迟复制，能保证数据强一致性；

有成熟的社区，有互联网公司在大规模的使用；

自动故障转移，自动添加、剔除节点；

缺点：

需要为原生MySQL节点打wsrep补丁

只支持innodb储存引擎

至少三节点；

253 POAXS

Paxos 算法解决的问题是一个分布式系统如何就某个值（决议）达成一致。这个算法被认为是同类算法中最有效的。Paxos与MySQL相结合可以实现在分布式的MySQL数据的强一致性。常见架构如下：

优点：

多主写入，无延迟复制，能保证数据强一致性；

有成熟理论基础；

自动故障转移，自动添加、剔除节点；

缺点：

只支持innodb储存引擎

至少三节点；

3 总结

随着人们对数据一致性的要求不断的提高，越来越多的方法被尝试用来解决分布式数据一致性的问题，如MySQL自身的优化、MySQL集群架构的优化、Paxos、Raft、2PC算法的引入等等。

而使用分布式算法用来解决MySQL数据库数据一致性的问题的方法，也越来越被人们所接受，一系列成熟的产品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越来越多的被大规模使用。

随着官方MySQL Group Replication的GA，使用分布式协议来解决数据一致性问题已经成为了主流的方向。期望越来越多优秀的解决方案被提出，MySQL高可用问题可以被更好的解决。

密码技术是读懂十种数据存储加密技术的方法。

数据作为新的生产要素，其蕴含的价值日益凸显，而安全问题却愈发突出。密码技术，是实现数据安全最经济、最有效、最可靠的手段，对数据进行加密，并结合有效的密钥保护手段，可在开放环境中实现对数据的强访问控制，从而让数据共享更安全、更有价值。随着《密码法》等“一法三规一条例”的落实，各行业对数据加密技术、产品和服务的重视程度不断提升。

本文聚焦十种数据存储加密技术，希望能够帮助读者快速了解数据存储加密技术的全貌，并在用户需要通过“加解密技术”进行自身核心数据资产的安全保护时，在场景适用性判断、相关技术与产品选型等方面提供参考和帮助。

实战与合规双驱动

在“实战与合规”共同驱动下，数据安全建设作为一种“不希望数据发生什么”的业务需求逐步被重视，将与之匹配的安全技术应用到信息系统业务场景，迫在眉睫。

从实战角度看，当下的数据泄露事件频发，面对新安全挑战与新合规要求，企业安全防护体系正在从“以网络为中心的安全”，升级到“侧重以数据为中心的安全”。而密码作为网络安全的杀手锏技术和核心支撑，天然具备安全防护基因，是实现数据安全最经济、最有效、最可靠的手段。尤其在政务、金融、交通文旅、央企、工业等行业，个人信息保护、商业秘密保护、国密合规等方面的建设亟待加速。

聚焦到数据实际流转过程，在每个关键节点上，作为生产要素的数据都面临着众多威胁。通过对数据流转中的威胁分析，选取关键安全增强点进行加密，用这种方式可以为数据重新塑造一个虚拟边界，实现防范内外部安全威胁，是当前数据安全实战防护的有效手段。

从合规角度看，数据安全技术迎来发展新趋势：第一，数据安全技术正逐步获得国家政策重视以及用户认可，从顶层规划到配套法律法规的不断加码，企业层面越发重视加密技术应用；第二，数据安全技术与业务的结合越来越紧密，业务应用层正成为数据安全建设的重点，将成为解决企业在平衡合规压力、改造复杂业务和信息系统困境的关键所在；第三，数据安全技术应用扩展到各领域行业，如国家标准GB/T 39786-2021《信息安全技术 信息系统密码应用基本要求》的发布，替代行标GM/T 0054-2018《信息系统密码应用基本要求》，密码技术的行业及场景适用性进一步延伸。

数据安全本质上是由攻防对抗推动发展的，实战是加密技术应用的内在需求，合规为加密技术推广提供加速引擎，在实战与合规双驱动下，数据存储加密技术在业务中的应用成为大势所趋。

寻找数据流转中的安全增强点

数据存储加密防护的难点，在于如何对流转中的数据主动实施加密等保护，确保数据不被泄露或篡改，这里的数据包括结构化与非结构化等类型。结构化数据一般是指可以使用关系型数据库存储和表示，表现为二维形式的数据，一般来讲，结构化数据也就是传统数据库中的数据形式；非结构化数据，就是指没有固定结构的数据，包括各种文档、、视频、音频等。

传统的“数据库加密”往往体现为密文数据存储到数据库后的情形，一般局限于结构化数据，而在企业实战化场景中，数据库只是数据处理的一个环节，因此，传统的“数据库存储加密”是“数据存储加密”的子集。

要对比各种数据存储加密技术，炼石认为有多项评判指标：第一，应满足加密防护能力融入业务流程，面向广泛信息化应用，在复杂场景中提供有效防护；第二，能够融合访问控制、审计等其他安全技术，实现安全机制可靠有效；第三，优秀的权限控制能力，能够根据不同属性的人群，展开细粒度权限控制，实现权限最小化，有效防范内部越权、外部黑客拖库等风险；第四，在节约企业成本，不影响企业业务正常运营的情况下，敏捷部署实施高性能的数据安全防护，有效控制实施风险。本文以“数据”为中心，沿着数据流转路径，在典型B/S三层信息系统架构的多个数据业务处理点基础上，综合业内数据加密技术现状，选取了10种代表性的存储加密技术，并对其实现原理、应用场景，以及相应的优势与挑战进行解读分析。

在实际应用中，要结合用户场景和适用性需求，选择一种或者组合多种存储加密技术，优势互补，打造“以密码技术为核心，访问控制、审计等多种安全技术相互融合”的数据安全防护体系，从而满足企业多场景的实战化及合规需求。

十种数据存储加密技术的特性分析

技术一：DLP终端加密

原理解析

部署位置：终端

原理：DLP（Data Leakage Prevention）终端加密技术，目的是管理企业终端上（主要是PC端）的敏感数据，其原理是在受管控的终端上安装代理程序，由代理程序与后台管理平台交互，并结合企业的数据管理要求和分级分类策略，对下载到终端的敏感数据进行加密，从而将加密应用到企业数据的日常流转和存储中。信息被读取到内存中时会进行解密，而未授权复制到管控范围外则是密文形式，主要适用于非结构化数据的保护。

应用场景

DLP终端加密技术主要适用于企业终端数据的安全管理，在原有安全防护能力之上，可有效增强以下场景的数据防护能力：

1）操作失误或无意识外发导致技术数据泄漏；2）通过打印、剪切、复制、粘贴、另存为、重命名等操作泄漏数据；3）离职人员通过U盘、移动硬盘等方式随意拷走机密资料；4）移动笔记本被盗、丢失或维修等造成数据泄漏。

优势

1、文件外发强管控。和其他终端安全技术相比，能够强制实现重要敏感文件的外发管控，从而实现对数据的“事前防护”，可防范一定程度的“有意泄露”。

挑战

1、终端适配困难、运维成本高。企业终端一般具有操作系统众多、终端类型复杂、文档使用场景多样等特点，终端加密在落地应用时，易出现终端兼容适配困难、运维成本较高等问题。在移动终端，由于存在权限问题，技术落地难度大。

技术二：CASB代理网关

原理解析

部署位置：终端-应用服务器之间

原理：CASB代理网关（Cloud Access Security Broker）是一种委托式安全代理技术，将网关部署在目标应用的客户端和服务端之间，无需改造目标应用，只需通过适配目标应用，对客户端请求进行解析，并分析出其包含的敏感数据，结合用户身份，并根据设置的安全策略对请求进行脱敏等访问控制，可针对结构化数据和非结构化数据同时进行安全管控。

应用场景

随着云的普及，传统的IT架构正在发生变化。企业很多业务系统都托管在云服务商处，日常的很多工作，比如HR、社保、报销、OA等工作事务的管理都有相应的SaaS服务可以采用，企业想要享受便捷的云服务，又不想失去对自身数据的控制权，则可以采用CASB代理网关技术。例如，最常见的一种安全防护场景是：能够识别出一个用户访问云资源是使用的私人账号还是企业账号，以防止敏感数据从企业资源转移到私人资源。

优势

1、与业务结合的数据安全保护。CASB代理网关位于应用服务和用户端之间，该位置可以获取到丰富的业务上下文，可以基于用户、资源、操作和业务属性，灵活利用访问者所对应属性集合决定是否有权访问目标数据，比如部门、区域、职位、动作、目标数据类型、时间，以及其他条件等，从而在复杂业务场景下实现对数据的安全防护。

挑战

1、实施成本较高。为实现从客户端请求中解析用户在应用中的操作含义，需适配目标应用，适配工作量取决于目标应用的数量和复杂度以及安全管控粒度。

技术三：应用内加密（集成密码SDK）

原理解析

部署位置：应用服务器

原理：应用内加密（集成密码SDK）是指应用系统通过开发改造的方式，与封装了加密业务逻辑的密码SDK进行集成，并调用其加解密接口，使目标应用系统具备数据加密防护能力。

应用场景

通常情况下，当应用系统仅对数量有限的敏感数据存在加密需求时，适用于使用应用内加密（集成密码SDK）技术。这里主要包含场景：需要加密处理的敏感数据代码逻辑在业务系统中分布不多，或者需要加密处理的敏感数据对应的表或字段相对较少。

优势

1、适用范围广。应用系统的开发商可以自行解决数据加解密的绝大多数问题，对数据库系统本身或第三方的数据安全厂商没有依赖；

2、灵活性高。应用服务端加密，主要是针对于应用服务器的加密方式，因为应用服务端加密可与业务逻辑紧密结合，在应用系统开发过程中，灵活地对相关业务中的敏感数据进行加密处理，且使用的加密函数、加密密钥等均可以根据业务逻辑需求进行灵活选择。

挑战

1、需要对应用系统开发改造。应用系统加密的实现需要应用系统开发投入较大的研发成本，时间周期较长，后期实施和维护成本较高，也面临大量代码改造带来的潜在业务风险；

2、对应用开发人员要求高。对业务开发人员来说，正确合规使用密码技术具有一定门槛。比如在实际应用中，会出现应用开发人员密钥使用不合规或安全风险等情况。

技术四：应用内加密（AOE面向切面加密）

原理解析

部署位置：应用服务器

原理：应用内加密（AOE面向切面加密）技术，能以免开发改造方式，实现应用系统中结构化数据和非结构化数据的存储加密，并提供细粒度访问控制、丰富脱敏策略、以及数据访问审计功能，为应用打造全面有效且易于实施的数据安全保护。其实现原理是将数据安全插件部署在应用服务中间件，结合旁路部署的数据安全管理平台、密钥管理系统，通过拦截入库SQL，将数据加密后存入数据库。

应用场景

应用内加密（AOE面向切面加密）主要适用于企业在应用层想要实现免开发改造的、可敏捷实施的高性能数据安全防护。该加密方式支持结构化/非结构化数据的加密，可与应用开发解耦，灵活性高。进一步的，该加密方式可支持分布式部署、集中式管控，既可针对单个应用防护，也可以针对上百个应用的批量保护。

优势

1、数据加密与业务逻辑解耦。该加密技术通过AOE面向切面加密方式，可以将安全与业务在技术上解耦，又在能力上融合交织，拥有高度灵活性；

2、不影响业务运营。应用内加密（AOE面向切面加密）适用于“应用免改造”的实战需求，能够实现以配置的方式敏捷部署实施，对应用的连续运行无影响。同时与其他加密技术相比，该技术对数据加解密的影响最低；3、基于细粒度权限控制的数据安全防护。该加密技术可针对应用打造“主体到用户，客体到字段”的安全防护体系，能够根据不同属性的人群，实施细粒度的权限控制，实现对企业内部人员的敏感数据访问最小化授权。

挑战

1、对应用程序编程语言和框架需要做适配。企业实际应用系统错综复杂，涉及到多样化的编程语言与框架，这对AOE面向切面加密技术的实现提出较高的工程化实现挑战。

技术五：数据库加密网关

原理解析

部署位置：应用服务器-数据库之间

原理：数据库加密网关是部署在应用服务器和数据库服务器之间的代理网关设备，通过解析数据库协议，对传入数据库的数据进行加密，从而获得保护数据安全的效果。

应用场景

数据库加密网关可以为数据库提供“入库加密、出库解密”的防护，可以建立数据库用户的访问控制，实现企业内部人员的敏感数据访问授权精细化，可以防数据库拖库以及拦截非法SQL。

优势

1、应用系统与加解密功能分离。相比较于传统的应用内加密（集成密码SDK）技术，数据库加密网关技术具有独立性，能够使用户从高度复杂且繁重的加密解密处理逻辑的开发工作解放出来。

挑战

1、存在一定的法律风险。对于Oracle等采用私有通信协议（不开源）的商业数据库，安全厂商提供的数据库加密网关破解协议的方案存在法律风险；

2、高性能和高可用实现难度大。数据库加密网关增加了额外的处理节点，在大数据量和高并发访问场景下，要实现高性能、高可用，面临工程化实现挑战。

技术六：数据库外挂加密

原理解析

部署位置：数据库

原理：数据库外挂加密通过针对数据库定制开发外挂进程，使进入数据库的明文先进入到外挂程序中进行加密，形成密文后再插入数据库表中。这种技术使用“触发器”+“多层视图”+“扩展索引”+“外部调用”的方式实现数据加密，可保证应用完全透明。通过扩展的接口和机制，数据库系统用户可以通过外部接口调用的方式实现对数据的加解密处理。视图可实现对表内数据的过滤、投影、聚集、关联和函数运算，在视图内实现对敏感列解密函数的调用，实现数据解密。

应用场景

如果查询涉及的加密列不多，查询结果集中，且包含的数据记录也相对不多时，可以考虑使用数据库外挂加密技术对数据库进行加密。

优势

1、独立权控体系。使用数据库外挂加密技术，可以在外置的安全服务中提供独立于数据库自有权控体系之外的权限控制体系，适用于对“独立权控体系”有相关需求的场景，可以有效防止特权用户（如DBA）对敏感数据的越权访问。

挑战

1、仅支持Oracle等少量数据库类型。数据库外挂加密，目前大多数的技术实现形式，存在功能性依赖，仅支持开放高级接口的Oracle等少量数据库；

2、数据库性能损耗较高。数据库外挂加密是通过触发器、多级视图，进行外部接口调用来实现加解密，触发器或视图的运行机制要求对加密表中的每一条数据中的每个加密列的读写都会进行外部接口调用，因此，当遇到比如“查询中涉及的加密列较多”等情况时，会对数据库的读写性能存在明显影响；

3、可扩展性差。在业务变化引起数据库表结构发生变化时，需要对外挂程序业务逻辑进行调整，甚至需重新定制开发，存在后期维护成本。

技术七：TDE透明数据加密

原理解析

部署位置：数据库

原理：透明数据加密（Transparent Data Encryption，简称为TDE）是在数据库内部透明实现数据存储加密、访问解密的技术，Oracle、SQL Server、MySQL等数据库默认内置此功能。数据在落盘时加密，在数据库内存中是明文，当攻击者“拔盘”窃取数据，由于数据库文件无法获得密钥而只能获取密文，从而起到保护数据库中数据的效果。

应用场景

透明数据加密技术适用于对数据库中的数据执行实时加解密的应用场景，尤其是在对数据加密透明化有要求，以及对数据加密后数据库性能有较高要求的场景中。在实际使用中，可根据Oracle等内置TDE的密钥管理接口，将默认“软密钥钱包”升级为外部密钥管理系统，以增强密钥安全性。

优势

1、独立权控体系。与数据库外挂加密类似，使用插件形式的透明数据加密技术，同样可以在外置的安全服务中提供独立于数据库自有权控体系之外的权限控制体系；

2、性能损耗较低。透明数据加密技术只对数据库引擎的存储管理层进行了性能增强，不影响数据库引擎的语句解析和优化等处理过程，数据库自身性能得以更好保留，透明数据加密技术在数据库加密技术中，性能损耗较低。

挑战

1、防护颗粒度较粗。TDE本身是一种落盘加密技术，数据在内存中处于明文状态，需要结合其他访问控制技术使用。在实战场景中难以防范DBA等风险；

2、数据库类型适用性上有限制。透明数据加密因使用插件技术，对数据库的版本有较强依赖性，且仅能对有限几种类型的数据库实现透明数据加密插件，在数据库类型适用性上有一定限制。

技术八：UDF用户自定义函数加密

原理解析

部署位置：数据库

原理：UDF（User Defined Function）用户自定义函数是在已有数据库功能的基础上扩展更丰富的业务需求，其原理是在数据库支持的形式上，通过定义函数名称及执行过程，实现自定义的处理逻辑。UDF用户自定义函数加密，是通过UDF接口实现数据在数据库内的加解密。

应用场景

UDF用户自定义函数加密，作为一种在数据库侧的高灵活加解密集成方式，适用于某些数据库需要定制加解密的场景，尤其是实现基于国密算法的数据加解密。

优势

1、扩展能力强。该加密技术适用于对数据有“定制化实现”的场景化需求，能够根据用户的业务需求，对数据实现丰富多样的加解密处理。

挑战

1、通用性低。该加密技术需要根据不同数据库的类型，做相对应的定制化实现，并且在存储过程或SQL中加以调用。

技术九：TFE透明文件加密

原理解析

部署位置：文件系统

原理：透明文件加密（Transparent File Encryption，简称为TFE），是在操作系统的文件管理子系统上部署加密插件来实现数据加密，基于用户态与内核态交付，可实现“逐文件逐密钥”加密。在正常使用时，计算机内存中的文件以明文形式存在，而硬盘上保存的数据是密文，如果没有合法的使用身份、访问权限以及正确的安全通道，加密文件都将以密文状态被保护。

应用场景

透明文件加密技术几乎可以适用于任何基于文件系统的数据存储加密需求，尤其是原生不支持透明数据加密的数据库系统。但是，由于文件系统加密技术无法提供针对数据库用户的增强权限控制，因此对于需要防范内部数据库超级用户的场景并不适用。

优势

1、可对应用进程授权。透明文件加密的防护颗粒度较细，可以适用于对应用进程有绑定需求的场景，只有授权的“白名单”应用进程访问文件时，才能获得明文，而未授权应用只能获取密文。

挑战

1、管理员风险。由于文件系统加密技术的数据库无关性，因此，该加密技术不具备对系统用户增强的权限控制能力，也无法防止内部人员包括系统管理员和数据库DBA对加密数据的访问；

2、高性能实现难度大。透明文件加密技术因为是在操作系统的文件管理子系统上部署加密插件来实现数据的加密功能，因此会增加操作系统中用户态的处理环节，从而对数据库系统整体性能造成部分损失，要实现到高性能面临工程化挑战。

技术十：FDE全磁盘加密

原理解析

部署位置：文件系统

原理：全磁盘加密（Full Disk Encryption，简称FDE）是指通过动态加解密技术，对磁盘或分区进行动态加解密的技术。FDE的动态加解密算法位于操作系统底层，其所有磁盘操作均通过FDE进行：当系统向磁盘上写入数据时，FDE首先加密要写入的数据，然后再写入磁盘；反之，当系统读取磁盘数据时，FDE会自动将读取到的数据进行解密，然后再提交给操作系统。

应用场景

全磁盘加密技术适用于磁盘上所有数据（包括操作系统）进行动态加解密的场景，但由于不能提供针对用户的增强权限控制，无法满足对内部超级用户泄露敏感数据的风险防范需求。

优势

1、性能优势突出。全磁盘加密技术通过操作系统内核层（或者存储设备自身的物理结构）实现，能够最大化减少加解密损耗，对上层业务服务提供性能最高的文件加解密服务；

2、部署、实施简单。全磁盘加密仅需对进入磁盘的数据进行加密，部署和实施简单高效。

挑战

1、数据防护颗粒度粗。该加密技术因为缺少访问控制能力，因此，一旦磁盘挂载口令泄露，就有数据泄露的风险，仅能防范“拔硬盘”攻击。

综上所述，十种数据存储加密技术在应用场景以及优势挑战方面各有侧重点，DLP终端加密技术侧重于企业PC端的数据安全防护；CASB代理网关、应用内加密（集成密码SDK）、应用内加密（AOE面向切面加密）侧重于企业应用服务器端的数据安全防护；数据库加密网关、数据库外挂加密、TDE透明数据加密、UDF用户自定义函数加密则侧重于数据库端的数据安全防护；TFE透明文件加密、FDE全磁盘加密则侧重于文件系统数据安全防护。

迎接数字时代，激活数据要素潜能，数据安全建设工作势在必行，在了解数据安全防护的必要性和迫切性的前提下，具体分析相关的数据存储加密技术原理，探究数据加密技术具体应用，提出更合理、更安全的数据防护措施，能够全面保障数据的安全性，助力我国数字化建设进程的健康发展。作为数据安全创新公司，炼石也将不断探索技术创新思路，提供丰富的数据存储加密技术及方案，为网络信息行业健康发展助力。