AWS学习

最新推荐文章于 2024-07-03 08:35:24 发布

cuiqi7532

最新推荐文章于 2024-07-03 08:35:24 发布

阅读量496

点赞数

BGP的结构和功能

BGP用于在不同的自治系统（AS）之间交换路由信息, 处理不相关路由域间的多路连接的协议。当两个AS需要交换路由信息时，每个AS都必须指定一个运行BGP的节点，来代表AS与其他的AS交换路由信息。这个节点可以是一个主机。但通常是路由器来执行BGP。两个AS中利用BGP交换信息的路由器也被称为边界网关（Border Gateway）或边界路由器（Border Router）。

AWS WAF - Web Application Firewall

AWS WAF is a web application firewall that helps protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources. AWS WAF gives you control over which traffic to allow or block to your web applications by defining customizable web security rules. You can use AWS WAF to create custom rules that block common attack patterns, such as SQL injection or cross-site scripting , and rules that are designed for your specific application. New rules can be deployed within minutes, letting you respond quickly to changing traffic patterns. Also, AWS WAF includes a full-featured API that you can use to automate the creation, deployment, and maintenance of web security rules.

AWS WAF pricing is based on how many rules you deploy and how many web requests your web application receives . There are no upfront commitments.

You can deploy AWS WAF on either Amazon CloudFront as part of your CDN solution or the Application Load Balancer (ALB) that fronts your web servers or origin servers running on EC2.

Benefit:

Increased Protection Against Web Attacks

Security Integrated with How You Develop Applications

Ease of Deployment & Maintenance

Improved Web Traffic Visibility

Cost Effective Web Application Protection

Refer to: https://aws.amazon.com/waf/

Route53

您可以将 DNS 与运行状况检查服务组合使用，路由流量到运行正常的终端节点，或者独立监控终端节点和/或对其提供警报。

LBR（基于延迟的路由）是 Amazon Route 53 的一项新功能，有助于您提高应用程序对全球受众的性能。您可以在多个 AWS 地区运行应用程序，Amazon Route 53 则通过其遍布全球的节点将最终用户路由到可提供最低延迟性的 AWS 地区。

Refer to: https://aws.amazon.com/cn/route53/faqs/

Amazon CloudFront

Amazon CloudFront 是 AWS 的 CDN，是一个用于加快将静态和动态的 Web 内容（如: .html, css, .js, 图片文件）分发给用户的Web 服务。

比如你在中国，想请求一张 Web 服务器位于美国的图片，在检索到图片之前，这个请求会从一个网络路由到另一个网络，在经历 n 多个路由后，才能到达该图片所在的服务器，这是一个非常大的跳数，同时会对性能、可用性和可靠性产生很大影响。但是如果将原始服务器与 CloudFront 关联（关联后 CloudFront 知道从哪些原始服务器获取资源），这时不再通过原始服务器访问图片，而是通过 CloudFront 分配的 URL 访问图片，则该请求将被路由到迟延最短的 CloudFront 边缘站点。如果该内容在迟延最短的 CloudFront 边缘站点的缓存中存在，则将直接从该边缘站点的缓存中返回图片。如果请求的内容不在该边缘站点的缓存中，才从源去取（请求的内容不在缓存中，这里写的比较笼统，这种情况下 CloudFront 是如何工作的，详细工作流程，见下面 Note 的解释）。这样大大减少了路由数，从而提高了性能。

Note：如果请求的内容不在迟延最短的边缘站点的缓存中，CloudFront 的处理如下：

① CloudFront 将比较该请求与分配中的说明，然后根据对应的文件类型将文件请求转发到适用的源服务器。例如，对于图像文件，转发到 Amazon S3 存储桶；对于 HTML 文件，转发到 HTTP 服务器。

② 原始服务器将这些文件发回 CloudFront 边缘站点。

③ 当从源返回的第一个字节到达 CloudFront 时，CloudFront 就开始将这些文件转发给用户，同时将这些文件添加到边缘站点的缓存中，方便有人再次请求这些文件。

Refer to: https://blog.csdn.net/u011886447/article/details/79070197

关于EBS磁盘的IOPS,以及IOPS是如何测量的

IOPS就是每秒的读写操作。亚马逊EBS使用16KB的快大小来衡量EBS的IO表现。

当你创建一块预设IOPS为4000的EBS磁盘，并把他挂载到优化EBS的实例上（EBS-optimized instance，优化EBS的EC2实例链接EBS的IO通道是是专用的，可以保证足够的IO带宽），你可以每秒传输4000个16KB大小的块。（这样大概IO带宽就是62.5MBps，或者500Mbps）(这个IOPS 4000就是这个衡量出来的)。

当块大小大于16KB是，你的IOPS数值就变小，但是此时实例到EBS的IO带宽还是等于你传输16KB块对应IOPS数值时候的表现。当操作的块大小为16KB或者更小时，你能得到你预设的IOPS数值的表现。对于更小的块操作，你可能会看到超过你预设的IOPS数值的表现（在客户端测量时），这是因为有的客户端会将小的快合并成一个16KB大小的块来传输。

