亚马逊AWS官方博客

by AWS Team | on |

AWS 连续 7 年在 Gartner 的基础设施即服务 (IaaS) 魔力象限中被评为领导者    22 Jun

新增 – Amazon WorkSpaces 托管设备身份验证    22 Jun

Amazon Lightsail 更新 – 另外 9 个区域和全球控制台    20 Jun

AWS Lambda 对 AWS X-Ray 的支持    20 Jun

来自柏林 AWS 技术峰会的消息 – 法兰克福的第三个可用区和 Lightsail 以及另一种 Polly 语音    20 Jun

AWS WAF – Web 应用程序防火墙初体验    20 Jun

云迁移的21个最佳实践    14 Jun

AWS Greengrass – 在互连设备上运行 AWS Lambda 函数    14 Jun

通过AWS Config 管理AWS服务配置    13 Jun

Amazon Rekognition 现支持名人人脸识别    12 Jun

免费试用 Amazon WorkSpaces 最长达 2 个月时间    7 Jun

云端开发工具:AWS CodeStar     6 Jun

Amazon EC2 Container Service – 发布回顾、客户案例和代码    31 May

深入Serverless—让Lambda 和 API Gateway支持二进制数据    27 May

使用AWS Lambda和Amazon DynamoDB自动管理AWS CloudFormation模板中的Parameters和Mappings    25 May

使用AWS ALB实现基于主机名的路由分发    23 May

在VPC中自建基于BIND的DNS服务器    23 May

AWS 使用 Twitch 进行实时流媒体播放  19 May

EC2 内存中处理更新:具有 4 到 16 TB 内存 + SAP HANA 横向扩展到 34 TB 的实例  19 May

从永恒之蓝开始,安全防范没有结束    16 May

数据库迁移服务DMS——手把手教你玩转MongoDB到DynamoDB之间数据库迁移    5 May

DAX – DynamoDB集成全托管的内存缓存,轻松搞定读取负载!    5 May

Redshift又添新功能:让用户直接查询S3中的海量数据而无需复制到本地    3 May

让你的数据库流动起来 – 利用MySQL Binlog实现流式实时分析架构    3 May

客户端直连S3实现断点续传思路与实践    2 May

自动化部署服务——CodeDeploy快速入门    24 Apr

手把手教你在FPGA实例上运行“Hello World”    24 Apr

带您玩转Lambda,轻松构建Serverless后台!    11 Apr

使用Sqoop实现RDS MySQL到Redshift的数据同步    7 Apr

新上线!AWS CodeDeploy自动部署初相识    7 Apr

CrowdTangle经验谈:如何立足AWS构建SaaS解决方案    24 Mar

Amazon EBS弹性卷修改实践    27 Feb

利用Mycat中间件实现RDS MySQL的分库分表及读写分离功能    26 Feb

使用AWS控制台或命令行将AWS IAM角色附加到现有的Amazon EC2实例中    26 Feb

巧用Amazon EMR节省数据分析成本    14 Feb

利用Amazon Redshift构建新一代数据分析BI系统    13 FEB

Capital One 与Alexa – 看美国银行业如何玩转人工智能    9 Feb

AWS文件存储网关初体验  6 Feb

Amazon DynamoDB 让海量数据管理变为可能    6 Feb

使用Amazon CloudFront签名URL+S3实现私有内容发布    23 Jan

AWS Snowmobile——在数周内将数EB数据迁移至云端     22 Jan

AWS Snowball Edge——更多存储容量、本地端口与Lambda函数    19 Jan

敬请期待——Amazon EC2 Elastic GPU    18 Jan

从IaaS到FaaS—— Serverless架构的前世今生    18 Jan

通过AWS目录服务管理AWS资源    18 Jan

Token Vending Machine:移动应用客户端安全访问AWS服务的解决方案(更新)    13 Jan

利用S3fs在Amazon EC2 Linux实例上挂载S3存储桶    12 Jan

Amazon Aurora Update – PostgreSQL 兼容性   6 Jan

Amazon Lightsail – 兼具 AWS 的强大功能与 VPS 的简易性    5 Jan

实力省钱,总有一款适合您    5 Jan

2016


如何在1个小时之内轻松构建一个Serverless 实时数据分析平台    30 Dec

AWS Limit Monitoring ——书到用时方恨少,资源提限需趁早!    29 Dec

Amazon Polly – 支持47种语音与24种语言的文本到语音转换服务  19 Dec

开发者预览版——EC2实例(F1)携手可编程硬件    19 Dec

Amazon Lex – 构建对话语音与文本界面    15 Dec

如何在AWS上安装使用分布式TensorFlow    13 Dec

New feature launched to AWS China (BJS) region, operated by SINNET – Amazon RDS for SQL Server – Support for Native Backup/Restore to Amazon S3    5 Dec

由光环新网运营的AWS中国北京(BJS)区域现推出新RDS功能–支持SQL Server 本机备份/还原到Amazon S3   27 Nov

Amazon S3 和 Amazon Glacier 降价    27 Nov

构建健壮的混合云网络——BJS DX+VPN篇    23 Nov

构建健壮的混合云网络——BJS DX篇    23 Nov

构建健壮的混合云网络——BJS VPN篇    23 Nov

GPU为 Amazon Graphics WorkSpaces 提供助力    21 Nov

Amazon QuickSight全面上线——更快更易用的大数据商务分析服务    21 Nov

Amazon EC2 产品价格调降通知(C4,M4, 和T2实例)    21 Nov

利用 CloudWatch 搭建无人值守的监控预警平台    16 Nov

一键搞定云端网络环境,让您轻松迁移至AWS!    9 Nov

程序员的深度学习入门指南    07 Nov

如何在 AWS上构建基于 OpenSwan 的软件 VPN 解决方案    01 Nov

AWS的在线云计算专家,你用了吗?    31 Oct

CloudFront常见错误配置及解决方法    25 Oct

使用DMT工具迁移北京区域的数据库    18 Oct

VPC中NAT的那点事     17 Oct

CloudWatch Events监控您应用的安全    8 Oct

Oracle数据库迁移到AWS云的方案    28 Sep

使用AWS的数据库迁移DMS服务    28 Sep

手把手教你使用Amazon EMR进行交互式数据查询    27 Sep

使用Oracle Data Pump将数据库迁移到AWS的RDS Oracle数据库    26 Sep

手把手教你快速部署流量压测工具 – Bees with Machine Guns    26 Sep

优秀的领导者如何更进一步迈向伟大?    24 Sep

现代IT高管已然化身首席变革管理官    24 Sep

利用云方案进行实验时的四要与四不要    24 Sep

来自成功云企业的十项诀窍    24 Sep

助你决胜云时代的人才其实近在眼前    13 Sep

手把手教你如何用Lambda + Alexa调用echo设备    01 Sep

