Where are we currently at with the PI Server supporting IPv6 in Trusts and the PI Firewall? Is it coming?
The current status is described in this KB article. There is a known issue with IP-based trusts, and it suggests some workarounds. If these are not possible in your environment, feel free to follow up with me directly (or through Tech Support) and we can try to find a solution...
Thanks, Jay. Read that article but it doesn't give anything away on how this is going to be addressed. Let me ask something else related to this, are PI Trusts & the PI Firewall always going to be around as security mechanisms for the PI Server?
I'm engaged with TechSupport over a possible AF + IPv6 issue, but it got me thinking about the PI Server with IPv6 becoming the norm. I can't believe the number of people (on internet, in person, ...) who say "just disable IPv6" to get products working.
Let me first state that IPv6 is fully supported on the PI System, with the exceptions noted in the KB article. We will continue to test and support IPv6 going forward (this is a stated non-functional requirement for our active products).
You ask a fair question about PI Trusts and PI Firewall. Our position is that Windows security (WIS) is recommended, and PI Trusts should only be used when necessary. Of course today PI Trusts are required for most PI Interfaces (since they are based on PI API). However, PI Clients and most PI SDK/PI AF SDK based products should use Windows security. Hopefully folks are moving towards WIS or planning their migration especially as they upgrade to PI Server 3.4.380 and later. Basically, we are trying to recommend best practices for securing your PI System (or point out potential risks)...
It is difficult to provide a forward-looking statement regarding the future of PI Trusts and PI Firewall. I would say there are better security mechanisms available and we would strongly recommend you consider using those instead.
If I said anything incorrect, I am sure that Bryan Owen will chime in or our new Security PM, Jim Davidson (formerly of INL, who some of you might have met at vCampus Live! in past...
Totally agree with WIS, and it is always implemented on projects I am involved in where possible. Actually WIS implementation on the PI Server got me thinking (dangerous, I know) and my thoughts landed on the principle of least privilege. Say you have a Windows Account that is granted basic read rights on some PI Points via a PI Identity through a PI Mapping. If that same Windows Account is a member of a Windows Group that has Write Access via another PI Identity to some of the database tables then you have 1 Windows Account with 2 very different privileged PI Identities associated with it. Did OSIsoft ever consider requiring a connection (via API/SDK/...) to explicitly request the elevated privilege(s) from "more powerful" PI Identities? It would mean certain permissions on a PI Server would naturally be classed differently to say data access type privileges. I guess a bit like UAC in Windows; just because you do have the privilege doesn't mean you can just go an use it without some security checkpoints for certain activities.
I am most interested to hear what changes are coming for PI Interfaces, second time I have seen some hints in changes to them in as many days...hmmmm...MDA?
The scenario you describe is documented in the Configuring PI Server Security manual. Here is an excerpt under "PI Server Access Permissions and AD":
Users that belong to more than one AD group get the cumulative access permissions for all the associated PI identities. Similarly, users get the cumulative access permissions for all parent AD groups (for nested AD groups).
The diagrams and examples in the manual are helpful for understanding what that means...
Yes, you will hear a rejuvenated message on PI Interfaces at UC 2012. This is a (renewed) strategic focus for OSIsoft and we will share with you what we are planning going forward.
Isn't the cumulative access permission instant though? You get everything as soon as you connect. Rather than getting all the keys to open all the doors you need when you enter the building, you only get the key that lets you do the least. You then explicitly ask for the key(s) to get in the other doors to the higher levels of the building as and when you need to. (Bad analogy I know.)
So if someone cracks a Windows Account then even though they now have access to read data (the least privilege mapped), if they then want to do anything more malicious they need to pass the elevated privilege request - how that elevation would work I don't know, just thinking out loud.
Do you guys ever get nervous about only offering WIS for the PI Server? Sometimes it feels more "safe" to say that this Windows Account/AD Group is mapped to this PI Identity, but only if the authentication comes from these nodes or IP address range. Or would the assumption be that the Windows Accounts are controlled outside of the realm of the PI Server?
I'll put a caveat up front - you're starting to get into an area where I'm far from the expert. I'd be interested to hear from our Cyber Security folks, or other customers/partners who are much more knowledgeable in this area. Ok, now that I got that out of the way, I'll say that yes, we do realize that WIS isn't a one size fits all answer. There are scenarios where it just won't fit (at least not well), and mostly those are because of IT policies/standards, or current configuration of the system. That's not to say those are static, but implementing WIS in these environments can be more change than someone initially anticipated. Of course, like anything else, the end result is that you get out of it what you put into it. In this case that is usually a more secure system if you follow our recommended best practices. This is also why we went to a model where we're relying on the OS to provide the security infrastructure. We're not in the business of building authentication mechanisms and we try to leverage technologies from Microsoft with the intent to offer tools and guidance so you can deploy the most secure PI System. To answer your question, yes, we have heard those types of rules (or similar ones like password expiration) which is why we suggest that AD is the best place to manage them.
I suppose I am drifting in to the area of claims based security, as what I have been thinking in the back of my head is that not everyone that may want to connect to a PI Server (or AF Server) is going to be running on Windows or authenticated via Active Directory within the same domain. However the connecting users from a 3rd party may have an agreement to consume certain data on a PI/AF Server, or a device/users needs to read data from a PI Server running within a cloud service; IP based trusts are not always the right answer IMO (which is what I was getting at earlier asking if PI Trusts will always be around). I can see what you are saying Jay, that you want the hosting environment of the PI Server to handle the "trust" between domains or enterprises, and the PI Server simply deals with the claims of the connecting user to provide authorisation...which I get now. Never given much thought to claims based security (Security Token Services, ClaimSets, Claims, ...) before but it is an interesting topic, especially for PI in the Sky (PI integrating with a federated identity model)
Is claims based security on the roadmap these days? How about one of the cyber security folks talks some more on claims based security for the PI & AF Server.
Rhys, it sounds like you know more about security than you claim (sorry, bad pun). Yes, we have done some research into claims-based authentication. It would probably be best to have a 1-on-1 conversation with our Cyber Security guys (maybe start with Bryan/Jim). We will have a Security pod at UC which is a good time to have that conversation over a beer!
Jay LakumbRhys, it sounds like you know more about security than you claim (sorry, bad pun).
Rhys, it sounds like you know more about security than you claim (sorry, bad pun).
That made me laugh whilst reading it on my phone...my wife said "what's so funny"...I contemplated explaining it but it would have lost all humour doing so...
Jay LakumbYes, we have done some research into claims-based authentication. It would probably be best to have a 1-on-1 conversation with our Cyber Security guys (maybe start with Bryan/Jim). We will have a Security pod at UC which is a good time to have that conversation over a beer!
Yes, we have done some research into claims-based authentication. It would probably be best to have a 1-on-1 conversation with our Cyber Security guys (maybe start with Bryan/Jim). We will have a Security pod at UC which is a good time to have that conversation over a beer!
Won't be at the UC but will catch up with Bryan or Jim at the next event or offline. I guess it would be a good solution to buffering identity issues too.
Retrieving data ...