分类
公司新闻

Symantec MPKI让企业实现SSL证书自主管理

SSL证书已经成为网站安全认证的主导,以其高安全性及加密性大行其道,应用越来越广泛及深入,但同时因其严格的鉴证流程,证书的申请、重签等都需要反复提交资料及漫长的流程。尤其是大型企业,购买证书的种类、数量及年限不同,管理起来更是错综复杂。
某金融公司网站运营负责人正面临这样的问题,因公司发展需求,公司多个域名下分别需要申请多张ssl证书,每张证书都要需要分别提交一次完备的审核资料、分别需要走一套商务流程、需要复杂的审核验证流程,这真是让人头大…..
有没有可能实现多证书的自助管理呢!
symantec推出针对VeriSign SSL品牌证书全生命周期的自主管理系统——MPKI。
MPKI能够一站完成多种类型SSL证书及代码签名证书产品的签发、续费、吊销、替换,省去资料提交、鉴证审核、商务流程等环节,降低成本,节省时间,且企业可根据自己需求随时进行证书的核发、重发等操作,自主便捷,安全高效,尤其让大批量证书管理者的工作化繁为简,是证书管理的贴心助手。

Symantec MPKI让企业实现SSL证书自主管理-1

MPKI实现证书全生命周期自主管理
企业可根据自身需求随时自主对MPKI中的证书进行签发、续费、重签、吊销、替换等操作,方便快捷.可以全面掌握您企业所有的证书,不用再由CA中心单独颁发。保持业务的连续性,防止未知证书过期。
无需任何投入与费用,即可一键轻松管理全部证书
企业无需增加任何网络基础设施、人员、服务及系统维护费用的投入,登录MPKI系统即可轻松管理所有证书,与单独购买证书相比大大节省企业成本
MPKI预审机制给力
企业注册管理员账户时即完成公司资质及域名的审核,一次审核,全年有效,通过审核即可随时签发证书,快速响应业务需求。省去资料提交、鉴证等过程,高效自主。
基于云的控制台,企业可以轻松和快速部署MPKI,同时可根据应用需求灵活扩展证书的种类、数量及年限,企业证书管理员可以根据企业运营需求创建子账户,给予相应的权限,并集中进行管理;企业证书管理员可以通过账户管理为相应证书量身定制注册流程,且管理员可自主完成证书签发,也可指派人员提交申请后由管理员统一签发,MPKI可自动生成关于管理操作等统计报告,且可导出,安全合规。
相信MPKI作为针对ssl证书代码签名证书的统一管理服务系统,必能够让您的证书管理工作化繁为简,开启证书全生命周期管理的新时代

分类
知识中心

公网用户访问lync系统的SSL证书要求

Microsoft Lync Server 2010/2013 通信软件支持使用用于访问和 Web 会议边缘外部接口,以及 A/V 身份验证服务的单个可信SSL证书。边缘内部接口通常使用内部证书颁发机构 (CA) 颁发的专用SSL证书,但同时也可以使用可信ssl证书,前提是该证书是由受信任的受信任的CA 颁发。部署中的反向代理使用可信证书,并会使用 HTTP 对反向代理与客户端以及反向代理与内部服务器之间的通信进行加密(即 HTTP 上的传输层安全性)。

以下是用于访问、Web 会议边缘外部接口以及 A/V 身份验证服务的可信SSL证书的要求:

  • 证书必须由经过批准的受信任的CA 颁发,且该 CA 支持使用者替代名称,比如Symantec公司的VeriSign SSL证书
  • 如果证书要在边缘池上使用,必须将其创建为可导出的证书,并在边缘池中的每台边缘服务器上使用相同的证书。可导出的私钥要求针对的是 A/V 身份验证服务,该服务必须在池中所有边缘服务器上使用同一私钥。
  • 证书的使用者名称是访问边缘外部接口完全限定域名 (FQDN) 或硬件负载平衡器 VIP(例如,access.contoso.com)。
    公网用户访问lync系统的SSL证书要求-1注意:
    对于 Lync Server 2010,不再需要满足此要求,但为了与 Office Communications Server 兼容,仍建议满足该要求。
  • 使用者替代名称列表包含以下各项的 FQDN:
    • 访问边缘外部接口或硬件负载平衡器 VIP(例如,access.contoso.com)。
      公网用户访问lync系统的SSL证书要求-1注意:
      即使证书使用者名称是访问边缘 FQDN,使用者替代名称还必须包含访问边缘 FQDN,因为传输层安全性 (TLS) 将忽略使用者名称,而使用使用者替代名称条目进行验证。
    • Web 会议边缘外部接口或硬件负载平衡器 VIP(例如,webcon.contoso.com)。
    • 如果要使用客户端自动配置或联盟,还需要包含公司内部使用的任何 SIP 域 FQDN(例如,sip.contoso.com、sip.fabrikam.com)。
    • A/V 身份验证服务不使用使用者名称或使用者替代名称条目。
    公网用户访问lync系统的SSL证书要求-1注意:
    使用者替代名称列表中的 FQDN 顺序无关紧要。

