一、背景
Amazon Bedrock Inference Profile功能是2024年底推出的一项功能，在诞生之初，主要用于实现跨Region推理，而通过给Profile增加Tag的方式，即可实现费用追踪。
一、背景
在配置邮件客户端的过程中，连接邮箱时除了输入域名、用户名、密码之外，通常需要手工填写收发邮件的服务器地址。此时如果打开了Auto Discover也就是自动发现功能，就能无需手工输入，邮件客户端将自动识别服务器地址，大大简化了配置过程。目前电脑上在用的邮件客户端、手机上的邮件客户端都具备自动发现功能。
当使用Amazon Workmail提供邮箱服务的时候，默认是不开启Auto Discover功能的，需要手工配置。本文介绍如何配置。
本文介绍如何为Amazon Workmail启用IAM Identity Center并开启MFA多因素认证。
一、背景
Amazon Workmail邮件系统自身有内部的目录服务，可用于用户数量较少的快速部署和使用。在此时登录界面上是不支持配置MFA的。即便点击Workmail的设置图标，在其中也无法找到开启MFA的选项。这是由于Amazon Workmail内置的目录认证服务是不支持MFA的。
为了开启MFA，需要将Amazon Workmail配置为使用IAM Identity Center服务（以前叫做AWS Single Sign-On即SSO，以下简称IdC服务），并在IdC服务中管理用户和分组。此时在IdC服务中，可以设置用户第一次登录时候必须强制绑定MFA，即可满足安全合规要求。IdC服务支持主流的软件MFA，例如Microsoft Authenticator，Google Authenticator等手机APP，也支持硬件形式的USB Token。
下面开始配置。
SageMaker Studio 对多用户并行开发的权限管理方式之一，是可以与企业现有单点认证系统对接，然后每个企业目录的用户就可以直接对应到一个SageMaker Studio内的Notebook。在这种对接方式下，SageMaker Studio首先与IAM Identity Center（IdC）集成，然后使用 External Source 连接外部的Identity Source，即可实现第三方SSO对接。
本文使用OKTA作为第三方SSO平台，演示SageMaker Studio对接使用体验。请参考视频。
另外，在不使用SageMaker Studio的情况下，还可以将AWS Console控制台配置直接对接到企业的SSO。此时配置方式是使用IAM内置的Identity Provider功能，对接到企业自有SSO。
本文使用OKTA作为第三方SSO平台，演示AWS Console的SSO对接体验。请参考视频。
在一些信息系统审计中，可能会被要求提交“S3存储是一个被动式系统”、“S3不会主动向外发起网络连接”、“S3不会执行存储的可执行文件”等证明资料。建议通过S3合规性最佳实践进行系统的解答。
本文展示了一个MCP Server和Client的运行交互过程，通过Step-by-step的打印日志，帮助理解MCP是如何工作的。本文引用的代码参考文中的Github链接。
一、背景
在上一篇博客《使用VPC Traffic Mirror功能进行流量审计》中，我们介绍了使用VPC Traffic Mirror采集7层访问日志，不过采集架构局限在单VPC、单EC2。
那么如何构建一个跨VPC、多VPC、跨账号专门的日志采集架构？本文解答这一需求的设计。
一、背景
1、使用Traffic Mirror的场景
对于简单的网络流量采集需求，可以使用VPC Flowlog功能，之前这篇博客介绍了VPC Flowlog的使用。不过VPC Flowlog也有局限，主要是仅记录OSI模型的第四层的日志信息，也就是所谓的“五元组”，即源地址、源端口、目标地址、目标端口、协议这五要素，很多时候不能满足日志需求。
如果需求进一步增加要求如下日志能力：
- 7层流量采集，记录域名、HTTP header等
- 旁路方式，不影响流量
- 相对低成本
- 不希望使用复杂的Network Firewall或者第三方NGFW+Gateway Load Balancer方案
以上需求场景，适合使用VPC Traffic Mirror实现。
一、针对S3存储的勒索攻击事件背景
近期有一片文章《亚马逊安全机制被用于勒索攻击，全球数千家机构已成为攻击目标》，原文在这里。引用部分文字如下：
据报道，勒索组织已经开始加密全球数千家机构在亚马逊云存储的数据。
与传统的勒索软件攻击不同，此次攻击没有利用任何系统漏洞，
而是利用了亚马逊云服务本身的安全机制，制造了一个几乎无法破解的困境，
迫使受害者不得不选择支付赎金。
勒索组织首先获取了受害者的亚马逊账户凭证，
这些凭证具有读取存储数据和写入加密工具的权限。
随后，他们利用亚马逊的服务器端加密工具（SSE-C）将客户的数据重新加密，
使用户无法正常访问，并向要求受害者在七天内支付赎金，
否则将永久删除所有加密文件。
这篇文章对整个攻击事件过程描述的比较模糊，文中提到“勒索组织首先获取了受害者的亚马逊账户凭证”，但转而又提到“此次攻击没有利用任何系统漏洞，而是利用了亚马逊云服务本身的安全机制”。这两句前后矛盾的表述让许多人感到困惑，并担心自身系统安全。
为此，AWS官方也有一篇博客针对类似攻击事件给出了一些信息，英文原文在这里。基于这两篇文章，本文介绍下类似勒索攻击的由来，以及类似的防护方法。
一、背景
在一些对数据安全有较高要求的场景中，需要对S3上的数据进行加密。有时候可能会遇到以下需求：
- 合规要求，必须加密
- 强度要高，例如AES256
- 加密要简单，最好是对称密钥，加密和解密都是同一个密码
- 与IDC、多云等兼容性问题，不能使用AWS KMS服务来管理密钥，用户自管理密钥
- 不希望编写加密代码
- 不希望应用层承担加密运算的开销
在以上情况下，可使用S3服务的SSE-C功能来满足以上加密需求。
此时可能有同学有疑问，在创建S3存储桶界面上选择加密算法的位置，并没有SSE-C加密方式的选项，那么它是如何运作的？这要从S3的几种加密方式说起。