AWS Kinesis的Javascript交互方法    25 Aug

基于AWS 平台跳板机配置    08 Aug

如何使用AWS 命令行分段上传大文件    02 Aug

我喜欢我的Amazon WorkSpaces    02 Aug

算法改变世界 - 从Prisma 的走红说开去    02 Aug

为员工进行云培训时的11条箴言    07 Jul

畅谈CIO该如何合并业务和技术    07 Jul

协同合作伙伴 合力加速上云战略    07 Jul

在云端试验时的“有所为和有所不为”    07 Jul

专线直连AWS建立混合IT环境实务指南    01 Jul

手把手教你调校AWS PB级数据仓库    20 Jun

Token Vending Machine:移动应用客户端安全访问AWS服务的解决方案    20 Jun

分布式神经网络框架 CaffeOnSpark在AWS上的部署过程    16 Jun

打造DIY版Echo:树莓派+ Alexa 语音服务    01 Jun

使用Docker封装IPSec安全网关    30 May

将VMware 中的Ubuntu 12.04 映像导入成Amazon EC2 AMI    30 May

如何使用AWS Auto-reboot和Auto-recovery进一步提升单机高可用    16 May

AWS CTO对过去十年的经验总结 – 十条军规    12 Apr

AWS上的游戏服务:Lumberyard + Amazon GameLift + Twitch    12 Apr

为AWS北京区管理控制台集成ADFS访问    12 Apr

AWS的十年创新之路    12 Apr

空荡的数据中心,120种妙用!    12 Apr

媒体洞察 | 让企业自由发展的云时代    12 Apr

亚马逊 风力发电厂在福勒岭启动了!    12 Apr

AWS 连续 7 年在 Gartner 的基础设施即服务 (IaaS) 魔力象限中被评为领导者

by AWS Team | on |

在 AWS,每个新产品的规划环节都是围绕客户展开的。我们竭尽全力倾听和学习,利用我们了解到的信息构建未来发展的路线图。在路线图中,有大约 90% 的项目源于客户的要求,专为满足客户与我们分享的特定需求和要求而设计。我坚信,正是这种由客户推动的创新帮助我们连续 7 年锁定 Gartner 云基础设施即服务 (IaaS) 魔力象限中领导者象限的右上角位置,实现最高的执行能力以及最充分的愿景完成度:要了解更多信息,请阅读完整报告。其中包含了大量细节,很好地总结了我们的客户在挑选云提供商时所考虑的功能和因素。

-Jeff

 

 

新增 – Amazon WorkSpaces 托管设备身份验证

by AWS Team | on |

Amazon Workspaces 允许您通过 Web 和各种桌面和移动设备访问云中的虚拟桌面。WorkSpaces 的这种灵活性使它非常适用于用户能够使用现有设备 (即 BYOD,也称为自带设备) 的环境。在这些环境中,组织有时需要对访问 WorkSpaces 的设备进行管理。例如,他们可能需要根据客户端设备的操作系统、版本或补丁级别控制这些设备的访问,从而满足合规性或安全性策略要求。

托管设备身份验证

今天我们发布了 WorkSpaces 的设备身份验证。现在,您可以使用数字证书管理 Apple OSX 和 Microsoft Windows 客户端访问。您还可以选择允许或阻止 iOS、Android、Chrome OS、Web 和零客户端设备的访问。您可以实施策略,控制您希望允许和阻止的设备类型,这种控制可以一直细化到补丁一级。访问策略是针对每个 WorkSpaces 目录设置的。设置策略后,会评估客户端设备连接 WorkSpaces 的请求,并进行阻止或允许。要利用此功能,您需要使用 Microsoft System Center Configuration Manager 或移动设备管理 (MDM) 工具将证书分发到您的客户端设备。

以下是通过 WorkSpaces 控制台设置访问控制选项的方式:

以下是客户端未授权连接的情况:

现已推出

此功能现已在支持 WorkSpaces 的所有区域推出。

-Jeff

Amazon Lightsail 更新 – 另外 9 个区域和全球控制台

by AWS Team | on |

借助 Amazon Lightsail,您只需单击几次即可在 AWS 上启动虚拟私有服务器。[ls_i] 的价格为每月 5 美元起,它可处理繁重工作并使您能够轻松构建和托管应用程序。正如我的 re:Invent 博客文章 (Amazon Lightsail – 兼具 AWS 的强大功能与 VPS 的简易性) 中所述,您可以从菜单中选择配置,并启动预先配置了基于 SSD 的存储、DNS 管理功能和静态 IP 地址的虚拟机。

自我们在 11 月推出 Lightsail 以来,许多客户都使用它来启动虚拟私有服务器。举例来说,莫纳什大学借助 Amazon Lightsail 以简单且经济高效的方式快速为大量 CMS 服务重新建立一个平台。他们已迁移 50 种工作负载,并且目前正在考虑创建基于 Lightsail 的内部 CMS 服务,以允许全体教职员工和学生通过自助方式创建自己的 CMS 实例。如今,我们正在将 Lightsail 扩展到另外 9 个 AWS 区域,并推出了新的全球控制台。

新区域

在 re:Invent 大会上,我们宣布在 美国东部(弗吉尼亚北部)区域提供 Lightsail。在5月早些时候,我们增加了对美国和欧洲的其他几个区域的支持。现在,我们在亚太地区中的 4 个区域推出了 Lightsail,从而将区域总数增加到了 10 个。下面是完整列表:

  • 美国东部(弗吉尼亚北部)
  • 美国西部(俄勒冈)
  • 美国东部(俄亥俄)
  • 欧洲(伦敦)
  • 欧洲(法兰克福)
  • 欧洲(爱尔兰)
  • 亚太地区(孟买)
  • 亚太地区(东京)
  • 亚太地区(新加坡)
  • 亚太地区(悉尼)

全球控制台

利用更新后的 Lightsail 控制台,您可以在一个或多个区域内轻松创建和管理资源。我仅选择在创建新实例时所需的区域:

我可以在同一页面上查看我所有的实例和静态 IP 地址,而无论它们在哪个区域内:

我可以跨我的所有资源和区域执行搜索。我所有的 LAMP 堆栈:

或我在 欧洲(爱尔兰) 区域内的所有资源:

我可以在 Snapshots 选项卡上执行类似搜索:

利用新的 DNS zones 选项卡,我可以查看我的现有区域和创建新区域:

现在,SSH 密钥对的创建过程是特定于区域的:

我可以按区域管理我的密钥对:

静态 IP 地址也是特定于某个特定区域的:

现已推出

现在,您可以使用新的 Lightsail 控制台并在所有 10 个区域中创建资源!

-Jeff

AWS Lambda 对 AWS X-Ray 的支持

by AWS Team | on |