如果要在站点上部署多台负载平衡边缘服务器,则安装在每台边缘服务器上的 A/V 身份验证服务证书必须由同一 CA 颁发且必须使用同一私钥。请注意,证书的私钥必须是可导出的,不管是在一台边缘服务器上使用还是在多台边缘服务器上使用。如果要从任何计算机(边缘服务器除外)请求证书,则私钥也必须可导出。由于 A/V 身份验证服务不使用使用者名称或使用者替代名称,因此,一旦满足访问边缘和 Web 会议边缘的使用者名称和使用者替代名称要求,且证书的私钥是可导出的,您就能重用访问边缘证书。

用于边缘内部接口的专用(或可信)证书的要求如下所示:

  • 证书可由内部 CA 或经过批准的受信任的CA 颁发。
  • 证书的使用者名称通常是边缘内部接口 FQDN 或硬件负载平衡器 VIP(例如,lsedge.contoso.com)。但是,可以在边缘内部上使用通配证书。
  • 不需要使用者替代名称列表。

部署服务中的反向代理请求:

  • 对会议的会议内容的外部用户访问权
  • 用于扩展和显示通讯组成员的外部用户访问权
  • 对可从通讯簿服务下载的文件的外部用户访问权
  • 对 Lync Web App 客户端的外部用户访问权
  • 对“电话拨入式会议设置”网页的外部用户访问权
  • 对位置信息服务的外部用户访问权
  • 对设备更新服务的外部设备访问权并获取更新

反向代理会发布内部服务器 Web 组件 URL。与拓扑生成器中的外部 Web 服务一样,Web 组件 URL 是在控制器、前端服务器或前端池上定义的。

可以在分配给反向代理的证书的使用者替代名称字段中使用通配符条目。

分类
知识中心

Lync Server 2013通配符证书支持

Lync Server 2013 使用证书来提供通信加密和服务器身份信息验证。在某些情况下,如通过反向代理的 Web 发布,不需要使用与提供服务的服务器的完全限定域名 (FQDN) 匹配的强使用者替代名称 (SAN) 项。在这些情况下,可以使用具有通配符 SAN 项(通常称为“通配符证书”)的证书来减少从公共证书颁发机构请求证书的成本,并降低证书规划流程的复杂性。

Lync Server 2013通配符证书支持-1警告:
若要保留统一通信 (UC) 设备(例如,桌面电话)的功能,您应该小心测试已部署的证书,确保设备在实施通配符证书后可以正常运行。

不支持使用通配符项作为任何角色的主题名称(也称为公用名或 CN)。使用 SAN 中的通配符项时支持以下服务器角色:

  • 反向代理。简单 URL 发布证书支持通配符 SAN 项。
  • 控制器。控制器 Web 组件中的简单 URL 支持通配符 SAN 项。
  • 前端服务器 (Standard Edition) 和前端池 (Enterprise Edition)。 前端 Web 组件中的简单 URL 支持通配符 SAN 项。
  • Exchange 统一消息 (UM)。   部署为独立的服务器时,服务器不使用 SAN 项。
  • Microsoft Exchange Server 客户端访问服务器。内部客户端和外部客户端支持 SAN 中的通配符项。
  • 相同服务器上的 Exchange 统一消息 (UM) 和 Microsoft Exchange Server 客户端访问服务器。支持通配符 SAN 项。

该主题中未提到的服务器角色:

  • 内部服务器角色(包括但不限于中介服务器、存档和监控服务器、Survivable Branch Appliance 或Survivable Branch Server)
  • 外部边缘服务器界面
  • 内部边缘服务器
    Lync Server 2013通配符证书支持-2注意:
    对于内部边缘服务器界面,可以将通配符项分配到 SAN,支持该操作。不会在内部边缘服务器上查询 SAN,但通配符 SAN 项具有有限的值。
分类
知识中心

Lync Server 2010通配符证书支持

Microsoft Lync Server 2010 使用证书来提供通信加密和服务器身份信息验证。在某些情况下,如通过反向代理的 Web 发布,不需要使用与提供服务的服务器的完全限定域名 (FQDN) 匹配的强主题备用名称 (SAN) 项。在这些情况下,可以使用具有通配符 SAN 项(通常称为“通配符证书”)的证书来减少从公共证书颁发机构请求证书的成本,并降低证书规划流程的复杂性。

