sqlserver有哪些安全策略

Microsoft建立了一种既灵活又强大的安全管理机制，它能够对用户访问SQL Server服务器系统和数据库的安全进行全面地管理。按照本文介绍的步骤，你可以为SQL Server 70(或2000)构造出一个灵活的、可管理的安全策略，而且它的安全性经得起考验。

一、验证方法选择

本文对验证(authentication)和授权(authorization)这两个概念作不同的解释。验证是指检验用户的身份标识;授权是指 允许用户做些什么。在本文的讨论中，验证过程在用户登录SQL Server的时候出现，授权过程在用户试图访问数据或执行命令的时候出现。

构造安全策略的第一个步骤是确定SQL Server用哪种方式验证用户。SQL Server的验证是把一组帐户、密码与Master数据库Sysxlogins表中的一个清单进行匹配。Windows NT/2000的验证是请求域控制器检查用户身份的合法性。一般地，如果服务器可以访问域控制器，我们应该使用Windows NT/2000验证。域控制器可以是Win2K服务器，也可以是NT服务器。无论在哪种情况下，SQL Server都接收到一个访问标记(Access Token)。访问标记是在验证过程中构造出来的一个特殊列表，其中包含了用户的SID(安全标识号)以及一系列用户所在组的SID。正如本文后面所介绍 的，SQL Server以这些SID为基础授予访问权限。注意， *** 作系统如何构造访问标记并不重要，SQL Server只使用访问标记中的SID。也就是说，不论你使用SQL Server 2000、SQL Server 70、Win2K还是NT进行验证都无关紧要，结果都一样。

如果使用SQL Server验证的登录，它最大的好处是很容易通过Enterprise Manager实现，最大的缺点在于SQL Server验证的登录只对特定的服务器有效，也就是说，在一个多服务器的环境中管理比较困难。使用SQL Server进行验证的第二个重要的缺点是，对于每一个数据库，我们必须分别地为它管理权限。如果某个用户对两个数据库有相同的权限要求，我们必须手工设 置两个数据库的权限，或者编写脚本设置权限。如果用户数量较少，比如25个以下，而且这些用户的权限变化不是很频繁，SQL Server验证的登录或许适用。但是，在几乎所有的其他情况下(有一些例外情况，例如直接管理安全问题的应用)，这种登录方式的管理负担将超过它的优 点。

二、Web环境中的验证

即使最好的安全策略也常常在一种情形前屈服，这种情形就是在Web应用中使用SQL Server的数据。在这种情形下，进行验证的典型方法是把一组SQL Server登录名称和密码嵌入到Web服务器上运行的程序，比如ASP页面或者CGI脚本;然后，由Web服务器负责验证用户，应用程序则使用它自己的 登录帐户(或者是系统管理员sa帐户，或者为了方便起见，使用Sysadmin服务器角色中的登录帐户)为用户访问数据。

这种安排有几个缺点，其中最重要的包括：它不具备对用户在服务器上的活动进行审核的能力，完全依赖于Web应用程序实现用户验证，当SQL Server需要限定用户权限时不同的用户之间不易区别。如果你使用的是IIS 50或者IIS 40，你可以用四种方法验证用户。第一种方法是为每一个网站和每一个虚拟目录创建一个匿名用户的NT帐户。此后，所有应用程序登录SQL Server时都使用该安全环境。我们可以通过授予NT匿名帐户合适的权限，改进审核和验证功能。

第二种方法是让所有网站使用Basic验证。此时，只有当用户在对话框中输入了合法的帐户和密码，IIS才会允许他们访问页面。IIS依靠一个NT 安全数据库实现登录身份验证，NT安全数据库既可以在本地服务器上，也可以在域控制器上。当用户运行一个访问SQL Server数据库的程序或者脚本时，IIS把用户为了浏览页面而提供的身份信息发送给服务器。如果你使用这种方法，应该记住：在通常情况下，浏览器与服 务器之间的密码传送一般是不加密的，对于那些使用Basic验证而安全又很重要的网站，你必须实现SSL(Secure Sockets Layer，安全套接字层)。

