亚马逊AWS官方博客
动态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 Config和AWS Trusted Advisor来监控EMR实例限制，并确定是否有人超额使用了被允许的实例数。
- 修复：团队创建一个自定义的AWS Config规则来终止那些不是指定类型的EMR实例。
- 审核：团队在AWS Config中审查EMR实例的生命周期。
控制
你可以通过标准化配置（通过AWS CloudFormation），限制配置的选项（通过AWS服务目录）和控制权限（通过IAM）来防范错误。
AWS CloudFormation可以帮助你在单个软件包中控制工作流环境。 在这个示例中，我们使用CloudFormation模板来限制实例的数量和类型，使用AWS标记来控制环境。
例如，团队可以通过使用限制了实例类型和数量的CloudFormation来阻止选择r3.8xlarge实例类型的选用。
CloudForamtion模板示例
包含标记的EMR集群
在AWS中AWS Service Catalog可用于分配经批准的产品（服务器，数据库，网站）。 这为IT管理员在哪些用户可以访问哪些产品的方面，提供了更多的灵活性。 AWS Service Catalog还使他们有能力根据业务标准执行合规性。
AWS IAM用于控制哪些用户可以访问哪些AWS服务和资源。 通过使用IAM角色，你可以避免在代码中使用root凭证来访问AWS资源。
在这个示例中，我们给予团队领导者完全的EMR访问包括控制台和API访问（不在此处介绍），并为开发者提供只读访问并且不提供控制台访问权限。 如果开发者想要运行这个任务，开发者只需要PEM文件。
IAM策略
以下策略使团队领导者拥有的完全的EMR访问：
以下策略使开发人员拥有只读访问：
这些是IAM管理的策略。如果要更改权限，你可以创建自己的IAM自定义策略。
监测
尽可能使用AWS CloudTrail，Amazon Cloudwatch，Amazon VPC，Amazon S3和Elastic 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的评估，架构，设计和实施。