다음을 통해 공유

HTTP 배포 권장 사항을 통한 RPC

  • 아티클

이 섹션에서는 HTTP를 통해 RPC를 사용할 때 최대 보안 및 성능을 달성하기 위한 모범 사례 및 권장 배포 구성을 설명합니다. 여기에 있는 다양한 구성은 다양한 크기, 예산 및 보안 요구 사항에 따라 다양한 조직을 적용합니다. 또한 각 구성은 지정된 시나리오에 가장 적합한 것을 결정하는 데 유용한 배포 고려 사항을 제공합니다.

HTTP 시나리오를 통한 대용량 RPC에 대한 자세한 내용은 Microsoft RPC 부하 분산을 참조하세요.

다음 권장 사항은 모든 구성에 적용됩니다.

  • HTTP v2를 통해 RPC를 지원하는 Windows 버전을 사용합니다.
  • IIS 6.0 모드에서 RPC 프록시를 실행하는 컴퓨터에 IIS를 배치합니다.
  • RPC 프록시 가상 디렉터리에 대한 익명 액세스를 허용하지 않습니다.
  • AllowAnonymous 레지스트리 키를 사용하도록 설정하지 마세요.
  • HTTP를 통한 RPC 클라이언트에서 CertificateSubjectField (자세한 내용은 RpcBindingSetAuthInfoEx 참조)를 사용하여 연결한 RPC 프록시가 예상한 RPC 프록시인지 확인합니다.
  • RPC over HTTP 클라이언트가 연결할 컴퓨터만 포함하도록 ValidPorts 레지스트리 키를 구성합니다.
  • ValidPorts 키에는 와일드카드를 사용하지 마세요. 이렇게 하면 시간을 절약할 수 있지만 완전히 예기치 않은 컴퓨터가 와일드카드에도 적합할 수 있습니다.
  • HTTP 클라이언트를 통해 RPC에서 SSL을 사용합니다. 이러한 섹션에 명시된 지침을 따르는 경우 RPC over HTTP 클라이언트는 SSL을 사용하지 않고 연결할 수 없습니다.
  • SSL을 사용하는 것 외에도 RPC 암호화를 사용하도록 HTTP 클라이언트를 통해 RPC를 구성합니다. HTTP를 통한 RPC 클라이언트가 KDC에 연결할 수 없는 경우 Negotiate 및 NTLM만 사용할 수 있습니다.
  • NTLMv2를 사용하도록 클라이언트 머신을 구성합니다. LMCompatibilityLevel 레지스트리 키를 2 이상으로 설정합니다. LMCompatibilityLevel 키에 대한 자세한 내용은 msdn.microsoft.com 참조하세요.
  • 위에 설명된 구성을 사용하여 RPC 프록시 컴퓨터의 웹 팜을 실행합니다.
  • 인터넷과 RPC 프록시 간에 방화벽을 배포합니다.
  • 최적의 성능을 위해 성공하지 못 한 오류 코드에 대한 짧은 응답을 보내도록 IIS를 구성합니다. IIS 응답의 소비자는 자동화된 프로세스이므로 사용자에게 친숙한 설명을 클라이언트로 보낼 필요가 없습니다. HTTP 클라이언트를 통한 RPC에서 단순히 무시됩니다.