如果你得到的IOPS数值小于你预设的IOPS，这可能是因为你的 EC2实例带宽是IO性能的瓶颈：你的实例得是EBS优化型实例，或者是拥有明确标注为10Gbps的网卡的类型的实例，而且你的EBS磁盘的IO带宽至少得超过你预设的IOPS。另一个你没有得到你预设的IOPS数值的原因很可能是因为你读写操作次数根本就没达到磁盘的上限，这样也就没法测量出EBS卷的真实IOPS表现。

DynamoDB中的二级索引(global secondary index)

Refer to: https://blog.csdn.net/vikings_1001/article/details/48675945

IPSEC Tunnel

IPSec VPN是目前VPN技术中点击率非常高的一种技术，同时提供VPN和信息加密两项技术。

IPSec VPN的应用场景分为3种：
1. Site-to-Site（站点到站点或者网关到网关）：如湾区评论的3个机构分布在互联网的3个不同的地方，各使用一个网关相互建立VPN隧道，企业内网（若干PC）之间的数据通过这些网关建立的IPSec隧道实现安全互联。
2. End-to-End（端到端或者PC到PC）：两个PC之间的通信由两个PC之间的IPSec会话保护，而不是网关。
3. End-to-Site（端到站点或者PC到网关）：两个PC之间的通信由网关和异地PC之间的IPSec进行保护。

VPN只是IPSec的一种应用方式，IPSec其实是IP Security的简称，它的目的是为IP提供高安全性特性，VPN则是在实现这种安全特性的方式下产生的解决方案。 IPSec是一个框架性架构，具体由两类协议组成：
1. AH协议（Authentication Header，使用较少）：可以同时提供数据完整性确认、数据来源确认、防重放等安全特性；AH常用摘要算法（单向Hash函数）MD5和SHA1实现该特性。
2. ESP协议（Encapsulated Security Payload，使用较广）：可以同时提供数据完整性确认、数据加密、防重放等安全特性；ESP通常使用DES、3DES、AES等加密算法实现数据加密，使用MD5或SHA1来实现数据完整性。

为何AH使用较少呢？因为AH无法提供数据加密，所有数据在传输时以明文传输，而ESP提供数据加密；其次AH因为提供数据来源确认（源IP地址一旦改变，AH校验失败），所以无法穿越NAT 。当然，IPSec在极端的情况下可以同时使用AH和ESP实现最完整的安全特性，但是此种方案极其少见。

IPSec封装模式介绍完IPSec VPN的场景和IPSec协议组成，再来看一下IPSec提供的两种封装模式（传输Transport模式和隧道Tunnel模式）

可以发现传输模式和隧道模式的区别：
1. 传输模式在AH、ESP处理前后IP头部保持不变，主要用于End-to-End的应用场景。
2. 隧道模式则在AH、ESP处理之后再封装了一个外网IP头，主要用于Site-to-Site的应用场景。

从上图我们还可以验证上一节所介绍AH和ESP的差别。下图是对传输模式、隧道模式适用于何种场景的说明。

从这张图的对比可以看出：
1. 隧道模式可以适用于任何场景
2. 传输模式只能适合PC到PC的场景
隧道模式虽然可以适用于任何场景，但是隧道模式需要多一层IP头（通常为20字节长度）开销，所以在PC到PC的场景，建议还是使用传输模式。
为了使大家有个更直观的了解，我们看看下图，分析一下为何在Site-to-Site场景中只能使用隧道模式：

如上图所示，如果发起方内网PC发往响应方内网PC的流量满足网关的兴趣流匹配条件，发起方使用传输模式进行封装：
1. IPSec会话建立在发起方、响应方两个网关之间。
2. 由于使用传输模式，所以IP头部并不会有任何变化，IP源地址是192.168.1.2，目的地址是10.1.1.2。
3. 这个数据包发到互联网后，其命运注定是杯具的，为什么这么讲，就因为其目的地址是10.1.1.2吗？这并不是根源，根源在于互联网并不会维护企业网络的路由，所以丢弃的可能性很大。
4. 即使数据包没有在互联网中丢弃，并且幸运地抵达了响应方网关，那么我们指望响应方网关进行解密工作吗？凭什么，的确没什么好的凭据，数据包的目的地址是内网PC的10.1.1.2，所以直接转发了事。
5. 最杯具的是响应方内网PC收到数据包了，因为没有参与IPSec会话的协商会议，没有对应的SA，这个数据包无法解密，而被丢弃。
我们利用这个反证法，巧妙地解释了在Site-to-Site情况下不能使用传输模式的原因。并且提出了使用传输模式的充要条件：兴趣流必须完全在发起方、响应方IP地址范围内的流量。比如在图中，发起方IP地址为6.24.1.2，响应方IP地址为2.17.1.2，那么兴趣流可以是源6.24.1.2/32、目的是2.17.1.2/32，协议可以是任意的，倘若数据包的源、目的IP地址稍有不同，对不起，请使用隧道模式。

IPSec协商