在客户端只使用IE 50、IE 40、IE 30浏览器的情况下，你可以使用第三种验证方法。你可以在Web网站上和虚拟目录上都启用NT验证。IE会把用户登录计算机的身份信息发送给IIS，当 该用户试图登录SQL Server时IIS就使用这些登录信息。使用这种简化的方法时，我们可以在一个远程网站的域上对用户身份进行验证(该远程网站登录到一个与运行着Web 服务器的域有着信任关系的域)。

最后，如果用户都有个人数字证书，你可以把那些证书映射到本地域的NT帐户上。个人数字证书与服务器数字证书以同样的技术为基础，它证明用户身份标 识的合法性，所以可以取代NT的Challenge/Response(质询/回应)验证算法。Netscape和IE都自动在每一个页面请求中把证书信 息发送给IIS。IIS提供了一个让管理员把证书映射到NT帐户的工具。因此，我们可以用数字证书取代通常的提供帐户名字和密码的登录过程。

由此可见，通过NT帐户验证用户时我们可以使用多种实现方法。即使当用户通过IIS跨越Internet连接SQL Server时，选择仍旧存在。因此，你应该把NT验证作为首选的用户身份验证办法。

三、设置全局组

构造安全策略的下一个步骤是确定用户应该属于什么组。通常，每一个组织或应用程序的用户都可以按照他们对数据的特定访问要求分成许多类别。例如，会 计应用软件的用户一般包括：数据输入 *** 作员，数据输入管理员，报表编写员，会计师，审计员，财务经理等。每一组用户都有不同的数据库访问要求。

我们可以从以下几点进行保护：

1、使用安全的密码策略

2、使用安全的帐号策略

3、加强数据库日志的记录

4、管理扩展存储过程

5、使用协议加密

6、不要让人随便探测到你的TCP/IP端口

7、修改TCP/IP使用的端口

8、拒绝来自1434端口的探测

9、对网络连接进行IP限制

10、安装数据库审计系统（例如：昂楷数据库审计系统）

#云原生背景#

云计算是信息技术发展和服务模式创新的集中体现，是信息化发展的重要变革和必然趋势。随着“新基建”加速布局，以及企业数字化转型的逐步深入，如何深化用云进一步提升云计算使用效能成为现阶段云计算发展的重点。云原生以其高效稳定、快速响应的特点极大地释放了云计算效能，成为企业数字业务应用创新的原动力，云原生进入快速发展阶段，就像集装箱加速贸易全球化进程一样，云原生技术正在助力云计算普及和企业数字化转型。

云原生计算基金会（CNCF）对云原生的定义是：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可d性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式编程API。

#云安全时代市场发展#

云安全几乎是伴随着云计算市场而发展起来的，云基础设施投资的快速增长，无疑为云安全发展提供土壤。根据 IDC 数据，2020 年全球云安全支出占云 IT 支出比例仅为 11%，说明目前云安全支出远远不够，假设这一比例提升至 5%，那么2020 年全球云安全市场空间可达 532 亿美元，2023 年可达 1089 亿美元。

海外云安全市场：技术创新与兼并整合活跃。整体来看，海外云安全市场正处于快速发展阶段，技术创新活跃，兼并整合频繁。一方面，云安全技术创新活跃，并呈现融合发展趋势。例如，综合型安全公司 PaloAlto 的 Prisma 产品线将 CWPP、CSPM 和 CASB 三个云安全技术产品统一融合，提供综合解决方案及 SASE、容器安全、微隔离等一系列云上安全能力。另一方面，新兴的云安全企业快速发展，同时，传统安全供应商也通过自研+兼并的方式加强云安全布局。

