亚马逊AWS官方博客

利用 Amazon Lex，您现在能够以 JSON 文件形式导出 Amazon Lex 聊天自动程序定义，以便能够将其添加到 Alexa Skills Kit (ASK)。在将该自动程序架构文件添加到 ASK 中后，您可以使用它构建 Alexa 技能，以便在 Amazon Echo、Amazon Dot、Amazon Look、Amazon Tap、Amazon Echo Show 和支持 Alexa 的第三方设备上使用。JSON 配置文件包含您的 Amazon Lex 聊天自动程序的结构，包括带表达、槽、提示和槽类型的目的架构。导出功能简化了通过 Amazon Lex 聊天自动程序创建 Alexa 技能的过程。

要创建 Alexa 技能，您可以从 ASK 门户中使用 Amazon Lex 自动程序定义文件，并执行以下步骤。

在 Amazon Lex 控制台中

在创建、构建并发布您的自动程序后，导航回包含您目前已开发的自动程序的列表的页面。
使用单选按钮选择要导出的自动程序。选择自动程序后，页面顶部的 Actions 选项卡将变为有效的。
在 Actions 选项卡中，从下拉菜单项中选择 Export，然后在模态对话框中，选择 Alexa Skills Kit 作为您的平台，然后选择版本。
单击 Create。这将生成一个 zip 文件，其中包含您的自动程序架构的 JSON 文件。

您的 Amazon Lex 自动程序架构现已能够在 Amazon Alexa 技能中使用！

(more…)

将 Amazon Lex 自动程序架构导出至 Alexa Skills Kit

您现在可以将 Amazon Lex 聊天自动程序架构导出到 Alexa Skills Kit 来简化创建 Alexa 技能的流程。

要创建 Alexa 技能，您可以从 ASK 门户中使用 Amazon Lex 自动程序定义文件，并执行以下步骤。

在 Amazon Lex 控制台中

在创建、构建并发布您的自动程序后，导航回包含您目前已开发的自动程序的列表的页面。
使用单选按钮选择要导出的自动程序。选择自动程序后，页面顶部的 Actions 选项卡将变为有效的。
在 Actions 选项卡中，从下拉菜单项中选择 Export，然后在模态对话框中，选择 Alexa Skills Kit 作为您的平台，然后选择版本。
单击 Create。这将生成一个 zip 文件，其中包含您的自动程序架构的 JSON 文件。

您的 Amazon Lex 自动程序架构现已能够在 Amazon Alexa 技能中使用！

(more…)

Certification Vending Machine: 智能设备接入AWS IoT平台解决方案

作者：刘洪曦谢佰臻

背景介绍

AWS IoT平台为了保证终端设备通信的安全性，终端设备与 AWS IoT平台的MQTT通信使用基于证书的TLS 1.2双向认证体系。即IoT平台会验证当前设备使用的证书是否可信，同时，终端设备也会验证IoT平台使用的CA证书是否可信。

这种双向TLS验证模式就会要求设备上所使用的证书需要具备以下条件之一：

IoT终端设备上所使用的证书为AWS IoT平台所签发的
IoT终端设备上所使用的证书的CA证书预先导入了AWS IoT平台

所以开发者应该尽量确保每个设备上在出厂前，为每个设备写入独立的证书，并要求该证书为IoT平台所信任的证书。这种方式也是最安全高效的。

何时应当使用 Certificate Vending Machine？

对于部分已经生产出厂的IoT设备，可能在生产过程中没有预装IoT证书，但是又希望这些设备连接至AWS IoT平台。此时，Certificate Vending Machine (简称CVM) 可以作为给终端设备写入IoT证书的可行方案，让设备自行向IoT平台申请CA签发的授信证书，并且通过AWS IoT管理平台控制证书权限，确保物联网通信安全。

通过此项目的设计思想和相关源码，开发者可以快速开发出符合自己项目需求的CVM系统。但是需要注意，由于原设备没有IoT证书进行TLS双向认证，所以进行CVM的过程中需要注意三点：

IoT设备与CVM系统通信时，原生并没有安全保护手段，所以需要在受信的DNS环境下进行，以防中间人攻击。或者采用其他安全链接的方式，例如使用HTTPS与CVM 服务器交互。
IoT设备在利用CVM系统申请证书时，由于不具备用于标识设备的证书，所以IoT设备本身应该具备唯一标识符用于设备的身份标识，例如序列号，client ID或者product ID等，通过该身份标识进行证书申请及策略绑定。
所有通过CVM系统申请获发的证书的跟证书，均为AWS IoT平台默认使用的CA根证书。如果需要使用自定义的CA跟证书，请参考JITR证书认证方式。

CVM实现原理

整个项目实现可以分为三个模块： IoT设备端、CVM 系统和AWS IoT 平台

A.智能设备端

通过Https 请求证书
请求时携带设备序列号以及密钥

B. CVM 系统

用于向IoT设备提供远程访问接口。
CVM系统作为代理向IoT平台申请每一个IoT设备的安全证书
校验请求合法性：通过校验请求的信息与数据库是否一致再决定是否为当前IoT设备申请证书， CVM使用内部Node.js 语言实现
使用了AWS 高性能的NoSQL数据库DynamoDB做为后台用户数据库。该数据库用来保存智能设备出厂时注册的设备ID、密钥和IoT平台证书等信息
CVM系统通过查询DynamoDB数据中的关联关系，将IoT Thing Name，Certificate Policy以及Certificate ID关联至一起。同时，修改DynamoDB里的证书状态attribute，避免同一台设备遭到攻击后，重复向IoT平台大量申请证书的可能性，从而保证证书与设备的唯一性。

CVM系统的基本工作流程如下:

CVM系统的具体架构如下：

为了使CVM服务端更具稳定与扩展性，可以使用AWS API Gateway 和Lambda 来部署CVM。通过这种方式，不需要长时间维护和管理部署于EC2的CVM，而是通过IoT终端设备的证书申请的需求，灵活的调配AWS上的服务资源。

具体如下:

IoT终端设备升级时请求接入IoT平台，发送相应API 请求到API Gateway申请IoT 证书
AWS API Gateway调用申请证书的Lambda向IoT平台发起证书申请
Lambda接收到请求后，查询DynamoDB校验请求合法性
确认当前请求合法之后，通过API的形式，向IoT平台申请证书
IoT平台返回当前IoT终端设备对应的证书，以及当前证书的certificate ID
通过查找DynamoDB中预先创建的对应关系，根据产品序列号，为当前申请到的证书附加对应的Thing Name（产品属性）以及Policy（权限）
Lambda进行证书的策略的绑定及DynamoDB关联关系表的更新
最终CVM将证书返回给IoT终端设备

