Need Information ...

[JaNas]

Hi,
We have planned to purchase ProCloud, before we can do this we need following information,

1. Is there a description available from Sparx of how information security and data protection have been taken into account when developing the solution? For example, how typical information security risks or software vulnerabilities have been taken into account during the development work.
2. How to log into the solution is of particular interest to a) internal users b) customer users.
I'm also interested in whether the solution has different user levels/roles, and how are these managed? Are there, for example, admin rights?
3. Encryption issues, is the data stored in the solution encrypted or open at the database level? Of particular interest is how traffic to the internet is encrypted or in situations where the customer uses Sparx Pro Cloud via a browser.
4. Does the system log actions taken in it, e.g. if someone deletes data/makes some changes to it? How is logging done, how long is the log data kept and is it somehow protected?

BR
JaNas

[BobM]

Hi,

I will answer what I can out of my own experience:

2. How to log into the solution is of particular interest to a) internal users b) customer users.
I'm also interested in whether the solution has different user levels/roles, and how are these managed? Are there, for example, admin rights?

You can set up for internal users and external users via different methods.
- For internal users we use SSO, only available when they are inside the internal network
- For external users (incl Customers) we use OpenID and two factor authentication

You can set up the rights in EA Sparx client with an admin account

It is technically possible to hide certain areas using row level security (if the your database supports it) depending on the method on how people enter (but it is a bit more difficult to set up, especially if you have legacy, if you don't take in account potential breaches via legacy setup in Sparx then it is security by obscurity)

[JaNas]

Thanks

[qwerty]

1. EA has no security whatsoever. Each user needs admin rights for the DB. So all doors are open wide.
2. Share XML (package exports). Can be a PITA.
3. See 1.
4. You can turn on the audit log. From my POV just a waste of resources.

I have no idea what you can do with that web stuff. I would not trust that PHP stuff further I can throw it.

You can make EA a nice modeling tool. But regarding the Enterprise in the name: nothing.

q.

[Geert Bellekens]

1. EA has no security whatsoever. Each user needs admin rights for the DB. So all doors are open wide.

That is really not true and has never been. In past versions (pre v15) the database user that connects to the database needed DDL_admin rights, but that is not the case anymore. Now read-write is enough.

And you always had the option to use a database user instead of windows authentication; using encrypted shortcut files. This meas the users never need to know the database users' password, and have no access themselves to the database.

Geert

[qwerty]

Well, even if you don't need the admin any more, the door is open still. You need access to the database and you can exploit that through any public client. If you have evil users you are lost.

q.

[Geert Bellekens]

Well, even if you don't need the admin any more, the door is open still. You need access to the database and you can exploit that through any public client. If you have evil users you are lost.

q.

Not if you don't give the users access to the database. You can work with an encrypted shortcut file that contains the a database user's credentials.
That way the users can only access the database through EA, and not through another client.

They can still delete the whole model if they want to, but no longer simply give themselves admin rights or something like that. (if you also ban them from writing scripts that is)

Geert

[Modesto Vega]

1. EA has no security whatsoever. Each user needs admin rights for the DB. So all doors are open wide.

I agree with Geert this is not really true and I will add that when using PCS not all users need database access. If using Active Directory, the only account that needs database access is the account used to run the PCS Windows service and it does not need administrator rights.

The only exception is any users that require direct database access to perform any of the functions not supported by PCS, a number that is diminishing with each release.