在AWS上运行用户提交代码的策略及安全问题咨询

方案1：动态创建/删除AWS Lambda函数 #

• 权限过度授权：如果给动态生成的Lambda函数分配了过宽的IAM权限，用户提交的代码就能调用S3、EC2等AWS服务，引发数据泄露或资源滥用问题。
• 部署残留敏感信息：打包用户代码时若不慎混入本地测试密钥、配置文件，会直接将敏感内容暴露给用户。
• 资源耗尽攻击：恶意用户提交无限循环类代码，虽Lambda会自动终止，但高频创建/销毁函数操作可能触发AWS资源配额报警，还会产生意外账单。

方案2：单用户对应独立EC2实例 #

• 实例配置不当风险：比如EC2开放不必要端口、使用默认密钥对，或未禁用IMDSv1，用户代码可突破进程限制，获取实例控制权，甚至横向渗透至其他AWS资源。
• IAM角色权限过松：EC2绑定的IAM角色权限过大时，用户代码能通过实例元数据服务拿到临时凭证，调用AWS服务执行删除数据、修改配置等敏感操作。
• 实例销毁不及时：用户交互结束后未立刻销毁实例，残留的代码、数据可能被后续用户或攻击者利用。

方案3：EC2实例+Docker容器（必要性分析） #

额外添加Docker隔离层有实际价值：

• Docker提供进程级隔离，即便用户代码突破应用层限制，也难以获取EC2实例的系统权限，降低横向渗透风险。
• 若后续调整架构为多用户容器共享单台EC2，Docker能确保不同用户代码完全隔离，避免资源或数据互扰。
• 但如果严格执行单用户单EC2，且实例配置足够安全（如最小权限IAM、禁用不必要系统调用），Docker的隔离效果会被EC2本身覆盖，此时必要性有所降低。

用户若获取到Lambda或EC2中的环境变量，会引发以下严重问题：

• AWS资源被滥用：如果环境变量包含AWS凭证或IAM临时密钥，用户可调用AWS服务创建资源、删除数据、访问S3敏感内容，轻则数据泄露，重则产生巨额账单。
• 内部系统被入侵：若存在数据库连接串、内部API密钥，用户可直接访问后端数据库窃取/篡改数据，或滥用内部服务权限。
• 平台控制权丢失：如果环境变量包含平台管理员密钥或核心配置，用户可能直接掌控整个代码运行平台，篡改其他用户代码或窃取平台敏感数据。

从安全、成本、维护性维度考虑，推荐以下方案：

• AWS Fargate无服务器容器：无需管理EC2实例，每个用户代码运行在独立隔离容器中，最长支持180天运行时长（远超Lambda的15分钟限制），按实际资源使用付费。为每个容器分配最小权限IAM角色，避免过度授权。
• 强化容器沙箱：在容器中启用seccomp、AppArmor等安全机制，限制用户代码的系统调用（如禁止外部网络访问、禁止文件系统写入），进一步缩小攻击面。
• 敏感信息托管：避免将敏感配置放入环境变量，改用AWS Secrets Manager或Parameter Store存储，仅给运行代码的容器/函数分配读取特定密钥的最小权限。
• 硬件级隔离沙箱：若需更严格的隔离，可基于AWS Nitro Enclaves创建硬件级隔离环境，确保用户代码无法访问宿主系统或其他用户资源。

内容的提问来源于stack exchange，提问作者Ben Chomsang