Author Topic: Unique Security Requirement for Implementation - Restrict SPI from Admin  (Read 221 times)

Offline FranklyOneZero

  • Associate
  • **
  • Join Date: Feb 2017
  • Posts: 2
  • Forum Citizenship: +0/-0
We have a unique requirement for our potential implementation of Cognos we are currently evaluating.  Our pilot was centered around 10.2.2 but is now centered around 11.  We need to be able to restrict access to sensitive personal information (columns in our DB2 tables) to the administrators of the system.  The DB2 database itself is encrypted but we need to be able to prevent the sysadmin from executing a Report Studio report, or a Query Studio query and seeing these SPI fields unencrypted.  Is it possible to accomplish this within the FM model, the Cognos admin panel, or otherwise, within a shared, hosted environment?   Do we need a dedicated server in order to accomplish this?  ???

Online MFGF

  • Never knowingly correct
  • Super Moderator
  • Statesman
  • ******
  • Join Date: Jul 2005
  • Posts: 9,456
  • Forum Citizenship: +571/-9
  • Cognos Software Muppet
We have a unique requirement for our potential implementation of Cognos we are currently evaluating.  Our pilot was centered around 10.2.2 but is now centered around 11.  We need to be able to restrict access to sensitive personal information (columns in our DB2 tables) to the administrators of the system.  The DB2 database itself is encrypted but we need to be able to prevent the sysadmin from executing a Report Studio report, or a Query Studio query and seeing these SPI fields unencrypted.  Is it possible to accomplish this within the FM model, the Cognos admin panel, or otherwise, within a shared, hosted environment?   Do we need a dedicated server in order to accomplish this?  ???

Hi,

For any "normal" user you can add security in FM to prevent them from seeing specific items/query subjects etc. However, if the people in question are members of the System Administrators role in Cognos, they are in essence super-users, and they can see and do everything, regardless of security rules.

Cheers!

MF.
Meep!

Offline FranklyOneZero

  • Associate
  • **
  • Join Date: Feb 2017
  • Posts: 2
  • Forum Citizenship: +0/-0
Thank you.

Offline simplebi_guy

  • Full Member
  • ***
  • Join Date: May 2016
  • Posts: 11
  • Forum Citizenship: +0/-0
    • http://simplebi.com
This is just database connection security no?  You don't need separate databases, just use your database accounts.
All the cognos tools (fm, reports, datasets) are going to use the permissions of the database account you use in the datasource to connect to the database, so create an account for the datasource that cannot access those fields/tables in your database and use that for your building your datasource.  You won't be able to report on them but the cognos admins won't be able to access them either.
You can even create a separate datasource and fm model for your cleared administrators so only they can report off that data, or any similar combination you could otherwise do with database security.

Online MFGF

  • Never knowingly correct
  • Super Moderator
  • Statesman
  • ******
  • Join Date: Jul 2005
  • Posts: 9,456
  • Forum Citizenship: +571/-9
  • Cognos Software Muppet
This is just database connection security no?  You don't need separate databases, just use your database accounts.
All the cognos tools (fm, reports, datasets) are going to use the permissions of the database account you use in the datasource to connect to the database, so create an account for the datasource that cannot access those fields/tables in your database and use that for your building your datasource.  You won't be able to report on them but the cognos admins won't be able to access them either.
You can even create a separate datasource and fm model for your cleared administrators so only they can report off that data, or any similar combination you could otherwise do with database security.

The problem with that is that nobody would be able to report on those data items at all - not even the HR people who I'm guessing should have access to them. As soon as you add a second data source that *does* have privileges to see the data, the Cognos system administrators would be able to use it - there's no way to prevent them from being able to do so.

The only solution I can see is a separate Cognos instance these users do not have access to at all.

MF.
Meep!

Offline simplebi_guy

  • Full Member
  • ***
  • Join Date: May 2016
  • Posts: 11
  • Forum Citizenship: +0/-0
    • http://simplebi.com
Well yes, someone would need to build the reports etc,  but once they are built (say against masked dev instance) you can lock it down by implementing SSO or leave the datasource authentication blank (userid or password or both if you have different accounts to use) so that the users get prompted when accessing them.  you can also split out admin privs in cognos to limit access to the content in cognos so that only cleared admins can access that content to maintain it.  You can customize all the roles, including most admin tasks (by role or by tenant) so that you don't have everyone using the system admin role.  bottom line is that the cognos admins have no special access outside cognos so limit data access it at that point of contact.   You shouldn't need a second instance since its an enterprise class tool.

 


           
Twittear