# Ensure Network File Storage Shares Are Restricted To Authorized VPC Or IP Ranges - Source: https://support.icompaas.com/support/solutions/articles/ensure-network-file-storage-shares-are-restricted-to-authorized-vpc-or-ip-ranges - Section: [Solutions](https://support.icompaas.com/support/solutions) › [DigitalOcean Cloud](https://support.icompaas.com/support/solutions/c_do_cloud) › [DigitalOcean Rules](https://support.icompaas.com/support/solutions/folders/digitalocean-rules) - Last updated: 2026-08-13 - Publisher: iCompaas, Inc. (https://www.icompaas.com) ## Description This rule checks that DigitalOcean Network File Storage (NFS) shares are reachable only from specific, authorized networks. DigitalOcean NFS controls access by VPC network, not by IP range — a share is attached to one or more VPCs (via access points) and can be mounted only by Droplets and DOKS nodes inside those VPCs, with all NFS traffic staying on the private VPC network. The rule inspects each share's attached VPCs and access points and flags shares attached to broad or shared VPCs that include hosts which should not have file access, as well as default access points left attached to more VPCs than the workload requires. Where path-level isolation is needed, subdirectory access points restrict a client to a specific path within the share. Remediation is to attach each share only to the VPC(s) hosting its authorized clients, detach any unneeded VPC, and use subdirectory access points to narrow path access. - NFS shares attached to VPC networks that contain hosts outside the intended client set. - Default (root) access points attached to more VPCs than required. ## Rationale An NFS share is mountable by any host that can reach it on its VPC, and a POSIX file share exposes every file it holds for read/write to those clients. Over-broad VPC attachment therefore lets unrelated workloads mount and read or modify shared data. Because DigitalOcean has no IP-level firewall for NFS — there is no security-group construct, and Cloud Firewalls govern Droplet ports rather than the NFS access model — the VPC attachment set is the primary access boundary and must be kept minimal. Scoping to the smallest VPC (and to subdirectory paths where possible) enforces least privilege and keeps a compromise of one workload from reaching another team's files on the same share. ## Impact Pros: - Limits which hosts can mount the share to the intended VPC(s) only. - Keeps all NFS traffic on the private network, off the public internet. - Subdirectory access points enforce path-level least privilege between teams or applications. Cons: - Tightening VPC attachments can break clients that relied on incidental access; mounts must be re-pointed. - Segmenting workloads may require additional VPCs or shares. - Access points are region-scoped, so multi-region clients need their own arrangements. ## Default Value A Network File Storage share is attached to the VPC network(s) you select at creation and is mountable by any Droplet or DOKS node in those VPCs; its default access point can be attached to up to 10 VPCs in the same region. ## Pre-Requisite - Account role that can manage NFS shares and their VPC attachments. - Knowledge of which VPC(s) host the share's authorized clients. - doctl authenticated or an API token to inspect shares and access points at scale. ## Remediation ### Test Plan Using the DigitalOcean Control Panel: 1. Sign in at cloud.digitalocean.com and open Network File Storage from the left menu (Manage > Network File Storage). 2. Open the share and review its attached VPC networks and access points. 3. Confirm each attached VPC contains only hosts that should be able to mount the share, and that no unneeded VPC is attached. 4. Pass: the share is attached only to the VPC(s) hosting authorized clients. 5. Fail: the share is attached to a VPC that includes unauthorized hosts, or to more VPCs than the workload needs. Using doctl or the API: List shares and inspect each share's VPCs and access points. curl -s -X GET -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" "https://api.digitalocean.com/v2/nfs" curl -s -X GET -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" "https://api.digitalocean.com/v2/nfs/" Pass: each share's attached VPCs (vpc\_ids) and access points map only to networks hosting authorized clients. Fail: a share is attached to a VPC containing unauthorized hosts, or to unnecessary networks. ### Implementation Steps Using the DigitalOcean Control Panel: 1. Open Network File Storage at cloud.digitalocean.com and select the share. 2. Use the share's access-point controls to detach any VPC network that should not have access. 3. Attach the share only to the VPC(s) hosting authorized clients. 4. For path-level isolation, create subdirectory access points that restrict clients to specific paths (for example /projects/team-a). 5. Re-mount clients using the correct access point's mount IP. Using doctl or the API: Manage VPC attachments through access points on the share (creating an access point is easiest in the Control Panel; the API exposes list, create, and delete on the share's access\_points collection). curl -s -X GET -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" "https://api.digitalocean.com/v2/nfs/shares//access\_points" curl -s -X DELETE -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" "https://api.digitalocean.com/v2/nfs/shares//access\_points/" ### Backout Plan: 1. To restore access for a client that was cut off, re-attach the appropriate VPC or re-create the access point for that network. 2. Re-mount the client using the restored access point's mount IP. ## References: 1. [Network File Storage overview](https://docs.digitalocean.com/products/nfs/) 2. [Network File Storage features (VPC-based access)](https://docs.digitalocean.com/products/nfs/details/features/) 3. [How to Create a Network File Storage Share](https://docs.digitalocean.com/products/nfs/how-to/create/) 4. [Network File Storage API reference](https://docs.digitalocean.com/reference/api/reference/nfs/) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.