Access can be achieved via browser-enabled agents, or on mobile devices through a Netskope gateway. When a mobile device is under control (e.g. routed through the gateway), maximum features are available, we found. When an unmanaged device is used for access, it’s up to administrators to determine by cloud app, if access is allowed, and if possible (by features of the cloud resource) what accessibility will mean in terms of control and access.
Gateway interactions come usually via the SecureForwarder VM/software appliance, but since it is based on Ubuntu Server, it can also be deployed as a discrete server. We installed the SecureForwarder appliance in our testing. We found the docs a bit wanting, but were able to eventually connect the SecureForwarder to our cloud test resources via Active Directory Federation Services and Windows WSAdmin. This said, Netskope seemed eager to help us.
Many supported cloud apps can have additional DLP rules applied to them, including an important one: if we can’t inspect the data, invoke a rule to sequester/jail the payload to be dealt with by an administrative type (of which there are three levels). This might be at a file level, or at a field level, or we found designed-in using FINREG or HIPAA data field examination, including “something like this, near something like that” logic. The possibilities are extensive, and administrative time sunk into astute design will likely pay well. We found filters understandable to design and deploy.
In execution, Netskope Introspection is a highly programmable administrative bot-like proxy process that scans supported applications for data using aforementioned DLP rules and triggers specific to the supported cloud app. As it doesn’t have quite the encryption power of CipherCloud, it does have very flexible rules that will be familiar to Unix/Linux programmers.
After installing the SecureForwarder VM onto a VMware substrate, we connected our Active Directory, and also WSAdmin services for Office365 cloud services. It’s a simple, three-step process. Client access was transparent; we did this through a browser agent which proxied an Office365 connection. When we had installed Secure Forwarding services, we constructed the platform to a supplied Ubuntu-based VM with three ports: management, input/ingress, and output/egress. DNS infrastructure needs to be in top shape for the scheme to work.
Once communicating with the Netskope portal, it’s possible and normal to have Netskope examine local log files, from which it extracts information about app communications, sources and most destinations. It’s now an interloper, forward or reverse proxy as the destination app needs.
Steered traffic can be “introspected” for apps Box, Google Drive, One Drive, SharePoint, Dropbox, Salesforce, Egnyte, and Service Now. We saw no delays, but we didn’t hit it with 2,000 concurrent diverse power users, either, and our net connections are fast. Their cloud-based proxies are load balanced, and can be homed to specific GoSkope processing sites based on speed, or by jurisdiction.
Sign up for CIO Asia eNewsletters.