원격 작업의 보안
일반적으로 .NET Framework Remoting을 사용하는 응용 프로그램에는 로컬 응용 프로그램보다 복잡한 보안 문제가 여러 가지 있습니다.
분산 응용 프로그램의 보안에는 성능을 저하시키는 방법에 의존하지 않고는 보안 문제를 해결하기 어렵다는 문제가 있습니다. 통신의 한 쪽 끝에서 호출을 수신하고 있을 경우 수신하는 끝점에 대해 알고 있는 권한이 없는 클라이언트가 통신의 다른 쪽 끝에서 deserialize된 정보를 얻어 호출할 목적으로 serialize된 일부 정보를 전달하려고 할 수도 있습니다. 따라서 신뢰된 구성 요소 간에서 통신이 이루어지게 하는 합리적이고 유일한 방법은 상호 인증한 다음 내용을 암호화하는 것입니다. 결과적으로 원격 응용 프로그램의 보안 요구 사항을 평가한 다음 성능 요구 사항을 평가해야 합니다. 응용 프로그램에 필요한 데이터 무결성의 수준에 따라 인증과 암호화 없이 데이터와 끝점을 노출시켜야 합니다.
원격 대리자는 이 문제를 보여 줍니다. 대리자는 원격으로 실행되지 않는 정적 메서드의 형식 정보를 래핑할 수 있으므로 서버 응용 프로그램에서는 항상 서버 컴퓨터에서 호출할 수 있는 정적 메서드와 일치하지 않는 사용자 지정 매개 변수를 사용하는 사용자 지정 대리자 형식을 선언해야 합니다. 또한 서버에서 deserialize할 수 있는 모든 형식은 클라이언트에서 정의하여 응용 프로그램에 전달하지 못하도록 해야 합니다.
.NET Framework Remoting 인프라를 사용하는 분산 응용 프로그램을 디자인할 때는 필요한 보안 수준과 보안이 필요한 지점을 알고 있어야 합니다. 이 단원에서는 특정 디자인 결정 사항을 기반으로 한 다양한 보안 방법에 대해 설명합니다. 여기에서 다루는 시나리오가 전부인 것은 아니지만 필요한 사항을 결정하는 데는 좋은 참고 자료가 될 것입니다.
코드 액세스 보안
코드 액세스 보안에서는 해당 컴퓨터의 관리자가 설정한 보안 정책을 기반으로 실행 코드에서 리소스 및 작업에 대해 가지는 액세스를 제어합니다. 그러나 코드 액세스 보안에서는 원격 연결 전반에서 스택 워크가 수행되지 않기 때문에 원격 응용 프로그램의 개발자는 원격 인프라를 클라이언트나 서버에서 실행하려면 완전한 신뢰가 필요하다는 점을 확실히 이해해야 합니다. 원격 응용 프로그램을 무단으로 사용할 수 있으면 FullTrust 사용 권한에 무단으로 액세스할 수 있습니다.
경고
AppDomain 개체에 대해 원격화할 수 있는 래퍼를 만들려고 해서는 안 됩니다. 이런 래퍼를 만들면 해당 AppDomain에 대한 참조를 원격으로 게시할 수 있게 되며, 이 경우 AppDomain.CreateInstance 메서드나 다른 메서드를 원격으로 노출하게 되므로 해당 AppDomain에 대한 코드 액세스 보안이 크게 손상됩니다. 권한이 없는 클라이언트가 원격화된 AppDomain에 연결하여 AppDomain이 액세스할 수 있는 모든 리소스에 대한 액세스 권한을 얻을 수 있기 때문입니다. 사실 MarshalByRefObject를 확장하며 권한이 없는 클라이언트가 보안 시스템을 우회하는 데 사용될 수 있는 메서드를 구현하는 모든 형식에 대해 이런 원격화할 수 있는 래퍼를 만들어서는 안 됩니다.
참고
더욱 일반적으로 일부 시스템 형식은 MarshalByRefObject를 확장하기는 하지만 응용 프로그램 도메인 외부에서 MarshalByRefObject 형식의 개체를 원격으로 호출하는 것을 막기 위해 런타임에 보안 검사를 수행합니다. AppDomain과 System.Windows.Forms.Form은 이러한 시스템 형식의 두 가지 예입니다. 이러한 특수 형식을 제외한 모든 형식은 MarshalByRefObject를 확장하고 원격으로 참조를 얻을 수 있다고 생각할 수 있습니다. in-process 참조를 원격화할 수 있는 다른 형식으로 래핑하는 것이 편하다고 생각될 수도 있지만 이렇게 하면 코드 액세스 보안이 손상되므로 절대로 이렇게 하지 마십시오.
원격 응용 프로그램의 보안 고려 사항
일반적으로 분산 응용 프로그램에서 다뤄야 하는 보안 영역은 사용자의 시나리오에 따라 두 가지가 있습니다. 통신 채널과 메시지 자체의 보안을 유지하거나 응용 프로그램을 부적절하게 사용하지 못하도록 보안을 유지할 수 있습니다. 또한 이 둘 모두를 일정 수준으로 처리할 수도 있습니다.
일반적으로 통신 채널의 보안을 유지하려면 채널 자체를 암호화하거나, 스트림의 한 쪽에서 메시지 내용을 암호화하고 스트림의 다른 쪽에서 이를 해독하거나, 이 두 방법을 모두 사용해야 합니다. 메시지의 내용은 다른 사용자가 훼손하지 않았다는 것을 확인하기 위해 무결성 검사가 필요할 수 있으며, 클라이언트나 서버, 또는 이 둘 모두의 ID를 확인해야 할 수도 있습니다.
항상 클라이언트를 인증하여 리소스를 사용할 권한이 있는지 확인해야 합니다. 그런 다음 모든 통신을 암호화하여 전송 중에 데이터를 보호해야 합니다. HttpChannel 및 TcpChannel 모두 이 두 단계를 완전하게 지원합니다. IPC 채널은 같은 컴퓨터에서만 작동하기 때문에 암호화를 지원하지 않는 대신 Windows 인증을 지원합니다.
일부 시나리오는 위 두 규칙에 대한 예외입니다. 성능 요구 사항이 중요하고 상대적으로 데이터 감시나 처리가 중요하지 않을 정도로 데이터 가치가 낮은 경우에는 암호화를 제거할 수 있습니다. IPsec으로 보안이 유지되는 경우처럼 통신이 암호화된 네트워크에서 발생하는 경우에도 암호화를 사용하지 않을 수 있습니다.
사용자의 동작을 기록하고 그에 따라 사용 패턴을 재구성하여 응용 프로그램을 무단 사용으로부터 보호할 수도 있습니다.
경고
.NET Framework Remoting에서는 기본적으로 인증이나 암호화 작업을 수행하지 않습니다. 따라서 원격으로 클라이언트나 서버와 상호 작용하기 전에 클라이언트나 서버의 ID를 확인하는 데 필요한 모든 단계를 수행하는 것이 좋습니다. .NET Framework Remoting 응용 프로그램을 실행하려면 FullTrust 권한이 필요하므로 권한이 없는 클라이언트에게 서버에 대한 액세스 권한을 부여하면 해당 클라이언트는 완전히 신뢰된 것처럼 코드를 실행할 수 있습니다. 항상 끝점을 인증하고 통신 스트림을 암호화합니다. 이러한 작업은 IIS(인터넷 정보 서비스)에서 원격화된 형식을 호스팅하거나 사용자 지정 채널 싱크 쌍을 만들어서 수행할 수 있습니다. .NET Framework 버전 2.0에서는 더 이상 통신 보안을 위해 사용자 지정 싱크를 빌드할 필요가 없습니다. TCP 채널에서 secure = true를 설정하여 활성화되는 인증 및 보안 기능을 사용하여 보안 통신을 사용할 수 있습니다. 이제 TCP 채널을 사용하여 연결 사용자를 인증하고 전송되는 데이터를 암호화하며 연결 클라이언트의 ID와 IP 주소를 확인할 수 있습니다.
참고 항목
참조
RemotingConfiguration
ChannelServices
Context
MethodCall
RemotingServices