One standard I have been tasked to bring my databases up to asks me to separate security functionality and non-security functionality. Based on supplemental reading, this seems to be talking about hardware, software, and firmware dealing with encryption, authentication, authorizations and auditing.

Pursuant to this goal, and just as a general question to you experienced people, is it acceptable for a DBA to also be acting as a Security Administrator? Separation of duties would seem to say no, as DBA work, while administrative and highly privileged in nature, is mostly not security-related in nature. But if it would be prohibitive to hire someone as a DBA and another as a security administrator, what would be the largest areas of concern, if any, if one person performed both of these sets of duties?

ETA: I can't give many details to the best of my understanding of my restrictions, but security concerns are high, budget is tight, and the databases range from small, non-application databases with few users to users in the thousands with an expansive number of tables, each with an expansive number of rows of information. DBAs are utilizing the DBA role, so the most expansive set of privileges. And it looks like I accidentally removed the oracle tag, so I'll put that back on and mention that this is an Oracle database.

For the sake of discussion, let's focus on the largest subset of databases. These have personal and financial information in them. I think I can say that we are shooting for a standard that heavily leans on the NIST database standard, but isn't NIST for whatever reason. Not sure if that helps at all.

  • 3
    This highly depends on what industry your are involved with, the budget you have to work with, what country(ies) you're in, and what controls you currently restrict yourself to. I don't know if there'll be a good answer to your question in it's current form. If you can elaborate on some of the restrictions/regulations/etc. you have to work within, it may be feasible to provide a good answer for your use-case. Commented Jul 3, 2017 at 15:18
  • Ah, I see; I didn't realize the answer was so dependent on environment. I'll update the OQ. Commented Jul 3, 2017 at 19:33
  • 1
    This certainly isn't all inclusive, but a good starting point for Oracle Database security is DBSAT (Database Security Assessment Tool): You can download the tool from MOS Doc ID 2138254.1. DBSAT was released at the same time as Oracle Database 12.2, but it is backward compatible all the way back to 10.2. Commented Jul 5, 2017 at 21:19

4 Answers 4


If this action is tied to a particular compliance area (Sarbanes-Oxley, or (as mentioned elsewhere) HIPAA, PCI, etc.), and someone's helping your company work to a compliance goal, pursue this with them.

As important as separation of duties is, in smaller companies/divisions it may not always be possible. Whoever is tracking what you do or don't have to do should be able to identify if you absolutely need to separate these duties, or if you can get an exception.


I have functioned as all the roles in the past. Small place, one server, 3 databases and I was the only IT. So I did it all; DBA, cabling, hardware, software, programming. It should be separated out, but if you don't have the manpower or the money, then combined roles is the only way to cover them all.

  • So you administered yourself for your own practices regarding security? I wonder how the constructive criticism from those audits looked like. Commented Jul 3, 2017 at 19:30
  • 2
    Never had one. It was a small company engaged in a private business. I was the entire IT department. I did it all. It was what it was. I no longer work there, my boss was insane.
    – DCook
    Commented Jul 3, 2017 at 19:42
  • 1
    In many ways, I've been there. I spent over a decade working in the automotive sector for a small company. That doesn't mean that I was a "security administrator", electrical engineer, network engineer, ux designer, and chief sales guy. It means I did what was needed to be done, and it worked well enough to not fail. I build stuff that works reasonably well and I wear lots of hats well enough to succeed. Commented Jul 3, 2017 at 19:56

In IT, we are all called to think as security admins. That said, if your company HAS a dedicated security resource, you lean on that person for guidelines and requirements. If not, then it really depends on a ton of factors:

  • Do you have really sensitive information? (HR information, HIPPA information, Credit Card/payment processing information.)
  • Depending on the above, different methods of encryption and security should be looked at.

Stick to the Principle of Least Privilege as best you can... Granting the minimum security required to do one's job. This seems to cover most bases for small/medium companies that don't have industry regulations dictating security standards.


Warning tremendously unpopular red-pill opinion. The truth hurts.

If someone comes up to me and gives me such a title, I am going to grill them uncomfortably. My first kind of question is what kind of threat are you securing your users against, and on what skill sets and abilities do you think you're qualified to do that task? I agree with @Wes, that everyone should "think as security", but for the term to have any meaning it should not apply to everyone. It sounds kind of pretentious to start with but when I think of people using those terms, you better be at Defcon and employed with Mitnic. You should not be substantiating that claim with the CompTIA de jour. What was the last book, tailored to the topic of security, that you read?

I think most IT roles are highly oriented to the merits of the target user. If you can't build it, you can't secure it. That leads me to dismiss Microsoft DBA's in this capacity and end-users of proprietary software. How are you going to claim any level of security expertise outside of the domain of creation? Do you have skills reverse engineering proprietary code? To state it another way, Microsoft may have guidelines that they don't currently follow in their point-and-click install of SQL Server. In so far as the end-user can follow those suggestions, that's some degree of security. But let's be honest here: it's not much.

  • 2
    I think there is a missing distinction. Should DBAs perform some security functions; be aware of security concerns; take some responsibility for security? Absolutely. Should they be given a "Security Administrator" title as though they are the last word in security and fully expert? Absolutely not.
    – Wildcard
    Commented Jul 3, 2017 at 22:09
  • @Wildcard I agree fully with that distinction. You're not your own security administrator in any useful sense of the word. Commented Jul 3, 2017 at 22:34
  • Yes. I upvoted your answer as I think I got the underlying point; perhaps the downvoters read into it that DBAs should never be responsible for security? Hence my comment above. (If I'm mistaken, I've no idea why else this might have been downvoted.)
    – Wildcard
    Commented Jul 3, 2017 at 22:56
  • 2
    @Wildcard I suppose some of the downvotes are due to the unsubstantiated claim that users proprietary software are by definition incapable of securing systems
    – Tom V
    Commented Jul 4, 2017 at 7:02
  • 2
    I agree with that up to some point, but exploits have been available for all systems. Remember the openssl heartbleed issue? The code was open for anybody to see and people still thought they were securing their systems using it.
    – Tom V
    Commented Jul 4, 2017 at 17:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.