devopsy.kinsta.cloud

Tag: data encryption

Exploring Cloud Key Management Options
Encryption keys are the fulcrum of trust in cloud systems. They protect data, enforce compliance boundaries, and underpin every secure transaction. But as organizations move deeper into cloud environments, the challenge of managing cloud security keys grows.

Choose the wrong model, and you might end up with unnecessary complexity, hidden performance bottlenecks, or compliance gaps. Choose well, and you create a foundation for security that scales with your business. Let’s explore the different approaches to cloud key management and how they impact control, convenience and resilience.

Cloud-Provider Managed KMS

The simplest entry point into key management is the native key management service (KMS) offered by major cloud providers like AWS KMS, Azure Key Vault, or Google Cloud KMS. These services handle most of the heavy lifting—secure storage of keys, rotation schedules, integration with cloud-native services, and automated encryption of data at rest or in transit. From a developer’s perspective, using a provider-managed KMS is almost frictionless: A few API calls, and encryption just works.

Of course, the tradeoff is control. Because the provider generates, stores and rotates the keys, customers have limited visibility into the cryptographic underpinnings. Compliance teams may bristle at the idea of keys never leaving the provider’s domain, especially in industries that demand strict segregation of duties.

Performance is generally strong because keys live close to the services using them, minimizing latency. Still, regional limitations can emerge: Accessing a key in one region from workloads running in another might introduce delays or break compliance rules. Disaster recovery is also bound to the provider’s guarantees; if their KMS suffers an outage, customers have few alternatives beyond waiting for restoration.

Customer-Managed Keys (BYOK and HYOK)

Organizations seeking more autonomy often gravitate toward models like Bring Your Own Key (BYOK) or Hold Your Own Key (HYOK).
- In BYOK, customers generate keys externally and import them into the cloud provider’s KMS. This allows tighter control over key creation and lifecycle policies, ensuring the organization—not the provider—defines the root of trust.
- HYOK goes further by keeping keys entirely outside the cloud provider’s environment, typically in on-premises hardware security modules (HSMs) or trusted key servers.
These approaches align with regulatory frameworks that demand provable control over cryptographic material. They also enhance auditability since security teams can trace key usage across systems with their own tooling. The downside is operational complexity. Imported keys still rely on the provider’s infrastructure once inside the KMS, so isolation isn’t absolute.

HYOK, while offering maximum independence, can introduce latency if workloads must reach across the network to retrieve keys. Failover planning also becomes the customer’s responsibility—if your HSM cluster goes down, cloud workloads dependent on those keys may stall until recovery.

External Hardware Security Modules

For organizations prioritizing hardware-level assurances, external HSMs remain the gold standard. Services like AWS CloudHSM or integrations with third-party vendors allow companies to maintain exclusive control of cryptographic keys within tamper-resistant hardware appliances. Unlike cloud-provider KMS, external HSMs provide the highest level of isolation since the provider cannot access the keys, even in theory.

This model is especially compelling in financial services, healthcare, or government sectors where compliance requires FIPS 140-2 Level 3 certification or higher. External HSMs offer robust guarantees around physical tampering, secure key generation and strict role-based access.

But exclusivity comes at a cost—both financial and operational. Provisioning, maintaining and scaling HSM clusters demands specialized expertise. Performance may also suffer when workloads depend on real-time access to HSMs across regions. Key rotation, backup and disaster recovery become customer-managed tasks, adding weight to cloud security, further burdening DevOps teams already juggling competing priorities.

Hybrid and Multi-Cloud Key Vaults

In a world where enterprises rarely operate in a single cloud, hybrid and multi-cloud key vaults offer a unifying strategy. These platforms abstract key management from any one provider, allowing organizations to centralize control while supporting workloads in AWS, Azure, Google Cloud, and even on-premises systems.

Solutions like HashiCorp Vault or Thales CipherTrust act as universal brokers, enforcing policies and providing consistent APIs regardless of environment.

Centralization and its Risks

The value here lies in portability and risk mitigation. By decoupling keys from individual providers, organizations reduce vendor lock-in and gain flexibility to migrate workloads without re-engineering encryption strategies. Likewise, multi-cloud vaults streamline compliance reporting, providing a single pane of glass for audit trails.

