Share via

Service Broker 대화 보안

  • 아티클

적용 대상:SQL ServerAzure SQL Managed Instance

대화 보안은 특정 대화에 대한 암호화, 원격 인증 및 원격 권한 부여를 제공합니다. 대화에서 대화 보안을 사용하는 경우 Service Broker는 SQL Server 인스턴스 외부에서 보낸 모든 메시지를 암호화합니다. Service Broker 대화는 기본적으로 대화 보안을 사용합니다.

대화 보안 기본 사항

Service Broker 대화 보안을 사용하면 애플리케이션이 개별 대화에 대한 인증, 권한 부여 또는 암호화를 사용할 수 있습니다. 모든 대화는 기본적으로 대화 보안을 사용합니다. 대화를 시작할 때 BEGIN DIALOG CONVERSATION 문에 ENCRYPTION = OFF 절을 포함하여 대화 보안 없이 대화가 계속 진행되도록 명시적으로 허용할 수 있습니다. 그러나 대화가 대상으로 하는 서비스에 대한 원격 서비스 바인딩이 있는 경우 ENCRYPTION = OFF인 경우에도 대화에서 보안을 사용합니다.

보안을 사용하는 대화의 경우 Service Broker는 SQL Server 인스턴스 외부에서 보낸 모든 메시지를 암호화합니다. SQL Server 인스턴스 내에 남아 있는 메시지는 암호화되지 않습니다. 대화 보안에서 시작 서비스를 호스트하는 데이터베이스와 대상 서비스를 호스트하는 데이터베이스만 보안에 사용되는 인증서에 액세스할 수 있어야 합니다. 즉, 메시지 전달을 수행하는 인스턴스는 인스턴스가 전달하는 메시지 암호를 해독할 수 있는 기능이 없어도 됩니다.

Service Broker는 높은 수준의 보안과 익명 보안의 두 가지 대화 보안 유형을 제공합니다. 대화 보안을 사용하는 대화의 경우 Service Broker는 대화의 원격 측을 로컬 사용자에 매핑할 수 있는 원격 권한 부여를 제공합니다.

대화에서 전체 보안 또는 익명 보안을 사용하는 경우 메시지는 네트워크에서 암호화됩니다. 그러나 대상 데이터베이스의 유효 권한과 메시지 암호화에 사용되는 전략은 두 가지 보안 방식에 따라 약간 다릅니다.

대화에서 전체 보안 또는 익명 보안을 사용하는지 여부에 관계없이 메시지 본문은 특정 대화에 대해 생성된 대칭 세션 키로 암호화됩니다. 대화 보안에 제공된 인증서를 사용하여 프라이빗 키 암호화로 키만 암호화됩니다. 또한 Service Broker는 메시지 손상 또는 변조를 감지하는 데 도움이 되는 메시지 무결성 검사를 수행합니다.

SQL Server는 대화 보안을 사용하는 대화에 대한 세션 키를 만듭니다. 세션 키가 데이터베이스에 저장되는 동안 세션 키를 보호하기 위해 Service Broker는 데이터베이스의 마스터 키를 사용하여 세션 키를 암호화합니다. 데이터베이스 마스터 키를 사용할 수 없는 경우 데이터베이스 마스터 키가 생성되거나 대화 시간이 초과될 때까지 대화에 대한 메시지가 오류와 함께 transmission_status에 남아 있습니다. 따라서 데이터베이스가 동일한 인스턴스에서 호스트되는 경우에도 대화에 참여하는 두 데이터베이스 모두 마스터 키를 포함해야 합니다. 시작 데이터베이스에 마스터 키가 없으면 대화가 실패합니다. 대상 데이터베이스에 마스터 키가 없는 경우 시작 데이터베이스의 전송 큐에 메시지가 남습니다. 이러한 메시지에 대한 마지막 전송 오류는 메시지를 배달할 수 없는 이유를 나타냅니다. ENCRYPTION = OFF 매개 변수를 사용하여 암호화되지 않은 대화를 만들거나 다음 명령을 사용하여 데이터베이스 마스터 키를 만듭니다.

    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>'

