iOS MAM策略：发现URL协议与数据传输例外

最近我写了一篇关于移动应用管理（MAM）策略的博客，这些策略是现代IT安全中默默无闻的英雄。它们即使在个人设备上也能确保企业数据的安全。然而，当涉及到数据传输例外时——那些允许非托管应用与托管应用数据交互的棘手设置——事情很快就会变得复杂。微软关于风险的警告并非玩笑：配置错误可能将您的安全设置变成漏水的桶。但这是为什么呢？存在哪些风险？

在本博客中，我将分享关于URL协议和数据传输例外的实践经验，以及为什么您可能考虑将应用添加到例外列表中。

我邀请您分享对此主题的想法，因为文档并没有真正清楚地说明幕后发生的事情，我们可以从彼此的经验中学习。我也希望微软能够对此有所阐明。当然，我还没有涵盖所有角度，并将此博客视为进行中的工作。同时，我将尽力深入研究，并在有消息分享时更新此文章…

无论您是管理iOS还是Android设备，在本博客中您将学习：

如何处理数据传输例外
发现iOS应用URL协议的分步指南（和脚本！）
来自现场的提示

所以，拿起您的咖啡，让我们开始工作。

应用保护策略（APP）

您可以在Intune应用保护策略（APP）数据传输设置中创建例外。这些例外允许您手动选择哪些非托管应用被允许与托管应用交换数据。

当您设置Intune应用保护策略，将“允许应用将数据传输到其他应用”设置为“策略管理的应用”时，您确保数据只能与其他Intune管理的应用共享。但是，如果您需要允许数据传输到某些不支持Intune APP的应用，您可以使用“选择要豁免的应用”选项创建例外。

根据文档：“豁免允许由Intune管理的应用基于URL协议（iOS/iPadOS）或包名（Android）调用非托管应用。”

阅读此内容时，我在想“好的，我明白了，由Intune管理的应用可以基于URL协议调用非托管应用”，而不是相反。但问题来了：

我无法真正解释这意味着什么。我已经配置了我的MAM策略，并尽力将数据泄露到这些豁免的应用中（我稍后会谈到），但没有成功。我看到的是一个应用可以通过链接调用。例如，公司电子邮件（MAM保护的Outlook）中的链接请求为您与一些同事举行的深夜派对付款。当收件人点击“付款”链接时，它应该打开银行应用。

请求：如果您有可以分享的信息，请这样做，让我们一起学习。

默认情况下，Intune在此例外列表中包含必要的本机应用以确保功能。这些默认应用是：skype;app-settings;calshow;itms;itmss;itms-apps;itms-appss;itms-services;。您在这里看到的是这些应用的URL协议。

iOS挑战：发现URL协议

为iOS应用创建例外需要知道它们的URL方案（又称URL协议）。这些看起来像是应用用于通信的别名。但是如何找到它们呢？不幸的是，苹果没有让这变得容易，微软也没有提供内置方法。

这就是脚本魔法的用武之地。我创建了一个方便的脚本，直接从应用的.ipa文件中提取这些协议。稍后会详细介绍…

数据传输例外的风险业务

数据传输例外对我来说有点神秘。它们是否允许非托管应用从托管应用访问数据？我不确定，并想知道为什么微软对此发出警告。这真的是数据泄露的潜在潘多拉盒子，还是我们在小题大做？

微软的主要警告：

非托管应用是通配符：它们不受您的MAM策略管辖，因此它们访问的任何数据都可能去任何地方。
您是守门人：微软明确表示，您负责审查和批准例外。
谨慎添加例外：坚持使用对组织至关重要且数据泄露风险最小的应用。

通用链接也是如此。您不能错过那里的警告。

查看微软关于iOS数据传输豁免的详细指南。

其他应用保护策略设置

为了让理解变得更加复杂，根据微软的说法，修改或添加例外到数据传输策略不会影响其他应用保护策略，例如剪切、复制和粘贴限制。在看到所有红色标签的警告后，这可能会让人感到惊讶…所以我再次问：到底存在什么数据泄露风险？真的希望有人能详细解释发生了什么…我想我可能会邀请Rudy Ooms进行深入探讨。

