Microsoft MVP성태의 닷넷 이야기
VS.NET IDE: 201. C# - Typed DataSet(XSD)를 위한 연결 문자열 암호화 [링크 복사], [링크+제목 복사],
조회: 216
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
(연관된 글이 2개 있습니다.)

C# - Typed DataSet(XSD)를 위한 연결 문자열 암호화

이런 질문이 있군요. ^^

winform DataSet.xsd의 암호화 된 ConnectionString 사용 질문
; https://www.sysnet.pe.kr/3/0/5968

아마 요즘 닷넷을 시작하는 분들은 typed dataset에 대해 거의 모르실 텐데요, 제 책에서도 .NET Framework을 기반으로 다룰 때는 그 내용을 포함했지만 .NET Core/5+로 개정판을 내면서 해당 내용을 책에서는 없애고 공개된 PDF로 옮겼습니다.

그러니 혹시 궁금하신 분들은 PDF의,

공개된 3부 및 부록 - PDF 파일
; https://www.sysnet.pe.kr/book/cs12_free.pdf

46 페이지에 있는 "6.8.3.3 Typed DataSet (닷넷 프레임워크)" 절을 참고하시면 됩니다. 이번 글에서는, 그 방법을 알고 있다고 가정하고 시작합니다. ^^




그나저나 질문 글이 닷넷 포럼에도 있는데요, 거기가 더 자세해서 그나마 추측할 수 있게 되었습니다.

DataSet ConnectionString 암호화 문제
; https://forum.dotnetdev.kr/t/dataset-connectionstring/12944

문제를 정리해 볼까요?

우선, Visual Studio가 Typed dataset을 구성했을 때 연결 문자열 정보를 총 3곳에 저장합니다. 우선, Settings 파일과,

// Settings.settings 파일

<?xml version='1.0' encoding='utf-8'?>
<SettingsFile xmlns="http://schemas.microsoft.com/VisualStudio/2004/01/settings" CurrentProfile="(Default)" GeneratedClassNamespace="WindowsFormsApp1.Properties" GeneratedClassName="Settings">
  <Profiles />
  <Settings>
    <Setting Name="UnitTestDB2ConnectionString" Type="(Connection string)" Scope="Application">
      <DesignTimeValue Profile="(Default)">&lt;?xml version="1.0" encoding="utf-16"?&gt;
&lt;SerializableConnectionString xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
  &lt;ConnectionString&gt;Data Source=.;Initial Catalog=UnitTestDB2;Integrated Security=True;Encrypt=True;TrustServerCertificate=True&lt;/ConnectionString&gt;
  &lt;ProviderName&gt;System.Data.SqlClient&lt;/ProviderName&gt;
&lt;/SerializableConnectionString&gt;</DesignTimeValue>
      <Value Profile="(Default)">Data Source=.;Initial Catalog=UnitTestDB2;Integrated Security=True;Encrypt=True;TrustServerCertificate=True</Value>
    </Setting>
  </Settings>
</SettingsFile>

그 파일로부터 자동 생성된 cs 파일이 있고,

//...[생략]...

namespace WindowsFormsApp1.Properties {
    
    
    [global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "17.12.0.0")]
    internal sealed partial class Settings : global::System.Configuration.ApplicationSettingsBase {
        
        private static Settings defaultInstance = ((Settings)(global::System.Configuration.ApplicationSettingsBase.Synchronized(new Settings())));
        
        public static Settings Default {
            get {
                return defaultInstance;
            }
        }
        
        [global::System.Configuration.ApplicationScopedSettingAttribute()]
        [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
        [global::System.Configuration.SpecialSettingAttribute(global::System.Configuration.SpecialSetting.ConnectionString)]
        [global::System.Configuration.DefaultSettingValueAttribute("Data Source=.;Initial Catalog=UnitTestDB2;Integrated Security=True;Encrypt=True;T" +
            "rustServerCertificate=True")]
        public string UnitTestDB2ConnectionString {
            get {
                return ((string)(this["UnitTestDB2ConnectionString"]));
            }
        }
    }
}

마지막으로 Settings.settings 파일의 연결 문자열이 "Application" scope를 가진 탓에 app.config에 실제 연결 문자열이 들어가게 됩니다.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
    </configSections>
    <connectionStrings>
        <add name="WindowsFormsApp1.Properties.Settings.UnitTestDB2ConnectionString"
            connectionString="Data Source=.;Initial Catalog=UnitTestDB2;Integrated Security=True;Encrypt=True;TrustServerCertificate=True"
            providerName="System.Data.SqlClient" />
    </connectionStrings>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
</configuration>

이와 같이 저장된 연결 문자열은 쉽게 사용자에게 노출되므로 질문자는 Settings.settings에 있는 연결 문자열 항목을 아예 삭제한 것입니다. 그리곤 Visual Studio가 만든 XSD의 designer.cs 파일에 있는 InitConnection 메서드 내부의 연결 문자열 코드를,

