Best Practices For Sharing RDM Access With Several Companies?

Best Practices For Sharing RDM Access With Several Companies?

avatar
an33

Hi,

we have received a request that we should give several companies access to our RDM, as there are collaborations and support is provided for the same customers.

Now we want to design the system according to best practice from the beginning, so that the whole system remains administrable and scales correctly.

Here are the basic requirements:
- Currently about 10,000 entries within RDM (MySQL backend)
- several companies in different countries would have the need to use sessions in our RDM database
- the companies should only have access to specific customers/connections
- It would be an option to set up a new database server/Devolutions server in a data center. A cloud variant would also be an option worth considering.

Now the following questions arise for us:
- Is there a recommended variant from Devolutions for such a scenario? (e.g. for the products, database backends, etc.).
- What is approximately the limit of entries you should have within RDM until you should split this to several databases to avoid performance problems?
- If it is needed to split - what would be the recommended variant in order not to have too much administrative effort? One vault for customers A-D, E-G etc. and assign permissions per company? Or one database per company and share/sync entries between vaults (is this possible?)?

I thought several companies might face this challenge and that's why I posted in the forum. If it would be possible to additionally have an appointment/get advice with someone from Devolutions, that would be appreciated as well.

Best Regards

All Comments (1)

avatar
Maurice Côté

Hello,

Indeed we can offer an architectural call, but let me post a few points for the others in the community.

  1. The lowest management effort comes from using a Directory integration to drive our Role Based Access Control
    1. Devolutions Server (customer managed) supports both Active Directory and Azure Active Directory
    2. Devolutions Hub (SAAS) will support Azure Active Directory in the coming months
  2. Although the great majority of our community is using database accounts (SQL Server, MySQL), this is NOT compliant with modern security practices. A user should never be able to connect directly to the database with tools like MS Excel or MS Access.... This means that it you do not use a directory integration, you must use SQL Server as a datasource, with our "Custom Login" authentication model. This is not really scalable if you have a lot of user churn, but some of our customers choose this for its low cost. (this model is not implemented in our MySQL datasource)
  3. The number of entries in the whole system does not have a significant impact since we introduced the notion of Vaults.
  4. In vaults though, it does have an impact. Thats why we recommend having a vault per team/geographical region/customer, etc. IF IT'S REASONABLE. Some customers do use a system like Customers_A_through_D, Customers_E_through_L, etc. with success.
  5. The "generic" recommended maximum number of entries per vault is 3000, although we are seeing that for Devolutions Hub its best to keep it around 2k, and for the Devolutions Server (since it has an extensive server side cache) we can go up to 4k. These numbers are widely variant if you use a lot of documentation in your entries, if you attach documents, etc. etc. If RDM adoption is dependent on it feeling extra performant, divide even further to satisfy your users.
  6. We do have synchronization tools if you use multiple databases, it just requires good planning to decide on the structure of the vaults.


It you have further question, just send a note a ticket@devolutions.net and we'll send you a booking link.

Best regards,

Maurice