我对aspnet_membership有一些疑问。我公司的数据库团队不允许我使用aspnet_membership。因为这个功能使用一些存储过程来安装一些违反我公司政策的东西。他们说这个功能可能会带来一些风险，但我不知道如果我使用它会有什么风险。
有没有人对此问题有任何想法或理由？
答案 0 :(得分：7)
你的“数据库团队”显然是偏执狂。如果aspnet_regsql.exe工具创建数据库，他们预计会遇到什么样的安全风险？我可以理解许多管理员使用向导感到不安，因为他们想知道幕后发生了什么。在这种情况下，命令行工具允许您高度自定义，并且应该优先于向导模式。
也许您和您的数据库团队应该阅读该工具的published implementation，而不是顽固地了解您的无知。如果您仍然认为“Creating the Application Services Database for SQL Server”过度，则很有可能创建自己的MembershipProviders和PersonalizationProviders并将它们与您自己的数据库结构合并。
答案 1 :(得分：0)
我知道这是一个老问题，但（正如大多数好问题所做的那样）让我思考。
我可以在某些情况下看到数据库团队的观点：
您必须遵守合规性规定，这些规定要求完全分离职责，并对环境所做的每项更改进行详尽的逐步记录。这意味着您不能自己运行任何实用程序（无论有多少文档或测试）;你必须把它交给另一个团队批准，那个团队必须理解（理论上）每一个潜在的影响。
对象安全策略可能存在一个非常精细的对象，您的数据库团队认为自动生成的表结构会违反此目的。
不是安全漏洞，但根据您的命名标准，该工具创建的表格/程序可能违反这些约定。
也许您在金融或医疗保健领域工作，并且必须满足一系列特定的安全要求。无论是通过无知还是研究，您的数据库团队都认为会员数据库不符合这些要求。
我曾与许多公司合作过，这些公司拥有严厉的安全政策，往往会花费大量的额外时间。相反，不遵守这些政策的后果可能产生如此可怕的后果（美国数百万美元的罚款），谨慎/偏执通常会胜出。
总结：如果ASP.Net身份验证/授权方案非常适合，那么就花时间在数据库团队的内部进行培训，以便他们能够熟悉它。倾听他们的反对意见; DBA可能过度保护他们的环境，但他们通常负责公司的关键资产。
正如@Cerebrus所指出的，有许多不同的方法可以使用ASP.Net安全性。尝试利用有意义的部分。如果你的数据库团队仍然“没有”（或提出有效的反对意见），还有很多其他的方法可以在ASP.Net中实现强大的安全性，他们只需要更多的努力。