使用EC2 替代API Gateway与Lambda的解决方案，其工作流程与搭建lambda的模式基本一致，仅在IoT终端设备与CVM系统通信时的调用关系上有所区别

IoT终端设备升级时请求接入IoT平台，向CVM Server申请IoT 证书
EC2接收到请求后，访问Device DB 校验请求合法性
CVM Server通过API的形式，向IoT平台发起获取IoT安全证书的请求
IoT平台返回当前IoT终端设备对应的证书，以及当前证书的certificate ID
通过查找DynamoDB中预先创建的对应关系，根据产品序列号，为当前证书附加对应的Thing Name（产品属性）以及Policy（权限）
更新当前设备的所有关联信息到DynamoDB的关联关系表中
CVM将证书返回给IoT终端设备

安全性说明

为了保证CVM系统的安全性，EC2 或者Lambda 函数需要赋予合适的IAM 角色，使得CVM系统只能进行其授予的工作权限，以下用lambda举例如何为CVM系统分配正确的IAM角色权限。

首先，需要明确CVM系统需要具备一下IAM权限才能完整证书的申请及颁发过程:

访问AWS DynamoDB，用于查询、修改、更新DynamoDB中的设备关联表
访问IoT 平台，用于申请IoT终端设备证书

除IAM进行权限划分之外，需要在DynamoDB上创建一张关联关系表，用于设备与证书及策略的绑定关系，具体来说，需要在DynamoDB中创建如下数据库字段:

productid : 智能设备ID
accessToken: 智能设备Token
timestamp : 证书申请时间戳
applyState : 申请状态（如果申请过证书设置为-1，标记此设备已经注册过证书了）
certID : 设备关联的证书ID

核心代码说明

以下的CVM server代码使用了 AWS Node.js SDK 提供的IOT接口完成证书申请以及附加对用的thingName和Policy。

//使用createKeysAndCertificate 接口创建证书，此接口返回创建后的证书ID以及证书

iot.createKeysAndCertificate (params = {}, callback) ⇒ AWS.Request

# 如果需要使用CSR进行证书生成，可以使用以下接口

# iot.createCertificateFromCsr(params = {}, callback) ⇒ AWS.Request

//为证书附加策略，传入上述接口返回的证书ID

iot.attachPrincipalPolicy(params = {}, callback) ⇒ AWS.Request

//为证书添加thing，同样是传入上述返回的证书ID

iot.attachThingPrincipal(params = {}, callback) ⇒ AWS.Request

CVM系统服务器端源码（EC2）：

https://github.com/cncoder/cvm/tree/master/server

CVM系统服务器端源码（Lambda）：

https://github.com/cncoder/cvm/tree/serverless/server

智能设备端源码：

https://github.com/cncoder/cvm/tree/serverless/device

参考链接

http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Iot.html

作者介绍：

刘洪曦，AWS解决方案架构师，负责基于AWS的云计算方案架构的咨询和设计，同时致力于帮助海外企业在AWS云服务的应用和推广。在加入AWS之前曾在思科担任网络顾问工程师，负责亚太区域物联网及安全业务的拓展及架构设计，在物联网，数据安全，网络架构有丰富部署实践经验。

谢佰臻，亚马逊AWS解决方案架构师实习生，擅长网站架设与网络应用开发，熟悉使用Node.js、Html5、Mysql数据库，对于Serverless 架构有自己的理解和实践经验。

新功能 – EC2 实例和 EBS 卷的每秒计费功能

在过去，如果您需要使用计算能力，则需要购买或租用服务器。当我们在 2006 年推出 EC2 时，使用一个实例一个小时只需支付一小时的费用是头条新闻。即付即用模式激励我们的客户思考开发、测试和运行所有类型的应用程序的新方法。

如今，AWS Lambda 等服务证明我们可以在短时间内完成大量有用的工作。我们的许多客户都在设计适用于 EC2 的应用程序，以便能够在更短的时间内（有时仅为几分钟）充分利用大量实例。

EC2 和 EBS 的每秒计费
于 10 月 2 日开始生效，以按需、预留和竞价形式发布的 Linux 实例的使用将按 1 秒的增量计费。同样，EBS 卷的预置存储也将按 1 秒的增量计费。

每秒计费功能也适用于 Amazon EMR 和 AWS Batch：

Amazon EMR – 我们的客户增加了其 EMR 群集的容量以更快地获得结果。借助适用于群集中的 EC2 实例的每秒计费功能，添加节点要比以往任何时候都更经济高效。

AWS Batch – 我们的客户运行的许多批处理作业在 1 小时内即可完成。AWS Batch 已启动和终止竞价型实例；利用每秒计费功能，批处理将变得更划算。

我们的一些更精明的客户已构建系统，通过在管理其游戏、广告技术或 3D 渲染队列时战略性地选择最有利的目标实例来从 EC2 中获得最大价值。每秒计费功能消除了这种额外的实例管理层的需要，并实现了所有客户和所有工作负载的成本节省。

虽然这将导致许多工作负载的价格降低（您知道我们喜欢降价），但我认为这并不是此改变的最重要方面。我相信，这种改变将激励您进行创新并以新的方式思考您的受计算限制的问题。您如何利用这一点来增强对持续集成的支持？这是否能改变您为开发和测试工作负载预置瞬态环境的方式？您的分析、批处理和 3D 渲染将会怎么样？

云计算的许多优势之一是，在您需要时预置或取消预置资源的弹性特性。通过对使用量每秒计费，我们使客户能够提高其弹性、节省资金，并且客户将被定位以利用计算中的持续改进。

需知信息
此更改在所有 AWS 区域中都是有效的，并且将于 10 月 2 日开始生效，适用于新发布的或已经运行的所有 Linux 实例。每秒计费功能目前不适用于运行 Microsoft Windows 或 Linux 发行版的实例，后者已按小时单独计费。每个实例均最少有 1 分钟计费。

列表价格和竞价市场价格仍按每小时列出，但计费单位下调至秒，预留实例使用量也按秒计算（您可以在 1 个小时内启动、使用和终止多个实例并获得所有实例的预留实例优势）。此外，账单将以十进制格式显示次数，如下所示：