国内云安全市场：市场空间广阔，尚处于技术追随阶段。市场规模上，根据中国信通院数据，2019 年我国云计算整体市场规模达 13345亿元，增速 386%。预计 2020-2022 年仍将处于快速增长阶段，到 2023 年市场规模将超过 37542 亿元。中性假设下，安全投入占云计算市场规模的 3%-5%，那么 2023 年中国云安全市场规模有望达到 1126 亿-1877 亿元。技术发展上，中国在云计算的发展阶段和云原生技术的程度上与海外市场还有一定差距。国内 CWPP 技术应用较为广泛，对于 CASB、CSPM 一些新兴的云安全技术应用较少。但随着国内公有云市场的加速发展，云原生技术的应用越来越广泛，我们认为CASB、SCPM、SASE 等新兴技术在国内的应用也将越来越广泛。

#云上安全呈原生化发展趋势#

云原生技术逐渐成为云计算市场新趋势，所带来的安全问题更为复杂。以容器、服务网格、微服务等为代表的云原生技术，正在影响各行各业的 IT 基础设施、平台和应用系统，也在渗透到如 IT/OT 融合的工业互联网、IT/CT 融合的 5G、边缘计算等新型基础设施中。随着云原生越来越多的落地应用，其相关的安全风险与威胁也不断的显现出来。Docker/Kubernetes 等服务暴露问题、特斯拉 Kubernetes 集群挖矿事件、Docker Hub 中的容器镜像被“投毒”注入挖矿程序、微软 Azure 安全中心检测到大规模 Kubernetes 挖矿事件、Graboid 蠕虫挖矿传播事件等一系列针对云原生的安全攻击事件层出不穷。

从各种各样的安全风险中可以一窥云原生技术的安全态势，云原生环境仍然存在许多安全问题亟待解决。在云原生技术的落地过程中，安全是必须要考虑的重要因素。

#云原生安全的定义#

国内外各组织、企业对云原生安全理念的解释略有差异，结合我国产业现状与痛点，云原生与云计算安全相似，云原生安全也包含两层含义：“面向云原生环境的安全”和“具有云原生特征的安全”。

面向云原生环境的安全，其目标是防护云原生环境中的基础设施、编排系统和微服务的安全。这类安全机制，不一定具备云原生的特性（比如容器化、可编排），它们可以是传统模式部署的，甚至是硬件设备，但其作用是保护日益普及的云原生环境。

具有云原生特征的安全，是指具有云原生的d性敏捷、轻量级、可编排等特性的各类安全机制。云原生是一种理念上的创新，通过容器化、资源编排和微服务重构了传统的开发运营体系，加速业务上线和变更的速度，因而，云原生系统的种种优良特性同样会给安全厂商带来很大的启发，重构安全产品、平台，改变其交付、更新模式。

#云原生安全理念构建#

为缓解传统安全防护建设中存在的痛点，促进云计算成为更加安全可信的信息基础设施，助力云客户更加安全的使用云计算，云原生安全理念兴起，国内外第三方组织、服务商纷纷提出以原生为核心构建和发展云安全。

Gartner提倡以云原生思维建设云安全体系

基于云原生思维，Gartner提出的云安全体系覆盖八方面。其中，基础设施配置、身份和访问管理两部分由云服务商作为基础能力提供，其它六部分，包括持续的云安全态势管理，全方位的可视化、日志、审计和评估，工作负载安全，应用、PaaS 和 API 安全，扩展的数据保护，云威胁检测，客户需基于安全产品实现。

Forrester评估公有云平台原生安全能力

Forrester认为公有云平台原生安全（Public cloud platform native security, PCPNS）应从三大类、37 个方面去衡量。从已提供的产品和功能，以及未来战略规划可以看出，一是考察云服务商自身的安全能力和建设情况，如数据中心安全、内部人员等，二是云平台具备的基础安全功能，如帮助和文档、授权和认证等，三是为用户提供的原生安全产品，如容器安全、数据安全等。

安全狗以4项工作防护体系建设云原生安全