今天,我们宣布全面推出 AWS LambdaAWS X-Ray 的支持。您可能已经从 Jeff 的 GA 文章中了解到,X-Ray 是 AWS 推出的一项服务,用于分析分布式应用程序的执行和性能行为。传统调试方法对于基于微服务的应用程序效果不佳,在这些应用程序中,有多个独立的组件在不同的服务上运行。利用 X-Ray,您可以通过对应用程序中的延迟进行细分,来快速诊断错误、速度下降和超时问题。稍后我将详细介绍如何构建和分析一个基于 Lambda 的简单应用程序,以演示您如何能够在自己的应用程序中使用 X-Ray。如果您想立即开始使用,可以通过导航到现有 Lambda 函数的配置页面并启用跟踪,来轻松地为函数启用 X-Ray:

或者在 AWS 命令行界面 (CLI) 中更新函数的 tracing-config (请务必同时传入 --function-name ):

$ aws lambda update-function-configuration --tracing-config '{"Mode": "Active"}'

如果激活跟踪模式,Lambda 将尝试跟踪您的函数 (除非上游服务明确说明不跟踪)。如果不激活跟踪模式,仅当上游服务明确说明需要跟踪时,才跟踪您的函数。一旦启用跟踪,您将开始生成跟踪,并将获得应用程序中资源的可视化表示形式以及它们之间的联系 (边缘)。需要注意的一点是,X-Ray 守护进程会占用 Lambda 函数的一些资源。如果您已接近内存限制,Lambda 将尝试终止 X-Ray 守护程序,以免引发内存不足错误。

下面让我们通过快速构建一个使用几种不同服务的应用程序来测试这种新的集成。

作为一个二十多岁且拥有智能手机的年轻人,我有大量 图片 自拍照 (一万多张!),我想如果能够分析所有这些照片,那就太棒了。我们将使用 Java 8 运行时编写一个简单的 Lambda 函数,以响应上传到 Amazon Simple Storage Service (S3) 存储桶的新图片。我们将对照片使用 Amazon Rekognition,并将检测到的标签存储在 Amazon DynamoDB 中。

服务地图

首先,我们来快速定义几个 X-Ray 术语:子分段分段跟踪。明白了吗?如果您记住子分段和分段构成 X-Ray 要处理的跟踪以生成服务图,那么 X-Ray 就很容易理解了。如上所示,服务图是一种很不错的直观表示 (用不同的颜色表示各种请求响应)。运行您的应用程序的计算资源以分段形式发送有关它们所完成工作的数据。您可以通过创建子分段来添加有关该数据的其他注释和更细粒度的代码时间信息。通过跟踪来追踪请求在您的应用程序中传输的路径。跟踪会收集单个请求生成的所有分段。这意味着您可以轻松地跟踪从 S3 进入的 Lambda 事件,一路跟踪到 DynamoDB,并了解错误和延迟的出现位置。

因此,我们将创建一个名为 selfies-bucket的 S3 存储桶,一个名为 selfies-table的 DynamoDB 表和一个 Lambda 函数。我们将在 ObjectCreated:All 事件上为 S3 存储桶的 Lambda 函数添加一个触发器。我们的 Lambda 函数代码超级简单,您可以在这里查看完整代码。无需更改代码,我们可以通过在 JAR 中包含 aws-xray-sdk 和 aws-xray-sdk-recorder-aws-sdk-instrumentor 程序包,来在 Java 函数中启用 X-Ray。现在我们上传一些照片,并看看 X-Ray 中的跟踪。

我们获得了一些数据!我们可以单击其中一个跟踪,获取有关我们的调用的大量详细信息。

在第一个 AWS::Lambda 分段中,我们看到函数的停留时间 (即等待执行的时间),以及尝试执行的次数。

在第二个 AWS::Lambda::Function 分段中,有几个可能的子分段:

嗯,DynamoDB 方面似乎有点问题。我们甚至可以通过单击错误图标更深入地探究,并获取完整的异常堆栈跟踪。您可以看到,我们已经受到 DynamoDB 的限制,因为我们的写入容量单位不足。幸运的是,我们只需单击几下或快速调用一个 API,就可以添加更多单位。当我们这样做时,我们将会在服务地图上看到越来越多的绿色!

借助 X-Ray 软件开发工具包,向 X-Ray 发送数据变得非常容易,但您不必使用它们与 X-Ray 守护进程通信。对于 Python,您可以从名为 fleece 的 Rackspace 查看此库。X-Ray 服务充满了许多有趣的内容,了解更多信息的最好去处是跳转到文档。我一直将它用于我的 @awscloudninja 自动程序,它真的非常好用!请记住,这不是官方资料库,AWS 不为其提供支持。就我个人而言,我真的很高兴能够在所有即将开展的项目中使用 X-Ray,因为在进行调试和运行时,它真的能够为我节省一些时间和精力。我期待看到我们的客户也可以使用它进行构建。如果您想到了一些很酷的技巧或窍门,请告诉我们!

– Randall

来自柏林 AWS 技术峰会的消息 – 法兰克福的第三个可用区和 Lightsail 以及另一种 Polly 语音

by AWS Team | on |

2014 年秋季,我们在法兰克福启动了 AWS 区域,并于第二年开放了针对该区域的 AWS Marketplace。我们在德国的客户类型和规模各不相同,有初创公司、中端市场企业、大型企业和公共部门。这些客户很好地利用了这一新区域,来构建和运行在德国、欧洲等地提供服务的应用程序和业务。他们依赖于 AWS 提供的广泛的安全功能、认证和保障,以便根据内部和法律要求及法规帮助保护客户数据。我们在德国的客户还利用位于柏林、德累斯顿和慕尼黑的销售、支持和架构资源及专业技能。柏林的 AWS 技术峰会于今天召开,我们借此机会宣布了一些重大消息。总结如下:

  • 在法兰克福推出第三个可用区
  • 在法兰克福推出 Amazon Lightsail
  • 为 Amazon Polly 添加一种新语音

在法兰克福推出第三个可用区

我们将于 2017 年年中在 [fra] 区域另外设立一个可用区 (AZ),以应对 AWS 使用量的持续增长。这将使我们在全球 16 个地理区域内的可用区数量达到 43 个。我们还计划今年晚些时候在法国和中国的新 AWS 区域设立五个可用区 (有关更多信息,请参阅 AWS 全球基础设施地图)。

德国的 AWS 客户已经在计划利用新的可用区。例如:

西门子希望通过在所有可用区镜像他们的服务,来获得更大的灵活性。这还将允许他们将所有数据存储在德国。

Zalando 将会做同样的事情,在所有可用区镜像他们的服务,并计划将更多应用程序迁移到云中。

在法兰克福推出 Amazon Lightsail

