08-15-2014 11:48 AM
Back when I used Microsoft Access more often, I remember there was a way to create a database with a GUI and lock it down so that I could share it with an end-user and the end-user could not modify it in any way. It had the added benefit of being able to run without the end-user actually having to install Access.
Is there a way to do something similar with a SAS project? I'm pretty sure the bit about it running without the user having SAS installed isn't possible, but how about the locking down so user cannot edit and possibly providing the user a GUI?
08-17-2014 04:32 AM
Your question is about IT governance. (ITIL release management, change management, version management) In a detailed aspect:
a/ who is allowed to do what actions
b/ how this is technically implemented
c/ the continuous evaluation of a and b (monitoring alerts/events improvements)
The good news is: there are a lot of options to implement this.
The bad news is: there are a lot of options to implement this.
You have to describe exactly your needs and environment.
Sometimes it need to be solved as part of a common IT-service (RBAC LDAP AD OS controls)
Sometimes you need to solve it by using the third-party toolings (external RDBMS systems)
Sometimes you can use SAS server services (SAS metadata platform administration)
Sometimes you need to code it into sources (row level access)
Nice to see the origin of a lockdown questions, MS-Access as readonly version.
There is a lockdown option with SAS it will block a lot of functionality. It something different as you are asking for.
08-17-2014 03:45 PM
There is no way to run an EG project without EG being installed, unless you export your project to SAS programs. Regardless you would still need either a local or remote SAS server for running either the EG project or the exported SAS programs.
08-18-2014 09:36 AM
As Jaap points out there are lots of ways to attack the Data Governance issues. We have found that it is partly technical and partly behavioral.
Locking down data and code stored in the OS is pretty straightforward. Locking down an entire EG project might be something you could do, but you could also cripple it beyond any value.
EG stores the SAS logs in the project. Those are always generated, so there is always writing going on. That means the (temporary) copy of the project that is being run must have write access. You can lock down the copy on disk, but it won't keep users from messing with it while they are using it.
08-18-2014 02:17 PM
There are good discussions here about the pros/cons of "locking" an EG project -- it's always a good idea to define exactly what behaviors you're trying to encourage or prevent, and then look to see what technology toggles, if any, can help to achieve that.
From an EG project file perspective, you have these options:
You can probably imagine using a combination of these techniques to control access. In my opinion, locking down the EG capabilities in this way would offer only limited effect. If you truly want a read-only, opaque process that an end-user can trigger without exposing too much IP, it's better to consider a stored process on a central server.