Secrets Copied, Doors Wide Open

Why credentials have become the weak link in digital security (and how to shield them once and for all).

"In 2025, a single file stolen from an internal server was enough to expose millions of customers of an electronics giant on the dark web."

Stories like this have been repeated since the early 2000s - and they all have the same villain: leaked secrets. This post explains, step by step, how these leaks happen, why they have become so common and what architecture (already used in critical banking systems) solves the problem without putting a brake on the day-to-day work of IT teams.

What is a digital "secret" anyway?

• • Access credential - the "key" that proves who you are to enter a system (login + password, token, API key).
  • Digital signature key - the "pen" that proves you signed it (RSA, ECDSA, Ed25519 certificates, etc.).

Both work exactly like the key to your front door: if only you have it, the lock will trust it. If someone else copies the key, the door loses its usefulness.

Who really keeps the secret? (Owners × custodians)

In a simple example (your home), you are the owner and custodian of the key. In companies, the story changes:

In practice, access is made by several "entities" because, in this case, the file is copied across several layers of infrastructure.

Where do secrets "live" in the age of automation?

Modern programs are built like matrioskas: one layer stacked on top of another. For a container to be able to sign an invoice, for example, the key file needs to exist inside.
But each layer below it actually has copying power - and can therefore leak the key.

The deeper the level, the greater the power - if someone controls any of these layers, they can steal the key. That's why the "circle of trust" widens dangerously when the secret becomes just a file on the disk.

The step-by-step solution: Architecture with Isolation + Layered Access Control

Imagine that your house keys are left lying around at the entrance to your building "to make life easier for everyone".It's convenient... until the day someone decides to take them.
It's the same in IT: if you leave the cryptographic key inside the application server, it will be "at the fingertips" of any person (or malware) administering that server.
The way out is to isolate the secret in a specialized safe and let the application just request the service it needs - without touching the key itself.

Step 1 - Separate critical functions into dedicated vaults

Why two safes?

• • Because the protection requirement changes: data files need LGPD policy, keys need cryptographic policy (key size, algorithm, rotation, etc.).
  • By specializing, you invest in security where it matters and you don't lock down environments that only run code.

Step 2 - Replace "file" with "service"

1. Before (unsafe model)

• • Application mounts a /keys volume and reads mykey.pem.
  • Anyone with shell or backup access to the server sees the same folder.

2. After (isolated model)

• • Application sends: "KMS, sign this document X with key Y".
  • KMS checks whether the caller's token has permission, uses the key within the vault itself and returns only the result (signature or decrypted text).
  • The key never leaves the KMS, nor is it even listable by those running the application.

Step 3 - Protect each layer proportionally

• • Vaults (KMS/DB) → Strong hardening: few admins, MFA, priority zero-day patching.
  • Application environment → Minimum network rules and service account; but without the burden of managing local secrets, the deployment cycle remains agile (CI/CD, fast rollback).

This division saves time and money: you don't have to turn every cluster into Fort Knox - just the place that actually holds gold.

Step 4 - Apply clear access policies

1. RBAC (Role-Based Access Control)

• • "NF-e Service" can sign with NF-e key.
  • "Reporting Service" can only read databases, never sign them.

2. Rotation and exhalation

• • Automatic deadlines for encryption keys that guarantee database confidentiality; applications don't even notice because they access the service, not the key.

3. Detailed audit

• • Each request to the KMS is logged: who, when, which operation, which IP/container.
  • Follow the guidelines of LGPD, PCI-DSS, BC-PG1, ISO 27001, etc.

Step 5 - Concrete benefits

• • Radical reduction of the attack surface - No more key files scattered on backup, snapshot or temporary disk.
  • Compliance made easy - A KMS report proves that the key never leaked from the safe.
  • Secure scaling - Upgrading more instances of the application does not multiply the number of copies of the key; they all use the same remote service.

Isolating means transforming secrets from "copyable things" into "summonable services". You close the door on the next leak without locking the team inside the room.

Layers that deserve attention (and typical controls)

Prodist Security Module

Prodist has been protecting PIX, SITRAF, SILOC, DDA, MES, SLC and C3 transactions for 20 years.
It will soon be launching a new solution on the market, PSM, which brings together:

• • Key management with integrated RBAC
  • Encryption and signing (AES, RSA, ECDSA + DREX curve, Ed25519)
  • APIs via TLS 1.2+ with certificate authentication
  • Container-native, scalable, fault-tolerant architecture

In this case, the difference is that the key never leaves the PSM; the application just "asks" for the operation. Copying the secret file is simply no longer possible.

Conclusion: It's time to act - start shielding credentials NOW

It's not enough to understand the risk: you need to execute the change before the next leak tarnishes your reputation (and your balance sheet). We've put together an immediate action checklist to help you:

1. 1. Make an inventory: List all the places where keys, passwords or tokens live as files.
   2. Sort by criticality: Which secrets, if leaked today, would stop your business?
   3. Migrate critical secrets to a KMS such as PSM: Use a vault that applies RBAC, and for database encryption use automatic rotation.
   4. Lock down root access to lower layers: Implement MFA and revision permissions on the OS, hypervisor and storage.
   5. Continually audit and adjust: Review vault logs every month; run intrusion tests with every major release.

Ready to eliminate the weakest point in your security?

Make an appointment now with the Prodist team to discuss the possibilities of encryption solutions and get to know the Suite of Solutions.

Click here for a Prodist expert to contact you or send an e-mail to gercom@prodist.com.br