Amazon Lightsail 允许您在几分钟内启动预先配置了 SSD 存储、DNS 管理功能和静态 IP 地址的虚拟机 (请阅读 Amazon Lightsail – 兼具 AWS 的强大功能与 VPS 的简易性,了解更多信息)。[ls_u] 现已在 [fra] 区域推出,您可以立即开始使用。这允许您使用它来托管在德国存储客户数据或其他敏感信息所需的应用程序。

为 Amazon Polly 添加一种新语音

Polly 为您提供多种语言的高质量且自然的男声和女声。今天,我们在 Polly 中添加了另一种讲德语的女声,将语音总数增加到了 48 种:

与 Alexa 的德语语音一样,Vicki (新语音) 同样流利而自然。Vicki 能够流利且智能地拼读德语文本中经常使用的英国惯用语,包括完全变形的版本。要开始使用 Polly,请打开 Polly 控制台或阅读 Polly 文档。我期待听到有关德国及其周边地区的客户持续发展和取得成功的更多消息!

-Jeff

AWS WAF – Web 应用程序防火墙初体验

by AWS Team | on |

1. 背景介绍

AWS WAF ,全称是Web Application Firewall ,即Web 应用程序防火墙,可以帮助用户保护Web 应用程序免受常见的Web漏洞攻击。通常这些攻击会损害Web应用的安全性,影响可用性,消耗过多的资源,增加成本,还降低响应速度和用户体验。

WAF可以让用户创建定制规则进行流量筛选,阻隔恶意访问,保障正常请求。比如,可以根据 IP 地址、HTTP 标头、HTTP 正文或 URI 字符串来筛选 Web 请求,这样便能阻止诸如 SQL 注入或跨站点脚本等常见攻击模式。

和其它诸多 AWS 服务一样,WAF 的所有功能也可以通过AWS管理控制台或API进行配置。这便利了用户团队的不同角色,不论是开发人员、DevOps工程师还是安全审查专家都可以方便使用,从开发到部署的全过程系统地管理Web应用的安全。

WAF 和AWS的Web相关服务紧密结合,目前支持CloudFront和Application Load Balancer。AWS WAF 让您能够创建集中化的规则集合,而后部署到多个网站上。用户通常有多个网站和 Web 应用程序,使用WAF可以只定义一组规则并复用于多个应用程序上。WAF也是AWS全托管的服务,用户无需担心其扩展和可用性。只需在正确的资源上启用WAF,无需部署任何额外软件即可完成部署。并且只需要部署一次,即可以全球的边缘节点全部生效。

作为防火墙,WAF当然也少不了监控和报警。WAF 可以让用户设置条件来监视哪些请求。提供准实时地 Web 流量监测报告,并以此信息来创建新的规则或使用 Amazon CloudWatch 的进行报警。

今天,我们以WAF实现防盗图这个常见应用场景,帮助大家快速上手,体验其强大和便捷。

2. 部署与配置WAF

现在主流的Web应用都使用了无cookie域名来加速静态内容,我们这里也进行类似的部署,如网站域名是 example.com,图片服务使用另一个域名 example_img.com。禁止盗图的效果可以从下表来概述。

调用图片的域名 响应效果
*.example.com 200 OK
其它非法域名 403 Forbidden

WAF目前支持CloudFront和Application Load Balancer,我们这个例子中防盗图要保护的是图片服务器,这里我们所使用的就是CloudFront提供的CDN。我们用一个现成的CloudFront分发来作演示,使用AWS 的DNS服务Route 53 配置了域名 imgtest.simg.cf。为了演示效果,我们还使用EC2配合搭建了一个简单的Web服务器,也使用Route 53 配置了域名allow.snowpeak.cf。有关EC2、ClourFront和Route 53的使用这里不再赘述,请参见各自相关文档。

现在已有了具体的2个域名,我们要实现前述的禁止盗图效果,把规则具体化为以下控制流程:

  • Referer请求头包含“://allow.snowpeak.cf/”(不写具体的协议更简单,可以同时支持HTTP和HTTPS请求)则允许访问。
  • 其它情况下禁止访问。

登录AWS WAF管理控制台

https://console.aws.amazon.com/waf/home

在左侧导航菜单中点击AWS WAF > Web ACLs,来到Web ACLs页,点击Create Web ACL按钮会前进到Set up a web access control list (web ACL)向导。

如果前进到Concepts overview页,直接点击右下角Next按钮,前进到Step 1: Name web ACL页。

2.1 创建 Web ACL

1.  Web ACL name 输入ImgAntiHotLink。

2.  CloudWatch metric name 会自动填上ImgAntiHotLink。

3.  Region保持默认的Global (CloudFront)不变。

4.  AWS resource to associate 点击下拉,选择我们已有的CloudFront分发。

5.  点击Next按钮。

2.2 创建字符串匹配条件

在Step 2: Create conditions页,下拉到页面最底部,找到String match conditions,点击其右边的Create condition 按钮创建字符串匹配条件。

在弹出的Create string match condition层中:

1.  Name栏填写referer_domain。

2.  Region保持默认的Global (CloudFront)不变。

3.  Filter settings 部分,Part of the request to filter on 在菜单中选择Header,在随后出现的 Header 栏选择Referer。

4.  Match type选Contains。Transformation选Convert to lowercase。

5.  Value to match填写://allow.snowpeak.cf/。

6.  点击 Add filter按钮,最后点击右下角Create按钮完成创建。

创建完成后弹层关闭,回到Step 2: Create conditions页,点击右下角Next按钮。

2.3 创建规则

在Step 3: Create rules页,Add rules to a web ACL 下点击右边的Create Rule按钮,在弹出层Create Rule 里如下填写:

1.  在 Name 中填写AntiHotlink,CloudWatch metric name 会自动填写上相同的值。

2.  Region保持默认的Global (CloudFront)不变即可。

3.  在 Add Conditions 下,When a request 下的3个菜单依次选择

  • does
  • match at least one of the filters in the string match condition
  • referer_domain

4.  点击“Add condition”,最后点击右下角 Create 按钮,完成创建。

创建完成后,弹层关闭,回到Step 3: Create rules页。

把 AntiHotLink 这条规则的Action 选 Allow。

Default action 选Allow all requests that don’t match any rules

点击右下角的Review and create 按钮。

最后来到Step 4: Review and create页,点击右下角Confirm and create 按钮完成创建。

3.4 查看配置结果

这时我们可以到 AWS WAF 下各个分项去看一下配置的结果,看看上述向导帮我们在Web ACLs、Rules、和 String matching下分别建立了记录并且做了关联。
在左侧导航菜单中点击AWS WAF > Web ACLs,来到Web ACLs页。如果你从其它区分region 的服务管理页来到AWS WAF页,可能出发现这里没有记录,提示“You don’t have any web ACLs in XXX region. Choose Create web ACL to get started.”,不用惊慌,是因为上面的Filter菜单默认选中了你常用的region。我们刚刚创建的WAF是不区分region的,所以在这里点选“Global (Cloudfront)”,然后我们创建的记录就可以显示出来了。

