Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a large ASP.NET application running on Windows 2003 web server. Parts of the system serve up static files (pdfs, csv, excel, etc) that contain sensitive data. The files are created by certain processes in the system, are uploaded by users and administrators, and are obtained by some integrations with other systems.

Where is the best (most secure, practical) place to store these file. I have been storing them outside of IIS and using .NET code to serve up the file when needed. This has been working fairly well but users have posed concerns about security of these sensitive files, since they are stored on a web server.

It has been suggested to store them in the database, but I would rather not do that.

Any ideas out there? Thanks!

share|improve this question

4 Answers 4

up vote 0 down vote accepted

The more appropriate question is, "How much overhead are you willing to take"

By offloading the files to a separate machine on the same network (I'll assume Gbps network), You incur a cost of about 1/2 a microsecond for every transaction (Once again, I'm making assumptions here about Disk cache and file size, but I think its a reasonable assumption). This provides only marginally better security. By offloading with AES with 128 bit block ciphering, You can expect each transaction to hover around 2-3 microseconds). Offloading with AES-128 + Authentication through ASP sessions, You can reasonably expect it to get up in the 20-30 microsecond range (per file).

share|improve this answer
    
I don't think that is unreasonable at all, considering the only time these transactions happen would be on upload, on view, and perhaps during a scheduled batch process. –  Mike Cole Jun 21 '10 at 20:29

As long as the directory where they are stored is locked down so that only the application and valid users can access it then they should be as secure as they can be. You could move them to another server that the web server can see, but isn't public facing itself.

The files are going to be ultimately served over the network so they have to be readable by someone/something.

Are you serving these files via https?

share|improve this answer
    
I'll have to check if the site requires https, but I fear not. I'll have to add that to the development queue. –  Mike Cole Jun 21 '10 at 19:23

but users have posed concerns about security of these sensitive files, since they are stored on a web server.

Well, duh. They want to upload and retrieve them via the web. They're going to be on a web server, for at least some point in the process. Some questions - who are the users? Are they customers? If so, how much knowledge of your architecture do they have, and should they have? Are you (if in the US) under PCI or HIPAA requirements, or some other sort of regulation? If so, then you should have an audit performed, and share the pass/fail results with the customers, rather than have them nitpicking your design.

share|improve this answer
    
The users are the customers who are also employees of my company, so we're all on the same team. –  Mike Cole Jun 21 '10 at 20:24

I know you stated not putting them in a database, but I'm an advocate for this where appropriate and I'm thinking here it is. Any way you store files you are going to be taking on some amount of overhead, it’s just how much your will to take is the issue. By storing files in the database you can further limit who can see them by completely removing them from the file system. Under the right control and programming you can limit the files to have access by only your application, thus eliminating the need for another server and tons of file system security changes not to mention an additional backup plan for that additional “secure” server.

Another added benefit of storing them like this is you can encrypt them and store them, as well as have a simplified backup plan.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.