This is a good question and we tend to see this requirement quite often. Traditionally you would want to separate any Internet-facing systems and supporting components into their own dedicated space (i.e. separate from internal systems).
Expanding on this initial thought to ensure the best possible level of security with a DMZ Web server setup, consider hosting the NAS device on its own dedicated network segment. Should the Web server ever be compromised, collateral damage will be kept to a minimum. By collateral damage, I mean mitigating the risk of the attacker getting to the NAS box and, in turn, the rest of the network. This will also allow you to set up tactical choke points to monitor for malicious activity. An example of such a deployment would be to set up an inline Web application firewall (WAF) or intrusion prevention system (IPS) to protect the downstream link (i.e. on the DMZ interface link).
From a networking perspective, I would enforce the appropriate inbound access control lists (ACLs) to be as restrictive as possible to the NAS from the DMZ server. For example, leverage built-in firewall security restrictions, which prevent traffic from an untrusted interface (e.g. Internet/DMZ) from flowing to a trusted interface (e.g. internal). In addition, access to the Internet-facing DMZ should be restricted to the appropriate application ports (typically TCP port 80 and TCP port 443). Consider enforcing a restrictive outbound ACL to control traffic from the internal network to the DMZ.
All other traditional server-hardening rules apply, especially on the DMZ swing. If you are primarily dealing with static content on the NAS, consider some form of a file integrity-monitoring system. Tripwire Inc. offers a commercial product, and the AIDE open source tool can be found on SourceForge.
This was first published in June 2010