Home / server / Questions / 153310
Accepted
Mike Cole
Asked: 2010-06-22 11:00:27 +0800 CST

Where to store sensitive files served up in ASP.NET application

  • 772

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!

security iis web-server

4 Answers

  1. 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?

    • 0
  2. Best Answer

    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).

    • 0

  3. 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.

    • 0

  4. 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.

    • 0