数据库管理员希望保护其千兆字节的重要业务数据免受未经授权的外部人员和企图超越其权限的内部人士的窥视，因此安全性至关重要。 所有的关系数据库管理系统都提供某种内在的安全机制，旨在将这些威胁降到最低。 它们的范围从Microsoft Access提供的简单密码保护到高级关系数据库（如Oracle和Microsoft SQL Server）支持的复杂用户/角色结构。 本文重点介绍实现结构化查询语言 （或SQL ）的所有数据库通用的安全机制。 我们将一起完成加强数据访问控制并确保数据安全的过程。
用户
基于服务器的数据库都支持类似于计算机操作系统中使用的用户概念。 如果您熟悉在Microsoft Windows NT和Windows 2000中找到的用户/组层次结构，则会发现SQL Server和Oracle支持的用户/角色分组非常相似。
强烈建议您为将要访问数据库的每个人创建个人数据库用户帐户。 技术上可以在用户之间共享帐户，或者简单地为每种需要访问数据库的用户类型使用一个用户帐户，但是我强烈劝阻这种做法有两个原因。 首先，它将消除个人责任 - 如果用户对数据库进行更改（假设通过给自己提高5,000美元），则通过使用审计日志将无法追溯到特定人员。 此外，如果特定用户离开您的组织并且您希望从数据库中删除他或她的访问权限，您将被迫更改所有用户依赖的密码。
创建用户帐户的方法因平台而异，您必须查阅您的DBMS特定文档以了解确切的过程。 Microsoft SQL Server用户应该调查sp_adduser存储过程的使用情况。 Oracle数据库管理员会发现CREATE USER命令很有用。 您也可能想要调查替代身份验证方案。 例如，Microsoft SQL Server支持使用Windows NT集成安全性。 在这种方案下，用户通过其Windows NT用户帐户被识别到数据库，并且不需要输入额外的用户ID和密码来访问数据库。 这种方法在数据库管理员中非常流行，因为它将帐户管理的负担转移给了网络管理人员，并为最终用户提供了简单的登录功能。
角色
如果您处于少数用户的环境中，您可能会发现创建用户帐户并直接为其分配权限足以满足您的需求。 但是，如果您拥有大量用户，则很可能会因维护帐户和适当的权限而负担过重。 为了减轻这种负担，关系数据库支持角色的概念。 数据库角色的功能与Windows NT组相似。 用户帐户分配给角色，然后将权限作为一个整体分配给角色，而不是单独的用户帐户。 例如，我们可以创建DBA角色，然后将管理人员的用户帐户添加到此角色。 一旦我们完成了这个任务，我们可以通过简单地为角色分配权限来为所有现在（和将来）的管理员分配特定的权限。 再一次，创建角色的过程因平台而异。 MS SQL Server管理员应调查sp_addrole存储过程，而Oracle DBA应使用CREATE ROLE语法。
授予权限
现在我们已经将用户添加到我们的数据库中，现在可以通过添加权限来加强安全性。 我们的第一步将是为我们的用户授予适当的数据库权限。 我们将通过使用SQL GRANT语句来完成此操作。
以下是该语句的语法：
授予<权限>
[ON
]
TO <用户/角色>
[有赠送选项]
现在，让我们一行一行看看这个说法。 第一行GRANT 允许我们指定我们授予的特定表权限。 这些可以是表级权限（如SELECT，INSERT，UPDATE和DELETE）或数据库权限（例如CREATE TABLE，ALTER DATABASE和GRANT）。 可以在单个GRANT语句中授予多个权限，但表级权限和数据库级权限可能不会合并到一个语句中。
第二行ON
用于为表级权限指定受影响的表。 如果我们授予数据库级权限，则此行将被省略。 第三行指定正在被授予权限的用户或角色。
最后，第四行WITH GRANT OPTION是可选的。 如果该行包含在该语句中，则受影响的用户也可以将这些相同的权限授予其他用户。 请注意，将权限分配给角色时，不能指定WITH GRANT OPTION。
例子
我们来看几个例子。 在我们的第一种情况下，我们最近雇用了一组42名数据录入员，他们将增加和维护客户记录。 他们需要能够访问Customers表中的信息，修改此信息并向表中添加新记录。 他们不应该能够从数据库中完全删除记录。 首先，我们应该为每个操作员创建用户帐户，然后将它们全部添加到新角色DataEntry中。 接下来，我们应该使用以下SQL语句为它们授予适当的权限：
授予选择，插入，更新
ON客户
到DataEntry
这就是它的全部！ 现在让我们来看看我们分配数据库级权限的情况。 我们希望允许DBA角色的成员将新表添加到我们的数据库中。 此外，我们希望他们能够授予其他用户同样的权限。 这是SQL语句：
授予创建表
致DBA
赠与选项
请注意，我们已经包含了WITH GRANT OPTION行，以确保我们的DBA可以将此权限分配给其他用户。
删除权限
一旦我们授予权限，通常证明有必要在以后撤销它们。 幸运的是，SQL为我们提供了REVOKE命令来删除以前授予的权限。 语法如下：
REVOKE [授予选项] <权限>
ON
FROM
您会注意到，该命令的语法与GRANT命令的语法相似。 唯一的区别在于WITH GRANT OPTION是在REVOKE命令行上指定的，而不是在命令的末尾。 举个例子，让我们想象一下，我们想撤销Mary之前授予的从Customers数据库中删除记录的权限。 我们将使用以下命令：
REVOKE DELETE
ON客户
玛丽
这就是它的全部！ 还有一个额外的机制是由Microsoft SQL Server支持的，值得一提的是DENY命令。 这个命令可以用来显式拒绝他们可能通过当前或将来角色成员身份获得的用户权限。 语法如下：
DENY <权限>
ON
TO <用户/角色
例子
回到我们之前的例子，我们假设Mary也是可以访问Customers表的Managers角色的成员。 之前的REVOKE声明不足以拒绝她进入桌子。 它将通过以她的用户帐户为目标的GRANT语句删除授予她的权限，但不会影响通过其在Managers角色中的成员资格获得的权限。 但是，如果我们使用DENY语句，它将阻止她继承权限。 这里是命令：
拒绝删除
ON客户
对玛丽
DENY命令实质上在数据库访问控制中创建了“否定权限”。 如果我们后来决定授予Mary从Customers表中删除行的权限，我们不能简单地使用GRANT命令。 该命令将立即被现有的DENY覆盖。 相反，我们首先使用REVOKE命令删除否定权限条目，如下所示：
REVOKE DELETE
ON客户
玛丽
您会注意到，该命令与用于删除肯定权限的命令完全相同。 请记住，DENY和GRANT命令都以类似的方式工作* mdash;它们都在数据库访问控制机制中创建权限（正数或负数）。 REVOKE命令删除指定用户的所有正面和负面权限。 一旦发布此命令，Mary将能够从表中删除行，如果她是拥有该权限的角色的成员。 或者，可以发出GRANT命令来直接向她的帐户提供DELETE权限。
在本文的整个过程中，您都了解了标准查询语言支持的访问控制机制。 本介绍应该为您提供一个良好的起点，但我鼓励您引用DBMS文档以了解您的系统支持的增强安全措施。 您会发现很多数据库都支持更高级的访问控制机制，例如授予特定列的权限。