Tag: AWS Config


动态DevOps环境中的IT治理

译者:殷实,AWS专业服务咨询顾问 |原文链接

动态DevOps环境中的IT治理

治理涵盖安全和生产力运营的协调,其目的是确保公司实现业务目标。 正在迁移到云端的客户可能处于实现治理的各个阶段。 每个阶段都有自己的挑战。 在这篇博文中(系列中的第一篇文章),我将讨论四步走的方法来自动化AWS服务的治理。

治理和DevOps环境

具有DevOps和敏捷思维的开发人员负责构建和运营服务。他们经常依靠中央安全小组制定和实施安全策略,寻求安全审查和批准,或实施最佳实践。
这些安全策略和规则并没有得到安全小组的严格执行。它们被视为开发人员为获得更多的使用AWS的灵活性而遵循的准则。然而,由于时间限制或重视度不足,开发人员可能并不总是遵循最佳实践和标准。如果这些最佳实践和规则得到严格执行,安全小组就可能成为瓶颈。
对于迁移到AWS的客户,这篇博文中描述的自动化治理机制将为开发人员保留灵活性,同时为安全团队提供控制。
在动态开发环境中,以下是一些常见的挑战:

  • 通过捷径完成任务,例如将安全凭证硬编码在代码中。
  • 成本管理,例如控制启动的实例的类型。
  • 知识传递。
  • 手动流程。

治理步骤

四步走的自动化治理方法:

在治理开始的时候,你需要实施一些(1)高风险操作的控制。在控制就绪后,你需要(2)监控你的环境,以确保你正确地配置了资源。监控将帮助你发现想要(3)尽快修复的问题。你还将需要定期地生成一份(4)审核报告,以展示所有内容都符合要求。
这篇博文中的例子协助阐明了四步走的自动化治理方法:中央IT团队允许其Big Data团队运行一个基于Amazon EMR集群的测试环境。该团队在100个t2.medium实例运行EMR任务,但是当一个团队成员使用100个r3.8xlarge实例来更快地完成任务时,业务会产生意外的费用。
中央IT团队关心治理,采取一些措施来防止这种情况再次发生:

  • 控制要素:团队使用CloudFormation来限制实例的数量和类型,并使用AWS身份和访问管理来允许只有某个组可以修改EMR集群。
  • 监控要素:团队使用AWS标记,AWS ConfigAWS Trusted Advisor来监控EMR实例限制,并确定是否有人超额使用了被允许的实例数。
  • 修复:团队创建一个自定义的AWS Config规则来终止那些不是指定类型的EMR实例。
  • 审核:团队在AWS Config中审查EMR实例的生命周期。

控制

你可以通过标准化配置(通过AWS CloudFormation),限制配置的选项(通过AWS服务目录)和控制权限(通过IAM)来防范错误。
AWS CloudFormation可以帮助你在单个软件包中控制工作流环境。 在这个示例中,我们使用CloudFormation模板来限制实例的数量和类型,使用AWS标记来控制环境。
例如,团队可以通过使用限制了实例类型和数量的CloudFormation来阻止选择r3.8xlarge实例类型的选用。

CloudForamtion模板示例

包含标记的EMR集群

{
“Type” : “AWS::EMR::Cluster”,
“Properties” : {
“AdditionalInfo” : JSON object,
“Applications” : [ Applications, … ],
“BootstrapActions” [ Bootstrap Actions, … ],
“Configurations” : [ Configurations, … ],
“Instances” : JobFlowInstancesConfig,
“JobFlowRole” : String,
“LogUri” : String,
“Name” : String,
“ReleaseLabel” : String,
“ServiceRole” : String,
“Tags” : [ Resource Tag, … ],
“VisibleToAllUsers” : Boolean
}
}

在AWS中AWS Service Catalog可用于分配经批准的产品(服务器,数据库,网站)。 这为IT管理员在哪些用户可以访问哪些产品的方面,提供了更多的灵活性。 AWS Service Catalog还使他们有能力根据业务标准执行合规性。

AWS IAM用于控制哪些用户可以访问哪些AWS服务和资源。 通过使用IAM角色,你可以避免在代码中使用root凭证来访问AWS资源。
在这个示例中,我们给予团队领导者完全的EMR访问包括控制台和API访问(不在此处介绍),并为开发者提供只读访问并且不提供控制台访问权限。 如果开发者想要运行这个任务,开发者只需要PEM文件。

IAM策略