편의상 Service Broker는 데이터베이스에 마스터 키가 있는지와 관계없이 단일 데이터베이스 내에 남아 있는 보안 대화를 진행할 수 있도록 합니다. 대화의 수명 동안 서로 다른 두 데이터베이스를 서로 다른 SQL Server 인스턴스로 옮길 수 있지만 단일 데이터베이스 내의 대화는 항상 해당 데이터베이스 내에 남습니다. 그렇기 때문에 대화가 계속 진행됩니다.

전체 보안

높은 수준의 보안은 시작 서비스에서 트러스트되지 않은 데이터베이스로 메시지를 보내지 못하도록 하며 대상 서비스가 트러스트되지 않은 데이터베이스로부터 메시지를 수신하지 않도록 합니다. Service Broker는 대화에서 전체 보안을 사용하는 경우 네트워크를 통해 전송되는 메시지를 암호화합니다.

전체 보안은 시작 서비스와 대상 서비스 모두에 대한 ID를 제공합니다. 전체 보안을 사용하려면 시작 서비스가 대상 서비스를 신뢰해야 하며 대상 서비스에서 시작 서비스를 신뢰해야 합니다. 예를 들어 공급업체에서 부품을 주문하는 서비스는 주문 애플리케이션이 공급업체 서비스와 공급업체 서비스를 신뢰하여 주문 애플리케이션을 신뢰하도록 요구할 수 있습니다.

데이터베이스 관리자는 공개 키가 포함된 인증서를 교환하여 신뢰를 설정합니다. 전체 대화 보안을 위해 대화의 양측에는 로컬 사용자의 프라이빗 키와 원격 사용자에 대한 공개 키가 포함됩니다. 시작 서비스를 호스트하는 데이터베이스에는 원격 서비스 바인딩이 포함되어 있습니다. 이 원격 서비스 바인딩은 원격 데이터베이스의 프라이빗 키에 해당하는 인증서를 소유하는 로컬 사용자를 지정합니다. 따라서 시작 서비스를 대신하여 수행되는 작업은 대상 데이터베이스에서 지정된 사용자로 실행됩니다.

대상 데이터베이스에는 사용자가 포함됩니다. 이 사용자는 시작 서비스를 소유한 사용자가 소유한 프라이빗 키에 해당하는 인증서를 소유합니다. 따라서 대상 서비스를 대신하는 작업은 시작 서비스를 소유한 사용자로 시작 데이터베이스에서 실행됩니다.

전체 보안을 사용하는 대화의 경우 대화의 양측에서 세션 키를 생성합니다. 각 방향의 첫 번째 메시지에는 인증서 및 Service Broker에 설명된 대로 키 교환 키로 암호화된 세션 키가 있습니다.

익명 보안

익명 보안은 신뢰할 수 없는 데이터베이스에 메시지를 보내지 못하도록 시작 서비스를 보호하는 데 도움이 됩니다. Service Broker는 대화에서 익명 보안을 사용할 때 네트워크를 통해 전송되는 메시지를 암호화합니다.

익명 보안은 시작 서비스에 대한 대상 서비스를 식별하지만 대상 서비스에 대한 시작 서비스를 식별하지는 않습니다.

예를 들어 작업 주문을 제출하는 애플리케이션은 작업 주문의 받는 사람이 의도한 대상임을 보장해야 할 수도 있지만 대상 데이터베이스는 작업 주문을 제출하는 서비스에 대해 특별한 권한을 제공할 필요가 없습니다. 이 경우 시작 서비스를 포함하는 데이터베이스에는 대상 서비스에 대한 원격 서비스 바인딩이 포함되어야 합니다.

대상 서비스는 시작 서비스의 ID를 확인할 수 없으므로 시작 서비스를 대신하여 수행되는 작업은 대상 데이터베이스에서 고정 데이터베이스 역할 public의 멤버로 실행됩니다. 대상 데이터베이스는 대화를 시작한 사용자에 대한 정보를 수신하지 않습니다. 대상 데이터베이스는 대화를 시작하는 사용자에 대한 인증서를 포함할 필요가 없습니다.

익명 보안을 사용하는 대화의 경우 대화의 양측 모두 시작 데이터베이스에서 생성된 세션 키를 사용합니다. 대상 데이터베이스는 시작 데이터베이스에 세션 키를 반환하지 않습니다.

대화 보안에 대한 보안 컨텍스트

Service Broker 원격 권한 부여는 개별 서비스에 대한 원격 액세스를 제어합니다. 원격 권한 부여는 SQL Server 인스턴스에 들어오는 메시지가 서비스로 전달되는 보안 컨텍스트를 결정합니다.

