friol Asked: 2009-05-14 10:29:05 +0800 CST2009-05-14 10:29:05 +0800 CST 2009-05-14 10:29:05 +0800 CST 非系统管理员访问生产系统 772 您对非系统管理员访问生产或实时系统有何看法? 您认为应该为这种访问提供名义用户名吗? 您认为应该允许访问日志文件或数据库吗? security user-management 7 个回答 Voted K. Brian Kelley 2009-05-14T10:33:11+08:002009-05-14T10:33:11+08:00 应用最小特权原则。如果他们需要访问权限来完成工作,您可以授予他们访问权限。但是您只提供他们需要的访问权限。如果他们不需要访问权限来完成这项工作,你就不要给他们。 这不仅可以保护个人(不能被指责越界),而且可以保护组织,以防用户的帐户被盗用。 至于为什么不应该给予他们这样的访问权限...... 一个关于失误和腐败的悲伤故事(从今天开始) WerkkreW 2009-05-14T10:36:34+08:002009-05-14T10:36:34+08:00 我同意上述观点,但我想补充一点,共享用户帐户根本不是一个好主意。您无法在日志中追踪谁做了什么,也无法控制谁与谁共享了哪些密码。 配置一个具有特定访问控制的组,并为每个需要访问系统的非管理员提供他们自己的帐户,只有他们完成工作所需的访问权限。 DCNYAM 2009-05-14T11:29:35+08:002009-05-14T11:29:35+08:00 从 DBA 的角度来看,用户对生产系统的访问应该受到严格限制,这包括开发人员。用户应该只能看到他们需要的数据,理想情况下这将通过视图提供,而不是直接访问表。 同样,开发人员应该能够查看生产中的数据,但不能更改任何表。任何更改都应首先在测试(或开发)中完成,然后由 DBA 编写脚本并在生产环境中运行。 Tim Howland 2009-05-14T13:02:41+08:002009-05-14T13:02:41+08:00 启发式非常简单: 如果系统搞砸了,他们会被解雇吗? 你? 如果答案是“否”和“是”,大多数组织都是这样,那么答案就很清楚了。 skamradt 2009-05-14T14:34:02+08:002009-05-14T14:34:02+08:00 对于开发,如果可能的话,为他们提供实时系统的副本,并提供一种将数据库更改随意推送回开发副本的方法。您会发现,您的许多开发人员在访问“真实”数据时会更有效率,并且知道他们无法访问实时系统,您会感到安全。 我也相信没有真正的理由在交易之外存储某些敏感数据。例如,信用卡交易...抓取数据并将其发送到商户处理系统...但不要将其保存在数据库中,而只需存储卡的最后 4 位数字和商户的交易 ID系统。这样,当发现漏洞并生成修复程序时(我知道,这种情况永远不会发生),您可以确信没有人可以从您的数据库中窃取任何这些数据。 quux 2009-06-25T02:17:14+08:002009-06-25T02:17:14+08:00 我完全同意 H. Brian Kelley 以Principle of Least Privilege为特色的回答。 但我想提一下,它与我自己的家常便饭责任共担原则密切相关。也就是说,任何有能力管理服务器的人也应该将他们的电话号码添加到服务器的待命列表中。所以现在这个非系统管理员也可以知道凌晨 2 点“东西坏了”电话的乐趣。 根据生产服务器的重要性,是的,我认为非系统管理员应该必须使用第二个特权帐户来访问系统 - 就像我一样(例如,我使用一个帐户来处理我的日常电子邮件和普通用户活动;另一个用于我的系统管理员活动)。用户现在必须明确更改为更高的 priv 级别,这将有助于防止失误。 是的,在某些情况下应该允许日志(仅查看)访问。显然,当那个人需要看到输出以更好地完成他/她的工作时,您希望倾向于提供访问权限。如果日志包含真正敏感的信息,例如客户个人或财务数据,请重新考虑这一点。 每当您授予特权访问权限时,您可能会考虑对特权访问的安全方面进行某种程度的正式/非正式培训。 jtimberman 2010-08-28T11:51:36+08:002010-08-28T11:51:36+08:00 是的。完全 root 访问权限(通过 sudo ALL 授予)。他们也将被添加到待命轮换中。 许多公司都有一名系统管理员 24/7 全天候待命,即使是针对应用程序问题也是如此。有些公司很幸运,有两个。期望一个人完成所有日常操作工作并在夜间所有时间响应系统警报是完全不合理的。 但是,许多公司都有相当数量的开发人员负责系统上运行的应用程序代码。他们中的许多人甚至可能有运营经验。 不,他们不应该对邮件系统负责,除非它直接与他们工作的应用程序相关联。但是应该有一个清晰的运行手册来快速推理,以便他们可以为系统管理员收集信息,或者如果足够简单,甚至可以自行解决。 每个人的工作是使业务成为可能。
应用最小特权原则。如果他们需要访问权限来完成工作,您可以授予他们访问权限。但是您只提供他们需要的访问权限。如果他们不需要访问权限来完成这项工作,你就不要给他们。
这不仅可以保护个人(不能被指责越界),而且可以保护组织,以防用户的帐户被盗用。
至于为什么不应该给予他们这样的访问权限......
一个关于失误和腐败的悲伤故事(从今天开始)
我同意上述观点,但我想补充一点,共享用户帐户根本不是一个好主意。您无法在日志中追踪谁做了什么,也无法控制谁与谁共享了哪些密码。
配置一个具有特定访问控制的组,并为每个需要访问系统的非管理员提供他们自己的帐户,只有他们完成工作所需的访问权限。
从 DBA 的角度来看,用户对生产系统的访问应该受到严格限制,这包括开发人员。用户应该只能看到他们需要的数据,理想情况下这将通过视图提供,而不是直接访问表。
同样,开发人员应该能够查看生产中的数据,但不能更改任何表。任何更改都应首先在测试(或开发)中完成,然后由 DBA 编写脚本并在生产环境中运行。
启发式非常简单:
如果系统搞砸了,他们会被解雇吗?
你?
如果答案是“否”和“是”,大多数组织都是这样,那么答案就很清楚了。
对于开发,如果可能的话,为他们提供实时系统的副本,并提供一种将数据库更改随意推送回开发副本的方法。您会发现,您的许多开发人员在访问“真实”数据时会更有效率,并且知道他们无法访问实时系统,您会感到安全。
我也相信没有真正的理由在交易之外存储某些敏感数据。例如,信用卡交易...抓取数据并将其发送到商户处理系统...但不要将其保存在数据库中,而只需存储卡的最后 4 位数字和商户的交易 ID系统。这样,当发现漏洞并生成修复程序时(我知道,这种情况永远不会发生),您可以确信没有人可以从您的数据库中窃取任何这些数据。
我完全同意 H. Brian Kelley 以Principle of Least Privilege为特色的回答。
但我想提一下,它与我自己的家常便饭责任共担原则密切相关。也就是说,任何有能力管理服务器的人也应该将他们的电话号码添加到服务器的待命列表中。所以现在这个非系统管理员也可以知道凌晨 2 点“东西坏了”电话的乐趣。
根据生产服务器的重要性,是的,我认为非系统管理员应该必须使用第二个特权帐户来访问系统 - 就像我一样(例如,我使用一个帐户来处理我的日常电子邮件和普通用户活动;另一个用于我的系统管理员活动)。用户现在必须明确更改为更高的 priv 级别,这将有助于防止失误。
是的,在某些情况下应该允许日志(仅查看)访问。显然,当那个人需要看到输出以更好地完成他/她的工作时,您希望倾向于提供访问权限。如果日志包含真正敏感的信息,例如客户个人或财务数据,请重新考虑这一点。
每当您授予特权访问权限时,您可能会考虑对特权访问的安全方面进行某种程度的正式/非正式培训。
是的。完全 root 访问权限(通过 sudo ALL 授予)。他们也将被添加到待命轮换中。
许多公司都有一名系统管理员 24/7 全天候待命,即使是针对应用程序问题也是如此。有些公司很幸运,有两个。期望一个人完成所有日常操作工作并在夜间所有时间响应系统警报是完全不合理的。
但是,许多公司都有相当数量的开发人员负责系统上运行的应用程序代码。他们中的许多人甚至可能有运营经验。
不,他们不应该对邮件系统负责,除非它直接与他们工作的应用程序相关联。但是应该有一个清晰的运行手册来快速推理,以便他们可以为系统管理员收集信息,或者如果足够简单,甚至可以自行解决。
每个人的工作是使业务成为可能。