AWS Marketplace 中的区域专用费、EBS 快照和产品仍按小时计费。

— Jeff；

AWS Deep Learning AMI 现在包含 Apache MXNet 0.11 和 TensorFlow 1.3

AWS Deep Learning Amazon 系统映像 (AMI) 旨在帮助您在 AWS 上构建稳定、安全且可扩展的深度学习应用程序。AMI 预安装了常用的深度学习框架，具有 GPU 驱动程序和库，让您可以训练复杂的 AI 模型并在云中进行扩展。

最新版 AWS Deep Learning AMI 可用于 Ubuntu 和 Amazon Linux 平台。AMI 中包括多项更新，其中最引人注目的是支持 Keras 的 MXNet 0.11。MXNet 现可作为运行 Keras 1.2 的用户的后端选择。利用 MXNet，Keras 用户可以轻松设置多 GPU 以实现训练和近线性扩展的出色性能。要了解有关使用 MXNet 作为 Keras 后端的好处的更多信息，请参阅 NVIDIA 的博客。AMI 现在还可与最新版 TensorFlow (1.3.0 版) 一起运行。

使用 AMI 进行入门可谓轻松快捷。按照此分步指南进行操作，在几分钟内便可开始深度学习。

以下是 AMI 上的深度学习框架和 GPU 驱动程序的完整列表 (同时适用于 Ubuntu 和 Amazon Linux 版本)：

MXNet 0.11.0
TensorFlow 1.3.0
Keras 1.2.2 (DMLC 复制，具有 MXNet 0.11 支持)
Caffe1.0
Caffe2 0.8.0
CNTK 2.0
Theano 0.9.0
Torch (主分支)
CUDA Toolkit 8.0
cuDNN 5.1
NVIDIA Driver 375.66

您可以在 AWS Marketplace 上找到 AMI for Ubuntu 和 Amazon Linux。

如何使用Amazon Macie 进行安全数据自动分类和用户行为监控

概述

当我们在Amazon S3中存储大量内容时，识别和分类其中潜在敏感数据可能会有点像在一个非常大的干草堆中找绣花针针，整个的过程是非常低效。那么能否有一种工具可以在数据加入到S3后就自动的识别敏感信息并自动进行分类？

同时在我们日常的工作中，访问数据的时间间隔及物理位置相对的固定。如果发生异常的事件，例如原来某个用户一天访问一到两个文件，但如果突然在某天访问超过一百个文件，能否由系统发出告警事件提醒相关人员进行相关检查，确保安全？

本文从如下几部分介绍Amazon Macie服务及主要功能，同时还列出常见使用场景，以及如何配置的简要步骤。希望能给大家带来帮助。

什么是Macie

Amazon Macie 是一种支持人工智能技术的安全服务，可以帮助您通过自动发现、分类和保护存储在 AWS 中的敏感数据来防止数据丢失。Amazon Macie 使用机器学习来识别敏感数据 (例如,个人身份信息 [PII] 或知识产权)，分配业务价值，提供此数据的存储位置信息及其在组织中的使用方式信息。

Amazon Macie 可持续监控数据访问活动异常，并在检测到未经授权的访问或意外数据泄漏风险时发出警报。

为什么要使用Macie

对现存的海量文件进行自动的分类并且根据不同的分类制定不同的监控策略，一旦发生异常的访问需要得到及时的告警，是每个组织面临的挑战。

Amazon Macie提供了简单高效并且安全的方案，Macie通过使用机器学习来了解存储的内容和用户行为，同时提供可视化界面，展示安全分类，从而使客户能够专注于保护敏感信息，而不是浪费时间手工的处理。

Amazon Macie内置检测个人身份信息（PII）或敏感个人信息（SP）的常见敏感信息的引擎，可以自动识别出S3存储文件是否包含例如个人身份信息（PII）或其他公司财报等敏感信息，在没有Macie之前，这样的工作都需要手工的处理或者使用第三方平台。而现在可使用Macie很容易解决上述问题。

Amazon Macie持续监控数据和账户凭证。在发现可疑行为或对实体或第三方应用程序进行未经授权的数据访问时撤销访问或触发密码重置策略，来防范安全威胁。当Amazon Macie发出警报时，您可以使用预先在Amazon CloudWatch设置的规则发送告警，以便迅速采取行动，保护数据。

Macie主要功能

Amazon Macie首先功能分为两部分，一方面是使用自然语言处理(NLP)来理解数据，Macie可以自动对您的S3桶中的数据进行分类。另外一个是使用机器学习理解用户访问数据的行为，同时利用动态分析数据访问模式的预测分析算法，并使用日常访问的用户行为数据不断的训练并优化模型。

Macie 主要功能

自动化处理数据：分析，分类和自动处理数据，从现有的数据和访问日志分析出有规律的历史模式，用户认证数据，用户位置信息及时间信息。
数据安全和监控：主动监控日志数据，检测到的异常情况，转发告警信息到CloudWatch 事件或和Lambda以进行后续处理，例如自动修复安全漏洞或者发送邮件通知。
主动预防的数据的丢失，提供即时保护，无需手动干预。
可视化分析：提供存储数据的可视化详细信息。
数据研究与报告：允许用户管理配置报告。

Macie如何运作

在数据分类过程中，Amazon Macie 识别 S3 存储桶中的对象，并将对象内容流式传输到内存中进行分析。

当需要对复杂文件格式进行更深入的分析时，Amazon Macie 将下载对象的完整副本，并在短时间内保存，直到完成对象的全面分析。Amazon Macie 对数据分类的文件内容分析完毕后，它将立即删除存储内容，仅保留未来分析所需的元数据。

Amazon Macie持续监控分析当前的用户行为习惯并以基础形成基线，例如敏感数据在哪个IP地址以及何时以什么样的频率被进行访问。随后Macie持续监控CloudTrail日志并训练机器学习所使用的模型，，一旦发现可疑的访问活动，Macie可以及时发出告警。

示意图如下：

信息分类

Amazon Macie已经定义好信息分类标准：