private void InitConnection() {
    this._connection = new global::System.Data.SqlClient.SqlConnection();

    // 아래 코드를 삭제하고,
    // this._connection.ConnectionString = global::WindowsFormsApp1.Properties.Settings.Default.UnitTestDB2ConnectionString;

    // 이런 식으로 별도의 파일에 저장한 암호화된 연결 문자열을 복호화하여 사용하도록 코드 변경
    this._connection.ConnectionString = DecryptConnectionStringFromFile();
}

저런 식으로 변경했다고 합니다. 이렇게 되면, 일단 런타임에는 프로그램이 정상 동작하지만, Visual Studio에서 XSD 파일의 디자인 화면을 열어 편집하게 되면 이런 오류가 발생합니다.

enc_cs_for_xsd_1.png

Failed to insert column.

Unable to find connection 'UnitTestDB2ConnectionString' for object 'Settings'. The connection string could not be found in application settings, or the data provider associated with the connection string could not be loaded


질문자는, 디자인 타임에서의 이런 오류를 해결하고 싶다는 것이고!




그럼 해결 방법을 모색해 볼까요? 제 생각에는, InitConnection 메서드를 직접 수정하는 것부터 바람직하지 않은 방법으로 보입니다. 왜냐하면 해당 코드는 XSD 파일을 편집하면 다시 재생성되므로 그때마다 일일이 다시 코드를 수정해야 하기 때문입니다.

따라서 이런 경우에는 접근을 달리해야 합니다.

어떤 방법이 있을까요? ^^ 여기서 무엇보다 원하는 것은 InitConnection 메서드를 포함한 Designer.cs 파일은 수정하지 않게 만드는 것입니다. 그렇다면, 기존 코드를 재활용하는 방법을 써야 하는데요,

private void InitConnection() {
    this._connection = new global::System.Data.SqlClient.SqlConnection();
    this._connection.ConnectionString = global::WindowsFormsApp1.Properties.Settings.Default.UnitTestDB2ConnectionString;
}

차라리 Settings.Default.UnitTestDB2ConnectionString의 get 접근자를 변형하면 될 듯합니다. 가능할 법도 한 것이, Settings.Designer.cs에 정의한 클래스가 partial이기 때문입니다. 따라서 Settings.settings에 있던 연결 문자열 항목은 삭제하고 별도 파일에 속성을 이렇게 정의하면,

// 별도 파일에 정의 (Settings.partial.cs)

namespace WindowsFormsApp1.Properties
{
    partial class Settings : global::System.Configuration.ApplicationSettingsBase
    {
        public string UnitTestDB2ConnectionString
        {
            get
            {
                return DecryptConnectionStringFromFile();
            }
        }
    }
}

일단 빌드는 잘됩니다. 그런데, 저렇게 맞춰주었는데도 디자이너 화면에서는 여전히 오류가 발생합니다. 정확한 이유는 알 수 없지만, 비주얼 스튜디오의 디자인 타임에 실행하는 코드에 대한 특별한 제약(예전에 이와 관련해 글을 쓴 것 같은데 못 찾겠습니다. ^^;)으로 인해 연결 문자열을 저 코드에서 구하는 것이 아닌, Settings.settings 파일에 있는 XML 정보를 직접 읽어오는 것으로 보입니다.

// Settings.settings 파일

<?xml version='1.0' encoding='utf-8'?>
<SettingsFile xmlns="http://schemas.microsoft.com/VisualStudio/2004/01/settings" CurrentProfile="(Default)" GeneratedClassNamespace="WindowsFormsApp1.Properties" GeneratedClassName="Settings">
  <Profiles />
  <Settings>
    <Setting Name="UnitTestDB2ConnectionString" Type="(Connection string)" Scope="Application">
      <DesignTimeValue Profile="(Default)">&lt;?xml version="1.0" encoding="utf-16"?&gt;
&lt;SerializableConnectionString xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
  &lt;ConnectionString&gt;Data Source=.;Initial Catalog=UnitTestDB2;Integrated Security=True;Encrypt=True;TrustServerCertificate=True&lt;/ConnectionString&gt;
  &lt;ProviderName&gt;System.Data.SqlClient&lt;/ProviderName&gt;
&lt;/SerializableConnectionString&gt;</DesignTimeValue>
      <Value Profile="(Default)">Data Source=.;Initial Catalog=UnitTestDB2;Integrated Security=True;Encrypt=True;TrustServerCertificate=True</Value>
    </Setting>
  </Settings>
</SettingsFile>

결국, XSD designer가 제대로 동작하려면 어쩔 수 없이 저 설정이 꼭 존재해야 하는 것입니다.




