如何在Windows store应用中安全的使用Azure Blob存储(2)


三. 进一步提高WCF Service的可靠性和安全性

我们已经实现了对Windows Azure上Blob数据的安全存取。但是这还不足以应用到生产环境。在生产环境,我们还需要保证WCF Service的高可靠性。设置服务器的负载均衡是一个很好的解决办法。下面就让我们来介绍一下如何修改WCFServiceWebRole1的设定以实现负载均衡。

1.在Cloud Service项目WindowsAzure1的Roles文件夹中,右键点击WCFServiceWebRole1选择Properties打开属性页。

 

2.在Configuration页面中将Instance count设为2或更多,Windows Azure会该为Cloud Service创建相应数目虚拟机做负载平衡。这样如果其中一台虚拟机出问题的时候其他虚拟机还能继续服务,从而保证了服务的稳定性。

 

另外,第三方还有可能通过抓包的方式来获取身份验证及数据信息,虽然因为我们使用了共享访问签名,可以设置该身份验证信息的有效时间,但还是可能形成隐患。为了避免这种情况,我们需要实现与Windows Azure的https连接。由于客户端和Storage Service的连接已经是https的了,所以这里只需要关心客户端和Cloud Service的连接设置。下面就是设定与Cloud Service的通讯https连接的步骤:

1.为了采用https连接,我们需要一张SSL证书。而在实际生产环境中,您需要使用一张受信任的证书或者公司颁发的证书。出于演示目的,这里我使用了一张自签名的证书,在Developer Command Prompt for VS2013中以管理员身份运行makecert命令可以帮助我们创建一张自签名证书:

C:\>makecert -r -pe -n CN="sasservice.cloudapp.net " -b 03/13/2014 -e 03/13/2015 -eku 1.3.6.1.5.5.7.3.1 -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -sv sasCert.pvk sasCert.cer

2.期间您需要设定并输入私钥的保护口令。生成的证书包含两个文件,一个是pvk文件,用于存储证书私钥,一个是cer文件,用于存储证书公钥。关于如何使用makecert命令的详细信息,您可以参考以下链接:

http://msdn.microsoft.com/zh-cn/library/bfsktky3(v=vs.110).aspx

3.接下来您需要用pvk2pfx命令生成pfx文件以供后用:

C:\>pvk2pfx -pvk sasCert.pvk  -pi “<pvk password>” -spc sasCert.cer -pfx sasCert.pfx -po “<pfx password>”

pfx文件中包含了证书公钥和私钥。-pi参数用来设定前面输入的私钥的保护口令,-po参数用来设定输出的pfx文件的私钥的保护口令。

4.在客户端右键点击sasCert.cer文件,选择Install certificate安装该证书,按照导入向导一步步将证书安装到Local Machine的Personal存储中。

5. 在Windows Azure管理门户进入前面建立的名为sasservice的云服务管理界面,点击Certificates标签页,在该页面中点击Upload弹出上传向导,根据向导将第3步生成的pfx文件上传到服务端。

 

 6.回到在Cloud Service项目WindowsAzure1的Roles文件夹,右键点击WCFServiceWebRole1选择Properties打开属性页,在Certificates标签页中添加证书,Store Location选择Local Machine, Store Name选择My,Thumbprint选择步骤4中已经安装到客户端的sasservice证书。Cloud Service项目需要改Thumprint信息以便能够在服务端找到步骤5中上传的那张带私钥的证书。

 

7.Endpoints标签页中,将EndpointProtocol改为https, Public Port改为443. SSL Certificate Name选择步骤6中添加的证书名Certificate1:

 

8. 打开WCFServiceWebRole1web.config文件,加入以下设置使得WCF服务支持https

<configuration>

 <system.serviceModel>

    <services>

      <service name="WCFServiceWebRole1.Service1">

        <endpoint address=""

                  binding="basicHttpBinding"

                  bindingConfiguration="secureHttpBinding"

                  contract="WCFServiceWebRole1.IService1"/>

        <endpoint address="mex"

                  binding="mexHttpsBinding"

                  contract="IMetadataExchange" />

      </service>

    </services>

    <bindings>

      <basicHttpBinding>

        <binding name="secureHttpBinding">

          <security mode="Transport">

            <transport clientCredentialType="None"/>

          </security>

        </binding>

      </basicHttpBinding>

    </bindings>

    <behaviors>

      <serviceBehaviors>

        <behavior>

         <serviceMetadata httpGetEnabled="false" httpsGetEnabled="true"/>

        </behavior>

      </serviceBehaviors>

    </behaviors>

</configuration>

 9.       WindowsAzure1项目点击Build->Publish将该服务重新发布Windows Azure上,这样Cloud Service就只允许通过https来访问了。

10.   Windows Store应用客户端更新Service Reference,将原来的支持httpService Renference删除,使用以下URL为应用重新添加Service Reference:

https://sasservice.cloudapp.net/Service1.svc

这样Windows Store应用客户端就可以通过https来与Cloud Service进行通讯了。

四.防止加密的https数据被Fiddler截获

理论上,通过https传输的内容是不可能被解密的。但是,我们发现,通过一定的设置以后,像Fiddler这样的网络抓包工具却能够看到https报文的内容。这是怎么回事呢?其实,这是因为Fiddler在数据发送端和接收端横插了一脚,充当了一个代理的角色。它首先在系统中生成了一张证书,然后用这张证书和发送端建立https连接。然后再用接收端的证书建立与接收端的https连接。这样子,它就成功的把数据骗到手里啦。

如果想要解决这个问题的话,我们需要对Windows Store应用的可信任的证书作一个限制,只允许它信任指定的证书,而确实它会信任所有安装在系统中的证书。方法是在Windows store应用的Manifest文件中添加所信任的证书,并且设定为Exclusive trust

 

这里需要添加两张证书,一张是用于和Cloud service通讯的证书,也就是前面生成的sasCert.cer。另一张是用于Storage service通讯的证书,你首先需要找到这张证书的根证书。Windows Azure上的 Storage service用的证书是由Baltimore CyberTrust Root签发的。该证书可以在[Local Computer\Trusted Root Certification Authorities]中找到。这里我们将该证书导出到一个名为BalimoreCyber.cer的文件文件中。

通过以上一系列操作,我们终于将可以在Windows Store应用中安全的使用Windows Azure上的storage service了。由于步骤比较复杂,我这里附上了完整的示例代码以供大家参考,希望能够对大家开发高安全性的Windows Store应用有所帮助。大家如果有什么问题的话,也欢迎与我讨论。

AzureStorageDemo.zip

Comments (0)

Skip to main content