谨慎进行…

在急于创建例外和调整策略之前，让我们暂停片刻。调整数据传输例外可能对组织的安全产生严重影响。在继续之前，这里有一些建议：

了解风险：添加例外意味着允许非托管应用从托管应用访问数据。如果未仔细选择例外，这可能导致意外的数据泄露。
在受控环境中测试：在没有彻底测试的情况下，切勿将更改部署到生产环境。设置测试环境以验证您的策略，并确保不会发生意外行为。
仔细检查：确保您无法通过“打开方式”菜单共享整个文件
定期审查例外：例外不应是“设置后就忘记”。定期审查它们以确保它们仍然需要且不构成风险。
与利益相关者沟通：确保从IT到最终用户的每个人都了解这些例外的影响。透明度有助于降低风险，并确保策略与组织目标一致。
记录一切：保留所有更改的详细日志，包括为什么添加例外以及谁批准了它。这将在审计或故障排除期间为您省去很多麻烦。

底线：您在功能性和安全性之间走钢丝。确保您始终谨慎行事，并记录每一步。

数据泄露可能如何发生

这些只是基于常识、安全实践、应用通常的工作方式以及非托管应用带来的风险的有根据的猜测。微软没有确切说明当您豁免应用时数据可能如何泄露，但这些示例突出了现实世界的漏洞，以及当非托管应用获得对托管企业数据的访问权限时可能出错的方式。我无法确认…或否认…

不安全的网络传输：如果豁免的应用通过不安全连接（例如，HTTP而不是HTTPS）发送或接收数据，敏感的企业数据可能在传输过程中被拦截。
与个人账户的云同步：许多应用，尤其是生产力工具，提供与个人账户（例如，Google Drive、iCloud或Dropbox）绑定的云同步选项。如果豁免的应用将工作数据同步到非托管的个人账户，它将绕过您的企业控制，并成为潜在的泄露点。
第三方集成：一些应用连接到未经组织审查的第三方服务或插件。通过豁免应用，您可能无意中允许这些集成访问企业数据，为数据泄露创建后门。
设备上的数据保留：一些应用在设备上本地存储数据而不加密。如果应用被豁免，这些数据容易受到未经授权的访问，特别是如果设备被入侵或丢失。
伪装成合法应用的恶意应用：如果您在没有彻底审查的情况下豁免应用，您可能允许恶意应用（或可能被利用的应用）访问企业数据，可能将其暴露给攻击者。
社会工程或用户错误：用户可能无意中通过豁免的应用共享数据，特别是如果这些应用缺乏关于传输敏感信息的明确提示或警告。

简而言之，豁免应用可能为意外的数据共享或泄露打开多种途径。这可能是为什么微软强调彻底测试并仅豁免您信任且对组织至关重要的应用。实际风险可能取决于您环境中的特定应用和配置。在受控环境中测试和评估应用行为是确认这些场景的关键。

URL协议提取脚本

此脚本深入.ipa文件，查找应用Info.plist文件中列出的所有URL方案。对于需要快速、可靠地发现URL协议的管理员来说，这是完美的。

注意：此脚本将维护在我的GitHub存储库中。

脚本：

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105


