HTTP 보안을 통한 RPC

RPC over HTTP는 표준 RPC 보안 외에도 세 가지 유형의 보안을 제공하므로 RPC에서 HTTP 트래픽을 통해 RPC를 한 번 보호한 다음 HTTP를 통해 RPC에서 제공하는 터널링 메커니즘에 의해 이중으로 보호됩니다. 표준 RPC 보안 메커니즘에 대한 설명은 보안을 참조 하세요. HTTP 터널링 메커니즘을 통한 RPC는 다음과 같은 방식으로 일반 RPC 보안에 추가됩니다.

  • IIS를 통해 보안을 제공합니다(HTTP v2를 통한 RPC에만 사용 가능).
  • SSL 암호화 및 RPC 프록시 확인(상호 인증)을 제공합니다. HTTP v2를 통한 RPC에서만 사용할 수 있습니다.
  • HTTP 호출을 통해 RPC를 수신할 수 있는 서버 네트워크의 컴퓨터를 지시하는 RPC 프록시 수준에 대한 제한을 제공합니다.

이러한 세 가지 보안 기능은 각각 다음 섹션에서 자세히 설명합니다.

IIS 인증

HTTP를 통한 RPC는 IIS의 일반 인증 메커니즘을 활용할 수 있습니다. RPC 프록시에 대한 가상 디렉터리를 IIS MMC 스냅인의 기본 웹 사이트 아래에 있는 Rpc 노드를 사용하여 구성할 수 있습니다.

Screenshot showing the Rpc node under the Default Web Site in the IIS MMC snap-in.

익명 액세스를 사용하지 않도록 IIS를 구성하고 RPC 프록시에 대한 가상 디렉터리에 대한 인증을 요구할 수 있습니다. 이렇게 하려면 Rpc 노드를 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다. 디렉터리 보안 탭을 선택하고 다음과 같이 인증 및 액세스 제어 그룹에서 편집 단추를 클릭합니다.

Screenshot showing the RPC Properties dialog box.

RPC 프록시 가상 디렉터리가 익명 액세스를 허용하는 경우에도 HTTP를 통해 RPC를 사용할 수 있지만 보안상의 이유로 해당 가상 디렉터리에 대한 익명 액세스를 사용하지 않도록 설정하는 것이 좋습니다. 대신 HTTP를 통한 RPC의 경우 기본 인증, Windows 통합 인증 또는 둘 다를 사용하도록 설정합니다. HTTP v2를 통한 RPC만 기본 또는 Windows 통합 인증이 필요한 RPC 프록시에 대해 인증할 수 있습니다. 익명 액세스를 허용하지 않는 경우 HTTP v1을 통한 RPC는 연결할 수 없습니다. HTTP v2를 통한 RPC는 보다 안전하고 강력한 구현이므로 이를 지원하는 Windows 버전을 사용하면 설치의 보안이 향상됩니다.

참고 항목

기본적으로 RPC 프록시 가상 디렉터리가 익명 액세스를 허용하도록 표시됩니다. 그러나 HTTP v2를 통한 RPC 프록시는 기본적으로 인증되지 않은 요청을 거부합니다.

 

트래픽 암호화

HTTP를 통한 RPC는 HTTP 클라이언트를 통한 RPC와 SSL을 사용하여 RPC 프록시 간의 트래픽을 암호화할 수 있습니다. HTTP 서버를 통한 RPC 프록시와 RPC 간의 트래픽은 일반 RPC 보안 메커니즘을 사용하여 암호화되며 SSL을 사용하지 않습니다(클라이언트와 RPC 프록시 간의 SSL이 선택된 경우에도). 트래픽의 해당 부분이 조직의 네트워크 내에서 방화벽 뒤로 이동하기 때문입니다.

일반적으로 인터넷을 통해 이동하는 RPC 클라이언트와 RPC 프록시 간의 트래픽은 RPC에 대해 선택된 암호화 메커니즘 외에도 SSL로 암호화할 수 있습니다. 이 경우 경로의 인터넷 부분에서 트래픽이 이중 암호화됩니다. RPC 프록시를 통해 트래픽을 암호화하면 RPC 프록시 또는 경계 네트워크의 다른 컴퓨터가 손상된 경우 보조 방어가 제공됩니다. RPC 프록시는 보조 암호화 계층의 암호를 해독할 수 없으므로 RPC 프록시는 전송되는 데이터에 액세스할 수 없습니다. 자세한 내용은 HTTP 배포 권장 사항 통해 RPC를 참조하세요. SSL 암호화는 HTTP v2를 통한 RPC에서만 사용할 수 있습니다.

특정 컴퓨터에 대한 HTTP 호출을 통한 RPC 제한

IIS 보안 구성은 허용되는 컴퓨터 및 포트 범위를 기반으로 합니다. HTTP를 통해 RPC를 사용하는 기능은 IIS 및 RPC 프록시를 실행하는 컴퓨터의 두 레지스트리 항목에 의해 제어됩니다. 첫 번째 항목은 RPC 프록시 기능을 토글하는 플래그입니다. 두 번째는 프록시가 RPC 호출을 전달할 수 있는 컴퓨터의 선택적 목록입니다.

