提升 Web3项目运营安全：开发者和团队的最佳实践

通过经过验证的协议安全策略增强 web3 OpSec。了解分层防御、密钥管理和安全流程以保护用户和协议资金。

由于 ByBit 攻击仍然历历在目，我希望帮助 web3 社区 加强其操作安全 (OpSec)。这不是关于 ByBit 黑客事件的具体文章，而是你今天可以采取的 可行步骤 来保护你的环境和流程。如果你对 ByBit 黑客事件的细节以及如何防止类似事件感兴趣，Patrick Collins 有两段绝佳的视频：一段解读 黑客，另一段是关于如何 验证你签署的内容，同样在 Cyfrin 的博客发布：如何验证安全的多签钱包签名。

本指南是 针对协议开发人员、维护者和负责管理数百万甚至数十亿用户和协议资金的人。不适合最终用户——关于这一点有很多 优秀指南。如果你正在构建和维护处理大量资金的协议，你必须比一般用户更仔细地平衡便利性和安全性，特别是因为你正在管理其他人的或组织的钱。

在审核 区块链 协议之前，我在信用卡支付行业工作了十多年。我与 PCI DSS 要求合作，参与审计，提供证据，并维持合规环境，无论是在本地还是云中。对于那些不熟悉 PCI DSS 的人来说，它代表支付卡行业数据安全标准。该组织制定了处理 Visa、MasterCard 和其他卡品牌所需的安全标准。

尽管 PCI DSS 主要专注于保护支付环境和持卡人数据，但它强制执行的许多 流程对操作安全也很有帮助。Web3 可以从这些实践中学到很多东西。

在区块链的背景下，我强烈建议阅读 SEAL 911 团队的 全面 最佳实践。这个指南覆盖了 OpSec 的所有方面，内容丰富且详尽。阅读全文，加入书签，经常回顾。它本质上是 web3 OpSec 的圣杯。

本篇文章总结了 SEAL 的最佳实践，并增添了可操作的见解，灵感来自于与文档维护和定期审查相关的 PCI DSS 要求。

‍

分层防御

防御的核心原则是深度。 “深度”可以通过多种方式来定义。在安全性方面，我们谈论一种多层次的方法。这包括组织结构、开发实践、操作流程、链下环境、密钥管理、链上合同等。所有内容都应设计为，即使一两层被攻破，系统 仍然保持安全，并避免灾难性损失。

每一层必须被强化和具备弹性，因为一个错误不应该导致灾难。我们都是人；我们会被社会工程攻击并点击错误的链接。泄露的 私钥 或甚至雇佣朝鲜黑客都不应使协议或用户资金面临风险。

任何系统都可能被攻破：任何服务器、任何软件都可能存在零日漏洞，任何提供商都可能遭遇数据泄露。你必须为这种可能性进行规划和设计。这就是分层防御的意义——不要盲目信任任何一层。

我们必须构建更强大、更具韧性的 платформ，执行警惕且无信任的流程。

‍

为安全而设计链上内容

任何链上设计的目标是最小化攻击面，并确保如果系统的某一部分被攻破，损害能够被控制。

1. 无权限合约：使合约尽可能 无权限。被攻破的账户拥有的特权越少，造成的损害就越小。虽然无权限性是去中心化金融 ( DeFi ) 的核心原则，但这也是一种防御策略。通过限制特权行为，你减少了单个被攻破的密钥对你的系统造成破坏的风险。

‍

2. 维护者/管理机器人：这些机器人应尽可能 在没有特权访问的情况下运行。如果升级权限是必要的，使用来自主要云提供商的可信服务安全地存储密钥。这些密钥不应直接允许开发者访问。对于非应用访问，应进行日志记录，并需要安全官员的授权。这有助于防止敏感密钥的意外泄露或滥用。像 Chainlink Automation 这样的服务可以协助实现这一点。

‍

3. 时间锁特权角色：拥有提升权限的角色应指派给时间锁合约。此设置为敏感操作引入 故意延迟，使受信任的监护人（你全面验证了其安全性）能够在执行之前取消未经授权的更改。

‍

4. 变更的多重签名或 DAO：任何单个个人不应能够单独推动更改。关键操作应 需要 多个受信任党派的批准，以确保透明度并减少内部滥用或外部攻破的风险。

‍

5. 监护账户：监护账户也必须 由多重签名控制。这增加了额外的保护层，防止任何单一账户成为单点故障。

‍

6. 暂停和应急功能：模拟和测试各种故障场景。确保应急机制是健壮的，允许你在出现严重问题时迅速停止操作。

‍

密钥管理和签名

SEAL 911 的 建议和最佳实践 对于密钥管理和交易签名进行了详细说明。最重要的要点是：

1. 加密你的密钥：使用安全的保险库和秘密管理系统来保护敏感信息。

‍

