4 Replies Latest reply on Jun 11, 2008 7:55 PM by Jason Ebersole

    PDMWorks basic security Questions (and info about DBWorks)

    Jason Ebersole
      The reason for this thread:

      I'd like to ask questions about the security structure of PDMWorks as it relates to basic IT security theories and to share with users in these forums some basic things I've recently learned about DBWorks security.

      I am currently evaluating DBWorks and will start a PDMWorks in-house evaluation in a couple of weeks. Some of the things I've learned about DBWorks security has raised an eyebrow, and I am looking for confirmation of these findings from people with DBWorks experience, and a comparison of these findings to how PDMWorks "does it."

      I have a couple of things to discuss:
      When using DBworks with SQLServer as the DB platform, there is a DbWorks utility that will assign a windows domain group (intended for DBWorks user accounts) proper DB permissions. What this utility does is assign this group "owner" rights to the DBWorks db on SQLServer. From a DB Admin perspective, this is a huge issue. For DBWorks people, can this be tweaked to better secure the DBWorks DB? For PDMWorks people, is this also the case with PDMWE? If not owner rights, would a PDMWE user still be able to connect to db tables via ODBC with read/write/delete access to the data?

      To control user permissions on checked-out files in DBWorks, each client PC runs a DBWorks service called DBWServer. If a DBWorks user checks out a file, this service tweaks windows file-level permissions on the file "on the fly" so other DBWorks users have only read/execute permissions while it is checked-out. As far as I know, this DBWServer service needs to start under a Domain account with Domain Admin rights. This gets configured on every DBWorks PC. Hmmm. DBWorks people, is there any way to protect DBWorks file repositories without the use of a Domain Admin level account configured on each PC? PDMWorks people, I am vaguely familiar with the PDMWorks infrastructure, but from what I can tell, vault files are protected by a service that runs on the server where the files are being stored. Is this correct? This seems much more proper in an Enterprise environment. Are there any similar security-related concerns that are worth discussing?

      Thanks, Jason

        • PDMWorks basic security Questions (and info about DBWorks)
          Joy Garon
          Hello Jason -

          PDMWE uses a single SQL-Server user account that must be "db owner". The normal end user will never have access to the SQL-server credentials however so he won't be able to log in to the database himself. The credentials are stored encrypted on the PDMWE archive server to which normal users usually do not have access. MS SQL Server supports SSL-protection of the log-in and when this is turned on you have a very robust protection of your SQL-server data.

          The files that are put in PDMWE are stored on an archive server. The end user does not have disk access to that server. All communication goes via PDMWE's archive server port (usually 3030). You cannot retrieve or upload data without logging in first using an PDMWE account. This provides a safe layer preventing user from destroying/accessing data either by accident or intentionally.

          Best Regards,
            • PDMWorks basic security Questions (and info about DBWorks)
              Spencer Smith
              Good question. I'll attempt to elaborate on Joy's answer - mainly as a previous DBWorks admin/user, and current PDMWE admin/user. In my experience, however, the end user never has access to the credentials since the service is configured so that the log on information is unique to the DBWServer service, and the configuration/setup is done by an admin anyway. The user just keeps on going, oblivious to it all. Now, whether a user is able to utilize the DBWServer service to gain Domain Admin rights is a question for your VAR's technical guy. I would assume not, since that would indeed be a problem. Personally, if there were a user savvy enough to do so, and stupid enough to attempt it, they wouldn't be around for long.

              First, you have to realize that DBW and PDMWE have a basic and inherent difference...in DBWorks, you are always working on the file referenced by the db, and there are no copies made. In PDMWE, a Check Out or GET operation makes a copy of the db file locally on your machine. There are drawbacks and benefits to both - that's another discussion.

              That being said, in each case there must be a method for allowing the PDM system to create/update files and records that are otherwise protected against such changes. The "db owner" for PDMWE and the DBWServer service for DBWorks is what achieves this. The rules for what can and cannot be done are maintained at the PDM UI level, and the actual work that gets carried out is done through this 'superuser' account.

              So, while both systems handle it a little differently, both are pretty secure. In any system, PDM or otherwise, there are ways for people to get around your measures, both within and outside the rules. Unfortunately, not giving access to anyone is not a feasible solution so you must figure out what works and what doesn't.

              Hope this helps,
            • PDMWorks basic security Questions (and info about DBWorks)
              Jeff Sweeney
              The DBWService is typically logged in as an admin. It simply sits there waiting for commands from DBWorks. If the user has the ability to get to its API shell, the user can make the service run commands in the service's library.

              I don't see this as a very big risk for two reasons: You can limit who can send the commands to the service; and the service only works on the vault, it would take a pretty good hack to use it for other purposes.
                • PDMWorks basic security Questions (and info about DBWorks)
                  Jason Ebersole
                  I can deal with the DBWServer service account and how it works at the windows file level. One thing you didn't mention however is the SQLServer DB security. From what I've learned, access to the DB data (and the vault documents) is more restrictive with PDMWE, and in a good way I think.

                  For example, with DBWorks, each client PC has an ODBC connector for the DBWorks DB on SQLServer. The DBWorks client uses this connector for access to the DB (obviously), but this connector can also be used with other applications such as MSAccess. Since the connector is configured to use Windows Authentication, and the DBWorks DB is set so DBWorks Users are "owners" of the DB, users would have the ability to read/write/delete data in the DBWorks Db if they were to connect to the Db by an application other than the DbWorks client. Not likely that this would happen, but still possible.

                  Does PDMWE work the same way as far as client DB access is concerned? Joy says not. Can someone else verify?

                  Thanks, Jason