配置合规性 – 与合规性内容策略，配置设置，数据日志记录以及补丁级别相关。
数据合规性 – 与合规性或安全控制内容的发现相关，例如存在个人身份信息或访问密钥。
文件托管 – 与恶意软件，不安全的软件或攻击者的命令和控制基础架构相关的托管主机或存储服务。
服务中断 – 可能导致无法访问资源的配置更改。
恶意软件或活动- 潜在的恶意软件或活动。
可疑访问 – 从风险异常的IP地址，用户或系统访问您的资源。
身份枚举 – 一系列API调用或访问，枚举系统的访问级别，可能指示攻击的早期阶段或受到破坏的凭据。
特权升级 – 成功或不成功的尝试，以获得对通常受应用程序或用户保护的资源的高级访问，或尝试长时间访问系统或网络。
匿名访问 – 尝试从IP地址，用户或服务访问资源，以隐藏用户的真实身份。例如包括使用代理服务器，虚拟专用网络和其他匿名服务，如Tor。
开放许可 – 识别受潜在过度允许访问控制机制保护的敏感资源。
位置异常 – 访问尝试敏感数据的异常和危险的位置。
信息丢失 – 敏感数据的异常和冒险访问。
凭证丢失 – 可能损害您的凭据。

告警严重级别

Macie 内置了5种告警信息级别

严重(Critical) – 该级别可能导致信息机密性，完整性和可用性受到损害的安全问题。建议将此安全问题视为紧急情况，并实施立即的补救或加固措施。
高 –该级别可能导致信息机密性，完整性和可用性受到损害的安全问题。建议将此安全问题视为紧急情况，并实施立即的补救或加固措施。
中等(Medium) – 该级别可能导致信息机密性，完整性和可用性受到中等性损害。建议在下次更新服务期间修复此问题。
低(Low) -该级别可能导致信息机密性，完整性和可用性受到低等性损害。建议您将此问题作为未来服务更新的一部分。
信息(Informational) – 该级别警告只描述基础架构的特定安全配置详细信息。根据相关业务和组织目标，可以简单地记录这些信息或使用它来提高系统和资源的安全性。

注：严重(Critical) 和高(High)之间的主要区别:

产生严重(Critical)警报的事件可能导致大量资源或系统受到损害。

产生高(High)警报的事件可能导致一个或多个资源或系统受到损害。

开始使用Macie

需要配置的IAM 角色

创建身份访问管理（IAM）角色，为Macie提供对您的AWS帐户的访问权限。这些角色只需要创建一次，以便在所有地区使用。

我们以Oregon区域作为例子，可以通过启动下面列出的URL中找到的AWS CloudFormation堆栈模板来创建这些角色和所需的策略。

https://s3-us-west-2.amazonaws.com/us-west-2.macie-redirection/cfntemplates/MacieServiceRolesMaster.template

配置Cloud Trail服务

首先需要建立相应IAM Role, 确保Amazon Macie能够访问S3及 CloudTrail，另外是要启动CloudTrail服务以对相关的AWS API操作进行分析。

开始使用Macie服务

添加需要管理的S3 存储桶

需要在Macie中添加需要访问S3存储桶并对其中的文件进行统计分类。

步骤如下：

1. 进入Macie Console 页面，点击 Integrations 页面后，选择SERVIES 标签页面，点击 Select an account 下拉框

2. 选择 Amazon S3 Detail

3. 选择Selected S3 buckets and prefixes

4. 选择Macie分析的S3 bucket

文件分类

在Macie中添加需要分析的S3 存储桶后，Macie会自动开始分析其中的文件，稍等一段时间后，进入Macie的Dashboard 页面。

在Dashboard中共提供10种视图，为了演示本文章仅仅展示其中的两个。

S3文件分类统计结果

S3文件分类统计详细结果

用户行为分析

根据CloudTrail的日志，Macie自动分析所有IAM user的相关操作。根据Macie预先定义的规则，把IAM用户分为如下四类：

白金：这类IAM用户或角色曾有管理员或root用户的高风险API调用的历史，例如创建用户，授权安全组入口或更新策略。应对这类帐户进行重点监控。
黄金：这类IAM用户或角色曾有创建与基础设施相关的API调用的历史，这些API调用标志其具有高级权限，例如创建实例或拥有向Amazon S3写入数据的权限。这些帐户应密切监控。
白银：这类IAM用户或角色曾大量中等风险的API调用的历史，例如Describe和 List操作或对Amazon S3的只读访问请求。
青铜：这些IAM用户或角色通常在AWS环境中执行较少量的Describe 和List API调用。

Macie使用如下的界面展示用户行为分析。

告警管理

Macie内置了40种告警规则，我们可以根据实际情况选择启用或者禁用该规则。

下面我们选择级别为严重(Critical) 的告警规则进行分析。

从上图可知该告警的规则是 “如果 IAM Policy 设置 S3存储桶可以被任何人可读,那么触发告警”, 告警样例如下：

添加自定义告警

Macie不仅仅支持内置的告警规则设置，同时也支持自定义规则的定义。

场景：

根据 Macie 定义的规则，如果文档中包含 “merger, acquisition, divestiture, reorganization, consolidation, demerger, restructuring, rebranding, takeover, subsidiary” 关键字，那么该文档会被分类为 “Corporate Growth Keywords”的类别。

现在假设用户往S3上传了具有上述关键字文档，可能存在信息泄漏的风险，需要发送告警严重级别为 “Medium”的告警。

下面演示如何添加自定义告警

1. 进入Macie Console

2. 点击 Setting-> Protect data –> Basic alerts

3. 点击 Add New 按钮

4. 按照如下样例填写

Alert Title: Test Customer Alert

Description: Test Customer Alert

Category: 选择 Information Loss

Query: themes:” Corporate Growth Keywords ”

Index: 选择S3 objects

Min number of matches:1

Severity:Medium

Whitelisted Users: 不选

5. 点击 Save 按钮.

6. 往S3上传如下内容的word文件

7. 上传成功（存储桶名字暴露了）

8. 回到DASHBOARD界面，收到告警

注：在Alert中定义最关键的部分是Query, Macie会把Query中的内容使用JavaCC转换成Lucene Query。有关查询语法的更多信息，请参阅Apache Lucene – Query Parser Syntax

如下是常见搜索的示例：

搜索任何不是源自Amazon IP地址的控制台登录：

eventNameIsp.compound:/ConsoleLogin:~(Amazon.*)/

公共S3存储中的PII(Personally Identifiable Information)

filesystem_metadata.bucket:”my-public-bucket” AND (pii_impact:”moderate” OR pii_impact:”high”)

同AWS其他服务集成

Amazon Macie 可以同其他AWS服务集成。如下示例如何使用CloudWatch和SNS集成。具体演示如下：

