When it comes to securing PI the best it can be secured --
well, you will notice that a lot of what the
discussion is about is about closing
off things that we used to do. So, this is one of those instances
where, if you are just implementing PI
for the first time, you are in luck. All of the recommendations
we have are going to go much easier for you since you do not have any
of our Legacy mechanisms for doing security.
But, basically, what we are going to suggest you do is
to make sure you disable any explicit
logins using the regular username and passwords
or the traditional user and passwords from PI do not allow any
users, under any circumstances, to use
piadmin or to map to the piuser called
piadmin. Instead, we suggest you create a new identity,
and we will go over that. We will suggest you create
Identities and Trusts for interfaces that have the proper
write access. In other words, we have relied too heavily
on just using piadmin as a general,
a general connection that can write to everything.
But we suggest that when working with interfaces you do not do that,
and we will go over that. Also, we suggest you disable
PIWorld, and I will show you where to do that in the Database.
We suggest you secure all of your
utilities with something called Check Utility Login. And
finally, we suggest you disable SDK-based
Trusts. A lot of this discussion's going to be around
how to kind of back off some of the earlier implementations
of PI Security. And, of course, when you do that, you want to do it in a way
that does not disable anybody who's currently
connecting, and that can be tricky. That's why we
do not attempt to do this automatically for you. We have been
looking at this PI Server Security document because
this is where, I guess, our best recommendations can be found.
You will find that on our tech support website.
The first recommendation is to disable explicit logins.
And what you will notice is that's something that actually shows up by
default when you install the PI Server.
It's one of the options is to
disable the password authentication for PI
Users. See, since we have gone to Windows Integrated Security
there's really no need anymore to use the traditional PI
User and password. So that's something we suggest
you do initially when you install If
this is a brand new installation, not if it's an upgrade, though, because
if it's an upgrade, disabling that may
hurt your existing Users. If you need to
disable Users, or in order to disable Users like that,
the explicit PI Users, what you would do is go into
this Security Settings here under PI
SMT. So, we are running PI SMT.
Under Security Settings it's this right here that
we are going to disable, this Explicit login disable.
And that will disable the traditional PI Users
and Passwords you may have configured. Again, go slowly
when doing this. This is not something that you are going to want to do without
giving a lot of consideration to people who may already be using
that. It's not something I would do, you know,
three o'clock on a Friday. You may want to do this,
for example, during a, a, planned maintenance
shutdown anyway. So, just not at, not at
a time where people are going to be
greatly inconvenienced if you accidentally disable them
from logging into PI. Now, what's it mean if you
do disable them from logging in using their traditional
User and Password? Well, it means that before you do that
you'd better have the alternative ready. And the alternative
is what you will find described in our other videos
on Windows Integrated Security. So, that's what we suggest you do
first. And, basically, this means all connections
to PI from Users should be done using Windows
Integrated Security. Again, my apologies
to those of you who have been with us for a long time and you have got
all this infrastructure built in with all these other
mechanisms to connect. You know, it's like that with high tech
stuff. The last guy in tends to be the guy who has the easiest,
easiest road here, and if you have
just bought PI for the first time, you implement
Windows Integrated Security from the start, it's going to be a lot easier than somebody
who's migrating forward. The latest
and greatest stuff tends to be better than the stuff that came
before it, and not just be a little bit. Now what's
implicit in this suggestion is that we suggest
you no longer use this PI User
called piadmin. We suggest you do not use
that User for anything anymore. Instead, we
suggest you create a new Identity.
You can -- like this one right here, PISupervisors. This is an Identity
that's associated with the, you know,
having some kind of supervisory permissions.
You would set that up as an Identity. You would
map it using whatever mappings,
you know, will map the, the, the people who are
Windows Users who should have access to this. You would go ahead and set up
your mapping to Active Directory Group or a
Supervisors. And then once those Windows Users
are associated with this PISupervisors, then
under the Database Security, you would just
make sure that all of the things that the
piadmin user had access to. So, for example,
if you look at piadmin, he's the, he has read-write
access to the Point Database.
You just make sure that PISupervisors has
that same read-write access. So, in the
attempt to, you know, kind of get
away from using piadmin, at all,
you would use this PISupervisors, or some other,
you know, some other Identity
of your own choosing. So, I will go ahead and create that.
And I will go through, and for all of those
databases, really all of the databases that you see here,
you know, let's -- the Digital State Database,
etc. -- all of these, you are going to add that
PISupervisors. And then, that would be what you would use
instead of the piadmin that has
traditionally been used to grant access to all these different
databases. Now, another thing we suggest is
to make sure that when you are configuring Trusts,
you configure those Trusts so that they
connect with Identities that are other than
piadmin. Let me show you what I am talking about.
And, and I have to confess, we are kind of guilty of this, of
making this recommendation in our training. If you look
at some of our training material, we tend to make
shortcuts, sometimes, when we create
interfaces and the trusts that go with those interfaces.
We make shortcuts by just configuring
a Trust that maps to this piadmin user.
And, in fact, sometimes, I mean sometimes we will even --
you will see our, our, our field service folks will do this
just to get things working, and then they will, later on,
tighten up security. So, that's not
really the best practice. We do not suggest you should
use a Trust that connects and gives
you the privileges of piadmin, because piadmin can do everything.
So, if, you know, if somebody
happens to get on that machine that's running an interface
and he, in the Trust, is not secure enough, you
may end up having somebody who can get access in ways that you
do not want. So, what we suggest instead,
is that you explicitly configure
a PI Identity
that is just for
that interface. Now, we actually do that in, in the videos
you will find in, in this particular
series of System Management, you will find that in
configuring the OPC Interface we did tighten up security eventually.
We created an Identity called PI_OPCInt,
and then we ensured that
PI_OPCInt had privileges, only privileges
required, which is the privilege to write
to the Tags that are collected by the OPC Interface.
So, make sure you have created that Identity and
then, when you create the Trust -- here's our Trust right here, PI OPC
Interface. Make sure that you are
associating that Trust with that Identity, not with
the piadmin user. Now, one more thing we suggest
is that, if you really want a secure system, go ahead and
disable this PIWorld Identity.
Now those of you who just saw our video on
Windows Integrated Security may say, hey, hold on a second.
Did not we just demonstrate that?
Because this PIWorld Identity exists,
that's why any Windows User
who is mapped to any Identity can see the system.
And, and, that is correct. That's traditionally been how
people connect to PI. But, if you want it to be more secure
than that, if you want to only allow
access based on named Identities and specifically
allowing or disallowing access to each and every
one of the, you know, the objects within PI,
all the different Points, then you
might want to consider disabling this PIWorld Identity.
Just go in here and choose to disable that.
So, again, it's, it's not something
you should do casually. Just give a lot of consideration
before disabling PIWorld. And, again, do not do it during
a period where it's going to inconvenience a lot of people if you
happen to get it wrong and need to scramble a little to get
people access. Now, another recommendation
is to use what we call the
Check Utility Login Setting. This is under
Operation, and the Tuning Parameters.
You will notice a Tuning Parameter called Check
Utility Login, and what this does is it
requires that people will
have to log in when they use
any of the Command Line utilities. See, right now,
the assumption's always been that if you are at the Command Line
on the PI Server, then being at the
Command Line basically means you are king of PI, you can do whatever you want
within the PI System. This will change all that.
This will require explicit login.
So, before you can do any one of these
interactive console utilities like piconfig, pisetpass,
etc. It does require a system startup
in order for that to take effect. You would just go in
there and change that Value
to a one. Now, if you have been working with PI for a
while, you know that if you create Trusts
for allowing SDK-based Applications
to connect to PI, you actually have better
credential checking than if you create a Trust that's
based on the API. But, even though the
SDK-based Trusts are stronger than the traditional Trusts, the
API-based ones, they are still not as strong as the
Windows Integrated Security. So, what we do suggest is
you go into your System Settings, under Security,
and you disable that.
Now it does mean that now, explicitly, you are going to have to make sure
that you have got, you have got
all those things that do need to
connect are connecting using Windows Integrated Security,
not these Trusts that are set up for SDK-based
applications. So, any interfaces that are
connecting using the SDK, any
user applications connecting using to the SDK,
you are going to have to make sure you set up PI Identities that will allow
the connection based on the Windows Integrated Security.
You know, based on the Windows User that
maps to those PI Identities. Now since I mentioned
Interfaces, and starting those Interfaces, and using Windows
Integrated Security, I feel obliged to remind
everybody how you would go about doing that for a Service.
I am over on an Interface Node right now,
and I am running a little Services Applet.
Let me bring that onto my screen here. In the Services Applet
you would just specify the logon
as Option for your Interface. So, for example, here's my
OPC Interface. If I go in here
to the Logon Section, this is where I would
specify a specific Windows User that
would be associated with this Service when it starts up. So,
this is where you would specify the Windows User
whose credentials we are going to use in Windows Integrated
Security to, you know, associate
this incoming connection with a specific
PI Identity that has the proper permissions.
So, again, in summary, a lot of what the
tightest security involves is really just kind of eliminating
some of the Security Options that you had in previous versions of
PI. Starting with Windows Integrated Security is, is probably
the best way you could get started if you are
just brand new to PI. So, hopefully, you will not have to
back off of a lot of things. If you are backing off
of a lot of previous mechanisms for connecting,
one of the things I suggest is, go into the piadmin
user itself that was used so,
you know, so much over the years for people to
be granted access to PI, that if you
would go in here and start turning off some of these things --
turning off its use in a Trust, not allowing anybody
to create a mapping that maps to it, etc., You know
that, that would be a good way to
ensure that you have, you are definitely not using piadmin
for any of the things that,
well, really, the piadmin should no longer be used for,
like allowing it to be used in an Interface Trust,
or allowing people to explicitly log on as
that piadmin user, or likewise, to map
to that piadmin user, 'cause he just has too many privileges.