A. 数据库安全的概念是什么一般影响数据库安全的因素有哪些
数据库安全包含两层含义：第一层是指系统运行安全，系统运行安全通常受到的威胁如下，一些网络不法分子通过网络，局域网等途径通过入侵电脑使系统无法正常启动，或超负荷让机子运行大量算法，并关闭cpu风扇，使cpu过热烧坏等破坏性活动； 第二层是指系统信息安全，系统安全通常受到的威胁如下，黑客对数据库入侵，并盗取想要的资料。数据库系统的安全特性主要是针对数据而言的，包括数据独立性、数据安全性、数据完整性、并发控制、故障恢复等几个方面。
数据库安全的防护技术有：数据库加密（核心数据存储加密）、数据库防火墙（防漏洞、防攻击）、数据脱敏（敏感数据匿名化）等。（来自网络）
安华金和针对于数据库安全的防护技术全部拥护，并且在政府、金融、社保、能源、军工、运营商、教育、医疗、企业等各行业树立多个标杆案例。
B. 数据库系统的安全措施有哪些
数据库数据加密
数据加密可以有效防止数据库信息失密性的有效手段。通常加密的方法有替换、置换、混合加密等。虽然通过密钥的保护是数据库加密技术的重要手段，但如果采用同种的密钥来管理所有数据的话，对于一些不法用户可以采用暴力破解的方法进行攻击。
但通过不同版本的密钥对不同的数据信息进行加密处理的话，可以大大提高数据库数据的安全强度。这种方式主要的表现形式是在解密时必须对应匹配的密钥版本，加密时就尽量的挑选最新技术的版本。强制存取控制
为了保证数据库系统的安全性，通常采取的是强制存取检测方式，它是保证数据库系统安全的重要的一环。强制存取控制是通过对每一个数据进行严格的分配不同的密级，例如政府，信息部门。在强制存取控制中，DBMS所管理的全部实体被分为主体和客体两大类。主体是系统中的活动实体，它不仅包括DBMS 被管理的实际用户，也包括代表用户的各进程。
客体是系统中的被动实体，是受主体操纵的，包括文件、基表、索引、视图等等。对于主体和客体，DBMS 为它们每个实例(值)指派一个敏感度标记。主客体各自被赋予相应的安全级，主体的安全级反映主体的可信度，而客体的安全级反映客体所含信息的敏感程度。对于病毒和恶意软件的攻击可以通过强制存取控制策略进行防范。但强制存取控制并不能从根本上避免攻击的问题，但可以有从较高安全性级别程序向较低安全性级别程序进行信息传递。审计日志
审计是将用户操作数据库的所有记录存储在审计日志(Audit Log)中，它对将来出现问题时可以方便调查和分析有重要的作用。对于系统出现问题，可以很快得找出非法存取数据的时间、内容以及相关的人。从软件工程的角度上看，目前通过存取控制、数据加密的方式对数据进行保护是不够的。因此，作为重要的补充手段，审计方式是安全的数据库系统不可缺少的一部分，也是数据库系统的最后一道重要的安全防线。
C. 在云平台上的数据库主要面临哪些安全问题
数据库存储着系统的核心数据，其安全方面的问题在传统环境中已经很突出，成为数据泄漏的重要根源。而在云端，数据库所面临的威胁被进一步的放大。其安全问题主要来自于以下几方面： 1） 云运营商的“上帝之手”。如上所述，云端数据库的租户对数据库的可控性是很低的，而云运营商却具有对数据库的所有权限。从技术上来说，云运营商完全可以在租户毫无察觉的情况下进入数据库系统；或者进入数据库服务器所在的虚拟机；或者进入虚拟机所在的宿主物理服务器；或者直接获取到数据库文件所在的存储设备。也就是说，任何租户的数据，对云运营商来说，几乎是完全开放的。而对于有商业价值的数据，对云运营商的众多技术人员来说，绝对有足够的吸引力；2） 来自于其它租户的攻击。同一个云平台上的其它租户，有可能通过虚拟机逃逸等攻击方法，得到数据库中的数据；3） 来自租户自身内部人员的威胁。租户内部人员能够直接使用帐号密码登录到云数据库，从而进行越权或者违规的数据操作；4） 更广泛的攻击。有价值的数据放在云上之后，各种来源的攻击者，都“惦记”着这些数据。可能通过各种方法来进行攻击以获取数据，如近年来频发的sql注入攻击事件，就导致了大量云端数据的泄漏。要解决如上所述的数据安全问题，需要多方面的防御手段。但是对数据库访问情况的记录和审计，是最基本的安全需求。租户需要清楚的知道，自己的数据库，在什么时间，被什么人，以什么工具，具体做什么访问，又拿到了什么数据。并且需要知道什么时候出现了攻击行为和异常的访问情况。这些功能，正是合格数据库审计产品所必须具有的功能。在云平台上的数据库主要面临哪些安全问题？
D. 数据库对一个国家的经济文化科技国家安全等有何影响
随着数据安全法、个人信息保护法的颁布实施，数据安全成为各行业数字化转型的重要一环，通过数据库技术创新助力数据安全成为业内热点。
记者调研采访发现，面对数据安全合规以及新应用新场景下的安全防护要求，传统数据库安全防护理念和技术已经开始转变。在大数据环境下进行顶层设计、标准制订，对各大数据组件进行安全审计、访问控制与风险识别，针对结构化与非结构化数据的安全脱敏、加密安全与隐私防护等，都是当前数据库安全防护新趋势的重要问题。
多因素驱动数据库安全发展
近年来，我国数字经济蓬勃发展。最新发布的《中国互联网发展报告2021》显示，2020年我国数字经济规模达到39.2万亿元，占GDP比重达38.6%。
“只有保障数据安全，才能筑牢数字经济发展的底线。”达梦数据库高级副总经理付铨表示，数据是数字经济的重要生产资料，是国家核心战略资源和社会重要财富。同时，数据安全问题是关乎数字经济健康有序可持续发展的重大问题。
绿盟科技集团副总裁李晨认为，数据库安全发展主要有两个驱动因素，一是数据库本身的发展促使数据库安全技术发展，二是数据安全相关法律法规和标准规范对数据库安全防护提出新的需求。从技术发展看，大规模的数据存储和处理需求，使得大数据、数据仓库、数据湖以及数据中台得到推广，并应用于分布式数据库、云端数据库等很多场景。从数据安全法律法规看，继等级保护2.0系列标准提出大数据应用场景的安全防护参考后，数据安全法和个人信息保护法又相继颁布实施，将数据安全要求提高到法律的高度。
在中国信通院数据库应用创新实验室、中国通信标准化协会大数据技术标准推进委员会近日举办的“数据库安全防护新趋势”沙龙上，清华大学计算机系长聘教授李国良表示，标准有助于落实产业政策，促进企业发展。希望更多企业重视相关工作，共同为数据库安全的发展做出贡献。
据中国信通院云大所工程师刘思源介绍，中国信通院深耕数据库领域标准研制、产业研究、政策支撑、评测评估等，依托中国通信标准化协会大数据技术标准推进委员会，已牵头编制近10项数据库领域行业标准和若干团体标准，累计发布数据库白皮书和研究报告近10本，并定期发布评测评估观察，为遴选优质标的提供重要依据。
数据库安全保障网络安全
数据库安全防护是数据安全治理体系的一部分。李晨表示，绿盟科技从数据安全建设顶层设计出发，提出“一个中心，四个领域，五个阶段”的数据安全体系建设思路。以数据安全防护为中心，在组织建设、制度流程、技术工具和人员能力四个领域同时开展建设工作，通过“知、识、控、察、行”五个步骤进行数据安全落地建设。仅就数据库安全技术而言，绿盟科技有数据分类分级、审计与访问控制、脱敏、水印、脱敏后风险评估、数据防护与态势感知和隐私计算相关技术等。
付铨表示，在信息技术快速发展的背景下，需要在网络信息安全关键技术上有更大突破，前提是独立研发，掌握核心技术。在安全问题上，只有数据库没有安全问题，数据才不会泄露或丢失，信息安全才能得到保障。可以说，只有底层的数据库安全了，网络安全才有保障。
据介绍，达梦数据库研发的数据共享集群实现了国产数据库在共享存储集群方面的突破，在性能上与国际同类产品持平。公司产品广泛应用于金融、能源、电信等50多个重要领域。
构筑多维度立体化安全防线
“随着数据价值重要性的凸显以及未来开放性环境下的安全风险日益突出，数据库需要围绕系统整体韧性能力和数据端到端全生命周期安全构建系统整体外部感知能力和机密计算能力，并完善内核审计追溯能力。”华为技术有限公司数据库技术专家朱金伟说。
勒索病毒是当前受到关注的网络安全风险。美创科技产品和解决方案中心总监胡大海表示，为有效抵御勒索病毒威胁，美创科技从防范实践出发，以“零信任”安全理念为基础，推出“勒索防御产品+安全保险+容灾备份”三位一体的勒索病毒风险解决方案，为机构数据安全构筑起多维度、立体化的安全防线。完善的数据容灾备份建设可以在攻击发生前对数据进行备份，在攻击发生后对数据进行恢复，最大程度降低由勒索病毒加密、窃取数据造成的数据丢失乃至业务中断等影响。
据腾讯云计算技术有限公司数据库高级产品经理程昌明介绍，目前腾讯云数据库已经能够从数据沉淀、业务学习、特征总结、风险模型、人为中心以及行为分析等方面，基于大数据分析进行安全治理。
E. 在IT项目建设中，如何保证数据库安全性
#云原生背景#
云计算是信息技术发展和服务模式创新的集中体现，是信息化发展的重要变革和必然趋势。随着“新基建”加速布局，以及企业数字化转型的逐步深入，如何深化用云进一步提升云计算使用效能成为现阶段云计算发展的重点。云原生以其高效稳定、快速响应的特点极大地释放了云计算效能，成为企业数字业务应用创新的原动力，云原生进入快速发展阶段，就像集装箱加速贸易全球化进程一样，云原生技术正在助力云计算普及和企业数字化转型。
云原生计算基金会（CNCF）对云原生的定义是：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式编程API。
#云安全时代市场发展#
云安全几乎是伴随着云计算市场而发展起来的，云基础设施投资的快速增长，无疑为云安全发展提供土壤。根据 IDC 数据，2020 年全球云安全支出占云 IT 支出比例仅为 1.1%，说明目前云安全支出远远不够，假设这一比例提升至 5%，那么2020 年全球云安全市场空间可达 53.2 亿美元，2023 年可达 108.9 亿美元。
海外云安全市场：技术创新与兼并整合活跃。整体来看，海外云安全市场正处于快速发展阶段，技术创新活跃，兼并整合频繁。一方面，云安全技术创新活跃，并呈现融合发展趋势。例如，综合型安全公司 PaloAlto 的 Prisma 产品线将 CWPP、CSPM 和 CASB 三个云安全技术产品统一融合，提供综合解决方案及 SASE、容器安全、微隔离等一系列云上安全能力。另一方面，新兴的云安全企业快速发展，同时，传统安全供应商也通过自研+兼并的方式加强云安全布局。
国内云安全市场：市场空间广阔，尚处于技术追随阶段。市场规模上，根据中国信通院数据，2019 年我国云计算整体市场规模达 1334.5亿元，增速 38.6%。预计 2020-2022 年仍将处于快速增长阶段，到 2023 年市场规模将超过 3754.2 亿元。中性假设下，安全投入占云计算市场规模的 3%-5%，那么 2023 年中国云安全市场规模有望达到 112.6 亿-187.7 亿元。技术发展上，中国在云计算的发展阶段和云原生技术的程度上与海外市场还有一定差距。国内 CWPP 技术应用较为广泛，对于 CASB、CSPM 一些新兴的云安全技术应用较少。但随着国内公有云市场的加速发展，云原生技术的应用越来越广泛，我们认为CASB、SCPM、SASE 等新兴技术在国内的应用也将越来越广泛。
#云上安全呈原生化发展趋势#
云原生技术逐渐成为云计算市场新趋势，所带来的安全问题更为复杂。以容器、服务网格、微服务等为代表的云原生技术，正在影响各行各业的 IT 基础设施、平台和应用系统，也在渗透到如 IT/OT 融合的工业互联网、IT/CT 融合的 5G、边缘计算等新型基础设施中。随着云原生越来越多的落地应用，其相关的安全风险与威胁也不断的显现出来。Docker/Kubernetes 等服务暴露问题、特斯拉 Kubernetes 集群挖矿事件、Docker Hub 中的容器镜像被“投毒”注入挖矿程序、微软 Azure 安全中心检测到大规模 Kubernetes 挖矿事件、Graboid 蠕虫挖矿传播事件等一系列针对云原生的安全攻击事件层出不穷。
从各种各样的安全风险中可以一窥云原生技术的安全态势，云原生环境仍然存在许多安全问题亟待解决。在云原生技术的落地过程中，安全是必须要考虑的重要因素。
#云原生安全的定义#
国内外各组织、企业对云原生安全理念的解释略有差异，结合我国产业现状与痛点，云原生与云计算安全相似，云原生安全也包含两层含义：“面向云原生环境的安全”和“具有云原生特征的安全”。
面向云原生环境的安全，其目标是防护云原生环境中的基础设施、编排系统和微服务的安全。这类安全机制，不一定具备云原生的特性（比如容器化、可编排），它们可以是传统模式部署的，甚至是硬件设备，但其作用是保护日益普及的云原生环境。
具有云原生特征的安全，是指具有云原生的弹性敏捷、轻量级、可编排等特性的各类安全机制。云原生是一种理念上的创新，通过容器化、资源编排和微服务重构了传统的开发运营体系，加速业务上线和变更的速度，因而，云原生系统的种种优良特性同样会给安全厂商带来很大的启发，重构安全产品、平台，改变其交付、更新模式。
#云原生安全理念构建#
为缓解传统安全防护建设中存在的痛点，促进云计算成为更加安全可信的信息基础设施，助力云客户更加安全的使用云计算，云原生安全理念兴起，国内外第三方组织、服务商纷纷提出以原生为核心构建和发展云安全。
Gartner提倡以云原生思维建设云安全体系
基于云原生思维，Gartner提出的云安全体系覆盖八方面。其中，基础设施配置、身份和访问管理两部分由云服务商作为基础能力提供，其它六部分，包括持续的云安全态势管理，全方位的可视化、日志、审计和评估，工作负载安全，应用、PaaS 和 API 安全，扩展的数据保护，云威胁检测，客户需基于安全产品实现。
Forrester评估公有云平台原生安全能力
Forrester认为公有云平台原生安全（Public cloud platform native security, PCPNS）应从三大类、37 个方面去衡量。从已提供的产品和功能，以及未来战略规划可以看出，一是考察云服务商自身的安全能力和建设情况，如数据中心安全、内部人员等，二是云平台具备的基础安全功能，如帮助和文档、授权和认证等，三是为用户提供的原生安全产品，如容器安全、数据安全等。
安全狗以4项工作防护体系建设云原生安全
（1）结合云原生技术的具体落地情况开展并落实最小权限、纵深防御工作，对于云原生环境中的各种组成部分，均可贯彻落实“安全左移”的原则，进行安全基线配置，防范于未然。而对于微服务架构Web应用以及Serverless应用的防护而言，其重点是应用安全问题。
（2）围绕云原生应用的生命周期来进行DevSecOps建设，以当前的云原生环境的关键技术栈“K8S + Docker”举例进行分析。应该在容器的全生命周期注重“配置安全”，在项目构建时注重“镜像安全”，在项目部署时注重“容器准入”，在容器的运行环境注重云计算的三要素“计算”“网络”以及“存储”等方面的安全问题。
（3）围绕攻击前、中、后的安全实施准则进行构建，可依据安全实施准则对攻击前、中、后这三个阶段开展检测与防御工作。
（4）改造并综合运用现有云安全技术，不应将“云原生安全”视为一个独立的命题，为云原生环境提供更多支持的主机安全、微隔离等技术可赋能于云原生安全。
#云原生安全新型风险#
云原生架构的安全风险包含云原生基础设施自身的安全风险，以及上层应用云原生化改造后新增和扩大的安全风险。云原生环境面临着严峻的安全风险问题。攻击者可能利用的重要攻击面包括但不限于：容器安全、编排系统、软件供应链等。下面对重要的攻击面安全风险问题进行梳理。
#云原生安全问题梳理#
问题1：容器安全问题
在云原生应用和服务平台的构建过程中，容器技术凭借高弹性、敏捷的特性，成为云原生应用场景下的重要技术支撑，因而容器安全也是云原生安全的重要基石。
（1）容器镜像不安全
Sysdig的报告中提到，在用户的生产环境中，会将公开的镜像仓库作为软件源，如最大的容器镜像仓库Docker Hub。一方面，很多开源软件会在Docker Hub上发布容器镜像。另一方面，开发者通常会直接下载公开仓库中的容器镜像，或者基于这些基础镜像定制自己的镜像，整个过程非常方便、高效。然而，Docker Hub上的镜像安全并不理想，有大量的官方镜像存在高危漏洞，如果使用了这些带高危漏洞的镜像，就会极大的增加容器和主机的入侵风险。目前容器镜像的安全问题主要有以下三点：
1.不安全的第三方组件
在实际的容器化应用开发过程当中，很少从零开始构建镜像，而是在基础镜像之上增加自己的程序和代码，然后统一打包最终的业务镜像并上线运行，这导致许多开发者根本不知道基础镜像中包含多少组件，以及包含哪些组件，包含的组件越多，可能存在的漏洞就越多。
2.恶意镜像
公共镜像仓库中可能存在第三方上传的恶意镜像，如果使用了这些恶意镜像来创建容器后，将会影响容器和应用程序的安全
3.敏感信息泄露
为了开发和调试的方便，开发者将敏感信息存在配置文件中，例如数据库密码、证书和密钥等内容，在构建镜像时，这些敏感信息跟随配置文件一并打包进镜像，从而造成敏感信息泄露
（2）容器生命周期的时间短
云原生技术以其敏捷、可靠的特点驱动引领企业的业务发展，成为企业数字业务应用创新的原动力。在容器环境下，一部分容器是以docker的命令启动和管理的，还有大量的容器是通过Kubernetes容器编排系统启动和管理，带来了容器在构建、部署、运行，快速敏捷的特点，大量容器生命周期短于1小时，这样一来容器的生命周期防护较传统虚拟化环境发生了巨大的变化，容器的全生命周期防护存在很大变数。对防守者而言，需要采用传统异常检测和行为分析相结合的方式，来适应短容器生命周期的场景。
传统的异常检测采用WAF、IDS等设备，其规则库已经很完善，通过这种检测方法能够直观的展示出存在的威胁，在容器环境下，这种方法仍然适用。
传统的异常检测能够快速、精确地发现已知威胁，但大多数未知威胁是无法通过规则库匹配到的，因而需要通过行为分析机制来从大量模式中将异常模式分析出来。一般来说，一段生产运营时间内的业务模式是相对固定的，这意味着，业务行为是可以预测的，无论启动多少个容器，容器内部的行为总是相似的。通过机器学习、采集进程行为，自动构建出合理的基线，利用这些基线对容器内的未知威胁进行检测。
（3）容器运行时安全
容器技术带来便利的同时，往往会忽略容器运行时的安全加固，由于容器的生命周期短、轻量级的特性，传统在宿主机或虚拟机上安装杀毒软件来对一个运行一两个进程的容器进行防护，显示费时费力且消耗资源，但在黑客眼里容器和裸奔没有什么区别。容器运行时安全主要关注点：
1.不安全的容器应用
与传统的Web安全类似，容器环境下也会存在SQL注入、XSS、RCE、XXE等漏洞，容器在对外提供服务的同时，就有可能被攻击者利用，从而导致容器被入侵
2.容器DDOS攻击
默认情况下，docker并不会对容器的资源使用进行限制，默认情况下可以无限使用CPU、内存、硬盘资源，造成不同层面的DDOS攻击
（4）容器微隔离
在容器环境中，与传统网络相比，容器的生命周期变得短了很多，其变化频率也快很多。容器之间有着复杂的访问关系，尤其是当容器数量达到一定规模以后，这种访问关系带来的东西向流量，将会变得异常的庞大和复杂。因此，在容器环境中，网络的隔离需求已经不仅仅是物理网络的隔离，而是变成了容器与容器之间、容器组与宿主机之间、宿主机与宿主机之间的隔离。
问题2：云原生等保合规问题
等级保护2.0中，针对云计算等新技术、新应用领域的个性安全保护需求提出安全扩展要求，形成新的网络安全等级保护基本要求标准。虽然编写了云计算的安全扩展要求，但是由于编写周期很长，编写时主流还是虚拟化场景，而没有考虑到容器化、微服务、无服务等云原生场景，等级保护2.0中的所有标准不能完全保证适用于目前云原生环境；
通过安全狗在云安全领域的经验和具体实践，对于云计算安全扩展要求中访问控制的控制点，需要检测主机账号安全，设置不同账号对不同容器的访问权限，保证容器在构建、部署、运行时访问控制策略随其迁移；
对于入侵防范制的控制点，需要可视化管理，绘制业务拓扑图，对主机入侵进行全方位的防范，控制业务流量访问，检测恶意代码感染及蔓延的情况；
镜像和快照保护的控制的，需要对镜像和快照进行保护，保障容器镜像的完整性、可用性和保密性，防止敏感信息泄露。
问题3：宿主机安全
容器与宿主机共享操作系统内核，因此宿主机的配置对容器运行的安全有着重要的影响，比如宿主机安装了有漏洞的软件可能会导致任意代码执行风险，端口无限制开放可能会导致任意用户访问的风险。通过部署主机入侵监测及安全防护系统，提供主机资产管理、主机安全加固、风险漏洞识别、防范入侵行为、问题主机隔离等功能，各个功能之间进行联动，建立采集、检测、监测、防御、捕获一体化的安全闭环管理系统，对主机进行全方位的安全防护，协助用户及时定位已经失陷的主机，响应已知、未知威胁风险，避免内部大面积主机安全事件的发生。
问题4：编排系统问题
编排系统支撑着诸多云原生应用，如无服务、服务网格等，这些新型的微服务体系也同样存在着安全问题。例如攻击者编写一段代码获得容器的shell权限，进而对容器网络进行渗透横移，造成巨大损失。
Kubernetes架构设计的复杂性，启动一个Pod资源需要涉及API Server、Controller、Manager、Scheler等组件，因而每个组件自身的安全能力显的尤为重要。API Server组件提供的认证授权、准入控制，进行细粒度访问控制、Secret资源提供密钥管理及Pod自身提供安全策略和网络策略，合理使用这些机制可以有效实现Kubernetes的安全加固。
问题5：软件供应链安全问题
通常一个项目中会使用大量的开源软件，根据Gartner统计至少有95%的企业会在关键IT产品中使用开源软件，这些来自互联网的开源软件可能本身就带有病毒、这些开源软件中使用了哪些组件也不了解，导致当开源软件中存在0day或Nday漏洞，我们根本无法获悉。
开源软件漏洞无法根治，容器自身的安全问题可能会给开发阶段带的各个过程带来风险，我们能做的是根据SDL原则，从开发阶段就开始对软件安全性进行合理的评估和控制，来提升整个供应链的质量。
问题6：安全运营成本问题
虽然容器的生命周期很短，但是包罗万象。对容器的全生命周期防护时，会对容器构建、部署、运行时进行异常检测和安全防护，随之而来的就是高成本的投入，对成千上万容器中的进程行为进程检测和分析，会消耗宿主机处理器和内存资源，日志传输会占用网络带宽，行为检测会消耗计算资源，当环境中容器数量巨大时，对应的安全运营成本就会急剧增加。
问题7：如何提升安全防护效果
关于安全运营成本问题中，我们了解到容器安全运营成本较高，我们该如何降低安全运营成本的同时，提升安全防护效果呢？这就引入一个业界比较流行的词“安全左移”，将软件生命周期从左到右展开，即开发、测试、集成、部署、运行，安全左移的含义就是将安全防护从传统运营转向开发侧，开发侧主要设计开发软件、软件供应链安全和镜像安全。
因此，想要降低云原生场景下的安全运营成本，提升运营效率，那么首先就要进行“安全左移”，也就是从运营安全转向开发安全，主要考虑开发安全、软件供应链安全、镜像安全和配置核查：
开发安全
需要团队关注代码漏洞，比如使用进行代码审计，找到因缺少安全意识造成的漏洞和因逻辑问题造成的代码逻辑漏洞。
供应链安全
可以使用代码检查工具进行持续性的安全评估。
镜像安全
使用镜像漏洞扫描工具持续对自由仓库中的镜像进行持续评估，对存在风险的镜像进行及时更新。
配置核查
核查包括暴露面、宿主机加固、资产管理等，来提升攻击者利用漏洞的难度。
问题8：安全配置和密钥凭证管理问题
安全配置不规范、密钥凭证不理想也是云原生的一大风险点。云原生应用会存在大量与中间件、后端服务的交互，为了简便，很多开发者将访问凭证、密钥文件直接存放在代码中，或者将一些线上资源的访问凭证设置为弱口令，导致攻击者很容易获得访问敏感数据的权限。
#云原生安全未来展望#
从日益新增的新型攻击威胁来看，云原生的安全将成为今后网络安全防护的关键。伴随着ATT&CK的不断积累和相关技术的日益完善，ATT&CK也已增加了容器矩阵的内容。ATT&CK是对抗战术、技术和常识（Adversarial Tactics, Techniques, and Common Knowledge）的缩写，是一个攻击行为知识库和威胁建模模型，它包含众多威胁组织及其使用的工具和攻击技术。这一开源的对抗战术和技术的知识库已经对安全行业产生了广泛而深刻的影响。
云原生安全的备受关注，使ATTACK Matrix for Container on Cloud的出现恰合时宜。ATT&CK让我们从行为的视角来看待攻击者和防御措施，让相对抽象的容器攻击技术和工具变得有迹可循。结合ATT&CK框架进行模拟红蓝对抗，评估企业目前的安全能力，对提升企业安全防护能力是很好的参考。
F. 数据库需求分析中的安全性完整性怎么体现
完整性和安全性都是在数据库编程中可以用编程语句来实现的，在SQL编程中加上完整性约束条件。
楼主说的在需求分析中体现安全性和完整性，这就比较复杂了。
因为第一，普通用户根本不知道数据库能干什么，不能干什么，这样用户自己很难确定需求，所表述的需求不清晰，也经常改动，这是数据库设计很正常的事情；第二，设计人员缺少专业的知识，理解不了用户所要的需求，这都是在数据库需求分析中常见的。
因此，为了体现这一方面，数据库的设计人员应和用户多多交流、多多沟通，确定用户真正的需求，是数据库中的数据达到完整和安全。。。
G. 如何做好MySQL安全策略
摘至网页链接
常见Mysql配置文件：linux系统下是my.conf，windows环境下是my.ini；
数据库整体安全需求：机密性、完整性、可用性；
下面以mysql 5.7版本为例，介绍mysql常见的安全策略、配置、加固方式等等，有些策略可能只针对Linux操作系统，更多策略可以参考CIS Mysql Benchmark相关文档：
1、操作系统级别安全配置
1.1不要将数据库放在系统分区
Windows系统：直接检查是否将数据库放置在C盘。
Linux系统：
在终端连接上mysql数据库，执行如下命令：
show variables where variable_name = 'datadir';
然后返回shell命令行：
df -h <datadir>
其中datadir是上一条命令的返回值。
上述命令的返回值不应是/、/var、/usr
1.2使用专用的最小权限账号运行mysql数据库进程
Windows系统：直接打开任务管理器，查看运行mysql进程的操作系统账号，不能为administrator账号。
Linux系统：
Shell命令行运行如下命令：
ps -ef | grep mysql
查看mysql服务的运行账号是否为root或其他高权限账号，如果是的，则需要创建一个非管理员专用账号来运行mysql服务。
1.3禁止使用mysql命令行历史记录
Linux系统：
执行如下命令：
find / -name ".mysql_history"
查看是否存在mysql的历史命令记录文件，如果存在，则需要进行如下加固：
（1）删除.mysql_history文件；
（2）设置环境变量MYSQL_HISTFILE为/dev/null，并添加到shell的初始化脚本中，创建mysql_history到/dev/null的链接：
ln -s /dev/null $HOME/.mysql_history
1.4确保MYSQL_PWD环境变量未设置敏感信息
Windows系统下进入cmd命令行，使用如下命令：
Set
查看是否设置了环境变量MYSQL_PWD。
Linux系统下使用如下命令：
grep MYSQL_PWD /proc/*/environ
查看MYSQL_PWD环境变量是否设置了敏感信息。
确认那个配置文件或脚本设置了MYSQL_PWD环境变量。
2、安装
2.1使用数据库专用服务器
使用专用的服务器安装mysql服务可以减少mysql服务的攻击面，尽量卸载或删除操作系统上的不必要的应用或服务，减少其他应用的安装可能给mysql的运行带来的安全风险。
2.2不要复用数据库账号
运行mysql服务的操作系统账号不要用来运行其他应用或服务，这样可以避免其他应用或服务器被攻击给mysql服务带来影响。
2.3历史命令行密码设置为不可见
使用如下命令：
mysql -u admin -p password
连接mysql数据库服务，退出后查看历史命令，确认password是否为明文。
建议使用如下命令方式登录：
（1）先输入mysql -u admin -p
（2）根据命令行提示输入密码；
而不要在一整条命令中输入密码。
另外要控制mysql配置文件访问权限。
3、文件权限控制
3.1控制数据目录的访问权限
数据目录是mysql数据库存放的位置，在mysql命令行界面下执行如下命令：
show variables where variable_name = 'datadir';
在终端命令行下执行如下命令：
ls -l <datadir>/.. | egrep "^d[r|w|x]{3}------s*.s*mysqls*mysqls*d*.*mysql"
其中<datadir>是第一条命令的执行结果
如果存在问题，linux环境下在终端执行如下命令进行加固：
chmod 700 <datadir>
chown mysql:mysql <datadir>
3.2控制二进制日志文件的权限
mysql的运行会产生很多日志，例如二进制日志、错误日志、慢查询日志等等，Mysql命令行下执行如下命令：
show variables like 'log_bin_basename';
在终端命令行执行如下命令：
ls <log_bin_basename>.*
对于发现的每一个文件，执行如下命令：
ls -l <log_bin_basename.nnnnn> | egrep "^-[r|w]{2}-[r|w]{2}----s*.*$"
根据输出确认日志文件的权限设置是否存在问题。
对于每个日志文件，修改其权限和属组如下：
chmod 660 <log file>
chown mysql:mysql <log file>
3.3控制错误日志文件的权限
Mysql命令行下执行如下命令：
show variables like 'log_error';
在终端命令行执行如下命令：
ls <log_error>.*
对于发现的每一个文件，执行如下命令：
ls -l <log_error> | egrep "^-[r|w]{2}-[r|w]{2}----s*.*$"
根据输出确认日志文件的权限设置是否存在问题。
对于每个日志文件，修改其权限和属组如下：
chmod 660 <log file>
chown mysql:mysql <log file>
3.4控制慢查询日志文件的权限
Mysql命令行下执行如下命令：
show variables like 'slow_query_log_file';
在终端命令行执行如下命令：
ls <slow_query_log_file>.*
对于发现的每一个文件，执行如下命令：
ls -l <slow_query_log_file> | egrep "^-[r|w]{2}-[r|w]{2}----s*.*$"
根据输出确认日志文件的权限设置是否存在问题。
对于每个日志文件，修改其权限和属组如下：
chmod 660 <log file>
chown mysql:mysql <log file>
3.5控制通用日志文件的权限
Mysql命令行下执行如下命令：
show variables like 'general_log_file';
在终端命令行执行如下命令：
ls <general_log_file>.*
对于发现的每一个文件，执行如下命令：
ls -l <general_log_file> | egrep "^-[r|w]{2}-[r|w]{2}----s*.*$"
根据输出确认日志文件的权限设置是否存在问题。
对于每个日志文件，修改其权限和属组如下：
chmod 660 <log file>
chown mysql:mysql <log file>
3.6控制审计日志文件的权限
Mysql命令行下执行如下命令：
show global variables where variable_name = 'audit_log_file';
在终端执行如下命令：
ls -l <audit_log_file> | egrep "^-rw[-x]rw[-x][-r][-w][-x][ ]*[0-9][ ]*mysql[
]*mysql.*$"
根据输出确认日志文件的权限设置是否存在问题。
对于每个日志文件，修改其权限和属组如下：
chmod 660 <audit_log_file>
chown mysql:mysql <audit_log_file>
4、通用安全
4.1安装最新的补丁
在mysql命令行下查询MySQL的版本：
SHOW VARIABLES WHERE Variable_name LIKE "version";
确认是否由需要安装的补丁包，如果有请安装。
4.2删除test数据库
Mysql数据库默认安装好后，存在一个名为test的数据库，如果存在，请执行如下命令删除：
Drop database “test”
4.3确保读取本地文件的参数设置为失效
Mysql命令行下，使用如下命令：
SHOW VARIABLES WHERE Variable_name = 'local_infile';
查看结果是否为OFF。
如果该命令为ON，则数据库用户可以通过LOAD DATA INFILE 或者SELECT local_file读取到数据库所在操作系统本地的文件，在这种情况下，需要在mysql配置文件中新增一行：
Local-infile=0；
然后重启数据库服务。
5、权限配置
5.1控制可以访问所有数据库的账号
Mysql数据库下的user表和db表中存放着可以授予数据库用户的权限，确保只有管理员账号才能访问所有数据库。可以访问mysql数据库的用户或许可以查看密码哈希值、修改用户权限等等。
使用如下sql语句：
SELECT user, hostFROM mysql.user
WHERE (Select_priv = 'Y')OR (Insert_priv = 'Y')OR (Update_priv = 'Y')
OR (Delete_priv = 'Y')OR (Create_priv = 'Y')OR (Drop_priv = 'Y');
SELECT user, hostFROM mysql.dbWHERE db = 'mysql'
AND ((Select_priv = 'Y')OR (Insert_priv = 'Y')OR (Update_priv = 'Y')
OR (Delete_priv = 'Y')OR (Create_priv = 'Y')OR (Drop_priv = 'Y'));
确保返回结果只能是数据库管理员账号。
5.2限制非管理员用户的权限
Mysql.user表中的权限列有：
file_priv：表示是否允许用户读取数据库所在主机的本地文件；
Process：表示是否允许用户查询所有用户的命令执行信息；
Super_priv：表示用户是否有设置全局变量、管理员调试等高级别权限；
Shutdown_priv：表示用户是否可以关闭数据库；
Create_user_priv：表示用户是否可以创建或删除其他用户；
Grant_priv：表示用户是否可以修改其他用户的权限；
应确保只有数据库管理员才有上述权限，使用如下sql语句查看拥有各个权限的数据库账号：
select user, host from mysql.user where File_priv = 'Y';
select user, host from mysql.user where Process_priv = 'Y';
select user, host from mysql.user where Process_priv = 'Y';
SELECT user, host FROM mysql.user WHERE Shutdown_priv = 'Y';
SELECT user, host FROM mysql.user WHERE Create_user_priv = 'Y';
SELECT user, host FROM mysql.user WHERE Grant_priv = 'Y';
SELECT user, host FROM mysql.db WHERE Grant_priv = 'Y';
确保查询结果中不存在非管理员用户。
如果存在非管理员用户，使用如下命令进行权限回收：
REVOKE FILE ON *.* FROM '<user>';
REVOKE PROCESS ON *.* FROM '<user>';
REVOKE SUPER ON *.* FROM '<user>';
REVOKE SHUTDOWN ON *.* FROM '<user>';
REVOKE CREATE USER ON *.* FROM '<user>';
REVOKE GRANT OPTION ON *.* FROM <user>;
其中user为上述查询到的非管理员用户。
5.3合理控制DML/DDL操作授权
DML/DDL语句包括创建或修改数据库结构的权限，例如insert、update、delete、create、drop和alter语句，在任何数据库中都要控制用户的此类权限，确保只授权给有业务需求的非管理员用户。Mysql命令行下执行如下命令：
SELECT User,Host,DbFROM mysql.dbWHERE Select_priv='Y'
OR Insert_priv='Y'OR Update_priv='Y'OR Delete_priv='Y'OR Create_priv='Y'
OR Drop_priv='Y'OR Alter_priv='Y';
上述查询到的用户只能对特地的数据库才有相关的权限，使用如下命令进行相关权限的回收：
REVOKE SELECT ON <host>.<database> FROM <user>;
REVOKE INSERT ON <host>.<database> FROM <user>;
REVOKE UPDATE ON <host>.<database> FROM <user>;
REVOKE DELETE ON <host>.<database> FROM <user>;
REVOKE CREATE ON <host>.<database> FROM <user>;
REVOKE DROP ON <host>.<database> FROM <user>;
REVOKE ALTER ON <host>.<database> FROM <user>;
其中<user>为查询到的未授权的用户，host为相关主机，database为相关数据库。
6、审计和日志
6.1开启错误日志审计功能
错误日志包括数据库运行和停止过程中的一系列活动信息，有助于分析数据库运行过程中的一些异常活动，一般情况下需要开启错误日志记录功能，使用如下命令查询：
SHOW variables LIKE 'log_error';
确保返回结果为非空，如果为空，需要在mysql数据库配置文件中增加相关配置。
6.2确保日志存放在非系统区域
日志文件随着数据库的运行会不断增加，如果存放在系统区域，则会影响系统的正常运行，使用如下命令进行查询：
SELECT @@global.log_bin_basename;
确保返回结果不是如下路径：/、/var、/usr
6.3关闭原始日志功能
原始日志选项会决定一些敏感信息是否会被明文写进日志中，例如查询日志、慢查询日志、二进制日志，确保数据库配置文件中存在如下配置项：
Log-raw = OFF
7、认证
7.1 Old_passwords环境变量设置
Old_passwords决定了使用PASSWORD()函数和IDENTIFIED BY、CREATE USER、GRANT等语句是时的hash算法：
0 - authenticate with the mysql_native_password plugin
1 - authenticate with the mysql_old_password plugin
2 - authenticate with the sha256_password plugin
设置为mysql_old_password代表弱hash算法，可以快速通过密码字典进行暴力破解。使用如下命令查询相关值：
SHOW VARIABLES WHERE Variable_name = 'old_passwords';
确保返回值不为1。
7.2 secure_auth选项设置
如果客户端采用Old_passwords发起连接请求，如果服务器端设置了secure_auth，则客户端会拒绝连接请求，可以根据安全需求在配置文件中做相应配置。
7.3密码保存
确保密码没有明文保存在全局配置文件中。
7.4确保所有用户都要求使用非空密码登录
执行如下语句查询是否有用户不需要密码即可登录：
SELECT User,host
FROM mysql.user
WHERE (plugin IN('mysql_native_password', 'mysql_old_password')
AND (LENGTH(Password) = 0
OR Password IS NULL))
OR (plugin='sha256_password' AND LENGTH(authentication_string) = 0);
7.5不存在空账号
使用如下命令查询是否存在空账号：
SELECT user,host FROM mysql.user WHERE user = '';
8、网络设置
如果mysql数据库服务器与应用是跨信任域部署的，则需要考虑在数据库服务器与应用服务器之间建立ssl通道进行数据传输，不过这种场景一般很少见，在此不详细描述。
9、数据库备份
H. 以数据为中心的安全是否可以满足现在的数据安全需求
我觉得基于“安全体系以数据为中心”的数据安全理念则更贴近安全目标，因为数据安全主要依靠的是一种“协议解析”技术，对数据库流量协议数据包进行全协议解码，从数据库协议、应用协议中抽取出更为细粒度的SQL语句以及应用客户端、访问源IP、目标数据库IP、数据库用户、数据库实例等信息，以该技术为基础进行数据级的细粒度控制手段，才能满足企业内部数据传输、数据访问、数据处理的更高细粒度的访问准入控制要求。