Windows 앱 개발에서 최저한의 보안을 지키기 위한 체크리스트

Excel판 체크리스트 다운로드

Windows 앱의 보안이라고 하면 이야기가 갑자기 커지기 쉽습니다. 제로 트러스트, EDR, SBOM, 증명서 운영, 취약성 관리. 어느 것도 중요하지만, 실무에서는 그 전에 빠뜨리고 싶지 않은 최저한이 꽤 있습니다.

특히 다음과 같은 앱에서는 「고도의 방어」보다 먼저 기본의 누수를 막는 편이 효과적입니다.

• WPF / WinForms / WinUI의 데스크톱 앱
• C++ / C#의 Win32 앱
• 장치 연계, 파일 연계, DB 접속, 사내 배포 도구
• 자동 업데이트 기구를 가지는 업무 앱
• Windows 서비스나 보조 EXE를 포함하는 구성

Windows 앱 개발에서는 전부를 한 번에 완벽하게 하기보다, 우선 명백히 위험한 구멍을 남기지 않는 편이 현실적입니다. 여기서는 설계, 구현, 배포, 운용의 순서로 최저한 빠뜨리고 싶지 않은 포인트를 체크하기 쉬운 형태로 정리합니다.

1. 먼저 결론

• 처음에 빠뜨리고 싶지 않은 것은 불필요한 관리자 권한을 요구하지 않는 것, 서명하는 것, 비밀 정보를 평문으로 가지지 않는 것, 증명서 검증을 무효화하지 않는 것입니다.
• Windows 앱은 배포물 그 자체가 공격면이 됩니다. EXE / DLL / MSI / MSIX / 자동 업데이트 모듈까지 포함해 보는 편이 안전합니다.
• ServerCertificateValidationCallback => true, 평문의 접속 문자열, LoadLibrary("foo.dll")의 거친 읽기, 문자열 연결로의 SQL 실행은 최저한의 라인에서도 피하고 싶은 항목입니다.
• 관리자 권한이 필요한 처리가 일부뿐이라면, 앱 전체를 승격시키는 것이 아니라 그 부분만을 별도 EXE나 service로 나누는 편이 안전합니다.
• Windows에서 배포하는 앱은 서명 + 타임스탬프를 전제로 생각하는 편이 좋습니다. 이용자에의 신뢰성뿐만 아니라 개찬 검지나 운영 설명도 하기 쉬워집니다.
• 저장 시의 기밀 정보는 용도에 따라 DPAPI / ProtectedData나 Credential Locker를 구분해 사용합니다. 적어도 appsettings.json에 평문으로 두는 상태는 빠지고 싶은 곳입니다.
• 로그는 많으면 좋은 것이 아닙니다. 토큰, 비밀번호, 접속 문자열, 개인 정보, 풀 리퀘스트 본문을 그대로 남기면 로그 자체가 사고의 주역이 됩니다.

최저한의 보안은 특수한 기능을 추가하는 것보다 위험한 기본 동작이나 거친 구현을 남기지 않는 것입니다.

2. 이 글의 대상과 「최저한」의 의미

2.1. 대상으로 하는 범위

이 글의 대상은 예를 들어 다음과 같은 Windows 앱입니다.

• WPF / WinForms / WinUI의 데스크톱 앱
• C++ / C#의 Win32 앱
• 사내 배포 도구, 장치 연계 도구, 감시 도구
• 보조 EXE, Windows 서비스, 업데이터를 포함하는 구성
• EXE / MSI / MSIX로 배포하는 업무용 소프트

여기서 말하는 「최저한」은 감사에 통과하는 최종 형태가 아니라 이것이 빠지면 꽤 평범하게 사고나는 항목입니다.

2.2. 대상 외

한편, 이 글의 중심에서는 빼는 것도 있습니다.

• 기업 전체의 제로 트러스트 설계
• EDR / SIEM / DLP / MDM의 전체 운용
• 커널 드라이버의 상세한 하드닝
• 암호 설계 그 자체를 처음부터 하는 이야기
• 고도의 위협 분석이나 포렌식 순서

즉, 「조직 전체의 거대한 보안 시책」이 아니라 Windows 앱 개발자가 릴리스 전에 자력으로 빠뜨리기 어려운 기본선을 다룹니다.

3. 먼저 보는 체크리스트

세세한 의론 전에 먼저 전체를 둘러볼 수 있는 표를 둡니다. 여기만으로도 재검토할 장소의 짐작은 잡힙니다.

3.1. 전체상