#!/bin/bash
# -------------------------------------------------------------------------------------------------------------------------------
# 从iOS应用.ipa文件中提取和识别URL协议的脚本
# -------------------------------------------------------------------------------------------------------------------------------
#
# 此脚本从iOS应用.ipa文件的Info.plist文件中提取所有URL方案（CFBundleURLSchemes）。它输出：
# 1. 找到的所有CFBundleURLSchemes的完整列表。
# 2. 基于宽松过滤规则的最可能的URL协议。
#
# 免责声明：
# 此脚本按"原样"提供，无任何形式的保证或担保。虽然它已创建以满足特定功能，
# 并已为我的个人需求有效工作，但其性能在不同环境或使用案例中可能有所不同。
# 建议用户自行决定使用此脚本并自担风险。
# 对于可能因其使用而直接、间接、偶然或结果性产生的任何损害，不承担任何责任。
#
# 重要提示：
# 识别URL协议的准确性取决于脚本中应用的过滤规则。始终审查输出的CFBundleURLSchemes完整列表，
# 以确保没有遗漏关键条目。此脚本处理提取的Info.plist文件，并假设.ipa文件有效且包含所需结构。
#
# -------------------------------------------------------------------------------------------------------------------------------
# 作者：Oktay Sari
# https://allthingscloud.blog 
# https://github.com/oktay-sari/
#
# 注意：
# 此脚本绝非完美。
# 如果您认为有进一步改进此脚本的好主意，请与我们联系。
#
# 脚本版本/历史：
# 2025年1月18日 - Oktay Sari - URL方案提取的初始版本
# 2025年1月19日 - Oktay Sari - 添加了完整列表和最可能协议之间的清晰区分
# 2025年1月22日 - Oktay Sari - 增强了过滤逻辑以包括单点URL协议
# 2025年1月22日 - Oktay Sari - 脚本版本1.0
#
# 路线图/愿望清单：
# - 进一步优化边缘案例的过滤规则
# - 添加对多个.ipa文件的批处理支持
# - 添加日志记录到文件以进行详细审查
#
# 要求：
# - 要分析的有效.ipa文件
# -------------------------------------------------------------------------------------------------------------------------------

# 检查是否提供了参数（文件路径）
if [ -z "$1" ]; then
    echo " 请提供.ipa文件的路径。"
    exit 1
fi

# 验证提供的文件是否存在
if [ ! -f "$1" ]; then
    echo " 文件 $1 不存在。"
    exit 1
fi

# 创建唯一的临时目录
TEMP_DIR=$(mktemp -d)
IPA_FILE="$1"

# 将IPA文件解压缩到临时目录
echo "正在提取 $IPA_FILE..."
unzip -q "$IPA_FILE" -d "$TEMP_DIR" || { echo " 解压缩文件失败。"; rm -rf "$TEMP_DIR"; exit 1; }

# 在提取的应用包中定位Info.plist文件
APP_FOLDER=$(find "$TEMP_DIR/Payload" -name "*.app" -type d | head -n 1)
PLIST_FILE="$APP_FOLDER/Info.plist"

if [ ! -f "$PLIST_FILE" ]; then
    echo " 在应用包中未找到Info.plist。"
    rm -rf "$TEMP_DIR"
    exit 1
fi

# 提取所有CFBundleURLSchemes
echo "找到的URL方案："
ALL_SCHEMES=$(xmllint --xpath "//key[text()='CFBundleURLSchemes']/following-sibling::array/string/text()" "$PLIST_FILE" 2>/dev/null)

if [ -z "$ALL_SCHEMES" ]; then
    echo " 未找到URL方案。"
    rm -rf "$TEMP_DIR"
    exit 0
fi

# 按原样打印所有URL方案
echo "------------"
echo "这些是info.plist文件中所有的CFBundleURLSchemes值："
echo "$ALL_SCHEMES" | tr ' ' '\n'

# 分隔线
echo "------------"
echo "这些很可能是您要找的URL协议："

# 过滤并打印可能的URL协议
LIKELY_SCHEMES=$(echo "$ALL_SCHEMES" | tr ' ' '\n' | grep -E '^([a-zA-Z0-9\.\-]+)$' | grep -E '^[a-zA-Z0-9\-]+(\.[a-zA-Z0-9\-]+)?$')

if [ -z "$LIKELY_SCHEMES" ]; then
    echo " 未识别出明确的URL协议。请审查上面的完整列表以寻找潜在候选。"
else
    echo "$LIKELY_SCHEMES"
    echo "------------"
    echo " 注意：审查上面的完整列表以确保没有遗漏重要的URL协议。"
fi

# 清理临时目录
rm -rf "$TEMP_DIR"

如何使用URL协议提取脚本：

