事件时的程序AWS 安全事

shakibalhasan75

件响应指南是一个很好的起点 没有自定义 IAM 用户和角色来执行具有最低权限的特定操作 使用普通 AWS IAM 用户执行不相关的操作非常简单且诱人因为您已经拥有用户的凭证。 然而这是一个安全风险如果凭证落入攻击者手中它会增加攻击者可能造成的损害面。 避免这个陷阱的建议 为每个新操作创建一个新的 IAM 用户帐户并仅启用程序化帐户的密钥访问 对于真人使用的用户帐户默认启用FA因素身份验证 授予帐户工作的最低权限并在需要时添加权限 记录 IAM 管理员登录和其他关键事件 职业转变我如何成为一名 Web 开发人员 读这个故事 没有针对需要相互通信的资源的自定义安全组 当然您的 AWS 资源有时需要与其他 AWS 资源进行通信。 例如公司的 CMS 平台的 EC 服务器需要与 RDS 。

实例和 Memcached 实例通信。 一个配置不当的系统只会有一个安全组所有资源都会添加到该安全组中从而允许潜在攻击者在获得一个安全组后访问所有 AWS 资源。 避免这个陷阱的建议 创建自定义安全组以便资源仅获得正常运行所需的最小访问权限。例如EC、RDS 和 Memcached 实例 阿尔巴尼亚 WhatsApp 号码 可以位于安全组中。 资源和安全组上不必要的开放端口 作为日常功能的一部分Web 服务使用带有端口号 的TCP 或 UDP 端口。 客户端应用程序需要连接到此端口才能进行通信和传输数据。例如端口  用于 SSH 会话端口  用于  流量而端口  用于 S 流量。 这些是默认端口没有什么可以阻止我们重新分配它们尽管这会破坏不知道更改的客户端的兼容性。 但是这些端口容易出现潜在的错误配置这可能会损害您的 AWS 安全。 这些例子有 对互。



联网开放的端口可用于收集有关正在运行的服务的信息 过时的服务经常包含可被利用的安全漏洞 避免这个陷阱的建议 仅根据具体情况开放端口 禁用面向互联网的应用程序上的横幅曝光 如果通过开放端口公开的应用程序没有自动更新例如手动安装在 EC 服务器上的软件包那么保持其更新很重要这就是我所说的“绿色维护的一部分。本质上greenkeeping 是定期的代码和代码依赖项维护。 不安全/未经身份验证的 Lambda AWS Lambda 是无服务器函数即独立服务不与Ruby on Rails应用程序共享相同的身份验证机制。 这样做的结果可能是您公司的 Web 开发人员忘记在 Lambda 上实施任何类型的有意义的身份验证。 这会导致以下问题 Lambda 使用不安全或更糟糕的方式不对服务请求进行身份验证 Lambda 使用平面密钥身。