불가능한 이유는 어림짐작으로 알게 됐는데, 이제 그럼 차선책을 찾아봐야 합니다. 여기서 변함없는 사실은, Settings.settings 파일에서 해결을 봐야 한다는 건데요, 제가 제안할 수 있는 가장 적절한 방법이라면 2개의 Settings.settings 파일을 운영하는 것입니다.

즉, 하나는 비주얼 스튜디오에서 디버깅 시에 사용할 Settings.settings 파일이고, 또 하나는 배포 시에 사용할 Settings.settings 파일입니다. 단지 같은 파일을 2개 가질 수 없으므로 후자의 파일 이름을 Settings.Release.settings로 두고 다음과 같이 csproj 파일을 수정하면 됩니다.

...[생략]...

  <!-- XSD 디자인을 위한 디버그용 settings 파일 -->
  <ItemGroup Condition=" '$(Configuration)' == 'Debug' ">
    <None Include="Properties\Settings.settings">
      <Generator>SettingsSingleFileGenerator</Generator>
      <LastGenOutput>Settings.Designer.cs</LastGenOutput>
    </None>
    <Compile Include="Properties\Settings.Designer.cs">
      <AutoGen>True</AutoGen>
      <DependentUpon>Settings.settings</DependentUpon>
      <DesignTimeSharedInput>True</DesignTimeSharedInput>
    </Compile>
  </ItemGroup>

  <!-- 배포본 빌드를 위한 Release용 settings 파일 -->
  <ItemGroup Condition=" '$(Configuration)' == 'Release' ">
    <None Include="Properties\Settings.Release.settings">
      <Generator>SettingsSingleFileGenerator</Generator>
      <LastGenOutput>Settings.Release.Designer.cs</LastGenOutput>
    </None>
    <Compile Include="Properties\Settings.Release.Designer.cs">
      <AutoGen>True</AutoGen>
      <DependentUpon>Settings.Release.settings</DependentUpon>
      <DesignTimeSharedInput>True</DesignTimeSharedInput>
    </Compile>
  </ItemGroup>

...[생략]...

물론, 각각의 파일에서 연결 문자열을 제외한 다른 설정은 동일하게 유지해야 한다는 정도의 수고는 감수해야 하는데 이번 예제에서는 별도의 설정은 없으므로 다음과 같은 내용으로 구성됩니다.

<!-- 디버그 버전의 Settings.settings 파일 -->

<?xml version='1.0' encoding='utf-8'?>
<SettingsFile xmlns="http://schemas.microsoft.com/VisualStudio/2004/01/settings" CurrentProfile="(Default)" GeneratedClassNamespace="WindowsFormsApp1.Properties" GeneratedClassName="Settings">
  <Profiles />
  <Settings>
    <Setting Name="UnitTestDB2ConnectionString" Type="(Connection string)" Scope="Application">
      <DesignTimeValue Profile="(Default)">&lt;?xml version="1.0" encoding="utf-16"?&gt;
&lt;SerializableConnectionString xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
  &lt;ConnectionString&gt;Data Source=.;Initial Catalog=UnitTestDB2;Integrated Security=True;Encrypt=True;TrustServerCertificate=True&lt;/ConnectionString&gt;
  &lt;ProviderName&gt;System.Data.SqlClient&lt;/ProviderName&gt;
&lt;/SerializableConnectionString&gt;</DesignTimeValue>
      <Value Profile="(Default)">Data Source=.;Initial Catalog=UnitTestDB2;Integrated Security=True;Encrypt=True;TrustServerCertificate=True</Value>
    </Setting>
  </Settings>
</SettingsFile>

<!-- 릴리스 버전의 Settings.Release.settings 파일 -->

<?xml version='1.0' encoding='utf-8'?>
<SettingsFile xmlns="http://schemas.microsoft.com/VisualStudio/2004/01/settings" CurrentProfile="(Default)">
  <Profiles />
  <Settings />
</SettingsFile>

이와 함께 Release 버전에서는 연결 문자열을 복호화해 가져오는 코드가 필요하므로 (전에 만들어 두었던) partial 클래스에 DEBUG 상수에 따른 조건부 컴파일을 추가하면 됩니다.

// 별도 파일에 정의 (Settings.partial.cs)

namespace WindowsFormsApp1.Properties
{
#if !DEBUG
    partial class Settings : global::System.Configuration.ApplicationSettingsBase
    {
        public string UnitTestDB2ConnectionString
        {
            get
            {
                return DecryptConnectionStringFromFile(); // 복호화된 연결 문자열 반환
            }
        }
    }
#endif
}

