AWS 构建智能文档处理系统时，权限与敏感数据提取的设计陷阱

KMS 权限没配好简直是噩梦，对着那个 Access Denied 报错调了整整一下午。后来才发现，仅给 Lambda 角色挂 S3FullAccess 并不能解决问题，必须在策略里写明具体的 Bucket ARN 和对象 ARN，例如 "arn:aws:s3:::your-email-bucket" 与 "arn:aws:s3:::your-email-bucket/*"，否则触发事件时仍会被拦截。

DynamoDB 的权限坑确实让人抓狂，403 报错时常让人怀疑自己是否漏掉了什么。不过类似的问题在 S3 触发 Lambda 时也经常遇到，一开始我也给 Lambda 的执行角色挂了 S3FullAccess，结果还是报错。后来才发现，AWS 的权限校验特别细，即使策略看起来全面，如果信任关系没有明确指定触发源（比如 S3 Bucket 的 ARN），或者策略里缺少 Bucket 本身和对象的双重资源声明（比如 "arn:aws:s3:::your-bucket" 和 "arn:aws:s3:::your-bucket/*"），Lambda 依然会被拒绝。解决方案很简单：直接在 IAM 策略里写死具体的 Bucket ARN 和 /* 通配符，确保 ListBucket 和 GetObject 都被明确授权，这样邮件流触发时就不会再出现“Access Denied”。权限配置完整后，下一个坑就是 Textract 的 PII 提取精度了，不过那又是另一回事了。

资源路径没手动加的时候，我对着那行 Access Denied 报错死磕了整整一个下午！在 AWS 上搭建智能文档处理（IDP）系统时，目标是自动分类邮件，并提取其中的 PII（个人敏感信息）。从架构图看，流程不过是 S3 触发 Lambda，再由 Lambda 调用 Textract 提取数据，逻辑很简单；可真正部署到生产环境，权限配置和字段提取精度却会带来很大麻烦。先看 Lambda 的触发权限。很多开发者（我早期也一样）会给 Lambda 的执行角色（Execution Role）挂载 S3FullAccess 策略，以为这样就能覆盖所有访问场景。但当 S3 触发的邮件流被实际读取时，控制台仍会频繁出现 Access Denied 报错。反复排查之后才发现，AWS 的权限校验比预想中更细。即使执行角色已经拥有全局访问权限，如果信任关系（Trust Relationship）没有明确指定触发源，或者策略声明没有精确指向目标 Bucket 及其内部对象，访问依然可能被拦截。更稳妥的做法，是不再依赖大而全的权限组，而是在 JSON 策略中直接写出具体的资源 ARN。推荐的最小权限配置如下：

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::your-email-bucket", "arn:aws:s3:::your-email-bucket/*" ] } ] }

这份配置必须同时包含 Bucket 本身和 Bucket 下的所有对象。前者对应 ListBucket，后者通过 /* 对应 GetObject；如果缺少其中任何一项，处理邮件流触发事件时，Lambda 仍然无法正确读取文件内容。权限问题解决后，另一个难点就出现在 PII 提取精度上。邮件转换成 PDF 后，邮件客户端的渲染差异会让文档布局变得混乱，字段错位十分常见。此时如果直接使用 Textract 的默认分析模式，它会尝试通过坐标或布局分析来识别键值对（Key-Value Pairs），但在混乱布局中，关键信息字段经常发生偏移，最终提取结果完全不可用。尝试过多种方案后，最有效的优化方式是放弃对布局分析的依赖，改为强制开启 QUERIES 功能。Textract 默认模式为何容易导致字段错位？调用 Textract 接口时，不能指望它自动完成表格对齐或固定位置识别，而应该传入具体的自然语言问题，例如： `"What is the customer's phone number