1. 创建SNS并使用相应的邮箱确认

2. 在CloudWatch 创建Rule

3. 收到告警邮件

更改S3元数据(Metadata)的保存周期

缺省条件下，Macie保存S3 元数据的周期是一个月，但可以系统支持该周期最长为12个月。更改步骤如下：

进入Macie Console
点击 Integrations -> Choose retention duration for S3 metadata –> Select a range

总结

Macie使用机器学习算法自然语言处理S3中存储的数据，并且使用上下文信息对信息进行分类，并给数据分配相应的业务价值标签。自动发现分类和保护存储在AWS中的敏感数据,同时持续检查S3桶中PUT请求的CloudTrail事件，并几乎实时自动对新对象进行分类。同时监控CloudTrail的API日志，识别出日常的用户行为模式，一旦Macie发现异常的行为，可以及时的发出告警。

通过Macie，可以方便的实现数据安全自动化，及数据可视化和数据丢失防护。

作者介绍
刘春华，AWS 解决方案架构师，AWS的云计算方案架构的咨询和设计，同时致力于AWS云服务在国内和全球的应用和推广，在大规模并发应用架构、无服务器架构，人工智能与安全等方面有丰富的实践经验。曾任IBM云架构师，对企业应用迁移到云及应用系统改造有深入的研究。

应成文规定企业文化和聘用与企业文化相契合的人才的 3 个理由

“公司刚成立时，我们没有太多地讨论企业文化。根本没有任何成文规定。我们只是成立了一家自己感觉工作氛围良好的公司。在那时看来，这很不错了。但当我们开始进行更深层次的思索时，意识到企业文化是必不可少的。我们需要把它写下来，共同讨论。分解，精心讨论细节，再融合在一起。如此反复。一遍又一遍。” — 史蒂夫·乔布斯

大多数高管都认同“人才使组织变得独一无二”这句话。高绩效者的加入可以形成推动力，加快其参与的计划的进展，同时改善他人的成果。相反，如果缺少高绩效者，可能会形成“真空环境”，不能正常完成相关计划，同时降低组织的士气。无论哪种方式，团队增加或减少的每一个人都会影响组织的 DNA 或文化 — 这种影响有时微妙，有时深远。

在过去的几十年里，我有幸在几个具有高绩效文化的公司里工作过。

我花了 11 年时间从适应 — 到拥护 — Bloomberg LP 的企业文化，从工程师、工程经理一步步成长为业务负责人。在随后的 3 年里，我以首席信息官的身份在道琼斯内部推行了企业文化变革。在过去 3 年里，我作为 AWS 全球企业战略主管，四处推广 Amazon 强大的企业文化，帮助世界上一些最大的公司变革其企业文化。

通过这段经历，我发现，具有高绩效企业文化的组织在招聘人才时，对文化契合度的要求不亚于对专业领域和/或专业知识的要求。坚实的专业知识 — 无论是工程、销售、市场营销还是其他领域 — 不应忽视，但并非全部。

在我所经历的每一个高绩效企业文化中，组织对企业文化所扮演的角色都有其目的性，得益于它产生的上升力，有助于员工更快地发挥个人潜力。因此，在说明为什么我认为组织的聘用决策考虑文化契合度会对组织有益之前，您的组织需要明白自己的企业文化是什么，最好把它记录下来。

每一家公司 — 不管其规模、行业、资历如何 — 都有自己的企业文化。

企业文化是公司现状的结果 — 而不是其成因。

并非每一家公司都会以书面形式记录其企业文化。

如果没有明确成文的企业文化，员工可能会猜测自己该以何种方式工作，这对企业来说是一种风险。因此，就算有很多员工向生产力低下的方向发展或与工作环境格格不入，也不足为奇。

例如，我在彭博工作期间 (2001 年到 2012 年)，我们的部分企业文化是有成文规定的，有些更像是“部落文化”。每个部门都有一系列明确的指标 (如所有权、技术能力、沟通度)，公司会对员工开展测评以强化某些行为；此外，公司还有一项隐含指标，我们简单地称之为“彭博价值观”(如勇往直前、不屈不挠、完成工作 (GSD))，这是需要随着时间的推移才能慢慢感受和体会到的。事后看，我发现有一些貌似高绩效者 — 特别是具有很多以往经验的人士 — 因为抵触“彭博价值观”而成长较慢 (稍后再详细说明这一点)。

同样，Amazon 也将我们的部分企业文化以 14 条领导准则 (在 Amazon 内部，我们将其简称为 LP) 的形式记录了下来。每条 LP 都在我们的日常工作中发挥着巨大的作用，它们是在 Amazon 做任何工作 (从招聘、绩效管理到业务决策) 的关键因素 (稍后详细说明)。

在一篇相关文章中，我在 AWS 的一位同事 Joe Chung (我很荣幸认识他，我从他身上学到了很多东西) 介绍了制定明确的准则在任何大型云项目期间帮助指导决策的重要性。Joe 的许多观点适用于任何大型变更管理或企业文化原则制定活动。

不管组织有没有明确的“准则”或“价值观”，或者以其他形式描述企业文化，历史经验表明，以成文形式规定企业文化优于什么都不做 (至少对 Apple、彭博和 Amazon 是这样)。

而且，以书面形式规定企业文化有助于甄别契合企业文化的人才。您应该考虑以成文形式规定企业文化并聘用契合企业文化的人才，主要原因有以下 3 个：

原因 1 — 招聘契合企业文化的人才有助于始终如一地指导招聘工作

聘用人才非常难。要聘用的人越多，难度越大。

我认识的大多数高绩效者 (您的团队需要的那些人) 已经有了他们喜欢的工作，这可能也是他们绩效较高的原因之一。我发现，这些高绩效者倾向于寻找能够帮助其取得成功的企业文化。(包括我自己在内；我那时*真的*很希望到 Amazon 工作，想感受这里的工作驱动力。)也就是说，您越拥护、丰富和尊重自己的企业文化，契合您企业文化的人也越容易发现它。

在 Amazon，我们聘用员工的速度很快。我们通过多种方法来满足我们的招聘需求 — 例如，摇滚明星式招募团队、不懈创新追求、能吸引其他能人的能人，等等。在所有这些方法中，我认为，按照最相关的 LP 评估每位候选人能够最大限度地加快我们的招聘流程。每位面试官都非常了解如何依照对招聘经理最重要的 LP 来评估候选人，我们的所有“汇报”(决定每位候选人聘用与否) 讨论都基于候选人与 LP 及风险的匹配度 (没有不存在风险的招聘)。如果没有这些 LP 和周密的过程，我们的招聘活动不会这么快速。

