特性

审计亚马逊Web服务

审计亚马逊Web服务
作者: 亚当Kohnke, CISA, CISSP, GIAC, GPEN
发表日期: 2019年5月1日

随着组织越来越多地采用云服务来运行澳门赌场官方下载架构和应用程序, 审计人员需要加强他们的游戏,学习新的深入的审计技能. 以前的总管理服务公司(TASC)环境由不同系统的集合体组成, 基础设施和细面条式网络连接, 领导高级管理人员发现更好的方式来开展业务,并通过利用云技术改造组织. 有很多有价值的见解, 从检查云转换中获得的教育和审计注意事项, 一个组织在2017年5月至2018年5月期间经历的安全和合规之旅.

组织可以利用一些通用的审计方法来审查运营, 他们的Amazon Web Services (AWS)产品的安全性和遵从性方面. 这里介绍的通用审计程序结合了AWS互联网安全中心(CIS)基础基准的元素, 已出版的审核指南和开发人员指南, 在进行AWS评估时,哪些可以根据其他组织的需求加以利用或调整. 建议的审计主题和指南只是这样,绝不是组织应该或被指示执行的一组规定性测试. 最好从概述AWS的一些一般控制注意事项开始.

An important consideration before undertaking an AWS audit is understanding the specific AWS services the organization has purchased; the intended use of these services; the interrelationships between these services; how users, 无论是内部还是外部, are accessing the environment; and who is responsible for managing each service on a daily basis.

可以找到审计这些服务的有用文档.1 开发人员指南, 用户指南和白皮书提供了开发AWS审计领域和需要考虑的特定风险项目的有用信息.

治理

使用COBIT 5的元素, 建立并确定治理主体和操作管理之间的分离是否到位是很重要的,因为可能存在自我监管的关键风险, 导致难以控制的云实现, 不受控制的成本和未能实现利益相关者的需求. 此阶段的审计测试应确定文档中是否正式存在一致的操作和/或遵从性目标, 是否与运营管理层沟通, 如果在治理和管理职能之间定期召开会议来衡量这些目标的实现情况. 进一步 determinations should focus on whether and to what extent AWS services integrate into existing directives and processes such as the information security program; change management; incident response and disaster recovery; whether uniform asset inventory, tagging strategies and AWS service acquisition management processes are in effect to manage costs; and the use of AWS services and related resources. 这部分审查的其他重点领域应该通过检查网络图来围绕AWS服务的体系结构, 与本地系统的集成级别, 供应商管理流程, 以及其他监督职能,例如日常执行安全和/或风险评估.2

网络配置与管理

这方面的审核主要侧重于确定和理解AWS提供的外部VPC (virtual private cloud)是否满足组织的安全和架构要求. 此级别的一些考虑因素包括是否将资源部署到AWS区域, 可用性区域, AWS服务访问, 以及vpc的实施, 子网和安全组(也称为防火墙规则)是合适的. 在此阶段要考虑的一个关键风险是VPC对等是否处于活动状态, 哪些资源或亚马逊帐户之间, 以及通过VPC对等连接授予的访问级别. VPC对等允许从其他AWS根帐户到组织的云部分的外部访问,并可能作为潜在的数据泄露载体. 必要时应适当限制和监测. 进一步的确定应该关注网络体系结构比较是否在常规的基础上针对已定义的安全需求进行,以及该体系结构在多大程度上正确地隔离了各种环境(如test), 舞台与制作. 检查安全组和网络访问控制列表(NACL)是否适当地限制入站和出站网络流量也很重要, 缺省情况下,如果允许的流型无法匹配,则拒绝流量, 以及是否正在进行网络基线以理解标准网络模式和使用,并促进识别和正确响应异常网络流量模式的能力.

资产配置与管理

AWS资产包括从亚马逊购买的AWS服务, 与这些服务资源相关联的可配置设置, 以及包含在这些服务资源中或由这些服务资源处理的数据. 一个简化的例子是Amazon S3(服务), 托管的S3桶(可配置的服务资源)和这些S3桶中包含的数据. 这方面的审查主要集中在安全管理AWS服务资源上, 控制这些服务资源的使用, 确保安全配置, 控制对这些服务资源的更改,并随时间跟踪对它们的更改.