보안, 성능 및 관리 효율성 관점에서 RPC 프록시의 기본 목표는 다음과 같습니다.

  • 서버 네트워크에 대한 HTTP 트래픽을 통해 RPC에 대한 단일 진입점을 제공합니다. 서버 네트워크에 HTTP 트래픽을 통한 RPC에 대한 단일 진입점이 있으면 두 가지 기본 이점이 있습니다. 첫째, RPC 프록시가 인터넷에 연결되어 있기 때문에 대부분의 조직은 일반 조직 네트워크와 분리된 신뢰할 수 없는 경계 네트워크라는 특수 네트워크에서 이러한 컴퓨터를 격리합니다. 신뢰할 수 없는 경계 네트워크의 서버는 인터넷의 공격을 견딜 수 있도록 매우 신중하게 관리, 구성 및 모니터링됩니다. 신뢰할 수 없는 경계 네트워크에 있는 컴퓨터가 적을수록 더 쉽게 구성, 관리, 모니터링 및 보안을 유지할 수 있습니다. 둘째, RPC 프록시가 설치된 단일 웹 팜은 회사 네트워크에 있는 HTTP 서버를 통해 임의의 수의 RPC를 서비스할 수 있으므로 RPC 프록시를 HTTP 서버를 통해 RPC 프록시와 분리하고 RPC 프록시가 신뢰할 수 없는 경계 네트워크에 상주하도록 하는 것이 좋습니다. RPC 프록시가 HTTP 서버를 통한 RPC와 동일한 컴퓨터에 있는 경우 조직은 모든 백 엔드 서버를 신뢰할 수 없는 경계 네트워크에 배치해야 하므로 신뢰할 수 없는 경계 네트워크를 안전하게 유지하기가 훨씬 어려워집니다. RPC 프록시의 역할과 HTTP 서버를 통한 RPC를 분리하면 조직에서 신뢰할 수 없는 경계 네트워크의 컴퓨터 수를 관리가 가능하고 더 안전하게 유지할 수 있습니다.
  • 서버 네트워크의 안전 퓨즈 역할을 합니다. RPC 프록시는 서버 네트워크에 대한 소모성 퓨즈로 설계되었습니다. RPC 프록시에서 문제가 발생하면 단순히 꺼지고 HTTP 서버를 통해 실제 RPC를 보호합니다. 이 섹션에 설명된 모범 사례를 지금까지 따른 경우 HTTP 트래픽을 통한 RPC는 SSL 외에 RPC 암호화로 암호화됩니다. RPC 암호화 자체는 클라이언트와 프록시가 아니라 클라이언트와 서버 사이에 있습니다. 즉, 프록시가 수신하는 RPC 트래픽을 이해하지 못하고 암호를 해독할 수 없습니다. 연결 설정, 흐름 제어 및 기타 터널링 세부 정보를 처리하는 클라이언트가 전송한 일부 컨트롤 시퀀스만 이해합니다. HTTP 클라이언트를 통해 RPC가 서버에 보내는 데이터에 액세스할 수 없습니다. 또한 RPC over HTTP 클라이언트는 RPC 프록시와 RPC over HTTP 서버 모두에 대해 독립적으로 인증해야 합니다. 이를 통해 심층 방어가 제공됩니다. 일부 구성 오류 또는 일종의 보안 위반으로 인해 RPC 프록시 컴퓨터가 손상되는 경우 이를 통과하는 데이터는 변조로부터 보호됩니다. RPC 프록시를 제어하는 공격자는 트래픽을 최대로 방해할 수 있지만 읽거나 변조할 수는 없습니다. RPC 프록시의 fuse 역할이 실행되는 위치입니다. HTTP 트래픽을 통한 RPC 보안이 손상되지 않으면 소모할 수 있습니다.
  • 웹 팜에서 RPC 프록시를 실행하는 여러 컴퓨터에 액세스 검사 및 암호 해독 작업 중 일부를 배포합니다. RPC 프록시는 웹 팜에서 잘 작동하여 조직에서 SSL 암호 해독 및 일부 액세스 검사를 오프로드할 수 있으므로 백 엔드 서버에서 처리를 위해 더 많은 용량을 확보할 수 있습니다. 또한 RPC 프록시 컴퓨터의 웹 팜을 사용하면 organization 프런트 엔드 서버의 용량을 늘려 DoS(서비스 거부) 공격을 견딜 수 있는 기능을 높일 수 있습니다.

지금까지 제시된 지침 내에서 조직은 여전히 선택할 수 있습니다. 각 organization 사용자 불편, 보안 및 비용 간에 선택 사항과 손상이 있습니다.

  • 기본 인증 또는 Windows 통합 인증을 사용하여 RPC 프록시에 인증합니까? RPC over HTTP는 현재 NTLM만 지원하며 Kerberos를 지원하지 않습니다. 또한 HTTP를 통한 RPC 클라이언트와 HTTP 헤더에 pragma를 통해 를 삽입하는 RPC 프록시 사이에 HTTP 프록시 또는 방화벽이 있는 경우 NTLM 인증이 작동하지 않습니다. 그렇지 않은 경우 조직은 기본 인증과 NTLM 인증 중에서 선택할 수 있습니다. 기본 인증의 장점은 더 빠르고 간단하기 때문에 서비스 거부 공격에 대한 기회를 덜 제공한다는 것입니다. 그러나 NTLM은 더 안전합니다. organization 우선 순위에 따라 기본, NTLM을 선택하거나 사용자가 둘 중에서 선택할 수 있도록 허용할 수 있습니다. 하나만 선택한 경우 RPC 프록시 가상 디렉터리에서 다른 디렉터리를 해제하여 공격 위험을 줄이는 것이 가장 좋습니다.
  • RPC 프록시와 RPC over HTTP 서버 모두에 대해 동일한 자격 증명 집합을 사용하거나 각각에 대해 다른 자격 증명을 사용하나요? 이 결정에 대한 장단점은 사용자의 편의성과 보안 간의 장단점입니다. 여러 자격 증명을 입력하는 것을 좋아하는 사용자는 거의 없습니다. 그러나 신뢰할 수 없는 경계 네트워크에서 보안 위반이 발생하는 경우 RPC 프록시 및 HTTP 서버를 통한 RPC에 대한 별도의 자격 증명 집합이 있으면 추가 보호가 제공됩니다. 별도의 자격 증명이 사용되고 하나의 자격 증명 집합이 사용자의 도메인 자격 증명인 경우 RPC 프록시가 아닌 HTTP 서버를 통해 RPC에 대한 사용자의 도메인 자격 증명을 사용하는 것이 좋습니다.