IPSec除了一些协议原理外，我们更关注的是协议中涉及到方案制定的内容：
1. 兴趣流：IPSec是需要消耗资源的保护措施，并非所有流量都需要IPSec进行处理，而需要IPSec进行保护的流量就称为兴趣流，最后协商出来的兴趣流是由发起方和响应方所指定兴趣流的交集，如发起方指定兴趣流为192.168.1.0/24à10.0.0.0/8，而响应方的兴趣流为10.0.0.0/8à192.168.0.0/16，那么其交集是192.168.1.0/24à10.0.0.0/8，这就是最后会被IPSec所保护的兴趣流。
2. 发起方：Initiator，IPSec会话协商的触发方，IPSec会话通常是由指定兴趣流触发协商，触发的过程通常是将数据包中的源、目的地址、协议以及源、目的端口号与提前指定的IPSec兴趣流匹配模板如ACL进行匹配，如果匹配成功则属于指定兴趣流。指定兴趣流只是用于触发协商，至于是否会被IPSec保护要看是否匹配协商兴趣流，但是在通常实施方案过程中，通常会设计成发起方指定兴趣流属于协商兴趣流。
3. 响应方：Responder，IPSec会话协商的接收方，响应方是被动协商，响应方可以指定兴趣流，也可以不指定（完全由发起方指定）。
4. 发起方和响应方协商的内容主要包括：双方身份的确认和密钥种子刷新周期、AH/ESP的组合方式及各自使用的算法，还包括兴趣流、封装模式等。
5. SA：发起方、响应方协商的结果就是曝光率很高的SA，SA通常是包括密钥及密钥生存期、算法、封装模式、发起方、响应方地址、兴趣流等内容。

我们以最常见的IPSec隧道模式为例，解释一下IPSec的协商过程：

上图描述了由兴趣流触发的IPSec协商流程，原生IPSec并无身份确认等协商过程，在方案上存在诸多缺陷，如无法支持发起方地址动态变化情况下的身份确认、密钥动态更新等。伴随IPSec出现的IKE（Internet Key Exchange）协议专门用来弥补这些不足：
1. 发起方定义的兴趣流是源192.168.1.0/24目的10.0.0.0/8，所以在接口发送发起方内网PC发给响应方内网PC的数据包，能够得以匹配。
2. 满足兴趣流条件，在转发接口上检查SA不存在、过期或不可用，都会进行协商，否则使用当前SA对数据包进行处理。
3. 协商的过程通常分为两个阶段，第一阶段是为第二阶段服务，第二阶段是真正的为兴趣流服务的SA，两个阶段协商的侧重有所不同，第一阶段主要确认双方身份的正确性，第二阶段则是为兴趣流创建一个指定的安全套件，其最显著的结果就是第二阶段中的兴趣流在会话中是密文。

IPSec中安全性还体现在第二阶段SA永远是单向的：

从上图可以发现，在协商第二阶段SA时，SA是分方向性的，发起方到响应方所用SA和响应放到发起方SA是单独协商的，这样做的好处在于即使某个方向的SA被破解并不会波及到另一个方向的SA。这种设计类似于双向车道设计。
IPSec虽然只是5个字母的排列组合，但其所涉及的协议功能众多、方案又极其灵活，本期主要介绍IPSec的基本原理，在后续专栏还会继续介绍IPSec的其它方面知识。

Refer to: https://blog.csdn.net/Walking_Thinker/article/details/79127902

AWS Management Portal for vCenter

Option 1: Federation Authentication Proxy

You can set up the management portal to authenticate users using the AWS Connector for vCenter.

Your users don't have direct access to AWS resources. Instead, the vSphere client gets the user's information from your vCenter server and assumes an AWS Identity and Access Management (IAM) role to get temporary AWS security credentials for the user. The following diagram illustrates this process.

Federation authentication proxy

The user signs in to vCenter, clicks Home , and then clicks AWS Management Portal . The vSphere client sends an authentication request to the connector.
The connector authenticates the user.
The connector requests temporary security credentials from AWS Security Token Service (AWS STS).
AWS STS sends the connector temporary security credentials for the user.
Users are granted access to AWS resources based on the permissions assigned to them by an administrator.

Option 2: SAML-Based Authentication

You can set up the management portal to authenticate users using your identity provider (IdP).

Your users don't have direct access to AWS resources. Instead, the vSphere client gets the user's information from your identity store and uses a SAML assertion to grant the user access to AWS Management Portal for vCenter. The following diagram illustrates this process.

SAML-based authentication

The user signs in to vCenter, clicks Home , and then clicks AWS Management Portal . The vSphere client sends an authentication request to the IdP.
The IdP authenticates the user.
The IdP generates a SAML authentication response that includes assertions that identify the user and provide information about the user.
The vSphere client posts the SAML assertion to an AWS single sign-on (SSO) endpoint. The endpoint requests temporary security credentials from AWS Security Token Service (AWS STS) and creates a console sign-in URL.
AWS sends the console a sign-in URL to the vSphere client with a redirect.
The management portal grants users access to AWS resources based on the permissions assigned to them by an administrator.