审计测试应侧重于确定AWS资源是否, 例如EC2实例或S3桶, 是否以基线方式部署在所有AWS根帐户上, 区域和可用分区, 进一步确定如何识别不合格资源,以及这些资源配置的及时发现和纠正是否得到了充分的便利. 进一步的确定应关注对关键AWS服务资源配置的修改是否会产生审计跟踪, 谁可以操纵审计线索, 在哪里以及如何保护这些记录, 以及这些记录按照组织指令保留多久.

逻辑访问控制

至少可以说,AWS中的访问控制设置是复杂的. Amazon为组织提供了许多方法来访问通过AWS服务资源部署的数据. 方法包括通过HTTP访问AWS根帐户, AWS管理控制台, IAM (Identity and Access Management)服务, 应用程序编程接口网关, AWS Cognito, AWS CloudFront发行版, 通过本地Active Directory进行联邦访问, 和其他人. 访问控制给组织带来了最大的风险,因为用户可以通过多种方式访问AWS, 哪一个, 反过来, 通过对前面列出的每个单独访问向量的管理,引入了更普遍的攻击面和增加的活动.

此阶段的审计活动应侧重于现有的AWS根帐户, 可能有好几个. 传统意义上的AWS根帐户无法得到充分的限制, 因为密码策略不能应用于它,也因为它可以访问和操作的服务或数据不能受到限制. 值得注意的是,AWS中关于用户帐户的一个关键概念是访问密钥, 它们与用户名或密码分开,并由程序化使用AWS账户所需的两条信息组成. 第一个是秘密访问密钥,只有在创建帐户时才能访问. 第二个是访问键ID. 这两条信息是令牌,用于以编程方式访问和签署AWS内发出的API请求. AWS允许为每个帐户生成两个单独的访问密钥,以便轮换访问密钥,这应该是管理帐户的额外审计重点.3, 4

关于root帐号, 强烈建议通过从管理控制台中删除访问密钥或将访问密钥配置为非活动状态来禁用帐户的使用, 并且为AWS环境中的日常管理任务创建了基于管理角色的帐户. 有些活动需要使用与计费相关的根帐户, 支持和终止AWS服务的使用. 如果没有做出删除根访问键的决定, 应该确保根帐户对其启用了多因素身份验证,并且已经向Amazon支持进行了注册,以防出现任何问题,例如访问管理控制台或其他不可预见的场景.

在root帐号之后, 审查可以通过执行访问管理的典型IT通用控制行业实践来推进,例如用户的身份如何, roles and groups are structured; if they appropriately restrict access to AWS service resources; and whether other AWS accounts or Active Directory domains have administrative access to the services. 进一步的审计重点应该集中在如何限制使用加密密钥管理访问, 是否审查密钥管理活动, 以及是否通过使用不同的帐户或访问组来隔离管理和标准用户活动. 提供对环境访问的每个AWS服务都有详细的指南来解释默认配置, 可能的配置, 相关的角色, 或者访问和控制. 花时间了解跨服务操作也是早期要采取的重要步骤, 因为一些服务协同工作,为用户提供对环境(如IAM和API Gateway)的访问.

数据加密控制

亚马逊在为组织提供强大的电子商务服务方面做得很好.g., 高级加密标准[AES] AES-256)是AWS服务对静态数据的默认加密,并限制对某些服务资源(如S3存储桶)的默认访问. 这方面的审查可能会关注存储在特定AWS服务中的信息是否存在数据分类方案, 比如EC2, S3, 红移, 关系数据库服务(RDS)或Lambda, 如果适当的加密正在积极地保护这些服务资源及其数据. 这部分审查还可能侧重于与环境的远程连接,并确保远程访问所需的强加密.

日志和事件管理

Amazon提供了多种工具, 比如CloudWatch和CloudTrail, 这对于记录AWS中发生的事件非常有用. 组织还能够集成安全信息和事件管理(SIEM)系统,用于日志关联和集中分析. 审查的这一部分旨在验证是否存在一个全面的日志管理策略,以及AWS环境是否反映了这些需求. 审计重点将与前面的数据加密区域重叠,以了解敏感数据存在的位置(例如.e., S3 bucket, EC2实例, 红移集群),并关注详细的日志记录是否到位(日期/时间), 成功/失败指标和源/目的IP地址).

审计的重点还应确定是否集中管理日志数据以进行相关性分析, 是否对日志的访问进行了适当的限制, 以及修改尝试或日志记录失败是否可以及时识别和处理. 应该特别考虑EC2计算实例, 也, 验证主机入侵检测机制是否存在,是否配置充分,以提醒人员注意关键的操作系统级文件更改. 最后, 审计应确定日志记录功能是否能够充分识别并提醒人员注意未授权的用户或设备.

