【问题标题】:SQL Server Service Broker -- Communicating Between Non-Domain Servers Over a VPNSQL Server Service Broker -- 通过 VPN 在非域服务器之间进行通信
【发布时间】:2010-02-16 16:03:16
【问题描述】:

如果两个 SQL Server 2008 实例都不在域中,是否有任何好的选择可以通过 Service Broker 连接,但我们可以完全控制登录名和凭据?

我们正在考虑将这项技术用于企业级数据整合,但我们的服务器在客户端站点上运行,并且未配置为任何域的成员。我们正在寻找让 Service Broker 在这种环境中进行通信的最轻松的选择。

【问题讨论】:

    标签: sql-server sql-server-2008 dns service-broker


    【解决方案1】:

    您使用证书,这是专门为像您这样的场景设计的 Service Broker 身份验证选项。见How does Certificate based Authentication work。当端点配置了基于证书的身份验证时,握手将包含基于 SSPI Schannel 的身份验证交换(通常称为 SSL 或 TLS)。对等方使用的生成证书用于根据从证书部署派生的信任来授权连接。这意味着所使用的证书未针对特定属性进行验证,例如在“https://example.com”的情况下,“example.com”必须在证书上使用特定的 OID 和受信任的权威签名,但如果证书是已部署(即在主数据库中找到),则已部署证书的所有者就是身份。这允许您以安全的方式使用自签名证书和部署中的信任根(即系统管理员),而不是权威(即威瑞信)。这可能比您需要的信息更多:)

    它的要点是这样的:

    -------------------------------------
    -- connect to server
    -------------------------------------
    use master;
    go
    create master key encryption by password = '...';
    create certificate [<servername>]
      with subject = '<servername>'
      , start_date = '20100216'
      , expiry_date = '20150216';
    
    create endpoint broker 
    state = started
    as tcp (listener_port = 4022)
    for service_broker (authentication = certificate [<servername>]);
    
    -- Export the public key to disk
    backup certificate [<servername>]
    to file = '\\someshare\<servername>.cer';
    
    --------------------------------
    -- connect to client
    --------------------------------
    use master;
    go
    create master key encryption by password = '...';
    create certificate [<clientname>]
      with subject = '<clientname>'
      , start_date = '20100216'
      , expiry_date = '20150216';
    
    create endpoint broker 
    state = started
    as tcp (listener_port = 4022)
    for service_broker (authentication = certificate [<clientname>]);
    
    -- Export the public key to disk
    backup certificate [<clientname>]
    to file = '\\someshare\<clientname>.cer';
    
    --create an identity for server and import the server's certificate:
    create login [<servername>] with password = '...';
    alter login [<servername>] disable;
    create user [<servername>];
    
    create certificate [<servername>]
      authorization [<servername>]
      from file = '\\someshare\<servername>.cer';
    
    --authorize <servername> to connect on the broker endpoint 
    grant connect on endpoint::broker to [<servername>];
    
    ---------------------------------------
    -- connect to the server
    ---------------------------------------
    
    --create an identity for client and import the client's certificate:
    create login [<clientname>] with password = '...';
    alter login [<clientname>] disable;
    create user [<clientname>];
    
    create certificate [<clientname>]
      authorization [<clientname>]
      from file = '\\someshare\<clientname>.cer';
    
    --authorize <clientname> to connect on the broker endpoint 
    grant connect on endpoint::broker to [<clientname>];
    

    【讨论】:

    • 在您的示例中,是否可以在同一实例上的其他数据库中拥有用户、服务和服务绑定?需要有一个 db-local 用户来“授权发送”,对吗?
    • @JSacksteder 传输/端点安全性处于实例/端点级别。您说的是dialog security,它确实处于数据库/服务级别。
    • 我不确定两者之间的关系。我是否需要将主数据库中用于端点安全的相同证书应用到应用程序数据库中以实现对话安全,但使用不同的用户?
    • 两者是正交的。端点安全性允许两个 SQL Server 实例相互连接,并且是强制性的。仅当您想在服务级别识别哪个服务向您发送了消息时,才需要对话安全性。如果您不需要在 BEGIN DIALOG 上指定 WITH ENCRYPTION OFF 并在目标服务上将 send 授予 public 角色。如果您确实需要对话框安全性,请阅读链接文章。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-08-07
    • 2021-07-12
    • 2011-01-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多