rds-sqlserver

Amazon RDS for SQL Server

安全指南

当用户提出请求时，本技能涵盖创建和修改 RDS for SQL Server 资源。执行前，Agent 必须向用户确认操作。未经用户明确确认（例如“是”“继续”“已确认”“开始吧”），不得执行任何创建或修改操作。如果用户尚未确认，请说明计划执行的操作并征求批准。

用户确认后执行这些操作

• 创建实例：create-db-instance（需要 DB 子网组；RDS SQL Server 仅限 VPC，默认无法公开访问）
• 创建自定义参数组：create-db-parameter-group（系列为 sqlserver-ex-15.00、sqlserver-se-15.00 等）——用于设置 rds.force_ssl=1 等参数
• 创建选项组：create-option-group（用于 TDE、S3 集成、SQLServer Audit、Native Backup/Restore、SSIS、SSAS、SSRS）
• 创建 RDS Proxy：create-db-proxy、register-db-proxy-targets（用于 SQL Server 前端的 IAM DB 身份验证——请参阅 rds-proxy 参考）
• 创建用于 Windows 身份验证的 AWS Managed Microsoft AD 目录：create-directory（然后通过 modify-db-instance --domain 关联）
• 创建带轮换功能的 Secrets Manager 密钥：create-secret、rotate-secret --rotation-rules AutomaticallyAfterDays=N
• 更改备份保留期、删除保护和日志导出：modify-db-instance --backup-retention-period / --deletion-protection / --cloudwatch-logs-export-configuration
• 附加/分离参数组或选项组：modify-db-instance --db-parameter-group-name / --option-group-name
• 为资源添加标签：add-tags-to-resource、remove-tags-from-resource

资源标签（创建资源时始终应用）

创建任何 RDS for SQL Server 资源时（create-db-instance、create-db-parameter-group、create-option-group、create-db-proxy、用于 RDS 凭证的 create-secret、用于 Windows 身份验证的 create-directory），始终使用 RDS 的记录列表 --tags 语法包含以下标签（AWS Directory Service 和 Secrets Manager 使用相同格式）：

--tags Key=created_by,Value=rds-sqlserver-skill Key=generation_model,Value={your-model-id}

示例：--tags Key=created_by,Value=rds-sqlserver-skill Key=generation_model,Value=claude-sonnet-4-20250514

即使用户未提及标签，也要包含这些标签，以便用户识别通过本技能创建的资源。如果用户提供了其他标签，请将这些标签追加到用户提供的标签中，而非替换它们。通过 add-tags-to-resource 为现有资源添加标签时也适用此规则。

执行前警告用户停机风险，并在用户确认后执行

• 更改实例类：modify-db-instance --db-instance-class——警告：“这会导致 Multi-AZ 配置发生故障转移，并使单可用区实例短暂不可用。”
• 升级次要引擎版本：在同一主版本内使用 modify-db-instance --engine-version（例如，15.00.4X → 15.00.4Y）——警告：“这会触发重启，可能导致短暂中断。”
• 更改存储类型或 IOPS：modify-db-instance --storage-type / --iops / --allocated-storage——警告：“应用此更改期间，IO 性能可能会持续下降。”
• 立即应用：任何 modify-db-instance --apply-immediately 操作——警告：“这会在维护时段之外应用更改，可能立即导致停机。”
• 加入/退出域：modify-db-instance --domain / --disable-domain——警告：“这会重启实例。”

请勿执行（应拒绝，说明原因，并改为提供评估）

• 删除实例：delete-db-instance — 会导致不可逆的数据丢失
• 删除自动备份：delete-db-instance --delete-automated-backups — 会销毁时间点恢复历史记录
• 故障转移：reboot-db-instance --force-failover — 会影响生产环境
• 主版本升级：跨主版本执行 modify-db-instance --engine-version（例如，15.0 → 16.0）——需要预检查和回滚计划；应通过变更控制流程进行
• 重启：reboot-db-instance — 会影响生产环境
• 启用公共可访问性：modify-db-instance --publicly-accessible true — 会降低安全性；请使用 SSM 端口转发、VPN 或 Direct Connect

