21 Replies Latest reply on Mar 5, 2010 3:54 PM by Daniel Takara

    Off - Topic Question Security and and a lot of people with managing tag - rights

    wpurrer

      Just a more "Off - Topic" - Best Practice  question related to administration of big installations.

       

      I have about 90 Interfaces, and a lot of people help me, managing the interfaces, I now heared, that if you have "Write" - Rights to the Database you can access all the data, even if you have no rights on the datapoint itself. => That mean practically the security settings doesn't work for people with W rights to the pipoint - table.

       

      How do you manage your system, only a few administrators (1-3) or some key users who can change data in the point database.
      Or with third party companies, who create some of the interfaces for you ?

       

       

       

       

        • Re: Off - Topic Question Security and and a lot of people with managing tag - rights
          hanyong

          Hi Wolfgang,

           

          Wolfgang Purrer

          I now heared, that if you have "Write" - Rights to the Database you can access all the data, even if you have no rights on the datapoint itself. => That mean practically the security settings doesn't work for people with W rights to the pipoint - table.

          I am not sure where you heard that information from, but I do not think thats quite the case. The database security actually controls a different set of rights compared to the pipoint table/database. For example

           

          Write access to PIArcAdmin database => you have rights to administer archives, like unregistering archives
          Write access to PIArcData database => you have rights access internal archive information, like cache and statistics, meaning you can reset the statistics and cache, etc.

           

          I guess something that you want to take note of if you are using PI server version 3.4.380, you want to make sure the identity "PIWorld" do not have Read access, else no matter which user or identity you have, you will have read access to the data.

           

          I am not managing a PI server personally. Among the people that I have worked with, the most common way of managing is such that only the administrators have full access, and most other users only have read access to both points and data. So any task like changing data, adding/deleting point are sent to the administrators as a request. Some would group the points based on the production area and only allow groups working in that area to have read access as well.

           

           

            • Re: Off - Topic Question Security and and a lot of people with managing tag - rights

              Wolfgang Purrer

              I now heared, that if you have "Write" - Rights to the Database you can access all the data, even if you have no rights on the datapoint itself. => That mean practically the security settings doesn't work for people with W rights to the pipoint - table.
              As Han Yong pointed out, this is not the case: the "write" privilege on the PI Points database allows you to make change to the structure of the database itself (add/remove items, i.e. create/delete PI Points). Then access to these items specifically (i.e. read/edit the data in it, read/edit its configuration) is defined at the item level, through the DataAccess/PtAccess point attributes.

               

              Say you have a user with Write privileges on the PI Points database but no read/write (not even read through the PIWorld identity), then you won't even see the tag in the Tag Search. Just try it out, you'll see

                • Re: Off - Topic Question Security and and a lot of people with managing tag - rights
                  wpurrer

                  I know, but as long as you have write access to create points, you can create Performance Equations and you just have to know the name of a tag.
                  (to know the name of a tag is very easy: guessing, eng database, sap,...)

                   

                   

                   

                  If someone has the right to create tags ... he can access through PE all the data (even if he hasn't right to the datapoint itself). => The security of the data then just depends on if it easy to guess the tagname.

                    • Re: Off - Topic Question Security and and a lot of people with managing tag - rights

                      You are right in that somebody with 'write' privileges on the PI Points database can create a PE point that reads/exposes the value of another PI Point for which that same user does not have 'read' privileges (given that that person guessed/found the name of that PI Point).

                       

                      While that (very) indirect way to obtain data is a reality, I don't see it as being exactly in line with your original statements: if you have "Write" - Rights to the Database you can access all the data [...] the security settings doesn't work.

                       

                      With that said, I'm not sure how to address this, or if there even is a way to address this... I'll bring this up to the right people and see what they think.

                        • Re: Off - Topic Question Security and and a lot of people with managing tag - rights
                          Daniel Takara

                          Steve Pilon

                          You are right in that somebody with 'write' privileges on the PI Points database can create a PE point that reads/exposes the value of another PI Point for which that same user does not have 'read' privileges (given that that person guessed/found the name of that PI Point).

                           

                          (...) I'm not sure how to address this, or if there even is a way to address this...

                           

                          I have not tested it myself, but I think that a currently possible workaround is to create multiple instances of the PI Performance Equation Scheduler and the PI Totalizer Subsystem services on the PI Server. Each instance should then run with the privileges of the appropriate PI Principal (i.e., PI User, PI Group or PI Identity), depending on which tags each instance should have access to. Of course, in this scenario, this means that none of these services should run with piadmin privileges (which is the default configuration).

                  • Re: Off - Topic Question Security and and a lot of people with managing tag - rights
                    Bryan Owen

                    Wolfgang,

                     

                    Your concern is appreciated and of course it is legit to solicit best practices on vCampus. Hopefully you will hear from other sites in a similar situation.

                     

                    I want to emphasize write permission to point attributes (not just the database security point table) is indeed an important privilege.  Risks affect not just privacy but core integrity and availability concerns as well: 

                     

                    Until PI 3.4.380, out of the box demo tags opened write access to PIWORLD! Since calculation services often execute as piadmin the potential for anyone to configure a demo tag to follow any point on the system is real.  Worse yet, changing demo tag into an interface tag is potentially catastrophic. Permission to write point/module/element configuration attributes is a big responsibility - this is one of the main reasons for the PI Audit Trail. Configuration represents a significant engineering investment on many system. In addition to configuration rework, downtime, data loss, information disclosure and process manipulation represent some other potential risks.

                     

                    A configuration management system may be the best solution where the honor system is not sufficient assurance for proper use of configuration privileges.  This may include use of automation and scripting tools like AF, APS, OLEDB, SDK or even PICONFIG.   In a security sensitive environment, adding approval workflow may also be appropriate.

                     

                    A well configured PI server enforces a good measure of access control for standard users and all changes to the system can be tracked.  However, there is more work to do and we will continue to harden the default security posture.  I look forward to hearing about any real world configuration management solutions for PI.

                     

                    -Bryan

                     

                     

                      • Re: Off - Topic Question Security and and a lot of people with managing tag - rights
                        wpurrer

                        @ Bryan
                         ... where do i find the configuration management system from osisoft...

                          • Re: Off - Topic Question Security and and a lot of people with managing tag - rights

                            On the topic of security, on PI server WIS have you noticed on fresh installs it is very easy to lock everything up...install fresh, remove explicit piadmin access, restart basess...now you can't change anything, even the localhost trust fails.

                              • Re: Off - Topic Question Security and and a lot of people with managing tag - rights
                                Daniel Takara

                                Rhys @ RJK Solutions

                                On the topic of security, on PI server WIS have you noticed on fresh installs it is very easy to lock everything up...install fresh, remove explicit piadmin access, restart basess...now you can't change anything, even the localhost trust fails.

                                 

                                 

                                Rhys,

                                 

                                I would expect the built-in localhost trust to fail only if you check the option "User cannot be used on trusts" for the piadmin user in PI SMT. The "User cannot be used for an explicit login" field by itself actually should not make any difference on trusts.

                                 

                                The "User is disabled" field for the piadmin user appears disabled in PI SMT. Nevertheless, I experimented a little here and it was relatively easy to make piadmin "go into coma": just had to mark all the following options for the piadmin user in PI SMT

                                • User cannot be used for an explicit login
                                • User cannot be used in a Trust
                                • User cannot be used in a Mapping

                                As expected, this made the localhost trust fail. While I performed these changes, the random interface, pitotal and pipeschd were stopped. When I tried to start the random interface and pipeschd, they failed to establish a connection and quit (as expected):

                                 

                                D 04-Mar-10 18:45:35 pinetmgr                                            (7004)
                                 >> PInet accepted TCP/IP connection, cnxn ID 28 Hostname: , 127.0.0.1: 2157

                                D 04-Mar-10 18:45:35 pinetmgr                                            (7051)
                                 >> New Pinet 1 connection: PipeE Protocol: 00010008

                                I 04-Mar-10 18:45:35 pinetmgr                                            (7054)
                                 >> New Pinet 1 connection: PipeE No Trust established for: localhost|127.0.0.1|PipeE. Explicit login is required for access.

                                I 04-Mar-10 18:45:38 pinetmgr                                            (7077)
                                 >> Access Denied: [-10413] No trust relation for this request   ID: 28. Address: 127.0.0.1. Host: . Name: PipeE. User: . OSUser: . Trust:

                                D 04-Mar-10 18:45:38 pinetmgr:Connection Information                     (7080)
                                 >> Connection ID: 28 ; Process name: PipeE ; User:  ; OS User:  ; IP: 127.0.0.1 ; AppID: 0 , 0 ; AppName: PI-IN-UNIINT , pipeschd (connecting)

                                I 04-Mar-10 18:45:44 pinetmgr                                            (7113)
                                 >> Deleting connection:  PipeE, A request to abort a connection was received. Check previous messages for more details. [-10721] PINET: Client Aborted Connection., ID: 28  127.0.0.1:2157

                                D 04-Mar-10 18:45:44 pinetmgr:Connection Information                     (7079)
                                 >> Connection ID: 28 ; Process name: PipeE ; User:  ; OS User:  ; IP: 127.0.0.1 ; AppID: 0 , 0 ; AppName: PI-IN-UNIINT , pipeschd (disconnecting)

                                D 04-Mar-10 18:45:44 pinetmgr:Connection Statistics                      (7133)
                                 >> ID: 28; Duration: 0. min.; kbytes sent: 0.2089844; kbytes recv: 0.3925781; app: PI-IN-UNIINT, pipeschd; user: ; osuser: ; trust: ; ip address: 127.0.0.1; ip host:

                                 

                                However, when I started pitotal, it did not quit. It kept running fine instead. Apparently pitotal does not connect to PI using trusts:

                                 

                                I 04-Mar-10 18:44:33 pinetmgr                                            (7039)
                                 >> Connection accepted:     Process name:  pitotal(5588) ID: 27

                                D 04-Mar-10 18:44:33 pinetmgr:Connection Information                     (7080)
                                 >> Connection ID: 27 ; Process name: pitotal ; User:  ; OS User:  ; IP:   ; AppID: 0 ; AppName: pitotal (connecting)

                                I 04-Mar-10 18:44:33 pitotal                                             (6027)
                                 >> PI subsystem pitotal is now running, version: PI 3.4.380.36

                                I 04-Mar-10 18:44:34 pitotal                                            (12088)
                                 >> Restarting from save file C:\PI\dat\pilasttot_T.dat

                                I 04-Mar-10 18:44:34 pitotal                                            (12077)
                                 >> Initializing with pointsource = T

                                I 04-Mar-10 18:44:34 pitotal                                            (12092)
                                 >> Adding point total1

                                I 04-Mar-10 18:44:34 pitotal                                            (12078)
                                 >> Startup complete - 1 active points.

                                D 04-Mar-10 18:44:34 pinetmgr                                            (7075)
                                 >> Servertablelist received from ID 27 pitotal(5588). 2 entry(ies): pitotal_subsysquery|1 pitotal_dbsecurity|1

                                D 04-Mar-10 18:44:34 pitotal                                             (6041)
                                 >> Rpcservertablelist successfully registered to pinetmgr.

                                 

                                Could anyone maybe comment on the pitotal behavior (more specifically, on why it is different from the pipeschd behavior)?

                                 

                                Having not created any additional PI users (and granted them with the required priviledges to edit other users' settings), the only way I am aware of to recover piadmin from this situation is quite intrusive: restore a PI backup before piadmin settings were changed.

                                  • Re: Off - Topic Question Security and and a lot of people with managing tag - rights
                                    Bryan Owen

                                    Good observation. Both PI Alarm and PI Totalizer are well known PI 3 subsystems.  Authentication and authorization for subsystems is of interest but lower priority inside a machine trust boundary. However, subsystem authentication is required between members of a HA collective.

                                     

                                    PI Performance Equation Scheduler is a hybrid implementation, part subsystem (close coupled with PI Archive) and part trusted UNIINT based API application.  As an API application, PI Trust authentication is required.  Perhaps just luck but this provides a mechanism for administrators to lower the permissions for a PE instance.

                                     

                                    Authentication weaknesses are a top security issue and as many have noted Windows Integrated Security provides a significant step forward. That said, there is much more to do.  It must be much easier to implement a least privilege security model while allowing appropriate controls for multiple administrative roles. 

                                     

                                    It is certainly on the right track to configure point permissions and remove the default trusts. I look forward to the day piadmin goes into a peaceful retirement!  

                                     

                                     

                                      • Re: Off - Topic Question Security and and a lot of people with managing tag - rights
                                        Daniel Takara

                                        Daniel

                                        (...) I think that a currently possible workaround is to create multiple instances of the PI Performance Equation Scheduler and the PI Totalizer Subsystem services on the PI Server. Each instance should then run with the privileges of the appropriate PI Principal (i.e., PI User, PI Group or PI Identity), depending on which tags each instance should have access to. Of course, in this scenario, this means that none of these services should run with piadmin privileges (which is the default configuration).

                                         

                                        Bryan

                                        Good observation. Both PI Alarm and PI Totalizer are well known PI 3 subsystems.  Authentication and authorization for subsystems is of interest but lower priority inside a machine trust boundary. However, subsystem authentication is required between members of a HA collective.

                                         

                                        PI Performance Equation Scheduler is a hybrid implementation, part subsystem (close coupled with PI Archive) and part trusted UNIINT based API application.  As an API application, PI Trust authentication is required.  Perhaps just luck but this provides a mechanism for administrators to lower the permissions for a PE instance.

                                         

                                        Authentication weaknesses are a top security issue and as many have noted Windows Integrated Security provides a significant step forward. That said, there is much more to do.  It must be much easier to implement a least privilege security model while allowing appropriate controls for multiple administrative roles. 

                                         

                                        It is certainly on the right track to configure point permissions and remove the default trusts. I look forward to the day piadmin goes into a peaceful retirement!  

                                         

                                         

                                        Given Bryan's comments, the workaround I proposed is not an option for PI Totalizer, but I just confirmed that it works for the PI Performance Equation Scheduler. This is what I did:

                                        1. edited the !Proxy_127! trust, so that it is associated with pidemo (instead of piadmin)
                                        2. edited sinusoid's dataaccess and pointaccess to none for PIWorld (the settings were left intact for all other PI Principals)
                                        3. created a performance equation tag named soma_sinusoids, with expression 'sinusoid' + 'sinusoidu' and triggered by sinusoid
                                        4. started PI Performance Equation Scheduler
                                        5. observed the following message in the log

                                        Thu Mar 04 21:18:08 2010
                                        Pipeschd> Error -5: Event tag 'SINUSOID' not found
                                                Point ID 15: Tag 'soma_sinusoids'. Point will not be added

                                          • Re: Off - Topic Question Security and and a lot of people with managing tag - rights
                                            Daniel Takara

                                            Wolfgang,

                                            I just realized that the workaround I proposed does not fully address the issue you raised. In order to clarify better, let's use the following example:

                                            • a given tag named Fin-Tag1 is visible only to a PI user named Fin-User (i.e., dataaccess=RW for Fin-User, none for all the rest; ptaccess=RW for Fin-User, none for all the rest)
                                            • a PI Performance Equation Scheduler instance is configured with /ps=C and /id=99 and connects to PI with the priviledges of Fin-User

                                            If a user with RW access to the PI Point Database knew about the existance and configuration of the PI Performance Equation Scheduler instance above, he would just have to create a PI Performance Equation tag with pointsource=C, location1=99 and exdesc=Fin-Tag1,'Fin-Tag1' and then he would have (indirect) access to the values of tag Fin-Tag1...

                                            Therefore, if you see RW access to the PI Point Database for those 15 users and the resolution of the issue you raised as mandatory requirements, then perhaps you would have to stop using PI Totalizer and PI Performance Equation Scheduler.

                                            Furthermore, replacing PI Totalizer and PI Performance Equation Scheduler with ACE calculations is probably not an option to address this issue, as ACE is designed so that it is not possible to have multiple instances of the ACE Scheduler running different ACE calculations (note that I am not talking about ACE HA here). Instead, ACE is designed so that all ACE calculations connect to PI with the same priviledges (the priviledges of the only ACE Scheduler).

                                            It seems like a more viable option for now is to grant only a few administrators (which would be probably less than the 15 you mentioned, as they would be supposed to have access to the values of ALL existing tags in PI) with the priviledges to create PI tags, i.e., a more process-based than technology-based approach, as Bryan suggested.

                                        • Re: Off - Topic Question Security and and a lot of people with managing tag - rights

                                          Daniel Takara

                                          Rhys @ RJK Solutions

                                          On the topic of security, on PI server WIS have you noticed on fresh installs it is very easy to lock everything up...install fresh, remove explicit piadmin access, restart basess...now you can't change anything, even the localhost trust fails.
                                          Having not created any additional PI users (and granted them with the required priviledges to edit other users' settings), the only way I am aware of to recover piadmin from this situation is quite intrusive: restore a PI backup before piadmin settings were changed.
                                          Yeah, locking yourself up is an easy mistake to make in this case...

                                           

                                          There are a few ways around this (although this also is more of a Tech Support kind of call ):

                                          1. Method 1
                                            1. Run PI System Management Tools (PI SMT) and open the Connections dialog.
                                            2. Click on the Tools menu, and select Options.
                                            3. In the Connection Options dialog box, change the connection protocol order so that the connection will check for a PI Trust before using Windows Security.
                                          2. Method 2
                                            • Log into the PI Server computer as a Windows user for which a PI Mapping is not configured. This user should become the piadmin PI User through the local machine trust.
                                          3. Method 3
                                            • Use piconfig to create a new PI Mapping. You can edit the PI Identity table, PIIDENT, and the PI Identity Mapping table, PIIDENTMAP, to accomplish this. Please refer to the section Create a Mapping with a SID on page 49 of the Configuring PI Server Security manual for detailed instructions.

                                          Any of these methods will allow access to fix the security settings. OSIsoft recommends creating a PI Mapping between a privileged Windows group (for instance, Administrators), and the piadmins group or another privileged PI Identity you created. Please refer to the Configuring PI Server Security manual for more details.

                                           

                                          If you need further assistance with this, tech support is there for you!

                                            • Re: Off - Topic Question Security and and a lot of people with managing tag - rights
                                              Daniel Takara

                                              Hi Steve,

                                               

                                              I hope you don't mind if I follow up with the discussion a little bit here, but it's just that this puzzle is so interesting now...

                                               

                                              Steve Pilon

                                              There are a few ways around this (although this also is more of a Tech Support kind of call ):

                                              1. Method 1
                                                1. Run PI System Management Tools (PI SMT) and open the Connections dialog.
                                                2. Click on the Tools menu, and select Options.
                                                3. In the Connection Options dialog box, change the connection protocol order so that the connection will check for a PI Trust before using Windows Security.
                                              2. Method 2
                                                • Log into the PI Server computer as a Windows user for which a PI Mapping is not configured. This user should become the piadmin PI User through the local machine trust.
                                              3. Method 3
                                                • Use piconfig to create a new PI Mapping. You can edit the PI Identity table, PIIDENT, and the PI Identity Mapping table, PIIDENTMAP, to accomplish this. Please refer to the section Create a Mapping with a SID on page 49 of the Configuring PI Server Security manual for detailed instructions.

                                               

                                              Well, in the situation I proposed, I think these 3 methods would not work, as piadmin could not be being used in PI Trusts and PI Mappings (and no other users had enough priviledges to revert the piadmin settings). This implies that no connection could be established using the trusts and mappings associated with piadmin.

                                               

                                              Steve Pilon

                                              OSIsoft recommends creating a PI Mapping between a privileged Windows group (for instance, Administrators), and the piadmins group or another privileged PI Identity you created. Please refer to the Configuring PI Server Security manual for more details.

                                               

                                              Yes, granting certain Windows accounts (the ones that belong to trusted administrators) with the priviledges of the piadmins group (via PI mappings) and making sure that the piadmins group has proper, required priviledges would be a good measure to avoid the "dead end" I mentioned.

                                               

                                              Bryan

                                              @Dan - currently from the system console you can use piconfig to re-enable authentication methods for any identity.  Recovery scenarios will be considered as work on inside threats progresses.

                                               

                                              Hi Bryan,

                                               

                                              Thanks for your comments on pitotal and pipeschd!

                                               

                                              Regarding the use of piconfig as you, I think it would probably work, unless the CheckUtilityLogin tuning parameter had not been changed to something different than 0. In case I ever find myself in such a dead end (and restoring PI from backup is not an option), I'll make sure to open a TechSupport call.

                                            • Re: Off - Topic Question Security and and a lot of people with managing tag - rights
                                              Bryan Owen

                                              @Dan - currently from the system console you can use piconfig to re-enable authentication methods for any identity.  Recovery scenarios will be considered as work on inside threats progresses. 

                                          • Re: Off - Topic Question Security and and a lot of people with managing tag - rights
                                            Bryan Owen

                                            Fair comment.  Of course not a turn key CMS, but in my observation customers simply wrap a workflow procedure around SMT Tag Configurator.  Such a low tech solution is quite effective and easy to implement. 

                                             

                                            Note, this is especially effective for PE expressions.  For instance, request to build a PE should come by way of a worksheet that proves the PE works using Datalink.  Since Datalink connection is not using piadmin, attempts to use protected tags in expressions will fail.

                                             

                                            Interfaces are more difficult to validate instrumenttags and other settings. Automatic Point Sync (APS) is able to automate configuration management on a interface instance basis. You could argue that APS shifts the CMS burden to the source system, fair enough.  APS is open enough to support a master database based on typical relational technologies...thus not limited to only those interfaces with specific plugins.

                                             

                                            That's about it for turnkey solutions.  There are certainly plenty of tools for configuration management. Custom built has been the approach adopted by the truly large servers and fleets of servers I am aware of.

                                             

                                            Again, I'm not trying to trivialize your situtation.  Managing a large number of interfaces is certainly an area we want to improve. I do hope you get peer feedback, it will be interesting to hear about solutions used in this situation.