（1）结合云原生技术的具体落地情况开展并落实最小权限、纵深防御工作，对于云原生环境中的各种组成部分，均可贯彻落实“安全左移”的原则，进行安全基线配置，防范于未然。而对于微服务架构Web应用以及Serverless应用的防护而言，其重点是应用安全问题。

（2）围绕云原生应用的生命周期来进行DevSecOps建设，以当前的云原生环境的关键技术栈“K8S + Docker”举例进行分析。应该在容器的全生命周期注重“配置安全”，在项目构建时注重“镜像安全”，在项目部署时注重“容器准入”，在容器的运行环境注重云计算的三要素“计算”“网络”以及“存储”等方面的安全问题。

（3）围绕攻击前、中、后的安全实施准则进行构建，可依据安全实施准则对攻击前、中、后这三个阶段开展检测与防御工作。

（4）改造并综合运用现有云安全技术，不应将“云原生安全”视为一个独立的命题，为云原生环境提供更多支持的主机安全、微隔离等技术可赋能于云原生安全。

#云原生安全新型风险#

云原生架构的安全风险包含云原生基础设施自身的安全风险，以及上层应用云原生化改造后新增和扩大的安全风险。云原生环境面临着严峻的安全风险问题。攻击者可能利用的重要攻击面包括但不限于：容器安全、编排系统、软件供应链等。下面对重要的攻击面安全风险问题进行梳理。

#云原生安全问题梳理#

问题1：容器安全问题

在云原生应用和服务平台的构建过程中，容器技术凭借高d性、敏捷的特性，成为云原生应用场景下的重要技术支撑，因而容器安全也是云原生安全的重要基石。

（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：云原生等保合规问题

等级保护20中，针对云计算等新技术、新应用领域的个性安全保护需求提出安全扩展要求，形成新的网络安全等级保护基本要求标准。虽然编写了云计算的安全扩展要求，但是由于编写周期很长，编写时主流还是虚拟化场景，而没有考虑到容器化、微服务、无服务等云原生场景，等级保护20中的所有标准不能完全保证适用于目前云原生环境；

通过安全狗在云安全领域的经验和具体实践，对于云计算安全扩展要求中访问控制的控制点，需要检测主机账号安全，设置不同账号对不同容器的访问权限，保证容器在构建、部署、运行时访问控制策略随其迁移；

对于入侵防范制的控制点，需要可视化管理，绘制业务拓扑图，对主机入侵进行全方位的防范，控制业务流量访问，检测恶意代码感染及蔓延的情况；

镜像和快照保护的控制的，需要对镜像和快照进行保护，保障容器镜像的完整性、可用性和保密性，防止敏感信息泄露。

问题3：宿主机安全

容器与宿主机共享 *** 作系统内核，因此宿主机的配置对容器运行的安全有着重要的影响，比如宿主机安装了有漏洞的软件可能会导致任意代码执行风险，端口无限制开放可能会导致任意用户访问的风险。通过部署主机入侵监测及安全防护系统，提供主机资产管理、主机安全加固、风险漏洞识别、防范入侵行为、问题主机隔离等功能，各个功能之间进行联动，建立采集、检测、监测、防御、捕获一体化的安全闭环管理系统，对主机进行全方位的安全防护，协助用户及时定位已经失陷的主机，响应已知、未知威胁风险，避免内部大面积主机安全事件的发生。

问题4：编排系统问题

编排系统支撑着诸多云原生应用，如无服务、服务网格等，这些新型的微服务体系也同样存在着安全问题。例如攻击者编写一段代码获得容器的shell权限，进而对容器网络进行渗透横移，造成巨大损失。

Kubernetes架构设计的复杂性，启动一个Pod资源需要涉及API Server、Controller、Manager、Scheduler等组件，因而每个组件自身的安全能力显的尤为重要。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框架进行模拟红蓝对抗，评估企业目前的安全能力，对提升企业安全防护能力是很好的参考。

第一、防丢失，所以，要经常备份。

第二、防被盗窃，所以，数据库文件名命名要尽量乱七八糟，不容易让别人猜到。

