Encryption at Rest and in Transit

In modern software architecture, 'secure by default' isn't just a catchphrase; it's a requirement. Encryption is the foundation of this security. Without transit encryption, any intermediary on the network—from a malicious Wi-Fi hotspot to a compromised ISP—can read your HTTP traffic in plaintext. Without rest encryption, a stolen database backup or a decommissioned hard drive exposes every user's PII (Personally Identifiable Information).

This guide moves beyond the theory. We will explore how TLS handshakes protect your packets in the wild and how to implement application-level encryption in Spring Boot to ensure that even if your database is fully compromised, your most sensitive fields remain indecipherable strings of noise. We'll also cover key management, compliance requirements, and the real production pitfalls engineers face when deploying encryption at scale.

Why Encryption at Rest and in Transit Is Not Optional

Encryption at rest protects data stored on disk or in databases, while encryption in transit protects data moving over a network. The core mechanic is cryptographic transformation: plaintext becomes ciphertext using an algorithm (e.g., AES-256 for rest, TLS 1.3 for transit) and a key. Without both, data is exposed at rest to physical theft or misconfigured storage, and in transit to packet sniffing or man-in-the-middle attacks.

In practice, at-rest encryption is transparent to the application — the storage layer encrypts pages or objects before writing to disk. In-transit encryption requires TLS termination at the load balancer or application server, with mutual TLS (mTLS) for service-to-service calls. Key management is the hard part: a leaked key or weak rotation policy undermines the entire scheme.

Use both for any system handling PII, financial data, or secrets. Compliance mandates (PCI DSS, HIPAA, GDPR) require it, but the real reason is defense in depth: a single misconfiguration — like an S3 bucket set to public — still leaks ciphertext, not plaintext. Encrypt everything, always.

Encryption in Transit — TLS/HTTPS

Encryption in transit ensures that data remains confidential and untampered while moving across the wire. Modern standards rely on TLS (Transport Layer Security) 1.2 or 1.3. When a client connects via HTTPS, a handshake occurs where the server proves its identity via a Certificate Authority (CA) and both parties negotiate a symmetric session key.

In a Spring Boot environment, you must ensure that your microservices don't just 'accept' HTTPS, but actively enforce it. This includes rejecting insecure algorithms (like SSLv3 or TLS 1.0) and ensuring that internal service-to-service communication is also encrypted, often managed via a Service Mesh like Istio or Linkerd.

TLS 1.3 reduces handshake latency to one round trip (0-RTT for resumption) and removes obsolete ciphers. In production, you should always prefer TLS 1.3 and enable HSTS to prevent SSL stripping attacks.

package io.thecodeforge.security;

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

/**
 * Production-grade Security Configuration for io.thecodeforge
 * Forces HTTPS and sets Strict-Transport-Security (HSTS) headers.
 */
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .requiresChannel()
            .anyRequest()
            .requiresSecure() // Redirects all HTTP traffic to HTTPS
            .and()
            .headers()
            .httpStrictTransportSecurity()
            .includeSubDomains(true)
            .maxAgeInSeconds(31536000); // 1 Year HSTS policy
    }
}

// Pro-Tip: When using RestTemplate or WebClient to call external APIs,
// never disable SSL verification. Use a proper TrustStore if dealing with
// private CA certificates.

TLS 1.2 vs TLS 1.3 Comparison

TLS 1.3, finalized in 2018, is a major overhaul over TLS 1.2. It reduces handshake latency, removes obsolete and insecure cipher suites, and introduces 0-RTT (zero round-trip time) resumption. The following table compares key properties:

In production, you should enforce TLS 1.3 wherever possible. If legacy clients require TLS 1.2, ensure you only enable the strongest cipher suites (ECDHE with AES-GCM). Disable TLS 1.0/1.1 and SSLv3 entirely.

Encryption at Rest — Database and File Storage

Encryption at rest protects data stored on persistent media. There are two primary levels: Transparent Data Encryption (TDE) and Application-Level Encryption. TDE, offered by AWS RDS or Azure SQL, encrypts the entire database file on the disk. However, if a user gains access to the database via an SQL injection, TDE won't help because the database engine decrypts data for the authorized process.

