대화 보안 인증서

대화가 시작되면 Service Broker는 원격 서비스 바인딩을 사용하여 대화에 사용할 인증서를 찾습니다. 이 항목에서는 Service Broker가 대화에 사용할 인증서를 결정하는 방법에 대해 설명합니다.

대화에 대한 인증서 찾기

Service Broker는 먼저 대화에 대한 원격 서비스 바인딩을 찾은 다음 바인딩에 지정된 사용자가 소유한 인증서를 선택합니다.

바인딩을 찾기 위해 Service Broker는 대화에 대한 대상 서비스 이름을 지정하는 데이터베이스의 바인딩을 확인합니다.

인증서를 선택하기 위해 Service Broker는 원격 서비스 바인딩에 지정된 사용자가 소유하고 만료 날짜가 최신인 인증서를 찾습니다. Service Broker는 아직 유효하지 않거나, 만료되었거나, 대화 시작에 사용할 수 있도록 표시되지 않은 인증서를 고려하지 않습니다. 인증서에 대한 자세한 내용은 CREATE CERTIFICATE(Transact-SQL)를 참조하십시오.

원격 서비스 바인딩이 없거나 원격 서비스 바인딩에 대한 사용자가 대화 시작에 사용할 수 있는 유효한 인증서를 소유하지 않는 경우 Service Broker는 변환을 위해 메시지를 암호화할 수 없습니다. 바인딩이 없고 데이터베이스에 Broker Configuration 서비스가 포함되어 있으면 Service Broker는 해당 서비스를 통해 바인딩을 요청합니다. 데이터베이스에 Broker Configuration 서비스가 없거나 Broker Configuration 서비스가 원격 서비스 바인딩을 제공하지 않는 경우 암호화가 ON으로 설정되어 있으면 대화가 지연되고, 암호화가 OFF로 설정되어 있으면 대화가 암호화 없이 계속됩니다. 자세한 내용은 대화 보안 유형 결정을 참조하십시오.

원격 권한 부여 및 대화 보안

Service Broker 대화 보안에는 원격 권한 부여에 대한 인증서가 사용됩니다. 대화에 대화 보안이 사용되면 대화의 각 참가자가 보낸 첫 번째 메시지에 보내는 사용자의 개인 키로 암호화된 헤더 정보와 받는 사용자의 공개 키로 암호화된 헤더 정보가 포함됩니다. 메시지 내용은 세션 키로 암호화됩니다. 세션 키 자체가 암호화되므로 받는 사용자에 대한 개인 키를 사용해야만 복구할 수 있습니다.

메시지를 받는 사람이 메시지 암호를 성공적으로 해독할 수 있다면 받는 사람이 해당 키를 소유하고 있다는 의미이므로 대화의 각 참가자 ID를 확인할 수 있습니다. 인증서를 데이터베이스에 설치하면 개인 키를 보유한 데이터베이스와의 트러스트 관계가 만들어집니다.

실제로 로컬 사용자에 대한 개인 키로 헤더를 암호화하면 "원격 데이터베이스가 로컬 데이터베이스를 트러스트합니까?"라는 의문이 제기됩니다. 원격 데이터베이스는 데이터베이스에 해당 공개 키가 있는 경우에만 헤더의 암호를 해독할 수 있습니다. 원격 데이터베이스의 사용자에 대한 공개 키로 헤더를 암호화하면 "로컬 데이터베이스가 원격 데이터베이스를 트러스트합니까?"라는 의문이 제기됩니다. 원격 데이터베이스는 데이터베이스에 해당 개인 키가 있는 경우에만 헤더의 암호를 해독할 수 있습니다. 보안과 효율성을 위해 Service Broker는 이 두 가지 질문을 동시에 합니다. 그러나 메시지는 받는 사람이 이 두 질문을 모두 확인하여 메시지에 올바르게 응답할 수 있도록 구성됩니다.

이 전략의 바탕이 되는 원리는 간단합니다. 원격 데이터베이스가 로컬 데이터베이스의 개인 키로 암호화된 헤더의 암호를 해독할 수 있는 경우 원격 데이터베이스에는 해당 공개 키가 포함되어 있으며 원격 데이터베이스는 로컬 데이터베이스를 트러스트합니다. 원격 데이터베이스가 로컬 데이터베이스의 공개 키로 암호화된 헤더의 암호를 해독할 수 있는 경우 원격 데이터베이스에는 해당 개인 키가 포함되어 있으며 로컬 데이터베이스는 원격 데이터베이스를 트러스트합니다. 개인 키가 비밀로 유지된다면 대화에 포함된 두 데이터베이스만 대화에 대한 메시지를 성공적으로 주고받을 수 있습니다.

[!참고]

신뢰할 수 있는 출처에서 제공하는 인증서만 설치하십시오. 개인 키를 배포하지 마십시오.

전체 대화 보안은 메시지를 처음 주고받는 동안 양쪽 방향에서 ID를 확인합니다. 익명 대화 보안을 사용하는 대화의 경우 시작자는 대상 데이터베이스에 필요한 개인 키가 있는지 확인합니다. 그러나 익명 대화 보안을 사용하는 경우 대상 데이터베이스는 시작자의 ID를 확인하지 않습니다. 대신 대상 서비스를 호스팅하는 데이터베이스는 public 고정 데이터베이스 역할을 통해 서비스에 메시지를 보낼 수 있도록 허용해야 합니다.

로컬 데이터베이스가 확인할 원격 데이터베이스의 ID를 검토하기 전에 메시지를 양방향으로 교환해야 합니다. 로컬 데이터베이스에 원격 데이터베이스의 인증서에 대한 올바른 공개 키가 있는 경우에만 확인이 수행될 수 있습니다.

대화의 양측에서 각각 보낸 첫 번째 메시지에 대해 Service Broker는 다음과 같은 헤더를 포함합니다.

  • 메시지에 사용된 인증서 관련 정보가 포함된 서비스 쌍 보안 헤더 - 서비스 쌍 보안 헤더는 서비스를 소유한 사용자에 대한 개인 키로 서명됩니다.

  • 메시지 본문을 암호화하기 위해 사용된 128비트 세션 키를 암호화하는 키 교환 키 - 키 교환 키는 원격 사용자에 대한 공개 키로 암호화됩니다.

익명 보안을 사용하는 대화의 경우 서비스 쌍 보안 헤더가 암호화되지 않은 상태로 유지됩니다. 메시지 자체는 그대로 암호화되고 키 교환 키는 대상 데이터베이스의 보안 주체에 대한 공개 키로 암호화됩니다. 이 경우 첫 번째 반환 메시지에는 키 교환 키, 서비스 쌍 보안 헤더 또는 암호화된 세션 키가 포함되지 않습니다.

Service Broker가 들어오는 메시지(예: 오류 또는 승인)에 대한 응답으로 메시지를 직접 생성하면 대화에 높은 수준의 보안이 사용되든 익명 보안이 사용되든 관계없이 해당 메시지에는 들어오는 메시지의 세션 키가 사용됩니다.