在共享 SQL Server 上以 dbo 作为所有者创建表和查询？
我正在开发一个数据库，该数据库最终将驻留在主机（托管提供商）上的共享 SQL Server 2008 数据库上。我注意到所有的表和查询都属于 dbo。我想知道在共享主机上这是否是一个安全问题。以及分配数据库对象所有权的最佳实践是什么。我应该将数据库对象的所有权转移给共享托管环境中数据库的管理员用户吗？
谢谢
I'm developing a database that would eventually live on a shared SQL Server 2008 database on the host machine (at hosting provider). I noticed that all the tables and queries are owned by the dbo. I would like to know if this is a security issue when on a shared host. and what is the best practice for assigning ownership of database objects. Should I transfer the ownership of the db objects to the db's admin user in a shared hosting environment?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
dbo 架构是管理员或数据库所有者架构。它也是创建表时的默认架构，除非采取步骤对其进行更改。
即使在托管环境中，您也可以控制数据库内的安全性。您必须关注安全策略，并根据该策略授予、撤销或拒绝对数据库中对象的权限。单独避免使用 dbo 模式并不能提高安全性。
The dbo schema is the admin, or DB owner, schema. It is also the default schema when creating tables unless steps are taken to change it.
You can control the security within the database, even in a hosted environment. You must focus on your security strategy and grant, revoke or deny rights to the objects in the database based on that strategy. Avoiding the dbo schema alone will not improve security.
使用 dbo 时的最佳实践 使用
dbo 创建对象/表时，这意味着这些对象的别名的登录名必须具有 db_owner 角色，进而意味着它可以在该数据库中“执行任何操作”。访问该数据库的用户通常主要需要 CRUD。即表中的数据和执行 SP 应该是该帐户应该能够执行的所有操作。尽管当 db_owner 时它可以做任何在我看来是安全缺陷的事情。
应该有一个用于应用程序访问的登录名 (svcact_app1)，它是一个服务帐户（非交互式），以及用于 DDL 等的 Windows 登录名，这些登录名是 db_owner 的 - 因此默认为 dbo。每个对象都可以由 dbo 拥有，但授权应授予关联用户以进行 svcact_app1 登录。
这提供了分离，应用程序连接只能修改数据并执行授予它的 SP，而不能执行其他任何操作。如果您不这样做，并且攻击者可以成功启动 SQL 注入，则攻击可能会删除故事、修改 SP 或任何其他内容。
Best practice when using dbo
When creating objects/tables with dbo it means that the login which aliases to those objects must have the db_owner role and in turn means it can "do anything" within that database. The user accessing that database would normally require CRUD mostly. I.e. data within tables and executing SP's should be all that account should be able to do. Though when db_owner it can do anything which in my opinion is a security flaw.
There should be a login for the application access (svcact_app1) which is a service account (not interactive) and Windows Logins for the the DDL etc which are db_owner's - and therefore defaults to dbo. Each object can be owned by dbo though the grants should grant back to the associated user for the svcact_app1 login.
This gives separation whereby the app connection can only modify the data and execute SP's which are granted to it and nothing else. If you do not do this, and an attacker can successfully launch a SQL Injection, the attack could drop tales, modify SP's, or anything.