“Sealpath provides a flexible, powerful and performant SDK, which is the ideal solution to guarantee that sensitive documents can be issued without risk. We have integrated Sealpath security in our HR application very quickly. In addition, their technical support was highly responsive and helpful, which was also a big plus“.
Arnaud Guillet, IT Chief Technical Officer, Dietsmann
Often in the company, we find proprietary applications where sensitive information of different types is stored. For example, in the field of medicine, applications where patient data, medical records, etc., are stored, which have the possibility of exporting the information to Excel or PDF format for later sending, printing, etc. Another example are document managers, which have been customized to better manage the company’s workflows, and where critical financial data, customers, suppliers, etc. are stored.
To comply with certain regulations such as GDPR, or if we simply wish to have greater control over this stored or exported data, we may find it necessary to modify these applications to add encryption, or more controls to manage the information securely. These modifications are not trivial and may not reach the level of control we want. On the other hand, changing applications, document managers, etc. is not an option either, since it has taken time to adapt them to our workflow and the cost of the change may be excessive.
SealPath, is a data-centric information protection and control solution that allows protection to travel embedded with your documentation. The data is encrypted and you can monitor who is accessing, when they are accessing, if someone is trying to access without permission, etc. regardless of where the files are located: In the company, at an employee’s home, on a supplier or customer’s network, etc. The protection is dynamic and we can modify it in real time to give more or less permissions, or even, revoke completely the access to the document if you stop working with someone.
How can SealPath help us if we want this type of protection on our systems?
Through the SealPath SDK, we can integrate this persistent data protection into our corporate applications, so that when information is exported, or stored in certain folders in a document manager, it is protected and moves under SealPath’s control.
SealPath offers two types of SDKs for integration into our applications:
- Local Protection SDK: This SDK is based on C#/.NET and allows the protection of information in local applications running on a Windows computer or server.
- REST API: In this case we can use different programming languages to call the SealPath API that can be executed in a remote server and different from the one we have running the application we want to integrate.
How do these SDKs work?
Local Protection SDK
The Local Protection SDK is a library that provides functions to create and delete identities, to obtain a user’s protection policies and to protect and unprotect files with these protection policies.
The Protection SDK needs to be installed on the same SealPath Desktop or SealPath File Server machine. The SDK function library calls the SealPath Resident service on the machine, which will perform the actions.
The file is protected locally and does not need to be sent or travel to a third server.
User policies are managed with SealPath Desktop or the Web management interface on the machine where the SDK is running or on any other machine. The SDK only obtains the list of policies that the user can apply, it does not perform any additional management with them.
User identities must be registered with the organization’s web administration interface. The registration is done by importing the identities from the corporate Active Directory or by registering users in the system’s DB.
SThe REST SDK API is based on a client-server architecture that communicates through HTTPS requests and responses. It gives access to different operations related to the creation and deletion of user identities, obtaining protection policies and protecting and unprotecting files using these policies.
The big difference with the local protection SDK is that in this case the file must travel to the REST server to be protected.
The REST API SDK client can be developed in any programming language. Once the server interprets a request, it creates an HTTPS response with JSON data located inside the body or in the headers. API commands can be easily implemented with applications that send HTTPS requests and capture their responses.
The REST API server must be installed on a machine where the SealPath for File Server engine or service is installed. The REST API server communicates with the SealPath for File Servers service that makes the necessary requests to the SealPath protection server.
User identities must be pre-registered in the SealPath system and managed through the SealPath Web Management Console. The REST API service does not perform any user registration in the organisation.
REST API can work at the authentication level with OAuth 2.0 protocol, to make the communication secure. A client application first needs to obtain the access token that allows it to access REST API functions. To obtain this access token, the user must obtain and use two parameters: the “clientId” and the “clientSecret”, in order to later call the protection, unprotection, etc. functions of the REST API service.
Protection Use Cases through SDKs
Let’s suppose that we have a documentation repository where different types of files are stored: information on offers, product specifications, balances, documentation, personal data, etc. This tool can be a CMS (Content-Management-System), an ERP, CRM, etc. Users access them through a web interface, file synchronization application, etc.
This repository has its security mechanisms only certain users or groups of users are allowed to access the information but once the documents are downloaded or leave the security context of the repository, control over the documentation is lost.
The following types of integration can be done through SealPath protection SDKs.
1. Protect the documentation when it is uploaded to the repository
This case is recommended for cases in which we are interested in storing the information in an encrypted form. It can be for compliance requirements, for example. Also when the information uploading mechanism is controlled at one point and there are not many ways to upload the documents to the system.
The communication flow in this case would be:
- The user, through his browser uploads a file to the application.
- The system intercepts the file upload and makes a call to the local SDK or SealPath protection REST.
- The file is protected at that moment and is stored protected.
- If a user downloads later, this file will remain protected and under SealPath control.
2. Protect the documentation when it is downloaded from the repository
Recommended when we are interested in having the information unprotected in the repository to which other tools such as viewers, applications that load data, etc. can access. Also when the application for example generates automatically documents from a database to download them to the users’ computer.
The protection flow of a file in this case would be:
- The user accesses through the web application and decides to download a file.
- The system intercepts the download operation and makes a call to the SDK to protect the file being downloaded. The file stored in the server remains unprotected.
- The file is protected and continues its course until it reaches the user’s device, being now under SealPath control.
3. Protect the documentation stored in the repository
If we have different ways to upload or download the application, such as through a web interface, local synchronizers, or other applications, it can be complicated to protect the upload or download because there are different options. In this case the most recommendable thing can be to secure the documentation directly in the repository when we detect new files stored.
Integration would work as follows:
- The user saves documents in the application by uploading them through a web interface, loading them with a synchronization application, etc.
- These files are stored and a service detects when there are new files stored in the system, through events, periodic scanning or other means.
- The new files stored are protected through calls to the SDK. Also all the documents that were in the repository and that are not protected.
How is policy management carried out and with what policies does the documentation need to be protected?
The SealPath SDK offers a high level of granularity in terms of protection policy implementation:
The protection can be associated with a particular folder or document library in the repository, so that everything you save, upload or download from the folder is protected with that policy.
- The protection can be associated to individual documents, so that, depending on the user, group to which it belongs, context of the user (e.g. from where the download or upload of documentation is made) a certain protection policy can be applied.
- As with SealPath’s desktop or server protection applications, the protection SDK can assign to the files privileges of View Only, Edit, Copy & Paste, Print, Add Users, or Full Control. You can set expiration dates on the documentation, possibility to include watermarks, offline access for X days, etc
- Policies are typically defined in the SealPath Management Console and applied from the SDK. However, it is also possible to apply “custom” policies generated on the fly from the SDK depending on the user’s needs or context, or to create and update new protection policies.
What kind of features does the SDK offer me?
Both the Local Protection SDK and the REST API offer functions to protect, unprotect, check if a file is protected, etc. These are some of the most important ones:
1. Identity management
- Establish protection identity: We indicate to the SDK who is going to be the user who will carry out the protection operations, unprotected on the files.
- Change identity: We can work with several identities and change them according to the protection needs.
- Remove identity: Unlock an identity from the SDK that we are not going to use anymore.
2. Protection and unprotection operations
- Protect with a policy: Secure a file with a pre-established protection policy.
- Protect with a “custom” policy: Generate a custom policy “on the fly” and protect the file with it.
- Check if a file is protected.
- Obtain the policy with which a file has been protected.
- Obtain the permissions of a user for a protected file.
- Unprotect a file.
3. Protection policy management
- Create a new protection policy.
- Update a protection policy already created, for example, to revoke a user’s access to a protected document.
- Obtain protection policy based on Guid, name, etc.
- Filter protection policies of a certain user based on certain characteristics. Depending on the filter you can obtain one or more policies that meet the filtering criteria
- Remove protection policy.
Additionally, the REST API offers acquisition functions of the OAuth v2.0 token to securely initialize the environment and perform the rest of the protection operations.
For the various functions, error codes are also displayed which provide information as to why the operation was not performed or failed.
Finally, all file access tracking and audit information, is available in SealPath’s web-based administration interface or can be sent via Syslog or WebApis to an SIEM or other system that allows for audit trail processing and post-processing.
Both the SealPath Local Protection SDK and the SealPath REST API provide an easy way for organisations to integrate data-centric security or documentation protection and control into their corporate applications.
In this way, without much effort, they can guarantee compliance with certain regulations where it is critical to have the information encrypted. They can also apply persistent protection to their sensitive information so that when it has left the application or repository security context, they still have their confidential data under control.
Whether the application is local on Windows with .NET, a web application running on a Linux server, or any type of architecture, SealPath offers different solutions to make integration easy and appropriate to the organization’s technology environment.
Do not hesitate to contact us for any questions or for more information, a team of experts will help you with whatever you need.