However, consolidating control introduces its own hazards. If the centralized vault suffers an outage, every dependent workload could be impacted. Network latency can also creep in, particularly when workloads in multiple regions rely on a single vault.

Designing for resilience often means deploying regional replicas and investing in high-availability architectures, choices that add both cost and complexity.

Common Pitfalls and Gotchas

Even well-designed key management strategies run into pitfalls. One recurring challenge is cross-region key access. Workloads spanning multiple geographies often attempt to use a single KMS instance, only to discover that compliance rules or latency make the setup unworkable.

The fix, replicating keys across regions, introduces its own risks, including consistency issues and added attack surface. Another concern is tenant isolation in multi-tenant clouds. While providers promise strong logical separation, misconfigurations or vulnerabilities can lead to key leakage across tenants.

Organizations also underestimate the complexity of key rotation. Automated policies help, but not all services support seamless rotation. Applications may need to re-encrypt data or restart sessions, creating downtime risks.

Disaster recovery plans often ignore the dependency between encryption keys and backed-up data; a backup is useless if the corresponding keys are lost or corrupted. Finally, auditing can expose blind spots: Some KMS logs show when a key was used, but not the exact workload or transaction, limiting forensic clarity.

Conclusion

Managing encryption keys in the cloud is a balancing act between control and convenience, resilience and risk, performance and compliance. There is no universal solution—what works for a SaaS startup might fail under the scrutiny of a regulated bank.

Cloud-provider managed KMS offers speed and simplicity, customer-managed keys provide autonomy, external HSMs maximize assurance, and hybrid vaults deliver flexibility across multi-cloud landscapes.

The real task is aligning your choice with your threat model, compliance requirements and operational realities. In the end, the right key management approach is the foremost factor that builds the trust crucial for every modern cloud deployment.
October 30, 2025
DevSecOps Implementation: It’s About the Data

It seems we are constantly barraged with, “So-and-so announced that their systems had been breached and 80,000 user records were stolen,” notices. In fact, https://haveibeenpwned.com/ lists ten billion hacked accounts.

That is no surprise. Databases exist to pool related data together. Even NoSQL type databases, which some saw as an opportunity for wildly disparate data to be gathered and analyzed, almost exclusively contain related data sets. We generally don’t want or need to correlate, say, the number of pirates in the world with annual global temperatures, for example.

One would think, with decades of experience under our belts, we would have a good solution for protecting that data. If it was a simple problem, we would. It is not.

Databases are the primary target of most attackers. After all, getting access to your user database gives them account names through which they can try and gain elevated privileges. Getting a large amount of user/credit card information gives them a revenue stream by selling them off (though it is now so common that prices on the black market have become depressed, and this isn’t really profitable, given the risk versus the reward, anymore).

And databases must, by definition, have broad access. A database does not exist in a vacuum; it exists to serve an app. For server-based databases, it almost always exists to serve multiple apps. It must be on the corporate network (even if that network is a virtual private cloud), and it must … offer up data. It has users that have greater privileges than your average customer, and is notoriously difficult to protect with strong protections like encryption.

Encryption poses problems at multiple levels. It is still a bit slow, for starters. This is the nature of the beast – if it takes X microseconds to respond to a request, encrypted data will take at a minimum X+decrypt time (regardless of where decryption occurs). If encryption is done by column, index fields cannot be encrypted (because “nZ19?SDF” is unlikely to be in the same sort order as “ford explorer”, for example) Which means some data is immediately excepted from encryption. If encryption is handled by the database system, then the time overhead exists, and the database system must send the resulting data over your network … unencrypted. I was involved in a couple of projects that required encrypted databases – the one I can vaguely talk about was putting information about your corporate network onto Android and Apple devices. Needless to say, since phones and tablets are misplaced quite often, and most have weaker security than your average laptop, we needed information about critical infrastructure to be encrypted. It was … painful. We only managed it successfully because corporate networks are finite resources, so the amount of data we needed to store was limited, and we could prove performance wasn’t going to be the issue.

So what can you do? Continue to follow attempts to adequately encrypt corporate databases. Eventually, someone will crack this problem in a way that is performant, can be debugged and reliably protects the data.

