aspnet_membership에 대해 의심의 여지가 있습니다. 내 회사의 데이터베이스 팀이 aspnet_membership을 사용하지 못하게했습니다. 이 기능은 일부 저장 프로 시저를 사용하여 회사의 정책을 위반하는 일부 항목을 설치하기 때문입니다. 그들은이 기능이 약간의 위험을 야기 할 수 있다고 말했지만, 만약 내가 그것을 사용한다면 어떤 위험을 겪을 지 모른다.aspnet_membership을 사용하면 어떤 위험이 발생합니까?
누구든지이 문제에 대해 어떤 생각이나 이유가 있습니까?
귀하의 "데이터베이스 팀"은 분명히 편집증 적입니다. aspnet_regsql.exe 도구가 데이터베이스를 만드는 경우 어떤 종류의 보안 위험이 예상됩니까? 나는 많은 관리자들이 마법사를 사용하여 불안감을 느낀다는 것을 알고 있습니다. 왜냐하면 그들은 뒤에서 무슨 일이 벌어지고 있는지 정확히 알고 싶어하기 때문입니다. 이 경우 명령 줄 도구를 사용하면 높은 수준의 사용자 지정이 가능하므로 마법사 모드보다 우선해야합니다.
아마 당신과 당신의 데이터베이스 팀은 당신이 무지하다는 것을 고집하지 않고 도구의 published implementation을 읽어야합니다. "Creating the Application Services Database for SQL Server"이 지나치게 많으면 자신 만의 MembershipProviders 및 PersonalizationProviders를 만들고 자신의 데이터베이스 구조와 통합 할 수 있습니다.
나는 이것이 오래된 질문이지만, (가장 좋은 질문처럼) 그것이 나를 생각하게했다.
나는 특정 시나리오에서 데이터베이스 팀의 관점 볼 수 있습니다:
당신은으로 만든 임무와 모든 변화의 철저한 단계별 문서의 완전한 분리를 요구하는 준수 규정이 적용됩니다 환경. 즉, 아무리 잘 문서화되거나 테스트 되었더라도 유틸리티를 실행할 수는 없습니다. 승인을 위해 다른 팀으로 전달해야하며 팀은 이론적으로 모든 잠재적 영향을 이해해야합니다.
아마도 개체 보안 정책에 의해 매우 세분화 된 개체가 있고 데이터베이스 팀에서는 자동 생성 테이블 구조가이 정책을 위반한다고 생각합니다.
보안 위반 사항은 아니지만 사용자가 보유한 명명 표준에 따라 도구로 만든 테이블/프로 시저가 해당 규칙을 위반하는 것일 수 있습니다.
아마도 재무 또는 건강 관리 분야에서 근무하고 있으며 특정 보안 요구 사항이 충족되어야합니다. 무지 또는 연구를 통해 데이터베이스 팀은 회원 데이터베이스가 이러한 요구 사항을 충족시키지 못할 것이라고 생각합니다.
저는 많은 여분의 시간을 소비하는 드라 코안 보안 정책이있는 많은 회사에서 일했습니다. 반대로, 그러한 정책을 따르지 않을 경우의 결과는주의/편집증이 일반적으로 승리하는 등의 끔찍한 결과를 초래할 수 있습니다 (미국에서는 수백만 달러 벌금이 부과됩니다).
요약 : ASP.Net 인증/권한 부여 체계가 잘 맞으면 내부적으로 데이터베이스 팀을 교육하여 시간을 투자하여 익숙해 지도록하십시오. 그들의 반대 의견을 들어라. DBA는 자신의 환경을 과도하게 보호 할 수 있지만 회사의 핵심 자산을 담당하는 경우가 많습니다.
@Cerebrus가 지적했듯이 ASP.Net 보안을 사용하는 방법에는 여러 가지가 있습니다. 의미있는 부분을 활용 해보십시오. 데이터베이스 팀이 여전히 "획득"하지 않거나 유효한 이의 제기를 제기하는 경우 ASP.Net에서 강력한 보안을 구현할 수있는 다른 방법이 많이 있지만 더 많은 노력이 필요합니다.