Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By capoyeti on
The site administrator is all powerful, and can see all content (including uploaded files). What if this is the one problem that prevents a new site being built on Drupal?
I have built a site that has a community of members capturing personal information in CCK fields, and uploading personal documents. It has become apparent that the ability for the administrator to see this content is a major pitfall for the continued viability of the site.
Are there modules available to 'encrypt' or hide a) the content of the uploaded files, and b) the CCK fields.
I have investigated (and tried private files, bitcache, filedepot, privatenumber (for CCK fields), but cannot get around the admin being able to see the data.
Should I look at a bespoke site, and not use Drupal?
Any advice appreciated.
Chad
Comments
.
You need to look at what you are obscuring and how security through obscurity works (encryption).
If you're looking to encrypt files, then a decryption routine usually requires knowledge of a key. Where is this key stored? Does a user enter their key (or it's generated on the fly from user-entered information?) every time they want to download a file? This does not seem usable to me on any system. However, if that's the way you need to go, then you will probably need to create a new type of field that encrypts and decrypts files on upload as well as encrypt/decrypt field data on save/view. In order to decrypt, a user needs to actively send their key in order to decrypt.
On the other hand, instead of worrying about encryption at this level it would be a better and more usable solution to compartmentalize administrator privileges. I think you have more of a social problem rather than a technological one.
Does a PHP developer, Drupal site builder, etc... need access to the production server? If they do need access to the production server, what sort of access?
Regarding keys - is a
Regarding keys - is a client-side app not a possible solution for the creation and provision of keys?
Please expand on the compartmentalization of the administrator privileges - effectively, the site will be storing sensitive information that, if there was anyone else (super user, root, admin etc) that 'might' be able to view it, there would be no buy-in from a user community. Perhaps you are right about the social problem, but the social need for privacy can surely be addressed from a technological perspective?
Re access to the production server - no. Once the site is built, PHP developers or Drupal site builders will not need access. Although - with phase 2 of the project (additional functionality based on success of the V1) there will again be some access required.
thanks
Interesting stance on an administrator
I understand what you have stated. What I do not understand is why you feel that the "administrator" or user/1 in drupal should be any different than the administrator of any other system.
The web server that you are running drupal on has a root user. That user has access to everything. All databases, all files, ALL information on that server. The same model is used on virtually all computer systems. There is always a root user or "administrator".
On the web, with user contributed content, this model is basically a necessity. There are legal issues that can stem from information put on a server by users. In the end the "owner" of the server is responsible (in a very legal way) for the information on the server. The same as the "owner" of a website is legally responsible for the information on the site. I don't know about you, but I personally would never wish to be in a position to be legally responsible for something that I have absolutely no control or authority over.
Just my 2 cents.
Responsibility
Points noted, and agreed - to an extent. Assume that you are storing sensitive personal information on a website (even if you wouldn't in real life), surely you would want that visible to you only - and wouldn't encryption (maybe required at the source - ie. client side) solve that problem?
The only possible solution
The only possible solution is client side encryption. At that point then, it doesn't matter what CMS system you use. Drupal is as good (or bad) as any because the users have to encrypt their own data before uploading it. My point was that it matters not if you "blindfold" the drupal user 1. The server root account still has access to everything and so no matter what CMS you use, unless the clients are securing their files, their data is still accessible by someone besides them.
A problem when you are part of the community
While it is true that every computer server has an administrator, Drupal is often used by small groups where the administrator is often a member of the group using the site. While an organization might be okay with their server being administered by a disinterested third party system administrator across town, and organization may not be so keen to know that one of their own members has access to everyone else's private stuff.
This makes it hard to advocate for using Drupal internal to an organization. If there is no client-side encryption, an organization will tend to shy away from internal administration of a Drupal site and use outsourced or hosted solutions for their data instead.
Someone always holds the keys
Security through obscurity. In other words, don't tell them. Any organization that has a webserver (unless they physically own the server and pay a third party to run it, btw not a great idea), has a member with access to all the stuff on the server. period. Just because they never realized that one of their own members had access to all their dirty little secrets doesn't mean that wasn't the case.