Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The problem is that if someone already has full access to the database then it's just a matter of time before they link up the records to particular people. Somewhere in your database (or in the application itself) you will have to make the relation between the user and the items. If someone has full access, then they will have access to that mechanism.</p> <p>There is absolutely no way of preventing this.</p> <p>The reality is that by having full access we are in a position of trust. This means that the company managers have to trust that even though you can see the data, you will not act in any way on it. This is where little things like ethics come into play.</p> <p>Now, that said, a lot of companies separate the development and production staff. The purpose is to remove Development from having direct contact with live (ie:real) data. This has a number of advantages with security and data reliability being at the top of the heap.</p> <p>The only real drawback is that <em>some</em> developers believe they can't troubleshoot a problem without production access. However, this is simply not true.</p> <p>Production staff then would be the only ones with access to the live servers. They will typically be vetted to a larger degree (criminal history and other background checks) that is commiserate with the type of data you have to protect.</p> <p>The point of all this is that this is a personnel problem; and not one that can truly be solved with technical means. </p> <hr> <p><strong>UPDATE</strong></p> <p>Others here seem to be missing a very important and vital piece of the puzzle. Namely, that the data is being entered into the system for a reason. That reason is almost universally so that it can be shared. In the case of an expense report, that data is entered so that accounting can know who to pay back.</p> <p>Which means that the system, at some level, will have to match users and items without the data entry person (ie: a salesperson) being logged in.</p> <p>And because that data has to be tied together without all parties involved standing there to type in a security code to "release" the data, then a DBA will absolutely be able to review the query logs to figure out who is who. And very easily I might add regardless of how many hash marks you want to throw into it. Triple DES won't save you either.</p> <p>At the end of the day all you've done is make development harder with absolutely zero security benefit. I can't emphasize this enough: the only way to hide data from a dba would be for either 1. that data to <strong>only</strong> be accessible by the very person who entered it or 2. for it to not exist in the first place.</p> <p>Regarding option 1, if the only person who can ever access it is the person who entered it.. well, there is no point for it to be in a corporate database.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow to separate a person's identity from his personal data?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USNotMe
    1. USNotMe
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POHow to separate a person's identity from his personal data?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTDownMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COThat's what I've thought also... but it's a small startup with only two developers and not much more.
      singulars
      1. PO
      1. USRene Saarsoo
    2. CO@Chris - DB access is not the same as full access. This info can be hidden from DB admins, but someone with root or physical access to the web server could probably still get it. The Q is about protecting the data from those with database access; I think it's completely feasible. Please see my response, I hope it might change your mind.
      singulars
      1. PO
      1. USDagg Nabbit
    3. COI don't think that I can't troubleshoot without access to production systems, but I do think I can do it significantly faster. Problems that I could locate in minutes could require hours or days trading emails with the DBAs.
      singulars
      1. PO
      1. USmikerobi
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload