Today we are going
to draw a high level map of the mechanisms
we use to configure PI Server security.
PI Server security allows us to
control who or what gets access
and to tailor these permissions in a
manageable way. Why do we even care about
security? Well our PI Server specifically
our Data Archive component stores very important
data. Good security allows us to make
sure that our data is always available and that
we can confirm the integrity of our data.
Keep in mind we aren't only safeguarding our
PI data but potentially access to other systems that our
PI Server has access to.
Let's focus on the Data Archive first. And
the model that I'm outlining, this is available
starting with the Data Archive Versions
3.4.380.36 and later.
At your organization you have different groups of
users who interact with the PI System.
And for example maybe you have a
group that's your process engineers.
And maybe there is a few individuals that
are actually responsible for leading the process engineering team.
You also might have applications
that read data from the PI
System like PI Coresight. Or write data to it
like PI Interfaces.
These users and applications all have different
needs. What we want to do is tailor
their permissions to exactly match up to these
different needs. To do this, security
on the PI Data Archive is configured
on different areas or levels. And basically
each area governs specific
tasks. And having specific permissions on that
area controls who or what can do these tasks.
Trying to specify individual
user permissions on all of these different
areas would be really difficult to manage.
So we focus instead on setting permissions at a group
level. And we do this with PI
Identities. PI Identities are used to represent
different user groups and they gave
assigned specific permissions to these areas.
Essentially each PI Identity
represents a set of access permissions.
Now there are default identities
pre-built on the system like PI
Supervisors. And you can use the default PI
Identities but what you can do is you can customize
them. You can create your own PI Identities
that exactly match the groups at your organization.
For example if your organization
has a process engineering group,
you can create a process engineers PI Identity.
You can also create other identities
both for your user groups and for your applications.
And then you just need to set the
PI Identities permissions on the different data archive
areas that match up to these group's roles.
We also need a way
to link these Windows groups or
accounts to their corresponding
PI Identity. And this is exactly what mappings do.
In a mapping we are simply stating that
this Windows Active Directory group or
account equals this PI Identity.
And you can see
that leveraging groups is going to make
things easier to setup and maintain.
If I wasn't using a group, for example
I would have to create three different
mappings for the process engineering leads
instead of just a single mapping for the group.
Mappings are also used
to link applications to identities. You
just need to specify the
account that the application runs under.
And that equals the PI Identity.
You can see that this allows us to
really tailor our permissions. We have our
users and our applications and
we have corresponding PI Identities for them.
The users and applications get mapped to
these PI Identities through our mappings. And the
PI Identities are the ones that have access on the
different areas. So it's a simple
matter of using the mappings to authenticate
and having PI Identities
that are authorized to do specific
tasks. The only exception to this is
PI Interfaces. So for PI Interfaces,
we need to setup trusts. And with a
trust we specify the computer
that the interface is running on.
And we also specify its application name. And
a simple rule of thumb, you can
just remember that trusts are for PI Interfaces
and mappings are for everything else.
Both our users and our applications.
So we've been focusing on
the data archive but the asset framework component
on the PI Server is very similar. With the
asset framework starting with versions
2.7 and later, there are also mappings
and identities. And you can use these to set
permissions on the different areas in the Asset Framework as well.
Make sure to check out
the rest of our security videos to see how to set this
up in your PI System today.