此举将给对于移动 技术的使用态度带 来巨大而积极的转 变，我甚至可以大 胆地说一句连PC技 术也将包含在内。 特别是对于使用这 些API的第三方工 具以及软件开发人 员。
改变企业游戏规则
苹果在iOS及OS X中推出的针对内容的新型管理API 应该会进一步降低IT管理员及CSO们对安全问题的疑 虑，同时不会影响用户的自由空间。
如果有某家公司能够在实现企业 移动安全的同时保持用户的自由使 用空间，那一定就是苹果。事实也 的确如此，苹果在保证用户享受iOS 7及OS X 10.9 Mavericks新型内 容与应用管理API的同时，也将安 全水平提升到新的高度（具体细节 稍后再进行讨论）。 此举将给对 于移动技术的使用态度带来巨大而 积极的转变，我甚至可以大胆地说 一句连PC技术也将包含在内。特 别是对于使用这些API的第三方工 具以及软件开发人员。
几乎很少有商业应用敢于顶住风 险提供移动应用管理（简称MAM）API， 愿意支持多套API的产品就更少了。 IT部门也往往不愿从根本层面采取这 种保护措施——理由很简单，一旦将 这些专有API嵌入到自己的应用程序 当中，他们就会被锁定在特定供应商身 上。移动安全是一片年轻而充满风险的 市场，过早下注实在不够明智。另外， 我们也知道几乎没有哪家企业会重新调< 整陈旧应用——那些对ActiveX及IE 存在严重依赖性但却仍然活跃在我们视 野当中的应用能够充分证明这一点。
这是个不可告 人的秘密—— 尽管针对移动 内容“丢失” 的警钟响个不 停，但多年来 PC平台也始终 存在着同样的 问题。
情况也确实如此：AirWatch、Centrify、 思杰、Good Technology、MobileIron、Mob- ileSpace以及其它多家厂商都已经确定将在 其管理工具当中采用这项技术——其中一些 目前已正式上市。有趣的是，MobileSpace公 司还为Android平台带来了类似的功能。
当苹果在2010年夏季发布的iOS 4.2中 采用Exchange ActiveSync（简称EAS）并添 加自有管理与安全API时，企业就已经加入 了这场影响深远的移动变革。几乎在一夜之 间，IT部门得以强制执行密码政策、核实设 备上的加密机制是否启用，甚至根据合法安 全需要限制设备对于特定Wi-Fi网络、装置 以及各类服务的访问。随着时间的推移，苹 果已经在各iOS后续版本当中逐步改进这些 控制机制，并将成果添加到OS X当中。谷 歌在Android平台上借鉴了基础API，三星 则通过改进使其更接受苹果产品的实际效果。
因此，移动设备管理（简称MDM）已经 成为近乎标准化的普及型安全方案。这也解 释了为什么有这么多供应商及IT部门开始 将注意力转移到其它难题身上：失去对企业 信息的控制权，例如邮件附件、工作文档等 等。MDM能够有效阻断或者限制针对特定应 用程序及网络服务的访问，但却对内容管理 无能为力。
面对新的难题，业界也作出积极响应， 推出大量专有工具、要求开发人员使用供应 商指定的API并使用厂商自有管理工具（或 者来自合作方的相关工具）。
苹果的新型管理API在很大程度上杜绝了 此类专有工具的泛滥。如果大家已经或者正打 算使用这类工具，请尽早罢手。只需支付一百 美元成为苹果开发者、学习苹果API并将其引 入自己的应用程序，一切问题都将迎刃而解— —无论是对企业内部应用还是App Store消费 应用都是如此。可以肯定的是，每一家主流移 动管理工具厂商都将支持这些API，因为它们 同时支持OS X应用。苹果所提供的通用型API 在所有应用中都能起效、且适用于任何管理服 务器。如果大家需要更多深层功能，则可以考 虑使用专有API——目前Apperian、Good Technology以及MobileIron等厂商都提供以 苹果API为基础的丰富多层控制机制。
事实上，新型苹果API也为Windows PC 的内容安全之路指明了方向。这是个不可告人 的秘密——尽管针对移动内容“丢失”的警钟 响个不停，但多年来PC平台也始终存在着同样 的问题，而且始终未能出现切实有效的解决办 法。但现在不同了，Mac已经获得了与移动设备 相同的安全机制。也许微软也会将苹果API部 署到Windows PC当中，从而真正在不影响使用 的前提下实现安全诉求。
iOS 7与OS X Mavericks为我们带来了关键 性内容与应用程序管理API以及相关功能。苹果 自然也在其开发者网站上提供了大量说明文档（ 需要开发者权限方可阅读）以及针对IT部门的 功能概述。
OS X Mavericks 的密码政策已经 能够识别iOS 7 系统，因此IT 部门可以不必再 担心不同次级系 统版本所带来的 小麻烦。
管理“在……中打开
“在……中打开”旨在帮助用户在iOS中的一 个应用中打开其它应用数据。iOS系统并未使用 共享式文件系统，从而避免恶意软件攻击并保证 不同应用程序的内容互不干扰。相反，应用会指 定彼此全部支持的某种文件格式，并接受来自其 它应用的数据。用户点击“分享”按钮或者其它 能够触发“在……中打开”功能的情况下查看兼 容当前文件格式的其它应用。当前文件会调用被 选中的应用并向其发送被选中的文件。举例来说， 大家可以通过这种方式将邮件应用中的文件附件 移动到GoodReader或者Dropbox当中，也可以将Dropbox中的内容移动到苹果Pages或者谷歌Quickoffice当中。
我曾就此事与苹果公司展开讨论，而其竞争对 手则开发出一套更为细化的信息管理标准——也就是InfoTrust。 iOS 无法同时运行多个应用实例，因此大家不能同时拥有一个未受管个人副本与一个受管工作副本，MobileSpaces公司营销副总裁Dan Dearing指出。（Android则不受单一实例规则的约束。）这正是苹果新型应用程序管理方案的最大弱点：苹果真的应该以iOS 7为契机推出至少两个应用实例的支持能力，这样用户就可以独立运行Dropbox、Box、Quickoffice、iWork等应用实例，其中一个由工作区管理、另一个由个人使用环境管理。
iOS 7及OS X Mavericks中的新型API允 许大家指定哪些应用有权发送“在……中打开” 调用——这基本上相当于一种白名单机制，帮助 应用从用户配置或者管理的应用中获取数据。这 种管理机制源自账户层级，因此所有由企业方面 配置的账户（包括邮件与日历）及应用都遵循“ 在……中打开”政策组的要求。需要着重强调的 是，受管“在……中打开”都属于非黑即白机制： 所有受管应用（即由公司配置的应用）都拥有同 一套“在……中打开”政策，而所有未受管应用 （即那些由用户配置的、来自App Store的应用） 都不遵循“在……中打开”政策，MobileIron公 司战略副总裁Ojas Rege指出。
不过新型受管“在……中打开”方案也存在 局限，当一款应用既属于个人类型、又被包含在 业务用途当中时，问题就会出现——目前符合此 类情况的商用应用数量不少。“在……中打开”政 策对应用中的任何文档生效，因为像邮件这样的 应用程序根本无从知晓内部数据到底属于业务类 型还是个人类型。
在这一设想成为现实之前，IT部门仍然很难将受管 “在……中打开”机制应用到Quickoffice以及Pages 等日常应用当中，因为iOS只能同时支持一个运行实例； 换言之，应用程序要么处于受管状态、因而只能由业务 环境使用；要么处于非受管状态、只能由个人需求使用。 更进一步来说，如果一台设备已经拥有一个个人应用副 本，那么如果想将其纳入受管“在……中打开”的作用 范畴，用户必须移除该应用、而后重新安装由企业配置 的应用副本，Rege指出。
解决单一实例限制的方法之一在于允许开发人员在 公共App Store当中销售一个版本、另在企业App Store 当中发布一个版本，这样iOS就能将二者视为彼此独立 的两个应用并将其同时安装在同一台设备当中。这意味 着用户不得不用自己的头脑将两个应用版本硬性区分开 来——这种方式也许非常笨拙，但却是惟一的解决方案。 在这种情况下，对商业开发人员而言只有专有应用管理 系统（例如Good公司的Dynamics以及MobileIron的 App@Work）才值得为之分别创建业务与个人两个版本。
需要指出的是，这种应用程序冲突不会影响到 面向账户的应用，例如邮件、记事本、日历以及提 醒事项等。iOS一直将此类应用中的数据根据账户 加以隔离，因此它“知晓”来自企业Exchange服务器的数据不应与家中的IMAP（即消息访问协议）来 源混杂在一起。正因为如此，企业可以在不影响个 人邮件的前提下实现业务邮件清理功能。iOS 7能 够非常简便地将企业账户与由企业配置的应用对接 在一起（事实上应用配置通过的是企业账户所使用 的同一台服务器），这样Exchange邮件的“在…… 中打开”就可以被限制在某些特定应用当中，但却 不会影响其它账户的“在……中打开”政策。
单点登录与统一密码政策
iOS 7 与OS X Mavericks利用所谓“共享钥匙 串”实现存储统一与登录密钥访问，因此各类应用 程序及托管机制可以通过一台MDM服务器利用这一 功能。
在iOS的其它早期版本当中，企业中的内部开 发团队可以通过共享式钥匙串实现企业应用的单点 登录。与之类似，拥有一整套应用组合的开发人员 也可以利用该功能实现同样的效果。
以Kerberos为基础的新型单点登录机制允许IT 部门将这些共享式钥匙串与单独应用的密钥相结合， 这样只需一次通用登录、所有已关联的应用程序密 码都将被解锁。单点登录密码由iOS负责保存而并 非应用本身，同时受到使用者管理服务器的管理。大 部分应用程序无需重新编码即可实现与单点登录机制 的兼容。不过IT部门仍然需要负责单点登录方案的 部署——即保证Kerberos密钥机制能够通过VPN而 非互联网被使用者访问，MobileIron公司的Rege指 出。
AirPlay、AirPrint以及字体管理
iOS还拥有另一大独特亮点，即利用某种新型API 允许MDM服务器强制将内容以镜像形式投映到Apple TV 或者其它AirPlay目标设备之上，例如作为公共设备的 iPad。iOS设备的政策适用范围还包括获准接入的 AirPlay白名单及其密码，因此企业完全可以通过对受管 设备的配置以自动化方式将其与会议室中的Apple TV相 连，而且完全不必当着用户们的面输入密码。与之类似， 大家也可以配置获准AirPrint目标设备（也就是打印 机）。
而在iOS与OS X两套系统平台上，我们现在都可以 在设备上安装字体，例如确保整个企业都使用同样的字体 显示风格。
为每款应用提供独立VPN与Web内容过滤机制
iOS与OS X中的新机制允许由企业进行配置的应用使 用独立的VPN连接，这样企业就不必担心某些用户打开设 备级VPN连接后在其上运行其它不符合政策要求的应用了。 这种作法同时也确保了个人应用数据不会与企业VPN产生 不必要的交集——这同时也是困扰传统设备VPN连接的另 一个难题。在iOS当中，应用程序需要通过政策进行配置， 从而在其被安装完成后即具备只适用于自身的特定VPN； 而且这一配置无法在其后重新进行。值得一提的是，大家 的VPN需要支持各应用独立通道功能，因此请认真向VPN 垂询其方案与iOS 7之间的兼容性，Rege指出。
iOS的另一大特性是，政策同样可用于管理Web内容 过滤机制。
