July 10, 2011 at 12:44 am
Comments posted to this topic are about the item Lesson #6: What CIOs really care about
July 11, 2011 at 6:02 am
Retention is important but I've been on both sides of this formula. I've been given retention bonuses and I was also laid off due to budget issues. When clients started yelling, they ended up keeping me anyway.
The end result? I'm paranoid. I have expenses and need income to pay for those expenses. It's not easy to find a job in this economy (from what I've hard anyway). I'm always listening for the possibility of a budget issue again.
My goal? Keep doing the best job possible for the company. This gives them a good value and if they have to let someone go, maybe that might keep me off the list. None of this makes any difference if it comes from high level executives because they really have no idea what I do anyway.
July 11, 2011 at 7:46 am
Changing from sa to a new user should always be done.
However, having said that, it does not offer much if the new users rights is not properly limited.
If the new users password also is not encrypted in the .config files in applications, having a new user instead of using sa still does not increase the security much.
Do you encrypt the password for your users in the .config files? I hope you do, but I know many do not.
July 11, 2011 at 8:19 am
IceDread (7/11/2011)
Changing from sa to a new user should always be done.However, having said that, it does not offer much if the new users rights is not properly limited.
If the new users password also is not encrypted in the .config files in applications, having a new user instead of using sa still does not increase the security much.
Do you encrypt the password for your users in the .config files? I hope you do, but I know many do not.
If the account only has access to a very limited set of stored procedures, it's unlikely that the harm it can do to the database or server is something that couldn't be done using the application anyway. That's very different than "sa", which has the power to do anything you want to the server. That can be a big problem if some malicious individual or group starts issuing Drop commands via SQL injection, or a variety of other things.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
July 11, 2011 at 8:38 am
IceDread (7/11/2011)
Changing from sa to a new user should always be done.However, having said that, it does not offer much if the new users rights is not properly limited.
If the new users password also is not encrypted in the .config files in applications, having a new user instead of using sa still does not increase the security much.
Do you encrypt the password for your users in the .config files? I hope you do, but I know many do not.
Web developers, SSIS developers, or anyone who creates a .config file as part of their project, should take a moment to confirm wether the version of the .config file they check into source control contains passwords in clear text. Also ask yourself how many people within the organization have access to that project in source control.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 11, 2011 at 8:42 am
In addition to security, backups, and the hiring and retaining of good staff, a CIO should also periodically take inventory of all the IT projects that are currently under development and evaluate wether they are in line with the goals and needs of the business. Many times, especially with BI projects and data marts, it's not unusual for for a team of developers to have their heads down coding for months, a year, or even more and then someone discovers that the needs of the business have changed in the interim, but the original requirements were never updated.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 11, 2011 at 10:15 am
Thank you for getting this into our hands. It is alway valuable to know why others find our work valuable and what parts they are most aware of. Often the "IT" person is thought to be the most expendable in tight times because they cost so much and they do not add to the bottom line. But once the CEO knows that without an adaquate IT staff they can not determine what the bottom line is anymore, the priority changes.
One of the highest costs a busniess faces is the loss of corporate knowledge and experience. You can not buy it on the market and a new hire has to learn the paticular way that busniess is done within a company., which comes at a high price Remember the old commercial on TV that said "Motor oil is Motor oil" and then that was proven wrong. Today an IT professional is not just an IT professional, they become an integral part of the business and once you have one you had best do all you can to keep them.
Later...
Not all gray hairs are Dinosaurs!
July 11, 2011 at 12:01 pm
GSquared (7/11/2011)
IceDread (7/11/2011)
Changing from sa to a new user should always be done.However, having said that, it does not offer much if the new users rights is not properly limited.
If the new users password also is not encrypted in the .config files in applications, having a new user instead of using sa still does not increase the security much.
Do you encrypt the password for your users in the .config files? I hope you do, but I know many do not.
If the account only has access to a very limited set of stored procedures, it's unlikely that the harm it can do to the database or server is something that couldn't be done using the application anyway. That's very different than "sa", which has the power to do anything you want to the server. That can be a big problem if some malicious individual or group starts issuing Drop commands via SQL injection, or a variety of other things.
The time when SP's were used is starting to end sadly, I like writing sql code, however in Sweden ORM is taking over and it certainly has it's benefits, security with ORM works differently however. I do not know of a perfect way to handle security with an ORM mapper. Thus the ease of limiting use to sp's is not there for me in several cases.
July 11, 2011 at 12:36 pm
IceDread (7/11/2011)
GSquared (7/11/2011)
IceDread (7/11/2011)
Changing from sa to a new user should always be done.However, having said that, it does not offer much if the new users rights is not properly limited.
If the new users password also is not encrypted in the .config files in applications, having a new user instead of using sa still does not increase the security much.
Do you encrypt the password for your users in the .config files? I hope you do, but I know many do not.
If the account only has access to a very limited set of stored procedures, it's unlikely that the harm it can do to the database or server is something that couldn't be done using the application anyway. That's very different than "sa", which has the power to do anything you want to the server. That can be a big problem if some malicious individual or group starts issuing Drop commands via SQL injection, or a variety of other things.
The time when SP's were used is starting to end sadly, I like writing sql code, however in Sweden ORM is taking over and it certainly has it's benefits, security with ORM works differently however. I do not know of a perfect way to handle security with an ORM mapper. Thus the ease of limiting use to sp's is not there for me in several cases.
Granting db_datareader, db_datawrite, and "view definition" access to an account used by an ORM, LINQ, or BI application will give them more than what they need. Unless they need to create/drop objects or manage the server, there is no reason for the account to be a member of SYSADMIN or DBO. Maybe in development environment, but not in the Production environment.
Databases designed for use with ORM may make application development easier and faster, but they assume that the data will accessed in specific case usage patterns and are poorly designed for aggregate reporting or ad-hoc querying. I had the unfortunate task of building custom reports and billing from an application database where tables were designed such that there was one record per patient and then all phone numbers, claims, physician visits, etc. were serialized as XML documents in separate columns. The DBAs eventually had to end up creating an maintaining a seperate set of normalized tables with ETL extracts just for reporting purposes. I think that many companies implementing ORM will find that making life harder for the DBA staff and BI contractors is ultimately more expensive than making life harder for the offshore app developers.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 11, 2011 at 12:52 pm
Eric M Russell (7/11/2011)
IceDread (7/11/2011)
GSquared (7/11/2011)
IceDread (7/11/2011)
Changing from sa to a new user should always be done.However, having said that, it does not offer much if the new users rights is not properly limited.
If the new users password also is not encrypted in the .config files in applications, having a new user instead of using sa still does not increase the security much.
Do you encrypt the password for your users in the .config files? I hope you do, but I know many do not.
If the account only has access to a very limited set of stored procedures, it's unlikely that the harm it can do to the database or server is something that couldn't be done using the application anyway. That's very different than "sa", which has the power to do anything you want to the server. That can be a big problem if some malicious individual or group starts issuing Drop commands via SQL injection, or a variety of other things.
The time when SP's were used is starting to end sadly, I like writing sql code, however in Sweden ORM is taking over and it certainly has it's benefits, security with ORM works differently however. I do not know of a perfect way to handle security with an ORM mapper. Thus the ease of limiting use to sp's is not there for me in several cases.
Granting db_datareader, db_datawrite, and "view definition" access to an account used by an ORM, LINQ, or BI application will give them more than what they need. Unless they need to create/drop objects or manage the server, there is no reason for the account to be a member of SYSADMIN or DBO. Maybe in development environment, but not in the Production environment.
Databases designed for use with ORM may make application development easier and faster, but they assume that the data will accessed in specific case usage patterns and are poorly designed for aggregate reporting or ad-hoc querying. I had the unfortunate task of building custom reports and billing from an application database where tables were designed such that there was one record per patient and then all phone numbers, claims, physician visits, etc. were serialized as XML documents in separate columns. The DBAs eventually had to end up creating an maintaining a seperate set of normalized tables with ETL extracts just for reporting purposes. I think that many companies implementing ORM will find that making life harder for the DBA staff and BI contractors is ultimately more expensive than making life harder for the offshore app developers.
Still, that's more access than granting rights to sp's..
The odd behavior you mention I have not seen happen. I do however control the tables that nhibernate suggests and if I do not like them I do the work myself. However, it's very fast to use while in an early stage of development. Should the quires from nhibernate not be up to par we or I will change it. However, it does make the application easier to maintain and easier to refactor, especially in the development stage. This far I'm actually impressed, over, nothing can turn a day upside down while trying to write an nhibernate queryover statement... then I really miss my t-sql coding.
July 11, 2011 at 1:04 pm
IceDread (7/11/2011)
Eric M Russell (7/11/2011)
IceDread (7/11/2011)
GSquared (7/11/2011)
IceDread (7/11/2011)
Changing from sa to a new user should always be done.However, having said that, it does not offer much if the new users rights is not properly limited.
If the new users password also is not encrypted in the .config files in applications, having a new user instead of using sa still does not increase the security much.
Do you encrypt the password for your users in the .config files? I hope you do, but I know many do not.
If the account only has access to a very limited set of stored procedures, it's unlikely that the harm it can do to the database or server is something that couldn't be done using the application anyway. That's very different than "sa", which has the power to do anything you want to the server. That can be a big problem if some malicious individual or group starts issuing Drop commands via SQL injection, or a variety of other things.
The time when SP's were used is starting to end sadly, I like writing sql code, however in Sweden ORM is taking over and it certainly has it's benefits, security with ORM works differently however. I do not know of a perfect way to handle security with an ORM mapper. Thus the ease of limiting use to sp's is not there for me in several cases.
Granting db_datareader, db_datawrite, and "view definition" access to an account used by an ORM, LINQ, or BI application will give them more than what they need. Unless they need to create/drop objects or manage the server, there is no reason for the account to be a member of SYSADMIN or DBO. Maybe in development environment, but not in the Production environment.
Databases designed for use with ORM may make application development easier and faster, but they assume that the data will accessed in specific case usage patterns and are poorly designed for aggregate reporting or ad-hoc querying. I had the unfortunate task of building custom reports and billing from an application database where tables were designed such that there was one record per patient and then all phone numbers, claims, physician visits, etc. were serialized as XML documents in separate columns. The DBAs eventually had to end up creating an maintaining a seperate set of normalized tables with ETL extracts just for reporting purposes. I think that many companies implementing ORM will find that making life harder for the DBA staff and BI contractors is ultimately more expensive than making life harder for the offshore app developers.
Still, that's more access than granting rights to sp's..
The odd behavior you mention I have not seen happen. I do however control the tables that nhibernate suggests and if I do not like them I do the work myself. However, it's very fast to use while in an early stage of development. Should the quires from nhibernate not be up to par we or I will change it. However, it does make the application easier to maintain and easier to refactor, especially in the development stage. This far I'm actually impressed, over, nothing can turn a day upside down while trying to write an nhibernate queryover statement... then I really miss my t-sql coding.
ORM is fine for something like persisting application session state (that's not important enterprise data) or managing meta data lookup tables. It's when everything gets implemented as an object in the database that things get messy.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 12, 2011 at 8:28 am
First, datareader and datawriter are dangerous rights to have to grant. Given that you sometimes have to do so, to accommodate poorly designed applications, you have to recognize in doing so that any hijack of your database connection (hack or injection) will be able to either steal any data desired, or delete/alter any data desired.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
July 12, 2011 at 8:51 am
GSquared (7/12/2011)
First, datareader and datawriter are dangerous rights to have to grant. Given that you sometimes have to do so, to accommodate poorly designed applications, you have to recognize in doing so that any hijack of your database connection (hack or injection) will be able to either steal any data desired, or delete/alter any data desired.
ORM is by definition a poorly designed database.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply