将 sysadmin 角色授予需要执行特定任务的服务帐户是否危险?

将 sysadmin 角色授予需要执行特定任务的服务帐户是否危险?

我正在尝试设置 Amazon DMS,以便将数据从我们的生产 SQL Server 实例(当前在专用 EC2 实例中运行)复制到 Redshift 中,以用于数据仓库目的。DMS 文档明确指出那:

AWS DMS 用户账户必须具有系统管理员您正在连接到的 Microsoft SQL Server 数据库上的固定服务器角色。

不支持 Windows 身份验证。

这让我们的 DBA 很担心。他们担心创建一个具有系统管理员权限的帐户(实际上是 SQL 或 AD),然后将该访问权限授予第三方服务。虽然我理解这种担忧,但我倾向于信任亚马逊,创建服务帐户,然后继续我的日子。

他们建议设置一个作业,在夜间同步之前授予帐户必要的 sysAdmin 角色,然后在作业完成后恢复权限。我觉得这没有必要,而且如果我们转向连续复制

所以我的问题是:创建这样的账户有多危险(假设遵循其他最佳实践,即:安全加密的密码、通过 IP 地址限制访问等)?是否有充分的理由不继续推进,或者这只是做生意的成本?

答案1

是否有充分的理由不继续前进,或者这只是经营的成本?

我完全理解 DBA 的犹豫,而且提供 SA 并不是一个好的做法。如果服务器受到任何行业法规(如 PCI/SOX)的约束,使用 SA 登录需要受到监控并且有正当理由,那么这种情况会变得尤其糟糕。

但是,这是业务需求,而且您已经在使用 AWS,这使得这种担忧变得毫无意义。我肯定会要求 Amazon 提供权限列表,而不仅仅是 SA,但我也会(同时)继续测试,不让它成为阻碍。

创建这样的帐户有多危险(假设遵循其他最佳实践,即:安全加密的密码、通过 IP 地址限制访问等)?

给出 SA 应该不是一件小事,因为任何有权访问它的人都可以做任何他们想做的事情而不会留下任何痕迹。假设这个服务器不能直接从互联网访问,并且登录受到 IP 限制等,这将最好地限制表面区域。之后就取决于信任亚马逊了,但你似乎没有理由这样做不是相信他们。

总的来说,我会要求提供所需最低权限的列表,但会继续使用该服务并根据需要设置帐户。就我个人而言,我会对该登录进行额外的审核,并在我的测试环境中密切关注它,以了解它“真正”做了什么……但如果你想使用该服务,这是必需的——与该服务所有者做生意的代价。

相关内容