第三、防被篡改，所以，管理员权限的用户名、密码，要保密，密码经常更改。密码不要太短。

数据库安全性问题一直是围绕着数据库管理员的恶梦 数据库数据的丢失以及数据库被非法用户的侵入使得数据库管理员身心疲惫不堪 本文围绕数据库的安全性问题提出了一些安全性策略 希望对数据库管理员有所帮助 不再夜夜恶梦 数据库安全性问题应包括两个部分 一 数据库数据的安全它应能确保当数据库系统DownTime时 当数据库数据存储媒体被破坏时以及当数据库用户误 *** 作时 数据库数据信息不至于丢失 二 数据库系统不被非法用户侵入它应尽可能地堵住潜在的各种漏洞 防止非法用户利用它们侵入数据库系统 对于数据库数据的安全问题 数据库管理员可以参考有关系统双机热备份功能以及数据库的备份和恢复的资料 以下就数据库系统不被非法用户侵入这个问题作进一步的阐述 组和安全性在 *** 作系统下建立用户组也是保证数据库安全性的一种有效方法 Oracle程序为了安全性目的一般分为两类 一类所有的用户都可执行 另一类只DBA可执行 在Unix环境下组设置的配置文件是/etc/group 关于这个文件如何配置 请参阅Unix的有关手册 以下是保证安全性的几种方法 ( ) 在安装Oracle Server前 创建数据库管理员组(DBA)而且分配root和Oracle软件拥有者的用户ID给这个组 DBA能执行的程序只有 权限 在安装过程中SQLDBA系统权限命令被自动分配给DBA组 ( ) 允许一部分Unix用户有限制地访问Oracle服务器系统 增加一个由授权用户组成的Oracle组 确保给Oracle服务器实用例程Oracle组ID 公用的可执行程序 比如SQLPlus SQLForms等 应该可被这组执行 然后该这个实用例程的权限为 它将允许同组的用户执行 而其他用户不能 ( ) 改那些不会影响数据库安全性的程序的权限为 注 在我们的系统中为了安装和调试的方便 Oracle数据库中的两个具有DBA权限的用户Sys和System的缺省密码是manager 为了您数据库系统的安全 我们强烈建议您该掉这两个用户的密码 具体 *** 作如下 在SQLDBA下键入 alter user sys indentified by password;alter user system indentified by password;其中password为您为用户设置的密码 Oracle服务器实用例程的安全性以下是保护Oracle服务器不被非法用户使用的几条建议 ( ) 确保$ORACLE_HOME/bin目录下的所有程序的拥有权归Oracle软件拥有者所有 ( ) 给所有用户实用便程(sqiplus sqiforms exp imp等) 权限 使服务器上所有的用户都可访问Oracle服务器 ( ) 给所有的DBA实用例程(比如SQLDBA) 权限 Oracle服务器和Unix组当访问本地的服务器时 您可以通过在 *** 作系统下把Oracle服务器的角色映射到Unix的组的方式来使用Unix管理服务器的安全性 这种方法适应于本地访问 在Unix中指定Oracle服务器角色的格式如下 ora_sid_role[_dla]其中sid 是您Oracle数据库的oracle_sid role是Oracle服务器中角色的名字 d(可选)表示这个角色是缺省值 a(可选)表示这个角色带有WITH ADMIN选项 您只可以把这个角色 授予其他角色 不能是其他用户 以下是在/etc/group文件中设置的例子 ora_test_osoper_d:NONE: :jim narry scottora_test_osdba_a:NONE: :patora_test_role :NONE: :bob jane tom mary jimbin:NONE: :root oracle dbaroot:NONE: :root词组 ora_test_osoper_d 表示组的名字 词组 NONE 表示这个组的密码 数字 表示这个组的ID 接下来的是这个组的成员 前两行是Oracle服务器角色的例子 使用test作为sid osoper和osdba作为Oracle服务器角色的名字 osoper是分配给用户的缺省角色 osdba带有WITH ADMIN选项 为了使这些数据库角色起作用 您必须shutdown您的数据库系统 设置Oracle数据库参数文件initORACLE_SID ora中os_roles参数为True 然后重新启动您的数据库 如果您想让这些角色有connect internal权限 运行orapwd为这些角色设置密码 当您尝试connect internal时 您键入的密码表示了角色所对应的权限 SQLDBA命令的安全性如果您没有SQLPLUS应用程序 您也可以使用SQLDBA作SQL查权限相关的命令只能分配给Oracle软件拥有者和DBA组的用户 因为这些命令被授予了特殊的系统权限 ( ) startup( ) shutdown( ) connect internal数据库文件的安全性Oracle软件的拥有者应该这些数据库文件($ORACLE_HOME/dbs/ dbf)设置这些文件的使用权限为 文件的拥有者可读可写 同组的和其他组的用户没有写的权限 Oracle软件的拥有者应该拥有包含数据库文件的目录 为了增加安全性 建议收回同组和其他组用户对这些文件的可读权限 网络安全性当处理网络安全性时 以下是额外要考虑的几个问题 ( ) 在网络上使用密码在网上的远端用户可以通过加密或不加密方式键入密码 当您用不加密方式键入密码时 您的密码很有可能被非法用户截获 导致破坏了系统的安全性 ( ) 网络上的DBA权限控制您可以通过下列两种方式对网络上的DBA权限进行控制 A 设置成拒绝远程DBA访问 B 通过orapwd给DBA设置特殊的密码 建立安全性策略系统安全性策略( ) 管理数据库用户数据库用户是访问Oracle数据库信息的途径 因此 应该很好地维护管理数据库用户的安全性 按照数据库系统的大小和管理数据库用户所需的工作量 数据库安全性管理者可能只是拥有create alter 或drop数据库用户的一个特殊用户 或者是拥有这些权限的一组用户 应注意的是 只有那些值得信任的个人才应该有管理数据库用户的权限 ( ) 用户身份确认数据库用户可以通过 *** 作系统 网络服务 或数据库进行身份确认 通过主机 *** 作系统进行用户身份认证的优点有 A 用户能更快 更方便地联入数据库 B 通过 *** 作系统对用户身份确认进行集中控制 如果 *** 作系统与数据库用户信息一致 那么Oracle无须存储和管理用户名以及密码 C 用户进入数据库和 *** 作系统审计信息一致 ( ) *** 作系统安全性A 数据库管理员必须有create和delete文件的 *** 作系统权限 B 一般数据库用户不应该有create或delete与数据库相关文件的 *** 作系统权限 C 如果 *** 作系统能为数据库用户分配角色 那么安全性管理者必须有修改 *** 作系统帐户安全性区域的 *** 作系统权限 数据的安全性策略数据的生考虑应基于数据的重要性 如果数据不是很重要 那么数据的安全性策略可以稍稍放松一些 然而 如果数据很重要 那么应该有一谨慎的安全性策略 用它来维护对数据对象访问的有效控制 用户安全性策略( ) 一般用户的安全性A 密码的安全性如果用户是通过数据库进行用户身份的确认 那么建议使用密码加密的方式与数据库进行连接 这种方式的设置方法如下 在客户端的oracle ini文件中设置ora_encrypt_login数为true 在服务器端的initORACLE_SID ora文件中设置dbling_encypt_login参数为true B 权限管理对于那些用户很多 应用程序和数据对象很丰富的数据库 应充分利用 角色 这个机制所带的方便性对权限进行有效管理 对于复杂的系统环境 角色 能大大地简化权限的管理 ( ) 终端用户的安全性您必须针对终端用户制定安全性策略 例如 对于一个有很多用户的大规模数据库 安全性管理者可以决定用户组分类 为这些用户组创建用户角色 把所需的权限和应用程序角色授予每一个用户角色 以及为用户分配相应的用户角色 当处理特殊的应用要求时 安全性管理者也必须明确地把一些特定的权限要求授予给用户 您可以使用 角色 对终端用户进行权限管理 数据库管理者安全性策略( ) 保护作为sys和system用户的连接当数据库创建好以后 立即更改有管理权限的sys和system用户的密码 防止非法用户访问数据库 当作为sys和system用户连入数据库后 用户有强大的权限用各种方式对数据库进行改动 改动sys和system用户的密码的方法 可参看前面的相关部分 ( ) 保护管理者与数据库的连接应该只有数据库管理者能用管理权限连入数据库 当以sysdba或startup shutdown 和recover或数据库对象(例如create drop 和delete等)进行没有任何限制的 *** 作 ( ) 使用角色对管理者权限进行管理应用程序开发者的安全性策略( ) 应用程序开发者和他们的权限数据库应用程序开发者是唯一一类需要特殊权限组完成自己工作的数据库用户 开发者需要诸如create table create procedure等系统权限 然而 为了限制开发者对数据库的 *** 作 只应该把一些特定的系统权限授予开发者 ( ) 应用程序开发者的环境A 程序开发者不应与终端用户竞争数据库资源 B 用程序开发者不能损害数据库其他应用产品 ( ) free和controlled应用程序开发应用程序开发者有一下两种权限 A free development应用程序开发者允许创建新的模式对象 包括table index procedure package等 它允许应用程序开发者开发独立于其他对象的应用程序 B controlled development应用程序开发者不允许创建新的模式对象 所有需要table indes procedure等都由数据库管理者创建 它保证了数据库管理者能完全控制数据空间的使用以及访问数据库信息的途径 但有时应用程序开发者也需这两种权限的混和 ( ) 应用程序开发者的角色和权限 lishixinzhi/Article/program/Oracle/201311/16746

