Database repository - single or multiple projects per database ?

[qwerty]

As Uffe said...

EA per se is not secure. Working on a central DB needs full access for each modeler. Meaning you can query anything with ease. There is no protection. Anything built "aside" is a work around. If you need central security you need to have a central gate where authorized people hand out stripped EAP files and merge data back. Lots of overhead here and definitely you need a security team to approve the setup (if you manage to get one at all).
q.

[Geert Bellekens]

Uffe,

I understood things a bit differently. I think that row level security is actually security in the database itself, regardless of the way you connect to it.
I believe the reason they say you can only use it with Pro Cloud server, is because the setup is organized there. Once set-up it should provide database level security regardless of connecting with the EA client directly, or even with SSMS.

Disclaimer: this is what I understood from a demo a while ago. I did not actually play with it myself.

Geert

[Eve]

Across the EA15 presentations videos I see that I could make multiple root nodes in a project and limit their visibility so users can't even see the root node.
Would this feature help me acheive my goals ?

No. This feature is not related to the row level security function. Consider it more as a convenience for your users who don't want to see things in those root nodes. They can still access the information if they try a little.

I would not trust this mechanism to meet any information security requirements without having done a proper analysis in the context of the proposed deployment.

By all means, review it. Row level security is not our term. What we have done is applied the techniques described by Oracle and Microsoft to the Enterprise Architect data model, allowing useful portions of the database to be restricted. The good news is you only need to do your analysis on the EA portion of the technology. The DB side is well documented.