再依次点击AWS WAF > Rules和Conditions > String matching,查看到各有一条记录。

前述的向导已经帮我们创建了这些具体的分项,一方面方便我们可以逐个分别调整,另一方面,也方便我把把条件和规则复用到不同的站点上。

WAF 配置完毕后立刻生效,不用像 CloudFront 分发那样还需要等待一段时间。这一点在发生Web攻击时用于及时应对是很有意义的。

3. 效果验证

我们做一个简单的 HTML 页面,里面引用我们的图片文件,然后把它部署到我们在EC2上的Web站点上。当我们使用正常的域名访问时,比如https://allow.snowpeak.cf/imgtest.htm,图片都可以正常加载出来。下图是带 Firebug请求详情的截图。

我们再使用EC2原始的域名来访问,http://ec2-xxxx.compute.amazonaws.com 就可以模拟非法域名引用我们的图片。可以看到图片都没有显示出来。下图是带 Firebug请求详情的截图。

4. 监控

WAF提供方便的常用监控,在WAF管理页面就可以查看,还可集成到CloudWatch,使用更丰富的指标和图表。在左侧导航菜单中点击AWS WAF > Web ACLs,来到Web ACLs页,在这里点击咱们已创建的这条记录ImgAntiHotLink,页面右侧就会显示出监控详情。这个请求的数据归集有几分钟延迟,新建的ACL稍等一会可以看到结果。

首先是请求次数的图表。

右下方是请求的详情。

这里点击“View the graph in CloudWatch”,还可以跳转到CloudWatch 去看更多详细的日志和图表。

更为强大的是,可以结合CloudWatch Alarm创建报警,比如当拦截的非法请求数高于一定阈值时通知我们,方便我们再人工干预。操作方法和其它Alarm一样,具体可参考Alarm的相关文档,这里不再赘述。

5. 小结

今天我们只是通过一条规则实现了一个常见场景的配置。实际的防盗图还要考虑到更多因素,比如允许移动端App访问,允许特定搜索引擎访问图片以便收录。我们可以灵活使用String matching和Rule,配置出各种丰富的规则和效果,满足各种访问控制的需求。

在Web应用开发领域,防盗图是只个常见的小需求,在自建数据中心如果要实现防盗图,需要在所有CDN节点上逐个配置,开发和运维都很繁琐。在AWS上我们使用WAF可以非常方便的进行配置,还能享受其天然的高可用。对于各种Web攻击的防御,WAF更是得心应手的工具,为我们Web应用保驾护航。

 

作者介绍:

薛峰,AWS解决方案架构师,AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内和全球的应用和推广,在大规模并发应用架构、移动应用以及无服务器架构等方面有丰富的实践经验。在加入AWS之前曾长期从事互联网应用开发,先后在新浪、唯品会等公司担任架构师、技术总监等职位。对跨平台多终端的互联网应用架构和方案有深入的研究。

 

云迁移的21个最佳实践

by AWS Team | on |

作者:Sadegh Nadimi                翻译:郝森

 

在过去的几年里,AWS专业服务团队已经指导和帮助企业完成数百个迁移项目。今年,我们建立了一个专门的专家团队,称作专业服务大规模迁移团队,专注于协助客户开始大规模迁移(数百个应用)。

客户经常困惑有哪些最佳实践,使应用快速稳健的迁移到AWS. 虽然每个企业的组织架构和业务目标不同,但是大规模迁移团队已经掌握一些模式和实践,帮助每种类型的企业。以下是一个不完全的清单:

迁移前阶段

1. 为未来IT和业务交集的部分,制定一个清晰的愿景。想象这个愿景将怎样影响组织的战略;更广泛的宣传,使大家明确的知道战略对组织非常重要。

2. 规划并分享一个云治理模型。识别更广泛的团队的角色和职责,满足企业信息安全的最小访问特权和职责分立等原则,保障企业目标的达成将有很长的一段路要走。它同样使增强安全管控纳入到更好的控制。在使内部用户进入使用云服务的洪流之前,需要回答很多问题。我应该有多少AWS帐户?谁可以使用什么?你怎么样授予权限?在云治理来临时,AWS可以告诉你每种方法的最佳实践、优势、限制。

3. 在此过程中,尽早的培训员工。团队掌握AWS的相关知识越多,迁移就越顺畅;内部的云布道师越多,就更容易的消除障碍。在组织做一个决定,即决定在AWS之上的最终IT全景视图,这些工作应该尽早展开。

4. 花时间和精力规划AWS之上的运维管理。研究需要调整的流程,有帮助的云运维工具,以及增强团队力量的各级别运维管理培训。思考那些使你关注更宏观图景的运维管理,确保你的环境与业务战略更好的协同。

5.了解当前拥有的IT资产,以及每批迁移中都包含哪些资产。这使你完全量化和衡量你的成功入云过程。花时间找到正确的资产发现工具,更新你的应用清单。这些使迁移规划较为顺畅,使迁移过程中忽略关联关系的风险最小化。

6. 为迁移之旅选择合适的合作伙伴。应该寻找那些既有技术技能和实施经验,又有灵活方法和项目管理框架的合作伙伴。你可能已经有一个具备云能力的合作伙伴,在选择之前,留出时间对合作伙伴进行审查,要求提供参考案例。思考你计划采用的云运维模型,合作伙伴是否可以帮助协同这个模型(建设持续交付持续集成管道,管理服务)。

迁移阶段

7. 从较小的和简单的开始。换句话说,选择一些速赢的方案。你的员工对使用AWS服务越舒服,那么干系人就会越快看到收益,那么在内部推动上就越容易。你需要做到持续和透明,我们已经看到很多组织通过一系列速赢方案而实现成功。

8. 自动化。云灵活性的实现有赖于自动化。花时间重新审视那些流程,并建立一些新的在迁移过程中有用的流程。如果不是所有的方面都能自动化,仔细决定哪些可以,让团队完成。

9. 把云当作转型。通过调整内部流程,使其拥抱技术变化。运用天然的转型优势,与干系人就新的工作模式达成协同。质疑那些总是说“我们一直这样做”的人。

10. 在可能的情况下,更多的运用全托管服务。比如包括Amazon RDS, AWS Directory Service, 和Amazon DynamoDB。由AWS处理日常的维护活动,使你的团队专注于你的客户事务。

迁移后阶段

11. 全面监控。当你的应用实现健壮的架构,综合监控战略将确保你得到所有的细节。考虑到效率和成本的相互制约,你的环境运行状况如何,数据驱动的洞察力将使你做出更聪明的业务决策。

12. 使用云原生的监控工具。在AWS上,有很多工具都可以提供应用级别的洞察和监控能力。运用最适合业务的工具,从长期看,运维人员将会感谢你,业务负责人也会拥有更清晰的数据为决策提供支持。