Lync Server 2010通配符证书支持-1警告:
若要保留统一通信 (UC) 设备(例如,桌面电话)的功能,您应该小心测试已部署的证书,确保设备在实施通配符证书后可以正常运行。

不支持使用通配符项作为任何角色的主题名称(也称为公用名或 CN)。使用 SAN 中的通配符项时支持以下服务器角色:

  • 反向代理。简单的 URL 发布证书支持通配符 SAN 项。
  • 控制器。控制器 Web 组件中的简单 URL 支持通配符 SAN 项。
  • 前端服务器(标准版)和前端池(企业版)。前端 Web 组件中的简单 URL 支持通配符 SAN 项。
  • Exchange 统一消息 (UM)。部署为独立的服务器时,服务器不使用 SAN 项。
  • Microsoft Exchange Server 客户端访问服务器。内部客户端和外部客户端支持 SAN 中的通配符项。
  • 相同服务器上的 Exchange 统一消息 (UM) 和 Microsoft Exchange Server 客户端访问服务器。支持通配符 SAN 项。

该主题中未提到的服务器角色:

  • 内部服务器角色(包括但不限于中介服务器、存档和监控服务器、Survivable Branch Appliance 或Survivable Branch Server)
  • 外部边缘服务器界面
  • 内部边缘服务器
    Lync Server 2010通配符证书支持-2注意:
    对于内部边缘服务器界面,可以将通配符项分配到 SAN,支持该操作。不会在内部边缘服务器上查询 SAN,但通配符 SAN 项具有有限的值。

为了描述可能的通配符证书的使用,此处复制了规划文档中参考结构所使用的证书指南,以保持一致性。有关详细信息,请参阅参考体系结构。如前所述,UC 设备将利用强名称匹配,如果在 FQDN 项之前呈现通配符 SAN 项,将无法进行验证。按照以下表格中所示的顺序操作,可以限制 UC 设备和 SAN 中的通配符项可能发生的问题。


Lync Server 2010 的通配符证书配置

组件 主题名称 SAN 项/顺序 证书颁发机构 (CA) 增强型密钥使用 (EKU) 组件
反向代理 lsrp.contoso.com lsweb-ext.contoso.com*.contoso.com 公共 服务器 通讯簿服务、通讯组扩展和 Lync IP 设备发布规则。主题备用名称包括:外部 Web 服务 FQDN如果 meet 和 dialin 简单 URL 使用以下格式,通配符会取代 meet 和 dialin SAN:<FQDN>/meet

<FQDN>/dialin

meet.<FQDN>

dialin.<FQDN>

控制器 dirpool01.contoso.net sip.contoso.comsip.fabrikam.comdirweb.contoso.netdirweb-ext.contoso.com

<主机名称>.contoso.net,例如,池中控制器的 <主机名称> 是 director01

dirpool.contoso.net

*.contoso.com

私有 服务器 分配到控制器池中的以下服务器和角色:池中的每部控制器或独立的控制器(未部署控制器池时)。如果 meet 和 dialin 简单 URL 使用以下格式,通配符会取代 meet 和 dialin SAN:<FQDN>/admin

<FQDN>/meet

<FQDN>/dialin

admin.<FQDN>

meet.<FQDN>

dialin.<FQDN>

企业版前端 pool01.contoso.net(对于负载平衡的池) sip.contoso.comsip.fabrikam.comlsweb.contoso.netlsweb-ext.contoso.com

<主机名称>.contoso.net,例如,池中前端服务器的 <主机名称> 是 fe01

pool01.contoso.net

*.contoso.com

私有 服务器 分配到下一个跃点池中的以下服务器和角色:Pool01 中的前端如果 meet 和 dialin 简单 URL 使用以下格式,通配符会取代 meet 和 dialin SAN:<FQDN>/admin

<FQDN>/meet

<FQDN>/dialin

admin.<FQDN>

meet.<FQDN>

dialin.<FQDN>

标准版前端 se01.contoso.net sip.contoso.comsip.fabrikam.comlsweb.contoso.netlsweb-ext.contoso.com

se01.contoso.net

*.contoso.com

私有 服务器 分配到下一个跃点池中的以下服务器和角色:如果 meet 和 dialin 简单 URL 使用以下格式,通配符会取代 meet 和 dialin SAN:<FQDN>/admin<FQDN>/meet

<FQDN>/dialin

admin.<FQDN>

meet.<FQDN>

dialin.<FQDN>

安装和配置 Microsoft Exchange Server 时,会创建并实施自签名证书。将 CA 提供的证书添加到服务器时,我们建议您不要删除自签名证书,除非已将所有服务和 Web 服务重新配置为成功使用新证书。在某些组件不能正常运行的情况下,自签名证书仍可用,因此可以重新配置原始设置和还原原始功能,尽管自签名SSL证书将不会允许您需要的所有功能。这样可以在不影响所有生产功能的情况下为您提供更多的时间来解决配置问题。

 