Until then, protect your databases. Use the tools we’ve talked about in this series to monitor and protect the entire network, knowing that the database is a high-profile target if someone gets in. And use the other security tools available. The major database vendors offer DBMS security tools to evaluate your current status. Some will flag weak passwords, others will monitor for injection attacks (as will development tools discussed in the first few installments of this series). Lock down interfaces to databases – by user, by IP, whatever makes the most secure, but still usable, environment for you. Set up monitors for behavior outside the bounds of normal behavior – a query of 250K records should raise a flag, for example, since the vast majority of apps will only do a subset that can be paginated. Sure, it will probably be a false positive caused by someone hand querying, but the one time it isn’t, you’ll be glad the monitor was there.

And protect your database backups – be they actual backups or a dump to test. Fewer organizations are using real, unfiltered data for testing, but it crops up in most orgs at one point or another, as testers are trying to look at issues that fake/masked data can’t replicate. For actual backups, those must be encrypted. To lose your customers to a hacker because you had an unencrypted database dump lying around, and the attacker didn’t even have to attack the DB, is downright shameful, and happens too often. Along these same lines, and this should go without saying, but it’s happened enough that I feel compelled, do not copy large chunks of your database out to an unsecured cloud storage bucket. Some vendors have addressed this issue by not allowing public unsecured buckets, but you can still do this, depending on the cloud you are using. So, don’t.

The database security market will be best served by being rolled into SIEM and/or XDR. And while I’m in full-on pundit mode, for this statement, I’ll predict that is where it is headed. Database security is as much about overall security as it is the database, so overarching systems are the best place to detect and defend from. So watch for moves in that direction. A holistic view will serve you better in the long run.

Meanwhile? Keep rocking it. Treat your data like gold, because to hackers, it really is. And, keep running the world’s business. Celebrate your successes as much – or more – than you learn from your failures.

February 9, 2021
Making SD-WAN More Secure and Flexible

Cloud and managed services enable companies to focus scarce IT resources on business outcomes. According to Gartner, the “market size for cloud is growing exponentially, and cloud is projected to be a $317 billion industry by 2022.”

Managed service providers (MSPs) leverage the power of software-defined wide area networks (SD-WAN) to offer higher quality services and reduce branch network costs. SD-WAN offers compelling advantages for distributed organizations with critical branch operations, including the benefits of business agility, improved application performance and lower bandwidth costs.

MSPs invest considerable time and energy in ensuring that their servers, applications, data centers and people are always available. The same amount of attention needs to be paid to managing customer connectivity, as connectivity issues will result in customer support and retention issues, together with increases in cost and decreases in monthly recurring revenue.

While bringing connectivity to the data center is viewed as a customer-driven activity — meaning that MSPs are relying on end-users and carrier networks to deliver their customer experience — managing that connectivity is primarily, but not always, the responsibility of the MSP.

However, the quality, performance and security of carrier networks can be outside of the MSP’s control, creating vulnerability in the MSP’s service delivery and revenue process. Many MSPs are, therefore, rightly concerned about the safety of end-user data as it passes over the carrier networks. Outsourcing security measures and data assurance for end-users’ critical data can sometimes be undesirable and, thus, should be considered as part of a risk mitigation strategy.

Making SD-WAN More Secure and Flexible

A challenge that most MSPs face is ensuring that their customers’ data is encrypted safely in an SD-WAN environment and the integrity and confidentiality of that data is assured.

An on-premise, scalable encryption management solution that can integrate into an SD-WAN without disrupting an MSP’s environment provides the flexibility MSPs are seeking. In addition, the utilization of micro-segmentation using cryptography to prevent lateral movement of threats between segments can protect the confidentiality and integrity of the end-user’s data providing the security both parties need.

A viable encryption solution that makes the SD-WAN environment more secure and flexible provides the data assurance MSPs and their end-users are seeking, while mitigating risk and reducing the attack surface for everyone.

Data Assurance with Separation of Duties

Layer 4 encryption provides data assurance and eliminates risk for both the MSP and the end-user with the separation of duties, allowing the end-user to encrypt and protect their data prior to sending it over the MSP/carrier networks. Through crypto-segmentation, fine-grained policies are defined and enforced to protect the confidentiality and integrity of the end-user’s data.

