本文讨论增强Web3的运营安全性(OpSec)的方法,包括分层防御、密钥管理和安全流程。作者基于自己在卡支付行业的经验和SEAL 911的最佳实践,提供了一系列切实可行的建议,旨在帮助协议开发者和维护者保护用户及协议的资金。
通过经过验证的协议安全策略增强 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 要求。
防御的核心原则是深度。 “深度”可以通过多种方式来定义。在安全性方面,我们谈论一种多层次的方法。这包括组织结构、开发实践、操作流程、链下环境、密钥管理、链上合同等。所有内容都应设计为,即使一两层被攻破,系统 仍然保持安全,并避免灾难性损失。
每一层必须被强化和具备弹性,因为一个错误不应该导致灾难。我们都是人;我们会被社会工程攻击并点击错误的链接。泄露的 私钥 或甚至雇佣朝鲜黑客都不应使协议或用户资金面临风险。
任何系统都可能被攻破:任何服务器、任何软件都可能存在零日漏洞,任何提供商都可能遭遇数据泄露。你必须为这种可能性进行规划和设计。这就是分层防御的意义——不要盲目信任任何一层。
我们必须构建更强大、更具韧性的 платформ,执行警惕且无信任的流程。
任何链上设计的目标是最小化攻击面,并确保如果系统的某一部分被攻破,损害能够被控制。
SEAL 911 的 建议和最佳实践 对于密钥管理和交易签名进行了详细说明。最重要的要点是:
验证 calldata:如上所述,重新观看 Patrick 提供的绝佳指南,了解 如何验证 calldata(然后重新阅读 博客文章并保存书签)。建立一种验证程序,确保用户证明他们已验证 calldata(通过 哈希 或类似验证数据的照片)。
许多组织内部没有进行此类操作的技术专长,实在遗憾。如果这听起来像是你的组织,你 必须 至少有一个能够这样做的人,并将其签名和验证作为所有交易所需。只需明白,你正在创造一个单点故障!更好的解决方案是培训每位签署者进行 calldata 验证,并要求所有交易都进行验证。
锁定环境:
为虚拟机实施 严格的防火墙规则(iptables)以阻止不必要的访问。
安全的微服务通信:
强制严格的身份验证 和授权,使用 OAuth2 等标准进行。
定期更新:
关注相关的安全频道,保持对关键安全补丁的信息更新,并记录申请这些补丁的变更过程。
操作安全是一项共同的责任,问责制至关重要。
责任包括:
确保安全相关文档是最新的。
定期审查对维护长期安全至关重要。这是确保你的安全实践与最新标准保持一致的方式。同样重要的是,定期评估和挑战你的流程,以识别潜在的弱点,并确保你的系统能够抵御新兴威胁。以下是来自 PCI DSS 最佳实践(需要注册)的时间表:
SEAL 911 的最佳实践是一个活文档——你的贡献可以帮助改进它。加入这个努力 这里,帮助 web3 OpSec。
- 原文链接: cyfrin.io/blog/web3-oper...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!