September 30, 2014 at 7:56 am
Jeff Moden (9/30/2014)
GilaMonster (9/30/2014)
Eric M Russell (9/29/2014)
Upgrading to the next release of SQL Server offers an excellent pretext for removing unneeded permissions from app developers."I'm so sorry, I know it a pain in the a$$, but under SQL Server 20xx a login can't drop/recreate objects unless we make them database owner or sysadmin. It's a new default feature intended to tighten security and prevent SQL injection attacks. Do we really want to operate under a non-standard security configuration? It's best just to leave it as is and let the DBA execute all the deployments."
Because lying to management is such a great way to get them to trust you....
+Infinity.
I'm always straight-up with management. Behind the scenes, they get the full story with all options presented along with pros and cons, and they make the final decision. But sometimes it's necessary to be economical with the truth when explaining things to users of the database.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 30, 2014 at 8:12 am
Eric M Russell (9/30/2014)
GilaMonster (9/30/2014)
Eric M Russell (9/29/2014)
Upgrading to the next release of SQL Server offers an excellent pretext for removing unneeded permissions from app developers."I'm so sorry, I know it a pain in the a$$, but under SQL Server 20xx a login can't drop/recreate objects unless we make them database owner or sysadmin. It's a new default feature intended to tighten security and prevent SQL injection attacks. Do we really want to operate under a non-standard security configuration? It's best just to leave it as is and let the DBA execute all the deployments."
Because lying to management is such a great way to get them to trust you....
OK, but is it really a lie? I believe it's just being "economical with the truth".
http://en.wikipedia.org/wiki/Lie#Types
Notice I never said that it's impossible to continue granting such privillage going forward. It's actually true (for the most recent release as well as all past releases) that a login can't drop/recreate objects unless it's a member of the SYSADMIN role or at least DBO for the database, and it's also true that granting membership in those roles to non-operational staff exposes security risks needlessly.
Gosh. being "economical with the truth" requires the same memory of who you told what to and, if such an omission is discovered, it will be just as detrimental to your reputation and credibility as if it were an outright like instead of a lie by omission.
Although a lot of other people don't abide by it, I consider absolute truth (including not being "economical with the truth") and immediate notification as part of the essential core requirements for being a DBA or a good consultant. Being able to deal with any fallout from such honesty is also an essential core requirement.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 30, 2014 at 8:47 am
Jeff Moden (9/30/2014)
Eric M Russell (9/30/2014)
GilaMonster (9/30/2014)
Eric M Russell (9/29/2014)
Upgrading to the next release of SQL Server offers an excellent pretext for removing unneeded permissions from app developers."I'm so sorry, I know it a pain in the a$$, but under SQL Server 20xx a login can't drop/recreate objects unless we make them database owner or sysadmin. It's a new default feature intended to tighten security and prevent SQL injection attacks. Do we really want to operate under a non-standard security configuration? It's best just to leave it as is and let the DBA execute all the deployments."
Because lying to management is such a great way to get them to trust you....
OK, but is it really a lie? I believe it's just being "economical with the truth".
http://en.wikipedia.org/wiki/Lie#Types
Notice I never said that it's impossible to continue granting such privillage going forward. It's actually true (for the most recent release as well as all past releases) that a login can't drop/recreate objects unless it's a member of the SYSADMIN role or at least DBO for the database, and it's also true that granting membership in those roles to non-operational staff exposes security risks needlessly.
Gosh. being "economical with the truth" requires the same memory of who you told what to and, if such an omission is discovered, it will be just as detrimental to your reputation and credibility as if it were an outright like instead of a lie by omission.
Although a lot of other people don't abide by it, I consider absolute truth (including not being "economical with the truth") and immediate notification as part of the essential core requirements for being a DBA or a good consultant. Being able to deal with any fallout from such honesty is also an essential core requirement.
First, I simply wasn't talking about misleading management or a client. A DBA or a contractor owes them the full truth and nothing but the truth at all times. I'm not going to debate that.
I'm talking about how changes in security roles should be communicated to end users of the database, which includes application developers or other types of "power users" who might have taken advantage of loose security for granted in the past. The intent is not the deceive but rather to present a simplified version of the truth that supports one's side of an argument and avoids a longer debate. Sure, the developer will probably dig around on MSDN and come back with a technical rebuttal. But db_ddladmin is still an admin role, and CREATE/ALTER/DROP permissions are just granting DBO privillages in a peacemeal fashion; they both work against the default security configuration when granted to non operational staff.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 30, 2014 at 9:10 am
A lie of omission is still a lie - just ask any parent. I'm also a firm believer in that being completely truthful with you boss is the way to build credibility and trust. Lies of any type (outright, omission, spin, politics, etc.) destroy credibility and trust. If you lie to them in small things, how can you ever be trusted with anything of consequence.
I will be judicious with levels of detail with some people, but am always willing to drill down to the level of detail they want. That's not a matter of honesty, but rather a matter of telling people what they can handle.
Bringing in the OP for a moment, people generally don't listen out of ignorance or belief that their way is better. However, people will never listen if they catch you being dishonest.
September 30, 2014 at 9:41 am
So, if a DBA removes an end user from the DBO role in the process of performing a migration to the next release of SQL Server, and then he says the following (not to management or a client... but to the end user for whom he revoked DBO membership), you guys would consider it a lie, an outright deceit?
"I'm so sorry, I know it a pain in the a$$, but under SQL Server 20xx a login can't drop/recreate objects unless we make them database owner or sysadmin. It's a new default feature intended to tighten security and prevent SQL injection attacks. Do we really want to operate under a non-standard security configuration? It's best just to leave it as is and let the DBA execute all the deployments."
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 30, 2014 at 9:42 am
Eric M Russell (9/30/2014)
The intent is not the deceive but rather to present a simplified version of the truth that supports one's side of an argument and avoids a longer debate. Sure, the developer will probably dig around on MSDN and come back with a technical rebuttal. But db_ddladmin is still an admin role, and CREATE/ALTER/DROP permissions are just granting DBO privillages in a peacemeal fashion; they both work against the default security configuration when granted to non operational staff.
I don't believe in lying to my colleagues either. That's also leading to a culture of mistrust.
If they dig around on MSDN and realise that I've been 'economical with the truth', then they're less likely to trust anything else I say. They're also more likely to lie to me, figuring that I don't trust them with the truth so they don't own me the truth.
The app devs are not enemies, they're the people that I work with who help me support the business goals.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 30, 2014 at 9:49 am
Eric M Russell (9/30/2014)
So, if a DBA removes an end user from the DBO role in the process of performing a migration to the next release of SQL Server, and then he says the following (not to management or a client... but to the end user for whom he revoked DBO membership), you guys would consider it a lie, an outright deceit?"I'm so sorry, I know it a pain in the a$$, but under SQL Server 20xx a login can't drop/recreate objects unless we make them database owner or sysadmin. It's a new default feature intended to tighten security and prevent SQL injection attacks. Do we really want to operate under a non-standard security configuration? It's best just to leave it as is and let the DBA execute all the deployments."
Yes, it's an outright attempt to deceive.
1) There's no such new default feature
2) A login most certainly can drop and recreate objects without being database owner or sysadmin.
If you're going to remove DBO rights, be upfront about why.
"Management has mandated that no member of the development team may have dbo on a production database"
"It's bad practice to have developers changing code in production without the knowledge of the DBA team, hence from now on the policy is that only DBAs have sysadmin"
"The auditors have said that unless we remove the DBO rights from the development team, we're in violation of the audit requirements and are subject to penalties of ..."
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 30, 2014 at 12:00 pm
GilaMonster (9/30/2014)
Eric M Russell (9/30/2014)
So, if a DBA removes an end user from the DBO role in the process of performing a migration to the next release of SQL Server, and then he says the following (not to management or a client... but to the end user for whom he revoked DBO membership), you guys would consider it a lie, an outright deceit?"I'm so sorry, I know it a pain in the a$$, but under SQL Server 20xx a login can't drop/recreate objects unless we make them database owner or sysadmin. It's a new default feature intended to tighten security and prevent SQL injection attacks. Do we really want to operate under a non-standard security configuration? It's best just to leave it as is and let the DBA execute all the deployments."
Yes, it's an outright attempt to deceive.
1) There's no such new default feature
2) A login most certainly can drop and recreate objects without being database owner or sysadmin.
If you're going to remove DBO rights, be upfront about why.
"Management has mandated that no member of the development team may have dbo on a production database"
"It's bad practice to have developers changing code in production without the knowledge of the DBA team, hence from now on the policy is that only DBAs have sysadmin"
"The auditors have said that unless we remove the DBO rights from the development team, we're in violation of the audit requirements and are subject to penalties of ..."
If the decision to tighten security comes from upper management or is part of an effort to comply with auditors, then those details would be part of a broader conversation with users, most probably delivered by management.
My earlier comments would be in response to a developer who asks "Why can't we just deploy our own procedures; why is it only your domain as the DBA?". While it is technically possible to grant them alter/drop/create permission, without granting them membership in DBO or admin role, it would still present other security issues, like unsafe code modifications (ex: SQL Injection), for which the DBA would not be made aware of. I'd prefer not to even acknowledge that as an option, and instead suffice it to say that the developer writes the code and deploys to development and the DBA deploys to production.
I'm sorry for steering this conversation off-topic; I was just curious about why some felt it was phrased in a way that made it dishonest. In the end, I agree with your assessment of it, Gail. I do believe it would be better to take a more straightforward approach in explaining to developers why it's a bad idea for anyone other than the DBA to deploy to production.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 6, 2014 at 6:14 am
Eric M Russell (9/30/2014)
GilaMonster (9/30/2014)
Eric M Russell (9/30/2014)
So, if a DBA removes an end user from the DBO role in the process of performing a migration to the next release of SQL Server, and then he says the following (not to management or a client... but to the end user for whom he revoked DBO membership), you guys would consider it a lie, an outright deceit?"I'm so sorry, I know it a pain in the a$$, but under SQL Server 20xx a login can't drop/recreate objects unless we make them database owner or sysadmin. It's a new default feature intended to tighten security and prevent SQL injection attacks. Do we really want to operate under a non-standard security configuration? It's best just to leave it as is and let the DBA execute all the deployments."
Yes, it's an outright attempt to deceive.
1) There's no such new default feature
2) A login most certainly can drop and recreate objects without being database owner or sysadmin.
If you're going to remove DBO rights, be upfront about why.
"Management has mandated that no member of the development team may have dbo on a production database"
"It's bad practice to have developers changing code in production without the knowledge of the DBA team, hence from now on the policy is that only DBAs have sysadmin"
"The auditors have said that unless we remove the DBO rights from the development team, we're in violation of the audit requirements and are subject to penalties of ..."
If the decision to tighten security comes from upper management or is part of an effort to comply with auditors, then those details would be part of a broader conversation with users, most probably delivered by management.
My earlier comments would be in response to a developer who asks "Why can't we just deploy our own procedures; why is it only your domain as the DBA?". While it is technically possible to grant them alter/drop/create permission, without granting them membership in DBO or admin role, it would still present other security issues, like unsafe code modifications (ex: SQL Injection), for which the DBA would not be made aware of. I'd prefer not to even acknowledge that as an option, and instead suffice it to say that the developer writes the code and deploys to development and the DBA deploys to production.
I'm sorry for steering this conversation off-topic; I was just curious about why some felt it was phrased in a way that made it dishonest. In the end, I agree with your assessment of it, Gail. I do believe it would be better to take a more straightforward approach in explaining to developers why it's a bad idea for anyone other than the DBA to deploy to production.
If I may. I think what you are trying to attain is not a "Lie of Omission" but rather "You didn't ask for that information". The example given is a direct lie. What you are going for is where there is "more to the story" but that the part given to the user is "all they need to know".
The case you seem to be looking for is the case where you are not withholding information to misrepresent, but rather because they didn't ask. A person can fairly state facts and information that answer questions posed and not volunteer additional information that is the "more to the story" without it being a lie. For example, when a small child (under age 6) asks where babies come from, most people don't give them the 411 on interpersonal relations of the coital nature. Is there more to the "story"? Definitely. Are you lying to the child? Depends on what you told them (e.g. you did if you told them that storks are involved.).
A proper story would be when someone asks you why they can't just rollout their own procedures would be something like this:
"With the upgrade to SQL Server 20xx policies have been changed to have better control and a more stable production environment."
As long as those policies have been applied and include management buy-in, you don't have to add the "more to the story" as such:
"The policies are imposed because your developers have cost us $xx million in rework and overtime by pushing randomly to production."
or:
"The policies are in place so that I can build a fiefdom and make you do what I want."
October 6, 2014 at 7:02 am
venoym (10/6/2014)
Eric M Russell (9/30/2014)
GilaMonster (9/30/2014)
Eric M Russell (9/30/2014)
So, if a DBA removes an end user from the DBO role in the process of performing a migration to the next release of SQL Server, and then he says the following (not to management or a client... but to the end user for whom he revoked DBO membership), you guys would consider it a lie, an outright deceit?"I'm so sorry, I know it a pain in the a$$, but under SQL Server 20xx a login can't drop/recreate objects unless we make them database owner or sysadmin. It's a new default feature intended to tighten security and prevent SQL injection attacks. Do we really want to operate under a non-standard security configuration? It's best just to leave it as is and let the DBA execute all the deployments."
Yes, it's an outright attempt to deceive.
1) There's no such new default feature
2) A login most certainly can drop and recreate objects without being database owner or sysadmin.
If you're going to remove DBO rights, be upfront about why.
"Management has mandated that no member of the development team may have dbo on a production database"
"It's bad practice to have developers changing code in production without the knowledge of the DBA team, hence from now on the policy is that only DBAs have sysadmin"
"The auditors have said that unless we remove the DBO rights from the development team, we're in violation of the audit requirements and are subject to penalties of ..."
If the decision to tighten security comes from upper management or is part of an effort to comply with auditors, then those details would be part of a broader conversation with users, most probably delivered by management.
My earlier comments would be in response to a developer who asks "Why can't we just deploy our own procedures; why is it only your domain as the DBA?". While it is technically possible to grant them alter/drop/create permission, without granting them membership in DBO or admin role, it would still present other security issues, like unsafe code modifications (ex: SQL Injection), for which the DBA would not be made aware of. I'd prefer not to even acknowledge that as an option, and instead suffice it to say that the developer writes the code and deploys to development and the DBA deploys to production.
I'm sorry for steering this conversation off-topic; I was just curious about why some felt it was phrased in a way that made it dishonest. In the end, I agree with your assessment of it, Gail. I do believe it would be better to take a more straightforward approach in explaining to developers why it's a bad idea for anyone other than the DBA to deploy to production.
If I may. I think what you are trying to attain is not a "Lie of Omission" but rather "You didn't ask for that information". The example given is a direct lie. What you are going for is where there is "more to the story" but that the part given to the user is "all they need to know".
The case you seem to be looking for is the case where you are not withholding information to misrepresent, but rather because they didn't ask. A person can fairly state facts and information that answer questions posed and not volunteer additional information that is the "more to the story" without it being a lie. For example, when a small child (under age 6) asks where babies come from, most people don't give them the 411 on interpersonal relations of the coital nature. Is there more to the "story"? Definitely. Are you lying to the child? Depends on what you told them (e.g. you did if you told them that storks are involved.).
A proper story would be when someone asks you why they can't just rollout their own procedures would be something like this:
"With the upgrade to SQL Server 20xx policies have been changed to have better control and a more stable production environment."
As long as those policies have been applied and include management buy-in, you don't have to add the "more to the story" as such:
"The policies are imposed because your developers have cost us $xx million in rework and overtime by pushing randomly to production."
or:
"The policies are in place so that I can build a fiefdom and make you do what I want."
Being honest is easier - you don't have to remember what you said about anything. You can always state your opinion as to what is a good / bad process and the pitfalls / advantages
-------------------------------Posting Data Etiquette - Jeff Moden [/url]Smart way to ask a question
There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand (the world). There is no such thing as a dumb question. ― Carl Sagan
I would never join a club that would allow me as a member - Groucho Marx
October 7, 2014 at 11:38 am
djj (9/29/2014)
They hire me to be a DBA and then they do not take my suggestions.I tell them they should only store a standardized value. A prime example of where this would help is phone number. They put in whatever they want then have to run a udf to find the number to compare to. I have been overridden several times when I suggest cleaning the numbers they say there are extensions which I point out I can handle but no go.
This is just an example. I have been looking into why a procedure runs so long, well they programmed it to check every phone number using a udf that is not well written. i.e. it has multiple steps within the udf.
Sorry for the rant but I had to get it off my chest.:crying:
Documentation.
Write down everything. Write down the pain. Write down the solutions. Most of all, write down the amount of time you deal with firefighting.
No one will believe what you say until you're consistently correct AND you have the email chains and documentation to prove it. Even then, it's a constant battle. At no point, ever, in my career have I been in the situation where I was just believed (except when consulting). I've always had to prove it. Stinks because sometimes you know something is wrong, but you don't have the precise mechanisms to define why it's wrong. Without that exact knowledge, it's hard to get people to believe.
The good news is, if you really do try to influence them from a position beyond "I'm the DBA doggone it!" you'll learn a lot more and you'll develop some great skills.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 7, 2014 at 11:41 am
djj (9/30/2014)
SQLRNNR (9/29/2014)
Along the same line of thinking, you need to tell them what they want to hear. If you seed the idea and make it theirs, then when you agree with them on it, it will get approved. 😉A lot of times it comes down to how well you can sell them on the idea and the politics you are willing to play. I know it sounds like snakeskin salesman approach. But, think about spinning the suggestion in a more positive way without demoting the other approaches with negative connotations. TPTB will often be more receptive (whether consultant or fte), if the message sounds good rather than if it had any negative notes to it at all.
My problem is I could not sell water to a thirsty millionaire. 🙂
Then that's a skill to work on.
Thing is, you're saying you want to influence the company. You can do that through two ways, institutional power or personal power. You've already said they are not listening to you through institutional power. Fine. Build personal power. You do that by building influence, which means lots of salesmanship.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 7, 2014 at 11:44 am
Finally someone listened. We had a meeting today and we are looking to revamp the entire phone number storage.
Not because I suggested it, but a need for the client made them say, "Hey, maybe we should do something about that".
October 7, 2014 at 12:18 pm
djj (10/7/2014)
Finally someone listened. We had a meeting today and we are looking to revamp the entire phone number storage.Not because I suggested it, but a need for the client made them say, "Hey, maybe we should do something about that".
ROI will drive change faster than anything else. Retraining 20+ people to do things a particular way derives no additional cash flow. Making a customer happy retains cash flow.
ROI is both our enemy and our weapon. Use wisely.
Eric:
If some app developer (for example) pulled that on me from his side of the fence I'd be in the CIO's office of ANY company within the week describing exactly why this person needs to be fired, immediately, before he ruins any of the other developers he still trusts.
Don't lie, even by omission (which what you stated originally wasn't that method). Outright trust is the only safe and sane way to build your reputation when you're dealing with a few billion dollars of financial data or the medical records of an entire hospital. I'd rather go down in flames for the truth than do the right thing the wrong way. It's the only way you have the clout you need when you have to stand your ground... even if that ground is outside the door.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
October 7, 2014 at 1:37 pm
😉
Evil Kraig F (10/7/2014)
djj (10/7/2014)
Finally someone listened. We had a meeting today and we are looking to revamp the entire phone number storage.Not because I suggested it, but a need for the client made them say, "Hey, maybe we should do something about that".
ROI will drive change faster than anything else. Retraining 20+ people to do things a particular way derives no additional cash flow. Making a customer happy retains cash flow.
ROI is both our enemy and our weapon. Use wisely.
Eric:
If some app developer (for example) pulled that on me from his side of the fence I'd be in the CIO's office of ANY company within the week describing exactly why this person needs to be fired, immediately, before he ruins any of the other developers he still trusts.
Don't lie, even by omission (which what you stated originally wasn't that method). Outright trust is the only safe and sane way to build your reputation when you're dealing with a few billion dollars of financial data or the medical records of an entire hospital. I'd rather go down in flames for the truth than do the right thing the wrong way. It's the only way you have the clout you need when you have to stand your ground... even if that ground is outside the door.
Just for the record, what I presented earlier was a hypothetical scenario, and it wasn't intended to be taken too seriously in the first place. I've never intentionally mislead coworkers, but I'm sure we've all felt mislead from time to time while on the job, if not technically, then in other ways. It was interesting to hear various readers reactions to it. 😉
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 31 through 45 (of 47 total)
You must be logged in to reply to this topic. Login to reply