Service Broker는 전적으로 SQL Server 인스턴스 내에서 실행되지 않는 보안 대화에 대해 항상 원격 권한 부여를 사용합니다. 대화에 대해 구성된 대화 보안에 따라 Service Broker가 원격 권한 부여에 사용하는 보안 컨텍스트가 결정됩니다.

Service Broker는 대화가 SQL Server 인스턴스 내에 남아 있을 때 원격 권한 부여가 구성되었더라도 원격 권한 부여를 사용하지 않습니다. 인스턴스 내 대화의 경우 SQL Server 보안 주체가 이미 SQL Server에 대해 사용 가능한 상태이므로 원격 권한 부여를 사용하여 Service Broker 작업의 올바른 보안 컨텍스트를 결정할 필요가 없습니다. 그러나 이 항목의 앞부분에서 설명한 바와 같이 Service Broker는 대화 도중 데이터베이스 중 하나가 다른 인스턴스로 이동되더라도 대화가 진행될 수 있도록 세션 키를 만듭니다.

익명 보안을 사용하는 대화의 경우 대상 데이터베이스에서 고정 데이터베이스 역할 public의 멤버로 연결이 실행됩니다. 이 경우 고정 데이터베이스 역할 public에는 서비스에 메시지를 보낼 수 있는 권한이 있어야 합니다. 그러나 역할은 데이터베이스에서 다른 권한이 필요하지 않습니다.

전체 보안을 사용하는 대화의 경우 대화의 양측에 있는 연결은 원격 서비스 바인딩에 지정된 사용자의 권한으로 작동합니다. 예를 들어 원격 서비스 바인딩이 서비스 이름 InventoryService를 InventoryServiceRemoteUser 사용자와 연결하면 SQL Server는 InventoryServiceRemoteUser에 대한 보안 컨텍스트를 사용하여 InventoryService 애플리케이션에 대한 메시지를 대상 서비스의 큐에 넣습니다.

더욱 강력한 보안을 확보하려면 서비스에 대한 프라이빗 키를 소유하는 사용자는 일반적으로 활성화를 위해 지정된 사용자와 달라야 합니다. 개인 키를 소유한 사용자는 큐에 메시지를 추가할 수 있는 권한, 즉 큐를 사용하는 서비스에 대한 SEND 권한만 필요합니다. 반면, 활성화를 위해 지정된 사용자에게는 요청된 작업을 수행하고 응답을 보내는 데 필요한 권한이 있습니다. 위 예에서 InventoryServiceRemoteUser는 재고 테이블을 쿼리하거나 반환 메시지를 보낼 수 있는 권한이 필요하지 않습니다. 이 사용자는 InventoryService가 사용하는 큐에 메시지를 보낼 수 있는 권한만 필요합니다. 저장 프로시저 활성화는 큐에서 지정하는 자격 증명을 사용해 다른 세션에서 발생합니다. 메시지를 큐에 추가하는 세션과 메시지를 처리하는 세션 간에 자격 증명을 공유할 필요는 없습니다.

보안 대화 만들기

Service Broker에서 두 데이터베이스 사이의 대화를 설정하는 경우 시작 서비스는 대상 큐에 메시지를 추가할 수 있도록 대상 데이터베이스에 사용자 컨텍스트를 설정해야 합니다. 이 사용자 컨텍스트는 시작 서비스에 대상에 대한 대화를 열 수 있는 권한이 있는지 여부를 결정합니다.

이 작업을 수행하는 가장 유연한 방법은 인증서 및 원격 서비스 바인딩을 만드는 것입니다. 인증서를 만드는 방법은 CREATE CERTIFICATE(Transact-SQL)를 참조하세요. 원격 서비스 바인딩을 만드는 방법에 대한 자세한 내용은 CREATE REMOTE SERVICE BINDING(Transact-SQL)을 참조하세요.

참고 항목

보안 컨텍스트를 제대로 설정하지 않으면 대화를 통해 전송된 메시지가 시작 서비스의 sys.transmission_queue에 머무르게 되며 transmission_status 열에 The server principal '%.*ls' is not able to access the database '%.*ls' under the current security context.라는 오류 메시지가 표시됩니다.

참고 항목