다음을 통해 공유


보안 QOS 옵션 선택

보안 QOS 옵션은 RpcBindingSetAuthInfoEx 함수에 지정된 SecurityQOS 매개 변수의 일부로 전달됩니다. 다음 모범 사례를 사용합니다.

상호 인증 사용

진정한 상호 인증은 협상(Kerberos 협상 시), Kerberos 및 Schannel과 같은 특정 보안 공급자에만 사용할 수 있습니다. NTLM은 상호 인증을 지원하지 않습니다. 상호 인증을 사용하려면 올바른 형식의 서버 보안 주체 이름을 제공해야 합니다. 많은 개발자가 다음과 같은 잘못된 보안 사례를 사용합니다. 서버는 주 이름(RpcMgmtInqServerPrincName)을 요청하기 위해 호출된 다음, 해당 주체 이름을 사용하여 상호 인증을 맹목적으로 요청합니다. 이 방법은 상호 인증에 대한 전체적인 개념을 깨뜨립니다. 상호 인증의 개념은 특정 서버만 데이터를 구문 분석하고 처리하기 위해 신뢰할 수 있기 때문에 호출된다는 것입니다. 방금 설명한 잘못된 보안 사례를 사용하여 개발자는 자신의 이름을 반환할 수 있을 만큼 똑똑한 사람에게 데이터를 제공합니다.

예를 들어 클라이언트 소프트웨어가 Joe, Pete 또는 Alice의 계정에서 실행되는 서버만 호출해야 하는 경우 RpcMgmtInqServerPrincName 함수를 호출해야 하며 다시 전송된 이름을 확인해야 합니다. Joe, Pete 또는 Alice인 경우 서버 보안 주체 이름을 사용하여 상호 인증을 요청해야 합니다. 이렇게 하면 대화의 절반 모두 동일한 보안 주체로 이동합니다.

클라이언트 소프트웨어가 Joe의 계정으로만 실행되는 서비스를 호출해야 하는 경우 Joe의 서버 보안 주체 이름을 직접 작성하고 호출합니다. 서버가 Joe가 아니면 호출이 실패합니다.

서비스는 여러 번 Windows 시스템 서비스로 실행되므로 컴퓨터 계정으로 실행됩니다. 상호 인증 및 서버 보안 주체 이름 만들기는 여전히 권장됩니다.

호출을 통과하도록 허용하는 가장 낮은 ImpersonationType 사용

이 모범 사례는 상당히 자명합니다. 상호 인증을 사용하는 경우에도 서버에 필요한 것보다 더 많은 권한을 부여하지 마세요. 합법적인 서버가 손상되었을 수 있으며, 이러한 경우 보내는 데이터가 잘못된 손에 넘어가더라도 적어도 서버는 사용자를 대신하여 네트워크의 다른 데이터에 액세스할 수 없습니다. 일부 서버는 호출자를 확인하고 가장할 수 있는 충분한 정보가 없는 호출을 거부합니다. 또한 일부 프로토콜 시퀀스는 전송 수준 보안(ncacn_npncalrpc)을 지원합니다. 이러한 경우 바인딩 핸들을 만들 때 NetworkOptions 매개 변수를 통해 충분히 높은 가장 수준을 지정하는 경우 서버는 항상 사용자를 가장할 수 있습니다.

마지막으로 일부 보안 공급자 또는 전송은 ImpersonationType을 지정된 수준보다 더 높은 수준으로 투명하게 범프할 수 있습니다. 프로그램을 개발할 때는 의도한 ImpersonationType을 사용하여 호출을 시도하고 서버에서 ImpersonationType이 더 높은지 여부를 검사.