기본적으로 RPC 프록시에 연결하여 HTTP 호출을 통해 RPC를 터널하는 클라이언트는 RPC 프록시와 동일한 컴퓨터에서 실행되는 RPC over HTTP 서버 프로세스를 제외한 모든 RPC 서버 프로세스에 액세스할 수 없습니다. ENABLED 플래그가 정의되지 않았거나 0 값으로 설정된 경우 IIS는 RPC 프록시를 사용하지 않도록 설정합니다. ENABLED 플래그가 정의되고 0이 아닌 값으로 설정된 경우 클라이언트는 IIS를 실행하는 컴퓨터의 HTTP 서버를 통해 RPC에 연결할 수 있습니다. 클라이언트가 다른 컴퓨터의 HTTP 서버 프로세스를 통해 RPC에 터널링할 수 있도록 하려면 HTTP 서버를 통해 IIS 컴퓨터의 RPC 목록에 레지스트리 항목을 추가해야 합니다.

RPC 서버는 특별히 RPC가 HTTP를 통해 RPC에서 수신하도록 요청하지 않는 한 HTTP 호출을 통해 RPC를 수락할 수 없습니다.

다음 예제에서는 클라이언트가 인터넷을 통해 서버에 연결할 수 있도록 레지스트리를 구성하는 방법을 보여 줍니다.

HKEY_LOCAL_MACHINE\
   Software\Microsoft\Rpc\RpcProxy\Enabled:REG_DWORD
   Software\Microsoft\Rpc\RpcProxy\ValidPorts:REG_SZ

ValidPorts 항목은 IIS RPC 프록시가 RPC 호출을 전달할 수 있는 컴퓨터 목록과 RPC 서버에 연결하는 데 사용해야 하는 포트를 포함하는 REG_SZ 항목입니다. REG_SZ 항목은 다음과 같은 형식을 사용합니다. Rosco:593; Rosco:2000-8000; Data*:4000-8000.

이 예제에서 IIS는 포트 593 및 2000에서 8000까지 서버 "Rosco"에 HTTP 호출을 통해 RPC를 전달할 수 있습니다. 또한 이름이 "Data"로 시작하는 모든 서버에 대한 호출을 보낼 수 있습니다. 4000~8000 포트에 연결됩니다. 또한 HTTP 서버를 통해 RPC의 지정된 포트로 트래픽을 전달하기 전에 RPC 프록시는 해당 포트에서 수신 대기하는 RPC 서비스와 특수 패킷 교환을 수행하여 HTTP를 통한 요청을 수락할 의향이 있는지 확인합니다.

이러한 예제 설정을 기반으로 하는 예제의 경우 RPC 서비스가 서버 "Data1"의 포트 4500에서 수신 대기하지만 ncacn_http 사용하여 RpcServerUseProtseq* 함수 하나를 호출하지 않은 경우 요청을 거부합니다. 이 동작은 구성 오류로 인해 열린 포트에서 수신 대기하는 서버에 대한 추가 보호를 제공합니다. 서버가 HTTP를 통해 RPC에서 수신하도록 특별히 요청하지 않는 한 방화벽 외부에서 발생하는 호출을 수신하지 않습니다.

ValidPorts 키의 항목은 클라이언트가 요청한 HTTP 서버를 통한 RPC와 정확히 일치해야 합니다(대/소문자를 구분하지 않음). 처리를 간소화하기 위해 RPC 프록시는 HTTP 클라이언트를 통해 RPC에서 제공하는 이름의 정식화를 수행하지 않습니다. 따라서 클라이언트가 rosco.microsoft.com 요청하고 ValidPortsRosco만 포함된 경우 두 이름이 동일한 컴퓨터를 참조할 수 있더라도 RPC 프록시는 이름과 일치하지 않습니다. 또한 Rosco의 IP 주소가 66.77.88.99이고 클라이언트가 66.77.88.99를 요청하지만 ValidPorts 키에 Rosco만 포함된 경우 RPC 프록시는 연결을 거부합니다. 클라이언트가 이름 또는 IP 주소로 HTTP 서버를 통해 RPC를 요청할 수 있는 경우 ValidPorts 키에 둘 다 삽입합니다 .

참고 항목

RPC는 IPv6을 사용하도록 설정되어 있지만 RPC 프록시는 ValidPorts 키의 IPv6 주소를 지원하지 않습니다. IPv6을 사용하여 RPC 프록시와 RPC over HTTP 서버를 연결하는 경우 DNS 이름만 사용할 수 있습니다.

 

IIS는 시작 시 EnabledValidPorts 레지스트리 항목을 읽습니다. 또한 HTTP를 통한 RPC는 약 5분마다 ValidPorts 키의 콘텐츠를 다시 읽습니다. ValidPorts 항목이 변경되면 변경 내용이 5분 이내에 구현됩니다.

HTTP v1을 통한 RPC: 구현할 레지스트리 항목의 새 값에 대해 Internet Service Manager를 사용하여 웹 서비스를 중지하고 다시 시작해야 합니다.