3.2. 권한은 asInvoker를 기본으로 한다

Windows 앱에서 처음에 재검토하고 싶은 곳은 여기입니다. 앱 전체를 관리자 권한으로 동작시키면, 버그나 DLL 바꿔치기, 설정 파일 오독, 외부 입력의 불비가 그대로 강한 권한으로 실행됩니다.

기본 방침은 다음 형태입니다.

• 통상의 UI 앱은 asInvoker
• 관리자 권한이 필요한 처리만 별도 프로세스나 service로 분리한다
• 승격은 필요한 순간만 한다
• 보조 EXE나 service에 건네는 입력도 검증한다

예를 들어 통상은 열람과 편집뿐인 데스크톱 앱에서, 인스톨이나 방화벽 설정 변경만이 관리자 권한을 필요로 한다면, 앱 전체를 requireAdministrator로 하기보다 승격이 필요한 부분만 broker에 기울이는 편이 안전합니다.

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
  <security>
    <requestedPrivileges>
      <requestedExecutionLevel level="asInvoker" uiAccess="false" />
    </requestedPrivileges>
  </security>
</trustInfo>

「관리자로 동작시키면 편하다」는 대개 나중에 효과가 옵니다. 최소 권한으로 동작시키고, 그래도 필요한 조작만 잘라내는 편이 사고의 반경은 꽤 작아집니다.

3.3. 바이너리와 인스톨러에 서명한다

Windows에서는 배포물의 신뢰성이 꽤 중요합니다. 사용자가 만지는 것은 소스 코드가 아니라 EXE, DLL, MSI, MSIX, 업데이터입니다. 여기가 미서명이면 운영상의 설명도 개찬 검지도 배포 시의 안심감도 약해집니다.

최저한으로 보고 싶은 것은 다음입니다.

• EXE / DLL / MSI / MSIX에 서명한다
• 인스톨러뿐만 아니라 업데이트에 사용하는 보조 바이너리도 서명한다
• 타임스탬프를 붙인다
• 증명서의 기한과 업데이트 순서를 release 순서에 포함한다

특히 타임스탬프를 붙이지 않은 서명은 증명서 기한 만료 후의 검증에서 곤란해지기 쉽습니다. 「서명했으니 끝」이 아니라 서명 + 타임스탬프까지를 release 순서에 넣어 두는 편이 안정됩니다.

MSIX를 사용한다면 패키지 서명은 전제입니다. MSI / EXE 배포에서도 적어도 인스톨러 본체와 주요 실행 바이너리는 서명해 두는 편이 좋습니다.

3.4. 업데이트 경로를 고정하고, 개찬 검지를 넣는다

요즘의 Windows 앱에서는 초회 인스톨보다 업데이트 경로 쪽이 길게 사용됩니다. 여기가 거칠면 애써서 본체를 정성스럽게 만들어도 업데이터가 가장 약한 곳이 됩니다.

최저한의 사고방식은 다음입니다.

• 업데이트 파일의 취득은 HTTPS 전제
• 다운로드한 업데이트물의 서명이나 해시를 검증한다
• 업데이트원 URL을 코드나 설정으로 무제한 교체할 수 없도록 한다
• 업데이트 모듈 자신도 서명한다
• 롤백이나 실패 시의 복구 순서를 정한다

MSIX + App Installer를 택할 수 있다면 업데이트의 구조를 OS 쪽에 기울이기 쉽습니다. 한편, 독자 업데이터를 가진다면 통신의 안전성과 배포물의 진정성의 양쪽을 확인할 필요가 있습니다. HTTPS만으로는 「통신 경로」는 지켜도 「그 파일이 정말로 자신의 발행물인지」까지는 보증하지 않습니다.

3.5. 비밀 정보를 소스 코드나 평문 설정에 두지 않는다

여기는 실무에서 정말 사고나기 쉬운 곳입니다. 「사내 도구니까」 「어차피 exe를 배포할 뿐이니까」로 접속 문자열, API 키, 공유 폴더 자격 정보, 고정 토큰을 소스 코드나 설정 파일에 두기 쉽습니다.

최저한으로 피하고 싶은 것은 다음입니다.

• 소스 코드에 직접 쓴 API 키
• appsettings.json이나 app.config의 평문 비밀번호
• 리포지토리에 들어간 접속 문자열
• 복호 키와 암호문을 같은 장소에 두는 설계
• 이용자별이 아닌 전원 공통의 고정 자격 정보

Windows 앱에서의 실무적인 선택지는 대개 다음입니다.

