aspnet_membershipに関する疑問があります。私の会社の私のデータベースチームは私にaspnet_membershipを使用させませんでした。この機能は、私の会社のポリシーを破るいくつかのものをインストールするためにいくつかのストアドプロシージャを使用するためです。彼らはこの機能がいくらかのリスクをもたらす可能性があると言いましたが、私がそれを使用すればどんなリスクが出るか分かりません。aspnet_membershipを使用した場合のリスク
誰もがこの問題について考えているのですか？
あなたの「データベースチーム」は明らかに編集不能です。 aspnet_regsql.exeツールでデータベースを作成すると、どのようなセキュリティリスクが予想されますか？私は多くの管理者が、舞台裏で何が起こっているのかを正確に知りたいので、ウィザードを使って不安を感じることを理解できます。この場合、コマンドラインツールを使用すると高度なカスタマイズが可能になり、ウィザードモードよりも優先する必要があります。
おそらくあなたとあなたのデータベースチームは、あなたが知らないことについて頑強ではなく、ツールのpublished implementationを読んでください。残念ながら "Creating the Application Services Database for SQL Server"が見つかった場合は、独自のMembershipProvidersとPersonalizationProvidersを作成し、独自のデータベース構造に組み込むことは可能です。
私はこれが古い質問であることを知っていますが、（ほとんどの良い質問がするように）それは私に考えさせました。
私は特定のシナリオで、データベースチームの視点を見ることができます：
あなたは任務を完全に分離し、ANに行われたすべての変更を徹底的にステップバイステップのドキュメントを必要とコンプライアンス規制の対象となっています環境。これは、あなた自身で（どのようにうまく文書化されているかテストされていても）何らかのユーティリティを実行することはできないことを意味します。それを承認するために別のチームに渡す必要があり、そのチームは潜在的な影響を（理論的に）理解しなければなりません。
おそらく、オブジェクトセキュリティポリシーによる非常に細かいオブジェクトが存在し、データベースチームは自動生成テーブル構造がこれに違反すると感じています。
セキュリティ違反ではありませんが、指定した命名基準によっては、ツールによって作成された表/手順がこれらの規則に違反する可能性があります。
おそらくあなたは財務や医療の分野で働いており、特定のセキュリティ要件が満たされている必要があります。無知か研究を通して、あなたのデータベースチームは、メンバーシップデータベースがこれらの要件を満たしていないと信じています。
私は多くの場合余計な時間を費やす恐れのある厳しいセキュリティポリシーを持つ多くの企業と協力してきました。反対に、これらの政策を守らないと、悲惨な結果が出る可能性があります（米国では数百万ドルの罰金が科せられます）。
要約：ASP.Net認証/認可スキームが適切である場合は、データベースチームを内部に教育して快適になるように時間を投資してください。彼らの反対意見に耳を傾ける。 DBAは環境を過度に保護することができますが、多くの場合、企業の主要資産を担当しています。
@Cerebrusが指摘しているように、ASP.Netセキュリティを使用するにはさまざまな方法があります。意味のある部分を活用してみてください。データベースチームが依然として「取得」していない（または有効な異論を提起していない）場合、ASP.Netに堅牢なセキュリティを実装するための他にも多くの方法があります。