Enhance Top Secret for DB2 security administration

Idea created by josef.thaler on Aug 13, 2015
    Wish-Listed
    Score9
    • ErwinGull
    • jbaker314
    • josef.thaler
    • Adnan_Can
    • balfr03
    • Frank_Armstrong
    • Jacques_Hulak
    • Chris_Williams
    • David_Lorenz

    As a Top Secret Security Administrator I need an efficient, effective and clear implementation of the administration of DB2-ressources.

     

    Therefore I suggest to enhance Top Secret for DB2, to precede each checked ressourcename with an optional customizable prefix.

     

    Installations, which have to run several db2 subsystems in the same sysplex and have to graduate and distingush the security permissions between the particular db2 subsystems could significantly benefit from the business value of this enhancement:

     

    1. From a conceptual perspective the local db2 ressourcenames (for one facility) will become global ressourcenames.
    2. Ownership of ressources and their administrative permissions could be introduced per db2 subsystem.
    3. The permission to a db2 ressource of a particular db2 subsystem would not be needed to be specified with control option FACILITY( ) any more.
    4. All powerful instruments of TSS commands could be used much more efficient (TSS LIST, TSS WHOHAS, TSSSIM, and so on)
    5. The first two characters of the db2-ressource would be maskable (today it’s not possible because of the minimum prefix length)
    6. The number of db2-facilities could be reduced to one or two. The entry-access to the db2 subsystems is anyway controlled by “DB2” resclass.
    7. The ressourcename would become similar to Websphere-MQ-ressourcenames (MQ-entities like MQQUEUE etc. begin with the queue-manager-id)
    8. A competitive inferiority (IBM's optional RACF/DB2 external security module supports the choice between "single subsystem class scope"  and "multi-subsystem class scope"!) could be turned in a superior approach by this enhancement.
    9. The "best match" determination will be improved. (in the current implementation FACILITY( ) is not involved in "best match" determination; this leads to misunderstandings and arises the need additional administration. e.g PER DB2TABLE(XYZ) FAC(DSN1) undercuts a PER DB2TABLE(XY) FAC(DSN2) although these are different db2-subsystems)

     

    There is no formal demand how to implement this enhancement.

    For illustration purposes I suggest a new DB2FAC TSS-startup-option in addition to DB2FAC(DBT1=DSNDBT1) (while DBT1 is the DB2-membername and DSNDBT1 the facility-id), for example:

     

    DB2FAC(DBT1=RESPREFX=DB2GRP) or

    DB2FAC(DBT1=RESPREFX=‘DBTG‘)

    (while DB2GRP should be replaced by the DB2-sharing-group-identifier – let’s say DBTG - resp. ‚DBTG‘ as literal)

     

    Current permissions, for example (and in assumption of above control options)

    TSS PER(prof-acid) DB2TABLE(CREATOR.TABLE_NAME) FAC(DSNDBT1)

     

    would “prefixed” have to look like

     

    TSS PER(prof-acid) DB2TABLE(DBTG.CREATOR.TABLE_NAME)  

     

     

    Yes, the implementation of such a ressource prefix would ask for a conversion of the current permissions, but I would consider this effort very worth because of the resulting better, more efficient and concludent security administration of db2 ressources.

     

    As non-native-english speaker my definition of the enhancement might be not clear enough in formulation, any amendment and supplement would be appreciated very much.

     

    reworked 2015-08-18: Business value item 7 added.

     

    reworked 2015-09-03: Business value item 8 added.

    reworked on 2015-11-09: Business value item 9 added.