• Windows의 자격 정보를 저장하고 싶다 packaged desktop app / WinUI계라면 Credential Locker를 검토한다
• 로컬에 비밀을 암호화 저장하고 싶다 Win32 / .NET이라면 DPAPI / ProtectedData를 사용한다
• 접속처가 Windows 인증이나 통합 인증을 사용할 수 있다 가능하면 앱에 비밀번호를 가지게 하지 않는다
• 클라우드나 서버 측에서 비밀 관리할 수 있다 클라이언트에 장기 비밀을 묻어 두지 않는 설계를 우선한다

C#이라면 적어도 다음과 같이 DPAPI를 사용하는 것만으로도 평문 저장보다는 훨씬 낫습니다.

using System.Security.Cryptography;
using System.Text;

byte[] plaintext = Encoding.UTF8.GetBytes(secretText);
byte[] ciphertext = ProtectedData.Protect(
    plaintext,
    optionalEntropy: null,
    scope: DataProtectionScope.CurrentUser);

여기서 중요한 것은 「암호화했으니 안전」이 아니라 누가 복호할 수 있는가를 설계로 결정하는 것입니다. CurrentUser로 할지 LocalMachine으로 할지로 의미가 꽤 바뀝니다.

SQL Server 접속이라면 온프레미스 환경에서는 Windows 인증을 제1후보로 할 수 있는 경우가 있습니다. 아무래도 접속 문자열에 자격 정보를 포함해야 한다면, 적어도 Persist Security Info=False를 유지하고, 평문 설정 파일에 방치하지 않는 편이 안전합니다.

3.6. 통신은 HTTPS 전제, 증명서 검증을 죽이지 않는다

개발 중에만의 생각으로 넣은 도피로가 그대로 본번에 남는다. 통신 주변에서는 이것이 꽤 정석입니다.

특히 주의하고 싶은 것은 다음입니다.

• ServicePointManager.ServerCertificateValidationCallback += ... => true
• HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
• 증명서 실효 확인을 무효화한 채 출하
• 개발용 자기 서명 증명서 전제의 코드를 본번에 남긴다

최저한의 방침은 단순합니다.

• 본번 통신은 HTTPS
• 증명서 검증을 상시 스킵하지 않는다
• 예외적인 검증 완화가 필요하면 대상 호스트와 증명서를 한정한다
• 개발용의 회피 코드는 빌드 조건이나 설정으로 확실히 배제한다
• .NET이라면 실효 확인도 의식한다

안 되는 예는 대개 이렇습니다.

ServicePointManager.ServerCertificateValidationCallback +=
    (_, _, _, _) => true;

얼핏 편하지만, 이것은 「이 HTTPS 통신은 누구에게 연결해도 통과시킨다」에 가까운 움직임이 됩니다. 증명서 검증을 떼면 HTTPS를 사용하고 있어도 내용은 꽤 뼈만 남은 상태입니다.

3.7. 외부 입력을 전부 「신용하지 않는 입력」으로서 다룬다

Windows 앱은 Web 앱이 아니므로 입력 validation이 약해지기 쉽습니다. 하지만 실제로는 외부 입력의 입구가 꽤 많습니다.

• 파일 패스
• CSV / Excel / JSON / XML
• 커맨드라인 인수
• named pipe / socket / COM / RPC / gRPC
• DB에 넘기는 문자열
• 레지스트리 값
• 클립보드
• URL / deep link
• 외부 장치나 SDK에서 반환되는 데이터

특히 최저한 빠뜨리고 싶지 않은 것은 다음 3가지입니다.

1. SQL은 반드시 파라미터화한다 문자열 연결로 SQL을 짜지 않는다.
2. 파일 패스는 정규화하고 나서 사용한다 사용자 지정 패스를 그대로 삭제, 덮어쓰기, 전개에 사용하지 않는다.
3. 외부 파일의 읽기는 사이즈 상한과 형식 체크를 넣는다 「열 수 있으니 안전」이 아니다.

SQL의 예로 말하면, 이것은 피하고 싶습니다.

var sql = "SELECT * FROM Users WHERE Name = '" + userName + "'";

최저한이라도 이쪽으로 기울이고 싶습니다.

using System.Data;
using Microsoft.Data.SqlClient;

using var cmd = connection.CreateCommand();
cmd.CommandText = "SELECT * FROM Users WHERE Name = @name";
cmd.Parameters.Add("@name", SqlDbType.NVarChar, 256).Value = userName;

