Storage Security Guide: Hardening SAN, NAS and Object

Storage arrays, filers and object stores hold every copy of an organisation's data, including the snapshots and backups it plans to recover from, yet their management interfaces are often reachable from the general network and run on shared admin accounts. An attacker with storage administrator rights does not need to encrypt files one by one: deleting volumes, snapshots and replicas achieves the same result in minutes. This guide covers the identity and access model of SAN (Fibre Channel and iSCSI), NAS (SMB and NFS) and object storage, privileged administration, the service accounts and tokens that integrations rely on, logging and detection, and a hardening baseline built around NIST SP 800-209. It is for storage, infrastructure and security engineers who run on-premises or hybrid storage. Data classification and protection policy are covered in the Data Security Guide.

Key takeaways

Separate the management plane from the data plane: array and filer management interfaces belong on an isolated admin network reached through privileged access workstations, never on the user LAN or the internet.
Storage admin is a tier 0 role: it can destroy every recovery point, so it needs phishing-resistant MFA, individual named accounts, a directory separate from user identities and multi-person approval for destructive operations.
Make at least one copy immutable: locked snapshots, WORM object storage (such as S3 Object Lock in compliance mode) or an isolated vault mean a compromised admin cannot remove the last good copy.
Integrations are privileged non-human identities: backup NDMP accounts, hypervisor plug-ins, replication partners and S3 access keys often hold more rights than any human and are rarely rotated.
Log and alert on the destructive verbs: volume, snapshot and replica deletion, retention changes, new admin accounts and lifecycle rule changes should page someone in real time.

How identity and access work in storage

NIST SP 800-209 (Security Guidelines for Storage Infrastructure, October 2020) groups storage-specific controls under data protection, isolation, restoration assurance and encryption, alongside general areas such as authentication and authorisation, change management and configuration control. Its threat list explains why identity matters: credential theft, privilege escalation that lets an attacker delete volumes or change access settings, misconfiguration such as replication left disabled after maintenance, and compromise or poisoning of backups. Each storage type controls access differently.

Storage type	Who or what is authenticated	Access control mechanism	Weak default to fix
Fibre Channel SAN	Host bus adapter port (WWPN), not a user	Fabric zoning (prefer single-initiator zones) plus LUN masking on the array	Broad zones and masking by host group, so any host in the zone can mount any LUN; WWPNs can be spoofed by a host administrator
iSCSI SAN (TCP 3260)	Initiator name (IQN), optionally CHAP secret	Target access lists, CHAP or mutual CHAP, dedicated VLAN	No CHAP, IQN-only filtering, iSCSI on routed user networks
NAS: SMB (TCP 445)	Users and computers through Active Directory (Kerberos or NTLM)	Share and NTFS-style ACLs	SMB1 enabled, signing not required, Everyone or Authenticated Users on shares
NAS: NFS (TCP 2049)	With AUTH_SYS, the client's claimed UID and GID; with Kerberos, the user principal	Export rules by client address, root squash, `sec=krb5`, `krb5i` or `krb5p`	AUTH_SYS exports to whole subnets with root squash disabled, which trusts any host that can claim root
Object storage (S3 compatible, HTTPS)	Access key pairs, federated roles or tokens	Bucket and identity policies, ACLs, object lock	Long-lived access keys with wildcard actions, public or cross-account bucket policies

SAN: treat zoning and masking as two independent layers and audit both against the host inventory. Use mutual CHAP for iSCSI and keep iSCSI on non-routed storage VLANs.
SMB: disable SMB1, require signing (the RequireSecuritySignature setting on Windows servers and clients, or the array's equivalent), and use Kerberos rather than NTLM. Microsoft documents that signing detects tampering and relayed or spoofed messages, which blocks SMB relay (ATT&CK T1557.001). Enable SMB encryption for shares holding sensitive data.
NFS: use NFSv4 with Kerberos (krb5p where confidentiality on the wire matters), keep root squash on, and restrict exports to named hosts. AUTH_SYS should be limited to tightly controlled networks.
Object: prefer short-lived federated credentials over static keys, block public access at account level, and deny dangerous operations (for example, customer-provided encryption keys) unless an application needs them. See the MinIO and S3 Compatible Object Storage Security Guide and the Amazon S3 Security Guide.

Admin roles and privileged access

SP 800-209 has a dedicated section on administrative access, and it is where most storage compromises are decided. The array or filer administrator can remove snapshots, break replication, reformat volumes and change retention, so the role belongs in tier 0 with domain controllers and backup servers.

Named accounts only: disable or vault the default admin or root account after creating individual accounts; keep one break-glass account with its credential in a sealed vault and alerting on use.
Separate identity source: do not let the storage management plane trust the production Active Directory domain that ransomware operators target first. Use local accounts with MFA, a separate admin forest, or an identity provider with phishing-resistant MFA for administrators.
Role-based access: split monitoring (read only), provisioning (create volumes, shares, LUNs) and destructive or security roles (delete, retention, encryption keys, user management). Few people need the last.
Multi-person approval: many enterprise platforms now offer a feature that requires a second administrator to approve destructive commands. NetApp ONTAP's multi-admin verification (from version 9.11.1), for example, can protect operations such as volume and snapshot deletion and does not let a requester approve their own request. Where your platform has such a feature, enable it for deletion, retention and snapshot policy changes.
Management network isolation: management interfaces (web UI, SSH, REST API, service processor or baseboard controllers) on a dedicated network reachable only from privileged access workstations or a jump host with session recording. See the Privileged Access Workstations Guide.
Vendor support access: remote support tunnels and "phone home" channels should be disabled by default and opened per case, with the vendor's session logged.

Integrations, API tokens and service accounts

Integration	Typical credential	Risk	Control
Backup software (NDMP, snapshot orchestration)	Array service account, NDMP password	Often has delete rights on snapshots; compromise of the backup server becomes compromise of storage	Dedicated account with only the operations backup needs; no snapshot delete outside retention policy; see the Backup Identity Isolation Guide
Hypervisor plug-ins (vCenter, Hyper-V, VSS providers)	Array admin credential stored in the hypervisor manager	Hypervisor compromise yields storage admin	Scoped role per plug-in; review stored credentials; see the ESXi Ransomware Playbook
Kubernetes CSI drivers	Array API token in a Kubernetes secret	Anyone who can read the secret controls provisioning	Tenant or namespace scoped accounts; encrypt secrets; restrict RBAC on the secret
Replication partners	Peer cluster trust, passphrase or certificate	A compromised peer can delete or corrupt replicas	Pair only with managed sites; separate admin domains per site; protect the target's snapshots independently
Monitoring and automation	SNMP communities, REST API tokens, Ansible or Terraform credentials	SNMPv1/v2c communities are clear text; automation tokens often hold full admin	SNMPv3 with authentication and privacy; read-only monitoring tokens; automation credentials in a vault with rotation
Object storage clients	Access key pairs	Leaked keys allow bulk overwrite or deletion	Short-lived role credentials; per-application keys scoped to bucket and actions; rotation and leak scanning
External key managers (KMIP)	Client certificate on the array	Loss of the key manager makes encrypted volumes unreadable	Redundant key managers, certificate lifecycle tracking, tested key recovery

Inventory these credentials as non-human identities with an owner, a rotation date and a documented scope. See the Service Account Security Guide.

Immutability and recovery assurance

SP 800-209 treats restoration assurance as a storage-specific control area, and warns that attackers may target backup copies directly or poison future backups so that recovery copies are too old or already infected. In practice:

Locked snapshots: use the platform's tamper-proof or locked snapshot feature with a retention period that a single administrator cannot shorten.
WORM object storage: on S3 and compatible stores, Object Lock (which requires versioning) offers governance mode, which users with s3:BypassGovernanceRetention can override, and compliance mode, in which no user, including the root user, can delete a protected version or shorten retention. Use compliance mode for the last-resort copy and governance mode while testing retention settings.
Isolated copy: keep a copy in a separate administrative domain (different credentials, different identity source, ideally a different site or provider), so one compromise cannot reach every copy. See the Backup Security and Immutable Backup Guide.
Built-in anomaly detection: some arrays analyse entropy and file extension changes and take automatic snapshots when activity looks like encryption (NetApp's Autonomous Ransomware Protection is one example). Treat it as an early warning, not a substitute for immutable copies.
Test restores: restore from immutable copies on a schedule and verify integrity before relying on them, as NIST CSF 2.0 RC.RP-03 expects.

Logging and detection

SP 800-209 includes audit logging as a recommendation area. Forward array, filer and object storage audit logs to the SIEM over an authenticated channel, with time synchronised by NTP, and keep a copy outside the storage system being monitored.

Event	Why it matters	Response
Deletion of volumes, LUNs, snapshots or replicas outside change windows	Inhibit system recovery (ATT&CK T1490) and data destruction (T1485)	Page on-call immediately; verify with the change record
Snapshot policy or retention reduced, object lock or legal hold removed, lifecycle rules added	Preparation for destruction; lifecycle expiry was used in the Codefinger S3 ransomware campaign	Alert and require second approval
New administrator account, role change or authentication source change	Persistence with valid accounts (T1078)	Alert; verify with identity team
Admin logins from outside the management network or at unusual times	Credential misuse	Alert; force re-authentication
Spikes in file renames, writes with high entropy, or bulk object overwrites	Encryption for impact (T1486)	Isolate client, take protective snapshots, start ransomware playbook
Clients connecting without SMB signing or encryption	Relay or downgrade exposure	Use the Windows audit settings (for example `AuditClientDoesNotSupportSigning`) before enforcing
Export, share or bucket policy changes to broad or public access	Exposure of data	Alert; auto-revert where possible

Metrics that show the programme is working:

Share of storage systems with management interfaces reachable only from the admin network (target 100%).
Share of administrator accounts that are named, MFA-protected and outside the production user directory (target 100%).
Share of critical datasets with at least one immutable or isolated copy, and the age of the last successful restore test from it.
Integration credentials older than their rotation period (target 0).
Mean time from a destructive storage event to human acknowledgement.

Hardening baseline

Inventory: list every array, filer, object store, management interface, service processor, integration credential and replication relationship. Record firmware versions.
Isolate management: move management interfaces to the admin network, restrict by firewall to jump hosts, and disable unused services (telnet, HTTP, FTP, SNMPv1/v2c) per NIST SP 800-53 CM-7.
Fix administration: named accounts, MFA, separate identity source, role split, break-glass procedure, multi-person approval where supported. Test by attempting a protected deletion with one account.
Harden protocols: SMB1 off and signing required (audit first, then enforce), NFS with Kerberos and root squash, mutual CHAP for iSCSI, single-initiator zoning, TLS on object endpoints.
Encrypt at rest: self-encrypting drives or array encryption with keys held in an external key manager over KMIP where possible, with documented key recovery. See the Database and Storage Encryption Guide.
Immutable copies: locked snapshots and an isolated or WORM copy for critical data, with restore tests.
Patch: track firmware and operating system advisories for arrays and NAS devices; SP 800-209 notes that many successful attacks exploit vulnerabilities with published fixes. Never expose consumer or SMB NAS management to the internet.
Log and alert: forward audit logs and build the detections above.

Rollback and testing: enforce SMB signing and NFS Kerberos per share or export in pilot groups, keep the previous export and share configuration exported, and schedule changes in maintenance windows with application owners. A failed client can be moved back to the old export while it is fixed, without reverting the whole system.

Small versus large: a small organisation with one NAS should prioritise removing internet exposure, MFA on the admin account, firmware updates and an offline or immutable cloud copy. Large estates need the full baseline plus multi-person approval, separate admin domains per site and automated configuration drift checks.

Common misconfigurations

Storage admin through the production domain: a domain admin compromise becomes a storage admin compromise, and the attacker deletes snapshots before deploying ransomware.
NAS management on the internet: web interfaces or remote access services published through port forwarding or UPnP, then hit by mass exploitation of known vulnerabilities.
Everyone-writable shares and AUTH_SYS exports: any compromised workstation can encrypt the share; any host on the subnet can claim to be root over NFS.
Snapshots treated as backups: snapshots on the same array, deletable by the same admin, are not an independent recovery copy.
Static object storage keys: long-lived keys with write and lifecycle permissions, as in the Codefinger campaign, where stolen AWS keys were used to re-encrypt objects with attacker-held keys and schedule deletion within seven days.
Replication left off after maintenance: a scenario SP 800-209 calls out; nobody notices until the recovery site is needed.

Framework mapping

Framework	Reference	Storage control
NIST SP 800-209	Sections 4.2 to 4.10	Data protection, access control, audit logging, cyber recovery, network configuration, isolation, restoration assurance, encryption, administrative access
NIST SP 800-53 Rev. 5	AC-3; AC-6(5); IA-2(1); CM-7; AU-2; SC-28; CP-9 and CP-9(8)	Access enforcement, privileged accounts, MFA for privileged accounts, least functionality, logging, encryption at rest, protected backups
NIST CSF 2.0	PR.DS-01; PR.DS-11; RC.RP-03	Data at rest protected; backups protected and tested; backup integrity verified before restore
ISO/IEC 27001:2022 Annex A	A.8.2 Privileged access rights; A.8.13 Information backup; A.8.24 Use of cryptography; A.8.22 Segregation of networks	Admin control, backups, encryption, management network
CIS Controls v8.1	Control 3 Data Protection; Control 4 Secure Configuration; Control 11 Data Recovery	Baseline, encryption and recovery
MITRE ATT&CK	T1486; T1490; T1485; T1078; T1557.001; T1021.002	Ransomware impact, recovery inhibition, valid accounts, SMB relay and admin shares

Practitioner checklist

Inventory arrays, filers, object stores, management interfaces, integrations and replication links.
Place all management interfaces on an isolated admin network reachable only from PAWs or recorded jump hosts.
Use named, MFA-protected admin accounts outside the production user directory; vault the default and break-glass accounts.
Enable multi-person approval for destructive operations where the platform supports it.
Scope, vault and rotate integration credentials (backup, hypervisor, CSI, automation, object keys).
Require SMB signing, disable SMB1, use NFS Kerberos with root squash, mutual CHAP and single-initiator zoning.
Keep at least one locked, WORM or isolated copy of critical data and test restores from it.
Forward audit logs off-box and alert on deletion, retention, admin and policy changes.
Patch storage firmware promptly and never expose NAS management to the internet.

Storage Infrastructure Security Guide: Hardening SAN, NAS and Object Storage