클라이언트 가장 및 위임

  • 아티클

경우에 따라 서버 애플리케이션은 클라이언트를 대신하여 액세스하는 리소스에 클라이언트의 ID를 제공해야 합니다. 일반적으로 클라이언트의 ID에 대해 액세스 확인 또는 인증이 수행되도록 합니다. 어느 정도 서버는 클라이언트의 ID(클라이언트를 가장하는 작업)에 따라 작동할 수 있습니다.

가장 은 스레드가 스레드를 소유하는 프로세스와 다른 보안 컨텍스트에서 실행할 수 있는 기능입니다. 서버 스레드는 클라이언트의 자격 증명을 나타내는 액세스 토큰을 사용하며, 이를 통해 클라이언트가 액세스할 수 있는 리소스에 액세스할 수 있습니다.

가장을 사용하면 서버가 클라이언트에서 수행할 수 있는 작업을 정확하게 수행할 수 있습니다. 클라이언트가 수행할 수 있는 권한에 따라 리소스에 대한 액세스가 제한되거나 확장될 수 있습니다.

데이터베이스가 클라이언트 자체를 인증하고 권한을 부여할 수 있도록 데이터베이스에 연결할 때 서버가 클라이언트를 가장하도록 선택할 수 있습니다. 또는 애플리케이션이 보안 설명자로 보호되는 파일에 액세스하고 클라이언트가 이러한 파일의 정보에 대한 권한 있는 액세스를 얻을 수 있도록 하는 경우 애플리케이션은 파일에 액세스하기 전에 클라이언트를 가장할 수 있습니다.

가장을 구현하는 방법

가장하려면 클라이언트와 서버(그리고 경우에 따라 시스템 관리자)의 참여가 필요합니다. 클라이언트는 서버가 ID를 사용하도록 허용하려는 의지를 나타내야 하며 서버는 클라이언트의 ID를 프로그래밍 방식으로 명시적으로 가정해야 합니다. 자세한 내용은 가장에 대한 topics 클라이언트 쪽 요구 사항 및 가장에 대한 서버 쪽 요구 사항을 참조하세요.

Delegate-Level 가장에 대한 관리 요구 사항

네트워크를 통해 클라이언트를 가장하는 가장인 가장, 위임의 가장을 효과적으로 사용하려면 다음과 같이 클라이언트 및 서버 사용자 계정을 지원하도록 Active Directory Service에서 클라이언트 및 서버 사용자 계정을 올바르게 구성해야 합니다(위임 수준 가장을 수행할 권한을 부여하는 클라이언트 외에도).

  • 서버 ID는 Active Directory 서비스에서 "위임을 위해 신뢰할 수 있음"으로 표시되어야 합니다.
  • Active Directory 서비스에서 클라이언트 ID를 "계정이 중요하고 위임할 수 없습니다"로 표시해서는 안 됩니다.

이러한 구성 기능은 도메인 관리자에게 위임에 대한 높은 수준의 제어를 제공하며, 이는 신뢰(및 따라서 보안 위험)가 얼마나 관련되어 있는지를 고려할 때 바람직합니다. 위임에 대한 자세한 내용은 위임 및 가장을 참조하세요.

클 로킹

클라이언트가 가장 수준을 통해 서버에 부여하는 권한과 함께 서버의 은폐 기능은 대부분 가장이 작동하는 방식을 결정합니다. 은폐는 서버가 클라이언트를 대신하여 호출할 때 서버에서 실제로 제공하는 ID(자체 또는 클라이언트)에 영향을 줍니다. 자세한 내용은 은폐를 참조하세요.

성능 의미

가장은 성능 및 크기 조정에 크게 영향을 줄 수 있습니다. 일반적으로 직접 호출하는 것보다 호출에서 클라이언트를 가장하는 것이 더 비쌉니다. 다음은 고려해야 할 몇 가지 문제입니다.

  • 특히 동적 은폐를 사용하는 경우 복잡한 패턴으로 ID를 전달하는 계산 오버헤드입니다.
  • 중간 계층에서 중앙에 있는 것이 아니라 여러 위치에서 중복 보안 검사를 적용하는 일반적인 복잡성입니다.
  • 클라이언트를 가장하여 열 때 데이터베이스 연결 같은 리소스는 여러 클라이언트에서 재사용할 수 없습니다. 이는 크기 조정에 매우 큰 장애물입니다.

경우에 따라 문제에 대한 유일한 효과적인 해결 방법은 가장을 사용하는 것이지만 이 결정을 신중하게 고려해야 합니다. 이러한 문제에 대한 자세한 내용은 다중 계층 애플리케이션 보안을 참조하세요.

큐에 대기된 구성 요소

큐에 대기된 구성 요소는 가장을 지원하지 않습니다. 클라이언트가 큐에 대기 중인 개체를 호출하면 실제로 서버로 메시지의 일부로 패키지되는 레코더에 대한 호출이 이루어집니다. 그런 다음 수신기는 큐에서 메시지를 읽고 플레이어에게 전달하여 실제 서버 구성 요소를 호출하고 동일한 메서드를 호출합니다. 따라서 서버가 호출을 받으면 원래 클라이언트 토큰을 가장을 통해 사용할 수 없습니다. 그러나 역할 기반 보안은 여전히 적용되며 ISecurityCallContext 인터페이스를 사용하는 프로그래밍 방식 보안이 작동합니다. 자세한 내용은 대기 중 구성 요소 보안을 참조하세요.

클라이언트 인증

라이브러리 애플리케이션 보안

다중 계층 애플리케이션 보안

프로그래밍 방식 구성 요소 보안

역할 기반 보안 관리

COM+에서 소프트웨어 제한 정책 사용