发布于: Nov 30, 2022
【概要】随着 Amazon Web Services 不断推出更多激动人心的全新机器学习服务，Amazon FGBS 团队也期待不断增强这套解决方案，运用现代化、自动化成果逐步取代传统财会工作用例。
数据安全防护技术一直以来都是人们关注的焦点，在信息化时代，我们的个人信息都被数字化，经常面临着信息泄露等一系列安全问题。对于企业而言，信息的泄露更是会导致不可估量的损失，如何保护自己的信息安全呢？Amazon Web Services 为您提供了一套方案。
下图所示，为自定义 Web 用户界面（UI）与报告架构：
为了与提取到的合约数据进行有效交互，团队构建了一套自定义 Web UI。使用 Angular v8 框架构建的 Web 应用程序通过 Amazon S3 托管在云内容交付网络 Amazon CloudFront 上。当访问 Amazon CloudFront URL 时，我们首无使用具有严格权限约束的用户池对用户进行授权及身份验证，借此判断其是否有权查看此 UI 并与之交互。在完成验证之后，会话信息将被保存下来，确保用户仅在设定的时段之内保持登录状态。
在登陆页面上，用户可以通过链接导航至面板上显示的三套关键用户方案处：
- Search for Records – 查看并编辑合约记录
- View Record History – 查看合约记录的历史编辑记录
- Appstream Reports – 打开 Appstream 托管的报告仪表板
要查看特定记录，系统会提示用户使用特定的客户名称或文件名称进行文件搜索。在使用前一种方式时，搜索将返回具有相同客户名称的各份合约的最新记录。对于后一种方式，搜索将仅返回具有 该文件名的特定合约的最新记录。
在用户找到需要检查或编辑的正确合约之后，即可选定其文件名称并跳转至 Edit Record 页面。系统将显示合约条款的完整列表，并允许用户编辑、添加或删除这些提取自合约的信息。您可以使用不同的术语从表单字段中检索最新记录，选择不同的值为验证数据；如果发现错误，则及时编辑数据。用户还可以选择 Add New Field 并为自定义术语输入键-值对来添加新的字段。
使用编辑或新的字段更新条目之后，用户可以选择 Update Item 按钮。这项操作将触发使用 POST 方法把新记录的数据从前端通过 Amazon API Gateway 传递至 PostFromDynamoDB 函数的过程，生成一个 JSON 文件，此文件将被推送至保存全部已提取到的术语数据的 S3 存储桶内。该文件触发相同的 UpdateDynamoDB 函数，此函数会在第一次 Amazon Textract 处理运行之后将原始术语数据推送至 DynamoDB 表。
验证完成之后，用户可以选择 Delete Record，借此通过统一删除 DynamoDB 以及存储到S3存储桶内所有已提取到的各合约版本中的数据。这项操作由 DELETE 方法所启动，将触发用于删除数据的 DeleteFromDynamoDB 函数。在合约数据验证及编辑期间，对于推送字段的每一次更新都会创建一条新的数据记录。此记录将根据登录配置文件自动记录时间戳与用户身份，借此确保对历史编辑记录进行细粒度跟踪。
要发挥编辑跟踪的作用，用户可以搜索合约并查看合约中全部记录的集合（按时间戳排序）。以此为基础，用户可以快速比较跨时间段进行的编辑操作，包括添加任何自定义字段，并将这些编辑链接回编辑器标记。
为了确保团队能够从这套解决方案中实现业务价值，他们还向架构当中添加了报告仪表板管道。报告应用程序实例由完全托管应用程序流服务 Amazon AppStream 2.0 负责托管。Amazon Glue 爬取器则为 Amazon S3 中的数据建立 schema，并由 Amazon Athena 查询并将数据加载至 Amazon AppStream 实例与报告应用程序当中。
考虑到这部分数据对于 Amazon 而言相当敏感，我们的团队还纳入了不少安全考量，确保能够安全地与数据进行交互，同时严格阻断未授权第三方的访问。Amazon Cognito 授权程序负责保护 API Gateway 的安全。在用户登录期间，将由采用双因素身份验证的 Amazon 内部单点登录机制对申请访问 Amazon Cognito 用户池的团队成员进行验证。
要查看历史记录，用户可以搜索合约并检查单一合约的完整记录集合，快速查看一切错误或可疑的编辑结果，并准确追溯编辑时间与编辑者身份。
该团队还采用其他应用程序强化步骤，用以保护架构及前端。请确保根据最低权限原则缩小 Amazon Web Services 角色与策略的应用范围。对于 Amazon S3 与 DynamoDB 等存储位置，一切访问将默认被阻断，通过启用服务器端加密以实现静态加密，同时提供版本控制与日志记录功能。对于传输数据加密，Amazon PrivateLink 支持的 VPC 接口端点将各 Amazon Web Services 服务连接起来，确保数据只通过 Amazon Web Services 私有端点（而非公共互联网）进行往来传输。在一切 Lambda 函数中，全面使用 Python 临时文件库以应对时间攻击（TOCTOU），由此遵循临时数据处理方面的最佳实践。顺带一提，所谓时间攻击，是指攻击者抢先将文件放置在指定位置，以时间差的方式完成入侵目标。由于 Lambda 属于无服务器服务，因此在调用 Lambda 函数之后，存储在临时目录中的所有数据都将被删除，除非用户明确要求将数据推送至另一存储位置（例如 Amazon S3）。
客户数据隐私一直是 Amazon FGBS 团队乃至整个 Amazon Web Services 服务团队的头等大事。虽然在 Amazon Textract 及 Amazon Comprehend 等 Amazon Web Services 服务中合并其他训练数据，能够显著提高机器学习模型的最终性能，但大家请务必保持严格的数据保留限制。为了防止将 Amazon Textract 与 Amazon Comprehend 生成的合约数据存储下来供后续模型训练，Amazon FGBS 团队建立起客户数据清退机制以及时清理客户数据。
为了在处理特定敏感数据时验证应用程序的完整性，团队还执行了内部安全检查与来自外部供应商的渗透测试。其中包含动态代码审查、动态模糊测试、表单验证、脚本注入与跨站点脚本（XSS），并针对 OWASP 十大 Web 应用程序安全风险做出响应。为了解决分布式拒绝服务（DDoS）攻击，团队在 API Gateway 上设置了限制，并使用 CloudWatch 警报对调用阈值限值加以监控。
将安全要求整合至应用程序当中，整个解决方案即可被编入 Amazon CloudFormation 模板，而后将解决方案交付至团队的实际生产流程内。CloudFormation 模板将多个嵌套栈组成，其中描述了应用程序基础设施中的各关键组件（前端服务与后端服务）。使用 Amazon CodeBUIld 设置的持续部署管道，帮助团队及时构建并部署指向应用程序代码或基础设施的一切更改。开发及生产环境在两个相互独立的 Amazon Web Services 账户当中创建，并通过在相应账户中设置的环境变量来管理两套环境的具体部署。
这款应用程序现已上线，而且每月通过成百上千份合约进行测试。最重要的是，该团队已经切实体会到业务流程自动化所带来的时间节约与价值提升效益。
Amazon ProServe 团队目前正与 Amazon FGBS 团队合作推进项目的第二阶段，旨在进一步增强这套解决方案。为了提高术语提取的准确性，他们尝试使用经过预训练及定制化设计的 Amazon Comprehend NER 模型。他们将建立起重新训练管道，确保平台智能可以随着时间推移与新数据的供给实现改进。他们还考虑引入 Amazon Augmented AI（Amazon A2I）这一新服务，利用其中的 AI 代码审查功能发现低置信度 Amazon Textract 输出结果，并生成新的训练数据以持续改进模型。
随着 Amazon Web Services 不断推出更多激动人心的全新机器学习服务，Amazon FGBS 团队也期待不断增强这套解决方案，运用现代化、自动化成果逐步取代传统财会工作用例。
相关文章