拒绝时，请说明原因，并提供相应的评估工作流：

“我无法执行[操作]，因为[原因]。我可以运行评估来帮助你做出决定。实际变更应通过团队的变更控制流程或 AWS Console 进行。”

概述

Amazon RDS for SQL Server 是 AWS 提供的托管 SQL Server 服务。此技能涵盖将应用程序连接到 RDS for SQL Server 的端到端工作流：驱动程序选择、连接字符串、SSL/TLS 加密、SQL 和 Windows 身份验证、通过 RDS Proxy 进行 IAM 身份验证、连接池、VPC 网络、适用于 EC2 / ECS / Lambda / EKS 的部署模式，以及常见错误模式的故障排除。

此技能可直接配合 AWS CLI 使用。建议使用 AWS MCP 服务，但并非必需——在可用时，它可提供沙盒执行、CloudTrail 审计和可观测性。

常见任务

1. 验证依赖项

检查所需工具，并在缺少任何工具时告知用户。

限制：

• 你必须验证 AWS CLI 是否可用（aws --version）
• 如果缺少 AWS CLI，你必须告知用户，因为大多数步骤都需要访问 AWS API
• 如果 AWS MCP 服务工具（call_aws、suggest_aws_commands）可用，优先使用这些工具进行审计和可观测性——但并非必需

2. 分类并路由

收集连接上下文，并路由到相应的子技能参考文件。

参数：

