行业新闻与博客
您需要了解的 14 个 SSH 密钥管理最佳实践
您管理和保护安全 Shell 密钥生命周期的良好程度在一定程度上决定了网络和其他 IT 环境的安全性。以下是一些 SSH 密钥管理最佳实践,可帮助您入门
SSH 密钥管理是身份和访问管理(IAM)经常被忽略的元素。在 Hashed Out,我们通常专注于基于公钥基础结构(PKI)的身份验证和数字身份形式,因为这是我们的专长和专业领域。但是,我们必须承认,几乎所有公司都以某种能力使用的安全外壳(SSH)偶尔也需要在覆盖范围方面有所帮助。
这就是为什么我们决定解决一篇针对您企业最重要的 SSH 密钥管理最佳实践的文章的原因。但是,您现在需要实施的 14 个最重要的 SSH 密钥管理最佳实践是什么,它们如何使您的组织受益?
让我们将其散列出来。
什么是 SSH 密钥管理?SSH 密钥在身份和访问管理中的作用
在我们开始定义 SSH 密钥管理之前,首先让我们快速重新说明什么是安全外壳,什么是 SSH 密钥以及组织如何使用它们进行用户友好的身份验证和增强的数据安全性。
什么是 SSH 及其作用?
SSH代表安全外壳,是一种加密网络协议,允许通过开放通道在两个设备之间进行安全身份验证和数据通信。SSH 对于网络和常规系统管理(例如,管理防火墙,网络,服务器等)至关重要。作为真正内置在 Unix 和 Linux 服务器中的东西,它是一个客户端-服务器模型系统,旨在通过不安全的连接来保护用户和关键系统之间的远程访问。
简而言之,SSH 是 IT 管理员用来登录服务器和其他 Linux 机器以远程管理它们的numero uno系统。它的工作方式是当授权用户登录到安全外壳环境进行身份验证时,他们的设备可以访问您的安全 IT 环境中的一个或多个设备或资源。因此,很容易看出 SSH 身份验证在组织的身份和访问管理过程中如何发挥关键作用。
使用 SSH 以管理员根访问权限登录时,您可以完全控制计算机。SSH 访问充当进入王国的钥匙,使您可以控制所有命令和文件。因此,您可以想象,通过适当的 SSH 密钥管理保护这种特权访问对组织的安全至关重要。(走到这里说 SSH 安全性对您很重要,因为您仍然在这里并且已经读了很远,至少……)
SSH 身份验证(以及在其中插入 SSH 密钥的位置)
SSH 身份验证可以通过几种不同的方式进行。但是,我们今天要重点关注的两种是基于密码和 SSH 密钥的身份验证方法。正如您可能从本文标题中可以猜到的那样,我们的主要重点将专门集中在 SSH 密钥管理最佳实践上。
- 当用户手动输入其登录凭据以访问安全资源时,就会发生基于密码的 SSH 身份验证。例如,当您的一位同事在登录字段中输入其各自的用户名和密码以访问 Amazon Web Service 的 Elastic Computing Cloud(AWS EC2)中的文件时。
- 基于 SSH 密钥的身份验证允许用户使用加密密钥对自动进行身份验证。这些密钥对由私钥和公钥组成,用于对用户(其设备)和主机进行身份验证。基本上,您使用具有私钥的本地计算机对 AWS 进行一次身份验证。之后,两个设备之间的所有 SSH 交互都将依赖密钥对进行身份验证。
简而言之,SSH 密钥是计算机身份和身份验证的另一种形式。它们使您组织的经授权的,经过身份验证的用户可以访问关键系统来执行其工作。但是,与我们用于 X.509 数字证书的传统 PKI 密钥不同,SSH 密钥没有由证书颁发机构(例如,证书颁发机构或 CA)(例如 DigiCert 或 Sectigo)签名的公共密钥。(在 SSL 中,您是通过 CSR 流程自行生成 SSL 密钥的,而公共密钥是 CA 作为证书的一部分进行签名的。)即使 SSH 身份验证涉及的过程类似于 SSL / TLS 握手,其身份验证也是如此过程并不那么复杂。
以下是 SSH 身份验证工作原理的快速概述(概述):
但是,在比较基于密码和基于密钥的 SSH 身份验证方法时,哪个选项更好或更安全?EdgeScan 的《 2021年漏洞统计报告》显示,到 2020年,组织暴露的最大增长中有一些与不安全的 SSH 凭据的使用有关。
“远程桌面(RDP)和安全 Shell(SSH)的暴露增加了大约 40%,这可能是由于 covid-19 导致远程工作增加的缘故。RDP(和类似服务)是针对弱用户凭据的暴力攻击或凭据填充攻击的简便且常用途径。”
EdgeScan 的报告显示,在“远程系统登录和管理”方面,SSH 在其一百万个面向公共端点的公开服务的示例中,代表了 3.8%(38,000)。
如果得到妥善管理,SSH 密钥将提供一种比仅使用传统登录凭据更安全的身份验证方法。为什么?因为密钥可以抵抗暴力攻击。但是,这些密钥的安全性和有效性取决于您的组织对它们进行跟踪的程度。这是遵循 SSH 密钥管理最佳做法的地方。
SSH 密钥管理-这是您控制通往王国的密钥的方式
SSH 密钥管理是策略,流程和工具的组合,使您能够保护和管理这些数字密钥对。安全的外壳密钥使用户可以向您的网络,服务器或其他系统进行身份验证,并安全地共享文件,而无需持续使用用户名和密码登录。
有效的 SSH 密钥管理的一些好处包括:
- 始终具有对访问密钥的完全可见性(这有助于您确保每个密钥都免受盗窃)。
- 知道您不是意外地在系统和用户之间重用了密钥(是的,这可能发生)。
- 如果丢失访问密钥(发生事故),请确保您不会被锁定在服务器或系统之外。
- 能够立即更改或撤消员工的访问权限(例如,当某人离开公司时)。
- 如果密钥被泄露,则能够更改或撤消访问权限(在这种情况下,您必须迅速采取行动)。
就像 PKI 密钥管理一样,成功的 SSH 密钥管理围绕着如何保护和跟踪组织的公钥和私钥进行。这意味着要使用有效的方法来生成,存储,旋转,吊销和使用它们,以使其不受网络犯罪分子和其他未授权用户的控制。这需要确保在所有 IT 环境中正确配置,终止和监视 SSH 密钥的过程。
考虑到没有适当的访问管理和批准流程,用户可以简单地向自己发布对您最关键的系统的访问特权访问,因此这可能很棘手。这就是为什么必须要有一个强大的 SSH 密钥管理程序的原因。这也是为什么 SSH 密钥管理应成为访问和 IT 风险管理以及补救流程,策略和策略的一部分。
SSH 密钥管理不善使您容易受到攻击并且不符合行业法规
您现在应该了解,对 SSH 密钥的管理不当会使您的组织面临凭证泄露,数据盗窃和数据泄露的风险,但是您是否知道这还会使您不遵守某些行业法规?许多著名的法规(HIPAA,GDPR,PCI DSS)都需要数据安全和隐私保护。其中一些要求与管理对数据的访问有关,这意味着或指定使用诸如 SSH 密钥之类的加密密钥。
《健康保险可移植性和责任法案》(HIPAA)
HIPAA 的《安全规则》要求受保护的组织实施基于角色的访问措施,以在使用,运输和休息时保护受保护的电子健康信息(ePHI)数据。这是 SSH 密钥管理所起作用的。
支付卡行业数据安全标准(PCI DSS)
PCI DSS 要求 4 规定,所涵盖的组织必须使用加密的传输来通过开放网络传输持卡人数据。这就要求使用加密过程和组件,例如公共-私人密钥对。
PCI DSS 测试程序 2.3 要求对所有非控制台管理访问使用“强密码”。根据 2.3c 中指定的 PCI DSS 指南:“被认为是'强密码学',应采用适用于所使用技术类型的,具有适当密钥强度和密钥管理的行业认可协议 [。]”
通用数据保护条例(GDPR)
欧盟的 GDPR 要求对涵盖的个人数据进行安全处理。GDPR 第 32 条规定了“适当的技术和组织措施”的使用,其中包括数据加密和对该数据的安全访问。(这包括使用公共密钥加密方法来保护访问。)
不用说,如果坏人设法利用员工的 SSH 密钥,则可能导致许多可怕且代价高昂的后果。这就是为什么无论大小如何,SSH 密钥管理都应成为每个企业的优先事项。
现在需要实施的 14 个 SSH 密钥管理最佳实践
从研究的 Acunetix 的 2020年Web 应用程序漏洞的报告显示,5000 个扫描目标的 15.5%,他们分析了 SSH 相关的漏洞。其中很大一部分是由于 SSH 密钥管理不当。这是因为 SSH 密钥的安全性仅与您实施的 SSH 密钥管理和审核实践一样好。
有效地管理您的 SSH 密钥需要了解以下内容:
- 您的 IT 环境中存在的 SSH 密钥的确切数量,
- 何时以及如何使用每个密钥以及它可以访问的系统,
- 每个钥匙的寿命以及何时需要更换它,以及
- 如何安全地生成,存储,吊销和删除网络和整个 IT 环境中的密钥。
美国国家科学技术研究院(NIST)在其机构间报告 7966(NISTIR 7966)中提供了有关 SSH 访问管理的深入指导。它们涵盖了许多漏洞,包括:
- SSH 实施问题,
- 访问控制配置问题,
- 意外的 SSH 密钥使用情况,以及
- 未知或未经审核的活动密钥(以及与之相关的风险)。
但是,这里有很多内容要讲,坦率地说,我们不认为您现在就来了解所有这些内容。这就是为什么我们在本文中将采用更多高级方法来进行 SSH 密钥管理。
因此,不用费吹灰之力,让我们分解一下您现在可以使用的 14 种 SSH 密钥管理最佳实践,以保护和管理对组织的 IT 环境和数据的访问。这些最佳实践将分为四个总体类别,这将有助于使事情变得容易理解。
使用可提高网络和 IT 环境中 SSH 密钥可见性的工具
SSH 密钥可见性是我们要提到的第一个最佳实践,因为如果您不知道组织的 SSH 密钥存在,就无法保护或保护它们。这就像负责美国特勤局,必须保护总统而又不事先知道他们要去哪里以及与谁会面。
同样,有效的关键治理要求您清楚了解网络和 IT 环境中发生的情况。其中的一部分需要维护所有 SSH 密钥的最新(理想情况下是集中式)清单,以及如何在服务器,主机和其他 IT 基础结构中使用它们。这将帮助您确定:
- 重复的 SSH 密钥或访问权限,
- 识别仍然有效的“孤立”或“恶意” SSH 密钥,以及
- 谁在使用什么键来访问哪个系统。
如果您不知道哪些系统或用户使用了哪些键,那么您将无所适从。这是因为黑客和其他网络犯罪分子等坏人可能会先弄清楚哪些密钥可以访问特定系统,然后再利用它们。
因此,您如何确定所有这些不同的密钥对组件都位于何处以及它们可以访问什么?
1.使用 SSH 密钥管理器发现 SSH 密钥并启用自动化
使用可靠的 SSH 密钥管理工具是在组织内管理密钥管理生命周期的简便方法。SSH 密钥管理器可帮助您发现 IT 基础结构中任何密钥存在的地方以及它们控制或访问的内容。这可以帮助您确定潜在的漏洞,恶意分子可以通过暂时被遗忘的,孤立的或恶意的 SSH 密钥来利用这些漏洞。
在其电子书“取回 SSH 密钥控制权的 6 个步骤”中,Keyfactor 将孤立密钥描述为授权的公共密钥,而其私有密钥的位置未知。忘记的密钥是管理员为特定任务创建的临时使用密钥,但以后忘记删除。顾名思义,流氓密钥是未经授权的工具,可以带外创建。
SSH 密钥管理工具允许您手动管理密钥,同时还可以使许多这些功能自动化。它们还可以帮助您避免或减轻密钥散布问题,这对于必须在其环境中管理数千甚至数百万 SSH 密钥(对于财富 500 强公司而言)的大型组织和公司特别有用。
但是,需要注意的是,并非所有的密钥管理平台都支持 SSH 密钥。允许您保护和管理 SSH 密钥管理平台的一些示例如下:
- AppViewX,
- Keyfactor 的 SSH 密钥管理器,
- ManageEngine 的 Key Manager Plus,以及
- Venafi 的 SSH Protect。
使用安全方法存储,备份和允许对密钥的授权访问
正如我之前提到的,SSH 密钥是由私钥和公钥组成的密钥对。私钥是您存储在用户设备上的人,它将使用该密钥进行访问。例如,他们的办公室笔记本电脑或智能手机。另一方面,公用密钥是您需要存储在用户将连接到的计算机(例如服务器)上的密钥。这可能是您的网络,服务器或各种其他系统。
每个 SSH 私钥都应使用独特且难以猜测的密码来保护。这会增加另一层抵御暴力攻击和工具的安全性。这样,即使一个坏人设法访问了您的私钥,他们也无法做任何事情,因为他们无法猜出密码。每次更换此密钥时,还应使用一个新的强密码短语。
私钥也应保留在生成它的设备上。唯一的例外是,如果您决定将其存储在安全密钥库或硬件安全模块(HSM)中。只是一定要永远,永远分享在网络上的 SSH 私钥!
有效的 SSH 密钥管理要求安全备份和存储这些密钥。这部分意味着要知道如何以及在何处保存密钥,以免密钥被泄漏或以其他方式被破坏。例如,您永远不希望将 SSH 密钥信息存储在要共享的任何代码文件夹中,因为它们最终可能会泄漏。
2.使用密钥库和物理 SSH 密钥存储
一种选择是使用受信任的信誉良好的密钥保险库(例如 Azure Key Vault 或 AWS Key Management Service)。这是一个安全,集中的位置,您可以在其中安全地存储多种类型的加密元素(证书,PKI 密钥,SSH 密钥和其他机密),以便授权的 Web 应用程序和实体仍然可以根据需要对其进行访问。
安全密钥存储的另一种选择是将 SSH 密钥存储在物理安全的脱机环境中。这应该意味着将用于保存钥匙和钥匙的安全设备存储在只能选择授权人员访问的安全区域中。
3.实施密钥托管以允许仅授权实体访问 SSH 密钥
确保私钥在仍可访问的同时保持安全的一种好方法是使用称为密钥托管的过程。这基本上意味着使用受信任的第三方或工具来保留 SSH 私钥的副本。使用密钥托管的优势在于,如果原始密钥发生意外情况,它可以用作备份。
使用密钥托管的一个示例是,当 IT 管理员使用第三方工具存储密钥时,需要它们的授权实体可以访问它们。要进行设置,他们必须确定在何处以及如何保存密钥以及谁可以访问该密钥。系统中可能已经存在一些重要的托管功能(例如,它可能是 Active Directory 的一部分)。
在某些方面,密钥托管的概念类似于抵押公司为您管理托管帐户的方式。他们每个月都会向您收取一定金额的款项,并将其一部分存储在托管帐户中。然后,该帐户就是他们每年到期时用来支付您的年度财产税和房主保险的帐户。
实施并遵循有效的访问管理最佳实践
有效的用户访问管理也是 SSH 密钥管理的最佳做法也就不足为奇了。毕竟,SSH 密钥只是可以用来代替用户的传统凭据(用户名和密码)的另一种身份验证方法。因此,这意味着您的 SSH 密钥管理过程和策略应与访问控制保持一致。
正如我们之前提到的,NIST 还提供了有关 SSH 用户访问和密钥管理的指南。这可以在我们之前引用的机构间报告 7966(NIST IR 7966)中找到。它还会影响它们在特殊出版物 800-53(SP 800-53)中处理的控制系列。
4.实施和执行严格的 SSH 密钥管理策略和流程
SSH 密钥管理仅与您已制定并实施的策略一样好。如果您的书面政策从未得到遵循或应用,那么它们根本就一文不值。这些策略应该是支配 SSH 密钥基础结构和流程的骨干,并且还应确保负责这些策略的人员负责。
假设您已经制定了明确列出每个人的职责和角色的策略,并且这些策略是定期执行的。在那种情况下,执行这些功能不太可能被推到优先事项的后面,而被遗忘。
5.创建,管理和记录单个用户帐户(避免创建共享帐户凭据)
虽然创建一些共享帐户可能更容易,但是更有效的凭据管理要求最好为每位员工创建一个单独的帐户。这意味着创建您需要为需要访问特定系统的每个人创建 SSH 密钥对。
此过程的一部分应包括正式的访问批准和随附的文档。这有助于提供有关为什么每个键的访问权限是必需的以及用户访问权限与哪个键相关联的记录。尽管所有这些通常对于 SSH 密钥管理都是有用的,但在终止用户访问时帮助您将鸭子连续排成一列时,它尤其有用。
6.实施飞跃特权政策(POLP)
这里的想法是,只有授权用户才应该具有特权访问权限。为确保这一点,您可以配置个人的 SSH 密钥,使其与限制访问该用户所需内容的帐户相关联。
每当员工在公司内更换工作或完全离开公司时,最好也删除旧的访问权限。这将我们带到下一个话题...
7.删除旧的 SSH 公共密钥(缓解基于密钥的风险)
对于企业而言,孤立的和遗忘的 SSH 密钥是一个大问题。这些未经审计的密钥实际上是被遗忘的活动密钥,这些活动密钥会创建后门,网络罪犯甚至是不满的前雇员都可以利用这些后门。这是一个非常重要的步骤,因为您不希望有有效的 SSH 密钥可以访问您不了解的系统。
每当有人离开您的公司时,您都应该有适当的策略和流程来确定如何终止与该用户相关联的任何帐户的访问。一种这样的访问管理方法是删除与它们关联的所有公共密钥。这将防止其私钥允许访问授权的系统。否则,您将剩下坏人可以尝试利用的密钥。
确保正确配置了所有 SSH 密钥和相关系统
一个硬化的 SSH 安全性的方法之一是确保一切正确配置-你正在打点你的我秒和穿越你牛逼秒。您可以使用各种工具,终端和应用程序(例如 PowerShell 或 MacOS 的终端)来设置 SSH 配置。
以下是一些 SSH 密钥管理项,应仔细检查以确保操作正确:
8.确保所有 SSH 密钥均符合或超过建议的最小密钥大小
SSH 密钥用途广泛,可以在多种大小的选项中生成。但是,NIST IR 7966 规定“用户密钥必须符合组织标准,以确保批准的算法所使用的最小密钥长度。”
这就是为什么当今许多组织选择生成 RSA 2048 SSH 密钥的原因。这里的想法是,这种大小的密钥有助于使分解尝试对于攻击者而言过于不切实际(且成本很高)。因此,要确保组织内的所有 SSH 密钥生成都达到最小值,必须指定最小密钥大小。
您可以通过两种方式生成密钥对。一种方法是通过使用SSH-keygen -t rsa命令直接在服务器本身上生成它,并按照提示进行操作,其中包括为私钥创建密码。我将借用我前同事的一篇文章的屏幕快照,该屏幕快照显示了它的外观:
另一种方法是使用独立软件(例如 PuTTYGen),该软件允许您创建公用专用密钥对。
9.在一段时间后使您的 SSH 密钥无效
SSH 密钥的有趣之处在于,与 PKI 证书不同,SSH 密钥在技术上不会在任何给定期限后“过期”。当然,它们可以被撤销,但是要使它们在不再可用的意义上所谓的“过期”,您必须手动强制服务器拒绝旧密钥或将其直接从 IT 系统中删除。(嗯,也许我应该在这里说“退休”而不是“到期”。)
但是,无论选择哪种选择,为什么都需要使 SSH 密钥无效?您不想无限期地保留 SSH 密钥,因为这样做会带来重大的安全风险。一方面,密钥管理不当会导致活动密钥无法访问关键系统。另一个令人担忧的问题是员工流动率。如果因其密钥仍处于活动状态而离开公司的员工可以访问,那将是一个巨大的(而且完全可以避免的)责任。
10.定期旋转按键
由于 SSH 密钥不会过期,因此通常的做法是定期轮换密钥。尽管您应该有适当的流程来确保删除不活动的密钥,但我们可以确保生活会发生,并且某些事情并不一定总是如期发生。因此,定期的密钥轮换有助于防止坏人利用受损的密钥。
但是,NIST IR 7966 确实指出,按键旋转会负面影响或破坏外部按键。这些密钥既可以来自外部组织,也可以是内部密钥,用于对环境外部的系统进行身份验证和访问。正确的 SSH 密钥轮换意味着:
- 用您生成的新授权密钥替换现有的身份密钥,以及
- 更新所有相应的系统以反映这些关键更改。
但是,您应该如何定期旋转钥匙?嗯,答案取决于你问谁。例如,NIST IR 7966 对此含糊不清,只是说应该“定期”旋转按键来对冲他们的赌注。但在附录 F 中,它们包含指向 2013 NIST 文档草案的链接,该链接指定了以下内容:
“导致中度影响力和高影响力系统的所有信任关系的身份验证凭据必须每 12 个月轮换一次,建议导致低影响度系统的信任关系每 12 个月轮换一次。” 建议在修复过程中旋转所有钥匙,以确保以前泄漏的任何钥匙不再可用。”
另一方面,趋势科技则更为具体。他们说您应该大约每个半月(即每 45 天)轮换 SSH 公钥。
Keyfactor 解决方案工程总监 Toby Gaff 警告说,在没有计划的情况下随机旋转钥匙:
“但这是 SSH 密钥的挑战,其中大多数不用于交互目的。我们可以看到密钥轮换存在两个不同的要求。一个基于应用程序 / 系统密钥,另一个基于交互式 / 用户密钥。我们认为,对于交互式 / 用户密钥(类似于密码),应该更频繁地旋转密钥,但是拥有这样的策略是没有意义的,除非您可以报告或执行它。”
这使我想到了有关更改密钥的下一个观点……
11.对不同的用户,主机和环境使用不同的 SSH 密钥
一个好的经验法则是为不同的用户和环境使用唯一的 SSH 密钥。例如,在生产环境中用于管理员的 SSH 密钥不应与在开发环境中用于帐户的 SSH 密钥相同。这样,如果某人设法在一个环境中为用户泄露 SSH 密钥,则他们将无法转过身来并使用相同的密钥来访问系统中的其他环境。
12.更改默认的 SSH 端口并禁用端口转发
SSH 默认使用 TCP 端口 22,但这并不意味着您会被自动使用。TheSSLstore.com 的 IT 管理员 / DevOps 工程师 Jeremy Caban 总结了以下最佳做法:
“想到的一件事是,学校围绕使用不同的 SSH 端口进行了思考。有了适当的安全措施,在大多数情况下,这几乎是没有问题的。但是,仍然可以有更多的安全层。”
尽管不一定要更改通信端口,但这是一个很好的最佳实践,因为它有助于减少自动攻击(例如暴力攻击)。考虑到您可以选择 65,536 个 TCP 通信端口,这很容易使威胁参与者难以确定正在使用哪个端口。(为此工作吧,对吧?)
根据互联网号码分配机构(IANA),端口号通常分为三组范围(其中一些可能需要 IANA 注册):
- 系统端口(0-1023),
- 用户端口(1024-49151)和
- 动态 / 专用端口(49152-65535)。注意:这些端口不需要 IANA 分配。
您可以通过 Linux 命令行在 SSH 配置文件中手动更改客户端程序的端口访问规范。这将强制 SSH 通过您选择的端口号进行连接。您还可以将防火墙配置为完全阻止对端口 22 的访问,或者也限制从受信任的主机对其的访问。有关如何更改默认 SSH 端口的具体说明,请参阅 linuxhint.com 的 Caban 建议文章。
SSH.com 还建议您禁用不需要的端口转发。端口转发是指“将应用程序端口从客户端计算机隧道传输到服务器 […],反之亦然”的过程。尽管它对组织有一定的合法用途,但网络罪犯也可以利用它作为内部网络的后门。
13.避免使用弱版本的 SSH 协议
可以轻松忽略的是用于客户端和服务器的 SSH 协议。例如,您要避免使用 SSH 版本 1(SSH-1),而应将其默认设置为使用 SSH 版本 2(SSH-2)。您要使用后者而不是前者的一个关键原因是,它更安全并且不易受到与 SSH-1 相同的一些安全利用的影响。
14.使您的 SSH 服务器和客户端保持最新状态
网络安全最被忽视的领域之一是应用补丁和其他更新。制造商发布更新和补丁来解决错误和严重漏洞,这可能会使您的组织和数据容易受到攻击。
坦白地说,补丁管理是您可以轻松使用自动化的领域,但是许多公司仍然无法实施这些制造商发布的修补程序。
关于有效 SSH 密钥管理的最终想法
像 SSL 和 TLS 一样,SSH 本身是一种加密网络协议,它可以通过开放通道进行安全身份验证和数据通信。SSH 密钥用作用户访问的一种替代方法,它允许用户以比仅使用传统登录凭据更安全的方式向服务器进行身份验证。但是,为了安全地使用此连接和身份验证过程,它需要严格的密钥管理策略,过程和实现。
为了确保组织的安全 Shell 使用的安全性,您需要具有可见性,并知道每个 SSH 密钥具有什么授权和访问权限。我希望本文可以作为有用的介绍和资源,帮助您实现更好,更安全的 SSH 密钥管理最佳实践。
与往常一样,如果您还有其他建议或最佳做法,请随时在下面的评论中分享您的想法。
最近新闻
2024年11月12日
2024年11月12日
2024年11月12日
2024年11月12日
2024年10月28日
2024年10月28日
2024年10月28日
2024年10月28日
需要帮助吗?联系我们的支持团队 在线客服