2. 验证 calldata：如上所述，重新观看 Patrick 提供的绝佳指南，了解 如何验证 calldata（然后重新阅读 博客文章并保存书签）。建立一种验证程序，确保用户证明他们已验证 calldata（通过 哈希 或类似验证数据的照片）。

   • 许多组织内部没有进行此类操作的技术专长，实在遗憾。如果这听起来像是你的组织，你 必须 至少有一个能够这样做的人，并将其签名和验证作为所有交易所需。只需明白，你正在创造一个单点故障！更好的解决方案是培训每位签署者进行 calldata 验证，并要求所有交易都进行验证。

     ‍

3. 专用签名设备：专门为交易签名提供的计算机 。这限制了可能拦截敏感操作的恶意软件的暴露。

‍

4. 多元化密钥管理：在不同的设置和环境中分散你的密钥。使用不同的 硬件钱包 和操作系统降低了单一漏洞暴露所有资金的可能性。

‍

链下安全

1. 维护最小特权访问：授予用户和应用程序 所需的最低权限。

‍

2. 遵循云安全最佳实践：每个主要的云提供商均提供专注于安全的资源、认证和课程。了解你提供商的最佳实践 有助于防止可能导致数据 breaches 的错误配置。

‍

3. 锁定环境：

   • 使用 Kubernetes 网络策略 执行默认拒绝姿态。

   • 为虚拟机实施 严格的防火墙规则（iptables）以阻止不必要的访问。

     ‍

4. 安全的微服务通信：

   • 使用最新版 的 TLS 确保数据在传输中。限制 TLS 仅允许现代强加密（TLSv3）。

   • 强制严格的身份验证 和授权，使用 OAuth2 等标准进行。

     ‍

5. 定期更新：

   • 定期应用 安全补丁，无论是每月还是每季度。

   • 关注相关的安全频道，保持对关键安全补丁的信息更新，并记录申请这些补丁的变更过程。

     ‍

6. 监控网络流量：使用 OWASP 安全包保护你的端点免受已知威胁。

‍

开发和变更实践

1. 绝不要以明文存储密钥！再说一次。写下来。让它成为你的座右铭。

‍

2. 深思熟虑地测试：不要仅仅依赖于代码覆盖。关注边缘案例和失败场景。结合测试驱动开发 (TDD) 元素可以改善你的设计和安全思维方式。

‍

3. 强制进行代码审查。

‍

4. 使用 CI/CD 管道，确保只有经过 审查和漏洞扫描的代码 能够部署到生产环境。

‍

5. 部署程序：记录部署流程，考虑潜在的失败点。清晰的 应急计划 可以防止在部署过程中出现灾难。

‍

6. 配置审查：所有变更都应通过 同行审查，以减少人为错误的可能性。

‍

7. 紧急变更：记录并排练 紧急响应程序，以便你的团队在压力下知道该怎么做。

‍

持续运营

操作安全是一项共同的责任，问责制至关重要。

1. 分配安全职能：指定一个人或团队负责维护安全流程和文档。

‍

2. 责任包括：

   • 定期审查关键系统的日志。
   • 参与开发和设计流程以确保安全。
   • 监督配置变更。
   • 核实第三方依赖项的安全漏洞。

   • 确保安全相关文档是最新的。

     ‍

审查流程

定期审查对维护长期安全至关重要。这是确保你的安全实践与最新标准保持一致的方式。同样重要的是，定期评估和挑战你的流程，以识别潜在的弱点，并确保你的系统能够抵御新兴威胁。以下是来自 PCI DSS 最佳实践（需要注册）的时间表：

‍

每日

• 监控来自安全关键系统的日志，如防火墙、入侵检测系统 (IDS) 和身份验证服务器，以及发出的事件和关键交易。
• 禁用已终止的用户账户。

每季度

• 审查密钥保管和保管人，并确认密钥未被篡改。
• 审查所有用户访问级别，以确保没有人拥有不必要的特权。
• 主动替换即将到期的证书。

每半年

• 重新评估所有特权账户的权限。在此上下文中，特权账户特指机器人或服务。
• 审核环境中的所有安全配置，包括云安全设置和 GitHub 的存储库与 CI 配置。确保它们与最新的最佳实践保持一致。
• 审查并更新所有安全相关文档，包括变更管理、部署程序、开发工作流程及入职/离职流程。确保这些文档保持清晰、全面，并与当前的安全最佳实践一致，以应对不断变化的威胁。

每年

• 进行全面的事件响应演练以测试组织的准备情况。
• 审查并更新 DevOps 和开发者培训程序。确保所有访问关键环境的人具备必要的知识，并对其角色相关的安全协议、工具和最佳实践有最新了解。

‍

你可以如何帮助

SEAL 911 的最佳实践是一个活文档——你的贡献可以帮助改进它。加入这个努力 这里，帮助 web3 OpSec。

‍

资源和进一步阅读

• PCI DSS V2.0 固持 PCI DSS 合规性的最佳实践.pdf
• PCI-DSS-v4_0_1.pdf
• https://frameworks.securityalliance.org/
• https://www.iso.org/standard/27001

• 原文链接： cyfrin.io/blog/web3-oper...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～