Windows 데스크톱 앱에 대한 인증 요구 사항
문서 버전: 10
문서 날짜: 2015년 7월 29일
이 문서에는 Windows 10 데스크톱 앱 인증 프로그램에 참여하기 위해 데스크톱 앱이 충족해야 하는 기술 요구 사항 및 자격 자격이 포함되어 있습니다.
환영합니다!
Windows 플랫폼은 광범위한 제품 및 파트너 에코시스템을 지원합니다. 제품에 Windows 로고를 표시하는 것은 Microsoft와 회사 간의 품질에 대한 관계와 공유된 약속을 나타냅니다. 고객은 제품에서 Windows 브랜드가 호환성 표준을 충족하고 Windows 플랫폼에서 잘 수행되도록 하기 때문에 제품에서 Windows 브랜드를 신뢰합니다. Windows 앱 인증을 성공적으로 통과하면 앱이 Windows 호환성 센터에 표시될 수 있으며 사이트에 인증 로고가 표시될 수 있습니다.
Windows 앱 인증 프로그램은 Windows 브랜드를 탑재한 타사 앱이 Windows를 실행하는 PC에서 쉽게 설치하고 신뢰할 수 있도록 하는 프로그램 및 기술 요구 사항으로 구성됩니다. 고객은 구매하는 시스템의 안정성, 호환성, 안정성, 성능 및 품질을 중시합니다. Microsoft는 PC용 Windows 플랫폼에서 실행되도록 설계된 소프트웨어 앱에 대한 이러한 요구 사항을 충족하기 위해 투자에 중점을 둡니다. 이러한 노력에는 Windows 소프트웨어를 실행하는 PC의 환경 일관성, 향상된 성능 및 향상된 보안에 대한 호환성 테스트가 포함됩니다. Microsoft 호환성 테스트는 업계 파트너와 협력하여 설계되었으며 산업 개발 및 소비자 수요에 따라 지속적으로 개선됩니다.
Windows 앱 인증 키트는 이러한 요구 사항을 준수하는지 확인하는 데 사용되며 Windows 7, Windows 8 또는 Windows 8.1 유효성을 검사하는 데 사용되는 이전 버전의 키트를 대체합니다. Windows 앱 인증 키트는 Windows 10 위한 Windows SDK(소프트웨어 개발 키트)에 포함된 구성 요소 중 하나입니다.
앱 자격
앱이 Windows 10 데스크톱 앱 인증을 받으려면 다음 기준과 이 문서에 나열된 모든 기술 요구 사항을 충족해야 합니다.
- 독립 실행형 앱이어야 합니다.
- 로컬 Windows 10 PC에서 실행해야 합니다.
- 인증된 Windows Server 앱의 클라이언트 구성 요소일 수 있습니다.
- 코드 및 기능이 완료되어야 합니다.
- 지원되는 엔터프라이즈 시나리오를 제외하고 파일 및 레지스트리 키를 포함한 로컬 메커니즘을 통해 Windows 스토어 앱과 통신해서는 안 됩니다.
- Windows 시스템의 보안 또는 기능을 위태롭게 하거나 손상해서는 안 됩니다.
- 고유한 이름이 있어야 하며 다른 사용자가 상표를 등록해서는 안 됩니다.
- 모든 외부 구성 요소는 별도로 인증되거나 Windows 앱 인증 키트를 준수해야 합니다.
- 번들 앱에 대한 옵트아웃 옵션이 있어야 합니다.
데스크톱 앱이 바이러스 백신 및/또는 스파이웨어 방지(즉, 맬웨어 방지) 제품 범주에 제출되는 경우 맬웨어 방지 플랫폼 지침을 준수해야 합니다. WINDOWS 10 맬웨어 방지 API 라이선스 및 목록 계약은 제출 전에 서명되어 적용되어야 합니다. 파트너는 의 구성원이어야 하며, 또는 계약에 나열된 조직 중 하나에 소속되어 있고 좋은 위치에 있는 연구원이 있어야 합니다. 이 기능은 계약에 나열된 조직에서 Windows 10 인증을 받아야 합니다. 앱은 지난 12개월 동안 한 번 이상 테스트되었으며 감지 및 청소에 대한 인증을 받아야 합니다.
1. 앱은 호환되고 복원력이 있습니다.
앱이 충돌하거나 응답을 중지하는 경우 많은 사용자 불만이 발생합니다. 앱은 복원력 있고 안정적이어야 하며 이러한 오류를 제거하면 소프트웨어가 더 예측 가능하고 유지 관리 가능하며 성능이 뛰어나며 신뢰할 수 있습니다.
- 1.1 앱은 Windows 호환성 모드, AppHelp 메시지 또는 기타 호환성 수정에 종속되지 않아야 합니다.
1.2 앱에 호환성 매니페스트가 있어야 하며 지원되는 Windows 버전에 적절한 GUID를 사용해야 합니다.
1.3 앱은 SetProcessDPIAware를 호출하는 대신 애플리케이션의 어셈블리 매니페스트를 사용하여 DPI를 인식해야 합니다.
1.4 앱이 VB6 런타임에 종속되지 않아야 합니다.
1.5 앱은 HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls 사용하여 Win32 API 호출을 가로채기 위해 임의의 DLL을 로드해서는 안 됩니다.
2. 앱은 Windows 보안 모범 사례를 준수해야 합니다.
Windows 보안 모범 사례를 사용하면 Windows 공격 노출을 방지하는 데 도움이 됩니다. 공격 표면은 악의적인 공격자가 대상 소프트웨어의 취약성을 활용하여 운영 체제를 악용하는 데 사용할 수 있는 진입점입니다. 최악의 보안 취약성 중 하나는 권한 상승입니다.
테스트 2.1 2.6은 Windows 7, Windows 8 또는 Windows 8.1 테스트된 데스크톱 앱에만 적용됩니다.
- 2.1 앱은 강력하고 적절한 ACL 을 사용하여 실행 파일 보안을 유지해야 합니다.
2.2 앱은 강력하고 적절한 ACL 을 사용하여 디렉터리를 보호해야 합니다.
2.3 앱은 강력하고 적절한 ACL 을 사용하여 레지스트리 키를 보호해야 합니다.
2.4 앱은 강력하고 적절한 ACL 을 사용하여 개체가 포함된 디렉터리를 보호해야 합니다.
2.5 앱은 변조에 취약한 서비스에 대한 관리자가 아닌 액세스를 줄여야 합니다.
2.6 앱은 빠른 다시 시작이 있는 서비스가 24시간마다 두 번 이상 다시 시작되지 않도록 해야 합니다.
참고: 필요한 엔터티에만 액세스 권한을 부여해야 합니다.
Windows 앱 인증 프로그램은 ACL 및 서비스가 Windows 시스템을 위험에 빠뜨리지 않는 방식으로 구현되었는지 확인하여 Windows 공격 표면이 노출되지 않는지 확인합니다.
3. 앱은 Windows 보안 기능을 지원합니다.
Windows 운영 체제에는 시스템 보안 및 개인 정보를 지원하는 많은 기능이 있습니다. 앱은 운영 체제의 무결성을 유지하기 위해 이러한 기능을 지원해야 합니다. 잘못 컴파일된 앱은 버퍼 오버런을 유발하여 서비스 거부를 유발하거나 악성 코드 실행을 허용할 수 있습니다.
- 3.1 강력한 이름의 어셈블리에 대한 보안 액세스를 보장하기 위해 앱에서 AllowPartiallyTrustedCallersAttribute(APTCA)를 사용하지 않아야 합니다.
3.2 안전한 예외 처리를 보장하려면 /SafeSEH 플래그를 사용하여 앱을 컴파일해야 합니다.
3.3 데이터 실행을 방지하려면 /NXCOMPAT 플래그를 사용하여 앱을 컴파일해야 합니다.
3.4 ASLR(주소 공간 레이아웃 임의화)을 위해 /DYNAMICBASE 플래그를 사용하여 앱을 컴파일해야 합니다.
3.5 앱이 공유 PE 섹션을 읽고 쓰지 않아야 합니다.
4. 앱은 시스템 다시 시작 관리자 메시지를 준수해야 합니다.
사용자가 종료를 시작할 때 일반적으로 종료 성공에 대한 강한 욕구가 있습니다. 그들은 서둘러 사무실을 떠날 수 있으며 컴퓨터가 꺼지길 원할 수 있습니다. 앱은 종료를 차단하지 않음으로써 이러한 욕구를 존중해야 합니다. 대부분의 경우 종료는 중요하지 않을 수 있지만 앱은 중요한 종료 가능성에 대비해야 합니다.
- 4.1 앱이 중요한 종료를 적절하게 처리해야 합니다.
- 중요한 종료 시 FALSE를 WM_QUERYENDSESSION 반환하는 앱은 WM_ENDSESSION 전송되고 닫힙니다. 반면 WM_QUERYENDSESSION 대한 응답으로 시간 초과된 앱은 종료됩니다.
- WM\_QUERYENDSESSION with LPARAM = ENDSESSION\_CLOSEAPP(0x1).
콘솔 앱은 SetConsoleCtrlHandler를 호출하여 종료 알림을 처리할 함수를 지정할 수 있습니다. 서비스 앱은 RegisterServiceCtrlHandlerEx를 호출하여 종료 알림을 받을 함수를 지정할 수 있습니다.
- WM\_ENDSESSION with LPARAM = ENDSESSION\_CLOSEAPP(0x1).
최소한 앱은 사용자 데이터를 저장하여 준비하고 다시 시작한 후 필요한 정보를 명시해야 합니다.
5. 앱은 클린 되돌릴 수 있는 설치를 지원해야 합니다.
클린 되돌릴 수 있는 설치를 통해 사용자는 시스템에서 앱을 성공적으로 관리(배포 및 제거)할 수 있습니다.
- 5.1 앱이 클린, 되돌릴 수 있는 설치를 제대로 구현해야 합니다.
- DisplayName
- InstallLocation
- Publisher
- UninstallString
- VersionMajor 또는 MajorVersion
- VersionMinor 또는 MinorVersion
- 설치에 실패하면 앱이 롤백하고 컴퓨터를 이전 상태로 복원할 수 있어야 합니다.
- 컴퓨터를 다시 시작하는 것은 설치, 제거 또는 업데이트가 끝날 때 유일한 옵션이 되어서는 안 됩니다. 사용자는 나중에 다시 시작할 수 있어야 합니다.
- Windows 인벤토리 도구 및 원격 분석 도구에는 설치된 앱에 대한 완전한 정보가 필요합니다. MSI 기반 설치 관리자를 사용하는 경우 MSI는 아래에 레지스트리 항목을 자동으로 만듭니다. MSI 설치 관리자를 사용하지 않는 경우 설치 모듈은 설치 중에 다음 레지스트리 항목을 만들어야 합니다.
6. 앱은 파일 및 드라이버에 디지털 서명해야 합니다.
Authenticode 디지털 서명을 사용하면 사용자가 소프트웨어가 정품인지 확인할 수 있습니다. 또한 파일이 바이러스에 감염된 경우와 같이 파일이 변조되었는지 여부를 감지할 수 있습니다. 커널 모드 코드 서명 적용은 CI(코드 무결성)라고 하는 Windows 기능으로, 파일 이미지가 메모리에 로드될 때마다 파일의 무결성을 확인하여 운영 체제의 보안을 향상시킵니다. CI는 악성 코드가 시스템 이진 파일을 수정했는지 여부를 검색합니다. 커널 모듈의 서명이 올바르게 확인되지 않을 때 진단 및 시스템 감사 로그 이벤트도 생성합니다.
- 6.1 모든 실행 파일(.exe, .dll, .ocx, .sys, .cpl, .drv, .scr)은 Authenticode 인증서로 서명해야 합니다.
6.2 앱에서 설치한 모든 커널 모드 드라이버에는 Windows 하드웨어 인증 프로그램을 통해 얻은 Microsoft 서명이 있어야 합니다. 모든 파일 시스템 필터 드라이버는 Microsoft에서 서명해야 합니다.
6.3 예외 및 면제
- 면제는 드라이버를 제외한 서명되지 않은 제3자 재배포 가능 패키지에 대해서만 고려됩니다. 이 면제를 부여하려면 서명된 버전의 재배포 가능 파일을 요청하는 통신 증명이 필요합니다.
7. 앱은 운영 체제 버전 검사 따라 설치 또는 앱 시작을 차단하지 않습니다.
기술적인 제한 사항이 없는 경우 고객이 앱을 설치하거나 실행하지 못하도록 인위적으로 차단하지 않는 것이 중요합니다. 일반적으로 앱이 Windows Vista 이상 버전의 Windows용으로 작성된 경우 운영 체제 버전을 검사 필요가 없습니다.
- 7.1 앱에서 같음 버전 검사를 수행해서는 안 됩니다.
- Windows 7, Windows 8 및 Windows 8.1 실행되며 운영 체제 버전을 검사 지정된 운영 체제에 설치할 구성 요소를 결정하는 하나의 패키지로 제공되는 앱입니다.
- 승인된 API 호출만 사용하여 운영 체제의 최소 버전만 검사 앱 매니페스트에서 최소 버전 요구 사항을 올바르게 나열하는 앱입니다(런타임이 아닌 설치 중에만).
- 승인된 API 호출만 사용하여 운영 체제 버전을 검사 보안 앱(바이러스 백신, 방화벽 등), 시스템 유틸리티(예: 조각 모음, 백업 및 진단 도구).
- 특정 기능이 필요한 경우 기능 자체를 사용할 수 있는지 여부를 검사. Windows 7이 필요한 경우 Windows 7 이상용으로 검사(>= 6.2). 이렇게 하면 검색 코드가 이후 버전의 Windows에서 계속 작동합니다. 드라이버 설치 관리자 및 제거 모듈은 운영 체제 버전을 검사 않아야 합니다.
8. 앱이 안전 모드에서 서비스 또는 드라이버를 로드하지 않음
안전 모드를 사용하면 사용자가 Windows를 진단하고 문제를 해결할 수 있습니다. 드라이버 및 서비스는 스토리지 디바이스 드라이버와 같은 기본 시스템 작업이나 바이러스 백신 스캐너와 같은 진단 및 복구 목적에 필요한 경우가 아니면 안전 모드로 로드하도록 설정해서는 안 됩니다. 기본적으로 Windows가 안전 모드인 경우 Windows와 함께 사전 설치된 드라이버 및 서비스만 시작합니다.
- 8.1 예외 및 면제
- 안전 모드에서 시작해야 하는 드라이버 및 서비스에는 면제가 필요합니다. 면제 요청에는 SafeBoot 레지스트리 키에 기록할 수 있는 각 드라이버 또는 서비스가 포함되어야 하며 앱 또는 서비스가 안전 모드로 실행되어야 하는 기술적 이유를 설명해야 합니다. 앱 설치 관리자는 다음 레지스트리 키를 사용하여 이러한 모든 드라이버 및 서비스를 등록해야 합니다.
참고: 이러한 드라이버와 서비스를 테스트하여 오류 없이 안전 모드에서 작동하는지 확인해야 합니다.
9. 앱은 사용자 계정 제어 지침을 따라야 합니다.
일부 Windows 앱은 관리자 계정의 보안 컨텍스트에서 실행되며 앱은 종종 과도한 사용자 권한 및 Windows 권한을 요청합니다. 리소스에 대한 액세스를 제어하면 사용자가 시스템을 제어하고 원치 않는 변경으로부터 보호할 수 있습니다. 원치 않는 변경은 컴퓨터를 제어하는 루트킷과 같이 악의적이거나 권한이 제한된 사용자가 수행한 작업의 결과일 수 있습니다. 리소스에 대한 액세스를 제어하는 가장 중요한 규칙은 사용자가 필요한 작업을 수행하는 데 필요한 최소한의 액세스 표준 사용자 컨텍스트를 제공하는 것입니다. 다음 UAC(사용자 계정 제어) 지침은 시스템이 보안 위험에 지속적으로 노출되지 않고 앱에서 필요할 때 필요한 권한을 앱에 제공합니다. 대부분의 앱은 런타임에 관리자 권한이 필요하지 않으며 표준 사용자로 잘 실행되어야 합니다.
- 9.1 앱에는 실행 수준을 정의하고 앱이 실행하기 위해 필요한 권한을 운영 체제에 알려주는 매니페스트가 있어야 합니다.
- 실행 수준이 highestAvailable로 설정된 관리 또는 시스템 도구 및/또는 requireAdministrator
- 접근성 또는 UI 자동화 프레임워크 앱만 UIAccess 플래그를 true로 설정하여 UIPI(사용자 인터페이스 권한 격리)를 무시합니다. 앱 사용률을 제대로 시작하려면 이 플래그는 Authenticode 서명되어야 하며 파일 시스템의 보호된 위치인 Program Files에 있어야 합니다.
- 앱 매니페스트 표시는 DLL이 아닌 EXE에만 적용됩니다. UAC는 프로세스를 만드는 동안 DLL을 검사하지 않기 때문입니다. UAC 규칙은 Microsoft 서비스에 적용되지 않는다는 점도 주목할 가치가 있습니다. 매니페스트는 포함되거나 외부일 수 있습니다.
매니페스트를 만들려면 이름이 <app_name.exe.manifest> 인 파일을 만들고 EXE와 동일한 디렉터리에 저장합니다. 앱에 내부 매니페스트가 있는 경우 외부 매니페스트는 무시됩니다. 예:
<requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false""/>
- 모든 관리 기능은 관리 권한으로 실행되는 별도의 프로세스로 이동해야 합니다. 시작 메뉴의 프로그램 그룹을 통해 액세스할 수 있고 권한 상승이 필요한 앱과 같은 사용자 연결 앱은 Authenticode에 서명되어야 합니다.
- 권한 상승(administrator 또는 highestAvailable 필요)을 사용하여 기본 프로세스를 실행하는 앱에는 면제가 필요합니다. 기본 프로세스는 앱에 대한 사용자의 진입점으로 식별됩니다. 면제는 다음 시나리오에 대해 고려됩니다.
10. 앱은 기본적으로 올바른 폴더에 설치해야 합니다.
사용자는 선택한 위치에 앱을 설치하는 옵션을 유지하면서 파일의 기본 설치 위치에 일관되고 안전한 환경을 가져야 합니다. 또한 여러 사람이 서로의 데이터와 설정을 손상시키거나 덮어쓰지 않고 동일한 컴퓨터를 사용할 수 있도록 앱 데이터를 올바른 위치에 저장해야 합니다. Windows는 사용자와 관련된 프로그램 및 소프트웨어 구성 요소, 공유 앱 데이터 및 앱 데이터를 저장할 파일 시스템의 특정 위치를 제공합니다.
- 10.1 기본적으로 프로그램 파일 폴더에 앱을 설치해야 합니다.
- 레지스트리 실행 키 HKLM 및 또는 Software\Microsoft\Windows\CurrentVersion의 HKCU
- 레지스트리 실행 키 HKLM 또는 Software\Wow6432Node\Microsoft\windows\CurrentVersion의 HKCU
- 시작 메뉴 AllPrograms > STARTUP
- %ProgramFiles%의 네이티브 32비트 및 64비트 앱의 경우 , x64에서 실행되는 32비트 앱의 경우 %ProgramFiles(x86)%입니다. 이 폴더에 대해 구성된 보안 권한 때문에 사용자 데이터 또는 앱 데이터를 이 위치에 저장해서는 안 됩니다.
- 예를 들어 앱은 다음 중 어느 것을 설정해서는 안 됩니다.
- 글꼴 또는 드라이버와 같은 파일을 설치하는 데 올바른 방법을 사용합니다.
- 앱이 설치되면 데이터를 저장할 올바른 사용자 위치가 없습니다. 설치 후 컴퓨터 수준에서 기본 연결 동작을 수정하려는 앱의 시도는 실패합니다. 대신 사용자별 수준에서 기본값을 클레임해야 하므로 여러 사용자가 서로의 기본값을 덮어쓰지 못하게 됩니다.
- GAC(전역 어셈블리 캐시) .NET 앱에 쓰는 앱에는 어셈블리 종속성을 비공개로 유지하고 어셈블리를 명시적으로 공유해야 하는 경우가 아니면 앱 디렉터리에 저장해야 합니다.
11. 앱은 다중 사용자 세션을 지원해야 합니다.
Windows 사용자는 충돌 또는 중단 없이 동시 세션을 실행할 수 있어야 합니다.
- 11.1 앱은 로컬 또는 원격으로 여러 세션에서 실행할 때 앱의 일반적인 기능이 부정적인 영향을 받지 않도록 해야 합니다.
11.2 앱의 설정 및 데이터 파일이 사용자 간에 유지되어서는 안 됩니다.
11.3 사용자의 개인 정보 및 기본 설정은 사용자 세션으로 격리되어야 합니다.
11.4 앱 인스턴스를 서로 격리해야 합니다.
- 즉, 한 instance 사용자 데이터가 앱의 다른 instance 표시되지 않습니다. 비활성 사용자 세션의 소리는 활성 사용자 세션에서 들리지 않아야 합니다. 여러 앱 인스턴스가 공유 리소스를 사용하는 경우 앱은 충돌이 없는지 확인해야 합니다.
- UAC 요구 사항을 참조하세요.
12. 앱은 x64 버전의 Windows를 지원해야 합니다.
64비트 하드웨어가 더 일반화됨에 따라 사용자는 앱 개발자가 앱을 64비트로 마이그레이션하여 64비트 아키텍처의 이점을 활용하거나 32비트 버전의 앱이 64비트 버전의 Windows에서 잘 실행되기를 기대합니다.
- 12.1 앱은 기본적으로 64비트를 지원해야 합니다. 또는 최소한 32비트 Windows 기반 앱은 64비트 Windows 버전과의 호환성을 유지하기 위해 64비트 시스템에서 원활하게 실행되어야 합니다.
12.2 앱 및 해당 설치 관리자는 16비트 코드를 포함하거나 16비트 구성 요소를 사용해서는 안 됩니다.
12.3 앱 설정에서 64비트 아키텍처에 적합한 드라이버 및 구성 요소를 검색하고 설치해야 합니다.
12.4 모든 셸 플러그 인은 64비트 버전의 Windows에서 실행되어야 합니다.
12.5 WoW64 에뮬레이터에서 실행되는 앱은 Wow64 가상화 메커니즘을 전복하거나 바이패스하려고 시도해서는 안 됩니다.
- 앱이 WoW64 에뮬레이터에서 실행 중인지 여부를 감지해야 하는 특정 시나리오가 있는 경우 IsWow64Process를 호출하여 실행해야 합니다.
결론
이러한 요구 사항이 발전함에 따라 아래 수정 기록의 변경 내용을 살펴보겠습니다. 안정적인 요구 사항은 최상의 작업을 수행하는 데 중요하므로, Microsoft는 변경 내용이 지속 가능하도록 보장하고 앱을 계속 보호하고 개선하는 것을 목표로 합니다.
훌륭한 고객 경험을 제공하기 위한 우리의 노력에 참여해 주셔서 다시 한번 감사드립니다.
수정 기록
| Date | Version | 수정 설명 | 문서에 연결 |
|---|---|---|---|
| 2011년 12월 20일 | 1.0 | 미리 보기용 문서의 초기 초안입니다. | |
| 2012년 1월 26일 | 1.1 | 섹션 #2로 업데이트합니다. | 1.1 |
| 2012년 5월 31일 | 1.2 | 요약 테스트 결과 추가됨 | 1.2 |
| 2012년 6월 29일 | 3.0 | 최종 문서 Windows 8 | 3.0 |
| 2013년 6월 18일 | 3.1 | Windows 8.1 문서 | 3.1 |
| 2014년 2월 20일 | 3.2 | 내부 업데이트 | |
| 2014년 3월 18일 | 3.3 | Windows 8.1 Update 1 | 3.3 |
| 2015년 7월 29일 | 10 | Windows 10 업데이트 | 10 |
데스크톱 앱 인증에 대해 자세히 알아보기
| 요구 사항 | Description |
| 호환성 및 복원력 | 중단 & 충돌은 사용자에게 큰 혼란을 야기하고 좌절을 야기합니다. 앱은 복원력이 있고 안정적이어야 하며, 이러한 오류를 제거하면 소프트웨어가 더 예측 가능하고 유지 관리 가능하며 성능이 뛰어나며 신뢰할 수 있도록 하는 데 도움이 됩니다. 호환성을 위해 사용자 지향 앱 진입점을 매니페스트하고 올바른 GUID를 선언해야 합니다. HIGH-DPI 인식을 위해 사용자 연결 앱 진입점을 나타내야 하며 HIGH-DPI를 지원하기 위해 적절한 API가 호출되어야 합니다. 자세한 내용은 다음을 참조하세요. |
| Windows 보안 모범 사례 준수 | Windows 보안 모범 사례를 사용하면 Windows 공격 표면에 노출되지 않도록 방지할 수 있습니다. 공격 표면은 악의적인 공격자가 대상 소프트웨어의 취약성을 활용하여 운영 체제를 악용하는 데 사용할 수 있는 진입점입니다. 최악의 보안 취약성 중 하나는 권한 상승입니다. 자세한 내용은 다음을 참조하세요. |
| 지원 Windows 보안 기능 | Windows 운영 체제는 시스템 보안 및 개인 정보를 지원하기 위한 많은 조치를 구현했습니다. 애플리케이션은 OS의 무결성을 유지하기 위해 이러한 조치를 지원해야 합니다. 잘못 컴파일된 애플리케이션으로 인해 버퍼 오버런이 발생하여 서비스 거부 또는 악성 코드 실행이 발생할 수 있습니다. 자세한 내용은 BinScope 도구 참조를 참조하세요. |
| 시스템 다시 시작 관리자 메시지 준수 | 사용자가 종료를 시작할 때 대부분의 경우 종료가 성공하는 것을 보려는 강한 욕구가 있습니다. 그들은 서둘러 사무실을 떠나 "그냥 원하는"자신의 컴퓨터를 해제 할 수 있습니다. 앱은 종료를 차단하지 않음으로써 이러한 욕구를 존중해야 합니다. 대부분의 경우 종료는 중요하지 않을 수 있지만 중요한 종료 가능성에 대비해야 합니다. |
| 취소 가능한 설치 정리 | 클린 되돌릴 수 있는 설치를 통해 사용자는 시스템에서 앱을 성공적으로 관리(배포 및 제거)할 수 있습니다. 자세한 내용은 방법: ClickOnce 애플리케이션을 사용하여 필수 구성 요소 설치를 참조하세요. |
| 파일 및 드라이버에 디지털 서명 | Authenticode 디지털 서명을 사용하면 사용자가 소프트웨어가 정품인지 확인할 수 있습니다. 또한 파일이 바이러스에 감염된 경우와 같이 파일이 변조되었는지 여부를 감지할 수 있습니다. 커널 모드 코드 서명 적용은 CI(코드 무결성)라고 하는 Windows 기능으로, 파일 이미지가 메모리에 로드될 때마다 파일의 무결성을 확인하여 운영 체제의 보안을 향상시킵니다. CI는 악성 코드가 시스템 이진 파일을 수정했는지 여부를 검색합니다. 커널 모듈의 서명이 올바르게 확인되지 않을 때 진단 및 시스템 감사 로그 이벤트도 생성합니다. |
| 운영 체제 버전 검사 따라 설치 또는 앱 시작을 차단하지 마세요. | 기술적인 제한 사항이 없는 경우 고객이 앱을 설치하거나 실행하지 못하도록 인위적으로 차단하지 않는 것이 중요합니다. 일반적으로 앱이 Windows Vista 이상 릴리스용으로 작성된 경우 운영 체제 버전을 검사 이유가 없어야 합니다. 자세한 내용은 운영 체제 버전 관리를 참조하세요. |
| 안전 모드에서 서비스 및 드라이버 로드 안 함 | 안전 모드를 사용하면 사용자가 Windows를 진단하고 문제를 해결할 수 있습니다. 시스템의 기본 작업(예: 스토리지 디바이스 드라이버) 또는 진단 및 복구 목적(예: 바이러스 백신 스캐너)에 필요한 경우가 아니면 드라이버와 서비스를 안전 모드로 로드하도록 설정해서는 안 됩니다. 기본적으로 안전 모드는 Windows와 함께 사전 설치되지 않은 대부분의 드라이버 및 서비스를 시작하지 않습니다. 시스템에서 기본 작업 또는 진단 및 복구 목적으로 요구하지 않는 한 사용하지 않도록 설정해야 합니다. 자세한 내용은 다음을 참조하세요. |
| UAC(사용자 계정 컨트롤) 지침 준수 | 일부 Windows 앱은 관리자 계정의 보안 컨텍스트에서 실행되며, 많은 경우 과도한 사용자 권한과 Windows 권한이 필요합니다. 리소스에 대한 액세스를 제어하면 사용자가 원치 않는 변경에 대해 시스템을 제어할 수 있습니다(원치 않는 변경은 컴퓨터를 은밀하게 인수하는 루트킷 또는 제한된 권한이 있는 사용자의 작업(예: 회사 컴퓨터에 금지된 소프트웨어를 설치하는 직원)과 같은 악의적일 수 있습니다). 리소스에 대한 액세스를 제어하는 가장 중요한 규칙은 사용자가 필요한 작업을 수행하는 데 필요한 최소한의 액세스 표준 사용자 컨텍스트를 제공하는 것입니다. UAC 지침에 따라 시스템은 보안 위험에 지속적으로 노출되지 않고 필요할 때 필요한 권한을 앱에 제공합니다. 자세한 내용은 다음을 참조하세요. |
| 기본적으로 올바른 폴더에 설치 | 사용자는 선택한 위치에 앱을 설치하는 옵션을 유지하면서 파일의 기본 설치 위치에 일관되고 안전한 환경을 가져야 합니다. 또한 여러 사람이 서로의 데이터와 설정을 손상시키거나 덮어쓰지 않고 동일한 컴퓨터를 사용할 수 있도록 앱 데이터를 올바른 위치에 저장해야 합니다. 자세한 내용은 설치/제거 요구 사항 요약을 참조하세요. |
| 다중 사용자 세션 지원 | Windows 사용자는 충돌 또는 중단 없이 동시 세션을 실행할 수 있어야 합니다. 자세한 내용은 원격 데스크톱 서비스 프로그래밍 지침을 참조하세요. |
| x64 버전의 Windows 지원 | 64비트 하드웨어가 널리 보급됨에 따라 사용자는 앱 개발자가 앱을 64비트로 마이그레이션하거나 32비트 버전의 앱이 64비트 버전의 Windows에서 잘 실행되도록 하여 64비트 아키텍처의 이점을 활용할 것으로 기대합니다. |
추가 정보
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기