iSCSI（Internet Small Computer System Interface）把SCSI指令封装在TCP/IP报文中传输，让以太网具备了承载块级存储的能力。相比FC光纤通道，它的硬件成本低、管理门槛低，被大量用于中小企业的SAN存储、虚拟化平台的后端存储和备份系统。但正因为iSCSI跑在普通IP网络上，它继承了IP网络的全部攻击面：嗅探、伪造、中间人、拒绝服务，而存储流量一旦失守，损失的往往是整个数据库或全部虚拟机磁盘。iSCSI存储网络安全不能只靠一个开关解决，需要从网络隔离、身份认证、传输加密、访问控制几个层面协同构建。
iSCSI面临的主要安全威胁有哪些
第一个威胁是明文传输导致的嗅探风险。iSCSI协议本身不加密，SCSI命令、LBA地址、数据载荷全部以明文形式在网络上传输。攻击者只要能在存储网络路径上抓包，就能直接还原出数据库文件、虚拟机磁盘镜像的内容。这一点与NFS、SMB早期版本的问题类似，但块级存储泄露的数据往往是整块磁盘，影响面更大。
第二个威胁是未授权访问和伪造发起端。iSCSI采用发起端（Initiator）与目标端（Target）的架构，如果目标端没有配置认证，任何知道目标IP和IQN名称的主机都可以发起登录，直接挂载LUN并读取甚至格式化其中的数据。更危险的是，攻击者可以伪装成合法发起端的IQN，将真正的主机踢下线或者争夺同一LUN的写权限，造成文件系统损坏。
第三个威胁来自CHAP认证本身的弱点。CHAP基于共享密钥的挑战应答机制，密钥从不在线路上明文传输，这点比明文口令强。但单向CHAP只验证发起端身份，目标端不证明自己，存在伪装目标端钓鱼的场景；而且如果密钥设置得过短或多个发起端共用同一密钥，暴力破解和横向渗透的门槛会大幅降低。此外，iSCSI依赖TCP 3260端口，网络层的DDoS、TCP劫持同样会影响存储可用性。
网络层隔离：安全架构的第一道防线
iSCSI安全设计的核心原则是：存储流量永远不应该与业务流量、办公流量混跑在同一个网段。最基础的做法是为存储网络划分独立的VLAN，并使用专门的物理网卡或独立的交换机承载iSCSI流量。很多存储厂商的最佳实践都要求iSCSI流量与生产网络物理隔离，服务器通过专用的存储网卡连接存储交换机，业务网卡与存储网卡之间不做路由。
如果受限于硬件无法完全物理隔离，至少要做到逻辑隔离并配合ACL策略。在交换机上配置访问控制列表，只允许发起端IP访问目标端的3260端口，其他流量一律丢弃。同时关闭存储VLAN的网关路由，避免存储流量被路由到办公网或互联网。下面是一个典型的端口级ACL配置思路：
# 交换机ACL示例：仅放行指定网段访问iSCSI目标端口 access-list 120 remark iSCSI-ACL access-list 120 permit tcp 10.10.20.0 0.0.0.255 host 10.10.20.100 eq 3260 access-list 120 deny ip any any log interface Vlan20 ip access-group 120 in
另外要注意关闭不必要的服务。存储阵列的管理接口、iSCSI目标端口应分别放在不同网段，管理接口只允许跳板机访问。一些阵列还支持绑定发起端IP与IQN的校验，即使认证被绕过，IP不匹配的连接也会被拒绝，这是成本很低但很有效的一层约束。
CHAP双向认证与访问控制配置实践
CHAP是iSCSI最常用的身份认证机制，强烈建议启用双向CHAP（Mutual CHAP），让发起端和目标端互相验证身份，杜绝伪装目标端的攻击。密钥管理上要注意：长度至少16位以上随机字符串，每个发起端使用独立密钥，避免一把钥匙开所有门。在Linux发起端上，双向CHAP的配置写在/etc/iscsi/iscsid.conf中：
# /etc/iscsi/iscsid.conf 关键配置 node.session.auth.authmethod = CHAP node.session.auth.username = sql-server01 node.session.auth.password = InitiatorSecret!x9Kq2 # 双向CHAP：验证目标端身份 node.session.auth.username_in = target-array01 node.session.auth.password_in = TargetSecret!m7Wp4
在目标端（以Linux的targetcli为例），需要为每个发起端创建独立的ACL条目并绑定CHAP账号，同时将LUN的映射限定到具体发起端，而不是图省事对所有人开放：
# targetcli 中配置认证与访问控制 cd /iscsi/iqn.2005-10.org.open-iscsi:target-array01/tpg1 set attribute authentication=1 demo_mode_write_protect=0 generate_node_acls=0 # 为指定发起端创建ACL（禁用自动生成ACL） create iqn.1991-05.com.microsoft:sql-server01 cd iqn.1991-05.com.microsoft:sql-server01 set auth userid=sql-server01 password=InitiatorSecret!x9Kq2 set auth mutual_userid=array01 mutual_password=TargetSecret!m7Wp4
这里有个容易踩的坑：generate_node_acls=0必须设置，否则target会为任何发起端自动生成ACL，等于认证形同虚设。配置完成后用iscsiadm -m discovery -t sendtargets -p 10.10.20.100测试发现，再执行登录并观察日志中的认证记录，确认双向验证均通过。
传输加密与日常运维审计
当iSCSI流量必须经过不可信链路（例如跨机房由第三方提供的专线）时，仅靠隔离和认证不够，需要对流量加密。主流方案有两种：一是IPSec隧道，在存储主机与阵列之间建立传输模式的ESP加密，性能开销取决于是否有硬件加速卡；二是选用支持原生加密的新一代协议方案。对大多数场景，IPSec的ESP-AES128配置在独立网卡上，配合网卡TSO与RSS卸载，吞吐损耗可以控制在可接受范围内。
# Linux strongSwan IPSec 传输模式保护iSCSI流量示例
conn iscsi-protect
left=10.10.20.11
right=10.10.20.100
authby=secret
esp=aes128-sha1
type=transport
auto=start日常运维层面，建议把以下几项纳入巡检清单：定期轮换CHAP密钥并核对发起端清单，清理已经下线主机的ACL条目；监控目标端的登录失败日志，短时间内大量失败往往意味着有人在扫描或暴力破解；关注每个LUN的并发会话数，同一LUN出现多个意外会话要立即排查；对存储交换机的配置做基线管理，任何新增端口或VLAN变更都要走审批流程。
把这些措施组合起来，iSCSI完全可以在安全性和成本之间取得平衡，成为可靠的企业级块存储方案。安全的本质是纵深防御，单一手段总有被绕过的可能，而隔离、认证、加密、审计层层叠加之后，攻击者的每一步都要付出高昂代价，这才是存储网络安全的正确打开方式。