「사내 도구니까 입력은 신뢰할 수 있다」는 꽤 위험한 전제입니다. 현실에는 망가진 CSV, 상정 외의 파일 이름, 오래된 DB 데이터, 운용자의 수입력 실수, 다른 도구가 쓴 도중 JSON이 평범하게 들어옵니다.

3.8. DLL의 읽기 처를 애매하게 하지 않는다

이것은 Windows다운 함정입니다. LoadLibrary("foo.dll")처럼 이름만으로 DLL을 읽게 하면 검색 순서 여하로 의도하지 않은 장소의 DLL을 주울 수 있습니다.

최저한의 방침은 다음입니다.

• 가능하면 DLL의 절대 패스를 지정한다
• SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_DEFAULT_DIRS)를 이른 단계에서 설정한다
• AddDllDirectory로 명시적으로 검색 대상을 추가한다
• SearchPath의 결과를 그대로 LoadLibrary에 넘기는 설계를 피한다
• safe DLL search mode에 의지하지 않는다

예를 들어 native code라면 프로세스 초기화의 이른 단계에서 다음을 넣는 설계는 유력합니다.

SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_DEFAULT_DIRS);

그리고 필요한 추가 디렉터리만을 AddDllDirectory로 등록합니다.

여기는 「평소는 동작」하므로 방치되기 쉽지만, 배포처에서 작업 디렉터리가 바뀌거나 다른 제품의 DLL이 PATH에 들어 있거나 하면 조용히 망가집니다. 보안뿐만 아니라 장해 예방으로서도 꽤 효과적입니다.

3.9. 로그와 예외에 기밀을 내보내지 않는다

장해 조사를 위해 로그를 늘리는 것은 중요합니다. 다만, 로그는 기밀의 묘지가 되기도 쉽습니다.

최저한으로 재검토하고 싶은 것은 다음입니다.

• 비밀번호, Bearer token, API 키를 로그에 내지 않는다
• 접속 문자열을 통째로 내지 않는다
• 개인 정보나 업무 데이터 본문은 마스크한다
• 예외 상세는 이용자 전용 화면과 내부 로그로 나눈다
• debug용 PII 로그를 본번에서 유효화하지 않는다
• dump나 trace의 저장처 권한을 재검토한다

최근의 .NET에서는 redaction을 전제로 한 정리도 하기 쉬워지고 있습니다. 적어도 「뭐든 문자열화해 그대로 log」는 그만두고 싶습니다.

자주 있는 실패는 다음입니다.

• HTTP request / response body를 통째로 저장한다
• 인증 실패 시에 토큰이나 헤더 전체를 출력한다
• 예외 메시지를 그대로 MessageBox에 낸다
• 보수용 ZIP에 기밀 로그를 전부 동봉한다

에러 표시는 예를 들어 다음과 같이 나눕니다.

• 이용자 전용: 「서버로의 접속에 실패했습니다. 네트워크 설정과 URL을 확인해 주세요.」
• 내부 로그: 실패처 호스트, TLS 에러 종별, 상관 ID, stack trace, 재시행 횟수

이 분리만으로도 정보 누설과 조사성의 밸런스가 꽤 좋아집니다.

3.10. 의존 라이브러리와 개발 도구를 방치하지 않는다

마지막은 수수하지만 꽤 효과적인 항목입니다. 앱 본체를 정성스럽게 만들어도 오래된 런타임이나 기지 취약성이 있는 의존 라이브러리를 쌓은 채라면 발 밑이 빠집니다.

최저한으로 보고 싶은 것은 다음입니다.

• .NET SDK / runtime을 서포트 내의 판으로 유지한다
• NuGet / OSS 의존의 업데이트를 정기적으로 확인한다
• C++라면 런타임 재배포물이나 외부 DLL의 판 관리를 한다
• 취약성 정보의 확인을 release 전 체크에 넣는다
• 의존 업데이트로 망가지지 않도록 smoke test를 준비한다

여기는 「나중에 한꺼번에 한다」가 가장 위험합니다. 반 년, 1년 방치하면 업데이트 차분이 너무 커져, 보안 대응 그 자체가 중작업이 됩니다.

4. 릴리스 전 체크리스트

리뷰나 출하 판정의 틀로서 그대로 사용할 수 있는 형태로 합니다. 표로 확인하기 쉽도록 릴리스 전에 최저한 보고 싶은 항목을 카테고리별로 나열합니다.

4.1. 권한, 실행 방식

4.2. 배포, 서명

4.3. 업데이트

4.4. 비밀 정보