13. 采用AWS企业支持服务。AWS技术客户经理和帐单管家,是企业支持服务包的一部分,是非常有价值的资源。他们可以是你虚拟云团队的一部分,提供一个AWS中心接触点,和事件升级路径,同时也是技术信息和指导的宝贵资源。

大规模迁移(一次性迁移数百个应用)

14. 建立一个以迁移活动为中心,由团队、工具和流程组成的健壮的迁移工厂。在第一批迁移工作之前,记录并向组织分享相关细节。采用一个灵活的模式,加速应用迁移到AWS的过程;采用一个合适的保障措施,保障关键迁移里程碑的执行,防范相关风险,例如员工休假,或为特殊负载设计的工具发生故障。

15. 提供领导力以及设定迁移工厂的相关标准。考虑建立项目管理团队,总体管理迁移活动,保障合适的交流和沟通,以及变更过程。建立一个云卓越中心,作为撬动整个迁移工程的支点组织。卓越中心提供技术指导,或者更清晰的规定,它的成员自身也要参加迁移工程。总之,伴随迁移工厂,必须设立项目管理团队和卓越中心,确保迁移项目成功。

16. 在整体项目开始后,制定一个新团队成员加入流程。这其实是另外一种形式的培训。需要建立一个专门团队,评估和批准迁移工厂所用的工具。为了优化迁移结果,考虑任命一个更小的团队,在卓越中心之上,寻找对于自我环境中独特的工作效能和模式。鉴于敏捷批次的范围和节奏的不同,迁移可能是数月,甚至是数年才能完成。应该把迁移工厂看作持续发展和进步的一个有机体。

17. 明智的将有天赋的专家分布于敏捷批次团队。对于AWS服务和数据中心应用,确保有足够宽度上和广度上的能力,处理敏捷批次中遇到的小问题。如果在一个敏捷批次中没有合适的资源,可能导致不统一的决策,进而在后续敏捷迁移批次中产生混乱。

18. 当为一个特殊应用决定迁移策略时,考虑不同的标准。如考虑业务目标、路线图、风险情况、成本等。在高阶层次上,你可以决定保持现状平移应用入云,或者在模式上做一些调整。无论是哪种选择,尽可能采纳弹性和节约成本的最佳实践,并对支撑基础架构进行抽象。有一些共同选择是自动扩展、负载均衡、多可用区场景和准确容量估算的EC2实例。如果有意义,随时让你的团队采用AWS最佳实践,并尽快开始优化。

19. 找到模式并设计蓝图。在团队进行规划活动时,基于选定的战略,迁移模式将是确定的。针对这些模式,设计可重用的蓝图,将加快工作负载迁移的速度。不要忘记与迁移团队分享这些蓝图。这可以帮助进行迁移活动的同事,使他们专注于速度和效率,而不用为决定如何迁移有相似特征的应用而担心。

20. 应用测试。迁移工厂的一个关键活动是整合和验证部署到云端的工作负载。每一个应用组件将通过一系列预定义的和文档记录的测试。如果要求应用负责人在项目的早期就提供测试计划,将会比较顺利的得到业务负责人的签字通过。理想情况下,应该有一个模板,以供所有应用负责人提出特定的测试需求。这将帮助验证活动顺利执行,使业务负责人放心,他们的应用在AWS上运行与在数据中心中运行是类似的,甚至是更好的。

21. 确保将充分交流的文化灌输给所有相关团队。所有迁移决定需要清晰的文档记录和签字确认。提醒组织内的团队一个事实,即使是不直接和迁移相关的团队,系统会出现故障,以及潜在的新IP地址/URL直接引发流量。不要忘记通知可能访问该系统的任何第三方。

AWS Greengrass – 在互连设备上运行 AWS Lambda 函数

by AWS Team | on |

在 re:Invent 大会期间发布的文章 (AWS Greengrass – 无处不在的现实世界计算) 中,我首次介绍了 AWS Greengrass。当时我们推出了 AWS Greengrass 的有限预览版,并邀请您注册。

正如我当时指出的那样,许多 AWS 客户希望在现场收集和处理数据,而现场的网络连接通常很慢,有时还时断时续,并不可靠。利用 Greengrass,他们可以在基于现场的小型简单设备上应用 AWS 编程模型。它建立在 AWS IoTAWS Lambda 的基础上,支持访问 AWS Cloud 中不断增加的各种服务。

利用 Greengrass,您可以访问在现场运行的计算、消息收发、数据缓存和同步服务,这些服务并不依赖与 AWS 区域的稳定高带宽连接。您可以在 Python 2.7 中编写 Lambda 函数,并将其从云部署到 Greengrass 设备,同时使用 Device Shadows 来维护状态。您的设备和外设可以使用本地消息收发互相通信,后者并不通过云进行传递。

现已公开发布

今天我们将在US East (Northern Virginia) 和 US West (Oregon) 区域公开发布 Greengrass。在预览版本中,AWS 客户已成功获得 Greengrass 的实践操作体验,并开始围绕它构建应用程序和业务。在后文中,我将分享一些早期的成功案例。

Greengrass 核心代码可在每台设备上运行。它允许您在设备上部署和运行 Lambda 应用程序,支持通过安全网络传递本地 MQTT 消息,并可确保设备和云之间的对话通过安全连接完成。Greengrass 核心还支持安全的无线软件更新,包括 Lambda 函数。它包括消息代理、Lambda 运行时、Thing Shadows 实现和部署代理。Greengrass 核心和可选的其他设备共同组成 Greengrass 组。该组包括配置数据、Greengrass 核心的设备和身份列表、Lambda 函数列表以及一组定义消息应发往何处的订阅。在部署过程中,所有这些信息都将复制到 Greengrass 核心设备。

您的 Lambda 函数可以使用三个不同软件开发工具包中的 API:

适用于 Python 的 AWS 软件开发工具包 – 该软件开发工具包允许您的代码与 Amazon Simple Storage Service (S3)Amazon DynamoDBAmazon Simple Queue Service (SQS), 和其他 AWS 服务交互。

AWS IoT 设备软件开发工具包 – 该软件开发工具包 (适用于 Node.js、Python、Java 和 C++) 可帮助您将硬件设备连接到 AWS IoT。C++ 软件开发工具包具有几项额外功能,包括对 Greengrass Discovery Service 的访问权和支持根 CA 下载。

AWS Greengrass 核心软件开发工具包 – 该软件开发工具包提供的 API 允许本地调用其他 Lambda 函数,发布消息和使用 Thing Shadows。

您可以在启用了 OverlayFS 和用户命名空间功能的 x86 和 ARM 设备 (具有版本 4.4.11 或更高版本 Linux 内核) 上运行 Greengrass 核心。虽然大部分 Greengrass 部署将针对专业化的工业级硬件,但您也可以在 Raspberry Pi 或 EC2 实例上运行 Greengrass 核心进行开发和测试。