For high-stakes data (like SSNs or API keys), we use Application-Level Encryption. Here, the data is encrypted before it ever hits the database driver. Even a root-level database admin cannot see the raw values without access to the keys stored in an external Secrets Manager like AWS KMS or HashiCorp Vault.

When implementing field-level encryption, pay attention to IV generation and key rotation. AES-GCM is the recommended mode because it provides authenticated encryption — it detects if data has been tampered with.

package io.thecodeforge.security;

import javax.crypto.Cipher;
import javax.crypto.spec.GCMParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import java.security.SecureRandom;
import java.util.Base64;

/**
 * Field-Level Encryption Utility
 * Standard: AES/GCM/NoPadding (Production recommended over ECB/CBC)
 */
public class EncryptionService {

    private static final String ALGORITHM = "AES/GCM/NoPadding";
    private static final int GCM_TAG_LENGTH = 128; // bits
    private static final int IV_LENGTH = 12; // bytes
    // In production, retrieve this key from AWS KMS or HashiCorp Vault
    private byte[] encryptionKey = System.getenv("DB_ENCRYPTION_KEY").getBytes();
    private SecureRandom secureRandom = new SecureRandom();

    public String encrypt(String data) throws Exception {
        SecretKeySpec secretKey = new SecretKeySpec(encryptionKey, "AES");
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        byte[] iv = new byte[IV_LENGTH];
        secureRandom.nextBytes(iv);
        GCMParameterSpec gcmSpec = new GCMParameterSpec(GCM_TAG_LENGTH, iv);
        cipher.init(Cipher.ENCRYPT_MODE, secretKey, gcmSpec);
        byte[] cipherText = cipher.doFinal(data.getBytes());
        // Prepend IV to ciphertext for storage
        byte[] combined = new byte[IV_LENGTH + cipherText.length];
        System.arraycopy(iv, 0, combined, 0, IV_LENGTH);
        System.arraycopy(cipherText, 0, combined, IV_LENGTH, cipherText.length);
        return Base64.getEncoder().encodeToString(combined);
    }

    public String decrypt(String encryptedData) throws Exception {
        byte[] combined = Base64.getDecoder().decode(encryptedData);
        byte[] iv = new byte[IV_LENGTH];
        byte[] cipherText = new byte[combined.length - IV_LENGTH];
        System.arraycopy(combined, 0, iv, 0, IV_LENGTH);
        System.arraycopy(combined, IV_LENGTH, cipherText, 0, cipherText.length);
        SecretKeySpec secretKey = new SecretKeySpec(encryptionKey, "AES");
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        GCMParameterSpec gcmSpec = new GCMParameterSpec(GCM_TAG_LENGTH, iv);
        cipher.init(Cipher.DECRYPT_MODE, secretKey, gcmSpec);
        return new String(cipher.doFinal(cipherText));
    }
}

// usage: entity.setSsn(encryptionService.encrypt(rawSsn));
// Store IV alongside ciphertext — it's not secret

AES Encryption Modes Comparison (ECB, CBC, CTR, GCM)

AES operates on 128-bit blocks and can be used in different modes. The choice of mode dramatically affects security, performance, and features. Below is a comparison of the most common modes:

GCM is the gold standard for symmetric encryption in production. It combines AES-CTR with a cryptographic hash (GHASH) to provide integrity verification. Always use GCM with a 12-byte random IV and never reuse the IV with the same key. Avoid ECB entirely. CBC can be used if authenticated separately (e.g., CBC + HMAC), but GCM is simpler and more performant.

Symmetric vs Asymmetric Encryption — Comparison

Encryption algorithms fall into two categories: symmetric (same key for encryption and decryption) and asymmetric (public/private key pair). Both are essential in modern cryptography. The table below contrasts them:

In practice, systems combine both: asymmetric encryption (RSA or ECDH) is used to exchange a symmetric session key, and then symmetric encryption (AES-GCM) is used for the actual data. This is called a hybrid cryptosystem. For example, TLS uses ECDHE for key agreement (asymmetric) and AES-GCM for bulk encryption (symmetric). For encryption at rest, we use symmetric encryption (AES) directly, but the encryption key is often wrapped (asymmetrically) using a master key in a KMS.

Key Management — The Hardest Part of Encryption

Encryption without proper key management is like locking a door and leaving the key in the lock. The security of your encrypted data ultimately rests on the secrecy and integrity of the encryption keys. This means you must never hardcode keys, never store them in the same database as the encrypted data, and never share them via email or chat.

Production-grade key management involves three principles: (1) Use a dedicated Hardware Security Module (HSM) or cloud Key Management Service (KMS) to generate, store, and rotate keys. (2) Implement key rotation policies — regularly generate new key versions and retire old ones. (3) Control access to keys with strict IAM policies and audit all usage.

Cloud providers offer managed KMS solutions (AWS KMS, Azure Key Vault, GCP Cloud KMS) that integrate seamlessly with their services. For multi-cloud or on-prem, HashiCorp Vault is a popular choice. A common pattern is envelope encryption: a master key (kept in the KMS) encrypts data keys, and the data keys encrypt your actual data. This allows efficient rotation of data keys without touching the encrypted payloads.

package io.thecodeforge.security;

import software.amazon.awssdk.core.SdkBytes;
import software.amazon.awssdk.services.kms.KmsClient;
import software.amazon.awssdk.services.kms.model.*;

public class KmsService {

    private final KmsClient kmsClient;
    private final String keyId = System.getenv("KMS_KEY_ID");

    public KmsService() {
        this.kmsClient = KmsClient.builder().build();
    }

    public byte[] encryptData(byte[] plaintext) {
        EncryptRequest request = EncryptRequest.builder()
                .keyId(keyId)
                .plaintext(SdkBytes.fromByteArray(plaintext))
                .encryptionAlgorithm(EncryptionAlgorithmSpec.SYMMETRIC_DEFAULT)
                .build();
        EncryptResponse response = kmsClient.encrypt(request);
        return response.ciphertextBlob().asByteArray();
    }

    public byte[] decryptData(byte[] ciphertext) {
        DecryptRequest request = DecryptRequest.builder()
                .keyId(keyId)
                .ciphertextBlob(SdkBytes.fromByteArray(ciphertext))
                .encryptionAlgorithm(EncryptionAlgorithmSpec.SYMMETRIC_DEFAULT)
                .build();
        DecryptResponse response = kmsClient.decrypt(request);
        return response.plaintext().asByteArray();
    }
}

// Usage: KMS encrypts/decrypts app-level data keys, not the raw payload.
// Store encrypted data keys alongside ciphertext for envelope encryption.

End-to-End Encryption (E2EE)

End-to-End Encryption ensures that data is encrypted on the sender's device and can only be decrypted on the intended recipient's device. No intermediary — including the server that facilitates the communication — can read the plaintext. This is different from TLS, which only protects data between the client and server; the server sees plaintext.

E2EE typically uses asymmetric encryption: each user has a public-private key pair. The sender encrypts the message with the recipient's public key, which can only be decrypted with the recipient's private key. In practice, for performance, a hybrid approach is used: a random symmetric key is encrypted with the recipient's public key, and the message is encrypted with that symmetric key.