• language（必填）：python | dotnet | java | nodejs。根据项目文件推断（requirements.txt/*.py → python；*.csproj → dotnet；pom.xml/build.gradle → java；package.json → nodejs）。仅在无法明确判断时询问。
• runtime（必填）：ec2 | ecs | lambda | eks | laptop。决定网络和密钥模式。
• auth（必填）：sql | windows-kerberos | windows-ntlm | iam-proxy。除非用户提及 Active Directory、Kerberos、NTLM 或 IAM，否则默认为 sql。
• region（必填）：AWS 区域，例如 us-east-1。
• db_instance_id（故障排除时必填）：RDS 实例标识符。

限制：

• 你必须在单次提示中一次性询问所有必填参数，因为反复提问会让用户感到沮丧
• 有项目文件可用时，你必须根据这些文件推断 language，而不是询问用户
• 继续操作前，你必须根据 AWS 区域枚举列表验证 region
• 除非用户明确表示要使用 Windows 身份验证、IAM 身份验证或 Active Directory，否则你应默认采用 SQL 身份验证

子技能路由

加载且仅加载一个驱动程序参考文件，以及任何相关的主题参考文件：

用户正在进行的操作	加载
Python / pymssql / pyodbc	references/python.md
.NET / C# / Microsoft.Data.SqlClient	references/dotnet.md
Java / JDBC / mssql-jdbc	references/java.md
Node.js / tedious / mssql	references/nodejs.md
EC2 托管	references/ec2-vpc.md
Lambda 托管	references/lambda-vpc.md
ECS 或 Fargate 托管	references/ecs-fargate-vpc.md
通过 SSM 隧道连接笔记本电脑	references/ssm-tunneling.md
SSL/TLS、rds.force_ssl、证书	references/encryption.md
Windows / AD / Kerberos / NTLM	references/ad-kerberos.md
跨 VPC、Transit Gateway、VPC 对等连接	references/networking.md
SQL 身份验证、Secrets Manager、凭证	references/connection-auth.md
IAM 身份验证、RDS Proxy、连接池	references/rds-proxy.md
错误、连接失败、Kerberos 回退到 NTLM	references/troubleshooting.md

3. 执行工作流

按顺序遵循已加载参考文件中的步骤：驱动程序设置 → 网络 → 身份验证 → 密钥 → 验证。

约束：

• 所有连接都必须使用 TLS 1.2 或更高版本，因为较旧的 TLS 版本存在已知漏洞
• 必须从 AWS Secrets Manager 获取凭证，而不是将密码嵌入代码，因为硬编码的密钥会泄漏到日志和源代码管理中
• 在生产环境中，必须设置 Encrypt=Mandatory（.NET）/ encrypt=true（JDBC）/ encryption="require"（pymssql）/ encrypt: true（tedious），因为机会性加密可能会在不提示的情况下回退到明文
• 必须使用 RDS CA 捆绑包 https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem 验证服务器证书链，而不是在生产环境中设置 TrustServerCertificate=true，因为禁用验证会使你面临中间人攻击
• 绝不能在 DB 实例上启用 PubliclyAccessible: true，因为这会将 SQL Server 端口 1433 暴露到公共互联网
• 对于同一 VPC 内的访问，必须将安全组 ID 用作源；对于通过 Transit Gateway 或 VPC 对等连接实现的跨 VPC 访问，必须使用 CIDR 网段，因为安全组引用无法跨越 VPC 边界
• 绝不能直接对 RDS for SQL Server 使用 IAM 身份验证，因为 RDS for SQL Server 不支持此功能 — IAM 身份验证要求在实例前端使用 RDS Proxy
• 必须从已加入域的主机（EC2 或客户端）测试 Windows 身份验证，不能通过 SSM send-command 测试，因为 SSM 以系统账户运行，而不是以用户的 AD 身份运行
• 两种方式都可用时，应该优先选择 Kerberos 而不是 NTLM，因为 Kerberos 的加密强度更高，也更便于审计
• 如果应用程序需要 Kerberos/Windows 身份验证，应该使用 pyodbc 而不是 pymssql，因为 pymssql 不支持 Kerberos

评分标准关键事实，务必说明

以下 RDS for SQL Server 专属事实可将此技能与通用 SQL Server 知识区分开来。每个清单中的内容都是评分标准在对应测试场景中会评估的要点。

对于“无法从 EC2 连接到 RDS SQL Server — SSMS 超时”，必须向用户说明以下全部六项事实，并且必须进行系统性排查，而不是直接罗列通用清单：

1. 询问用户正在排查哪个 RDS 实例，以及哪个源 EC2 实例——没有这两个标识符，切勿开始排查。未根据用户的实际资源界定诊断范围的通用检查清单，会被评分标准判定为失败。
2. 检查 EC2 与 RDS 之间的 VPC 和子网连通性（位于同一 VPC，或通过 VPC 对等连接／Transit Gateway 建立可路由的路径）。
3. RDS 的安全组允许来自 EC2 安全组的 1433 入站流量（按安全组 ID 配置，而不是按 CIDR 配置）。安全组规则是最常见的修复方法。
4. 从 EC2 检查 RDS 端点的 DNS 解析——在 EC2 上运行 nslookup <rds-endpoint>，并确认返回的是私有 IP。
5. 检查 1433 端口的 TCP 连通性——在 PowerShell 中运行 Test-NetConnection -ComputerName <rds-endpoint> -Port 1433，或运行 telnet <rds-endpoint> 1433。如果 DNS 正常但此项失败，问题出在安全组或 NACL。
6. 仅当实例位于公有子网时，才检查公有可访问标志——检查 describe-db-instances 中的 PubliclyAccessible；位于私有子网的公有端点无法访问。
7. 如果默认协议出现异常，建议在 SSMS 中选择“Options → Connection Properties → Network Protocol = TCP/IP”。回复中必须包含这一条特定的 SSMS 对话框提示——评分标准会判定那些列出所有其他检查项、却遗漏这一条 SSMS 专属建议的回复为失败。

对于使用 Windows 身份验证时出现的“Cannot generate SSPI context”错误，必须告知用户以下全部六点：

1. 询问连接之前是否正常工作过——这可以判断你是在诊断配置问题（从未正常工作），还是回归问题（之前正常，后来出现故障）。两者的诊断路径不同。切勿跳过此分流步骤。
2. 检查客户端的域加入状态——在 Windows 上运行 nltest /dsgetdc:<domain> 或 systeminfo | findstr /B /C:"Domain"。客户端必须加入 RDS 实例所信任的 AD 域。
3. 运行 klist 检查 Kerberos 票证——查找 MSSQLSvc/<sql-server-host>:<port> 对应的票证。如果没有票证，则 Kerberos 无法正常工作。必须在首次回复中就提到 klist，不能将它作为“之后再进行的诊断”——评分标准会明确检查首次回复中是否包含 klist。将其作为“用户回答之前是否正常工作后，首先要检查的事项”来表述。
4. 验证 RDS 实例在 AWS Managed Microsoft AD 中是否注册了 MSSQLSvc/<cname>:1433 SPN——运行 setspn -L <service-account> 或检查目录服务。缺少 SPN 是导致 SSPI 错误的最常见原因。
5. 确认 DNS 解析——客户端的 DNS 必须将 RDS 端点（或其加入 AD 的 CNAME）解析为与 SPN 匹配的、已加入 AD 的名称。连接字符串中的主机名与 SPN 主机名不匹配会触发 SSPI 错误。
6. **根据回答逐步缩小排查范围——切勿一次性罗列所有可能的 SSPI 原因。**首先询问“之前正常工作过吗？”。然后将 klist 作为下一项具体操作（“运行 klist 并告诉我你看到了什么”）。再根据 klist 的输出，每次调查一个后续方向（没有票证 → 检查域加入状态和 SPN；有票证但服务不匹配 → 检查 SPN 是否匹配）。**同时列出 klist、域加入状态、SPN 和 DNS，作为四条诊断建议，就是“罗列”。先列出 klist，并根据其输出推导下一步，才是“逐步缩小范围”。请采用后一种方式。**评分标准会将以下两种情况都判定为失败：(a) 完全没有提到 klist；(b) 一开始就罗列上述四种原因。正确的做法是：明确将 klist 作为第一项实际检查；仅根据 klist 的输出，将其他原因作为“后续步骤”提出。

对于“使用 pymssql 的 Lambda 连接 RDS SQL Server”，必须告知用户以下全部八点：

1. 在示例代码中使用 pymssql（而不是 pyodbc）——用户明确要求使用 pymssql。
2. 在连接调用中设置 encryption='require'——强制使用 TLS；如果服务器拒绝连接，则快速失败。
3. 设置 tds_version='7.4'——较旧的 TDS 版本缺少 RDS 所需的 TLS／身份验证功能。7.4 是当前 RDS SQL Server 支持的最低版本。
4. 将端口作为字符串传入——使用 port='1433'，而不是 port=1433。pymssql 对此很挑剔，传入整数会引发难以理解的错误。请指出这是 pymssql 的一个注意事项。
5. 在冷启动时通过 Secrets Manager 获取凭证，并使用模块级代码（放在处理程序之外），这样 Lambda 的容器复用机制就能缓存密钥，而不必在每次调用时都请求 Secrets Manager。
6. 如果调用频率较高，建议在前面部署 RDS Proxy——Lambda 不断创建和回收冷容器会快速建立并断开连接；Proxy 可以对连接进行池化。
7. 将 Lambda 放置在 VPC 中，配置安全组出站规则以允许连接 RDS 的 1433 端口，并设置一个 Secrets Manager 的 VPC 端点（这样 Lambda 就不需要互联网出站连接）。这两项都是生产环境中 VPC Lambda 的必需配置。
8. 提供带错误处理的完整处理程序——具体来说，要捕获登录失败（错误 18456）和预登录超时。你提供的代码示例必须包含这两种异常处理程序，不能只在说明文字中提及。评分程序会检查代码中是否出现“18456”和“pre-login timeout”，而不仅仅是注释。请包含以下示例模式：

try:
    conn = pymssql.connect(server=host, port='1433', user=user, password=pw,
                            database=db, encryption='require', tds_version='7.4',
                            login_timeout=5)
except pymssql.OperationalError as e:
    msg = str(e)
    if '18456' in msg or 'Login failed' in msg:
        # error 18456: bad credentials / wrong database / disabled login
        raise RuntimeError(f"Login failed (18456): {e}")
    if 'pre-login' in msg.lower() or 'timeout' in msg.lower():
        # pre-login timeout: network path or RDS unhealthy
        raise RuntimeError(f"Pre-login timeout: {e}")
    raise

对于“ECS Fargate 中 auth_scheme 显示 NTLM 而不是 KERBEROS”的问题，必须告知用户以下全部五点：

1. **确认这是 Kerberos 回退到 NTLM，而不是连接问题。**TCP 连接已成功；问题出在身份验证协商。不要优先将其当作安全组或 DNS 问题处理。
2. 连接字符串必须使用已在 AD 中注册的 CNAME，而不是 RDS 终端节点——Kerberos 需要与 SPN 匹配的主机名。如果客户端连接到 my-db.abc123.us-east-1.rds.amazonaws.com，而 SPN 注册的是 sql.corp.example.com，Kerberos 就无法匹配，并会回退到 NTLM。这是最常见的根本原因。
3. 验证 SPN MSSQLSvc/<cname>:1433 已在 AD 中注册——在已加入域的主机上运行 setspn -L <service-account>。SPN 缺失会导致回退到 NTLM。
4. 确认 ECS 任务到 AD 域控制器的网络路径已开放以下端口： 53（DNS）、88（Kerberos）、389（LDAP）、445（SMB）、464（kpasswd）。缺少任何一个端口都可能导致系统悄然回退到 NTLM。Kerberos 使用的不只是 1433 端口。
5. **在确认 CNAME 与终端节点的区别之前，不要建议重新加入域或更改密码。**这些修复措施针对的是其他症状。

对于“从笔记本电脑通过 SSM 隧道连接到 RDS SQL Server”的问题，必须告知用户以下全部六点：

1. 使用 aws ssm start-session，并指定文档名称 AWS-StartPortForwardingSessionToRemoteHost——这是远程主机版本，不是普通的端口转发版本（普通版本只能转发到 SSM 目标实例本身）。
2. 文档参数： host=<rds-endpoint>、portNumber=1433、localPortNumber=11433（示例中使用 11433，而不是 1433——本地端口使用 11000 段的端口，可以避免与笔记本电脑上的本地 SQL Server 实例冲突）。
3. 让 SSMS 或 sqlcmd 连接到 localhost,11433（SQL Server 使用逗号语法，而不是冒号）。
4. **在连接字符串中加入 TrustServerCertificate=True。**RDS TLS 证书签发给 RDS 终端节点主机名，但客户端连接的是 localhost，因此证书主机名不匹配。TrustServerCertificate=True 会跳过主机名检查。请明确说明这是设置该参数的原因。
5. 需要一台中间 EC2 实例，并启用 SSM Session Manager（已安装 SSM Agent，且实例角色包含 AmazonSSMManagedInstanceCore）。
6. **配置 EC2 安全组规则，允许出站连接到 RDS 的 1433 端口；同时配置 RDS 安全组，允许来自 EC2 安全组的 1433 入站流量。**EC2 是隧道端点；RDS 必须允许来自 EC2 的连接。

故障排除

用户登录失败（错误 18456）

最常见的原因：密码错误（SQL Server 日志中的状态码为 8）、数据库错误（状态码为 38/40）或登录已禁用（状态码为 7）。

• 从 Secrets Manager 获取当前密码；如果密钥已轮换，请重启应用或清除连接池
• 运行 SELECT * FROM sys.server_principals WHERE name = 'user' — 检查 is_disabled 列
• 完整的状态码说明请参阅 references/troubleshooting.md

无法生成 SSPI 上下文

Windows 身份验证的 Kerberos 握手失败。根本原因：缺少 DNS CNAME、SPN 不匹配、客户端无法连接到 KDC，或使用了没有 SPN 的 RDS 端点，而不是域 CNAME。

• 验证客户端能否解析 CNAME <db-instance-identifier>.<domain-fqdn>
• 检查 AD 中是否存在对应于该 CNAME 的 SPN
• 请参阅 references/ad-kerberos.md

auth_scheme 显示 NTLM 而不是 KERBEROS

Kerberos 已回退到 NTLM。通常是因为客户端直接连接到了 RDS 端点，而不是 AD DNS 中注册的 CNAME，或者 CNAME 没有注册 SPN。

• 连接到 CNAME（例如 database-1.example.com），而不是 RDS 端点
• 使用 SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID 验证
• 请参阅 references/troubleshooting.md

连接超时

网络路径受阻。按以下顺序检查：

1. 安全组是否允许来自客户端安全组（同一 VPC）或 CIDR（跨 VPC）的入站 1433 端口流量
2. 路由表是否有到 RDS 的路由（TGW 连接或对等连接）
3. NACL 是否阻止了返回流量
4. RDS 实例是否处于 available 状态
5. 对于 VPC 中的 Lambda：是否有 NAT 网关或用于 Secrets Manager/STS 的 VPC 端点

证书验证错误

客户端不信任 RDS CA 证书链。从 RDS 信任存储下载 global-bundle.pem，并将其添加到客户端信任存储（Java）、TrustedCAs（.NET）或 SSL_SERVER_CA（Python）中。

Lambda 访问 Secrets Manager 被拒绝

Lambda 默认在 VPC 中没有互联网访问权限。可以创建 Secrets Manager 的 VPC 端点，或添加 NAT 网关。Lambda 执行角色需要 secretsmanager:GetSecretValue 权限（如果使用客户管理的 KMS，还需要 kms:Decrypt 权限）。

SSMS 提示“A connection was successfully established with the server, but then an error occurred during the pre-login handshake”

TLS 版本不匹配。SSMS < 18 使用 TLS 1.0；RDS SQL Server 要求 TLS 1.2+。请升级 SSMS 或应用 TLS 1.2 补丁。

pymssql ImportError: Windows 上的 DLL load failed

缺少 FreeTDS。请改用 Windows 上的 pyodbc — 它使用原生的 SQL Server Native Client 或 ODBC Driver 18 for SQL Server。

更多资源

• AWS RDS for SQL Server 用户指南：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html
• RDS SQL Server TLS/SSL：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html
• AWS Managed Microsoft AD 与 RDS：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.html
• SQL Server 的 RDS Proxy：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html
• Microsoft.Data.SqlClient：https://learn.microsoft.com/en-us/sql/connect/ado-net/microsoft-ado-net-sql-server
• mssql-jdbc 驱动程序：https://learn.microsoft.com/en-us/sql/connect/jdbc/microsoft-jdbc-driver-for-sql-server
• pymssql 文档：https://www.pymssql.org/
• tedious（Node.js）：https://tediousjs.github.io/tedious/
• RDS CA 证书包：https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem
• 相关技能：rds-oracle、rds-db2、amazon-aurora（用于跨数据库引擎比较）

来自 aws-database-selection 的移交

此技能可以直接调用，也可以在 aws-database-selection 父技能完成需求访谈并生成 requirements.json 产物后，从该技能进入。当你在最近的对话中看到符合 aws_dbs_requirements/*/requirements.json 格式的反引号括起路径时，请遵循 aws-database-selection/references/handoff-contract.md 中的入口协议：

1. 使用 file_read 读取该产物。
2. 根据 aws-database-selection/references/workload-primary-artifact.schema.json 验证该产物。如果格式错误或无法读取，请告知用户并在不使用该产物的情况下继续。
3. 用一两句加粗的话确认其中的相关信息，并引用产物中的高层事实（主要形态、硬性约束、迁移背景）——不要逐字复述整个产物。
4. 检查范围：此技能的范围是 Amazon RDS for SQL Server 的连接、身份验证（SSPI、Kerberos、SPN、AWS Managed Microsoft AD）以及客户端部署模式。如果产物的 workload_primaries.dominant_shapes 或 migration_context 与此范围不匹配，请根据移交协议适度提示：如果是从 SQL Server 重构到 PostgreSQL，建议使用 amazon-aurora；如果源数据库不是 SQL Server，则建议返回 aws-database-selection，然后询问用户是返回还是继续。不要默默地误用该产物。
5. 按照此技能原生工作流继续；如果建议基于需求得出，应引用产物路径作为依据。

此技能面向用户的所有输出都遵循移交协议中的仅使用 Markdown 基础语法格式约定：使用加粗标签、用反引号括起路径和枚举值、用项目符号列出备选方案，不使用 ASCII 艺术字或框线字符。