在本文中,我使用了附加到 BrickPi 的 Raspberry Pi,它通过 WiFi 连接到我的家庭网络:

Raspberry Pi、BrickPi、盒子和所有其他部件均在 BrickPi 3 初学者工具包中提供。您需要一些 Linux 命令行专业知识和一定的动手能力将所有这一切组装起来,不过如果我都能做到,您肯定也可以。

Greengrass 的实际使用

我可以从控制台、API 或 CLI 访问 Greengrass。我将使用控制台。Greengrass 控制台的简介页面允许我定义组,添加 Greengrass 核心,并向组中添加设备:

单击 Get Started,然后单击 Use easy creation

然后为组命名:

并为第一个 Greengrass 核心命名:

准备好后,单击 Create Group and Core

这将运行几秒钟,然后提供可供下载的安全资源 (两个密钥和一个证书) 以及 Greengrass 核心:

我下载这些安全资源并将它们放到一个安全的地方,然后选择并下载所需版本的 Greengrass 核心软件 (适用于我的 Raspberry Pi 的 ARMv7l),最后单击 Finish

现在我打开 Pi 的电源,并将安全资源和软件复制到其中 (我将它们放在一个 S3 存储桶中,并使用 wget下载它们)。这是此时的外壳程序历史记录:

重要更新:正如我在 AWS 安全团队的一位细心的同事指出的那样,这不是向设备分发密钥的好方法。我本来可以使用 AWS CLI 从加密的存储桶中下载,通过剪切和粘贴复制它们,或者使用 USB 闪存盘。

我按照用户指南中的说明创建新用户和组,然后运行 rpi-update 脚本,并安装几个程序包,包括 sqlite3openssl几次重启后,我就可以继续了!

接下来,仍然遵循指示,解压缩 Greengrass 核心软件,并将安全资源移动到其最终目的地 (/greengrass/configuration/certs),在这个过程中为它们指定通用名称。目录看起来如下所示:

下一步是将核心与 AWS IoT 事物关联起来。返回到控制台,点击浏览组和 Greengrass 核心,找到 Thing ARN:

将证书名称和 Thing ARN 插入到 config.json 文件中,同时填充缺失的 iotHostggHost部分:

启动 Greengrass 守护程序 (这是我的第二次尝试;第一次我把其中一个路径名称拼错了):

在命令行中度过愉快的时光后 (这让我回想起了使用 Unix v7 和 BSD 4.2 的日子),现在是时候再次转到视觉界面了!访问我的 AWS IoT 控制面板,看到我的 Greengrass 核心正在与 IoT 建立连接:

我转到 Lambda 控制台并使用 Python 2.7 运行时创建一个 Lambda 函数 (IAM 角色在这里无关紧要):

以常用方式发布函数,然后跳转到 Greengrass 控制台,单击我的组,并选择添加一个 Lambda 函数:

然后选择要部署的版本:

我还将此函数配置为长期存在而不是按需提供:

我的代码会将消息发布到 AWS IoT,所以我通过指定源和目标来创建一个订阅:

我还在订阅上设置一个主题筛选条件 (hello/world):

确认完成的设置并保存我的订阅,现在我已准备就绪,可以部署代码了。重新访问我的组,单击 Deployments,并从 Actions 菜单中选择 Deploy

选择 Automatic detection 以便继续:

由于这是我的第一个部署,我需要创建一个服务级角色,以便为 Greengrass 授予访问其他 AWS 服务的权限。直接单击 Grant permission

可以看到每个部署的状态:

代码现在已在我的 Pi 上运行!它向主题 hello/world 发布消息;我可以通过转到 IoT 控制台,单击“Test”并订阅该主题,来查看这些消息:

消息如下所示:

完成所有设置工作后,我可以通过上传、发布和部署代码的新版本来进行迭代开发。我计划使用 BrickPi 来控制一些 LEGO Technic 电动车,并发布从一些传感器收集的数据。敬请关注相关文章!

Greengrass 定价

作为 AWS 免费套餐的一部分,您可以在三台设备上免费运行一年 Greengrass 核心。在下一级别 (3 到 10,000 台设备),有两个选项可用:

  • 即付即用 – 每台设备每个月 0.16 USD。
  • 年度承诺 – 每台设备每年 1.49 USD,节省 17.5% 的成本。

如果您想在 10,000 台以上的设备上运行 Greengrass 核心,或者想做出更长期的承诺,请与我们联系;有关所有定价模型的详细信息,请参阅 Greengrass 定价页面。

-Jeff

通过AWS Config 管理AWS服务配置

by AWS Team | on |

在之前的一篇安全相关的文章《从永恒之蓝开始,安全防范没有结束》中,提到通过AWS Config自动规范AWS服务的安全、合规方面的配置。

为更好遵从各行业的合规要求,构建安全的IT环境,企业的安全团队一般都会在明确安全/管理边界的前提下,选择相关安全框架,用对应的风险评估方法梳理出符合自身业务特点的安全模型。根据安全模型,通常也会用各种文档标准化抽象为各种管理策略,例如可能包含以下常见的内容:

  • 用户权限策略
  • 访问控制策略
  • 服务器安全策略
  • 应用接入策略
  • 网络分区策略
  • 数据传输策略
  • 数据存储策略
  • 备份归档策略
  • 日志记录策略
  • 审计管理策略

……….

在实际的应用场景中,标准策略可能会因为业务的变化或管理方式的变化动态调整,如何持续评估和审核在AWS云端的资源配置的合规性是否与企业规划一致?如何帮助用户在云端更好的实现变更管理,安全分析甚至自动修正不合规的配置 ?这种场景下,可以考虑用AWS Config 服务来帮忙。

一、AWS config 是什么

AWS Config 是一项托管服务,借助 Config您可以盘点AWS 资源、查看配置更改以及 AWS 资源之间的关系并深入探究详细的资源配置历史记录。使用 Config,还能通过自定义规则来定义所需的资源配置、内部最佳实践和指南,并依据这些规则评估您记录的配置。

AWS Config的主要应用功能:

  • 评估您 AWS 资源配置是否具备所需设置。
  • 获得与您的 AWS 账户关联的受支持资源的当前配置快照。
  • 检索您的账户中的一个或多个资源配置。
  • 检索一个或多个资源的历史配置。
  • 在资源被创建、修改或删除时接收通知。
  • 查看不同资源之间的关系。例如,您可能想要找到使用特定安全组的所有资源

AWS Config工作原理

更多AWS Config的信息可以参考https://aws.amazon.com/cn/config/

二、 AWS config 配置测试

为了更好了解AWS Config的工作过程,以下 将以AWS安全组的配置监控为例做一个简短测试 。

