Server Auditing
With SQL Compliance Manager
Configuring SQL Compliance Manager
Welcome to our gear virtual education. And this video, we're going to talk about server level audit, configuration, and SQL compliance manager. There's different layers of auditing that you can implement within compliance manager.
Server Auditing
When we talk about server level auditing, if you right, click on the instance and drill down to the properties, the second tab from the left, you'll see a list of different types of audit events that are available. Things like log-in, log-out failed, login security, change, administrative actions, DDL, and user-defined events.
Now it is important to understand that these are server level events, meaning that, you know, if I created a store procedure in a database, this is not going to identify that this would be more directed towards DDL from an instance perspective, such as creating a database, dropping a database, you know, or security changes, creating a, you know, a server level log in versus a permission at a table level. For example, that being said, there's two other options that you have at the server level that can carry down to the database.
Privileged User
For example, privileged user auditing is, is a way that I can set at list of logins, be that either a role, a server role and or a server login that I basically am elevating to a higher standard of auditing.
A good example would be something like a DBA group, right? So I have a group, an 80 group in my environment called SQL DBA when I hit add, hit, okay. They are now listed as privileged users. And down below, we're going to talk about basically what we want to audit in relation to these privileged users. So the idea here is that these should be generally speaking people and people who probably aren't doing a ton of activity, right? This is a production server. The database base administrators may be logging in and making some changes, you know, from time to time. But most of the activity on the SQL server has not related to privileged users, it's other application accounts and things like that. But I do need to see what they're doing now down below.
You'll see that I'm auditing basically everything that they do when they log in, they log out and failed logins, security, administrative, DDL, DML, and select. Now one other little side note is you'll notice security, DDL felt login is great out. And the reason is I'm doing that already for the server. Therefore it's pushed down to the privileged users.
Trusted User
In contrast to privileged users. There's another option that you have, which is called trusted users. Now, trusted users are a way for you to omit auditing. So any log in or role added as a trusted user will not be audited and the main purpose, or I think the primary use case for this particular feature is to give you an easy and a quick way to eliminate a lot of noise or a lot of audit events that are really irrelevant to your specific controls, right?
Application Audit
So you may have application service accounts or, you know, maintenance accounts, things like that aren't typically people, but are more service level accounts that you do trust. An example might be the application has very good self auditing. Therefore we're not trying to track what the application is doing per se. We're trying to figure out for example, what the privileged users are doing, just like a privileged user trustees, or it could be a role or, and a login. So you have the same kind of pick lists available for who are the trusted users. But generally speaking, the idea is that I am going to do some higher level audits for all users across the board on the audit event tab. And then I'm going to expand out that auditing footprint generally for the privileged users and then help minimize noisy or irrelevant events with trusted users.
Conclusion
So that is the core functionality around server level audit, configuration, and SQL compliance manager. Thank you for your time.