云上堡垒：如何用AWS原生服务构筑坚不可摧的主机安全体系

王义杰
0 阅读6分钟

引言：主机安全的“最后⼀公⾥”挑战

在运维和安全领域，我们经常谈论网络防火墙、WAF、DDoS防护，这些构成了我们云上应用的第一道防线。但真正的攻防对抗中，主机本身的安全，往往是决定成败的“最后一公里”。

正如许多审计和合规要求（如PCI-DSS, ISO 27001）所强调的，我们需要确保：

  1. 访问受控：谁能登录服务器？他们用了什么权限？
  2. 操作可追溯：登录后执行了哪些命令？对系统做了什么更改？
  3. 日志不丢失：所有系统和应用日志都必须被集中、安全地存储，防止被篡改或删除。

传统方案通常依赖于跳板机（Bastion Host）和部署独立的第三方Agent。但这些方案不仅管理复杂、成本高昂，而且跳板机本身也可能成为单点故障和攻击目标。

那么，在AWS上，我们有没有更原生、更优雅的解决方案呢？答案是肯定的。今天，我们就来聊聊如何利用 AWS Systems Manager (SSM) 和 Amazon CloudWatch 这对“黄金搭档”，构建一个几乎坚不可摧的主机安全和审计体系。

image.png

核心利器一：AWS Systems Manager Session Manager

忘掉SSH密钥和开放的22端口吧！Session Manager 是AWS Systems Manager的一个功能，它彻底改变了我们访问EC2实例（无论是Linux还是Windows）的方式。

它是如何解决核心痛（dian）的？

  1. 告别公网暴露：使用Session Manager，我们不再需要在安全组里开放SSH（22）或RDP（3389）端口。所有访问都通过一个加密的SSM通道进行，实例甚至可以放在私有子网中，极大地减少了攻击面。
  2. 精细的权限控制：结合AWS IAM (Identity and Access Management)，我们可以精确控制谁可以启动会话、可以访问哪些实例、甚至可以以哪个操作系统用户（如 ssm-user）的身份运行命令。
  3. 完整的会话审计：这是最关键的功能！Session Manager可以将每一次会话的所有输入输出（没错，我们敲的每一个字符和系统的每一次返回）都完整地记录下来，并自动发送到 Amazon S3 或 CloudWatch Logs。

这意味着，再也没有“黑箱操作”。任何管理员的任何行为，都有据可查，无法抵赖。

核心利器二：Amazon CloudWatch Agent

有了操作命令的审计，我们还需要收集主机的系统日志、安全日志和应用日志。这就轮到 CloudWatch Agent 登场了。

与SSM Agent（通常已预装在大多数Amazon Machine Image (AMI) 中）不同，CloudWatch Agent需要手动安装和配置，但它功能强大：

  1. 日志集中化：它可以从指定的文件和路径（如 Linux的 /var/log/secure、/var/log/messages，或Windows的事件日志）收集日志数据。
  2. 实时传输：Agent会将收集到的日志近乎实时地推送到CloudWatch Logs中。日志一旦离开发生源主机，就很难被攻击者篡改或清除了。
  3. 统一的分析平台：所有日志汇集到CloudWatch Logs后，我们可以使用CloudWatch Logs Insights进行强大的查询和分析，设置告警（例如，检测到多次失败的sudo尝试），或将日志流式传输到S3进行长期归档，或传输到Amazon OpenSearch等服务进行更复杂的可视化分析。

实战演练：三步配置一个安全可审计的EC2实例

光说不练假把式。下面我们通过一个具体的例子，展示如何配置这一切。

目标：创建一个Linux EC2实例，我们可以通过Session Manager免密登录，并且所有操作命令和系统安全日志（/var/log/secure）都会被自动记录。

第一步：创建具备“神力”的IAM角色

这是最关键的一步。权限是安全的基石。我们需要创建一个IAM角色，并将其附加到EC2实例上，赋予它与SSM和CloudWatch通信的权限。

  1. 访问AWS IAM控制台，创建一个新角色。
  2. 选择“AWS service”作为可信实体，用例选择“EC2”。
  3. 在添加权限策略时，搜索并附加两个AWS托管策略：
    • AmazonSSMManagedInstanceCore：这是SSM Agent正常工作的核心权限。
    • CloudWatchAgentServerPolicy：这允许EC2实例上的Agent向CloudWatch写入日志和指标。
  4. 为角色命名（例如 EC2-SSM-CloudWatch-Role）并创建它。

第二步：配置Session Manager会话日志记录

现在，我们来告诉SSM把会话日志存到哪里。

  1. 访问AWS Systems Manager控制台。
  2. 在左侧导航栏中，找到“Session Manager”，点击“Preferences”选项卡。
  3. 在这里，我们可以配置日志记录。强烈建议启用它！
    • CloudWatch Logs：选择此项，我们可以指定一个Log Group（如果不存在，SSM会自动创建）。日志在这里易于搜索和告警。
    • S3 Bucket：选择此项，指定一个S3存储桶。S3成本更低，适合长期、不可变的审计归档。
    • 最佳实践：可以同时启用两者，兼顾实时分析和长期合规。

第三步：配置并启动CloudWatch Agent

  1. 启动EC2实例：启动一个新的Amazon Linux 2实例，在配置时，务必在“IAM instance profile”处选择我们刚刚创建的 EC2-SSM-CloudWatch-Role 角色。确保SSM Agent正在运行（默认情况下是的）。

  2. 创建CloudWatch Agent配置文件：我们需要告诉Agent要收集什么日志。这个配置通常保存在SSM Parameter Store中，方便统一管理。

    • 在SSM控制台，进入“Parameter Store”，创建一个新参数。
    • 命名为 AmazonCloudWatch-Linux-Config (这是一个约定的名字)。
    • 在值（Value）中，粘贴以下JSON配置。这个配置告诉Agent去收集 /var/log/secure 文件，并将其发送到名为 /ec2/security/secure-logs 的日志组。
    {
  "agent": {
    "run_as_user": "root"
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/secure",
            "log_group_name": "/ec2/security/secure-logs",
            "log_stream_name": "{instance_id}",
            "timezone": "Local"
          }
        ]
      }
    }
  }
}

  3. 在EC2上安装并启动Agent：

    • 使用Session Manager连接到我们的实例（看，已经用上了！）。在EC2控制台选中实例，点击“Connect”，选择“Session Manager”页签即可连接。
    • 运行命令安装Agent： 
      sudo yum install -y amazon-cloudwatch-agent
    • 运行命令，使用我们存储在Parameter Store中的配置来启动Agent： 
      sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-Linux-Config
    • 现在，Agent就会在后台默默工作，将安全日志源源不断地送往CloudWatch。

结论：化繁为简，安全原生

通过上面简单的三步，我们实现了一个强大的主机安全审计系统：

  • 无密钥、无端口暴露的安全访问。
  • 不可篡改的完整命令审计记录。
  • 集中化的系统安全日志收集。

这套方案几乎完全依赖AWS原生服务，不仅大大降低了管理复杂度和成本，其稳定性和安全性也由AWS本身保障。它回答了文章开头提出的所有问题：服务（SSM Agent）权限高，难以被普通用户停止；操作命令和系统日志都被实时传输到了远程审计系统（S3和CloudWatch）。

对于任何在AWS上运行关键业务的企业来说，这套方案都应该成为其安全架构的标配。赶紧动手试试，为我们的云上主机建起一座坚不可摧的堡垒吧！

avatar
文章
阅读
粉丝