Since we are in the middle of talking about
security, this would be a good time to bring up something we have discussed
in some other videos, the videos called PI
Trusts, also the videos on --
there's a long sequence on Interface Installation and
Configuration. We mention that there's
a special way you need to really treat
Trusts for Interfaces. We
suggest that Trusts for Interfaces be configured
such that they are associated with an Identity,
like this one right here, that has
permission only to write
to the Tags, you know, of that, that are
collected by that Interface. Now that is,
as opposed to a practice that used to be very
common, and we even used to recommend sometimes,
and that was the practice to associate
these Trusts with piadmin. Now,
as you have seen in our discussions of,
of security, we, we really do not
recommend you associate things with piadmin. I mean, here's,
here's a Trust, for example, that allows Perfmon Interface
to run remotely connecting as piadmin.
Well, that's not a real good idea.
I mean, technically, some joker could sit down, write
a little Windows application that uses that as
its, as it's process name, and as long
as he can install it somehow and run it from this machine,
then he's going to have full access to PI.
And, of course, that's not a good situ...scenario.
What we suggest instead, instead of giving people
full access through piadmin, instead,
when configuring these Trusts, you configure
them to connect to, or to connect using
an Identity that only has limited permissions,
like this one right here. So, you create your
own Identity and have that associated specifically with
that, that Trust that's associated with the
Interface. And, that would go for all of the
different Trusts that are required for that Interface, so
if you have got an older Interface that uses both the API
and the SDK, we would suggest
two Trusts. You know, one for each, API and
one for SDK, both mapping to that same.
That same Identity. And then,
also, for any of the other programs that are running on that
machine -- for example, if buffering is running
on that Remote Node, set up a Trust
that uses, again, that same Identity
so that you are only giving permission
to write to the Tags that need to be written to by that
computer. Now, when you create these Trusts,
just make sure you create these Trusts that
are, in a way that's restricted. In other words, it's
not a bad idea to restrict it
both to the name of the application and the IP Address.
It's much, much better than a liberal Trust that's
simply, for example, requires something like
this. That would allow any application, regardless
of the name coming from that computer,
to have the permissions of this Identity. That's not a good thing,
no. It would be better to specify
more than one criteria.
And that would go for any of the Trusts that are
running on here. Make sure that you specify
both either the IP or the Network Path
and the Application Name. Now,
one last point, and I would like to demonstrate this
with an example, is that you may have some Trusts
that we have not discussed so far anywhere
else in this class. And that would be a Trust that's
required for things like Interface Configuration
Utility running on that remote machine.
See, the Interface Configuration Utility
running on a remote machine -- let me show you this, again,
on our, on our remote machine here. It has to
run on a remote machine
because that's where the Interface Files are stored.
I go into Interface Configuration Utility here.
Yeah, there we go. But see, the first thing that that
ICU application does
is it goes out and it reads from the PI
Server, it reads the List of
Interfaces that are stored in the Module
Database. That's actually where we keep the Interface information
for right now. So, that information's being read
from the Module Database. Well, if you make
configuration changes, you are going to need to write back to the
Module Database. So, that means that you are
probably going to need -- well, you will. You will need a,
a Trust that grants this ICU Application
permission to write to the Module Database.
Now, let me
describe how you would do this. You would do it the same way as we have done these
other Inter...these other Trusts.
You would configure a Trust in which you would
make reference to an Identity, not piadmin.
Again, that's sometimes what, way people handle this. Sometimes
they will just put piadmin in there. But, you want to use
an Identity that only has permission to write to the Module
Database, and that's all. So, we name
this by IP Address. We name it by
its executable, PI ICU. That's the name of the
executable for Interface Configuration Utility.
And then we associate that with this For_ICU.
Now, what does For_ICU
get to do? If we take a look at this Identity,
For_ICU --
Well, first of all, it's, it's going to have to be
associated with some kind of a,
a Windows User, so it does have to be
Mapped to a User. That's a requirement in order
to write to the Module Database. Just
point that out in passing. But what For-ICU,
the identity's going to be able to do is
it's going to have permission to write to
the Module Database. So, I need to go in here
and add For_ICU
as a, you know, an Identity that has permission
to write. Now, because that
For_ICU Identity is actually mapped to an
Identity, and, and defined in a
Trust, then it will get the,
pick up the permissions of PIWorld. You know, anything that
maps correctly through a Trust or through an
Identity to the PI Server will
get the same privileges as PIWorld.
So, what you will notice when we actually try this,
is even though he does not have permission to write,
he does have permission to read. So that's why,
when I launched ICU earlier,
it was able to go out and read.
But, if you will notice, if I go to try to change
any of these things, I, I cannot change them.
I cannot make any changes to any of this
because it's basically locked
because it's in read only mode. So, let me close out of
this. Let me go back to my Server
and let's actually give this the permission it needs under PI
Modules. I will add For_ICU
and
I will give that For_ICU, I will give that read-write
access.
Now let me go ahead and go back. Log into
ICU again, or login using ICU,
and this
time with read-write access, we should have permission
to read, and then once we read this in here,
now we should have permission to write back. So, if I need to go in
and change this timeout, so you can see, now I can go ahead and change,
make those changes. So,
that's the dem..., that's the demonstration of, of basically
what you are going to require if you
have these other Trusts for things like ICU,
or PI SMT run remotely. You know, just
make sure that when you create those Trusts, you do not
simply just default those Trusts
over to -- you know, you do not, you do not
want to have those default to piadmin.
You'd like them to go to a User that's
been defined, or an Identity that's been defined, with only
the minimum permissions required.