保安事故应变

审计的这一部分将主要关注成熟组织为内部安全事件响应而实施的典型IT一般控制(ITGC)活动, 例如建立事件响应计划, 例行演习应对和危机沟通方面的计划. 这部分审查应该关注的一个关键风险是,确保在AWS根帐户下存在一个支持角色,以便在发生安全漏洞时使用AWS支持来管理安全事件, 对组织的影响. 另外, 确定是否向Amazon注册了安全联系信息,以确保组织能够及时接收安全咨询信息.

进一步的审计重点应确定是否在AWS根帐户下建立了安全问题. 这有助于确保与AWS支持的交互需要某种级别的身份验证,并可能有助于限制未经授权的组织信息暴露或重置根帐户凭据,从而使恶意用户能够访问AWS环境. 最后, 审计应确定是否部署了澳门赌场官方下载范围的监控解决方案,以及该解决方案监控AWS服务资源的可用性和/或安全状态的程度.

灾难恢复

AWS中的灾难恢复涵盖了大量AWS服务和资源. 在这个级别的审查中,一个好的实践是将灾难恢复测试点分成几个部分(例如.g.(网络架构、业务配置)来介绍一些效率. 从AWS服务的网络架构开始, 了解一些特定于aws的概念非常重要, 即区域和可用分区.

AWS区域包括地理区域(i.e., 圣保罗, US-East),通过可用区(US-East -1a或US-East -1b)提供一系列AWS服务。. 可用区是容错数据中心的集合,这些数据中心在物理上与特定区域隔离,但通过低延迟网络链路安全地相互连接以实现容错. 通过AWS购买的服务可以配置为跨多个区域和可用性区域运行. 在区域间复制数据时, 数据通过公共互联网, 最初的一些审计检查是为了确定这种容错条件是否存在, 是否为容错选择了适当的区域,以及该连接是否加密.

审计在这方面的重点应首先确定组织的灾难恢复流程和计划是否包含AWS服务,以及对这些恢复计划进行审查的程度, 锻炼和调整. 进一步, 审计应集中于关键过程的替代解决方案是否被识别并纳入恢复计划, 在主要人员不可用的情况下,是否发生人员交叉培训, 以及AWS服务资源本身在多大程度上(i.e.(S3桶,EC2实例)是冗余的. 可以利用AWS Trusted Advisor或其他工具来帮助确定组织的AWS服务容错性是否充足,并可以帮助组织高效地确定AWS环境的整体安全性和合规性状态.

当前的AWS风险范围

每个AWS服务类别(i.e.(计算、存储) 图1 是当前AWS服务产品的一小部分, 每一个都可以被认为是星系,在太阳系的服务类别中列出了单独的服务产品, 每个都有自己的配置和风险考虑(行星).5 随着AWS在各个服务类别下开发新的服务产品,该列表也在不断增长. 应该努力阅读组织所使用的每个服务提供的开发人员指南,以了解潜在的配置, 组织面临的适用风险和应采取的潜在缓解策略.

图1

ISACA发布的一份资源 亚马逊网络服务(AWS)审计程序,6 能帮助从业者设计和实施有效的AWS审计吗.

尾注

1 亚马逊网络服务、AWS文档、 http://aws.amazon.com/documentation
2 亚马逊网络服务, 审计AWS使用简介2015年10月; http://d1.awsstatic.com/whitepapers/compliance/AWS_Auditing_Security_Checklist.pdf
3 亚马逊网络服务, AWS安全最佳实践2016年8月 http://d1.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices.pdf
4 独联体基准, CIS亚马逊网络服务基金会, 2018年5月23日, http://d0.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf
5 亚马逊,“AWS文档”, http://docs.aws.amazon.com/index.html#lang/en_us
6 ISACA, 亚马逊网络服务(AWS)审计程序,美国,2019; 1bn.kingpaq.com/aws-audit-program

亚当Kohnke、CISA、CCNA:Security、ITIL v3、Security+
目前在麦迪逊市的Total Administrative Services Corporation担任高级IT审计员, 威斯康辛州, 美国. Kohnke拥有两年多的IT审计经验,并在多家财富500强公司的IT运营方面拥有六年多的经验, 变更和项目经理.