기존 ASP 응용 프로그램에서 연결 문자열을 보안하는 작업을 맡았으며 총알을 물고 ASP.NET 전체 응용 프로그램을 업그레이드해야하는지 아니면 간단한 수정이 필요한지 궁금합니다.ODBC 연결에서 일반 텍스트 암호를 사용해야합니까?
현재 응용 프로그램은 다음과 같이 연결 문자열을 가진 ODBC 데이터 소스에 연결 :
DSN=Mydb;uid=myuser;pwd=mypassword;DATABASE=mydb
내 질문은, 어떻게 든이 암호를 암호화하거나 방정식에서 ODBC를 제거하는 것이 가능하다?
도메인 사용자로 웹 응용 프로그램을 실행하고 연결 문자열에서 사용자 ID와 암호를 철자하는 대신 통합 보안을 사용할 수 있습니다.
ODBC가 아니라 OLEDB를 고려해 볼 수 있습니다. 필자는 일반적으로 후자를 권장합니다 (응용 프로그램의 구성이나 소스 코드를 변경하지 않고 dbs를 전환 할 수있는 ODBC 구성에서 제공되는 간접 참조가 필요할 때와 같이 예외가 발생할 수 있음).
EDIT : 질문을 빨리 읽으면서, 나는 당신이 MySQL을 사용하고 있다고 생각했다. (conn. string snippet에서이 "my"를 모두 사용했다.) 그러므로 다른 데이터베이스가 사용 중 ...
그러나 연결 문자열에서 암호를 제공하지 않으려는 경우이 유형의 연결에서 MySQL documentation은 대체 인증을 허용하지 않지만 accountid는 OLEDB를 사용할 수 없습니다 /암호.
따라서 통합 보안을 사용하여 ODBC를 호출하고 MySQL 계정 ID/암호를이 원본의 ODBC 구성 수준에 저장해야 할 수도 있습니다. 이런 식으로 암호는 응용 프로그램 수준에서 참조되지 않지만 (여전히 ODBC 구성에서 찾을 수 있습니다 ...). ODBC와
연결 문자열 키 = 통합 보안을 사용하기위한 값 쌍 연결 문자열에 유용한 기준이 적절하게 다른 대안은 (어떤 알고리즘을 사용하여 연결 문자열을 암호화하는 www.connectionstrings.com
라는
"Integrated Security=SSPI" which I believe is equivalent to "Trusted_Connection=yes"
인 또는 RSADLL과 같은 일부 구성 요소를 사용하여) 응용 프로그램에서 연결 문자열을 해독합니다.
관리자가 암호화 된 연결 문자열을 만들 수 있도록 서비스 페이지를 제공하는 것을 잊지 마십시오.
+1 데이터베이스 드라이버가 통합 보안을 지원하는 한 (대부분). – devstuff
도메인 사용자로 웹 응용 프로그램을 실행하면 다른 문제가 발생합니다.이 사용자는 기본 ASP 응용 프로그램 ID와 동일한 권한을 가지고 있어야합니다. 사용자 수명주기 유지 (예 : IIS가 만료되면 암호 변경, 일반 사용자 계정을 사용하는 것이 좋지 않을 수 있으므로 DB 연결을위한 별도의 도메인 계정을 만들어야 함) 이 사이트에서 실행중인 다른 웹 응용 프로그램이 데이터베이스 서버에 연결할 수 있도록 허용합니다. 환경 및 요구 사항에 따라 큰 문제는 아니지만 적어도 이러한 문제를 인식하고 있어야합니다. –