我在彭博任职期间经历过几次招聘高峰，那时，我们每年都会在大学校园直接聘用 100-150 名工程师。我们设立的技术门槛极低 — 每位候选人必须能够设计一个基本的系统，并且编写出解决一个简单问题的代码 — 其余的聘用决策都基于文化契合度。彭博招聘团队的大部分成员都已在该公司工作多年，非常熟悉自己的企业文化，足以衡量候选人是否具备适当的问题解决能力以及是否契合组织的“彭博价值观”。凭借这些洞见，我们能够在现场做出聘用决策，这引出了我们的另一个观点。

原因 2 — 招聘契合企业文化的人才有助于新员工融入新环境

开始一项新工作可能令人兴奋，也可能是一场可怕的经历。新员工一般不知道自己面临的是什么样的环境、同事，通常也不完全了解其角色所带来的细微差别。但是，候选人对企业文化了解越深 — 越理解自己与这种文化是一致的 — 就越容易适应新环境。

我经常将高绩效文化想象成一种气流。契合企业文化的新员工将得到助力，不契合者最后会非常疲惫，要么调整自己的行为，要么离开组织。

在 Amazon，我们相信新员工是顺流而不是逆流而行的人，因为在聘用决策前，面试过程中重视 LP 帮助我们做到了这一点。除此之外，在汇报期间讨论候选人风险时，我们还可以讨论降低这些风险的方式 — 指派辅导老师，提供培训计划或辅导课程 — 因此，候选人在我们的企业文化氛围中有最好的成功机会。

由于我们有成文的 LP，这就不限于任何个人、经理或计划。新员工更容易一贯如一地理解我们的行事方式。在我的职业生涯里，见过、听过很多高绩效者因为没有意识到自己与企业文化不一致而导致工作不开心或不成功。

原因 3 — 招聘契合企业文化的人才有助于部署 (或重新部署) 人才

有很多信源 (此处、此处和此处) 表明，当今企业的平均员工任期持续缩短，这也符合常识。

这里可以得出很多结论，其中一个合理的结论是高绩效企业文化的组织的员工任期更长。

此外，我还发现，聘用契合企业文化的人才不仅有助于为组织注入他人难以复制的灵活性，而且更有可能招聘到可确保组织在许多方面长期保持领先地位的人才。我尽量向我在 Amazon 聘用的每位候选人传达这样的信息：我们期望建立互惠关系，这样我们可以在较长的时间内 (我们乐于长远思考) 探索多个不同的角色和领域。

说点题外话，在 11 年的彭博职业生涯里，我担任过不同领域的 6 个不同职位。拥有如此多的机会是我一直呆在彭博的主要原因之一。而且，尽管我犯过无数的错误，但在彭博文化价值观的指导下，我的领导团队仍愿意为我提供各种机会。回想起来，在这 6 个职位中，有 3 个是我在之前的领域做出一定贡献后获得的；而另外 3 个职位，我很确信是因为契合彭博企业文化而得到的。
您的经验是什么？您的企业文化是否有成文规定？如果没有，为什么？您会写些什么？您在聘用人才时是否考虑企业文化契合度？我很乐意倾听您的想法！我将继续发表关于企业文化的文章，欢迎发表意见和提供新想法！

不断前进
– Stephen
orbans@amazon.com
@stephenorban
http://aws.amazon.com/enterprise/

将 AWS 认证工程师的数量从零增加到数百个的 12 步计划

“不要总希望得到您还未得到的；这会使您看不到目前拥有的可能性”

作为 AWS 企业战略家，我拥有与全球各地面对着各种业务和技术难题的高管们会面的特权。每个客户都是独一无二的。但是，许多难题，如同历史一样，往往具有规律性。

其中一个规律是，市场中的技能难题以及“不在相应岗位上配备合适的人员就会妨碍您提高行动速度、节省资金和在云上拓展业务”这一想法。可以肯定的是，随着人们认识到让 AWS 完成基础设施领域的无差别的繁重工作的好处，包含单词“AWS”和“云”的招聘广告显著增加了。但是，我认为这种不断增加的需求或者您没能获得所需人才的感觉并不会阻碍您的企业在云方面获得成功。

AWS 企业战略部主管 Stephen Orban 在一篇最新文章中就这一问题有力地指出，“您已经拥有成功实现云迁移所需的人才。”而且，为了加强这一说法的说服力，我想要分享我本人遇到一个主要技能难题时发生的故事。事情要追溯到 2014 年，我的云之旅才刚刚开始。

当时我在英国的 Capital One 担任首席技术官，然后，我发现自己在深入思考我在我的工程师身上发现的技能差距。这些工程师确实很有才华，但他们只是精通传统的内部技术；因此，他们掌握的大部分是孤立的基础设施技能。

为了寻求改变，我随后又犯了一个经常犯的错误：创建一个独角兽式的工作规范并自以为是地将它应用于外部就业市场。当我发现在收件箱中没有收到任何对这则招聘广告的回应时，我感到十分惊讶和失望。

很明显，我漏掉了一个重要的事实。

我拥有的技能高超、积极主动且全心投入的团队就是我需要的团队。只不过，团队成员们需要一个途径、一个动机以及一个善于倾听和帮助他们消除自身与生俱来的对未知技术恐惧的人。

有关人才转型的这种认识和企业云之旅为我积累了大量最佳实践，也让我更深刻地了解人类。但我必须说实话；在这个过程中，我们犯了很多错误并且浪费了很多时间。但是我们还是找到了一条途径，最终发挥了作用并且为 Capital One 在英国的成功做出贡献。这帮助 Capital One 将全球的技术人才提升到了极高的水平。实际上，所有 AWS 认证开发人员中现在足足有 2% 的人在 Capital One 工作。

在说明优势之后，下面将介绍适合我们的 12 个步骤 —

步骤 1 — 接受

心理健康专家们表示，接受是走向恢复的第一步；这种说法在此处也完全适用。您的工程师们必须接受他们有能力学习 AWS 云技能并成为专家的事实。接受这一事实对于您组织内的技术主管来说也同样非常重要。正如 Stephen Orban 在文章中所述以及我在 Capital One 任职期间的经历所表明的那样，您拥有的人才就是您需要的人才。这些是在开发和运行您的现有系统方面拥有多年的重要经验的人员。

