EA Security Best Practices

[braddet]

Hello,

I am looking for some information on Best practices with EA and database security.

Specifically, if the DB user being used to access the DBMS has full create, update, delete rights.  Then cannot the user simply elevate his or her own security by connecting to the DB via another tool and simply manipulating the appropriate tables? or otherwise updating models that have been checked out for use or marked read-only by others?

My experience with other applications is typically that the server database username and password are stored outside of the client (usually on another server), and that that username and password is unknown to the particular user accessing the application. (ie: they have their own username password that is validated at an application level).

I searched but was unable to find a similar question, I apologize in advance if one is there and I missed it.

Any recommendations on how to lock down EA to prevent privilege elevation would be appreciated.

Tks.
Brad D. :-)

[OpenIT Solutions]

Hi,

There are two parts to the answer. Firstly speak to your DBA. Not sure about other DB but i know SQL Server databases can be configured to only accept connection from specific client applications - ie Sparx.

Within Sparx itself you will want to enable security. Then use locking to ensure that model elements are locked to specifc users (or groups of users). Check out the help on security.

regards,

Jon.

[braddet]

Thanks for the suggestion! - Yes we could consider prevent access via other applications say via an application level firewall or similar. I was just looking if their was an EA best practice for setup to lock the system down.

As per the EA user security, my concern is that enabling it isn't creating "real" security, unless we could be sure that the general user base cannot access the DB directly to preform actions outside of EA itself.

It's not that we think people would intentionally modify anything. But I fear during a security audit if we specified that we use the EA user based security to manage access to models, a simple investigation would determine that it could be easily circumvented, so I'm just trying to head this off before such a defect might occur

[qwerty]

Basically the EA security is not much more than a "accidental-remove-prevention". Since each user needs full r/w access to the repos, EA builds some internal security inside the GUI. It is not implemented on the database. That means, if you connect with a simple command line SQL you can clobber the database with no problems. The question is: why should any of your modelers do that? To create reason for quick firing?

q.

[braddet]

They definitely wouldn't do that. I can proudly say I'd trust anyone on the team with my life. However it has been my experience that when dealing with security audits, one can't just say "We trust everyone not to do bad things" and then the auditor accepts that response and walks away.  

We can say, "This is not data that must be kept secure". In other words there is no risk to the company if the data was inadvertently  accessed / modified, and this situation that could be perfectly true.

Thanks again!

Thanks

[braddet]

It seems at least that after making a successful connection, I can encrypt the connection string. I can then give the encrypted string to other users and then they can access EA.

I am hopeful this might be sufficient for my needs, as the encrypted string will work with the application, but does not allow the user to access the db via other tools.

[Helmut Ortmann]

Be aware: If someone has access to your EA repository with EA he/she can do everything with this repository.

I think qwerty stated it very well.

Helmut

[qwerty]

It seems at least that after making a successful connection, I can encrypt the connection string. I can then give the encrypted string to other users and then they can access EA.

I am hopeful this might be sufficient for my needs, as the encrypted string will work with the application, but does not allow the user to access the db via other tools.

Of course you can limit access to the repository on a per-user basis from the database. EA allows for a windoze-user security so the extra effort for the admin is not too high.

q.