Skip to main content

4 posts tagged with "data-encryption"

View All Tags

· 2 min read
Hal Yaman (B.Sc)

Note - this article was originally posted on Hal's blog on March 21, 2023 under the title "Thales CipherTrust & Active Directory."

Into Image Why should you integrate Thales CipherTrust with your Microsoft Active Directory? What are the benefits of integration, and how is it done? Does Thales CipherTrust Manager (CTM) replace your Active Directory Group policy?

In the previous blog post, we went through the deployment of the CipherTrust Manager in our VMware environment. In today’s post, we will focus our discussion on how to integrate the newly provisioned OVA with the company Active Directory, a necessary step for activities we will discuss in our future posts.

The Why

To streamline the management of your company’s security requirements, and to easily manage your access and control of the company files and directories, it is a good idea to integrate CTM with Active Directory as a source of user management. By doing this, you can assign your policies more easily by basing them on the company AD Users and Groups.

The How

Now let’s focus on the fun technical part, the integration. The first step before we start the configuration is to get some information from AD; so, let’s run the following PowerShell command to retrieve the necessary information for our configuration: Get ADuser

The output will be as shown below:

AD Info

After you have retrieved the above information, we are ready to head back to our CTM and browse to: Access Management -> LDAP. From the top right corner, select “+ Add LDAP“:


On the pop-up config windows, provide the following information:

  • Connection Name: any
  • Server URL: your AD IP/DNS name
  • Bind DN: CN=Administrator,CN=Users,DC=oasis,DC=org
  • Server Bind Password: account password
  • Rood DN: DC=oasis,DC=org
  • User login name attribute: sAMAccountName AD_Bind-1

After you have tested the configurations to be correct and are ready to accept it, click on the “Add LDAP” button at the bottom right corner.


Today’s blog is very important; this post is setting the foundation for our next exciting topic, Thales Transparent Encryption feature. As you may have noticed, to integrate the CTM with AD is a very simple, but important operation. Next week, we going to use the configuration setup today to access and encrypt the company’s critical data.

· 8 min read
Hal Yaman (B.Sc)

Note - this article was originally posted on Hal's blog on March 24, 2023 under the title "CipherTrust Transparent Encryption."

In many organisations, IT departments are sometimes required to delegate some of their responsibilities to other teams, but at the same time, also required to keep control of the company security. Wait! In the world of security, can data security become a delegated responsibility? If that is a yes, then how?

Five years ago, I was pulled into the DevOps team culture and mindset. Since then, I have been lucky enough to manage the building of several DevOps teams. One of the many attributes of the DevOps culture is their autonomy. DevOps teams build in a way that can execute a task from end to end. The teams build up while working through the requirements and functions of the project or product, and with this knowledge, go on to find the most effective way of breaking the silos encountered by traditional teams.


The previous paragraph described DevOps as being about speed of delivery and autonomy, which also requires the team to access resources that are not always managed within the team; Active Directory, file shares, and so on are examples of these resources. So, how can you keep your DevOps team focused, but not affect the company processes?


Let’s put the DevOps information above into context using a real scenario I came across last week with one of the teams I help to build two years ago.

Company A was working on a confidential application for a client; the client was concerned that a breach of their code data would expose their intellectual property to competitors, or would become general knowledge.

The client asked that the following hierarchy be implemented to help mitigate their risk:

  • Each Team has it own encrypted directory
  • Only the specific team can access and read the code
  • Admin can manage the files within all the directories, but cannot read the code

The Challenge

From those requirements, Company A faces the following challenges:

  • How to implement access management and encryption at the same time
  • How to avoid disruption of the DevOps team concept
  • Delegate security manageability to the DevOps team without affecting the wider company policy


Access management can be controlled using the company Active Directory; but doing so will complicate the workflow of the DevOps team and will slow the delivery. At the same time, Active Directory and Group Policies do not offer encryption, so the IT department turned to Thales CipherTrust Manager to solve this challenge.


