Solidity 智能合约中如何实现访问控制？有哪些最佳实践？

访问控制是 Solidity 智能合约安全的第一道防线。据统计，2025 年上半年因访问控制漏洞造成的损失超过 16 亿美元，位居 OWASP Web3 安全威胁榜首。面试中，访问控制是高频考点，面试官通常从 Ownable 入手，逐步追问到 RBAC、多签和时间锁的组合方案。

一、Ownable 模式：最基础的访问控制

Ownable 是最简单的访问控制方式——合约只有一个 owner，只有 owner 能执行特定函数。

solidity
contract Ownable {
    address public owner;

    event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

    constructor() {
        owner = msg.sender;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Not the owner");
        _;
    }

    function transferOwnership(address newOwner) public onlyOwner {
        require(newOwner != address(0), "Invalid address");
        emit OwnershipTransferred(owner, newOwner);
        owner = newOwner;
    }
}

面试追问：transferOwnership 有什么安全隐患？

直接转移所有权存在误操作风险——如果 owner 把权限转给一个错误地址，合约将永久失去管理能力。OpenZeppelin 的 Ownable2Step 用两步转移解决这个问题：先提名新 owner，新 owner 必须主动接受才能生效。

solidity
// Ownable2Step 核心逻辑
function transferOwnership(address newOwner) public onlyOwner {
    pendingOwner = newOwner;  // 第一步：提名
}

function acceptOwnership() public {
    require(msg.sender == pendingOwner, "Not pending owner");
    _transferOwnership(pendingOwner);  // 第二步：接受
}

二、AccessControl：角色基础的访问控制（RBAC）

当合约需要多种角色时，Ownable 就不够用了。OpenZeppelin 的 AccessControl 提供了基于角色的访问控制。

solidity
import "@openzeppelin/contracts/access/AccessControl.sol";

contract RoleBased is AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    bytes32 public constant PAUSER_ROLE = keccak256("PAUSER_ROLE");

    constructor() {
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
        _grantRole(MINTER_ROLE, msg.sender);
    }

    function mint(address to, uint256 amount) public onlyRole(MINTER_ROLE) {
        // 铸造逻辑
    }

    function pause() public onlyRole(PAUSER_ROLE) {
        // 暂停逻辑
    }
}

关键机制：角色的 admin 角色

每个角色都有一个 admin 角色，只有 admin 角色的成员才能授予或撤销该角色。默认情况下，DEFAULT_ADMIN_ROLE 是所有角色的 admin。你可以通过 _setRoleAdmin 自定义层级关系：

solidity
// 设置 MINTER_ROLE 的 admin 为 ADMIN_ROLE
bytes32 public constant ADMIN_ROLE = keccak256("ADMIN_ROLE");

constructor() {
    _setRoleAdmin(MINTER_ROLE, ADMIN_ROLE);
    _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
    _grantRole(ADMIN_ROLE, msg.sender);
}

这样，只有 ADMIN_ROLE 成员才能管理 MINTER_ROLE，实现了权限分层。

面试追问：AccessControl 内部如何存储角色？

角色信息存储在 mapping(bytes32 => mapping(address => bool)) 中，bytes32 是角色的哈希，address 是账户。查询某个角色成员使用 hasRole(role, account)，授予和撤销分别用 _grantRole 和 _revokeRole。

三、多签控制：分散单点风险

单 owner 是单点故障——私钥泄露或丢失就失去控制权。多签要求 N 个签名人中至少 M 个同意才能执行操作。

solidity
contract SimpleMultiSig {
    address[] public signers;
    mapping(address => bool) public isSigner;
    uint256 public required;

    struct TxProposal {
        address target;
        uint256 value;
        bytes data;
        uint256 confirmCount;
        bool executed;
    }

    TxProposal[] public proposals;
    mapping(uint256 => mapping(address => bool)) public confirmed;

    modifier onlySigner() {
        require(isSigner[msg.sender], "Not signer");
        _;
    }

    constructor(address[] memory _signers, uint256 _required) {
        require(_required > 0 && _required <= _signers.length);
        for (uint i = 0; i < _signers.length; i++) {
            isSigner[_signers[i]] = true;
        }
        signers = _signers;
        required = _required;
    }

    function propose(address target, bytes calldata data) external onlySigner returns (uint256) {
        proposals.push(TxProposal(target, 0, data, 0, false));
        return proposals.length - 1;
    }

    function confirm(uint256 id) external onlySigner {
        require(!confirmed[id][msg.sender], "Already confirmed");
        confirmed[id][msg.sender] = true;
        proposals[id].confirmCount++;
    }

    function execute(uint256 id) external onlySigner {
        TxProposal storage p = proposals[id];
        require(p.confirmCount >= required, "Not enough confirmations");
        require(!p.executed, "Already executed");
        p.executed = true;
        (bool ok, ) = p.target.call{value: p.value}(p.data);
        require(ok, "Call failed");
    }
}

实际项目中的选择：Gnosis Safe（现 Safe）是最广泛使用的多签方案，支持任意 M-of-N 配置。许多 DeFi 协议的 treasury 和关键参数都用 Safe 管理。

四、时间锁：给用户反应时间

时间锁为敏感操作添加延迟，即使攻击者获得了权限，也无法立即执行恶意操作，用户有时间应对。

