如果我使用 aspnet_membership 有什么风险
我对 aspnet_membership 有一些疑问。 我公司的数据库团队不允许我使用aspnet_membership。 因为此功能使用一些存储过程来安装一些违反我公司政策的东西。 他们说这个功能可能会带来一些风险，但我不知道如果我使用它会带来什么风险。
有人对这个问题有任何想法或理由吗？
I have some doubt about aspnet_membership. My database team of my company dosen't let me use aspnet_membership. Because this feature use some stored procedure to install some thing that break the policy of my company. They said this feature could make some risk but I don't know what risk that I'll get if I used it.
Does anyone have any idea or reason about this issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你的“数据库团队”显然是偏执的。 如果
aspnet_regsql.exe工具创建数据库，他们预计会出现什么样的安全风险？ 我可以理解许多管理员对使用向导感到不安，因为他们想确切地知道幕后发生了什么。 在这种情况下，命令行工具允许您高度定制，并且应该优于向导模式。也许您和您的数据库团队应该阅读已发布的实现 的工具，而不是固执地认为你不了解。 如果您仍然发现“为 SQL Server 创建应用程序服务数据库”过度杀伤力，很可能创建您自己的 MembershipProviders 和 PersonalizationProviders 并将它们与您自己的数据库结构合并。
Your "database team" is obviously paranoid. What sort of security risk do they anticipate if the
aspnet_regsql.exetool creates a database? I can understand that many Administrators feel uneasy using wizards because they want to know exactly what is going on behind the scenes. In this case, the command line tool allows you a high degree of customizability and should be preferred over the wizard mode.Perhaps you and your database team should read up on the published implementation of the tool, rather than being obstinate about which you are ignorant. If you still find "Creating the Application Services Database for SQL Server" to be overkill, it is quite possible to create your own MembershipProviders and PersonalizationProviders and incorporate them with your own database structure.
我知道这是一个老问题，但是（就像大多数好问题一样）它让我思考。
我可以看到您的数据库团队在某些情况下的观点：
您必须遵守合规性法规，这些法规要求完全分离职责并详细记录对环境所做的每项更改。 这意味着您不能自己运行任何实用程序（无论文档记录或测试如何）；您必须自己运行任何实用程序。 您必须将其交给另一个团队进行批准，并且该团队必须（理论上）了解每一个潜在影响。
也许存在一个非常细粒度的逐个对象安全策略，并且您的数据库团队认为自动生成的表结构会违反这一点。
这不是安全漏洞，但根据您所采用的命名标准，该工具创建的表/过程可能会违反这些约定。
不是安全漏洞，但
也许您从事金融或医疗保健工作，并且必须满足一组特定的安全要求。 由于无知或研究，您的数据库团队认为会员数据库无法满足这些要求。
我曾与许多公司合作过，这些公司都有严格的安全政策，这往往会导致花费大量的额外时间。 相反，不遵守这些政策可能会产生如此可怕的后果（在美国会被处以数百万美元的罚款），因此谨慎/偏执通常会获胜。
总之：如果 ASP.Net 身份验证/授权方案很适合，那么就花时间对数据库团队进行内部培训，以便他们能够适应它。 听取他们的反对意见； DBA 可能会过度保护他们的环境，但他们通常负责公司的关键资产。
正如 @Cerebrus 指出的，有许多不同的方法来使用 ASP.Net 安全性。 尝试利用有意义的部分。 如果您的数据库团队仍然没有“明白”（或提出有效的反对意见），还有很多其他方法可以在 ASP.Net 中实现强大的安全性，只是需要付出更多的努力。
I know this is an old question, but (as most good questions do) it made me think.
I can see the perspective of your database team in certain scenarios:
You are subject to compliance regulations that require complete separation of duties and thorough step-by-step documentation of every change made to an environment. This means that you can't just run any utility (no matter how well-documented or tested) on your own; you must hand it off to another team for approval, and that team must understand (in theory) every potential impact.
Perhaps there is a very granular object by object security policy in place, and your database team feels that auto-generated table structures would violate this.
Not a security breach, but depending on naming standards you have in place, the tables/procedures created by the tool may violate those conventions.
Perhaps you work in finance or healthcare and there is a specific set of security requirements that must be met. Either through ignorance or research, your database team believes that the membership database will not meet these requirements.
I've worked with many companies that have draconian security policies that often cause a great deal of extra time to be spent. Conversely, the consequences of not following those policies can have such dire consequences (multi-million dollar fines here in the US) that caution/paranoia usually wins out.
In summary: if the ASP.Net authentication/authorization scheme is a good fit, then invest the time in educating the database team on its internals so they can be comfortable with it. Listen to their objections; DBAs can be over-protective of their environments, but they often are responsible for key assets of a company.
As @Cerebrus pointed out, there are many different ways to use ASP.Net security. Try to leverage the parts that make sense. If your database team still doesn't "get it" (or raises valid objections) there are plenty of other ways to implement robust security in ASP.Net, they just require more effort.