To achieve all the security requirements, Company A decided to use CipherTrust Manager with the Transparent Encryption feature. Using Transparent Encryption Live Data Transformation (LDT), Company A can delegate the code data management to the DevOps team, but at the same time, encrypt the data and also keep Admin in control of managing and backing up the code files without compromising security.

So let’s learn how company A uses CipherTrust Manager to keep each team in control.

CipherTrust User and Domain

To delegate responsibilities, the Company A IT team was looking for a multi-tenanted system that can help the department to easily create and assign multiple teams to manage their own security requirements, while remaining isolated from each other. This requirement can be met with Thales CTM by creating a Domain to allow the DevOps team to manage their access control and security needs.

To create a Domain, you first create a user by browsing to “Access Management -> Users -> Add User“: Add_User

After you have added the user, apply the user to CTE Admins and Clients by going to Edit/view the user. Under Groups, Search CTE and add to Admin/Client: CTE_Groups

The next step is to browse to “Admin Settings -> Domains” and click “Add Domain“:

  • Name: DevOps
  • Admins: devops (the user you just created)
  • Choose the default CA
  • Save Add_Domain

Now you are ready to logout and then login with the user you just created. After logging in again, change the domain to the new domain at the top right corner – Switch Domains: Switch_Domains

Create a Key

To be able to encrypt the data, we must create a key. Creating a key is very simple with CipherTrust Manager, all you need is to browse to the keys at the left menu and press the “Add key“. The next step is to provide a Key name: for example we will create a key name: LDT_Key and then press”Add Key” to save it.

At the next window, expand the “Key Access” option. On the search bar, type “CTE” with show all groups, then tick the check boxes for all the Admins and Clients permissions. Press Update: Key_Access

Next, browse to “Key Labels -> CTE“. Choose CBC from the drop down menu”. Press Update: Key_Label

Install the Transparent Encryption Agent

To be able to install and use the Transparent Encryption feature, you must install an agent. The first step is to create a “Registration Token“; this will be used during the agent installation to add the agent to the CipherTrust Manager. To create the Token, browse to “Access Management -> Registration Tokens” and click on “Add Registration Token” and complete the following entries:

  • Provide a Name Prefix: on my case DevOps_token
  • Local CA: choose the default
  • Create a token: Base64 Create_Token

Copy the token; then go to your Windows or Linux machine to run the agent installation. During the installation, you will be asked to provide:

  • Componant to register: File System
  • CipherTrust Manager IP/Hostname
  • Enable LDT Feature (FS agent only)
  • Token

After the installation is completed and you have successfully rebooted, you will be able to see the registered client on your CipherTrust Manager under: Transparent Encryption -> Clients: CTE_Client

Creating Policies:

After deploying the agent and connecting it to the CTM, we can focus on creating our polices. As we have four different teams in our example, lets create four policies as shown below:

  • DevOps_Admin_Team: Access and manage files and directories but can read files content
  • DevOps_Dev_Team: access only Development directory
  • DevOps_Ops_Policy: access only operation directory
  • DevOps_QA_Team: access only QA diretory

Let’s create first policy, the DevOps_Admin_Team policy by browsing to “Transparent Encryption -> Policies -> Create policy“:

  • Name: DevOps_Admin_Team
  • Policy Type: Live Data Transformation
  • Security Rules: + Create Security Rule
    • User Set – Select – Create User Set:
      • Name: Admin_Team
      • Create User
        • Agent – select Agent
        • User Type: LDAP
        • Member Choice: User or Group (on my case I choose group)
        • gname: group name
      • Note: repeat the above steps to create all the users for each group (i.e: Admin, Dev, Ops and QA team. on each time you need to create a policy you can easily choose the appropriate group or user)
    • Action – Select
      • All_Ops
    • Effect – Select
      • select permit
      • ApplyKey only of other group but not Admin group as the admin will not be able to unencrypt the data so a key not required
  • Key Rules: Create key Rule
    • Current Key Name: Select – “clear_key”
    • Tranformation Key Name: Select – LTD_Key
    • Add
  • Next – Confirmation – Save

Note: repeat the above steps for all the groups

Create GuardPoint

Our last step is to apply these policies to our folders or client. In this example, I will be using a Windows client. So let’s get started:

As we have different teams and policies, each with different access, we must create a different client GuardPoint. Browse to Transparent Encryption -> Clients. Choose the client – “Create GuardPoint“:

  • Select Policy: choose DevOps_QA_Team
  • Path: browse to the QA directory and select “select Path”
  • Create

Note: repeat for each team and select the appropriate directory Create_GuardPoint

After all the directories are assigned to a group – on each GuardPoint – press the policy name and add the right action for each team as shown below; for example:

  • Development_Team can access, and apply key
  • Operation_Team no access
  • Admin_Team access but no key DevOps_Permission_Group

Note: repeat for all other GuardPoints


After Following the steps described above, you can check that your new configuration works by accessing your Windows machine with a different user; for example, QA, dev, ops or admin, then check to see if you can access or read the files. The above steps are a little involved, more than Active Directory Group Policies; but with CipherTrust you also get the encryption aspect with a full and controlled separation of responsibilities.

Company A was able to achieve their client’s security request; but at the same time, did not affect the team processes, autonomy, and control. At both levels, Company A IT and DevOps, it was a win – win situation.

· 4 min read
Pranav Shikarpur

Your company has a ton of daily active users and you have this amazingly efficient architecture to process requests at scale, but your InfoSec team asks you to use a key manager — there are so many out there, which one do you choose?

There are various different types of key managers, but in this post, we’ll cover the three most common key managers:

  • Native Cloud Key Managers (Ex — AWS KMS, GCP KMS, Azure Key Vault, etc.)

  • External Key Managers (Ex — Thales CipherTrust Manager, etc.)

  • Hybrid Key Managers (Use the best of both worlds — Cloud managed services and external key managers)

First, the literal key to security — HSMs

HSM stands for “Hardware Security Module”. These are physical devices that are usually tamper resistant which store keys and perform encrypt, decrypt and other cryptographic operations.

HSMs are needed in secure environments such as healthcare or financial institutions where you need to pass compliances such as PCI DSS.

Now Let’s Compare

Let’s look at the pros and cons of each to help you decide what would work best for your organization.

Cloud Key Managers

Easy Integration with Cloud Managed Services

When using cloud key managers like AWS KMS (Key Management Service) it can be advantageous as you get the flexibility of AWS managing your keys as well as direct integration into your existing AWS managed services such as AWS S3, or AWS RDS (Relational Database Service), etc.

HSMs provisioned and managed by a cloud provider (most of the time 🤞)

Most famous cloud providers have HSMs that they use in their data centers which store your keys, so you don’t have to worry about renting an HSM.

❌ No Separation of Trust 🕵️‍♀️

Since your cloud provider now hosts and controls your data and encryption keys. Your user data might not be as safe anymore as the cloud provider with malicious intent could easily decrypt your user data. This does not help in creating a zero-trust architecture. While it’s true that your cloud provider has your best interest; there are always hackers lurking around the internet trying to get malicious access to your data, so it’s best to store data in an isolated environment.

External Key Managers

✅ Complete Separation of Trust

When running a product such as CipherTrust Manager, your architectures are zero-trust by default as 2 different entities have access to either your data or your keys and NOT both.

❌ Build your own custom integrations

Unless the key manager service has connectors, many-a-times, you would need to build your own connectors which could put a lot of engineering debt on your teams.

⚠️ Need to rent out your own HSM

You’d need to manage your own HSM, but fortunately, there are service providers that will rent out and manage the HSMs (just like a cloud provider) — so this is neither a pro nor a con. A great example of a hosted HSM is the Luna HSM.

Best of Both Worlds 🤔

Yes, it’s possible! To implement the best data security practices, you would want the ease of integration with cloud-managed services as well as complete separation of trust to isolate encryption keys from data. This method is also called BYOK (bring your own key).

You can do this with products such as CipherTrust Manager Cloud Key Manager. This offers:

✅ Direct connection with cloud-managed KMS account

Once you connect your AWS or GCP or Azure account to CipherTrust Manager as shown in the tutorial linked below, you will be able to manage keys directly from CipherTrust Manager and encrypt data on cloud-managed services.

✅ Key Lifecycle Management in a few clicks

In just a few clicks you can setup key rotation which will rotate your keys every few months and provide the best data security standards for your organization.

How do I implement this?

Luckily, it’s easy to implement in 3 simple steps. Here’s a tutorial I made that demos connecting CipherTrust Manager to my AWS KMS (Key Management Service) account and encrypt my AWS managed services such as S3 and RDS.

Now go ahead and encrypt all your cloud-managed services using this hybrid BYOK approach!

If you have any issues with implementation or questions about data encryption, go to the CipherTrust community and post a quesiton.

· 3 min read
Pranav Shikarpur

Building and deploying applications and services is super exciting. Still, when your security team prevents your application from going into production due to a lack of data encryption — this can be very annoying.

Let’s take a look at the different data encryption methods that are most commonly used and how we can implement some of them.

Data encrypted at-rest vs in-transit?

Well, it’s often hard to choose between encrypting a complete Postgres database or encrypting only specific fields of data in the database right before it gets written to a table.

The key difference between the two is that encrypting a database after data is written to it is called data encryption at rest and encrypting data before data is written to a database is called data encryption in-transit.

The illustration below should give you a good high-level understanding of the difference. Although data encryption at-rest was a standard encryption practice followed for many years, it involves developers writing and maintaining various different scripts or applications to ensure that the encryption is up to company standards. It is still useful while encrypting file systems and storage. On the other hand, data encryption in-transit is a lot more beneficial at times when you want to make your infrastructure database agnostic and provide high-security standards with significantly low developer effort.

Data Encryption at REST Architecture

Note that from the above diagram we can see that the method of encrypting data in-transit uses a side-car container which is a proxy used to intercept every request with sensitive fields or encrypted data and encrypt or decrypt the same respectively.

Data Encryption in-transit Architecture

Advantages of Data Encryption in-Transit

✅ No change to applications

The beauty of doing data-encryption in transit is that you don’t need to worry about changing any of your frontend apps, APIs, or databases. Since the side-car container does field-level encryption, you can granularly control all the data that needs to be encrypted and decrypted by remotely setting access policies from your key manager.

✅ Easy to deploy

Deploying a Data Protection Gateway side-car container is as easy to deploy as logging agents such as DataDog or Prometheus. You can just update your docker-compose, Kubernetes config files or just use Helm to install it.

✅ Developers can stop implementing data security policies

Now you can shift the responsibility of setting and implementing data security policies from developers over to InfoSec teams. This significantly helps prevent data breaches or unauthorized data access.

Disadvantages of Data Encryption in-Transit

Data encryption is only as strong as policies set

This applies to any method of data encryption. However, when we perform field-level encryption and decryption, InfoSec teams need to be aware of all data flowing through various API routes to prevent data breaches and unauthorized access to unencrypted data.

How Do I Implement Data Encryption in-Transit?

You’re in luck 🙌 because I have a tutorial showing you how to easily implement data encryption in-transit with any of your containerized applications.

In this tutorial, I have used CipherTrust Manager’s Data Protection Gateway product which is extremely easy to set up and free to start using👇

Now go ahead and encrypt data in-transit from all your applications using side-car containers.

If you have any issues with implementation or questions about data encryption in-transit, feel free to leave a comment, tweet @snpranav, or raise a GitHub issue :)