Guarding Data on CIFS Servers and Clients

The Common Internet File System (CIFS) is a well-known and widely-deployed distributed file sharing protocol for Windows. *NIX (Unix/Linux-like operating systems) offer support, to share a directory with Windows, via SAMBA.

Note

This topic is not about CTE Live Data Transformation.

You can guard data on a CIFS share:

• On the Server side of the share (WIN and *NIX)

• On the client side (WIN client only)

Guarding on the Windows SERVER side of a share

Guarding on the server side is supported for a local Windows volume drive (i.e. E: or local directory (i.e. E:\gp). After which you can share the CIFS share out to another Windows server or client. Do not guard the share on the server side and then also on the client side. This will lead to double encryption and other problems.

Guarding on the Windows CLIENT side of a Share

You can guard server share on the client side, independent of the server side. The server side can be Windows or *NIX. For either the server or client side OS, the GuardPoint must be a File System that CipherTrust Transparent Encryption supports guarding, which is most typically a native FS.

PROS

• Data sent over the channel is encrypted by the agent, above any channel protocol encryption.

• GuardPoint policy sees the processes on the host accessing files.

CONS

• More agents required, one per client, than guarding on the server side.

Proxy GuardPoint

Guarding on a client, and then exporting that client to another server, is not supported.

Guarding on the *NIX Server side of a Samba share

Guarding on a mounted CIFS/SAMBA share on *NIX is not supported. Use NFS to guard on the client side.

Whenever you are creating a GuardPoint on a CIFS share, you have two options.

1. Install CipherTrust Transparent Encryption agent on the CIFS server. Then create a GuardPoint on the network share. Have users connect remotely from their systems to the network share.

2. Install the CipherTrust Transparent Encryption agent on all remote user computers and again create a GuardPoint on the network share.

Note

• When creating a GuardPoint, do not use the share mount point \<serverName>\share$. You must create the GuardPoint on a sub-folder of the mount point \<serverName>\share$\folder1

• In the policy, you must create a UserSet for remote users accessing the network share. This UserSet must be linked to the ProcessSet for ntoskrnl.exe (Windows Only). Then grant the user Permit and Apply_key permissions.

• If a user that is logging in with UserPrincipalName (xyzuser@thales.com) is accessing the share folder, then the UserSet must contain the UPN. If the remote user logs on with a sAMAccountName(jharriman), then the UserSet must contain the sAMAccountName.