对于使用 Exchange 统一消息 (UM) 和 Exchange 客户端访问服务器部署的 Microsoft Exchange Server,此处有四个可能的部署应用场景:

  • 应用场景 1:Exchange 统一消息 (UM) 和 Exchange 客户端访问服务器部署在不同的服务器上,客户端访问服务器面向 Internet。
  • 应用场景 2:Exchange 统一消息 (UM) 和 Exchange 客户端访问服务器并置在相同的服务器上并且面向 Internet。
  • 应用场景 3:Exchange 统一消息 (UM) 和 Exchange 客户端访问服务器部署在不同的服务器(具有用于发布的反向代理)上。
  • 应用场景 4:Exchange 统一消息 (UM) 和 Exchange 客户端访问服务器并置在相同的服务器(具有用于发布的反向代理)上。

应用场景 1:Exchange 统一消息 (UM) 和 Exchange 客户端访问服务器部署在不同的服务器上(客户端访问服务器面向 Internet)

Microsoft Exchange 组件 主题名称 SAN 项/顺序 证书颁发机构 (CA) 增强型密钥使用 (EKU) 组件
Exchange 统一消息 (UM)服务器名称:exchum01.contoso.com exchum01.contoso.com Exchange UM 角色不应该包含 SAN 项 私有 服务器 Exchange UM 服务器仅与内部客户端和服务器通信。将私有 CA 根证书导入到每个 Exchange UM 服务器。为每个 Exchange UM 服务器创建并分配唯一的证书。主题名称必须与服务器名称匹配。必须在 Exchange UM 服务器上启用传输层安全性 (TLS),才能将证书分配到 Exchange UM 角色。

分配该证书,以用于在 Exchange 客户端访问服务器上与 Outlook Web Access 和即时消息 (IM) 集成。

Exchange 客户端访问服务器面向 Internet 的 Active Directory 站点客户端访问服务器服务器名称:exchcas01.contoso.com mail.contoso.com mail.contoso.comautodiscover.contoso.com*.contoso.com 公共 服务器 主题名称和 SAN 项必须匹配,才能支持外部 UC 设备。主题名称和 SAN 项 mail.contoso.com 是用于表示 Outlook Web Access、Outlook 无处不在、EWS 和脱机通讯簿的一个示例名称。唯一的要求是该项必须与 DNS 记录匹配,可以由给定名称引用外部 URL 和其他服务项。需要使用 autodiscover SAN 项才能支持外部 UC 设备。
Exchange 客户端访问服务器非面向 Internet 的 Active Directory 站点客户端访问服务器服务器名称:internalcas01.contoso.net internalcas01.contoso.com internalcas01.contoso.com*.contoso.com 私有 服务器 非面向 Internet 的 Active Directory 站点客户端访问服务器仅与内部客户端和服务器通信。如果请求来自查询 Active Directory 站点内承载的服务(例如邮箱)的用户或服务,则面向 Internet 的 Active Directory 站点客户端访问服务器会将通信代理到该客户端访问服务器。非面向 Internet 的 Active Directory 站点上的 EWS 和脱机通讯簿服务经过配置,可使用已部署的证书。该证书可以来自内部的私有 CA。该私有 CA 的根证书必须导入到面向 Internet 的 Active Directory 站点客户端访问服务器上的“受信任的第三方根证书”存储区。

 

应用场景 2:Exchange 统一消息 (UM) 和 Exchange 客户端访问服务器并置在相同的服务器(面向 Internet)上

Microsoft Exchange 组件 主题名称 SAN 项/顺序 证书颁发机构 (CA) 增强型密钥使用 (EKU) 组件
Exchange 统一消息 (UM)服务器名称:exchcas01.contoso.com exchcas01.contoso.com Exchange UM 角色不应该包含 SAN 项 私有 服务器 Exchange UM 服务器仅与内部客户端和服务器通信。将私有 CA 根证书导入到每个 Exchange UM 服务器。必须在 Exchange UM 服务器上启用 TLS,才能将证书分配到 Exchange UM 角色。分配该证书,以用于在客户端访问服务器上与 Outlook Web Access 和 IM 集成。
Exchange 客户端访问服务器和面向 Internet 的 Active Directory 站点客户端访问服务器服务器名称:exchcas01.contoso.com mail.contoso.com mail.contoso.comautodiscover.contoso.com*.contoso.com 公共 服务器 主题名称和 SAN 项必须匹配,才能支持外部 UC 设备。主题名称和 SAN 项 mail.contoso.com 是用于表示 Outlook Web Access、Outlook 无处不在、EWS 和脱机通讯簿的一个示例名称。唯一的要求是该项必须与 DNS 记录匹配,可以由给定名称引用外部 URL 和其他服务项。需要使用 autodiscover.<域命名空间> SAN 项才能支持外部 UC 设备。
Exchange 客户端访问服务器非面向 Internet 的 Active Directory 站点客户端访问服务器服务器名称:internalcas01.contoso.net internalcas01.contoso.com internalcas01.contoso.com*.contoso.com 私有 服务器 非面向 Internet 的 Active Directory 站点客户端访问服务器仅与内部客户端和服务器通信。如果请求来自查询 Active Directory 站点内承载的服务(例如邮箱)的用户或服务,面向 Internet 的 Active Directory 站点客户端访问服务器会将通信代理到该客户端访问服务器。非面向 Internet 的 Active Directory 站点上的 Exchange Web 服务和脱机通讯簿服务经过配置,可使用已部署的证书。该证书可以来自内部的私有 CA。该私有 CA 的根证书必须导入到面向 Internet 的 Active Directory 站点客户端访问服务器上的“受信任的第三方根证书”存储区。