4.5. 통신

4.6. 입력, 데이터 액세스

4.7. DLL과 실행 환경

4.8. 로그, 운용

5. 자주 있는 NG

실무에서 자주 보는 것은 대개 다음입니다.

5.1. 「사내 도구니까 괜찮다」

사내 도구에서도 망가진 파일, 오조작, 반입 단말, 공유 폴더, 오래된 DLL, 거친 권한 설정은 평범하게 있습니다. 인터넷 공개하지 않아도 공격면은 사라지지 않습니다.

5.2. 「HTTPS니까 안전」

HTTPS는 중요하지만, 증명서 검증을 무효화하면 꽤 의미가 옅어집니다. 또한 업데이트 배포에서는 HTTPS뿐만 아니라 배포물의 진정성 확인도 필요합니다.

5.3. 「암호화했으니 안전」

복호 키의 둘 곳, 복호 권한, 사용자 경계, 머신 경계가 정리되어 있지 않으면 암호화만으로는 부족합니다. 특히 LocalMachine으로 보호한 값을 「사용자별의 비밀」이라고 생각해 사용하면 나중에 혼란합니다.

5.4. 「로그를 늘리면 조사할 수 있다」

로그가 많기만 하고 토큰이나 개인 정보가 흘러내리고 있으면, 그것 자체가 인시던트가 됩니다. 조사성을 원한다면 무엇을 남기고 무엇을 숨길지를 정하는 편이 먼저입니다.

5.5. 「관리자로 동작시키면 해결」

처음에는 편하지만, 나중에 UAC, 배포, 서포트, 권한 경계, DLL 읽기, 파일 저장처에서 대개 힘들어집니다. 최소 권한 쪽이 장기에서는 안정됩니다.

6. 대강의 우선 순위

전부 한꺼번에 하는 것이 무거우면 순서는 대체로 다음입니다.

1. 관리자 권한의 재검토 우선 requireAdministrator의 상용을 그만둔다.
2. 서명과 타임스탬프 배포물의 신뢰성을 갖춘다.
3. 비밀 정보의 대피 소스 코드, 평문 설정에서 비밀을 뺀다.
4. HTTPS + 증명서 검증의 시정 => true 계를 출하물에서 지운다.
5. SQL / 파일 / IPC 입력의 재검토 문자열 연결이나 미검증 입력을 줄인다.
6. DLL 읽기의 고정 이름만 로드, PATH 맡김을 그만둔다.
7. 로그의 마스킹 사고 시에 로그가 이차 재해가 되지 않도록 한다.
8. 의존 업데이트의 정상화 릴리스 때마다 확인하는 흐름으로 한다.

이 순서라면 「우선 명백히 위험한 구멍을 막는다」는 의미로 진행하기 쉽습니다.

7. 정리

Windows 앱 개발의 보안은 특별한 제품이나 거대한 구조를 넣기 전에, 권한, 서명, 비밀 정보, 통신, 입력, DLL, 로그의 7점을 정돈하는 것만으로도 꽤 바뀝니다.

최저한으로 짚어두고 싶은 것은 다음입니다.

• 앱 전체를 관리자 권한으로 동작시키지 않는다
• 배포물과 업데이트물에 서명하고, 타임스탬프를 붙인다
• 비밀 정보를 소스 코드나 평문 설정에 두지 않는다
• HTTPS를 사용해도 증명서 검증을 죽이지 않는다
• SQL, 파일, IPC 등의 외부 입력을 신용하지 않는다
• DLL의 읽기 처를 애매하게 하지 않는다
• 로그에 기밀을 내지 않는다
• 의존 라이브러리를 방치하지 않는다

보안의 이야기는 넓지만, 처음부터 전부를 할 필요는 없습니다. 다만 위험한 기본 동작을 그대로 출하하지 않는다는 최저한만은 꽤 이른 단계에서 갖출 가치가 있습니다.

8. 참고 자료

• Administrator Broker Model - Win32 apps
• How User Account Control works
• Authenticode Digital Signatures
• Time Stamping Authenticode Signatures
• Sign a Windows app package
• Credential Locker for Windows apps
• CryptProtectData function (dpapi.h)
• CA5359: Do not disable certificate validation
• CA5399: Enable HttpClient certificate revocation list check
• Configuring parameters - ADO.NET Provider for SQL Server
• Connection String Syntax - ADO.NET
• Dynamic-Link Library Security - Win32 apps
• SetDefaultDllDirectories function (libloaderapi.h)
• Data redaction in .NET

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.