Common applications include messaging apps (Signal, WhatsApp), email (PGP), and file sharing. Implementing E2EE in a web application is complex because the server never has access to the private keys — they must be stored client-side (e.g., in the browser's IndexedDB) and derived from a user password. This makes features like server-side search or server-side key rotation impossible without additional cryptographic techniques.

Application-Level Encryption Patterns in Spring Boot

Spring Boot applications often handle sensitive data that must be encrypted before persistence. A common approach is to create a JPA AttributeConverter that transparently encrypts and decrypts entity fields. This keeps encryption logic out of business code and ensures every read/write goes through encryption.

However, AttributeConverter has a significant gotcha: it runs inside the JPA transaction context. If encryption fails (e.g., KMS is unreachable), the entire transaction may roll back. Always handle encryption failures gracefully — consider storing an error marker or retrying with a fallback key. Also, note that AttributeConverter encrypts the column value, so any direct database queries or reports will see the ciphertext — you cannot query by plaintext directly without deterministic encryption.

For searchable encrypted fields, use deterministic encryption (AES-SIV) or a separate search index. Never use ECB mode. And remember: encrypting a field prevents indexing in most databases, so only encrypt fields that truly need it.

package io.thecodeforge.security;

import javax.persistence.AttributeConverter;
import javax.persistence.Converter;

@Converter
public class SsnAttributeConverter implements AttributeConverter<String, String> {

    private final EncryptionService encryptionService; // inject via Spring

    public SsnAttributeConverter(EncryptionService encryptionService) {
        this.encryptionService = encryptionService;
    }

    @Override
    public String convertToDatabaseColumn(String plainSsn) {
        if (plainSsn == null) return null;
        try {
            return encryptionService.encrypt(plainSsn);
        } catch (Exception e) {
            // Log error and rethrow as runtime exception to rollback transaction
            throw new RuntimeException("Encryption failed for SSN", e);
        }
    }

    @Override
    public String convertToEntityAttribute(String encryptedSsn) {
        if (encryptedSsn == null) return null;
        try {
            return encryptionService.decrypt(encryptedSsn);
        } catch (Exception e) {
            // Log error and return a placeholder or throw based on business needs
            throw new RuntimeException("Decryption failed for SSN", e);
        }
    }
}

// Usage in entity:
// @Convert(converter = SsnAttributeConverter.class)
// @Column(name = "ssn")
// private String ssn;

Encryption Performance Considerations

Encryption adds CPU overhead and latency, but modern hardware mitigates most of the impact. Key factors:

AES-NI Hardware Acceleration Most modern x86-64 processors (Intel Core i5/i7, Xeon, AMD Ryzen) include AES-NI instructions that accelerate AES encryption. With AES-NI, AES-256-GCM encryption/decryption runs at line rate (~1GB/s per core) with negligible CPU cost. Without AES-NI, software-based AES is still fast but can be 5-10x slower. Always verify AES-NI is enabled in your cloud instance type (e.g., AWS C5/m5 series have AES-NI; T2/t3.micro may not).

TLS Handshake Cost Establishing a new TLS connection involves asymmetric cryptography (key exchange) which is CPU-intensive. TLS 1.3 reduces the handshake from 2-RTT to 1-RTT (full handshake) and supports 0-RTT for resumption. The actual CPU cost of a full TLS 1.3 handshake is around 0.5-1ms on modern hardware (ECDHE key exchange). However, network round trips dominate latency — typically 5-30ms for a full handshake. Connection reuse (keep-alive, session resumption) eliminates this overhead.

Application-Level Encryption Overhead Encrypting a single database field with AES-GCM takes roughly 0.5-1µs per 1KB on a modern CPU with AES-NI. For a single API call encrypting 10 fields, total latency is <10µs — negligible compared to database round trips. The bigger cost is network round trips to KMS if you decrypt every time. Caching decrypted data keys locally (with proper expiry) reduces this.

Performance Best Practices 1. Enable AES-NI: ensure your deployment uses instances with AES-NI support (check /proc/cpuinfo or sysctl machdep.cpu.features on macOS). 2. Use TLS 1.3 and session resumption to minimize handshake overhead. 3. Cache KMS-decrypted data keys in local memory (with TTL). 4. For bulk encryption, use streaming encryption (e.g., CipherInputStream) to avoid large memory allocations. 5. Profile encryption overhead before optimizing — often encryption is not the bottleneck.

Compliance and Standards — PCI DSS, HIPAA, GDPR

Encryption isn't just a technical decision — it's a compliance requirement. Regulations like PCI DSS, HIPAA, and GDPR mandate encryption of specific data types. For example, PCI DSS Requirement 3.4 requires rendering PAN (Primary Account Number) unreadable anywhere it is stored, which typically means encryption, truncation, or tokenization. HIPAA's Security Rule requires encryption of ePHI (electronic Protected Health Information) at rest and in transit.

Meeting compliance requires more than just turning on encryption. You must demonstrate control over key management, prove that encryption is properly configured, and maintain audit logs of all encryption operations. Many compliance frameworks also require annual penetration testing and vulnerability scans that verify encryption configurations.

The key takeaway: encryption for compliance is often about process as much as technology. You need documented policies, access controls, and regular reviews. Tools like AWS Artifact and Azure Compliance Manager help maintain documentation, but the implementation must be correct at the code level.

# Example AWS Config rule to check that S3 buckets enforce encryption at rest
Resources:
  S3BucketEncryption:
    Type: AWS::Config::ConfigRule
    Properties:
      Source:
        Owner: AWS
        SourceIdentifier: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED
      Scope:
        ComplianceResourceTypes:
          - AWS::S3::Bucket
      InputParameters:
        # Enforce SSE-KMS with specific KMS key
        # allowedEncryptionOptions: SSE-KMS

# Azure Policy to require encryption at rest for storage accounts
# https://docs.microsoft.com/en-us/azure/governance/policy/samples/require-storage-account-encryption

Compliance Requirements Comparison Table

Regulations have specific but sometimes overlapping encryption requirements. The following table compares PCI DSS, HIPAA, and GDPR:

Practical implications: If you store credit card data, you must comply with PCI DSS — this means using AES-256 for rest, enforcing TLS 1.2+ for transit, and implementing strict key management with rotation. For healthcare, HIPAA's addressable encryption means you must evaluate and decide; in practice, all covered entities encrypt ePHI. GDPR does not prescribe specific algorithms but expects encryption as part of 'data protection by design'.

Ciphertext Integrity – Why Your Encrypted Data Can Be Corrupted (And Nobody Tells You)

You encrypt a file. You store it. You decrypt it six months later and get garbage. Welcome to the world of bit flips, truncation, and padding oracle attacks. Encryption guarantees confidentiality, not integrity. That means an attacker (or a cosmic ray) can mutate your ciphertext in transit or at rest, and your decryption routine will cheerfully produce corrupted plaintext.

This isn't academic. In production, we've seen S3 buckets with silently corrupted AES-CTS ciphertext because someone's backup script did a partial overwrite. The result? Hours of debugging a 'decryption failure' that was actually a data corruption problem. The fix is to authenticate your ciphertext before you encrypt it. Authenticated Encryption with Associated Data (AEAD) modes like AES-GCM or ChaCha20-Poly1305 do this for you. They append a tag that verifies the ciphertext hasn't been tampered with.

Plain AES-CBC? You're vulnerable to padding oracle attacks. Just don't. If you must use a non-AEAD mode, pair it with HMAC-SHA256 over the ciphertext. Verify the HMAC before decryption. Every time.

// io.thecodeforge — system-design tutorial

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

# Production: use a real KMS, not a hardcoded key
key = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(key)

plaintext = b"Flight manifests: seat 12A, passenger ID: X7Y-9ZZ"
associated_data = b"flight_2024_12_01"  # binds context to ciphertext

nonce = os.urandom(12)
ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data)

