DG0004 Application object owner accounts should be disabled when not performing installation or maintenance actions.

Все ответы

• 1 мая 2012 г. 20:51

   

   
  

  0

  I can't of course speak for any DoD, nor the Swedish one, nor any other DoD.

  And what they mean and if they know what they mean who knows.

  I would take "application objects" to mean stored procedures and user-defined functions.

  Anyway, what the say is that accounts that owns objects should be disabled under normal circumstances. Normally - although I don't know if "normally" is applicable in places under the thumb of DoD - all objects in a database are owned by dbo. dbo maps to login. In many shops all databases are owned by sa, and it is not uncommon to keep sa disabled. Sounds simple, but that would be cheating. While sa is disabled, there is always someone who is in the sysadmin role, and that is the same as sa.

  But you can special login that are only used as database owner and keep them disabled.

  Then again, if you are sysadmin, you can be dbo in any database. Thus, for the directive to be meaningful, no logins with sysadmin can be active under normal circumstances. This may sound crazy, but say that your regular user is DOMAIN\joeller. Then there is an SQL login sa_joeller which is sysadmin. This login is constantly disabled - because you only permit Windows authentication. However, DOMAIN\joeller has one permission beyond the plain vanilla: it has the right to impersonate the login sa_joeller, so that when you need it, you can get the rights of sysadmin.

  If this is what DoD is after I have no idea - you will have to ask them. This is just my ramblings of what is actually possible and what makes sense.

  ---

  Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
  • Ответить
  • Цитировать

   
• 2 мая 2012 г. 11:31

   

   
  

  0

  This strategy is like "just in time" or "on demand". Meaning the objects are created when they are needed and the objects self destruct after use.

  You can store a sql scripts somewere else like a sharepoint site. And then run it when you need it.

  How ever if you are playing "hide-and-seek in the seen" you can store those scripts in a sql job. then run the job to build the sql objects you need. execute the created object in that same job and wipe it out automatically when the job completes.

  disable and secure the job by default.

  This design is used to hide a top secret processes.

  ---

  http://joeydj.com/blogs

  
  
  
  

  • Изменено JoeyDj 2 мая 2012 г. 11:37
  •  
  • Ответить
  • Цитировать

   
• 2 мая 2012 г. 14:49

   

   
  

  0

  Hi Joey;

  I don't think that this has to do with JIT based on the text expressed further along in the STIG

  In addition to the high privileges to application objects assigned to this account, it is also an account that, by definition, is not accessed interactively except for application installation and maintenance. This reduced access to the account means that unauthorized access to the account could go undetected. To help protect the account, it should be enabled only when access is required.

  Erland

  I agree with you that most database objects are owned by dbo.  However, dbo is not mapped to sa on these setups because sa is disabled and I believe has been removed (also a STIG).  There are several people in the db_owner role but they do more that application installation and maintenance, they are responsible for database updates and maintenance.  As far as it being just stored procedures and functions.... STIG DG0008 states

  Application objects should be owned by accounts authorized for ownership. ... Database object ownership implies full privileges to the owned object including the privilege to assign access to the owned objects to other subjects. Unmanaged or uncontrolled ownership of objects can lead to unauthorized object grants and alterations.

  This again does not specify exactly what constitutes an application object.  Sometimes when reading it I feel that they mean anything used by an application.  Other times, I am not so sure.  Can application roles own objects?  My reading about them seems to indicate that the stored procedure sp_setapprole enables the app role before allowing it to do anything.  But I don't see anything about whether or not they own the objects to which they have access nor anywhere that those objects are known by a special name of "application object".

  Update:

  Hopefully the person who wrote the STIG will see this and offer an explanation.  But probably not since the diagnostic queries that person wrote appear to have been devised by an Oracle DBA without using ANSI joins.

  ---

  Edward R. Joell MCSD MCDBA

  
  

  • Изменено joeller 2 мая 2012 г. 14:51 Update
  •  
  • Ответить
  • Цитировать

   
• 2 мая 2012 г. 21:56

   

   
  

  0

  Yes, an application role can own object. At least it worked when I did a quick test.

  Then again, I see little point in this. If the idea is that heavy-duty rights should normally not be use, it's little point of moving the ownership to an application role, there there still are people who are in the db_owner role.

  The only thing that makes kind of sense is that you have special accounts with heavy-duty permission that you impersonate when you need.

  But of course, who says that the people who wrote that document, understood what they were talking about?

  But probably not since the diagnostic queries that person wrote appear to have been devised by an Oracle DBA without using ANSI joins.

  And if he wrote the for Oracle, they will not run on SQL Server, since metadata are exposed differently...

  ---

  Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

  • Помечено в качестве ответа joeller 9 мая 2012 г. 20:05
  •  
  • Ответить
  • Цитировать

   
• 3 мая 2012 г. 1:53

  Модератор

   

   
  

  0

  The Department of Defense's Security Technical Implementation Guide (STIG) item STIG number DG0004 states

  "Application object owner accounts should be disabled when not performing installation or maintenance actions."

  This is supposed to be for SQL Server.  Is anyone familiar with any objects in SQL Server specifically called "Application Objects"?  I thought it might be database objects used by an application. But since the text refers later on to database objects as separate and distinct with application objects being a sub class I am not so sure. 

  I think this makes a bit more sense if you substute "user objects" for "application objects."  Chances are that the author simply didn't choose words carefully or there is an appendix or glossary that defines the terms better,

  The rationale for these guidelines is that ownership (and the implied control permissions) is sometimes overlooked.  You can easily comply by ensuring databases are owned by disabled logins and schemas of non-dbo objects are owned by a user without a login. 

  ---

  Dan Guzman, SQL Server MVP, http://weblogs.sqlteam.com/dang/

  • Предложено в качестве ответа amber zhangModerator 3 мая 2012 г. 2:16
  • Помечено в качестве ответа amber zhangModerator 8 мая 2012 г. 8:48
  • Снята пометка об ответе joeller 8 мая 2012 г. 12:58
  • Помечено в качестве ответа joeller 9 мая 2012 г. 20:06
  •  
  • Ответить
  • Цитировать

   
• 8 мая 2012 г. 13:42

   

   
  

  0

  Erland;

  When I said he was an Oracle DBA, I did not mean that the diagnostic queries were written for Oracle, I meant they were written using the style favor by Oracle DBA i.e. sans ANSI-92 equijoins.  Given that,

  But of course, who says that the people who wrote that document, understood what they were talking about?

  
  Your statement is not beyond the realm of possibility.

  Dan

  The was no glossary or appendix included with the documents.  Wwhen you read further in the text it states that the only time that the only time the application owner account is active is for the installation of the application.  This really seems to indicate that this only applies to objects associated with the application and not all user owned objects in general. 

  Sometimes when reading it I feel that they mean anything used by an application.

  Based on the very highly qualified people that have responded to this with the definite knowledge that there is no such thing as an "Application Object", I have come to three conclusions.

  1.  The writer is writing under the assumption that each object used by an application will be a member of a schema that is only used by that application. 

  2. That he or she thought that the owner of this schema shown be  the only login with ownership rights over objects in that schema.

  3. That the writer either did not understand ownership chaining or assumed that users with access to these objects would not be members of that schema.

  That is another reason I believe the writer is an Oracle DBA as in my experience with that RDBMS users/schemas were always devised for each application and all the objects required by that application were a part of that schema.

  ---

  Edward R. Joell MCSD MCDBA

  
  

  • Изменено joeller 8 мая 2012 г. 13:52 wording
  • Помечено в качестве ответа joeller 9 мая 2012 г. 20:06
  •  
  • Ответить
  • Цитировать