.NET DLL에 연결 문자열을 저장하는 가장 좋은 방법은 무엇입니까?

StackOverflow https://stackoverflow.com/questions/6113

문제

우리 팀이 현재 개발 중인 애플리케이션에는 모든 데이터베이스 액세스를 수행하는 데 사용되는 DLL이 있습니다.데이터베이스는 방화벽 뒤에 있고 도메인 서버는 그렇지 않기 때문에 애플리케이션은 신뢰할 수 있는 연결을 사용할 수 없습니다.따라서 연결 문자열에는 DB 사용자 이름과 비밀번호가 필요한 것으로 보입니다.DLL에는 현재 하드 코딩된 데이터베이스 연결 문자열이 있지만 어셈블리를 분해할 수 있고 사용자 이름과 비밀번호가 바로 공개되어 있으므로 시작할 때 이 작업을 수행하고 싶지 않습니다.

요구 사항 중 하나는 비밀번호를 몇 달에 한 번씩 변경해야 하므로 이를 내부 사용자 기반으로 확대해야 한다는 것입니다.

어셈블리에 저장하지 않고 전체 사용자 기반에 쉽게 배포할 수 있는 방식으로 비밀번호를 암호화하여 저장할 수 있는 방법이 있습니까?

업데이트:답변해주신 모든 분들께 감사드립니다.나는 나에게 몇 가지 질문에 대답하려고 노력할 것입니다 ...데이터 DLL은 ASP.NET WebForms와 VB.NET WinForms 모두에서 사용됩니다.응용 프로그램이 자체 구성 파일을 가질 수 있다는 것을 이해하지만 DLL용 구성 파일에서는 아무것도 본 적이 없습니다.불행하게도 저는 직장에서 Jon Galloway 포스트에 접근할 수 없어서 그것이 효과가 있을지 판단할 수 없습니다.개발 관점에서 우리는 웹 서비스를 내부적으로 사용하고 싶지 않지만 내년쯤에는 제3자에게 제공할 수도 있습니다.방화벽을 통해 사용자를 인증할 수 없기 때문에 가장이 작동하지 않을 것 같습니다.사용자(또는 이전 사용자)가 공격자가 될 수 있으므로 우리는 이를 모든 사람으로부터 보호하고 있습니다!

도움이 되었습니까?

해결책

확실하지는 않지만 구성 파일에 넣고 구성 파일을 암호화할 수 있다고 생각합니다.

업데이트:Jon Galloway의 게시물 보기 여기.

다른 팁

악의적인 사람이 구성 파일에서 자격 증명을 얻을 것이라고 가정하십시오.이는 해당 사용자가 데이터베이스에 로그인하여 해당 사용자가 할 수 있는 모든 작업을 수행할 수 있음을 의미합니다.따라서 사용자가 테이블에 직접 액세스하는 것과 같은 나쁜 작업을 수행할 수 없도록 하십시오.해당 사용자가 특정 저장 프로시저만 실행할 수 있도록 하면 더 나은 상태가 될 것입니다.이곳은 스프록이 빛나는 곳 중 하나입니다.

이런 말을 하기는 싫지만 클라이언트 컴퓨터에 무언가를 추가하자마자 해당 데이터에 대한 보안이 사라집니다.

프로그램이 해당 문자열을 해독하려면 공격자가 동일한 작업을 수행할 수 있다고 가정해야 합니다.프로그램에 디버거를 연결하는 것도 한 가지 방법입니다.

서버에 연결 문자열을 저장하고 웹 연결을 통해 이를 얻는 것은 해당 웹 연결에도 보안이 필요하다는 것을 깨닫기 전까지는 좋을 것 같습니다. 그렇지 않으면 공격자가 프로그램을 가장하여 웹 연결과 통신할 수도 있습니다.

질문 하나 할게요.연결 문자열을 누구에게 숨기고 있습니까?사용자인가, 공격자인가?그리고 사용자라면 왜 그렇습니까?

다른 아이디어도 있습니다.언제든지 가장을 사용할 수 있습니다.또한 Enterprise Library(공용 라이브러리)를 사용할 수도 있습니다.

<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<enterpriseLibrary.ConfigurationSource selectedSource="Common">
<sources>
  <add name="Common" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
    filePath="Config\Exception.config" />
</sources>

.NET은 이와 같은 구성 값에 대한 암호화를 지원합니다.구성 파일에 남겨둘 수 있지만 암호화되어 있습니다.

모든 설정 정보가 구성 가능한 위치에 있는 DLL을 배포할 수 있기를 원하지만 실제로는 사용자 정의 작업을 수행하지 않는 한 DLL에 대한 편리한 .NET 구성 파일 중 하나를 가질 수 없습니다.

어쩌면 DLL이 어떤 책임을 져야 하는지 다시 생각해볼 필요가 있을 수도 있습니다.라이브러리 사용자가 연결 문자열을 전달하도록 요구하는 것이 가능하거나 합리적입니까?DLL이 구성 파일을 읽는다는 것이 정말 말이 되나요?

앱이 ASP.NET 앱인 경우 연결 문자열 섹션을 암호화하면 됩니다. web.config.

앱이 여러 컴퓨터에서 실행되는 클라이언트 애플리케이션인 경우 연결 문자열을 로컬로 저장하는 대신 웹 서비스나 다른 종류의 보안 메커니즘을 사용하여 중앙에 저장하는 것이 좋습니다.이렇게 하면 나중에 더 쉽게 업데이트할 수 있으며 연결 문자열을 로컬에 저장하지 않아도 됩니다.

그냥 몇 가지 생각.

업데이트됨: @라세브크

"서버에 연결 문자열을 저장하고 웹 연결을 통해 이를 얻는 것은 웹 연결에도 보안이 필요하다는 사실을 깨닫기 전까지는 좋을 것 같습니다. 그렇지 않으면 공격자가 프로그램을 가장하여 웹 연결과 통신할 수도 있습니다. "

웹 서비스의 보안은 암시적이었습니다.배포 유형에 따라 다양한 옵션(예: 클라이언트측 인증서)이 있습니다.

여러 옵션:

  1. web.config에 저장하고 암호화
  2. DLL에 저장하고 난독화(dotfuscator)
  3. web.config에 하나를 저장하고(물론 암호화됨) 데이터베이스에 저장합니다(여러 개를 사용해야 하고 암호화/암호 해독이 어려워지는 경우).
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top