|
I am interested in the disk sandboxing feature of v16. As an alternative to storing documents in the database as blobs (the default for our products) we have a mechanism where access is still controlled by the database server (ie no direct client access) but the blob contents are stored in a file structure. This works pretty well, with performance pretty much the same as in-database storage. One downside is of course that the files have to be mirrored to stand-by servers and backed-up separately, but this can be done easily by some SAN systems. I thought that the sandbox facility would be a good additional security feature, but things are complicated by the fact that the the sandbox has to be "the directory where the main database file is located and any subdirectories of this directory". In our scenario we would ideally want to use different storage areas for the document files - often many times the database size and not needing to be on such expensive disk hardware (eg good RAID 1 rather than super-dooper RAID 10). I thought about experimenting with virtual folders eg mklink /D d:\DatabaseFolder\DocStructure v:\DocStructure but I don't know how solid that would be. While not a show stopper, I wonder if the ability to define alternative / additional disk sandboxes could be considered for future versions? Subsequent thought - perhaps I'm looking at this the wrong way? Is sandboxing really just a short cut to running the db service under a user that has certain restricted disk privileges. Should I be considering that route instead? |
|
Justin: While we were developing the disk sandboxing feature we (the development team) had talked about all of these ideas that you have mentioned (and a few more). Our decision for the first release of the feature was to keep it simple and then see if the feature got any traction in our customer base.... so thanks for raising the question: it means that there is at least one user (you) that is interested! :-) Your thought process is similar to ours: you can use links within the directory (that is containing the database system db) to other directories (on other drives) and thus provide a method to put files virtually anywhere. The stability of this configuration will only be as good as the stability of the alternate/remote file system. (On a personal note: I have use such a configuration on many of my systems have have not seen any issues). Use of disk sandboxing should not (necessarily) be used as a replacement for other common security practices (such as running your server as a user with restricted permissions). The main intention of the feature is to isolate each database running on a server (where there can be hundreds of databases running on the same server) from each other so that there is no possible data 'leakage' between databases. I.e. multi-tenancy configurations! Enhancements to the disk sandboxing feature are in the backlog queue but it is unknown at this time when such enhancements will make it into the product. HTH 1
Thanks Mark - that is really useful. When talking about user permissions I was of course missing the point about multiple databases under the same engine instance.
(15 Jan '14, 11:02)
Justin Willey
|
Though I have no current need for such a feature, I could also think that it would make sense to have a separate directory (independent from the database directory) as sandbox - just to make sure file I/O could not escape that "jail". I could imagine that would make particular sense when one is hosting databases for different customers and want to make sure each customer would have its own (separate) directory structure for external files and could not access those of other customers.