solidity
contract Timelock {
    uint256 public constant DELAY = 2 days;

    struct QueuedAction {
        bytes32 actionHash;
        uint256 executeAfter;
        bool executed;
    }

    mapping(bytes32 => QueuedAction) public queued;

    event Queued(bytes32 indexed hash, uint256 executeAfter);
    event Executed(bytes32 indexed hash);
    event Cancelled(bytes32 indexed hash);

    function queue(bytes32 hash) external onlyOwner {
        require(queued[hash].executeAfter == 0, "Already queued");
        queued[hash] = QueuedAction(hash, block.timestamp + DELAY, false);
        emit Queued(hash, block.timestamp + DELAY);
    }

    function execute(bytes32 hash) external {
        QueuedAction storage a = queued[hash];
        require(a.executeAfter > 0, "Not queued");
        require(block.timestamp >= a.executeAfter, "Too early");
        require(!a.executed, "Already executed");
        a.executed = true;
        emit Executed(hash);
    }

    function cancel(bytes32 hash) external onlyOwner {
        require(!queued[hash].executed, "Already executed");
        delete queued[hash];
        emit Cancelled(hash);
    }
}

面试追问：时间锁的延迟设多久合适？

没有标准答案，需要权衡安全性和效率。常见选择：2-7 天。太短用户来不及反应，太长影响协议运营效率。Compound 和 Uniswap 的治理时间锁都用 2 天。

五、代币加权控制：去中心化治理

DAO 场景下，权限不是给固定地址，而是根据代币持有量分配。

solidity
contract TokenGated {
    IERC20 public token;
    uint256 public threshold;

    modifier onlyHolder() {
        require(token.balanceOf(msg.sender) >= threshold, "Insufficient tokens");
        _;
    }

    function propose(bytes memory data) public onlyHolder {
        // 提案逻辑
    }
}

注意事项：直接按余额投票存在闪贷攻击风险——攻击者可以在一个交易中借入大量代币投票后归还。解决方案包括：快照投票（在特定区块高度记录余额）、时间加权（持有时间越长权重越大）。

六、生产级组合方案

实际项目中通常组合多种模式。以下是一个结合 RBAC + 白名单 + 可暂停 + 时间锁的综合方案：

solidity
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/security/Pausable.sol";

contract ProductionAccess is AccessControl, Pausable {
    bytes32 public constant OPERATOR_ROLE = keccak256("OPERATOR_ROLE");
    bytes32 public constant GUARDIAN_ROLE = keccak256("GUARDIAN_ROLE");

    mapping(address => bool) public whitelist;
    bool public whitelistEnabled;

    constructor() {
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
        _grantRole(OPERATOR_ROLE, msg.sender);
        _grantRole(GUARDIAN_ROLE, msg.sender);
    }

    modifier onlyWhitelisted() {
        require(!whitelistEnabled || whitelist[msg.sender], "Not whitelisted");
        _;
    }

    function process(address user, uint256 amount)
        public onlyRole(OPERATOR_ROLE) onlyWhitelisted whenNotPaused
    {
        // 核心业务逻辑
    }

    function emergencyPause() external onlyRole(GUARDIAN_ROLE) {
        _pause();
    }

    function setWhitelist(address user, bool status) external onlyRole(OPERATOR_ROLE) {
        whitelist[user] = status;
    }
}

角色设计原则：将紧急暂停权限给 Guardian 而非 Operator，实现职责分离。这样即使 Operator 密钥泄露，攻击者也无法暂停合约， Guardian 也无法执行业务操作。

七、常见安全陷阱与审计要点

1. 永远不要用 tx.origin 做权限检查

solidity
// 危险：钓鱼合约可诱导用户调用，借 tx.origin 绕过检查
modifier onlyOwner() {
    require(tx.origin == owner, "Not owner"); // 错误！
    _;
}

// 正确
modifier onlyOwner() {
    require(msg.sender == owner, "Not owner");
    _;
}

tx.origin 会追溯到交易发起的 EOA，中间合约调用会"继承"原始调用者的身份，钓鱼攻击正是利用这一点。

2. 权限转移必须校验地址

solidity
function transferOwnership(address newOwner) public onlyOwner {
    require(newOwner != address(0), "Zero address");  // 防止误转零地址
    require(newOwner != address(this), "Self transfer"); // 防止转给合约自身
    owner = newOwner;
}

3. 可升级合约的访问控制

使用 UUPS 或透明代理模式时，代理合约和实现合约的 owner 可能不同。透明代理通过 ProxyAdmin 管理升级权限，确保用户调用和管理员调用走不同路径，避免函数选择器冲突。

4. 最小权限原则

只授予完成工作所需的最低权限。审计中常见的发现是 DEFAULT_ADMIN_ROLE 被过度授予——每个管理员都能管理所有角色，应该按职能细分。

5. 事件与监控

所有权限变更操作都应触发事件，方便链下监控异常：

solidity
event RoleGranted(bytes32 indexed role, address indexed account, address indexed sender);
event RoleRevoked(bytes32 indexed role, address indexed account, address indexed sender);
event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

如何选择访问控制方案

场景	推荐方案	原因
简单合约	Ownable / Ownable2Step	单 owner 足够，两步转移防误操作
多角色合约	AccessControl (RBAC)	角色分层，灵活授权
高价值资金	多签 + 时间锁	分散风险，提供缓冲期
DAO 治理	代币加权 + 快照	去中心化决策，防闪贷攻击
生产环境	RBAC + 暂停 + 白名单	职责分离，多层防护

选择时核心考量：资金规模、用户数量、去中心化程度、紧急响应需求。没有万能方案，但有一条通用原则——宁可权限设计过度严格再逐步放宽，也不要部署后才发现权限过松。