步骤 2 — 培训

在接受之后，您应该迅速开始 AWS Technical Essentials 课程。此课堂教学课程能让人大开眼界并愉快地一窥无限可能的艺术。对此，AWS 自己的培训团队或我们的其中一位获批培训合作伙伴可以起到很大的推动作用。

步骤 3 — 动手实践时间

对于经验的获得，没有任何捷径可言。因此，现在需要进行动手实践。即使略显笨拙，工程师也需要花费这些时间并在一个安全的位置实施配置。此外，目前似乎有数百万个实现这种可能性的方法，并且这些方法都有点难以掌控。您的工程师可能会非常兴奋，也可能会有点垂头丧气。识别每个人经历的正常变化曲线 (有些人的很短，有些人的很长 — 因人而异) 非常重要。持续激励也很重要。

步骤 4 — 创建您的双比萨团队

您组建的第一个工程团队应彻底包含各项核心技能的组合 — 网络、数据库、Linux 服务器、应用程序、自动化、存储和安全性。该团队将取得一些进步。它可能着眼于 Terraform 之类的工具以及其他东西。它还将编写一些 CloudFormation 代码。该团队会犯错。这是非常自然的事情。

步骤 5 — 引进一些专家

对于经验的获得，没有任何捷径可言 (续)。现在，您应该引进一些真正的专家。事实上，增加一些乐意分享经验教训和最佳实践的专家级工程师是目前至关重要的事。在英国的 Capital One，我与 CloudReach 密切合作，引进大量具有专业认证且经过现场证实的 AWS 工程师来达到此目的。我将这些专业工程师分配到不同的团队来满足他们对专业知识的需求。这一举措产生了变革性的影响。员工们通过观察、提问和“照着做”来互相学习。更好的一点是，工程师们喜欢向工程师同事学习。此外，由于在小型团队中工作，他们有机会提出问题并尝试在课堂环境下不会尝试的事情。我们甚至将这一过程所需的时间缩短至一天。在这样短的时间内，一位新工程师加入了团队，与一位专家结成搭档，然后通过 CloudFormation 和已出现的关联的持续集成/持续开发 (CI/CD) 最佳实践展示了自己。

步骤 6 — 实现目标

在这个阶段，敏捷双比萨团队的目标应是构建真实的环境并投入生产。这可能是用于托管小型应用程序和相关网络设置的基本 Amazon 系统映像 (AMI)。目的是找出对于着手工作来说很重要但并非关键的东西。设定在数周内而不是数月内完成这一目标。跟踪进度。展示好处。设置演示截止时间。随时查看进度以及最终结果。一句忠告 — 切忌让团队好高骛远。仅使用所需的 AWS 构建块。(您无需从一开始就掌握所有 90 多个构建块。)以后将有大量时间来扩展到其他构建块，因为您的解决方案会需要它们。实验的好处很关键，在学习过程中可以根据需要不断地丢弃然后重新开始，就像 AWS 在教您“走路”一样自然。

步骤 7 — 利用“细胞核分裂”推广学习成果

由于第一个团队达到了一定的 AWS 熟练度并且交付了一款产品，您现在需要观察这第一个团队的细胞核分裂。此外，您还需要逐渐但有意识地将已获得经验和最佳实践的这第一个团队分为两个全新的 4 人团队，然后为每个团队再引进 4 位工程师。这项工作将会很困难，应该小心处理。坦诚对待团队成员并肯定他们的共同成果将至关重要。此外，还要请求成员帮助您将经验教训和最佳实践传递给新的队友。采用这种细胞核分裂式方法继续拆分和重组团队，直到所有工程师融合成一个技术水平相当的团队。

步骤 8 — 认证

通过与 AWS 技术培训或我们的其中一位出色的合作伙伴合作，您现在可以开启认证之路。鼓励使用 A Cloud Guru 之类的服务还可以为工程师提供让他们根据自己的时间和节奏通过认证的流程。我提倡从助理级认证开始，然后逐渐提升到专家级认证。我在这里要暂停一下来重点说明这一点。对于这个经常被忽视的步骤，无论我怎么强调其重要性都不过分。在 Capital One，我们在工程师认证、应用程序的迁移以及 AWS 上的新系统构建之间发现了一种直接关联。Capital One 甚至为一个用于度量转型的过程申请了专利。工程师的认证过程展示出显而易见的专业上的进步，它还使通用 AWS 语言能够传播并形成支持解决方案开发的事实方法。

步骤 9 — 推广认证和相关领导力

Capital One 本身的经验、与我们许多客户的合作经验以及科学研究表明，在网络效应产生作用之前，您的拥护平台的工程师需要达到 10% 的临界数量。因此，将这种学习和认证推广到您的 10% 的工程师是您的云之旅中的重大里程碑。从这个阶段开始，您将获得强有力的晕轮效应，这种效应将开始影响外部人员看待您公司的方式，而不只是影响内部人员。您组织外的那些仅希望与原生云公司合作的工程师将开始认真考虑为您工作。因此，随着您吸引更多人才或将原有人才转变为具有云素养的人，您转型的速度将呈指数级提高。

步骤 10 — 认可并奖励专业知识（以非常公开且自豪的方式！）

作为 IT 主管，您的目标是公开宣布通过每个认证考试的每个工程师的姓名。以您能力范围内的任何方式奖励并认可技术进步。这包括宴请、优惠券、饮品、特别团队岗位、新奇的奖励，总之就是您能够想到的各种奖励。在 Capital One，我们拥有一份包含所有员工姓名以及他们获得的所有 AWS 认证的全球花名册。认证被视为一种有形的发自内心取得的成就。我遇见的几乎每一位工程师都渴望得到同行的尊重，而认证以及您获得的成就将为社区荣誉做出贡献。

步骤 11 — 挑战自我

当我在市政厅会议上表彰和奖励取得进步的工程师时，听众席中的一位言辞尖锐的人大声地说：“既然您如此热情洋溢地相信认证，那么您将在什么时候参加考试？”这很直接地打断了我的话。我有很长一段时间没有参加过行业考试了。但是，正如喜欢实践我宣扬的理论的人一样，我走进了考场。然后，我通过了 AWS 助理架构师认证考试。现在，我也能骄傲地站在这个舞台上！参加考试对我而言是一种极好的强迫机制，进而确保我获得了对关键 AWS 构建块的广泛但足够详细的了解。