1. 测试场景:

  • 一个为web服务器配置的安全组,该安全组策略只允许对Internet开放HTTP和HTTPS两个端口;
  • 配置AWS Config 规则,当该安全组配置规则中添加了其他端口时,AWS Config 自动记录,并触发修复机制自动删除新加入的不合规的配置。

2. 配置过程

a. 权限准备。为成功配置AWS Config 规则,需要创建IAM 角色,授予 AWS Config 权限,使其可以访问Amazon S3 存储桶、Amazon SNS 主题,获取受支持的 AWS 资源的配置详细信息。IAM内置了一个AWSConfigRole的托管策略 。

新建一个IAM Role 命名为awsconfigrole, 可以直接附加该策略:

另外,测试过程中将使用lambda自动对安全组执行安全组操作,cloudwatch log操作,也需要建立好对应的IAM role并编辑策略赋予对应的权限,在测试中该IAM role为:awsoncifgec2security

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Allow",

            "Action": [

                "logs:CreateLogGroup",

                "logs:CreateLogStream",

                "logs:PutLogEvents"

            ],

            "Resource": "arn:aws:logs:*:*:*"

        },

        {

            "Effect": "Allow",

            "Action": [

                "config:PutEvaluations",

                "ec2:DescribeSecurityGroups",

                "ec2:AuthorizeSecurityGroupIngress",

                "ec2:RevokeSecurityGroupIngress"

            ],

            "Resource": "*"

        }

    ]

}

b. 配置AWS Config Setting。在AWS 控制台,打开 AWS Config ,具体过程可以参考:http://docs.aws.amazon.com/zh_cn/config/latest/developerguide/gs-console.html

在本测试过程中,我们选择资源类型为SecurityGroup:

在配置过程中,指定一个存储桶保存日志,并指定预先为AWS Config 的IAM Role ,当然也可以在这个步骤选择新建角色:

在上述页面中,可以选择是否通过SNS 启用通知将信息流式传输到 Amazon SNS 主题,发送配置历史记录传输、配置快照传输和合规性等通知。

在Resources页面中验证一下,评估的对象是否能正常的筛选出来,本例中我们是对测试的安全组进行查找:

c. AWS Config 规则配置。AWS Config提供一些内置的规则,也支持自定义规则创建。在前文中提及测试的背景中需要通过自动机制保证安全组规则符合设定的合规配置,我们将通过lambda完成该步骤。在创建规则的过程中,按向导设置规则名称,点击新建lambda功能按钮:

在lambda创建过程中,选择blank blueprint 并为函数指定runtime为python2.7 ,将准备好的代码保存在s3(可以在github中找到相关代码参考,比如https://github.com/awslabs/aws-config-rules )并上传。

Lambda函数主要完成以下工作:

  • lambda函数中按照要求只开启tcp 80 和tcp 443端口;
  • 如果有其他端口添加到配置规则中将被删除,最终保证安全组的配置规则条目中只有tcp80和tcp443相关的配置;
  • 相关的操作将记录在cloudwath logs中。

在创建过程中,为lambda指定对应的IAM Role.

lambda创建完成后,需要在AWS Config 规则页面中指定Lambda ARN,  配置触发器。本例中,当安全组配置发生变化时即触发对安全组的评估,也可以配置按照时间周期的评估对象。 另外,为了详细记录评估信息,为规则启用debug级别的记录。

 

AWS config  规则后,当前的安全组配置将自动被评估。

d. 验证。为触发AWS Config 对安全组的评估, 我们在对应的安全组规则中除tcp 80 和tpc443,额外新添加tcp445 端口。在cloudwathc logs中创建了logs group,可以进行相关日志查看:

在日志中可以清楚看到对安全组有revoking的行为,操作的端口正是额外添加的tcp445 , 并且最终将安全组只开启tcp80 和tcp443 端口。

三、进一步讨论

在上述测试过程中,大致可以了解AWS Config的工作机制和配置流程,下面进一步对一些场景的应用场景做进一步说明。

资产发现

AWS Config 不仅会发现账户中的资源、记录其当前配置并捕获对这些配置所做的任何更改,Config 还会保留已删除资源的详细配置信息。所有资源及其配置属性的完全快照在您的账户中提供完整的资源库。

持续安全分析

AWS Config 提供的数据可使您持续监控您的资源配置情况,并评估这些配置是否具有潜在的安全弱点。对您的资源配置进行更改,将触发系统发送 Amazon Simple Notification Service (SNS) 通知,这些通知可发送给您的安全团队,以便他们查看通知并采取相应措施。发生潜在的安全事件后,您可以使用 Config 查看资源的配置历史记录并检查您的安全状况。

正如测试过程中展示,企业IT团队只需明确制定相关的策略,配置AWS Config规则,AWS Config提供了托管规则和自定义规则,能满足各种就能持续监控相关的安全标准是否合规。借助 AWS Config,利用 AWS Lambda 中的自定义规则将合规性要求编制成代码,这些代码会定义资源配置内部最佳实践和指南。您可以使用 Config 自动评估您的资源配置和资源更改,从而确保整个 AWS 基础设施实现持续合规性和自主监管。通过这个机制,为企业的安全自动化提供了一个可行选项。

变更管理

在创建、更新或删除资源时,AWS Config 会将这些配置更改流式传输到 Amazon Simple Notification Service (SNS),如此便会收到所有配置更改通知。根据通知机制也可以考虑引入基于事件触发的机制,进一步集成各个管理环节。

在AWS Config按照既定规则完成评估后,可以在规则的详细信息中查看到具体的变更事件记录:

审计

AWS CloudTrail 将记录账户上的用户 API 活动,将保存有关 API 操作的完整详细信息,如发起人的身份、该 API 调用的时间、请求参数和 AWS 服务返 。AWS Config 与AWS CloudTrail 集成 ,回答“谁进行了修改此资源的 API 调用?”例如下图, 使用集成的 AWS CloudTrail 信息,可以发现是哪个用户错误配置了安全组。

综合上述讨论,企业内部资产管理团队可以清楚明确当前在AWS云端的数字资产,安全团队可以将严格制定的安全体系持续的在云端自动化运行,任何相关的变更和配置管理都能详尽的记录,方便后续的审计。

更多关于AWS Config的一些常见问题可参考:https://aws.amazon.com/cn/config/faq/

作者介绍

李艺明

AWS解决方案架构师,负责基于AWS的云计算方案架构规划和咨询。在企业数字化转型,物联网和大规模并发场景有广泛的规划和实践经验。拥有超过10年的IT从业经验,为各种规模的企业客户提供IT项目实施和顾问服务。在加入AWS之前,服务于微软担任解决方案工程师,负责Windows Azure方案和架构设计,在此之前负责企业私有云和企业协同应用系统的架构规划和设计。