print(f"Ciphertext length: {len(ciphertext)} bytes")  # includes 16-byte auth tag
print(f"Nonce: {nonce.hex()}")

# Simulate a network bit flip in ciphertext
corrupted = bytearray(ciphertext)
corrupted[10] ^= 0xff  # flip one bit

# Decrypt should raise InvalidTag
from cryptography.exceptions import InvalidTag
try:
    aesgcm.decrypt(nonce, bytes(corrupted), associated_data)
except InvalidTag:
    print("AUTHENTICATION FAILED — ciphertext tampered or corrupted")

The Wrecking Ball: Cryptographic Erasure vs. Deletion

You delete a database row. The file system marks it free. But the bytes are still on the SSD. In regulated environments (HIPAA, PCI-DSS), 'deleted' means unrecoverable. Logical deletion is a compliance trap. The only way to guarantee data erasure is to encrypt it and then throw away the key. That's cryptographic erasure.

Production pattern: encrypt every sensitive field with a unique data key (DEK). Store the DEK encrypted under a master key (KEK) in a KMS. When you need to 'delete' a record, just remove the encrypted DEK from your database. The ciphertext becomes gibberish. No waiting for garbage collection, no SSD wear-leveling headaches, no forensics recovery. Done.

This is how AWS S3 implements object deletion under the hood. They don't zero the bytes. They remove the key mapping. Your compliance auditor will love this because it's provable. The ciphertext exists, but without the key, it's entropy. Pair this with a short TTL on your KEK if you want paranoid-level assurance (e.g., Vault's lease mechanism).