步骤 12 — 创建统一的同类职业组合

最后，在适当的时候，您需要为您的技术员工提供具体的同类职业跟踪。以下是英国的 Capital One 在 IT 中创建的一些同类职业跟踪 —

技术项目经理 (TPM) — 通常负责敏捷执行、版本系列一致性和团队相互依赖性。

AWS 基础设施工程师 (IE) — 之前的数据中心系统工程师，过去通常负责 Linux/Wintel/Network 等。现在负责根据产品团队的需要创建用于不同的 AWS 构建块的 CloudFormation 代码。AWS 专家。

软件开发工程师 (SDE) — 编写逻辑并处理采用各种软件语言的数据结构。

软件质量工程师 (SQE) — 使用测试驱动型设计原则。确保在整个生命周期中都考虑并执行测试。

安全工程师 — 确保安全问题的全面性。

工程经理 — 该经理负责设计意图以及管理由上述技能团体的工程师组成的团队。

在您采用此途径时，应注意一些无形的晋升障碍可能会被打破。具体来说，不负责管理人员的工程师现在能够晋升到非常高的职位 (包括主管或主管以上职位) ，并且仍然不需要管理人员。这些晋升应考虑技术深度和相关能力发展以及逐渐提高的技术领导力成熟度。作为领导者，看到员工攀升到新的高度并获得来之不易的晋升始终是在该职位上令人欣慰的事情。我的团队中抓住绝佳机会的很多成员都自豪地获得了晋升。我们还自行打破了这种无形的障碍，而当我从英国 Capital One 离职时，我最自豪的时刻之一就是将我们的云卓越中心中的一位创始成员提升到了基础设施工程部门主管级别。这个人一直是一个独立贡献者和动手实践 AWS 专家，同时也是大家的好朋友。

将上述 12 个步骤作为人才转型的途径可以发挥您的团队成员的潜力，让他们为您的客户带来巨大的成果。

记住 — “您的所有假定的限制条件都是可辩驳的。”

Jonathan Allen
@jonathanallen02
jnatall@amazon.co.uk
EMEA 企业战略家和推广者

结合深度学习网络 (GAN 和 Siamese) 生成逼真的高品质图像

由于深度学习依靠用于训练它的数据的数量和质量，因此公司花费了大量资金来获得良好的图像数据。通常，公司会使用昂贵的人工注释或其他劳动密集型任务，如拍摄大量产品或人员照片。这种方法的成本高昂且不能扩展。训练计算机以生成高品质图像可大大降低成本并推动业务增长。

在这篇文章中，我用简单的术语解释由我的一些 Amazon 同事共同撰写的标题为“从语义上分解生成式对抗网络的潜在空间”的学术论文中介绍的概念。本文介绍了生成式对抗网络 (GAN)、Siamese 网络 (SN) 的实际应用，以便能够从语义上分解 GAN (SD-GAN)。

GAN 和 SN 是相对高级的深度学习符号，您可以单独使用 GAN 和 SN，也可以将其与其他深度学习符号结合使用来解决实际问题。通过将这些符号结合使用，AI 应用程序能够解决更多的难度更大且更复杂的业务问题。例如，面向 AI 的主要难题之一是缺少带注释或标记的数据。高品质的、带注释的数据的成本非常高，因此仅大型公司或资金充足的公司能够获得此类数据。通过使用深度学习方法 (如本文中介绍的那些方法)，可让更多的公司从几个示例生成高品质数据。

我将说明作者如何使用 GAN、SN 和 SD-GAN 分析实际图像，并使用它们生成带同一人员或对象的受控变体的“假”图像。根据您设置的参数或“观察属性”，这些假图像可能看起来像是从不同的视角拍摄的、使用了不同的光照或具有更高的分辨率或其他类似变体。通过使用本文中介绍的图像分析方法，您可以创建出非常真实的图像，这些图像看起来像已使用 Photoshop 专门处理过或是使用 3D 模型创建的。

图 1：使用本文中介绍的方法生成的示例。每行均显示同一面部的变体。每列均使用相同的观察属性。

什么是生成式对抗网络？

生成式对抗网络 (GAN) 是适用于神经网络的相对较新的深度学习架构。它们是由蒙特利尔大学的 Ian Goodfellow 与其同事在 2014 年共同开发的。一个 GAN 训练两个不同的网络，二者彼此针对，因此它们具有对抗性。一个网络通过拍摄一个实际图像并尽可能多地修改该图像来生成图像 (或任何其他示例，如文本或语音)。另一个网络尝试预测图像是“假”还是“真”。第一个网络 (称为“G 网络”) 学会生成更佳的图像。第二个网络 (称为“D 网络”) 学会辨别真假图像。其辨别能力随时间的推移不断增强。

(more…)

← Older posts

亚马逊AWS官方博客

最新发布

九月

八月

七月

六月

五月

四月

二月

一月

2016

在 Amazon Lex 控制台中

在 Amazon Lex 控制台中

背景介绍

何时应当使用 Certificate Vending Machine？

CVM实现原理

安全性说明

核心代码说明

参考链接

概述

什么是Macie

为什么要使用Macie

Macie主要功能

Macie 主要功能

Macie如何运作

信息分类

告警严重级别

开始使用Macie

需要配置的IAM 角色

配置Cloud Trail服务

开始使用Macie服务

添加需要管理的S3 存储桶

文件分类

用户行为分析

告警管理

添加自定义告警

同AWS其他服务集成

更改S3元数据(Metadata)的保存周期

总结

原因 1 — 招聘契合企业文化的人才有助于始终如一地指导招聘工作

原因 2 — 招聘契合企业文化的人才有助于新员工融入新环境

原因 3 — 招聘契合企业文化的人才有助于部署 (或重新部署) 人才

步骤 1 — 接受

步骤 2 — 培训

步骤 3 — 动手实践时间

步骤 4 — 创建您的双比萨团队

步骤 5 — 引进一些专家

步骤 6 — 实现目标

步骤 7 — 利用“细胞核分裂”推广学习成果

步骤 8 — 认证

步骤 9 — 推广认证和相关领导力

步骤 10 — 认可并奖励专业知识（以非常公开且自豪的方式！）

步骤 11 — 挑战自我

步骤 12 — 创建统一的同类职业组合

什么是生成式对抗网络？