내보내기(0) 인쇄
모두 확장
확장 최소화

DCOM 보안 강화

적용 대상: Windows Server 2003 with SP1

DCOM의 기능은 무엇입니까?

Microsoft COM(Component Object Model)은 플랫폼에 상관없이 작동하는 분산형 개체 지향 시스템으로서 상호 작용할 수 있는 이진 소프트웨어 구성 요소를 만들 수 있습니다. DCOM(Distributed Component Object Model)을 사용하면 사용자와 응용 프로그램에 가장 적절한 위치에 응용 프로그램을 배포할 수 있습니다. DCOM 와이어 프로토콜은 COM 구성 요소 사이의 안정적이고 안전하며 효율적인 통신을 지원합니다. 자세한 내용은 Microsoft 웹 사이트(http://go.microsoft.com/fwlink/?LinkId=20922)에서 "구성 요소 개체 모델"을 참조하십시오.

이 기능의 적용 대상은 누구입니까?

처리 중인 COM 구성 요소에 대해서만 COM을 사용하는 경우에는 이 섹션이 적용되지 않습니다.

이 기능은 다음 기준 중 하나를 만족하는 COM 서버 응용 프로그램이 있는 경우에 적용됩니다.

  • 응용 프로그램에 대한 액세스 권한이 실행에 필요한 사용 권한보다 덜 엄격합니다.

  • 일반적으로 응용 프로그램은 관리 계정을 사용하지 않고 원격 COM 클라이언트에 의해 활성화됩니다.

  • 해당 응용 프로그램이 로컬 전용인 경우. 즉 COM 서버 응용 프로그램이 원격으로 액세스되지 않도록 제한할 수 있음을 의미합니다.

Windows Server 2003 서비스 팩 1에서 이 기능에 추가된 새로운 기능은 무엇입니까?

컴퓨터 전체의 제한 사항

자세한 설명

COM의 변경으로 컴퓨터에서의 모든 호출, 활성화 또는 시작 요청에 대한 액세스를 주관하는 컴퓨터 전체의 액세스 제어를 제공할 수 있습니다. 이러한 액세스 제어는 컴퓨터에서 임의의 COM 서버를 호출, 활성화 또는 시작할 때마다 컴퓨터 전체의 ACL(액세스 제어 목록)에 대해 수행되는 추가적인 AccessCheck 호출로 생각하는 것이 가장 간단합니다. AccessCheck이 실패하면 해당 호출, 활성화 또는 시작 요청은 거부됩니다. 이것은 해당 서버 고유의 ACL에 대해 실행되는 AccessCheck와는 별도입니다. 실제로 이것은 해당 컴퓨터의 COM 서버를 액세스하기 위해 통과해야 하는 최소의 인증 기준입니다. 활성화 및 시작 권한을 처리하는 시작 권한에 대한 컴퓨터 전체의 ACL과 호출 권한을 처리하는 액세스 권한에 대한 컴퓨터 전체의 ACL이 있습니다. 이러한 ACL은 구성 요소 서비스 MMC(Microsoft Management Console)를 통해 구성될 수 있습니다.

이와 같이 컴퓨터 전체의 ACL이 있으면 CoInitializeSecurity 또는 응용 프로그램 고유 보안 설정을 통해 특정 응용 프로그램에서 지정하는 취약한 보안 설정을 대체할 수 있습니다. ACL은 특정 서버의 설정에 관계없이 통과해야 하는 최소 보안 기준을 제공합니다.

이러한 ACL은 RPCSS에 의해 노출되는 인터페이스가 액세스될 때 확인됩니다. 이러한 기능으로 이 시스템 서비스에 액세스할 수 있는 사용자를 제어할 수 있습니다.

이러한 ACL을 사용하여 관리자는 해당 컴퓨터의 모든 COM 서버에 적용되는 일반적인 권한 부여 정책을 한 곳에서 설정할 수 있습니다.

기본적으로 Windows Server 2003 SP1 컴퓨터의 제한 설정은 다음과 같습니다.

DCOM 컴퓨터 제한 설정

사용 권한 Administrator 분산 COM 사용자(기본 제공 그룹) Everyone Anonymous

시작

로컬 시작

로컬 활성화

원격 시작

원격 활성화

로컬 시작

로컬 활성화

원격 시작

원격 활성화

로컬 시작

로컬 활성화

N/A

액세스

N/A

로컬 액세스

원격 액세스

로컬 액세스

원격 액세스

로컬 액세스

원격 액세스

note참고
분산된 COM 사용자는 DCOM 컴퓨터 제한 설정에 사용자를 신속하게 추가하기 위해 Windows Server 2003 서비스 팩 1에 포함된 새로운 기본 제공 그룹입니다.

이 변경 사항이 중요한 이유는 무엇입니까?

많은 COM 응용 프로그램이 보안 관련 코드(예: CoInitializeSecurity 호출)를 포함하고 있지만 취약한 설정을 사용하므로 프로세스로의 무단 액세스를 허용하는 경우가 많습니다. 현재 이전 버전의 Windows에서는 관리자가 이러한 설정을 무시하고 더 강한 보안을 적용할 방법이 없습니다.

COM 인프라에는 시스템 시작 시 실행되고 그 후 계속 작동하는 시스템 서비스인 RPCSS가 포함되어 있습니다. 이 서비스는 COM 개체와 실행 중인 개체 테이블의 활성화를 관리하며, DCOM 원격 기능에 대한 도움 및 지원 서비스를 제공합니다. 또한 원격으로 호출될 수 있는 RPC 인터페이스를 노출합니다. 일부 COM 서버는 이전 섹션에서 설명한 것처럼 인증되지 않은 원격 액세스를 허용하므로 인증되지 않은 사용자를 비롯해 누구나 이러한 인터페이스를 호출할 수 있습니다. 따라서 RPCSS는 인증되지 않은 원격 컴퓨터를 사용하는 악의적인 사용자의 공격을 받을 수 있습니다.

이전 버전의 Windows에서는 관리자가 컴퓨터에 있는 COM 서버의 노출 수준을 알 수 있는 방법이 없었습니다. 관리자는 컴퓨터의 등록된 모든 COM 응용 프로그램에 대해 구성된 보안 설정을 체계적으로 확인하여 노출 수준을 짐작할 수 있었으나 Windows의 기본 설치에 150개 정도의 COM 서버가 있는 경우 이것은 엄청난 작업이었습니다. 소프트웨어의 소스 코드를 검토하는 것 외에는 해당 소프트웨어로 보안을 통합하는 서버에 대한 설정을 볼 수 있는 방법이 없었습니다.

DCOM 컴퓨터 전체의 제한 사항으로 이러한 세 가지 문제를 차단할 수 있습니다. 또한 들어오는 DCOM 활성화, 시작 및 액세스 호출을 비활성화할 수 있는 기능을 관리자에게 제공합니다.

작동 방식의 차이는 무엇입니까?

기본적으로 Everyone 그룹에는 로컬 시작, 로컬 활성화 및 로컬 액세스 권한이 부여됩니다. 따라서 소프트웨어나 운영 체제를 수정하지 않고도 모든 로컬 시나리오를 적용할 수 있어야 합니다.

기본적으로 EveryoneAnonymous 그룹은 원격 액세스 권한이 허가됩니다. 이 경우 COM 클라이언트가 로컬 참조를 원격 서버로 전달하여 사실상 클라이언트를 서버로 변환하는 일반적인 경우를 포함하여 대부분의 COM 클라이언트 시나리오가 가능합니다.

또한 기본적으로 Administrators 그룹의 구성원에게만 원격 활성화 및 시작 권한이 부여됩니다. 이 경우 관리자가 아닌 사람은 설치된 COM 서버에 대해 원격으로 활성화할 수 없습니다.

이러한 문제를 해결하는 방법은 무엇입니까?

COM 서버를 구현하고 관리자가 아닌 COM 클라이언트에 의한 원격 활성화을 지원할 것으로 예상되는 경우 이러한 프로세스를 가능하게 하는 것과 관련된 위험이 감수할 수 있는 정도인지 아닌지, 또는 관리자가 아닌 COM 클라이언트에 의한 원격 활성화 또는 인증되지 않은 원격 호출을 요구하지 않도록 구현을 수정해야 하는지를 고려해야 합니다.

감수할 수 있을 정도의 위험이고 관리자가 아닌 COM 클라이언트에 의한 원격 활성화을 가능하게 하려는 경우 이 기능에 대한 기본 구성을 변경해야 합니다.

구성 요소 서비스 MMC(Microsoft Management Console) 또는 Windows 레지스트리를 사용하여 구성 설정을 변경할 수 있습니다.

구성 요소 서비스라는 MMC 스냅인을 사용할 경우 이러한 설정은 관리 중인 컴퓨터에 대한 속성 대화 상자의 COM 보안 탭에서 구성할 수 있습니다. COM 보안 탭은 사용자가 COM 서버에 대한 표준 기본 설정 외에 컴퓨터 전체의 제한 사항을 설정할 수 있도록 수정되었습니다. 또한 제한 사항 또는 기본값 모두에서 로컬 및 원격 액세스에 대해 별도의 ACL 설정을 제공할 수 있습니다.

또한 레지스트리를 사용하여 이러한 ACL 설정을 구성할 수 있습니다.

해당 ACL은 레지스트리의 다음 위치에 저장됩니다.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineAccessRestriction= ACL
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineLaunchRestriction= ACL

이러한 ACL은 REG_BINARY 형식의 명명된 값으로 컴퓨터의 COM 클래스 또는 COM 개체를 액세스할 수 있는 사용자의 ACL을 서술하는 데이터를 포함합니다. ACL의 액세스 권한은 다음과 같습니다.

COM_RIGHTS_EXECUTE 1
COM_RIGHTS_EXECUTE_LOCAL 2
COM_RIGHTS_EXECUTE_REMOTE 4
COM_RIGHTS_ACTIVATE_LOCAL 8
COM_RIGHTS_ACTIVATE_REMOTE 16

이러한 ACL은 일반 보안 기능을 사용하여 만들 수 있습니다.

note참고
COM_RIGHTS_EXECUTE 권한은 항상 존재해야 합니다. 이 권한이 없으면 잘못된 보안 설명자를 생성합니다. Administrator 권한이 있는 사용자만 이러한 설정을 수정할 수 있습니다.

기존 기능 중 Windows Server 2003 서비스 팩 1에서 변경된 기능은 무엇입니까?

RPCSS가 네트워크 서비스로 실행됩니다.

자세한 설명

RPCSS는 RPC 종점 매퍼와 네트워크를 지향하는 DCOM 인프라에 대한 핵심 서비스입니다. 이 서비스는 이전 버전의 Windows에서는 로컬 시스템으로 실행되었습니다. Windows의 공격 범위를 줄이고 철저한 방어를 제공하기 위해 RPCSS 서비스 기능은 두 개의 서비스로 분할되었습니다. 로컬 시스템 권한을 요구하지 않았던 원래의 기능을 모두 유지하고 있는 RPCSS 서비스는 현재는 네트워크 서비스 계정에서 실행됩니다. 로컬 시스템 권한이 필요한 기능을 포함하는 새 DCOMLaunch 서비스는 로컬 시스템 계정에서 실행됩니다. 그러나 이 서비스는 네트워크 페이싱이 아닙니다.

이 변경 사항이 중요한 이유는 무엇입니까?

이 변경으로 RPCSS 서비스의 권한 증가가 네트워크 서비스 권한으로 제한되기 때문에 공격 범위가 줄어들고 RPCSS 서비스를 철저하게 방어할 수 있습니다.

작동 방식의 차이는 무엇입니까?

RPCSS 및 DCOMLaunch 서비스 조합은 이전 버전의 Windows에서 제공된 이전 RPCSS 서비스와 동일하므로 이 변경 내용은 사용자에게 표시되지 않습니다.

자세한 COM 권한

자세한 설명

COM 서버 응용 프로그램에는 시작 권한과 액세스 권한이 있습니다. 시작 권한은 COM 서버가 아직 실행 중이 아닐 경우 COM 활성화 중에 해당 서버를 시작할 수 있는 권한을 제어합니다. 이러한 사용 권한은 레지스트리 설정에 지정되는 보안 설명자로 정의됩니다. 액세스 권한은 실행 중인 모든 COM 서버를 호출할 수 있는 권한을 제어합니다. 이러한 사용 권한은 CoInitializeSecurity API를 통하거나 레지스트리 설정을 사용하여 COM 인프라에 제공되는 보안 설명자로 정의됩니다. 시작 및 액세스 권한 둘 모두는 사용자에 따라 액세스를 허용하거나 거부하며 호출자가 서버에 대해 로컬인지 또는 원격인지는 구분하지 않습니다.

첫 번째 변경 사항으로 COM 액세스 권한을 거리에 따라 구별할 수 있습니다. 거리는 로컬 및 원격의 두 가지로 정의됩니다. 로컬 COM 메시지는 LRPC(Lightweight Remote Procedure Call) 프로토콜을 통해 배달되지만 원격 COM 메시지는 TCP(전송 제어 프로토콜)와 같은 RPC(원격 프로시저 호출) 호스트 프로토콜을 통해 배달됩니다.

COM 활성화는 CoCreateInstance 또는 해당 변형 중 하나를 호출하여 클라이언트에서 COM 인터페이스 프록시를 가져오는 작업입니다. 이러한 활성화 과정에서 때로는 COM 서버를 시작해야 클라이언트의 요청을 충족시킬 수 있는 경우가 있습니다. 시작 권한 ACL은 COM 서버를 시작할 수 있는 사용자를 정합니다. 액세스 권한 ACL은 COM 개체를 활성화하거나 COM 서버가 이미 실행된 후에 해당 개체를 호출할 수 있는 사용자를 정합니다.

두 번째 변경 사항은 호출 및 활성화 권한이 독립된 두 작업을 반영하고 활성화 권한을 액세스 권한 ACL에서 시작 권한 ACL로 이동하기 위해 분리된다는 것입니다. 활성화 및 시작이 모두 인터페이스 포인터를 얻는 것과 관련이 있으므로 활성화 및 시작 액세스 권한은 논리적으로 하나의 ACL에 함께 속해 있습니다. 흔히 프로그래밍 방식으로 지정되는 액세스 권한과 비교해 볼 때 항상 구성을 통해 시작 권한을 지정하므로 활성화 권한을 시작 권한 ACL에 넣으면 관리자가 활성화를 제어할 수 있습니다.

시작 권한 ACE(액세스 제어 항목)는 네 개의 액세스 권한으로 나뉩니다.

  • 로컬 시작(LL)

  • 원격 시작(RL)

  • 로컬 활성화(LA)

  • 원격 활성화(RA)

액세스 권한 보안 설명자는 두 개의 액세스 권한으로 나뉩니다.

  • 로컬 액세스 호출(LC)

  • 원격 액세스 호출(RC)

이렇게 하면 관리자가 매우 특정한 보안 구성을 적용할 수 있습니다. 예를 들어 모두로부터 로컬 호출을 받아들이지만 원격 호출은 Administrators로부터만 받아들이도록 COM 서버를 구성할 수 있습니다. 이러한 구성은 COM 권한 보안 설명자를 변경하여 지정할 수 있습니다.

이 변경 사항이 중요한 이유는 무엇이며 이로 인해 줄어드는 위협은 무엇입니까?

이전 버전의 COM 서버 응용 프로그램에서는 DCOM을 통해 응용 프로그램을 네트워크에 노출하지 않고 로컬로만 사용할 수 있도록 응용 프로그램을 제한할 수 없습니다. 사용자가 COM 서버 응용 프로그램에 액세스 권한이 있는 경우 로컬 및 원격 사용에 대해 모두 액세스 권한을 갖습니다.

COM 서버 응용 프로그램은 인증되지 않은 사용자에게 노출되어 COM 콜백 시나리오를 구현하려고 할 수 있습니다. 이 경우 응용 프로그램은 인증되지 않은 사용자에게도 해당 활성화를 노출해야 하므로 바람직하지 않습니다. 악의적인 사용자가 이 시나리오를 사용하여 해당 서버에 무단으로 액세스할 수 있기 때문입니다.

정확한 COM 권한은 관리자에게 컴퓨터의 COM 권한 정책을 제어할 수 있는 유연성을 제공합니다. 이러한 권한은 기술된 시나리오에 대한 보안을 가능하게 합니다.

작동 방식의 차이는 무엇입니까? 종속성이 있습니까?

이전 버전과의 호환성을 제공하기 위해 기존의 COM 보안 설명자는 로컬 및 원격 액세스 모두를 동시에 허용하거나 거부하도록 해석됩니다. 즉 액세스 제어 항목은 로컬 및 원격 액세스를 모두 허용하거나 로컬 및 원격 액세스를 모두 거부합니다.

호출 또는 시작 권한의 경우 이전 버전과의 호환성 문제가 없습니다. 그러나 활성화 권한 호환성 문제가 있습니다. COM 서버의 기존 보안 설명자에서 구성된 시작 권한이 액세스 권한보다 더 제한적이고 클라이언트 활성화 시나리오에 최소로 필요한 수준보다 더 제한적인 경우 승인된 클라이언트에게 적절한 활성 권한을 제공하도록 시작 권한 ACL을 수정해야 합니다.

기본 보안 설정을 사용하는 COM 응용 프로그램의 경우 호환성 문제는 없습니다. COM 활성화를 사용하여 동적으로 시작되는 응용 프로그램의 경우 대부분은 호환성 문제가 없으며 이는 시작 권한이 개체를 활성화할 수 있는 모든 사용자를 이미 포함하고 있어야 하기 때문입니다. 그렇지 않으면 시작 권한이 없는 호출자가 개체를 활성화하려고 하고 COM 서버가 아직 실행되고 있지 않을 경우 이러한 응용 프로그램은 서비스 팩 1을 적용하기도 전에 활성화 실패를 생성합니다.

대부분 호환성 문제와 관련된 응용 프로그램은 Windows 탐색기 또는 서비스 제어 관리자와 같은 다른 메커니즘을 통해 이미 시작된 COM 응용 프로그램입니다. 또한 기본 액세스 및 시작 권한을 무시하고 호출 권한보다 더 제한적인 시작 권한을 지정하는 이전의 COM 활성화를 통해 이러한 응용 프로그램을 시작할 수도 있습니다. 이 호환성 문제 해결에 대한 자세한 내용은 다음 섹션의 "이러한 문제를 해결하는 방법은 무엇입니까?"를 참조하십시오.

Windows Server 2003 서비스 팩 1로 업데이트된 시스템이 이전 서비스 팩으로 롤백되는 경우 로컬 액세스, 원격 액세스 또는 둘 다를 허용하도록 편집된 모든 액세스 제어 항목은 로컬 및 원격 액세스를 모두 허용하도록 해석됩니다. 로컬 액세스, 원격 액세스 또는 둘 다를 거부하도록 편집된 모든 ACE는 로컬 및 원격 액세스를 모두 거부하도록 해석됩니다. 서비스 팩을 제거할 때마다 새로 설정된 ACE 때문에 응용 프로그램의 작동이 중지되는지 확인해야 합니다.

이러한 문제를 해결하는 방법은 무엇입니까?

COM 서버를 구현하고 기본 보안 설정을 무시할 경우 응용 프로그램 관련 시작 권한 ACL이 해당 사용자에게 활성화 권한을 승인하는지 확인합니다. 그렇지 않을 경우 DCOM을 사용하는 응용 프로그램과 Windows 구성 요소가 실패하지 않도록 응용 프로그램 관련 시작 권한 ACL을 변경하여 해당 사용자에게 활성화 권한을 제공해야 합니다. 이러한 응용 프로그램 관련 시작 권한은 레지스트리에 저장됩니다.

COM ACL은 일반 보안 기능을 사용하여 만들거나 수정할 수 있습니다.

Windows Server 2003 서비스 팩 1에서 변경되거나 추가된 설정은 무엇입니까?

Caution주의
이러한 설정을 잘못 사용하면 DCOM을 사용하는 응용 프로그램과 Windows 구성 요소가 실패할 수 있습니다.

다음 표에서 다음 약어가 사용됩니다.

LL - 로컬 시작

LA - 로컬 활성화

RL - 원격 시작

RA - 원격 활성화

LC - 로컬 액세스 호출

RC - 원격 액세스 호출

DCOM 설정

설정 이름 위치 이전 기본값 기본값 사용 가능한 값

MachineLaunch Restriction

HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft\Ole\

Everyone: LL, LA, RL, RA

Anonymous: LL, LA, RL, RA

(이것은 새 레지스트리 키입니다. 기존 동작에 따라 유효한 값이 됩니다.)

Administrator: LL, LA, RL, RA

Everyone: LL, LA

분산 COM 사용자: LL, LA, RL, RA

ACL

MachineAccess Restriction

HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft\Ole\

Everyone: LC, RC

Anonymous: LC, RC

(이것은 새 레지스트리 키입니다. 기존 동작에 따라 유효한 값이 됩니다.)

Everyone: LC, RC

Anonymous: LC, RC

ACL

CallFailure LoggingLevel

HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Ole\

해당 없음

이 레지스트리 키는 존재하지 않습니다. 그러나 없는 키나 값은 2로 해석됩니다.

이 이벤트는 기본적으로 기록되지 않습니다. 문제를 해결하기 위해 이 값을 1로 변경하여 해당 정보를 기록할 경우 이 이벤트는 아주 많은 항목을 생성할 수 있으므로 이벤트 로그의 크기를 모니터링해야 합니다.

1 - COM 인프라가 잘못된 보안 설명자를 찾으면 항상 이벤트 로그 실패를 기록합니다.

2 - COM 인프라가 잘못된 보안 설명자를 찾으면 이벤트 로그 실패를 기록하지 않습니다.

InvalidSecurity Descriptor LoggingLevel

HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft\Ole\

해당 없음

이 레지스트리 키는 존재하지 않습니다. 그러나 없는 키나 값은 1로 해석됩니다.

이 이벤트는 기본적으로 기록되며 거의 발생하지 않습니다.

1 - COM 인프라가 잘못된 보안 설명자를 찾으면 항상 이벤트 로그 실패를 기록합니다.

2 - COM 인프라가 잘못된 보안 설명자를 찾으면 이벤트 로그 실패를 기록하지 않습니다.

DCOM:SDDL(Security Descriptor Definition Language)의 컴퓨터 실행 제한 구문

(그룹 정책 개체) Computer Configuration \Windows Settings \Local Policies \Security Options

해당 없음

정의되지 않음

SDDL 형식의 액세스 제어 목록. 이 정책이 존재하면 위에 있는 MachineLaunch 제한의 값을 무시합니다.

DCOM:SDDL(Security Descriptor Definition Language)의 컴퓨터 액세스 제한 구문

(그룹 정책 개체) Computer Configuration \Windows Settings \Local Policies \Security Options

해당 없음

정의되지 않음

SDDL 형식의 제어 목록. 이 정책이 존재하면 위에 있는 MachineAccess 제한의 값을 무시합니다.

이 정보가 도움이 되었습니까?
(1500자 남음)
의견을 주셔서 감사합니다.

커뮤니티 추가 항목

추가
표시:
© 2014 Microsoft