加密方法过多导致安全通信变得困难

金融公司正在寻求把他们的安全基础设施扩展到他们的业务合作伙伴、服务提供者和客户中去。他们为了实现这种扩展而使用的主要技术之一是加密技术。不管公司是担心敏感信息在因特网上传送时有被截获的可能，还是要考虑必须遵从那些要求保护个人识别信息（PII）或者其他机密数据的规则，唯一的保护数据不被窥探的方法就是让信息不可读，当然除了授权的单位可以读之外。但是当公司开始涉及为了保护通信而进行的加密服务时，他们会面临更多的、预想不到的部署问题。

　　为了理解加密技术怎么工作的，你必须清楚一个加密服务是由三个部分组成的：进行加密的系统，对信息进行加密的加密标准，加密标准用来解码信息的密钥。为了成功的加密/解密信息，这些部分的三个层面在发送方和接受方之间必须相辅相成。

　　***个部分——加密系统，可以有以下三种类型：

• 应用程序—比如，电子邮件客户端，插件和本机加密模块。
• 基础设施服务—比如，信息边界设备、门户网站、网络服务通信，保护FTP服务器安全。
• 保护通信安全—比如，TLS/SSL和会话发起协议（SIP）

　　问题是，这些加密系统不一定能相互兼容。如果一个公司的雇员加密了一个包含PII信息的文档，并把它发送到了公司的业务合作伙伴，那么接收人将会发现：如果没有跟原来的加密系统配对的解密系统，文档是不可读的。

　　发送方和接收方不仅仅要有相辅相成的加密系统，接收方还必须能够支持发送方系统所采用的加密标准。有多种加密标准，包括：公共密钥基础（X.509），加密的HTML，基于身份的加密（IBE），安全/多用途互联网邮件扩展S/MIME，会话发起协议SIP，可扩展的消息处理和现场协议（XMPP），OpenPGP 和 TLS等。一些应用程序和设备可能不支持某种加密标准。举个例子，黑莓手机可能无法轻松地破译桌面应用程序加密的文件，只是因为黑莓平台不支持相应的加密标准。

　　***，如果上面的问题还不够复杂的话，为了成功的加密/ 解密通信内容，接收方必须要得到一个密钥或者密码来解码加密的信息。接受方还必须清楚加密密钥是对称的还是不对称的。某些情况下，比如传输层加密，这个信息对最终用户是隐藏的；但是从应用程序或者一个电子邮件系统中开始的加密来说，为了接受方能够访问信息，密钥必须提前导出或者取得。不管是哪种情况，密钥管理和密钥的分发都可能会花费很大的精力，尤其是当公司拥有大量的合作伙伴或者客户的时候。需要特别指出的是，用户访问安全信息会很麻烦，因为用户一般都会被限制访问公司资源，但是获得密钥必须简单，以缓解售后服务带来的压力。

　　同任何一个企业范围内的服务一样，公司必须认真规划和设计在跟业务合作伙伴和客户的通信中怎样使用加密技术。这通常包括建立一个技术体系结构，建立发送敏感信息的新过程，为了让接受方共享怎样解密信息而建立新的跟外面连接的通信渠道等。有些情况下，还必须为发送方和接受方建立培训项目，培训他们怎样成功的利用加密技术相互通信。

　　企业必须了解他们希望与之进行通信的用户的能力，以及是否为用户管理和运行这些服务。另外，对于那些有大量用户的外部实体，为了用户的应用程序能都得到必要的、用来解密信息的密钥，一般都需要一个很方便的注册过程。

　　由于管理安全通信的复杂性，许多金融公司决定只在其因特网的门户网站和网络应用程序中保留安全内容。然后，他们引导业务合作伙伴和用户去访问这些网站，在那里他们授权这些人并让这些人有权访问公司的敏感信息。这样做可以把加密体系机构限制在公司范围之内，进行更有力的保护控制。虽然这样的短期“拉拢”加密服务不需要给众多的远程用户单独设置加密服务，但是实施这种方案的成本，还有用户培训、支持和维护来管理这些服务的成本已经可以让很多公司的预算吃紧。但是直到组成加密服务的这三个部分的通用标准完善之前——或者至少减少一些选择之前——这可能是最可行的方案。

　　另一方面，保险行业通过代理商技术委员会（ACT）——美国独立保险代理人和经纪人机构的一部分，在2006年的一个报告（“电子通信运营商独立代理特惠制”）中对安全通信事宜做了规定。报告中指出，代理人可以指定他们想怎样从运营商接收安全通信。他们普遍认为，他们希望通过一个带有安全TLS/SSL 链接的电子邮件通知得到用户PII信息，而这个TLS/SSL链接可以让他们连接到包含这些信息门户的运营商网站。

　　虽然这个报告只针对了一个群体，但是保险公司确实开始在推动发送敏感信息业务朝着规范化的方向发展。在金融公司能够把他们的安全通信系统推广到公司外部之前，其他的行业部门需要进行类似的工作，从而减少业务加密带来的复杂性需求。