应用场景 3:Exchange 统一消息 (UM)/Exchange 客户端访问服务器部署在不同的服务器(具有用于发布的反向代理)上

Microsoft Exchange 组件 主题名称 SAN 项/顺序 证书颁发机构 (CA) 增强型密钥使用 (EKU) 组件
Exchange 统一消息 (UM)服务器名称:exchum01.contoso.com exchum01.contoso.com Exchange UM 角色不应该包含 SAN 项 私有 服务器 Exchange UM 服务器仅与内部客户端和服务器通信。将私有 CA 根证书导入到每个 Exchange UM 服务器。为每个 Exchange UM 服务器创建并分配唯一的证书。主题名称必须与服务器名称匹配。必须在 Exchange UM 服务器上启用 TLS,才能将证书分配到 Exchange UM 角色。

分配该证书,以用于在客户端访问服务器上与 Outlook Web Access 和 IM 集成。

Exchange 客户端访问服务器服务器名称:exchcas01.contoso.com exchcas01.contoso.com exchcas01.contoso.commail.contoso.comautodiscover.contoso.com*.contoso.com 私有 服务器 主题名称和 SAN 项必须匹配,才能支持外部 UC 设备。将私有 CA 根证书导入到每个 Exchange 客户端访问服务器。主题名称和 SAN 项 mail.contoso.com 是用于表示 Outlook Web Access、Outlook 无处不在、EWS 和脱机通讯簿的一个示例名称。唯一的要求是该项必须与 DNS 记录匹配,可以由给定名称引用外部 URL 和其他服务项。需要使用 autodiscover SAN 项才能支持外部 UC 设备。

必须存在计算机名称(在该示例中为 exchcas01.contoso.com)的项,才能与 Outlook Web Access 和 IM 集成。

反向代理服务器名称:rp.contoso.com mail.contoso.com mail.contoso.comautodiscover.contoso.com*.contoso.com 公共 服务器 另外,主题名称的匹配项必须在证书的 SAN 内。在反向代理位置终止 TLS 或 SSL 后重新建立客户端访问服务器的 TLS 或 SSL,将导致 UC 设备发生故障。如果要支持 UC 设备,则不能使用某些产品(如 Microsoft Internet Security、Acceleration (ISA) Server 和 Microsoft Forefront Threat Management Gateway)的功能以及其他第三方实施、TLS 或 SSL 终止。必须存在 autodiscover 的 SAN 项,才能使 UC 设备正常运行。
Exchange 客户端访问服务器非面向 Internet 的 Active Directory 站点客户端访问服务器服务器名称:internalcas01.contoso.com internalcas01.contoso.com internalcas01.contoso.com*.contoso.com 私有 服务器 非面向 Internet 的 Active Directory 站点客户端访问服务器仅与内部客户端和服务器通信。如果请求来自查询此 Active Directory 站点内承载的服务(例如邮箱)的用户或服务,则面向 Internet 的 Active Directory 站点客户端访问服务器会将通信代理到该客户端访问服务器。非面向 Internet 的 Active Directory 站点上的 Exchange Web 服务和脱机通讯簿服务经过配置,可使用已部署的证书。该证书可以来自内部的私有 CA。该私有 CA 的根证书必须导入到面向 Internet 的 Active Directory 站点客户端访问服务器上的“受信任的第三方根证书”存储区。

 

应用场景 4:Exchange 统一消息 (UM)/Exchange 客户端访问服务器并置在相同的服务器(具有用于发布的反向代理)上