以下策略使团队领导者拥有的完全的EMR访问:

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“cloudwatch:*”,
“cloudformation:CreateStack”,
“cloudformation:DescribeStackEvents”,
“ec2:AuthorizeSecurityGroupIngress”,
“ec2:AuthorizeSecurityGroupEgress”,
“ec2:CancelSpotInstanceRequests”,
“ec2:CreateRoute”,
“ec2:CreateSecurityGroup”,
“ec2:CreateTags”,
“ec2:DeleteRoute”,
“ec2:DeleteTags”,
“ec2:DeleteSecurityGroup”,
“ec2:DescribeAvailabilityZones”,
“ec2:DescribeAccountAttributes”,
“ec2:DescribeInstances”,
“ec2:DescribeKeyPairs”,
“ec2:DescribeRouteTables”,
“ec2:DescribeSecurityGroups”,
“ec2:DescribeSpotInstanceRequests”,
“ec2:DescribeSpotPriceHistory”,
“ec2:DescribeSubnets”,
“ec2:DescribeVpcAttribute”,
“ec2:DescribeVpcs”,
“ec2:DescribeRouteTables”,
“ec2:DescribeNetworkAcls”,
“ec2:CreateVpcEndpoint”,
“ec2:ModifyImageAttribute”,
“ec2:ModifyInstanceAttribute”,
“ec2:RequestSpotInstances”,
“ec2:RevokeSecurityGroupEgress”,
“ec2:RunInstances”,
“ec2:TerminateInstances”,
“elasticmapreduce:*”,
“iam:GetPolicy”,
“iam:GetPolicyVersion”,
“iam:ListRoles”,
“iam:PassRole”,
“kms:List*”,
“s3:*”,
“sdb:*”,
“support:CreateCase”,
“support:DescribeServices”,
“support:DescribeSeverityLevels”
],
“Resource”: “*”
}
]
}

以下策略使开发人员拥有只读访问:

{

“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“elasticmapreduce:Describe*”,
“elasticmapreduce:List*”,
“s3:GetObject”,
“s3:ListAllMyBuckets”,
“s3:ListBucket”,
“sdb:Select”,
“cloudwatch:GetMetricStatistics”
],
“Resource”: “*”
}
]
}

这些是IAM管理的策略。如果要更改权限,你可以创建自己的IAM自定义策略

监测

尽可能使用AWS CloudTrailAmazon CloudwatchAmazon VPCAmazon S3Elastic Load Balancing提供的日志。 你可以使用AWS Config,Trusted Advisor和CloudWatch的事件和警报来监控这些日志。
AWS CloudTrail可用于在AWS中记录API调用。 它可以帮助你解决问题,确保你的环境安全,并生成审核报告。 例如,您可以使用CloudTrail日志来识别谁启动了那些r3.8xlarge实例。

AWS Config可用于跟踪和执行规则,这些规则检查你的AWS资源的配置是否符合要求。你还可以根据你配置的规则一目了然地了解你的环境的合规性情况。
Amazon CloudWatch可用于对配置不正确的资源进行监控和报警。 CloudWatch的实体,包括监控指标,警报,日志和事件可帮助你监视AWS资源。使用监控指标(包括自定义的监控指标),你可以监控资源并获取可自定制的小控件的仪表板。 Cloudwatch日志可以用于从AWS提供的日志和你的系统日志中传输数据,这有助于问题修复和审核。
CloudWatch事件可以帮助你针对变更采取行动。 VPC流日志,S3和ELB日志为你提供数据,以便你在修复问题或优化环境时做出更明智的决定。
AWS Trusted Advisor分析你的AWS环境,并提供四个方面的最佳实践建议:成本,性能,安全性和容错能力。这个在线资源优化工具还包括有关AWS资源限制的警告。
我们将使用Trusted Advisor来确保这种资源限制不会成为启动100个实例的瓶颈:

问题修复

根据违规情况以及监控和展现资源配置的能力,你可能想要在发现配置不正确的资源导致安全性冲突时采取行动。 重要的是修复问题不会导致没有预期的后果,并且为你的执行的操作维护可审计的记录。

你可以使用AWS Lambda自动化一切。 当你使用Lambda与Amazon Cloudwatch 事件来修复问题时,你可以采取终止实例行动或者将新实例添加到 Auto Scaling 。你可以针对任何AWS API调用采取行动。 你还可以使用AWS Config托管规则和自定义规则进行问题修复。 在根据AWS Config规则获取有关环境的信息时,你可以使用AWS Lambda针对这些规则执行操作。 这有助于自动化的问题修复。

AWS Config查找运行中实例的类型

要解决我们示例中的问题,你可以实现AWS Config的自定义规则和触发器(例如,如果实例的类型大于.xlarge或被拆除出EMR群集,则该实例会被关机)。

审计

你做为审计员,将会希望在年底或季度末准备一份审计报告。你可以使用AWS Config资源自动化你的报表系统。
你可以查看AWS资源配置和历史记录,以便查看r3.8xlarge实例集群何时启动或者应用了哪个安全组。 你甚至可以搜索哪些被终止的实例。

AWS Config 资源

 

更多控制,监测和问题修复的示例

来自AWS专业服务团队的Armando Leite创建了一个利用Cloudwatch Events和AWS Lambda的治理框架示例来强制执行一组控件(无操作系统root的访问,无远程登录)。 当违规被注意到(监测)时,自动化措施会被采取来响应事件,并在必要时恢复到之前的良好状态(问题修复)。

  • 通过AWS Config的自定义规则或AWS CloudWatch事件去触发工作流,来进行修复(例如,关闭实例)
  • 监视用户的操作系统活动。 随着事件的发展,新的Lambda功能动态地启用更多的日志和订阅日志数据以实现进一步的实时分析。
  • 如果监测的结果是适合,将系统恢复到之前的良好状态。

 

译者

殷实,AWS专业服务咨询顾问,专注于企业客户在AWS上的运维和DevOps的评估,架构,设计和实施。

通过AWS Config 管理AWS服务配置

在之前的一篇安全相关的文章《从永恒之蓝开始,安全防范没有结束》中,提到通过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方案和架构设计,在此之前负责企业私有云和企业协同应用系统的架构规划和设计。