In practice, this means that MSPs do not take on the risk of having to manage and protect the confidentiality and integrity of their customers’ data, nor do they have to accept risk to protect end-user data when it’s on their network — it remains the responsibility of the end-user.

Similarly, the end-user can eliminate risk to their data from both the MSP and whatever carriers they, or the MSP, may be using for the connectivity; they do not have to trust the carrier team or network to be secure.

Ensuring Fine-Grained Regulatory Policies with Crypto-Segmentation

Most MSPs will have enterprise, government and high assurance customers, all of whom are under varying data protection regulations. The end-user can now use crypto-segmentation to create separate policies and data flows, thus eliminating risk by defining fine-grained policies that are difficult to infiltrate.

Crypto-segmentation enables MSPs with customers who must adhere to different or multiple industry and/or government regulations — for example, to generate these fine-grained policies by each customer and regulation (GDPR, PCI, CJIS, NERC CIP) etc.

Scalable Implementation Into Any Network or Transport

Lastly, a scalable, network agnostic overlay which integrates easily and sits on top of SD-WAN can make the SD environment more secure for MSPs and their customers without disrupting the current network architecture and with zero impact to performance. This solution should be fully interoperable with the SD-WAN, scale to support the breadth and depth of the customer’s environment and operate without impacting the SD-WAN core functionality.

Conclusion

MSPs and their end-users need to mitigate the risks and vulnerabilities associated with multiple carrier networks. In order to achieve this, it is essential that MSPs investigate flexible and secure data assurance solutions that help both carriers and end-users to take advantage of the management services provided by MSPs and provide critical separation of duties to mitigate risk for both parties.

June 12, 2020
Application Development: Ripe for Encryption

As businesses look to accelerate application innovation and move more and more workflows to the cloud, their needs can be at odds with the need to secure the data. This article will outline current challenges faced by application developers to protect data in this new cloud/DevOps environment. It will also provide insights on how to eliminate the burdens from the DevOps team while significantly improving the security of data stored in cloud databases.

Cloud Migration

Businesses are looking to accelerate application innovation and move more workflows to the cloud. Cisco’s Global Cloud index projects a 26 percent growth rate of cloud workloads between 2015 and 2020. As this trend accelerates, IT project owners increasingly run into audit and compliance requirements that prevent transfer of sensitive data outside the traditional security perimeters. The overwhelming benefits of the cloud including the ability to obtain unlimited scalability of infrastructure, set up and tear down rapidly and gain cost advantages due to economies of scale make this trend impossible to contain.

Application Development Challenges in the Cloud Era

As applications migrate to the cloud, application developers are using microservices to accelerate application development because they dramatically reduce development time and help them focus on their key value proposition, be it hailing a cab or booking a place to stay. The success of microservice players including Twilio and Braintree demonstrate the benefits of delegating non-core features such as calling, messaging and payment processing to domain experts.

Surprisingly, when it comes to something as critical as data security, enterprises still leave the burden on the application developers. This distracts them from working on business objectives as they worry about security problems such as how best to encrypt at data and when to change encryption keys—problems best handled by security domain experts.

Securing Cloud Workloads

As it turns out, encryption is not easy to incorporate into enterprise workflows. Encrypting application data prevents databases from processing it. Then there is the problem of managing keys, which could be lost or become stale. Encrypting cloud workloads brings a whole new set of challenges as the issue of control comes up. If the cloud vendor has access to the keys, what prevents them from being subjected to a subpoena from a government that is using national security as justification to decrypt the data? Add to that the complexity of migrating from on-premises databases to the cloud without risking the data.

Pragmatic Approach

A pragmatic approach to solving this problem is to use existing encryption solutions that provides the detection, classification, policy enforcement and monitoring of sensitive data at all times. These solutions can protect application data at a columnar level but easily integrate into existing enterprise workflows. Application developers can identify sensitive data based on a data classification matrix and the sensitive data is automatically protected as it is inserted into the database. Using existing cryptography techniques, that data can even be processed without ever being decrypted, ensuring the highest level of security.

About the Author/ Ameesh Divatia

Ameesh Divatia is CEO and Co-Founder of Baffle, developer of the world’s first solution for end-to-end database encryption. Ameesh is a serial entrepreneur with a track record of converting innovative ideas into successful businesses. Connect with him on LinkedIn.

June 16, 2017