将脚本保存为extract-url-protocol.sh
使其可执行：chmod +x extract-url-protocol.sh
使用.ipa文件运行：./extract-url-protocol.sh <path_to_ipa>

获取IPA文件

那么，IPA文件到底是什么？可以将其视为Android上APK的iOS等效物。IPA（iOS App Store Package）本质上是iOS应用文件和元数据的容器。在这个包中隐藏着我们正在寻找的宝藏：包含我们所需URL方案的Info.plist文件。

以下是获取IPA文件并定位Info.plist的方法：

1. 下载IPA文件

从App Store：如果您有一台安装了iTunes（12.7版之前）的旧iOS设备，您可以将应用下载到计算机并从那里提取IPA。
从iMazing：这是在现代设置中最简单的方法：
- 将您的iOS设备连接到计算机。
- 打开iMazing并导航到应用部分。
- 选择您想要的应用，然后从选项中选择下载，然后导出IPA。iMazing将打包并将IPA文件保存到您选择的位置。

获取IPA文件可能需要一些努力，但这是发现这些URL协议的关键步骤。使用iMazing，该过程简单直接，不需要开发人员工具、越狱或其他任何东西。

发现URL方案的其他方法

不喜欢脚本？不用担心。以下是查找iOS应用URL协议的其他方法：

手动检查Info.plist：
- 将.ipa文件重命名为.zip并解压缩。
- 在提取的文件夹中，导航到Payload目录。
- 找到.app文件夹（它将具有应用的名称）。
- 在.app文件夹中，找到Info.plist文件。这是URL方案所在的位置。
- 查找CFBundleURLTypes键。
使用终端命令：
- 使用诸如xmllint或plutil的命令直接提取方案。

命令示例：

1

xmllint –xpath “string(//key[text()=’CFBundleURLTypes’]/following-sibling::array/dict/array/string)” <path_to_Info.plist>

或使用plutil：

1

plutil -p <path_to_Info.plist> | grep -A2 CFBundleURLTypes

检查官方文档：
- 开发人员通常在其API文档中列出URL方案。
询问开发人员：
- 联系应用的开发团队。

Android呢？

Android不使用与iOS相同的方式使用URL方案，但概念是相同的。您需要Android应用的App Bundle ID。要查找应用的包ID，只需访问Google Play商店中的应用页面。包ID包含在页面的URL中。例如，Microsoft OneDrive应用的包ID是com.microsoft.skydrive。

管理例外的最佳实践

最小化例外：仅豁免对组织至关重要的应用。
评估风险：评估每个应用可能泄露数据的潜力。
彻底测试：在非生产环境中验证配置。
教育最终用户：培训员工了解托管应用的工作方式以及数据安全的重要性。

结论

管理MAM策略不仅仅是勾选复选框；它是关于平衡安全性和可用性。无论您使用iOS还是Android，理解数据传输例外都至关重要。借助提供的脚本、替代方法和最佳实践，我希望您现在能够应对这些挑战。

有反馈或想分享您的提示吗？在下方留言或通过GitHub联系。

有用的URL协议

一些银行应用的有用URL协议（主要是荷兰）。这些只是示例。始终确保自己检查它们，因为它们可能会更改。

ABN AMRO: abnamro.nl
KNAB: knab-app;knabapp
Rabobank: Rabobank
ASN: nl-asnbank-ideal
Yoursafe:mylink;bitsafe-app;yoursafe-app
Triodos: triodosmobilebanking
ING: ideal-ing-ng;ing-nl
Van Lanschot: vl-dailybanking
SNS Bank: nl-snsbank-banking;Nl-snsbank-ideal
Revolut: revolut
Regiobank: nl-regiobank-banking;nl-regiobank-ideal
Nationale Nederlanden: nnretailapp
N26: number26
Bunq: bunq
Tikkie: tikkie

iOS MAM策略解析：URL协议与数据传输例外管理

本文深入探讨iOS移动应用管理策略中的数据传输入口例外机制，提供URL协议提取脚本和最佳实践方案，帮助企业平衡安全性与功能性需求。