Microsoft Exchange 组件 主题名称 SAN 项/顺序 证书颁发机构 (CA) 增强型密钥使用 (EKU) 组件
Exchange 统一消息 (UM)服务器名称:exchum01.contoso.com exchum01.contoso.com Exchange UM 角色不应该包含 SAN 项 私有 服务器 Exchange UM 服务器仅与内部客户端和服务器通信。将私有 CA 根证书导入到每个 Exchange UM 服务器。为每个 Exchange UM 服务器创建并分配唯一的证书。主题名称必须与服务器名称匹配。无需使用 SAN。必须在 Exchange UM 服务器上启用 TLS,才能将证书分配到 Exchange UM 角色。
Exchange 客户端访问服务器Exchange 统一消息 (UM)服务器名称:exchcas01.contoso.com mail.contoso.com exchcas01.contoso.commail.contoso.comautodiscover.contoso.com*.contoso.com 私有 服务器 主题名称和 SAN 项必须匹配,才能支持外部 UC 设备。将私有 CA 根证书导入到每个 Exchange 客户端访问服务器。主题名称和 SAN 项 mail.contoso.com 是用于表示 Outlook Web Access、Outlook 无处不在、EWS 和脱机通讯簿的一个示例名称。唯一的要求是该项必须与 DNS 记录匹配,可以由给定名称引用外部 URL 和其他服务项。需要使用 autodiscover SAN 项才能支持外部 UC 设备。

必须存在计算机名称(在该示例中为 exchcas01.contoso.com)的项,才能与 Outlook Web Access 和 IM 集成。

反向代理服务器名称:rp.contoso.com mail.contoso.com mail.contoso.comautodiscover.contoso.com*.contoso.com 公共 服务器 另外,主题名称的匹配项必须在证书的 SAN 内。在反向代理位置终止 TLS SSL 后重新建立至客户端访问服务器的 TLS 或 SSL,将导致 UC 设备发生故障。如果要支持 UC 设备,则不能使用某些产品(如 ISA Server 和 Forefront Threat Management Gateway (TMG))的功能,以及其他第三方实施、TLS 或 SSL 终止。必须存在 autodiscover 的 SAN 项,才能使 UC 设备正常运行。
Exchange 客户端访问服务器非面向 Internet 的 Active Directory 站点客户端访问服务器服务器名称:internalcas01.contoso.com internalcas01.contoso.com internalcas01.contoso.com*.contoso.com 私有 服务器 非面向 Internet 的 Active Directory 站点客户端访问服务器仅与内部客户端和服务器通信。如果请求来自查询 Active Directory 站点内承载的服务(例如邮箱)的用户或服务,则面向 Internet 的 Active Directory 站点客户端访问服务器会将通信代理到该客户端访问服务器。非面向 Internet 的 Active Directory 站点上的 Exchange Web 服务和脱机通讯簿服务经过配置,可使用已部署的证书。该证书可以来自内部的私有 CA。该私有 CA 的根证书必须导入到面向 Internet 的 Active Directory 站点客户端访问服务器上的“受信任的第三方根证书”存储区。
分类
安全播报

社交网络、移动设备及云服务(分析)

分析

垃圾邮件和网页仿冒转向社交媒体
过去几年中我们注意到,社交媒体网站上的垃圾邮件和网页仿冒大幅增加。罪犯尾随用户到流行的网站上。随着 Facebook和 Twitter 用户数量的增长,这些网站也吸引了更多犯罪行为不过,去年网络罪犯也开始将目标对准一些飞速壮大的新网站,如 Instagram、Pinterest 和 Tumblr。
典型的威胁包括礼品卡和调查骗局。此类虚假内容骗局占全部社交媒体攻击的一半以上 (56%)。例如,在某个骗局中,受害者在某人的 Facebook Wall 或 Pinterest Feeds(其中的内容看似来自受害者关注的人或特定类别的人)上看到一个帖子,写着“单击此
处获得 100 美元的礼品卡”。当用户单击该链接后,会转到一个网站,要求用户报名参加种种活动,并在此过程中提交详细的个人信息。每注册一名用户,垃圾邮件发送者即可获得一定报酬,当然,直到过程结束,用户也不会收到任何礼品卡。
社交网络、移动设备及云服务(分析)-1

典型的社交网络骗局

社交网络、移动设备及云服务(分析)-2

包含虚假调查的虚假网站

社交网络、移动设备及云服务(分析)-2

仿冒网站伪装成一个宣传足球明星 Lionel Messi 的社交网站。

社交网络、移动设备及云服务(分析)-4

我们还记录了针对时下大热的照片分享应用程序Instagram 的一起类似的骗局。