Row-level security has been introduced to help address this, but there is no public documentation that goes into any detail beyond the fact that row-level security is applied only to 24 "critical" tables (out of the 94 tables in EA's database schema). However, the documentation does state explicitly that "only models hosted by a Pro Cloud Server are able to make use of this feature", so for client users the old access model still applies.

The changes all happen directly within your database, which as far as I'm concerned means that they are quite open. As Geert states, the security is within the database. The PCS offers an added redirection so that users don't have direct DB access, but even if they could connect using the credentials the cloud is using, they couldn't access the data they aren't meant to see.

Since the EA client's security model is trivial to bypass, the only way to achieve meaningful security is to use the security features of the underlying database. This means that the project (which is essentially the same as a database) is the smallest unit at which security protections can be applied.

Which is what row level security is doing.

That's as may be, but there are several industries where security is the business, or is at least integral to it. In those, convenience of use takes a backseat to security, and in those, EA has to be set up the way I've described.

Maybe you should actually investigate the features within EA and PCS before you make such a blanket statement.

[qwerty]

Since the EA client's security model is trivial to bypass, the only way to achieve meaningful security is to use the security features of the underlying database. This means that the project (which is essentially the same as a database) is the smallest unit at which security protections can be applied.

Which is what row level security is doing.

Any certification for that?

q.

[Eve]

Any certification for that?

I don't think that anyone offers certification for using a database feature.

Seriously, do a search for Oracle or SQL server row level security. That will give you a very good idea of what is happening and why it's better security than anything EA can do on the client side.

[Modesto Vega]

Row level security essentially delegates the management of what an authenticated user can do with individual rows to the underlying RDBMS. If you are thinking in terms of CRUD, this only applied to the letter R, U and D.

Row level security tends to be expensive, especially if it is abused/misused.

With regards to how to structure the repository, it depends on your needs. If your projects are all independent and are not contributing to documenting or creating/transforming an existing common and visible architecture, the you are fine with individual project files or databases. However, if these projects are contributing to documenting and creating/transforming a common and visible architecture, you probably need to have a common repository.

There are various ways to achieve this, one of them involves using multiple files/databases which are consolidated at some point into a central core repository.

It really depends on your requirements. There is another thread on the forum with a similar subject.

With regards to the canonical model proposed by adepreter, the important thing in my experience is to have, use, and monitor the usage of a canonical meta model. In my experience, a canonical approach is not achieve by having all structural elements in an structural folder. If the meta model is truly canonical and monitored properly, the same can be achieved by having multiple structural folders one per domain and/or project. The key thing is to encourage re-use and prevent duplication.

[Glassboy]

With regards to how to structure the repository, it depends on your needs. If your projects are all independent and are not contributing to documenting or creating/transforming an existing common and visible architecture, the you are fine with individual project files or databases. However, if these projects are contributing to documenting and creating/transforming a common and visible architecture, you probably need to have a common repository.

It's not determined by the technology.  It's determined by business rules around who should be able to view modelling of the future.  Especially where there are HR implications. 

[Paolo F Cantoni]

With regards to how to structure the repository, it depends on your needs. If your projects are all independent and are not contributing to documenting or creating/transforming an existing common and visible architecture, then you are fine with individual project files or databases. However, if these projects are contributing to documenting and creating/transforming a common and visible architecture, you probably need to have a common repository.

It's not determined by the technology.  It's determined by business rules around who should be able to view modelling of the future.  Especially where there are HR implications.

+1 (my emphasis).
Where people often say about certain behaviours etc. "It's all about the money"...
When you analyse model visibility and the reasons advanced for stopping universal visibility, it almost always comes to "It's about the HR implications".

Otherwise, the notion of hiding parts of the model is the antithesis of modelling.

My experience has been the same as GBs.

Paolo

[Modesto Vega]

With regards to how to structure the repository, it depends on your needs. If your projects are all independent and are not contributing to documenting or creating/transforming an existing common and visible architecture, then you are fine with individual project files or databases. However, if these projects are contributing to documenting and creating/transforming a common and visible architecture, you probably need to have a common repository.

It's not determined by the technology.  It's determined by business rules around who should be able to view modelling of the future.  Especially where there are HR implications.

+1 (my emphasis).

Just for the record, I did not write that it depends on technology. I intentionally used the very ambiguous word needs and did not precede it with the word business.

I do agree that business needs/requirements/rules need to be taken into consideration/drive the structure of the repository. But the key point is nicely synthesised by Paolo:

Code: [Select]

The notion of hiding part of the model is the antithesis of modellingI cannot agree more and will go further, it is the antithesis of architecture. But it is becoming more common as too much profit is at stake.
 

[Glassboy]

Code: [Select]

The notion of hiding part of the model is the antithesis of modellingI cannot agree more and will go further, it is the antithesis of architecture. But it is becoming more common as too much profit is at stake.

It isn't the antithesis at all.  The purpose of architecture is to deliver business outcomes.  Often there are very important business reasons for people not knowing things, either for commercial or regulatory reasons.

The idea that an architect is some special person who gets to lift every lid and peer in is nothing but sheer arrogance.

[Paolo F Cantoni]

Code: [Select]

The notion of hiding part of the model is the antithesis of modellingI cannot agree more and will go further, it is the antithesis of architecture. But it is becoming more common as too much profit is at stake.

It isn't the antithesis at all.  The purpose of architecture is to deliver business outcomes.  Often there are very important business reasons for people not knowing things, either for commercial or regulatory reasons.

The idea that an architect is some special person who gets to lift every lid and peer in is nothing but sheer arrogance.

I intended to write "The notion of hiding part of the model is seen as the antithesis of modelling"
As can be surmised from my original post here, I agree that certain parts of a common model may need to be less visible than others.

The question is not whether an architect (or user) can see that part (since somebody is modelling it) but whether all architects (or users) can see it (and at what time).
Often (again, frequently, for HR reasons) a part of a model may be "embargoed" until a certain date and then can be released "into the wild".

Paolo

[Glassboy]

I intended to write "The notion of hiding part of the model is seen as the antithesis of modelling"
As can be surmised from my original post here, I agree that certain parts of a common model may need to be less visible than others.

I didn't have a problem with your statement.  Modesto modified your statement in the quote.  My main issue is the assumption that the needs of projects or architects are more important than the needs of the business.

[Modesto Vega]

I intended to write "The notion of hiding part of the model is seen as the antithesis of modelling"
As can be surmised from my original post here, I agree that certain parts of a common model may need to be less visible than others.

I didn't have a problem with your statement.  Modesto modified your statement in the quote.  My main issue is the assumption that the needs of projects or architects are more important than the needs of the business.

I did not modify the quote and your suggestion I did is offensive. I will try to give you the benefit of the doubts and assume you did not read it, just glance it.

Paolo wrote:

Otherwise, the notion of hiding parts of the model is the antithesis of modelling.

The quote still reads “the notion of hiding parts of the model is the antithesis of modelling”. If Paolo thinks he now needs to say “is seen as the antithesis ...”, only he knows why.

The needs of the projects and the needs of the architects need to be balanced within the applicable legal framework. If the legal framework prescribes that certain parts of a model or certain models should be restricted, so they should be.

My point is that in the absence of such a legal requirement, the notion that some architects are more equal than others and therefore can see things others cannot see is ethically questionable and suspicious. It reminds me of the ending of certain famous novel by the same British author who wrote 1984.

P.S.: Just for the record, I do not believe in architecture democracy but whenever possible openness is important. Openness means everybody can see what can be legally shared but only their owners can modify it (and/or copy it).

[Glassboy]

I did not modify the quote and your suggestion I did is offensive. I will try to give you the benefit of the doubts and assume you did not read it, just glance it.

Paolo wrote:

Otherwise, the notion of hiding parts of the model is the antithesis of modelling.

The quote still reads “the notion of hiding parts of the model is the antithesis of modelling”. If Paolo thinks he now needs to say “is seen as the antithesis ...”, only he knows why.

You can see clearly in your quote that you did.  When you remove words from a sentence you change the context.

[KP]

Just a reminder...

Have fun on the forum, stay light, enjoy the exchange of really useful knowledge and experience, freely offered and gratefully received in good humor and friendliness.