Managing database roles with Active Directory and Heimdall Data

Thank you everybody. As uh my name is Eric Brands CTO of Heimel Data. We're going to be talking about one small aspect of our products functionality and that is how we can use our capabilities in order to automate role management and even user management on your databases. This actually supports MySQL Postgres SQL Server. Uh any variant of that including uh Aurora and Red Shift. So this allows you to link everything together and manage everything cleanly.

So the first thing we're going to open up with is a little bit of an introduction on certain security principles that this really helps to address. We're going to talk about the problem with the database administrators and how DBs effectively are causing compliance issues with many customers. We're going to talk about briefly the database integration with Active Directory that it exists as it is today. And then we're going to talk about Heimdall's solution.

So first off, let's talk about the one security principle and that is segregation of duty and this is where a lot of companies are in violation if you're a public company and you have database administrators that can directly log into the database. You are probably in violation of Sarbanes Oxley or any number of other mandates that say that you have to separate your user management realistically from your data management. So you want, we want to make sure that that compliance issue is resolved.

The second security principle we're going to look at is the principle of least privilege effectively. People should only have access to the data when they need access to the data. So if your DBA has access all the time as a super user, well, you're violating the principle of least privilege. Ok. So that's something that we help with as well.

And then finally zero trust model, I'll verify everybody all the time, etc. So I'm not going to go into all these too much detail. Uh for the simple reason that let's talk about the other aspects, but I wanted to say these are what we're trying to help you address.

No, the database super user and the danger of it. Ok. Most super users are violating all three principles. Ok? So you want that resolved? I get it. Oh, and if you are granting super users access all the time. Yeah, that's a problem.

Now, how do most databases do integration today with Active Directory? Well, if you're dealing with Postgres, it does have the ability to authenticate a user off of Active Directory, but your role management is still done on the database itself and it is not synchronized in any way with Active Directory or any other LDAP source. So that's a problem because if people are changing roles and such that role change within the organization should be honored by the database itself. But there's no integration there with MySQL. It's even worse. The only time that you get up integration is if you're using Enterprise Edition, ok? And on top of that, you have to load special modules into the driver's side on the client in order to support that, ok, most organizations don't want to have to deal with that. So in the end, the users are just completely managed on the database itself. Ok? And that means you really don't have an easy way to synchronize who has access to what data within your organization.

SQL Server is a little bit better on how it works with Active Directory and it can do role integration, but you still need to configure the user on the database itself. If someone leaves the organization and their Active Directory or they're changing things around, there's still something left on the database because the user had that the database had the user configured on it.

So, and the reality is though what people want is one place where they can configure access to their data and synchronize and manage it all across all their databases and that's where Heimdall Data is coming in.

So what we're targeting for our initial or for our current product we have something called zero touch user management. And the idea is we have a proxy, the proxy acts as the guardian. When you connect into the database, as someone authenticates into the database, we authenticate off of Active Directory with Active Directory, we then do group extraction. We can map the groups to roles on the database. And then with that done, we can create the user on the database with the roles that are appropriate for them at the moment that they log in. Then when they're done, all that can be cleaned up and it goes away. So this helps to ensure that you've got segregation of duty because now it's the management team that deals with the LDAP directory that's actually managing who has access to what it's not the database administrators anymore. Ok. On top of that, it ensures that you've got the principle of least privilege in place. There are systems that allow the Active Directory groups to be managed appropriately and through that only what someone is authorized to use is done at that point in time. Although we can make it even better than this and that's what we're doing.

We're basically announcing a release of new product for us. And that's a database portal and it really resolves everything. What it is is something that, for example, in particular super users, super users authenticate into a portal. The portal supports two factor authentication, Kerberos, all kinds of different security access methods. Once they're logged into the portal, they can request access at the level they need when they need it.

Now, how do we know what access they can even ask for? Well, that's where Active Directory comes in. You can have, let's say 10 different groups assigned to a user. Each group reflects a role of access that they may need within the portal. They can say today, I only need access to this one data set. They request it associated with that role will also be an approval chain. Someone can say yes, you, you need access to this today. You've justified your access. You can now gain access to that data set. They are then given access to the database that will set everything up so that they can connect to the database using whatever tool you want. DBBeaver Aqua Studio, any other tool they do what they need to do. Then when they're done, they can terminate the session. The access to the database is now effectively revoked and there's an audit trail that Joe had access to the database with this data set at a particular time. Ok. So you get an audit trail of who has access to what?

So when something goes wrong on the database at 3:30 PM you know who was in the system. Ok. Uh on top of that, uh uh we will be including role management and auditing functionality if the user doesn't exist on the database other audit tools aren't going to be able to know who actually has access to the data because that's within Active Directory. Ok. Our audit tools will allow you to get a global list of all the groups and users that are a member of a particular group and have access and it will generate an audit report that will say these are the 10 people who have access to this role and further this role gives access to this set of data all the way down to the column level. So if you have, you know that there's private information that's been tagged, say one column is tagged as a social security number. You can say these are the 10 people that have access to the actual social social security number in your organization. Ok? So you can then just generate that report, hand it to your auditors and you're done. Ok? Making that a lot easier.

Ok. At the same time, the database administrators no longer have to manage any of these users or roles as part of this. The uh call the role editor will allow you to tag what data is sensitive and then build the roles and edit them as appropriate. The approval chains for segregation of duty will allow you to say if someone goes in as super user, then these are the people that are required to sign off on it. There will be or there are functions for example, break a glass that can be enabled if you have an outage, a database administrator needs instant access. If you enable it, that will allow them to go in immediately in order to fix the problem. And then they can deal with the ramifications of the fact that they violated the approval chains in that instance. But it will sound alarms to make sure that people are aware that this just happened. Ok?

And then with the authentication going through a web portal, it will allow you to do things like biometric access to your database. So someone coming in as super user may have to literally you could do fingerprint or iris scan, whatever is supported within their hardware in order to authenticate in. So it will allow you to have appropriate security at the level that's needed when they go into an enhanced role.

Ok. Now how does the proxy layer work? This is just a general idea of the uh proxy diagram. This is us a acting as a gateway. Ok? And this is where the zero touch user management comes in as the user comes in, the proxy will synchronize into the database and go from there.

We do have other security features as well such as a database firewall so that you can block unknown SQL query patterns. If you have a well defined query set of patterns that are allowed for an application, we also have something called honey token detection. The idea is that you can plant data in your database that should never be queried. For example, you could have a user uh uh an employee table that has the name Adam Aardvark in it. If someone does select star on that table, they're over asking for data, they get Adam Aardvark, we flag that, we can literally strip that out so that nothing suspicious looks in the result that they got get. But because the database generated a result that contained the honey token, we can alert on that. So that allows you to really lock down and make sure that suspicious activity is detected.

Ok? And then obviously with Active Directory, you can do automate the secure access detection. We also provide uh auditing logged logs of what queries are done. Uh who, what, where, when?

Ok, any questions?