끝입니다. 이제 비주얼 스튜디오의 디자인 모드에서는 Settings.settings 파일의 정보에 따라 정상적으로 designer 화면이 동작하게 되고, 이렇게 개발한 제품을 나중에 Release 빌드로 배포하면 Settings.Release.settings 파일에는 연결 문자열 정보가 없고, 별도의 Settings.partial.cs에 정의한 연결 문자열 속성의 get 메서드를 통해 복호화된 연결 문자열을 사용하게 됩니다. ^^




부가적으로 고려해야 할 것이 app.config 파일에 있는 연결 문자열 정보입니다. 원래는 삭제해도 되는데요, 어떤 경우에는 XSD 디자이너가 자꾸만 app.config에 연결 문자열을 추가하려고 해서 원치 않게 삽입되는 경우가 발생합니다. 실수로 추가된 연결 문자열을 매번 삭제하는 것도 번거로우니, 이럴 때는 다음의 글에 따라,

C# - app.config 파일의 출력을 Configuration(Debug/Release)에 따라 제어하는 방법
; https://www.sysnet.pe.kr/2/0/13918

App.Release.config 파일에 이런 조건을 넣어두면 좋겠습니다.

<?xml version="1.0" encoding="utf-8"?>
<!--For more information on using transformations see the web.config examples at http://go.microsoft.com/fwlink/?LinkId=214134. -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <connectionStrings>
        <add name="WindowsFormsApp1.Properties.Settings.UnitTestDB2ConnectionString" xdt:Transform="Remove" xdt:Locator="Match(name)" />
    </connectionStrings>
</configuration>

그럼, Release 빌드 시 연결 문자열 정보가 확실하게 제거되므로 안전하게 배포할 수 있습니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




마지막으로 언급해야 할 것이 있다면, 저렇게 했다고 해서 로컬에 배포된 연결 문자열이 안전해지는 것은 아닙니다. 즉, 알고자 한다면 약간의 작업을 거쳐 금방 알아낼 수 있습니다. 개인적인 의견으로는, 그래도 저렇게 한 단계 귀찮음을 더하도록 하는 것에 의미가 없지는 않다고 생각합니다. 뭐랄까... 텃밭에 두른 울타리 정도의 역할은 할 수 있는 정도라고 보면 되겠습니다. 즉, 마음만 먹으면 언제든지 넘어가 작물을 취할 수는 있지만 울타리 하나가 쳐짐으로 인해 보통은 그냥 지나치게 두는 것과 같은 이치입니다.

그래도 잊지 말아야 할 것은, 안전한 방법은 아니라는 점!




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 5/2/2025]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...
NoWriterDateCnt.TitleFile(s)
12086정성태12/20/201921103디버깅 기술: 144. windbg - Marshal.FreeHGlobal에서 발생한 덤프 분석 사례
12085정성태12/20/201919064오류 유형: 586. iisreset - The data is invalid. (2147942413, 8007000d) 오류 발생 - 두 번째 이야기 [1]
12084정성태12/19/201919484디버깅 기술: 143. windbg/sos - Hashtable의 buckets 배열 내용을 모두 덤프하는 방법 (do_hashtable.py) [1]
12083정성태12/17/201922422Linux: 27. linux - lldb를 이용한 .NET Core 응용 프로그램의 메모리 덤프 분석 방법 [2]
12082정성태12/17/201920638오류 유형: 585. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
12081정성태12/16/201922544개발 환경 구성: 465. 로컬 PC에서 개발 중인 ASP.NET Core 웹 응용 프로그램을 다른 PC에서도 접근하는 방법 [5]
12080정성태12/16/201919684.NET Framework: 870. C# - 프로세스의 모든 핸들을 열람
12079정성태12/13/201921618오류 유형: 584. 원격 데스크톱(rdp) 환경에서 다중 또는 고용량 파일 복사 시 "Unspecified error" 오류 발생
12078정성태12/13/201921437Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법 [3]
12077정성태12/13/201920460Linux: 25. 자주 실행할 명령어 또는 초기 환경을 "~/.bashrc" 파일에 등록
12076정성태12/12/201919013디버깅 기술: 142. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅 - 배포 방법에 따른 차이
12075정성태12/11/201919849디버깅 기술: 141. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅
12074정성태12/10/201919529디버깅 기술: 140. windbg/Visual Studio - 값이 변경된 경우를 위한 정지점(BP) 설정(Data Breakpoint)
12073정성태12/10/201920990Linux: 24. Linux/C# - 실행 파일이 아닌 스크립트 형식의 명령어를 Process.Start로 실행하는 방법
12072정성태12/9/201917749오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
12071정성태12/9/201921292오류 유형: 582. 리눅스 디스크 공간 부족 및 safemode 부팅 방법
12070정성태12/9/201923208오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/2/201919668디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/201928312디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [3]파일 다운로드2
12067정성태11/27/201919742디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201919360디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201917661디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201920646오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201919613디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201918993디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201919439Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...