1、优化设计的技巧

(1) 如果一个字段需要经常更改，则采用以空间换时间的设计方法

最常见的例子是用户积分登录次数的累加，按照范式设计，在users表中建立一个字段us_scores,以后需要在用户积分改变时采用update的语句进行修改。但是知道 update语句的执行速度是很慢的，为了避免大量重复使用它，优化的设计方案是建立us_scores表，存储每次增加的积分，在查询是采用SQL语句的sum方法来计算之。

(2) 关联字段类型尽可能定义为数字类型

(3) 表的序列字段必须是数字类型

(4) 若数据库有移植的可能性，不使用存储过程及触发器

(5) 建立恰当的索引

索引的建立是加快数据库查询的基本技巧之一，通常的建议是，只有百万级的记录的表格才应该建立索引。

，命名都应该作为非常重要的事情来看待，表、序列、字段、索引的命名技巧可以归结如下：

(1) 关联字段名称必须相同，名称以基础表的字段名称为准

(2) 序列名字跟表字段名字相同

(3) 关联表的名称应该是被关联的表用“_”连接起来组成的

(4) 字段定义的前两位是表名的缩写，第三位是下划线

一，保证规范，序列名称必须是唯一的，而且，一般的序列就是这个表的id字段。如果不加前缀，那么字段都叫做id就会违背惟一性原则。

第二，为了将来关联查询语句的书写方便。

(5) 索引的名字和表的名字相同

(6) 常用字段采用固定定义

为了提高大数据量的表格的查询速度，可以采用建立适当的索引方式。如果一个表只有一个索引，建议索引的名字跟表相同，如果有多个索引，则为表名称加下划线加索引列名称。

最安全的设计方案是，Web数据库和测试数据库分离。Web数据库权限只被管理员一个人掌握。

关于MySQL数据库设计

的优化措施还需要经过数据库设计人员的不断发掘，从数据库设计中不断的发现问题，提出解决问题的方法，才能将数据库的性能优化的更好更全面。

以上就是关于sqlserver有哪些安全策略全部的内容，包括:sqlserver有哪些安全策略、如何实现对数据库系统的安全防护、在IT项目建设中，如何保证数据库安全性等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！