一、跨账号共享AWS IoT Core资源的核心逻辑
不少做物联网项目的开发者都会遇到这样的问题：比如一家连锁品牌，总部的技术部门在AWS主账号里搭了一套IoT Core的基础服务，用来统一管理全国门店的设备、收集设备数据；但各个区域的运营团队有自己的AWS子账号，需要独立查看自己区域门店的设备状态、调取对应的数据，同时又不想重复搭建一套IoT Core服务——既浪费钱，又难统一管理。
跨账号共享AWS IoT Core资源，本质就是解决“多个独立的AWS账号，如何共用一套IoT Core的核心资源，同时还能保证权限隔离、数据安全”的问题。最常用的实现方式是基于AWS的资源策略（Resource Policy），这种方式不需要复杂的账号绑定或跨账号角色切换，只要给IoT Core的核心资源配置对应的策略，就能精准控制不同账号的访问权限。
1.1 什么是AWS资源策略
AWS资源策略是一种附加在具体资源上的权限规则，和IAM（身份与访问管理）策略不同，IAM策略是“谁能访问”的规则，而资源策略是“这个资源允许谁访问”的规则。举个简单的例子：IAM策略就像小区门口的保安，只查你有没有进小区的权限；而资源策略就像你家大门的锁，只允许特定的人（比如家人、物业）进你家，哪怕你有进小区的权限，没有你家的钥匙也进不去。
对于IoT Core的资源来说，资源策略可以直接附加在设备影子（Device Shadow）、规则引擎（Rule Engine）、主题（Topic）这些核心组件上，精准控制哪些账号、哪些操作可以被允许。
1.2 跨账号共享的核心前提
要实现跨账号共享，首先需要确认几个基础条件：第一，所有参与的AWS账号必须是同一个组织（Organization）下的成员账号，或者已经完成了跨账号信任配置；第二，主账号（拥有IoT Core资源的账号）需要明确每个子账号的访问范围，比如子账号A只能访问主题前缀为store/a/的消息，子账号B只能访问store/b/的；第三，所有账号的区域要一致，比如主账号的IoT Core服务部署在us-east-1区域，子账号的访问请求也必须从us-east-1区域发起。
二、基于资源策略的跨账户设备管理与数据访问实现
接下来我们用一个完整的示例，一步步实现跨账号共享IoT Core资源的功能。本次示例统一使用AWS CLI（命令行工具）作为技术栈，所有操作都可以通过命令行完成，不需要登录AWS控制台。
2.1 示例场景说明
我们设定两个账号：主账号（账号ID：123456789012），负责部署IoT Core核心服务，拥有所有设备的管理权；子账号（账号ID：987654321098），需要实现两个功能：1、管理自己区域的设备（比如查询设备影子、更新设备状态）；2、访问自己区域的设备数据主题（比如store/region1/data/#）。
2.2 技术栈说明
本次示例使用的技术栈为：AWS CLI（命令行工具），版本要求为2.0以上。所有操作都基于AWS CLI完成，需要提前配置好主账号和子账号的CLI凭证。
2.3 主账号配置资源策略
首先，主账号需要给IoT Core的核心资源配置资源策略，允许子账号的访问请求。我们先配置设备影子的资源策略，允许子账号查询和更新自己区域的设备影子。
2.3.1 配置设备影子资源策略
设备影子是IoT Core中用来存储设备状态的核心组件，我们给主账号的设备影子配置资源策略，允许子账号（987654321098）访问前缀为region1/的设备影子。
# 主账号执行：配置设备影子资源策略，允许子账号987654321098访问前缀为region1/的设备影子
aws iot create-resource-policy \
--policy-name "cross-account-device-shadow-policy" \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::987654321098:root" # 子账号的根用户ARN
},
"Action": [
"iot:GetThingShadow", # 允许查询设备影子
"iot:UpdateThingShadow" # 允许更新设备影子
],
"Resource": "arn:aws:iot:us-east-1:123456789012:thing/region1/*" # 主账号的设备影子ARN，前缀为region1/
}
]
}' \
--region us-east-1
2.3.2 配置主题资源策略
接下来，我们给IoT Core的主题配置资源策略，允许子账号访问自己区域的设备数据主题store/region1/data/#。
# 主账号执行：配置主题资源策略，允许子账号987654321098订阅和发布store/region1/data/#主题
aws iot create-resource-policy \
--policy-name "cross-account-topic-policy" \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::987654321098:root" # 子账号的根用户ARN
},
"Action": [
"iot:Subscribe", # 允许订阅主题
"iot:Publish" # 允许发布主题
],
"Resource": "arn:aws:iot:us-east-1:123456789012:topic/store/region1/data/#" # 主账号的主题ARN
}
]
}' \
--region us-east-1
2.4 子账号配置IAM权限
主账号配置完资源策略后，子账号还需要配置自己的IAM权限，允许自己的用户或角色访问主账号的IoT Core资源。这里我们给子账号的一个IAM用户（用户名：region1-admin）配置权限，允许其访问主账号的IoT Core资源。
# 子账号执行：创建IAM权限策略，允许访问主账号的IoT Core资源
aws iam create-policy \
--policy-name "cross-account-iot-access-policy" \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iot:GetThingShadow",
"iot:UpdateThingShadow",
"iot:Subscribe",
"iot:Publish"
],
"Resource": [
"arn:aws:iot:us-east-1:123456789012:thing/region1/*", # 主账号的设备影子ARN
"arn:aws:iot:us-east-1:123456789012:topic/store/region1/data/#" # 主账号的主题ARN
]
}
]
}' \
--region us-east-1
然后，将这个权限策略附加到子账号的IAM用户region1-admin上：
# 子账号执行：将权限策略附加到IAM用户region1-admin
aws iam attach-user-policy \
--user-name region1-admin \
--policy-arn arn:aws:iam::987654321098:policy/cross-account-iot-access-policy \
--region us-east-1
2.5 验证跨账号访问效果
配置完成后，我们用子账号的region1-admin用户验证访问效果。首先，查询主账号的设备影子：
# 子账号执行：查询主账号的region1-device-1设备影子
aws iot get-thing-shadow \
--thing-name region1-device-1 \
--region us-east-1
如果配置正确，会返回设备影子的状态信息；如果配置错误，会返回权限不足的错误。
然后，订阅主账号的主题：
# 子账号执行：订阅主账号的store/region1/data/#主题
aws iot subscribe-topic \
--topic store/region1/data/# \
--region us-east-1
如果配置正确，会返回订阅成功的信息，之后主账号的设备发布到这个主题的消息，子账号可以正常接收。
三、核心技术的优缺点分析
3.1 优点
基于资源策略的跨账号共享方式，有几个明显的优点：第一，配置简单，不需要复杂的跨账号角色切换或账号绑定，只要配置资源策略和IAM权限就能实现；第二，权限隔离性好，主账号可以精准控制每个子账号的访问范围，比如不同区域的子账号只能访问自己区域的资源，不会互相干扰；第三，维护成本低，所有核心资源都在主账号管理，子账号只需要配置自己的IAM权限，不需要重复搭建IoT Core服务，节省了时间和成本；第四，兼容性好，支持所有IoT Core的核心资源，包括设备影子、主题、规则引擎、证书等。
3.2 缺点
这种方式也有一些局限性：第一，依赖AWS组织架构，如果子账号不在同一个组织下，需要额外配置跨账号信任，增加了复杂度；第二，权限粒度有限，资源策略的权限是基于资源的，无法实现更细粒度的权限控制，比如同一个设备影子的不同属性，无法给不同子账号分配不同的权限；第三，排查问题复杂，如果跨账号访问出现权限问题，需要同时检查主账号的资源策略和子账号的IAM权限，排查难度比单账号高；第四，不支持动态权限，如果子账号的访问范围需要频繁调整，需要频繁修改资源策略，维护成本会增加。
四、注意事项
在实际使用中，需要注意几个关键点：第一，权限最小化原则，主账号给子账号配置资源策略时，只允许子账号访问必要的资源和操作，不要给多余的权限，比如不要允许子账号访问主账号的所有设备影子，只允许访问自己区域的；第二，定期审计权限，定期检查主账号的资源策略和子账号的IAM权限，及时清理不必要的权限，避免权限泄露；第三，区域一致性，所有账号的操作区域必须一致，否则会出现访问失败的问题；第四，账号安全，主账号的资源策略不要直接允许子账号的根用户访问，最好给子账号的IAM角色或用户配置权限，避免根用户权限过大带来的安全风险；第五，测试验证，在正式环境配置之前，先在测试环境验证配置的正确性，避免影响正式环境的业务。
五、应用场景
基于资源策略的跨账号共享方式，适合很多实际的业务场景：第一，连锁企业的物联网管理，比如连锁超市、连锁酒店，总部在主账号管理所有设备，各个区域的运营团队在子账号管理自己区域的设备；第二，物联网平台的多租户服务，比如一个物联网平台服务商，给多个客户提供IoT Core服务，每个客户有自己的子账号，服务商在主账号管理所有核心资源；第三，企业内部的多部门管理，比如一个企业的技术部门在主账号管理IoT Core服务，市场部门、运营部门在子账号访问自己需要的设备数据；第四，跨企业的物联网合作，比如两个企业合作开发一个物联网项目，其中一个企业负责搭建IoT Core服务，另一个企业负责管理自己的设备，通过跨账号共享实现资源共用。
六、文章总结
基于资源策略的跨账号共享AWS IoT Core资源，是一种简单、高效、安全的跨账号管理方式，解决了多个账号共用IoT Core资源的问题，同时保证了权限隔离和数据安全。通过配置主账号的资源策略和子账号的IAM权限，就能实现精准的跨账号访问控制，适合连锁企业、多租户平台、多部门管理等多种场景。在实际使用中，需要注意权限最小化、定期审计、区域一致性等问题，避免出现权限泄露或访问失败的问题。
Comments