요청자에 대한 보안 고려 사항
VSS 인프라를 사용하려면 백업 애플리케이션과 같은 VSS 요청자가 COM 클라이언트와 서버로 모두 작동할 수 있어야 합니다.
서버 역할을 할 때 요청자는 외부 프로세스(예: 기록기 또는 VSS 서비스)에서 호출할 수 있는 COM 콜백 인터페이스 집합을 노출합니다. 따라서 요청자는 프로세스에 들어오는 COM 호출을 수행할 수 있는 COM 클라이언트를 안전하게 관리해야 합니다.
마찬가지로 요청자는 VSS 기록기 또는 VSS 서비스에서 제공하는 COM API에 대한 COM 클라이언트 역할을 할 수 있습니다. 요청자별 보안 설정은 요청자에서 이러한 다른 프로세스로 보내는 COM 호출을 허용해야 합니다.
요청자의 보안 문제를 관리하는 가장 간단한 메커니즘에는 실행 중인 사용자 계정을 적절히 선택하는 것이 포함됩니다.
요청자는 일반적으로 Administrators 그룹 또는 Backup 연산자 그룹의 구성원인 사용자에서 실행하거나 로컬 시스템 계정으로 실행해야 합니다.
기본적으로 요청자가 COM 클라이언트 역할을 하는 경우 이러한 계정으로 실행되지 않으면 COM 메서드 구현에 액세스하지 않고 도 E_ACCESSDENIED COM 호출이 자동으로 거부됩니다.
COM 예외 처리 사용 안 림
요청자를 개발할 때 COM COMGLB_EXCEPTION_DONOT_HANDLE 전역 옵션 플래그를 설정하여 COM 예외 처리를 사용하지 않도록 설정합니다. COM 예외 처리는 VSS 애플리케이션에서 치명적인 오류를 마스킹할 수 있으므로 이 작업을 수행하는 것이 중요합니다. 마스킹된 오류는 프로세스가 불안정하고 예측할 수 없는 상태로 남을 수 있으며 이로 인해 손상 및 중단이 발생할 수 있습니다. 이 플래그에 대한 자세한 내용은 IGlobalOptions를 참조하세요.
요청자 기본 COM 액세스 확인 권한 설정
요청자는 프로세스가 서버 역할을 할 때(예: 작성자가 백업 구성 요소 문서를 수정할 수 있도록 허용) 기록기 또는 VSS 서비스와 같은 다른 VSS 참가자의 수신 호출을 허용해야 한다는 점에 유의해야 합니다.
그러나 기본적으로 Windows 프로세스는 동일한 로그온 세션(SELF SID)에서 실행되거나 로컬 시스템 계정으로 실행되는 COM 클라이언트만 허용합니다. 이러한 기본값은 VSS 인프라에 적합하지 않기 때문에 잠재적인 문제입니다. 예를 들어 기록기는 요청자 프로세스 또는 로컬 시스템 계정과 동일한 로그온 세션에 있지 않은 "Backup 운영자" 사용자 계정으로 실행될 수 있습니다.
이러한 유형의 문제를 처리하기 위해 모든 COM 서버 프로세스는 CoInitializeSecurity 를 사용하여 프로세스 차원의 "기본 COM 액세스 확인 권한"을 설정하여 RPC 또는 COM 클라이언트가 서버(이 경우 요청자)에서 구현하는 COM 메서드를 수행할 수 있는지 여부를 추가로 제어할 수 있습니다.
요청자는 다음을 명시적으로 수행할 수 있습니다.
모든 프로세스에서 요청자 프로세스를 호출할 수 있도록 허용합니다.
이 옵션은 대부분의 요청자에게 적합할 수 있으며 다른 COM 서버에서 사용됩니다. 예를 들어 모든 SVCHOST 기반 Windows 서비스는 기본적으로 모든 COM+ 서비스와 마찬가지로 이 옵션을 이미 사용하고 있습니다.
모든 프로세스가 들어오는 COM 호출을 수행하도록 허용하는 것이 반드시 보안 약점은 아닙니다. 다른 모든 COM 서버와 마찬가지로 COM 서버 역할을 하는 요청자는 프로세스에서 구현된 모든 COM 메서드에서 클라이언트에 권한을 부여하는 옵션을 항상 유지합니다.
VSS에서 구현하는 내부 COM 콜백은 기본적으로 보호됩니다.
요청자에 대한 모든 프로세스 COM 액세스를 허용하려면 NULL 보안 설명자를 CoInitializeSecurity의 첫 번째 매개 변수로 전달할 수 있습니다. ( CoInitializeSecurity 는 전체 프로세스에 대해 최대 한 번 호출되어야 합니다. CoInitializeSecurity 호출에 대한 자세한 내용은 COM 설명서 또는 MSDN을 참조하세요.)
다음 코드 예제에서는 RVSS(원격 파일 공유)에 대해 VSS와 호환되기 위해 요청자가 Windows 8 및 Windows Server 2012 이상에서 CoInitializeSecurity를 호출하는 방법을 보여 줍니다.
// Initialize COM security. hr = CoInitializeSecurity( NULL, // PSECURITY_DESCRIPTOR pSecDesc, -1, // LONG cAuthSvc, NULL, // SOLE_AUTHENTICATION_SERVICE *asAuthSvc, NULL, // void *pReserved1, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, // DWORD dwAuthnLevel, RPC_C_IMP_LEVEL_IMPERSONATE, // DWORD dwImpLevel, NULL, // void *pAuthList, EOAC_STATIC, // DWORD dwCapabilities, NULL // void *pReserved3 );CoInitializeSecurity를 사용하여 요청자의 COM 수준 보안을 명시적으로 설정하는 경우 다음을 수행해야 합니다.
- 인증 수준을 RPC_C_AUTHN_LEVEL_PKT_INTEGRITY 이상으로 설정합니다. 보안을 강화하려면 RPC_C_AUTHN_LEVEL_PKT_PRIVACY 사용하는 것이 좋습니다.
- 가장 수준을 RPC_C_IMP_LEVEL_IMPERSONATE 설정합니다.
- 은폐 보안 기능을 EOAC_STATIC 설정합니다. 보안 은폐에 대한 자세한 내용은 은폐를 참조하세요.
다음 코드 예제에서는 RVSS 호환성이 필요하지 않은 경우 요청자가 Windows 7 및 Windows Server 2008 R2 이하(또는 Windows 8 및 Windows Server 2012 이상)에서 CoInitializeSecurity를 호출하는 방법을 보여 줍니다.
// Initialize COM security. hr = CoInitializeSecurity( NULL, // PSECURITY_DESCRIPTOR pSecDesc, -1, // LONG cAuthSvc, NULL, // SOLE_AUTHENTICATION_SERVICE *asAuthSvc, NULL, // void *pReserved1, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, // DWORD dwAuthnLevel, RPC_C_IMP_LEVEL_IDENTIFY, // DWORD dwImpLevel, NULL, // void *pAuthList, EOAC_NONE, // DWORD dwCapabilities, NULL // void *pReserved3 );CoInitializeSecurity를 사용하여 요청자의 COM 수준 보안을 명시적으로 설정하는 경우 다음을 수행해야 합니다.
- 인증 수준을 RPC_C_AUTHN_LEVEL_CONNECT 이상으로 설정합니다. 보안을 강화하려면 RPC_C_AUTHN_LEVEL_PKT_PRIVACY 사용하는 것이 좋습니다.
- 요청자 프로세스가 VSS와 관련이 없는 특정 RPC 또는 COM 호출에 대한 가장을 허용해야 하는 경우가 아니면 가장 수준을 RPC_C_IMP_LEVEL_IDENTIFY 설정합니다.
지정된 프로세스 액세스만 허용하여 요청자 프로세스를 호출할 수 있습니다.
첫 번째 매개 변수로 NULL이 아닌 보안 설명자를 사용하여 CoInitializeSecurity를 호출하는 COM 서버(예: 요청자)는 설명자를 사용하여 특정 계정 집합에 속한 사용자의 수신 호출만 수락하도록 자체적으로 구성할 수 있습니다.
요청자는 유효한 사용자로 실행되는 COM 클라이언트가 해당 프로세스를 호출할 권한이 있는지 확인해야 합니다. 첫 번째 매개 변수에서 보안 설명자를 지정하는 요청자는 다음 사용자가 요청자 프로세스로 들어오는 호출을 수행할 수 있도록 허용해야 합니다.
로컬 시스템
로컬 서비스
Windows XP: 이 값은 Windows Server 2003까지 지원되지 않습니다.
네트워크 서비스
Windows XP: 이 값은 Windows Server 2003까지 지원되지 않습니다.
로컬 관리자 그룹의 구성원
로컬 Backup 연산자 그룹의 구성원
"1"을 REG_DWORD 값으로 사용하여 아래 레지스트리 위치에 지정된 특수 사용자
요청자에 대한 사용자 계정 액세스 명시적으로 제어
요청자에 대한 액세스를 로컬 시스템으로 실행하거나 로컬 관리자 또는 로컬 백업 운영자 그룹에서 실행되는 프로세스로 제한하는 것이 너무 제한적일 수 있는 경우가 있습니다.
예를 들어 지정된 요청자 프로세스는 일반적으로 관리자 또는 Backup 운영자 계정으로 실행하지 않아도 될 수 있습니다. 보안상의 이유로 VSS를 지원하기 위해 프로세스 권한을 인위적으로 승격하지 않는 것이 가장 좋습니다.
이러한 경우 지정된 사용자가 VSS 요청자를 실행하는 것이 안전하다는 것을VSS\에 지시하도록 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ VSSVssAccessControl 레지스트리 키를 수정해야 합니다.
이 키 아래에서 액세스 권한을 부여하거나 거부할 계정과 이름이 같은 하위 키를 만들어야 합니다. 이 하위 키는 다음 표의 값 중 하나로 설정해야 합니다.
| 값 | 의미 |
|---|---|
| 0 | 작성자 및 요청자에 대한 사용자 액세스를 거부합니다. |
| 1 | 작성기에 대한 액세스 권한을 사용자에게 부여합니다. |
| 2 | 요청자에게 사용자 액세스 권한을 부여합니다. |
| 3 | 사용자에게 기록기 및 요청자에게 액세스 권한을 부여합니다. |
다음 예제에서는 "MyDomain\MyUser" 계정에 대한 액세스 권한을 부여합니다.
HKEY_LOCAL_MACHINE
SYSTEM
CurrentControlSet
Services
VSS
VssAccessControl
MyDomain\MyUser = 2<dl>
<dt>
Data type
</dt>
<dd> REG_DWORD</dd>
</dl>
이 메커니즘을 사용하여 달리 허용된 사용자가 VSS 요청자를 실행하지 못하도록 명시적으로 제한할 수도 있습니다. 다음 예제에서는 "ThatDomain\Administrator" 계정의 액세스를 제한합니다.
HKEY_LOCAL_MACHINE
SYSTEM
CurrentControlSet
Services
VSS
VssAccessControl
ThatDomain\Administrator = 0<dl>
<dt>
Data type
</dt>
<dd> REG_DWORD</dd>
</dl>
사용자 ThatDomain\Administrator는 VSS 요청자를 실행할 수 없습니다.
시스템 상태의 파일 백업 수행
요청자가 백업에 볼륨 이미지를 사용하는 대신 개별 파일을 백업하여 시스템 상태 백업을 수행하는 경우 FindFirstFileNameW 및 FindNextFileNameW 함수를 호출하여 다음 디렉터리에 있는 파일에 대한 하드 링크를 열거해야 합니다.
- Windows\system32\WDI\perftrack\
- Windows\WINSXS\
이러한 디렉터리들은 Administrators 그룹의 구성원만 액세스할 수 있습니다. 이러한 이유로 이러한 요청자는 시스템 계정 또는 Administrators 그룹의 구성원인 사용자 계정으로 실행되어야 합니다.
Windows XP 및 Windows Server 2003:FindFirstFileNameW 및 FindNextFileNameW 함수는 Windows Vista 및 Windows Server 2008까지 지원되지 않습니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기