Data Redaction Done Oracle-Style





  • The redaction features in 12c are designed to automatically protect sensitive database material by either totally obscuring column data or partially masking it – for example, recalling just the last four digits of a US social security number when a search query is run.

    I'm no SQL expert, but isn't that basically a view?



  • Yes, you could indeed do that in a view.


  • BINNED

    @anonymous234 said:

    I'm no SQL expert, but isn't that basically a view?

    How dare you describe such advanced functionality in such simplistic terms? Don't you know that all things that cost money have to sound and be devilishly complex?

    Views. Pish. MySQL has views. You cannot compare the awesome that is Oracle with something as elementary as MySQL. It's "redaction features"!



  • Views are more powerful than redaction ;)



  • I dunno. I'm a little bit with Oracle on this one.

    This isn't a "oh man you can count on this to secure EVERYTHING" feature. This is more a "DBAs don't need to see how much other people get paid while debugging a query" feature. In the latter case, security is not very important... you gotta trust the DBAs at some point anyway.



  • I think it's just Oracle marketing it as this big new feature that is supposed to be security.

    In fact it's part of their "Oracle Advanced Security"

    It's like they decided to bring the TSA to Oracle.



  • @blakeyrat said:

    "DBAs don't need to see how much other people get paid while debugging a query"

    Except when they do, because the query crashes for seemingly random records, and you have to figure out somehow that it happens when two people have the same salary.

    I'm not sure about Oracle, but I've run into it with MS SQL - it blows up when you treat an inner query result set as a single datum (eg. comparing it with something), and it suddenly returns more than one row.



  • Look, I'm not fucking saying it's a magical balm that solves all DB problems ever in the history of ever.

    For the fucking 99.9999989909099098989875934734769347534785349% of cases where identical salary amounts aren't the problem, this is a non-issue.

    Christ.



  • Trying to hide data from DBAs is like trying to hide applications from a user with root privilege. You may succeed in the short term, but said users likely have god-mode, they will either:

    1. Fuck shit up beyond recognition trying to do regular maintenance because they are in god-mode
    2. Accidentally fuck shit up because they are in god-mode.

    Really Oracle Data Redaction should be called Oracle Transparent Data Redaction. Legacy systems should benefit because the data is 'auto-magically masked' and new systems...well if they don't know what views are or how to use them well shit. Game over revert all your passwords to SCOTT/TIGER, bad guys win.



  • @MathNerdCNU said:

    Trying to hide data from DBAs is like trying to hide applications from a user with root privilege. You may succeed in the short term, but said users likely have god-mode, they will either:

    That's not the fucking point at all.

    Obviously the DBAs can still get the data if they really want to. Duh. That doesn't even need to be said. Well I guess it does now, with this new forum full of idiots.

    The point is if I'm a DBA I don't want to see the data myself. That's because I'm trustworthy and good at my job. I can use this feature to make that possible.

    It's not a security measure. It's a "damnit, I didn't really want to see that" feature.



  • Now I see why people say you don't read posts/believe aliens whisper in your ear, because you FUCKING DONT.The point of this worthless feature is "hurr-durr-the-dumb-asses-cant-see-sensitivie things" even though they can/DBAs generally have god-mode.

    They can fuck shit up. Again, trying to hide data from them is like trying to prevent "Junior Mc-Butt-Pluggs from shoving crap into-his-anal-cavaity" Futile at best.

    I agree with the notion/concept/general principle of minimal privilege, but masking data "aint gunna cut it alone" in the 21ST FUCKING CENTURY



  • @MathNerdCNU said:

    The point of this worthless feature is "hurr-durr-the-dumb-asses-cant-see-sensitivie things" even though they can/DBAs generally have god-mode.

    No. The point is they don't see it, not they can't see it.

    That has nothing to do with whether or not DBAs have "God-mode". This has nothing to do with whether DBAs can "fuck shit up."

    Look, if a DBA wants to fuck with a database, sure, of course they can. Duh. This feature is not for that DBA. It's not for him.

    But most DBAs, the huge majority of them, want to do their jobs while also preventing themselves from seeing sensitive information. This feature is perfect for them. This is who it's for. Back when I adminned an email server, if I could have set a flag or something to prevent myself from seeing the content of other people's emails, I definitely would have-- it sounds like a great idea.

    @MathNerdCNU said:

    aint gunna cut it alone

    Then practice defense-in-depth. Duh.

    @MathNerdCNU said:

    in the 21ST FUCKING CENTURY

    How is the year relevant?



  • @blakeyrat said:

    It's not a security measure. It's a "damnit, I didn't really want to see that" feature.

    Oracle: the best database for storing nude pictures of Richard Stallman.


  • :belt_onion:

    @Maciejasjmj said:

    I'm not sure about Oracle, but I've run into it with MS SQL - it blows up when you treat an inner query result set as a single datum (eg. comparing it with something), and it suddenly returns more than one row.

    In Oracle you can get even an better error for the reverse situation! In a certain scenario on 11g you could cause a query to return a cryptic "space leak" error if your query only returned 1 result from an inner query to a group by, in which case the single distinct salary vs multiples would truly be the cause of failure. I only ever made it happen on a single query I had written, but it was reproducible 100% of the time - adding a predicate to the inner query to cause only a single row to return would cause the db to puke.


  • :belt_onion:

    @blakeyrat said:

    The point is if I'm a DBA I don't want to see the data myself. That's because I'm trustworthy and good at my job. I can use this feature to make that possible

    If you were a DBA and didn't want to see the data, then you simply wouldn't query the data? If you needed to query it, you'd replace that column with junk in the query (which is essentially what the redaction bullshit does). Seems pretty easy.
    Why would you create a security layer that can't actually stop DBAs that don't want to be stopped, when all the ones that want to be stopped will just stop them-fucking-selves?

    This just sounds like one of those things you install so you can tell the boss upstairs, "nope, there's ZERO way I could ever see the data, honest, look at what I get back when I run these queries!!!111". Sounds more like it makes a good tool for the devious DBAs than for the ones that are actually ethical.

    edit - though I did think of one thing - if your ethical DBA doesn't actually know what the contents of a field are prior to querying, they would be saved by the redactions.
    We just secure those tables so that you can't accidentally query shit you weren't supposed to see...... I guess that's what they're trying to prevent with redaction - ever needing to know how to truly set up your database table security?



  • Actually.....the application I describe in my wtf here:
    http://what.thedailywtf.com/t/user-logins-lets-use-the-database/2160

    Would actually be a reason why this redaction feature exists. i.e. Enterprise apps that are glorified table viewers and err..the user system is the database....
    I wouldn't be surprised one bit. The usage of that particular software alone has a large install base in the manufacturing world and the application alone doesn't do any data processing since it always returns all tables columns all the time.
    At the moment I can actually company accounting and sales history and $$$ totals on a "normal" account. Perhaps I should inform them about this redaction feature?


  • Discourse touched me in a no-no place

    @ben_lubar said:

    Oracle: the best database for storing nude pictures of Richard Stallman.

    No, there's /dev/null too. But Oracle's a close second.



  • @ben_lubar said:

    Oracle: the best database for storing nude pictures of Richard Stallman.

    I'm sorry, all nude pictures of Richard Stallman are under the GPL, anything that would prevent access to them is a license violation. Please disable the data redaction feature ASAP or we will have to take legal action - EFF



  • @blakeyrat said:

    But most DBAs, the huge majority of them, want to do their jobs while also preventing themselves from seeing sensitive information. This feature is perfect for them. This is who it's for.

    Okay, so it's not "purely useless", instead it's "mostly useless". It's like having a SQL detection subsystem that just prompts you with a "Are you sure?" dialog. It has naught to do with security, it's easily replaceable with just querying a view instead, or not querying the data in the first place, or even gluing a piece of cardboard to your monitor over the sensitive column.

    The point is, it's hardly even a marketable feature, even if there's one use case in which it would be very slightly more convenient.



  • @darkmatter said:

    If you were a DBA and didn't want to see the data, then you simply wouldn't query the data?

    They wouldn't unless they have to. Duh. Not sure what point you're building at here...

    @darkmatter said:

    If you needed to query it, you'd replace that column with junk in the query

    Oh so you're saying they could... redact the data in some way, hmm...

    @darkmatter said:

    (which is essentially what the redaction bullshit does). Seems pretty easy.

    Oh so you're saying they'd use this redaction feature we've been talking about.

    THEN WHY THE FUCK ARE WE STILL TALKING IF YOU AGREE WITH IT!

    @darkmatter said:

    Why would you create a security layer that can't actually stop DBAs that don't want to be stopped, when all the ones that want to be stopped will just stop them-fucking-selves?

    I don't think it's even billed as a security feature. Is it? I don't read Oracle marketing.

    @darkmatter said:

    This just sounds like one of those things you install so you can tell the boss upstairs, "nope, there's ZERO way I could ever see the data, honest, look at what I get back when I run these queries!!!111". Sounds more like it makes a good tool for the devious DBAs than for the ones that are actually ethical.

    Well a tool's a tool. The usage is up to the chimp behind the keyboard.

    My point through all of this is this isn't a "useless" tool, even if it can be easily "cracked". As long as cracking it can't be done accidentally.

    @darkmatter said:

    We just secure those tables so that you can't accidentally query shit you weren't supposed to see...... I guess that's what they're trying to prevent with redaction - ever needing to know how to truly set up your database table security?

    Well your company is your company. I work in a company that has to follow HIPAA rules, and this is pretty fucking important to us.



  • @Maciejasjmj said:

    It has naught to do with security, it's easily replaceable with just querying a view instead, or not querying the data in the first place, or even gluing a piece of cardboard to your monitor over the sensitive column.

    Right.

    And like I said before, I don't even think it's billed as a security feature. I'm 99% sure it isn't.

    @Maciejasjmj said:

    The point is, it's hardly even a marketable feature, even if there's one use case in which it would be very slightly more convenient.

    Oracle sells to a lot of healthcare and government clients who have pretty onerous privacy rules. Maybe it's not useful to you, but that doesn't make it useless to everybody.



  • Actually, if you look at the Oracle blog post it does seem to be billed as a security feature.



  • Yeah ok whatever. "Security" is a pretty wide net to cast. The $2.50 padlock on my garage and the $50,000,000 doors at Fort Knox are both there for "security".



  • @blakeyrat said:

    Oracle sells to a lot of healthcare and government clients who have pretty onerous privacy rules. Maybe it's not useful to you, but that doesn't make it useless to everybody.

    But this thing doesn't guarantee privacy in any way whatsoever. Whoever could look at those data still can, they just need to jump through a minor hoop. So how would that help enforce a privacy rule (which I suppose is of form "user X shouldn't have access to data Y")?

    It prevents you from seeing those data accidentally - sure, but that can be achieved using existing measures already.



  • @blakeyrat said:

    The $2.50 padlock on my garage and the $50,000,000 doors at Fort Knox are both there for "security".

    I'm surprised they don't get more doors stolen.



  • @Maciejasjmj said:

    But this thing doesn't guarantee privacy in any way whatsoever.

    Look, if you don't get it by now, I really have no idea how else to explain it. I'm done trying.


  • :belt_onion:

    @blakeyrat said:

    And like I said before, I don't even think it's billed as a security feature. I'm 99% sure it isn't.

    If it's not a security feature then what is the point.


  • :belt_onion:

    @blakeyrat said:

    THEN WHY THE FUCK ARE WE STILL TALKING IF YOU AGREE WITH IT!

    I agree with not looking at data you're not supposed to see, I disagree with Oracle claiming some feature will automagically secure all your data when it clearly can't, doesn't, and won't.


  • Discourse touched me in a no-no place

    @Arantor said:

    Actually, if you look at the Oracle blog post it does seem to be billed as a security feature.

    It doesn't 'seem,' it is. It's there in the first clause of the first sentence.

    New to Oracle Advanced Security, Data Redaction provides selective, on-the-fly redaction of sensitive data in SQL query results prior to application display so that unauthorized users cannot view the sensitive data.

    And the 'unauthorized users' bit would seem to preclude any arguments relating to DBAs' access to the data.


  • I survived the hour long Uno hand

    @blakeyrat said:

    And like I said before, I don't even think it's billed as a security feature. I'm 99% sure it isn't.

    @blakeyrat said:

    Yeah ok whatever. "Security" is a pretty wide net to cast

    So basically what you're saying is:

    "It's NOT A SECURITY FEATURE GUYS, JEE-- wait, what, it is? WELL SECURITY IS MEANINGLESS, GUYS, JEEZE."


  • ♿ (Parody)

    Seems like this would be a way to prevent worst case scenarios when lazy devs show stuff they really shouldn't have. Because people get lazy all the time and forget to make sure stuff is only showing to authorized users. So...sort of a defense in depth, at least until the devs start doing whatever it is that they need to do to show the real data all the time.



  • Yeah, my argument is relying on a subtle distinction that apparently most people on this forum just can't cram into their brain.


  • ♿ (Parody)

    Also, these people have probably never talked to end users about new requirements. My first reaction (usually supressed) in such a conversation is something along the lines of, "Why the fuck would anyone want to do that‽"



  • It's a case of Slashdot-itis. Where the instant anything new is mentioned, every comment is along the lines of:

    • But you don't need X, you can just combine A, B, C, D and then E but it won't work so substitute F if you need voicemail unless you're in Germany in which case I guess you do need X, but still this is so unnecessary!

    • Well great idea, but what about {problem the development team obviously worked out long before making an announcement}? That problem is obvious, I can't believe they didn't solve it!

    Because what's more likely: that the development team didn't solve the obvious problem, or that they did and the 100-word blurb just didn't happen to mention it? Occam's Razor people!

    • This is a good idea, but while it solves 99.9% of the problem-space, it's obviously completely useless entirely.

    You hear that Ford? Your sedans can't climb Mount Everest, so according to this argument, there's no point in building sedans... they don't solve 100% of the "travel" problem-space.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    the 100-word blurb just didn't happen to mention it?

    Often the original documentation mentioned it, but one of the re-aggregators of re-aggregators chopped it off to “make it snappier” or in order to grind some political axe. On the other hand, most of the more direct submissions to /. seem to be just utterly unreadable dreck; the firehose is a truly dispiriting experience and you end up realising that the editors really do pick the best submissions by far.


Log in to reply