【总结】AWS上安全的最佳实践

原文地址：http://blog.****.net/qxk2001/article/details/51287869

讲师：武杰 AWS架构师 
下载地址：视频下载

1. 邱洋的总结

• 云安全的保障需要3个层面联合努力 
  – 云平台厂商（主要针对云中的硬件、网络、存储） 
  – 用户自身（主要针对云中的应用，资源管理流程） 
  – 合作伙伴（针对客户特别需求）
• 云平台厂商的安全资质包括 
  – 自身的资质，如cmmi、iso、soc等（甚至可以将资质租借给用户，以便拿下某些项目） 
  – 行业资质，如金融、医疗、军工等
• 云平台针对基础资源的安全保障包括 
  – 物理机（ssh访问、所有操作都记录可审计、os加强配置–关闭端口等） 
  – EC2（安全组、网络隔离、**保护、防攻击–山石） 
  – VPC（网络自定义、ACL访问控制、v*n加密访问） 
  – 存储(加密) 
  – 多区域部署 
  – 权限认证（IAM，用户、角色、分组，控制到是否允许访问那些资源） 
  – 审计（每条操作–api和人工行为的审计、资源变更审计）

2. 责任分担的模型

2.1 分担模型的定义

责任分担模型的定义是在安全层面，AWS和用户之间各自负责自己可控的部分从而共同与风险抗争，其中： 
- AWS负责两个层面的安全 
– 1.全球基础设施、大区域、可用区 
– 2.AWS提供的基本服务：计算、存储、数据库、网络等 
- 用户负责的安全 
– 1.加***管理、客户端加密、通讯加密 
– 2.OS打补丁、防火墙配置等 
– 3.应用系统相关，如身份认证、权限管理等

2.2 AWS在安全层面的一些资质

• SOC（注册会计师学会，针对服务性机构的控制，满足在美上市的公司的合规要求） 
  – ISO（27001、9001在安全领域顶级的认证）
• 行业层面 
  – 银行业PCI（信用卡支付）等认证 
  – 医疗行业，HIPAA BAAs 
  – 媒体行业
• AWS资质可以根据协议共享 
  – AWS的报告根据协议共享给客户，从而快速满足共同客户的需求

案例：沃达丰有个项目要在欧盟落地，但是本身无法达到某个认证（PCI认证），AWS将资质借给沃达丰，这样沃达丰就可以很快通过欧盟的认证了

3. AWS云资源的覆盖性和可用性特征

3.1 AWS云计算资源在全球布局

AWS在全球11个大区，横跨五大洲。北美3，南美1，欧洲2，亚太3，大洋洲1，中国北京1 
- 一个区域（Region）：一组数据中心的集合，一个区域至少2个可用区，最多的区域有5个可用区。（AWS的区域布局如下图） 

3.2 AWS的可用区设计

• 一个可用区（Availability Zone）：每个可用区相当于一个数据中心，同一个区域间的可用区AZ都是相互之间通过网络高速互联的（AWS的可用区布局如下图） 
  

• 边缘站点（Edge locations）：主要部署AWS的DNS服务、CDN加速服务等，全球目前共有52个。（AWS的边缘站点布局如下图） 
  

4. 如何用AWS现有服务和产品来保护云中数据

4.1 可用性概述

AWS的整体建设目标就是为了持续可用(Continuous Availablility )，具体表现在 
- 分布式的、可扩展的，容错的服务云服务 
- 所有数据中心的AZ（可用区）同时在线 
– 灾难恢复的数据中心 
– 相同的管理标准 
- 高速网络连接 
– 顶级的SIP合作，AZ之间低延迟 
– 弹性的网络基础设施

4.2 EC2的安全特征

多层面保障安全

• 物理机层面（包括hypervisor） 
  – 通过SSH登录，并记录管理员操作 
  – 所有的访问都进行统计，并进行审查
• 在vm的OS层面 
  – 用户管理（用户拥有root和admin的权限） 
  – AWS的管理员无法登陆 
  – 用户自己定义的**
• 标准防火墙（安全组） 
  – 用户vm的访问默认是不可访问的（隔离的） 
  – 允许用户自行控制 
  – 防火墙的配置可以到端口层面，或者到其他安全组（开放给哪些人）
• API访问 
  – 采用x.509的安全加密进行调用

针对典型的三层架构AWS可给与的安全保障 
- 针对web 
– 可以通过安全组设置web只开放80端口 
– 其他端口关闭 
- 对于app应用层 
– 可以打开ssh端口，和应用特定端口 
– 应用承担堡垒机角色，用户只能在office的ip地址登陆app 
- 对于数据库DB 
– 不对外开放端口 
– 数据库可以跟本地数据中心VPC连接和同步 
– 数据库只可以被app访问

4.3 在网络层面的安全（VPC）

• 允许用户创建一个逻辑隔离的网络，高可扩展
• 定义的私有ip规则，公有/私有子网（不接受Internet网络访问）
• 允许网络访问控制，通过访问控制列表，来设置子网网段内访问的策略
• VPC可以和本地数据中心网络进行v*n（加密通道）或专网连接
• 保护vm的数据流量（流入、流出）控制（安全组中）

对于AWS的网络流量安全来说 
- 最外面是VPC，会通过ACL控制 
- 然后进入安全组 
- 在OS层面的防火墙 
- 最后进入vm 

4.4 AWS的身份识别和权限控制（IAM）

• 细粒度的控制都通过IAM来进行控制 
  – 有些资源是开放人员用 
  – 有些资源是生产人员使用 
  – 有些资源项目A或B来使用
• IAM可以被授权的实体 
  – 用户 
  – 用户组 
  – 角色（例如某个程序要访问s3，就可以给程序授权）
• IAM授权不会针对OS和app（建议使用LDAP，AD等）

AWS可以更细力度的控制用角色 
- 控制的范畴：谁(who)，可以在什么环境下（where）使用哪些方式(what）使用AWS环境 
- 这个who甚至是可以是app应用程序，如某应用只能针对DanomyDB服务的行、列进行操作（PS：这些服务都是aws自己的服务）

IAM可以和AD等已有企业权限工具进行集成 
- IAM可以支撑AD的集成，也可以支撑openID 
- 这样就不用每个企业客户都开放一个AWS的账号了 

临时安全账号访问 
如一个手机可以访问S3的数据，不可能给每个手机都开放一个aws账号】，这就需要用到 

4.5 AWS的**管理服务

• 不同的服务使用不同的**，这样可以就看可能有多个**，提供管理界面
• 集成cloudtriall来审核key日志
• 两步认证机制
• **本身加密级别高 
  

4.6 购买CloudHSM（加密机）服务

相当于防篡改的硬件 

4.7 AWS config进行行为记录和审计

相当于开启一个CDMB数据库，例如：如果给EC2开启了AWS config服务，则可以随时看到EC2的配置、存储、ip等变更 

4.8 Cloud Trail开启后可以看到API的事件和IAM的访问记录

AWS CloudTrail的日志可以用于的方面 
- 安全分析 
- 跟踪AWS的资源变化（例如vpc的acl变更） 
- 了解API的调用过程 
- 排障

4.9 监控所有东西使用CloudWatch

5. AWS上有多种不同的存储服务适合不同的内容

3.11 用户在做安全管理层面的建议

• 最小授权
• SOA理念，解耦服务并控制
• 把系统和信息分类，不同级别系统和信息要保护
• 在不同内容层面都要有安全
• 安全状态要实时调查

4. 通过AWS服务构建典型的安全弹性的app

通过一个示例看一下 
- VPC的AutoScaling可以实现应用的弹性伸缩 
- 静态数据放在S3中，来分流静态数据 
- 如果用户访问持续上升，通过CDN在全球范围进行加速，可以作为ddos的第一道防线 
- 如果用户针对某个CDN边缘进行攻击，因此可以通过router53智能的将分流到不同的CDN站点 
- AWS的router53和CDN是7*24小时服务，因此可以跟攻击者进行在线的资源对抗

5. 安全层面并不是一个厂家可以做完的

合作伙伴和可以提供更多安全服务