还有一种骗局,是利用虚假网站来诱使受害者透露详细个人信息和密码,例如,Facebook 或 Twitter 帐户信息。这种网页仿冒骗局极为隐蔽,而且往往利用人们对名人的崇拜心理,如职业运动员、电影明星或歌手等。我们注意到,针对特定国家/地区及其名人的网页仿冒骗局有所增加。
2012 年我们注意到,越来越多威胁瞄准了社交媒体网站以及不断涌现的更多新渠道和平台,尤其是那些仅用作移动应用程序的渠道和平台。这些移动社交渠道很可能在 2013 年成为更大的目标,尤其是那些专门针对青少年和年轻人的社交渠道,这些年轻用户可能不知道如何识别此类攻击,并且对个人信息的保护也不太在意。

移动设备威胁
上一年我们观察到,移动恶意软件呈进一步增长势头。这与互联网连接移动设备数量的不断增长不无关系。根据 Gartner 的统计,Android 占据 72% 的市场份额,Apple? iOS 以相去甚远的 14% 位列第二。18 Android 因市场份额以及更为开放的开发环境,成为主要的移动设备威胁目标。

通常情况下,人们习惯用手机存储个人信息和联系信息,随后渐渐有了高速互联网连接。智能手机因自身特点成为了功能强大的计算机,因而对罪犯充满了诱惑力。此外,它们还具有与支付系统(所有者的手机合约)绑定的额外优势,这意味着它们为罪犯从受害者那窃取金钱提供了更多方式。

我们注意到,所有类型的手机攻击均大量增加:
• Android 威胁在东欧和亚洲地区更常见,不过,去年欧洲其他地区以及美国的 Android 威胁数量有所提升。
• 隐私泄露攻击意在暴露个人信息,包括设计用于暗中发送手机所有者位置的监视软件的推出。
• 付费服务号码诈骗,恶意应用程序发送昂贵的短信。这是通过移动恶意软件敛财最快的一种方式。赛门铁克观察到的一个移动僵尸网络即采用虚假移动应用程序感染用户,根据我们的计算,僵尸操控者不断在各地涌现,诈骗金额为每天 1,600 到9,000 美元,每年 547,500 到 3,285,000 美元。

在以往的情况中,恶意软件对智能手机的感染是通过流氓应用程序市场,以及用户通过电脑连线直接将应用程序安装到手机上这种方式。但现在,合法的应用程序商店也不能幸免。2012 年我们注意到,在 Google? Play 市场中,流氓软件伪装成热门游戏,以避开Google 的自动筛选流程。

企业逐渐允许员工“自带设备”(BYOD) 上班,允许员工将个人计算机、平板电脑或智能手机用于工作,甚至补贴员工购买自己的设备。即使公司提供设备,但消费化趋势意味着公司往往会转而采用个人用户技术(如文件共享网站)和设备(如个人用户笔记本电脑或平板电脑)以降低成本。这两个趋势打开了一扇大门,令企业处于更大的风险之中,因为移动设备往往缺乏安全功能,例如,加密、访问控制和可管理性等。

我们注意到,2012 年针对 iOS 平台的漏洞遥遥领先于 Android,占已发布漏洞的 93%,不过 Android 在恶意软件方面仍居前列,占新威胁的 97%。

乍看之下二者似乎相互矛盾,但此现象有一个很好的理由可解释:破解 iOS 设备。为了安装 Apple App Store 中没有的应用程序,用户必须利用软件中的漏洞。虽然从安全角度而言,这并非最安全的方法,但这是安装无法通过 Apple App Store 获得的应用程序的唯一方式。

相反,Android 平台提供了从非官方市场安装应用程序的选项,只需更改操作系统设置即可。由于不需要利用漏洞,因而不存在 iOS 上那样的动机。Android 用户容易受到大量威胁的攻击,但极少有攻击利用漏洞来扩散威胁。

尽管 Android 平台 2012 年遭遇了 103 种威胁,不过与移动设备威胁范畴内的其他估值相比,该数据并不算多。许多估值更大,是因为它们提供的是总的变体数量,而不是新的独特的威胁。其中许多变体只是进行了微小调整,以避开防病毒扫描程序的检测。根据赛门铁克的统计,一年当中至少出现了 3,906 个不同的移动变体。

在安全功能方面,旧版本 Android 与新版本之间存在重大区别。Google 在 Android 4.x 版中新增了一个功能,允许用户阻止任何特定应用程序向状态栏推送通知。由于广告平台向状态栏推送通知,骚扰到旧版本用户,该功能是根据其反馈意见做出的调整。

此外,由于在用户毫无察觉情况下发送付费短信这一威胁形式的兴起(例如,Android.Opfake、Android.Premiumtext、Android.Positmob 和 Android.Rufraud),Google 在 Android 4.2 中增加了一个功能,以提示用户确认是否发送此类付费短信。该功能对于保护大多数用户非常有用。

