CSAA PRACTICE TEST 5
18
- 创建AWS Security Account的时机:Most AWS customers with multiple AWS accounts would like to organize them in some sort of security hierarchy. If you answer “yes” to any of the following questions, it is a good indication that you should consider establishing one or more security relationships between AWS accounts:
- Do you want to manage AWS user identities in one account and federate access to other accounts?
- Do you want to centrally store, secure, analyze, and report on AWS generated log data from services such as AWS CloudTrail, AWS Config, Amazon S3, Amazon CloudFront, Elastic Load Balancing, or Amazon VPC Flow Logs?
- Do you want to empower security and compliance organizations to apply security baselines and monitor security compliance across multiple AWS accounts?
- Do you want to centrally manage approved Amazon Elastic Compute Cloud (Amazon EC2), Amazon Machine Images (AMIs), or AWS Service Catalog portfolios and products?
- AWS账户安全结构:
Many companies group AWS accounts into logical structures to better organize and secure their AWS resources. While AWS accounts are not technically hierarchical, you can use organizational units (OUs) with AWS Organizations to create hierarchical and logical account groupings. When creating a new AWS account in an organization, you can use service control policies (SCPs) to filter and restrict the services and actions its users and roles are able to access. All management of the organization is performed centrally in the master account; this includes creating SCPs, creating OUs, and attaching SCPs to OUs (IAM policies are managed on the account level, independently of AWS Organizations). The following security account structures are based on common approaches for creating and securing AWS account groups.
3 . 创建AWS Security Account是最高级别的安全隔离方案
- 为EC2资源打生产环境的标签,然后设置资源的访问权限,对于生产环境的EC2资源进行删除权限进行显式拒绝;
- MFA是在用户名密码之外增加的一层账户资源保护方案;\
23
- EBS自动提供了同region内的冗余能力:Amazon Elastic Block Store (Amazon EBS) 可在 AWS 云中提供用于 Amazon EC2 实例的持久性块存储卷。每个 Amazon EBS 卷都会在其可用区内自动复制,以保护您免受组件故障的影响,同时提供高可用性和持久性。Amazon EBS 卷为您提供处理工作所需的稳定低延迟性能。通过 Amazon EBS,您可在几分钟内调整用量大小 - 所有这些您只需为配置的资源量支付低廉的价格。
- EBS应用场景:Amazon EBS 设计用于优化性能、成本和容量即可受益的应用程序工作负载。典型使用案例包括:大数据分析引擎(如 Hadoop/HDFS 生态系统和 Amazon EMR 集群)、关系和 NoSQL 数据库(如 Microsoft SQL Server 和 MySQL 或 Cassandra 和 MongoDB)、流和日志处理应用程序(如 Kafka 和 Splunk),以及数据仓库应用程序(如 Vertica 和 Teradata)。
30
- Elastic Beanstalk是一个容易使用的,支持扩展部署的服务;
- 我们可以简单的将代码上传,Elastic Beanstalk会自动的处理部署,容量获取,负载均衡,自动扩展,健康监控;同时我们可以获取全部的Resource的控制权,及访问底层的资源在任何时间;
- 创建一个Lamp堆栈的web应用程序是 Beanstalk的对外标准案例;
31
- API GateWay有两种权限控制策略:使用 IAM 权限通过控制对以下两个 API Gateway 组件进程的访问来控制对 Amazon API Gateway API 的访问:
- 要在 API Gateway 中创建、部署和管理 API,您必须授予 API 开发人员相关许可,使其可执行受 API Gateway 的 API 管理组件支持的必要操作。
- 要调用已部署的 API 或者刷新 API 缓存,您必须授予 API 调用方相应许可,使其可执行受 API Gateway 的 API 执行组件支持的必要 IAM 操作。
- 用于创建和管理API的API GATEWAY许可模型(发布方):
要使 API 开发人员可在 API Gateway 中创建和管理 API,您必须创建 IAM 许可策略,允许特定的 API 开发人员创建、更新、部署、查看或删除必要的 API 实体。您可以将许可策略挂载到代表开发人员的 IAM 用户、包含用户的 IAM 组,或者是用户担任的 IAM 角色。
- 用于创建和管理 API 的 API Gateway 许可模型(调用方):
要使 API 调用方可调用 API 或刷新其缓存,您必须创建相关的 IAM 策略,允许指定的 API 调用方调用已启用 IAM 用户身份验证的 API 方法。API 开发人员可将该方法的 authorizationType 属性设置为 AWS_IAM,要求调用方提交 IAM 用户的访问密钥以进行身份验证。然后将策略挂载到代表 API 调用方的 IAM 用户、包含用户的 IAM 组,或者是用户担任的 IAM 角色。
45
- 一个VPC内的WebServer和DB instance的访问主要是通过SecurityGroup限定的,如果需要增加对于某些IP或者CIDR的限制,可以配合NACL进行控制;
50
- RDS是不提供底层资源操作系统级别的访问权限,只能通过参数组来修改默认配置;
- 参数组设置:
如果您在创建数据库实例时未指定客户创建的数据库参数组,则将创建默认的数据库参数组。该默认组包含数据库引擎默认值和 Amazon RDS 系统默认值,具体根据引擎、计算等级及实例的分配存储空间而定。您无法修改默认数据库参数组的参数设置;您必须创建自己的数据库参数组才能更改参数设置的默认值。请注意,并非所有数据库引擎参数都可在客户创建的数据库参数组中进行更改。
- 自定义参数组:
如果您想使用您自己的数据库参数组,只需创建一个新的数据库参数组,修改所需的参数并修改数据库实例,就可以使用新的数据库参数组。与特定数据库参数组关联的所有数据库实例都将获得该数据库参数组的所有参数更新。您还可使用 AWS CLI copy-db-parameter-group命令复制现有参数组。当您已创建一个数据库参数组并且想在新的数据库参数组中包含该组中的大部分自定义参数和值时,复制参数组是一个方便的解决方案。
- 数据库参数组操作注意事项:
- 当您更改动态参数并保存数据库参数组时,将立即应用更改,而不管“立即应用”设置如何。当您更改静态参数并保存数据库参数组时,参数更改将在您手动重启数据库实例后生效。您可通过使用 RDS 控制台或显式调用RebootDbInstance API 操作来重启数据库实例 (没有故障转移,前提是数据库实例处于多可用区部署中)。在静态参数更改后重启关联的数据库实例的要求可帮助缓解影响 API 调用的参数误配置的风险,例如调用 ModifyDBInstance 来更改数据库实例类或扩展存储。
- 当您更改与数据库实例关联的数据库参数组时,必须在数据库实例使用新的数据库参数组之前手动重启实例。
- 可以将数据库参数值指定为整数,也可以将其指定为通过公式、变量、函数和运算符创建的整数表达式。函数可以包含数学对数表达式。有关更多信息,请参阅 数据库参数值。
- 在创建数据库实例以及在数据库实例中创建数据库之前,在参数组中设置与字符集或数据库排序规则相关的任何参数。这将确保数据库实例中的默认数据库以及新数据库使用您指定的字符集和排序规则值。如果您更改数据库实例的字符集或排序规则参数,则参数更改不会应用于现有数据库。 您可使用 ALTER DATABASE 命令更改现有数据库的字符集或排序规则值,例如 1. ALTER DATABASE database_name CHARACTER SET character_set_name COLLATE collation;
- 在数据库参数组内设置参数不恰当可能会产生意外的不利影响,包括性能降低和系统不稳定。修改数据库参数时应始终保持谨慎,且修改数据库参数组前要备份数据。将参数组更改应用于生产数据库实例前,您应当在测试数据库实例上试用这些参数组设置更改。
- Amazon Aurora 同时使用了数据库参数组和数据库集群参数组。数据库参数组中的参数适用于 Aurora 数据库集群中的单个数据库实例。数据库集群参数组中的参数适用于数据库集群中的每个数据库实例。有关更多信息,请参阅 Amazon Aurora 数据库群集和数据库实例参数。
62
RDS Multi-AZ部署:Amazon RDS 多可用区域部署为数据库 (DB) 实例提供了增强的可用性和持久性,使其成为生产型数据库工作负载的理想之选。当您配置多可用区域数据库实例时,Amazon RDS 会自动创建主数据库实例并将数据同步复制到其他可用区域 (AZ) 中的备用实例。每个可用区域在其独立的、物理上显著不同的基础设施中运行,并已设计为具备高可靠性。万一发生基础设施故障,Amazon RDS 可自动故障转移至备用实例中 (如果是 Amazon Aurora,则会故障转移至只读副本中),以便您能够在故障转移结束后立即恢复数据库操作。由于故障转移后数据库实例的终端节点维持不变,因此应用程序可在无需手动管理干预的情况下恢复数据库操作。
Amazon Aurora 采用专为数据库工作负载构建的 SSD 型虚拟存储层。Amazon Aurora 可以跨三个可用区,通过六种方法自动复制存储。Amazon Aurora 存储是容错型的,可透明应对多达两个数据副本的损失,而不会影响数据库写入可用性,还能在不影响读取可用性的情况下应对多达三个副本。Amazon Aurora 存储还具有自我修复能力。可连续扫描数据块和磁盘的错误并自动更换。有关 Amazon Aurora 高可用性的更多信息,请参阅在线文档。
Web架构自愈的几个关键服务:使用AS 服务,监控web layer的利用率,根据利用率进行弹性自动扩展;