经过仔细考虑，我们决定停用适用于 SQL 应用程序的亚马逊 Kinesis 数据分析：

1. 从 2025 年 ** 9 月 1 日起**，我们将不再为适用于 SQL 应用程序的 Amazon Kinesis 数据分析提供任何错误修复，因为鉴于即将停产，我们对它的支持将有限。

2. 从 2025 年 ** 10 月 15 日起**，您将无法为 SQL 应用程序创建新的 Kinesis 数据分析。

3. 从 **2026 年 1 月 27 日**起，我们将删除您的应用程序。您将无法启动或操作 Amazon Kinesis Data Analytics for SQL 应用程序。从那时起，将不再提供对 Amazon Kinesis Data Analytics for SQL 的支持。有关更多信息，请参阅 [Amazon Kinesis Data Analytics for SQL 应用程序停用](discontinuation.md)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Cross-service 困惑的副手预防
<a name="iam-cross-service-confused-deputy-prevention"></a>

在中 Amazon，当一项服务（呼叫服务）调用另一项服务（被叫服务）时，可能会发生跨服务模拟。尽管调用服务不应具有适当的权限，但仍可操纵以对另一个客户的资源进行操作，这会导致代理混淆。

为防止代表们感到困惑， Amazon 提供工具来帮助您使用有权访问您账户中资源的服务主体保护所有服务的数据。本节重点介绍的是 Kinesis Data Analytics 特有的跨服务混淆代理人问题防范功能，您可以在 *IAM 用户指南*的[混淆代理人问题](https://docs.amazonaws.cn/IAM/latest/UserGuide/confused-deputy.html)部分了解更多相关信息。

在 Kinesis Data Analytics for SQL 的背景下，我们建议在角色信任策略中使用 a [ ws: SourceArn [ 和 aws: SourceAccount ](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) 全局条件上下文密钥，将对角色的访问权限限制为仅限由预期资源生成的请求。](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)

如果您只希望将一个资源与跨服务访问相关联，请使用。`aws:SourceArn`如果您想允许该账户中的任何资源与跨服务使用操作相关联，请使用。`aws:SourceAccount`

`aws:SourceArn` 的值必须是 Kinesis Data Analytics 使用资源的 ARN，其指定格式为：`arn:aws:kinesisanalytics:region:account:resource`。

防范混淆代理问题的建议方法是使用 `aws:SourceArn` 全局条件上下文键和资源的完整 ARN。

如果不知道资源的完整 ARN，或者正在指定多个资源，请针对 ARN 未知部分使用带有通配符 (\*) 的 `aws:SourceArn` 键。例如：`arn:aws:kinesisanalytics::111122223333:*`。

尽管 Kinesis Data Analytics for SQL API 中的大多数操作（例如[CreateApplication](https://docs.amazonaws.cn/kinesisanalytics/latest/dev/API_CreateApplication.html)[AddApplicationInput](https://docs.amazonaws.cn/kinesisanalytics/latest/dev/API_AddApplicationInput.html)和）[DeleteApplication](https://docs.amazonaws.cn/kinesisanalytics/latest/dev/API_DeleteApplication.html)都是在特定应用程序的上下文中执行的，但该[DiscoverInputSchema](https://docs.amazonaws.cn/kinesisanalytics/latest/dev/API_DiscoverInputSchema.html)操作不会在任何应用程序的上下文中执行。这意味着此操作中使用的角色不得在 `SourceArn` 条件键中完全指定资源。以下是使用通配符 ARN 的示例：

```
{
   ...
   "ArnLike":{
      "aws:SourceArn":"arn:aws:kinesisanalytics:us-east-1:123456789012:*"
   }
   ...
}
```

Kinesis Data Analytics for SQL 生成的默认角色使用此通配符。这可确保控制台发现输入架构的无缝体验。但是，建议在发现架构后编辑信任策略，从而使用完整 ARN，充分缓解混淆代理人问题。

您向 Kinesis 数据分析提供的角色策略以及为您生成的角色的信任策略可以使用 aws: SourceArn [ 和 [ a ](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) ws: SourceAccount ](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) 条件密钥。

为了防止出现代理混淆的问题，请执行以下步骤：

**防止出现代理混淆问题**

1. 登录 Amazon 管理控制台并在上打开 IAM 控制台[https://console.aws.amazon.com/iam/](https://console.amazonaws.cn/iam/)。

1. 选择**角色**，然后选择要修改的角色。

1. 选择**编辑信任策略**。

1. 在**编辑信任策略**页面上，将默认 JSON 策略替换为使用 `aws:SourceArn` 和 `aws:SourceAccount` 全局条件上下文密钥中的一个或两个的策略。请参阅以下示例策略：

1. 选择**更新策略**。

------
#### [ JSON ]

****  

   ```
   {
      "Version":"2012-10-17",		 	 	 
      "Statement":[
         {
            "Effect":"Allow",
            "Principal":{
               "Service":"kinesisanalytics.amazonaws.com"
            },
            "Action":"sts:AssumeRole",
            "Condition":{
               "StringEquals":{
                  "aws:SourceAccount":"Account ID"
               },
               "ArnEquals":{
                  "aws:SourceArn":"arn:aws:kinesisanalytics:us-east-1:123456789012:application/my-app"
               }
            }
         }
      ]
   }
   ```

------