March 12, 2018 at 11:45 am
shamshad.ali - Monday, March 12, 2018 11:29 AMSue_H - Monday, March 12, 2018 11:24 AMI think the harder part is that your company has you started in the wrong direction. You can't restrict sysadmin as already mentioned - sysadmin by passes security checks so it wouldn't work. You need to find out what access they would need for whatever the tasks they are going to perform and go from there.
Sue
Well the management is no technical, they want to secure their owns, that is good but the security guards after all you need to trust or do protect yourself and get trained.:laugh:
At the end of the day there are some tasks that require sysadmin in SQL server and depending on the role of the person sys admin on the server as well. If the person in question has to perform those tasks then you will have to look at other ways to keep them from seeing sensitive data.
March 12, 2018 at 11:59 am
shamshad.ali - Monday, March 12, 2018 11:29 AMSue_H - Monday, March 12, 2018 11:24 AMI think the harder part is that your company has you started in the wrong direction. You can't restrict sysadmin as already mentioned - sysadmin by passes security checks so it wouldn't work. You need to find out what access they would need for whatever the tasks they are going to perform and go from there.
Sue
Well the management is no technical, they want to secure their owns, that is good but the security guards after all you need to trust or do protect yourself and get trained.:laugh:
That's often the case even if it's not too fun to deal with.
Being that you said earlier that they can't be db_owner as they wouldn't be able to do some sysadmin tasks, this seems to be more than a sensitive data issue. And you also have some idea of what these tasks are. So now you can educate the management and explain that sysadmin bypasses security checks.
And then work with them on what tasks they need to be able to do. Sometimes its our responsibility to educate those asking us to do things that make no sense or aren't realistic. And if they want to limit anyone who is a DBA, it means they want to do all on-calls, code promotions, off hours patching, etc. Let it happen - it won't last and gives you an opportunity to sleep through the night while they figure it out. 🙂 Seriously though, that does work at times - let them limit everyone other than themselves if they want. Hopefully you won't have an audit during that time. Permissions should be based on roles not titles.
Sue
March 12, 2018 at 1:45 pm
Sue_H - Monday, March 12, 2018 11:59 AMshamshad.ali - Monday, March 12, 2018 11:29 AMSue_H - Monday, March 12, 2018 11:24 AMI think the harder part is that your company has you started in the wrong direction. You can't restrict sysadmin as already mentioned - sysadmin by passes security checks so it wouldn't work. You need to find out what access they would need for whatever the tasks they are going to perform and go from there.
Sue
Well the management is no technical, they want to secure their owns, that is good but the security guards after all you need to trust or do protect yourself and get trained.:laugh:
That's often the case even if it's not too fun to deal with.
Being that you said earlier that they can't be db_owner as they wouldn't be able to do some sysadmin tasks, this seems to be more than a sensitive data issue. And you also have some idea of what these tasks are. So now you can educate the management and explain that sysadmin bypasses security checks.
And then work with them on what tasks they need to be able to do. Sometimes its our responsibility to educate those asking us to do things that make no sense or aren't realistic. And if they want to limit anyone who is a DBA, it means they want to do all on-calls, code promotions, off hours patching, etc. Let it happen - it won't last and gives you an opportunity to sleep through the night while they figure it out. 🙂 Seriously though, that does work at times - let them limit everyone other than themselves if they want. Hopefully you won't have an audit during that time. Permissions should be based on roles not titles.Sue
Great !!! Sue, I agree with your suggest but do not try to educate at-least, its not part of my job. I can say yes OR no, that should be enough it they try to understand, sometimes people think there must be a provision which i don't know due to lack of information. That's why I posted here to get it verified and written somewhere in memories for future.
March 12, 2018 at 3:26 pm
shamshad.ali - Monday, March 12, 2018 1:45 PMSue_H - Monday, March 12, 2018 11:59 AMshamshad.ali - Monday, March 12, 2018 11:29 AMSue_H - Monday, March 12, 2018 11:24 AMI think the harder part is that your company has you started in the wrong direction. You can't restrict sysadmin as already mentioned - sysadmin by passes security checks so it wouldn't work. You need to find out what access they would need for whatever the tasks they are going to perform and go from there.
Sue
Well the management is no technical, they want to secure their owns, that is good but the security guards after all you need to trust or do protect yourself and get trained.:laugh:
That's often the case even if it's not too fun to deal with.
Being that you said earlier that they can't be db_owner as they wouldn't be able to do some sysadmin tasks, this seems to be more than a sensitive data issue. And you also have some idea of what these tasks are. So now you can educate the management and explain that sysadmin bypasses security checks.
And then work with them on what tasks they need to be able to do. Sometimes its our responsibility to educate those asking us to do things that make no sense or aren't realistic. And if they want to limit anyone who is a DBA, it means they want to do all on-calls, code promotions, off hours patching, etc. Let it happen - it won't last and gives you an opportunity to sleep through the night while they figure it out. 🙂 Seriously though, that does work at times - let them limit everyone other than themselves if they want. Hopefully you won't have an audit during that time. Permissions should be based on roles not titles.Sue
Great !!! Sue, I agree with your suggest but do not try to educate at-least, its not part of my job. I can say yes OR no, that should be enough it they try to understand, sometimes people think there must be a provision which i don't know due to lack of information. That's why I posted here to get it verified and written somewhere in memories for future.
It would be nice but realistically we are hired to be the "subject matter experts" for SQL Server. As such, we really do have a responsibility to explain things to others, especially our bosses. It doesn't mean they will follow it or follow our recommendations but we do need to at least tell others the consequences or ramifications of decisions or how things work. They can do whatever they want with the information but we still need to tell them what we know. And usually it's best to do those in email or get the general conversation in an email somehow. Not explaining what you know or withholding information can be seen as being dishonest
And there will definitely be times when you are not given all of the information needed so it's best to state things in a way that will take that into considerations. Things like "In general you would want to do <xyz> but it can vary based on different factors". Or "Based on the information I have on this so far I would recommend <xyz> but there could be other things I don't know about that affect that". Avoid words like always, every time, never, etc. There generally aren't too many absolutes like that in the database world and there are exceptions to a lot of things.
You can look some of the things up and find the documentation and simply provide that as well. Send the link to the documentation - then it's in email. In the process, you will often learn more even if its something you know real well so you can often benefit too from doing that.
Sue
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply