It’s not an overstatement that in today’s world, it’s dangerous to expose software services to the public without robust security controls in place. By “robust,” I mean going beyond the basic steps of using HTTPS with the latest TLS cipher suite to encrypt your data in transit. Today, there are myriad other risks that, if left unattended, can expose sensitive information to foreign parties.
The answer to those threats is what is known as trustless security. Below, I explain what the trustless security model means and how you can implement it, using Conjur’s secrets management features to illustrate what trustless security might look like in a real-world context.
The what and why of trustless security
When we mention the phrase “trustless security” (or “zero-trust security,” which means the same thing), it does not mean that we can stop the world and not allow anyone or anything to access keys and secrets forever. It means we allow only the minimum acceptable authorizations and permissions for each client, user or machine. Nothing and no one has access to credentials unless it is proven and verified that they should be trusted.
Not surprisingly, this is not an overnight process. But with the shift to the cloud, it should be planned and eventually implemented. In doing so, we’re starting with a secure default policy of restricting everything unless it comes with a set of known, secure endpoints and present authorized credentials, and we can remove the risk of privilege escalation attacks that can lead to data breaches.
Now you might be asking, “How can we start with implementing a zero trust security model that is readily available in the market?”
We start with properly managing our secrets, of course.
Implementing trustless security with Conjur and secrets management
Wouldn’t it be nice if we had a service that helps us create, manage and update the proper security controls regarding our management of secrets, credentials and access controls that are the heart of operational infrastructure? And above all, to have the right guarantees that it will work consistently and reliably? It turns out that CyberArk Conjur is our answer. Following are the key steps we need to perform so that we can implement a trustless/zero trust system with the help of the Conjur platform.
In the following examples, we assume that you have installed and configured Conjur platform on your system. If not, please refer to this Quickstart guide.
Role-Based Access Controls: Granting or revoking trust capabilities to users, machines or entities should be easy to manage and verify. In this case, we need an advanced control mechanism such as role-based access controls that allow both fine and coarse levels of assigning policies and permissions.
Conjur has built-in role-based access control through policy rules. For example, when we have two groups of users (developers and admins) and we want to assign the right level of permissions for each group, we can do so:
#declare 2 users and 2 groups - !user alice - !user bob - !group admins - !group developers #add members to the group - !grant role: !group admins member: !user alice - !grant role: !group developers member: !user bob #give the group privileges on some resources - !permit role: !group admins privileges: - create - update - read resources: - !policy root - !permit role: !group developers privileges: - read resources: - !policy root
Here, developers can see the metadata about the root policy, but cannot create or update new objects within that policy. Admins, however, have all of those permissions.
Creating fair and secure policies takes time and effort, but with regular peer review, we can decrease security incidents. Take your time when designing policies so they are easy to use and support.
Key Rotation: A common security practice is to discourage extensive reuse of encryption keys, especially on highly critical environments such as AWS. If a password or access key has the potential to be compromised without your knowledge, then you can limit how long the credentials can be used to access your resources. Ideally, key rotation should be transparent and consistent.
With Conjur, it’s fairly easy to do with the use of Rotators that are enabled using special annotations in our policy files. For example, the following policy specifies a secret_access_key variable on an AWS environment with a one-day rotation policy:
- !policy id: aws body: - !variable id: secret_access_key annotations: rotation/rotator: aws/secret-key rotation/ttl: P1D # 1 Day
We recommend that all passwords and credentials like IAM access keys be put under a rotation policy with secure defaults.
Encryption: Enterprise-ready applications need enterprise-ready cryptography to protect their data. Beyond that, the tools, libraries and software components that manage secrets need to be externally audited and verified by accredited institutions as having no known vulnerabilities. That alone increases the level of trust that a secrets management solution will keep our secrets secret.
Conjur uses a modern encryption standard (AES-256-GCM) for storing secrets and uses bcrypt with a work factor of 12 for storing passwords.
Conjur cryptography has been professionally audited, so we can rest assured that the level of security remains consistently high.
Elastic & Autoscale Environments: It’s easy to setup policies for static VMs and servers, but setting policy in a manual way is ineffective for dynamic environments where hosts are created and cycled on a regular basis. Perhaps as part of infrastructure deployment, there is a service that spins up new hosts for handling increased load. Or extra hosts need to be spun up to manage unexpected customer demand. There are lots of possible reasons why containers, applications, services, or machines are quickly scaled up and down to meet dynamic demand, but we still need an effective way to improve safety and compliance.
Conjur helps us deal with these scenarios with the usage of Host Factories, which enable Conjur to manage hosts dynamically. For example, see the following request to the Conjur server:
curl --request POST \ --data-urlencode "expiration=2019-05-04T22:00:00+00:00" \ --data-urlencode "host_factory=example:host_factory:hf-db" \ --data-urlencode "count=2" \ --data-urlencode "cidr[]=192.168.0.1" \ --data-urlencode "cidr[]=192.168.0.2" \ -H "$(conjur authn authenticate -H)" \ https://eval.conjur.org/host_factory_tokens \ | jq .
This creates two temporary Host Factory tokens with an expiration date for the host example:host_factory:hf-db with some CIDR address restrictions for an extra layer of security. (For example, only clients belonging to the 192.168.0.1 and 192.168.0.2 networks will be able to use the token to create new hosts.)
Auditing: Last but not least, we need to have a mechanism that provides us with auditing endpoints so we can verify that all operations in the past and in the future are traceable and actionable. For example, we absolutely need to have authentication and access logs collected in a secure way so that we can inspect any anomalies or potential escalation breaches. After all, we need to be sure that our level of trust is maintained.
With Conjur, we can do that out of the box, with no configuration. It maintains two types of logs:
- Audit logs: Located in /var/log/conjur/ and saved in the database. These contain all authentication attempts, permission checks, secret value retrievals, policy changes, and secret value changes. It’s important to forward those logs in an audit framework for further processing.
- General service logs: Located in /var/log. Useful for troubleshooting and process verification purposes.
Final Thoughts
A trustless security model means that there are mechanisms in place that make sure our policies are applied to the right users and roles, and at any point in time, we can verify that those rules are valid. This sort of trust is the absolute minimum required to continue operating under the model, and no other conditions are allowed.
Overall, the process of moving to a trustless security model is complex. Organizations should take it seriously and approach managing security in a proactive and predictive way. Hopefully, with the use of CyberArk Conjur open source security platform, we have a trusted tool that can help us transition to a trustless model with less friction. If you want to learn more about Conjur, you can schedule an evaluation demo.
Theo Despoudis is a Senior Software Engineer and an experienced mentor. He has a keen interest in Open Source Architectures, Cloud Computing, best practices and functional programming. He occasionally blogs on several publishing platforms and enjoys creating projects from inspiration.