在规划微软Azure SQL Database部署时,一定要考虑所有需要在深度防御策略中实现的安全措施。我们已经在前面一篇文章中详细介绍了实现基于防火墙的保护措施的一个方面。此外,我们还概括介绍了这个平台即服务(PaaS)产品中内置的验证、授权与加密特性。现在是时候更深入了解一些支持细粒度控制数据访问的授权方法了,它们最多可以深入到控制各个数据库对象和语句类型。
在很大程度上,Azure SQLDatabase集成的验证与授权机制基于成熟SQL Server实例所使用的相同原则,它既可以部署在内部网络,也可以部署在Azure IaaS虚拟机上。然而,它们之间有一些值得注意的重要区别。在验证方面……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
在规划微软Azure SQL Database部署时,一定要考虑所有需要在深度防御策略中实现的安全措施。我们已经在前面一篇文章中详细介绍了实现基于防火墙的保护措施的一个方面。此外,我们还概括介绍了这个平台即服务(PaaS)产品中内置的验证、授权与加密特性。现在是时候更深入了解一些支持细粒度控制数据访问的授权方法了,它们最多可以深入到控制各个数据库对象和语句类型。
在很大程度上,Azure SQLDatabase集成的验证与授权机制基于成熟SQL Server实例所使用的相同原则,它既可以部署在内部网络,也可以部署在Azure IaaS虚拟机上。然而,它们之间有一些值得注意的重要区别。在验证方面,最重要的一点是缺少Windows集成身份验证的支持。实际上,在每次建立SQL Database连接时,用户都必须明确指定他们的登录身份。这种方式与传统SQL Server身份验证方式相同,即便如此,还有一个重要的小问题。具体地说就是密码重置,它会在本地使用场景中触发自动重新验证,从而导致会话中断,即要求中断当前会话,并且在重新连接之后才能继续使用Azure SQL Database。(选择采用这种方式的原因是为了消除自动重新连接可能对性能造成的负面影响,这对于基于云的服务而言尤为重要。)
从授权角度看,Azure SQLDatabase实现了方法更适合用在服务器层次上。最明显的原因是,现在不能使用权限最高的sa登录帐号和相应的sysadmin SQL服务器角色(以及所有其他固定的服务器角色)。相反,在管理一个托管各个SQL Database的逻辑SQL Server(包括表示一个数据库管理单元的Azure平台结构)时,必须用到主数据库中预定义的两个角色,其中包括:
- loginmanager -分配了足够创建和管理登录帐号的权限(而不是securityadmin固定服务器角色)
- dbmanager -分配了创建和管理数据库的权限(而不是dbcreator固定服务角色)
这个区别体现在服务级安全性的管理方式上,它可以避免管理员过分依赖于Object Explorer of the SQL Server Management Studio中Security文件夹的图形界面,迫使他们在连接主数据库时执行相应的T-SQL语句。(虽然SQL ServerManagement Studio会通过将连接自动重定向主数据库并在查询窗口自动生成SQL登录模板来实现透明的登录过程)。
用户数据库角色与传统SQL Server实现的已有角色相对应,并且包含以下角色:
- db_accessadmin分配了用于创建和管理数据库用户的权限。
- db_backupoperator分配了用于备份数据库的权限。
- db_datareader分配了用于从所有数据库表和视图读取数据的权限。
- db_datawriter分配了用于向所有数据库表和视图写入数据的权限。
- db_ddladmin分配了用于在数据库创建和管理对象的权限。
- db_denydatareader拒绝从数据库任何一个表和视图读取数据的权限。
- db_denydatawriter拒绝向数据库任何一个表和视图写入数据的权限。
- db_owner分配了用于执行所有数据库配置和管理的权限。
- db_securityadmin分配了用于管理数据库角色成员和权限的权限。
如果想要进一步细分访问权限,那么可以选择使用模式级和对象级安全性,这就像数据库角色一样,与管理员熟悉的本地数据库管理完全相同。具体地,你可以使用GRANT、REVOKE和DENY T-SQL语句控制每一个模式、对象实例或语句层次的权限。一定要记住,DENY优先级高于显式分配或基于角色的权限。
要创建登录帐号,你需要创建一个主数据库连接会话,而创建用户帐号需要直接连接目标数据库。这一点非常重要,因为同一个会话无法切换数据库上下文(原来通常可以通过执行语句USEdatabase T-SQL语句)——相反,你必须为每一个需要管理的数据库建立独立的会话。初始登录帐号(也就是服务器级主登录帐号)和主数据库中相同名称的用户都是初始化SQL Server实例时自动创建的,无论是使用AzureManagement Portal、Azure PowerShell模块还是执行相应的REST API初始化都是这样。从授权角度看,这个登录帐号是唯一的,因为它隐含就分配了loginmanager和dbmanager角色所关联的权限(即便它实际上不是这些角色的成员)。此外,你可以用它连接同一个逻辑服务器的任何一个数据库。
因此,你可以使用CREATE LOGIN T-SQL语句创建更多的登录帐号(查询主数据库的sys.sql_logins视图就可以列举所有的登录帐号)。要想使用这些帐号信息连接任何一个数据库(包括主数据库),必须先在该数据库上创建一个相对应的用户帐号。实际上,如果想要指定一个loginmanager或dbmanager角色的新成员,则需要先使用服务器级主登录帐号登录主数据库,创建一个新的登录帐号,然后再创建一个与此登录帐号相关联的用户(使用CREATEUSER (...) FROM LOGIN T-SQL语句),最后再执行sp_addrolemember存储过程。类似地,如果想让这些登录帐号可用于连接或管理任何一个用户数据库,则需要先连接该数据库,在该数据库上创建一个关联的用户帐号(同样是使用CREATEUSER (...) FROM LOGIN T-SQL语句),最后再执行sp_addrolemember存储过程将新创建的用户分配给一个或多个数据库级角色。然而,如果dbmanager的成员需要连接他们自己创建的数据,则不受这个要求的限制,因为他们隐含已经关联到dbo用户帐号(这意味着它已经是db_owner角色的成员)。
这就是我们总结的Azure SQLDatabase数据保护管理方法,其重点是使用权限作为防御未授权访问的额外措施。在后续文章中,我们将继续介绍在云和混合环境中运行SQL Server的相关问题。
翻译
TechTarget中国特约技术编辑,某高校计算机科学专业教师和网络实验室负责人,曾任职某网络国际厂商,关注数据中心、开发运维、数据库及软件开发技术。有多本关于思科数据中心和虚拟化技术的译著,如《思科绿色数据中心建设与管理》和《基于IP的能源管理》等。
相关推荐
-
不安全的Firebase数据库使关键数据面临风险
当开发人员无法对支持其移动应用程序的数据库或云实例执行身份验证时,这里会发生一种最简单且最具破坏性的安全事件。 […]
-
真正的甲骨文云战略vs. AWS和Azure
如今,甲骨文云战略正遭受重创。原产品开发主管Thomas Kurian离开,加盟谷歌云计算部门,再加上甲骨文混 […]
-
FaunaDB分布式云数据库瞄准事务性NoSQL
作为云计算平台领导者,近日AWS在其NoSQL软件-DynamoDB中增加了对事务处理工作负载的支持,从而进一 […]
-
Amazon RDS on VMware扩展内部云数据库
VMware和AWS公司围绕混合云深化了合作伙伴关系,并推出产品使VMware客户可在自己数据中心内访问亚马逊 […]