然而,到 2012 年年底,Android 4.2 设备的市场渗透率仅为大约10%,23 只占总设备的一小部分。Android 生态系统使得很难令每个用户保持最新状态。Google 发布的官方平台只能在 Nexus 设备(Google 自己的品牌设备)上实现即装即用。每家制造商均以此为基础修改并发布自己的平台,然后移动网络运营商会挑选这些平台,同时他们也会定制自己的平台。

因此,Google 的任何变更不可能迅速推广到市场中的所有设备。对平台所做的任何更改需要每家制造商,然后是每家运营商进行全面彻底的测试,从而延长了到达用户手中所需的时间。设备型号如此之多,也大大增加了所有这些公司为每次更新不得不分配的资源量,从而导致很少发布更新程序,某些情况下较老的设备甚至没有更新程序。

对于操作系统中的大多数漏洞利用,Google 均发布了快速修复,但用户仍需等待较长时间才能从网络运营商那获得修复程序。某些漏洞利用并非存在于初始操作系统中,而是位于制造商的定制修改版本中,例如,2012 年出现的针对 Samsung 型号的漏洞利用。Samsung 迅速修复了该漏洞,但修复程序仍必须通过网络运营商才能到达用户手中。

Google 对平台的严格控制有利于解决某些“碎片”问题,但也会影响与制造商的合作关系。针对旧版本 Android 用户设立截止点有助于减少风险,但通常是制造商这么做。

 云计算风险

根据 Gartner 数据分析,2012 年云服务市场预计增长 20%。24云计算使企业有望在无需大笔前期资本成本的情况下加强 IT 能力,对于较小规模的企业而言,能够以可承受的价格使用企业级商业软件。基本言之,随着互联网带宽及处理能力的飞速提升,云计算带来了不断增长的巨大规模经济。

云计算也带来了一些潜在的安全优势,尤其对于没有专门的 IT 安全部门的小公司而言。运行良好的云应用程序更有可能经过有效修补和更新。相比内部系统,它们也更可能具备灵活性、安全性和备份功能。
不过,云计算也存在一些安全隐患:

• 隐私。对于谁能在哪些情况下访问客户数据(例如,用于故障排除),经营有方的云服务公司应当拥有周密的策略。只有在充分保障数据管理和访问方式的情况下,才能将信息通过互联网托付给第三方。
• 数据自由。如果您希望更换提供商,云计算企业可使之轻松启动,信誉良好的公司可令您的数据提取更简单(例如,归档的电子邮件或客户记录)。在将数据托付给云提供商之前,潜在用户应以后提取并恢复数据的条款和条件进行全面评估。
• 鸡蛋放在一个篮子里。如我们在过去几年中发生的大规模数据泄露事件中所见,攻击者倾向于去到那些不费力气即可攫取最多数据的地方。如果云服务提供商存储了大量客户的机密信息,那么也会成为攻击者的猎物。云提供商的哪怕一次泄露,对攻击者而言可能是一座个人数据金矿。
• 消费化。如果公司员工临时使用未经批准的云系统,公司将面临数据意外或故意泄露的重大风险。例如,如果根据公司策略,很难将大文件通过电子邮件发送给第三方,员工可能会转而使用免费的在线文件共享应用程序。风险在于,这些系统可能达不到公司的安全标准。例如,某个知名的文件共享网站将其所有用户帐户保持未锁定状态长达四小时。25 此外,如果员工在工作中使用未经授权的云应用程序,譬如通过社交媒体网站进行市场营销,公司可能会遭致基于 Web 的恶意软件的攻击。
• 基础架构。在多租户虚拟体系结构中,恶意用户可以租赁一个虚拟机,然后利用基础管理程序中的漏洞,通过该虚拟机向系统发动攻击,并访问运行于相同环境下的其他虚拟机,这种理论上的风险虽然并不常见,但仍然存在。还应当考虑在虚拟机内进行数据加密,以尽量降低未经授权访问物理硬盘所带来的风险。

 建议

将社交媒体威胁视为企业问题。
公司往往不愿意全面限制对社交媒体网站的访问,但必须想办法防御这些网站以及其他网站上基于 Web 的恶意软件。这意味着需要在网关和客户端电脑上安装多层安全软件。此外,还应当积极安装修补程序和更新程序,以降低偷渡式下载感染风险。最后,用户培训和明确的政策必不可少,尤其在用户在线泄露的个人信息量方面。

云服务安全建议。
在签字前进行全面风险评估。确保自身信息和身份信息的安全。建立强大的管理框架。

保护移动设备。
考虑在移动设备上安装安全软件。此外,必须对用户进行培训,告知下载流氓应用程序的风险以及如何使用隐私和权限设置。对于公司提供的设备,可考虑全面锁定设备,防止安装任何未经批准的应用程序