// io.thecodeforge — system-design tutorial

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from cryptography.hazmat.primitives import serialization, hashes
from cryptography.hazmat.primitives.asymmetric import rsa, padding
import os, json

# Simulated KMS: generate a key-encryption key (KEK) — in prod, store in AWS KMS
kek = rsa.generate_private_key(public_exponent=65537, key_size=2048)

# Generate data key per record (DEK)
dek = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(dek)

patient_id = "PAT-8831"
record = {"ssn": "123-45-6789", "diagnosis": "NSTEMI"}
plaintext = json.dumps(record).encode()

nonce = os.urandom(12)
ciphertext = aesgcm.encrypt(nonce, plaintext, None)

# Wrap DEK with KEK for storage
wrapped_dek = kek.public_key().encrypt(
    dek,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()),
                  algorithm=hashes.SHA256(),
                  label=None)
)

# Stored record: ciphertext + wrapped_dek + nonce
stored = {"ciphertext": ciphertext.hex(), "wrapped_dek": wrapped_dek.hex(), "nonce": nonce.hex()}
print(f"Patient {patient_id}: stored. DEK is wrapped.")

# To erase: delete the wrapped_dek from database
# Next line is the erasure action:
del stored["wrapped_dek"]
print(f"Erased. DEK removed. Ciphertext now unrecoverable: {stored['ciphertext'][:40]}...")

API Gateway as the Cipher Chokepoint

Encryption in transit must terminate somewhere. When microservices handle TLS individually, you lose central control over cipher strength, certificate rotation, and protocol version enforcement. An API Gateway solves this by becoming the single TLS termination point. All external traffic hits the gateway, which decrypts, inspects, and re-encrypts before forwarding to internal services. This lets you enforce TLS 1.3, HSTS preloading, and mTLS for internal traffic without touching every service. The gateway also offloads costly asymmetric handshakes from application servers, improving latency. Why this order? First, decide the termination boundary (the gateway), then apply consistent cipher policies across all routes. Without a gateway, each team picks their own TLS config, creating weak links and audit nightmares.

// io.thecodeforge — system-design tutorial

from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.backends import default_backend

# Enforce minimum TLS 1.2, prefer TLS 1.3
allowed_ciphers = [
    'ECDHE-RSA-AES256-GCM-SHA384',  # TLS 1.2
    'TLS_AES_256_GCM_SHA384'        # TLS 1.3
]
def validate_tls_config(cipher_suite: str) -> bool:
    return cipher_suite in allowed_ciphers

# Example: gateway rejects weak cipher
print(validate_tls_config('TLS_RSA_WITH_RC4_128_SHA'))  # False

Microsegmentation — Encrypting East-West Traffic

Encryption in transit focuses on north-south traffic (client to server), but the real risk is east-west traffic between microservices inside your cluster. Once an attacker breaches a single pod, they can sniff internal traffic if not encrypted. Microsegmentation forces every service-to-service call to use mTLS or an encrypted overlay (e.g., WireGuard, Istio sidecar proxies). The why: blast radius containment. Without it, a compromised auth service can read plaintext payment data flowing to the checkout service. The how: deploy a service mesh (Istio, Linkerd) that transparently injects TLS into every pod pair. Each sidecar handles mutual certificate verification, ensuring only approved identities communicate. This shifts encryption from a transport concern to a network policy — you define rules like “payment service can talk only to billing, on port 443, with mTLS.” The order: first model your service graph, then apply encrypted microsegments to each edge.

// io.thecodeforge — system-design tutorial

from typing import Dict

# Define allowed encrypted east-west flows
policy: Dict[str, list] = {
    "payment-svc": ["billing-svc:443", "fraud-svc:443"],
    "billing-svc": ["ledger-svc:443"],
    "auth-svc": []  # isolated — no direct access to payment
}
def is_encrypted_flow_allowed(source: str, target: str) -> bool:
    allowed = policy.get(source, [])
    return target in allowed

print(is_encrypted_flow_allowed("payment-svc", "billing-svc:443"))  # True