Updated: Monday, 29 November 2021 at 09:13AM
Author: Eric Vasbinder
All customers hosted in our Viewpoint Vista clouds will have the ability to edit their Vista databases: you'll have the ability to access the Vista database directly via ODBC, edit stored procedures, triggers, views, etc. - all as per previously. This access also applies to approved third party integrations, even if the integrations are hosted externally to our cloud.
You can use SSMS, Crystal Report Builder, and perform as many integrations with Vista as needed (over a VPN). In addition, access to the Viewpoint Repository folder will be possible over a VPN, but unnecessary for uploading and editing custom Crystal reports or Create and Send templates; those functions can now be handled through the Vista rich client itself, using our new File System API. See the following page for a walkthrough of this capability in Vista over VRL: How do I upload Custom Crystal Reports to Vista in the cloud? (VRL Method)
The only exception to this level of access is activities that require admin / root level access to the operating system of the Vista database and / or app servers. For example, installing new software or updating services on the Vista machines is not allowed. For more information about this restriction, please see our article about Root / Admin Level Access to Vista Machine Operating Systems.
Please note: Root "SA" access to the SQL database for user and SQL Service Accounts is NO LONGER permitted, for security reasons. Access up to and including DBO is permitted.
DBO Access for Viewpoint-hosted SQL databases may only be given upon customer request through our standard support channels: you WILL need to create a case to make this request.
NOTE: A unique service account for EACH third party integration is the recommended path. DBO rights should only be provided for those applications who need that level of access. Most third party applications only read data from Vista and thus need dbreader access ONLY. Some integrations need write access, but only the accounts for those specific integrations that NEED write access should be granted dbwriter access. Service accounts, usually used to integrate third party applications, should have their access limited to the specific views and tables that are required for that integration; we try to adhere to the information security industry-standard concept of "least privilege" as much as possible. In other words, the bare minimum access needed for a software product or employee to do their jobs is what should be granted - no more, no less. We highly recommend that you work with your third party vendor to determine exactly what access to which parts of the database their solution needs, and then tailor the access of your service accounts to that specific access need.
NOTE: Each unique interactive "human being" who needs access to a database (e.g. for SSMS) should also have a unique SQL account created, with permissions limited to the minimum needed for that user's job duties.
Updated: Monday, 29 November 2021 at 09:13AM
Updated to have link to File System API Article.
Updated: Monday, 15 November 2021 at 10:57AM
Updated to include reference to third parties being able to have direct ODBC access, even if the code bits for their solutions are physically hosted outside of our cloud, connected over the TLS Database Endpoint or an IPSEC VPN tunnel.