Docs

Security

Secure cloud ☁️🔐

Secure cloud: identity, secrets, and firewalls ☁️🔐

The cloud isn’t a magic fluffy thing that protects everything on its own: it takes method, attention, and a few good practices to avoid data ending up where it shouldn’t (like on a public forum or in a folder shared with half the world). In this introductory guide you’ll find everything you need to build a solid cloud security strategy, without losing sleep (or at least, not too often).

Fundamentals of Identity & Access Management (IAM) 🪪

Identity & Access Management (IAM) is the heart of cloud security: without rigorous management of identities and permissions, the risk of unauthorized access is just around the corner. IAM allows you to:

Define who can access what and when
Track every relevant action
Automate identity management at scale

Key IAM components 🧩

Users: represent real people or applications that need to access resources. Every user should have a unique, non-shared identity.
Groups: aggregate users with similar needs, simplifying permission management. For example, a “developers” group might have read-only access to certain environments.
Roles: ideal for temporary access or for delegating permissions to services/applications. Roles are perfect for automated tasks or for those who need to perform specific activities only at certain times.
Policies: rules that establish what is allowed or forbidden. Policies should be clear, granular, and documented, to avoid surprises. Practical examples of policies:
- Allowing users to rotate their own credentials without administrator intervention
- Allowing a service to access only a specific resource for a limited time
- Enabling a user to manage only the resources of a given project

Identity = who. Policy = who can do what, where, and when. Simple, right?

Least-privilege access controls 🦶

The Principle of Least Privilege (PoLP) is one of the cornerstones of information security. Imagine giving a plumber the keys to your house: you’d only give them the key to the bathroom and the boiler room, not the safe. The same applies to the cloud.

Every identity (human or machine) should have only the permissions strictly necessary to do its job, nothing more. This drastically reduces:

The risk of human error: a wrong command with excessive privileges can cause enormous damage.
The impact of any compromise: if an account is breached, the attacker will only have access to a limited perimeter.
The overall attack surface: fewer privileges around, fewer open doors for potential threats.

How to implement it in practice

Start from zero: when you create a new user or service, don’t assign any default permissions.
Add only what’s necessary: grant permissions one at a time, only when a real, documented need arises.
Be granular: instead of giving access to an entire service (e.g. s3:*), grant only the specific actions needed (e.g. s3:GetObject).
Use time-limited access: for sensitive operations, grant permissions that automatically expire after a short period.

Practical tip: periodically review assigned permissions (at least every 90 days) and automate the revocation of unused ones with Cloud Infrastructure Entitlement Management (CIEM) tools. Better a user who asks for one more permission than one who can do too much for no reason!

Centralized and decentralized identity solutions 🏢🔗

Digital identity management can follow two main approaches: centralized and decentralized. The choice depends on the context, security requirements, and the organization’s philosophy.

Centralized solutions 🏛️

In a centralized system, a single authority, called the Identity Provider (IdP), manages all identities and access policies. Think about how you access Google services: you use a single account for Gmail, Drive, and Calendar. That’s a centralized system.

This approach facilitates:

User onboarding and offboarding: a single place to create or disable an account.
Consistent policy enforcement: security rules are uniform across all connected services.
Monitoring and auditing: it’s easier to track who did what and when.

Warning: a centralized system is convenient, but it’s also a single point of failure. If the IdP is compromised, all connected accounts and services are at risk. That’s why it’s essential to protect it with strong authentication (MFA), constant monitoring, and regular backups. Common examples are Azure Active Directory, Okta, or Auth0.

Decentralized solutions 🪪

Decentralized solutions, such as the Decentralized Identity (DID) model and Verifiable Credentials (VC), give full control of identity back to the user. There’s no central authority that can create, modify, or revoke your digital identity. The user keeps their own credentials in a personal digital “wallet” and presents them when needed.

This approach is ideal for:

Advanced privacy scenarios: the user decides what information to share, without intermediaries.
Applications requiring self-sovereign identity (SSI): identity is owned and controlled exclusively by the individual.
Distributed and federated ecosystems: it allows interoperability between different systems without the need for complex federation agreements.

This model, based on W3C standards, is emerging as the foundation for a more secure, private, and portable digital identity in Web3 and beyond.

Practical example and visual comparison 🔍

Suppose you want to access a company portal and, in another scenario, a service that supports decentralized identities:

Centralized: the user uses corporate SSO (IdP) and gets a token for the portal. The company controls provisioning, policy, and revocation.
Decentralized: the user presents a verifiable credential (VC) from their own wallet; the service verifies the signature through a public registry (DID Registry) without involving a central IdP.

    flowchart LR
  %% Centralized IdP Flow
  subgraph Centralized
    U1[User] -->|SSO Login| IdP[(Identity Provider)]
    IdP -->|OIDC/SAML Token| App1[Company Portal]
    Adm[IAM Admin] -->|Policies & Roles| IdP
    IdP -->|Provisioning/Revocation| Dir[(Directory/SCIM)]
  end

  %% Decentralized DID Flow
  subgraph Decentralized
    U2[User] -->|Presents VC| App2[Service]
    U2 -->|Signs with key| Wallet[DID Wallet]
    App2 -->|Verifies| Reg[(DID Registry/Decentralized PKI)]
    Iss[Issuer] -->|Issues VC| Wallet
  end

  classDef central fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1,stroke-width:2px
  classDef dezent fill:#E8F5E9,stroke:#43A047,color:#1B5E20,stroke-width:2px
  class U1,IdP,App1,Adm,Dir central
  class U2,Wallet,App2,Reg,Iss dezent

When to choose which?

Choose centralized if you want fast onboarding/offboarding, granular control, and integration with existing systems (HR, SCIM, MDM).
Choose decentralized if your priorities are privacy, credential portability, and interoperability between domains without complex federations.

Authentication and authorization mechanisms 🔑

Authentication answers the question “who are you?”. Authorization answers “what can you do?”. Both are essential for security.

Authentication: how to prove who you are 🕵️‍♀️

Single Sign-on (SSO): allows access to multiple services with a single login. It reduces friction (and the temptation to reuse the same password everywhere), but must be protected with MFA.
Federated identity: allows using credentials from an external provider to access different services. Useful for collaboration between companies or for integrating cloud and on-premise services.
Multi-factor authentication (MFA): adds an extra layer of security. A password alone is no longer enough: you also need a temporary code, a physical key, or biometric data.
Password: the most widespread solution (and the most attacked). Use it only if you can’t avoid it, and always with MFA.

Single Sign-on (SSO) 🔗

One login to rule them all. With Single Sign-On, a user authenticates only once with a trusted Identity Provider (IdP) and gets access to multiple applications and services without having to re-enter credentials.

How does it work? After the initial login, the IdP generates a token (like SAML or OIDC) that is presented to other applications as proof of identity.
Advantages: improves the user experience, reduces “password fatigue,” and centralizes access management.
Risks: if the main account is compromised, an attacker could access all connected services. That’s why SSO must always be protected by Multi-Factor Authentication (MFA).

Federated identity 🌍

Federated identity is an evolution of SSO that works between different organizations. It allows a user from company A to access company B’s services using their own corporate credentials.

How does it work? It’s based on a trust relationship between the Identity Providers of the two organizations.
Advantages: eliminates the need to create duplicate accounts for external partners and collaborators, simplifying management and improving security.
Example: an external consultant accessing a client’s network using their own corporate account.

Federated authentication workflow 🔄

The federation process is orchestrated by standard protocols like SAML 2.0 or OpenID Connect (OIDC).

The user tries to access an application (Service Provider, SP).
The SP redirects the user to its Identity Provider (IdP) for authentication.
The user authenticates (with password and MFA).
The IdP generates an assertion (a digitally signed token) containing the user’s information and sends it to the SP.
The SP verifies the assertion’s signature, trusts the IdP, and grants the user access.

This flow avoids the proliferation of accounts and passwords, centralizing control and security.

Multi-factor authentication (MFA) 🛡️

Two (or more) factors to make sure it’s really you:

Something you know (password, PIN)
Something you have (OTP, physical key)
Something you are (fingerprint, location)

Tip: always enable MFA where possible, especially for administrative accounts and critical services.

Authorization: who can do what? 🗝️

RBAC (Role-based Access Control)

Permissions assigned based on company role. Simple to understand and govern.

Strengths: easy to audit, well supported in the cloud, great for stable scenarios.
Limits: can grow out of control (role explosion) and poorly handle dynamic conditions (e.g. time, device context).
Example: viewer, developer, ops, admin roles with scope on project/environment.
Best practice: fine-grained composite roles, separation between human roles and workload identity, avoid “catch-all” roles.

Useful pattern: map roles → permissions → resources with a clear scope (e.g. project:prod, namespace:payments). Use groups to assign roles to users.

ABAC (Attribute-based Access Control)

Permissions determined by attributes and conditions (e.g. time, department, location, device posture).

Strengths: flexible, contextual, reduces role proliferation.
Limits: complex rules, risk of inconsistency if not documented/versioned.
Example: “Finance department users can only access reports during office hours, from compliant devices and company IPs”.
Best practice: define an attribute data model, centralize policy (e.g. OPA/Rego), version the rules, and add tests.

Related advanced patterns:

ReBAC (Relationship-based): authorizations based on relationships (e.g. a graph “Alice is owner of repo X”). Useful for collaboration and shared resources.
PBAC (Policy-based): separates policies from code/roles using a policy engine (e.g. OPA), great for Zero Trust.

Operational tip: start from RBAC as a baseline and add ABAC for cases that require context (geography, device, time). Monitor the effect of rules with audits and metrics.

Secrets management 🤫

“Secrets” are the keys to the digital kingdom: passwords, API keys, tokens, certificates. If they fall into the wrong hands, the consequences can be disastrous. Managing them isn’t (just) a matter of trust, but a critical necessity that requires robust tools and processes to prevent unauthorized access, data leaks, and service interruptions.

Types of secrets 🔑

User and service passwords
API keys, encryption keys, SSH keys
TLS/SSL certificates
Cloud and database credentials
Temporary access tokens

Secret management: the truth table 📊

Entity	Secrets	IT infrastructure
Users	User credentials	App
App	API keys	Database
Services	Encryption keys	Cloud resources

Centralized secrets management 🧑‍💼

The practice of hardcoding secrets in code or configuration files is one of the leading causes of security incidents. A centralized secrets management system (like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault) solves this problem by providing:

Secure storage: secrets are encrypted both at rest (on-disk) and in transit (over-the-network) using robust cryptographic algorithms.
Automatic rotation: policies can enforce periodic rotation of passwords and keys, reducing the window of opportunity for an attacker in case of compromise.
Granular access control: only authorized identities (users or machines) can access specific secrets, and only for the strictly necessary time (just-in-time access).
Detailed audit and monitoring: every access, access attempt, or modification to a secret is logged, providing a complete audit trail for monitoring and forensic investigations.

Best practice: never store secrets in plaintext in code, configuration files, or Git repositories. Use centralized management systems and inject secrets dynamically at runtime. Automate rotation to reduce the risk associated with static, long-lived secrets.

Automatic rotation 🔄

Static secrets are an easy target. The longer a key or password remains unchanged, the greater the risk it will be compromised and misused. Automatic rotation is a proactive defense that periodically invalidates old credentials and replaces them with new ones.

Frequency: rotation frequency depends on the criticality of the secret. For example: API keys every 90 days, service passwords every 60-90 days, TLS certificates before expiration (with auto-renewal). Short-term access tokens might last only a few minutes.
Techniques: modern secrets management systems integrate with applications to make rotation transparent. They use secret versioning and dynamic references, so applications always retrieve the latest version without needing restarts or manual changes.
Antifragility: rotation shouldn’t be an exceptional event. Test it regularly in non-production environments to make sure the processes work correctly and to avoid surprises (and outages) in production.

Audit & monitoring 👀

If you can’t see it, you can’t protect it. Comprehensive logging of all secret access is essential for security and compliance. If something happens, the first question will be: “Who had access to what, and when?”.

Minimum logs: every log record should include: the identity that requested access (who), the secret that was accessed (what), the timestamp (when), the outcome of the operation (success/failure), the source IP address (from where), and, if possible, a justification for the access.
Useful alerts: configure automatic alerts for suspicious activity, such as a high number of failed access attempts, access to critical secrets outside normal working hours, or requests from unusual geographies.
Retention and protection: audit logs are sensitive data. They must be protected from tampering (for example, by writing them to WORM storage - Write-Once, Read-Many) and retained for a period defined by company and regulatory policies. Integration with a SIEM (Security Information and Event Management) system allows correlating events and getting an overall view of the security posture.

Data classification and segmentation 🗂️

Classifying and segmenting data is essential to know what to protect and how. Not all data is created equal!

Data classification 🏷️

Organize data based on sensitivity, value, and regulations. For example:

Public data: can be shared without issue
Internal data: accessible only to the organization
Confidential data: access limited to a few
Regulated data: subject to specific regulations (GDPR, PCI-DSS, HIPAA)

Sensitive and regulated data ⚖️

PII (personal data): name, email, phone, fingerprint, etc.
Financial data: transactions, accounts, credit cards.
PHI (health data): diagnoses, therapies, insurance…

Regulations: GDPR, CCPA, PCI-DSS, SOX, HIPAA, PIPEDA

Data segmentation 🪓

Divide data into separate segments by use, access, or compliance. That way, if someone gets in, they don’t find the whole treasure in one go.

Logical isolation 🧱

Separation through software: isolated virtual networks, granular permissions, encryption, tagging. Ideal for multi-tenant environments or for separating development, test, and production environments.

Pattern: account/project per environment, VPC/VNET per domain, subnet per tier, security boundary per team/product.
Tagging/labels: use them for access, encryption, backup, DLP, and cost allocation policies.
Zero Trust: apply per-service access policies (mTLS, identity-based policies) instead of trusted perimeters.

Physical isolation 🏢

Hardware separation: dedicated servers, specific regions, private cloud. Useful for highly sensitive data or for strict compliance needs.

Typical choices: regions with required data residency, dedicated hosts for regulated workloads, dedicated HSMs for critical keys.
Trade-off: higher costs, less elasticity; use it where the risk/compliance justifies it.

Encryption techniques 🔒

Encryption is the seatbelt of data: without it, every other control risks being useless.

Encryption at rest 🛌

Protect data stored on disks, databases, and backups. Use robust algorithms and manage keys carefully.

Practical choices: enable encryption by default on storage, databases, and snapshots/backups.
Keys: prefer a KMS with provider-managed keys (PMK) or customer-managed keys (CMK) where control/rotation is needed.
Verification: include encryption checks in pipelines and configuration benchmarks (CIS, org policy).

Encryption in transit 🚚

Protect data as it travels between clients, servers, and services. Use secure protocols like TLS and always verify the configuration.

TLS everywhere: enforce HTTPS, disable weak ciphers, use HSTS and modern TLS (1.2+ or 1.3).
mTLS: for internal service-to-service communications and for sensitive administrative access.
Rotation: automate certificate renewal and verify the chain (OCSP/CRL) where necessary.

Key management 🗝️

Encryption keys are the real treasure: they must be generated, stored, rotated, and revoked through secure processes. Never leave them in plaintext or in places accessible to everyone.

KMS/HSM: use key management services with certified HSMs for critical material.
Access: separate roles between key admin and data admin; apply dual-control for sensitive operations.
Lifecycle: define rotation policies, secure decommissioning, and traceability of key versions.

Data Loss Prevention (DLP) 🛑

Data Loss Prevention (or Data Leakage Prevention) is a set of strategies and tools designed to prevent sensitive data from leaving the organization’s boundaries in an unauthorized way, whether due to human error or malicious action. DLP doesn’t focus on incoming threats, but on controlling outgoing data.

DLP tools and practices act like an intelligent guardian:

They monitor network traffic, emails, instant messages, and file transfers to USB devices or cloud storage services.
They identify sensitive data based on rules, keywords, or regular expressions (e.g. credit card numbers, tax codes).
They block unauthorized transfers or apply corrective actions, such as automatic encryption or notification to a security officer.
They flag anomalous behavior that could indicate a data exfiltration attempt.

Tip: implement DLP policies gradually. Start in monitor-only mode to understand how data moves and to reduce false positives. Then, enable blocking rules for the most critical data categories. Examples of policies include: blocking external sharing of documents labeled “Confidential,” automatically masking IBANs in outgoing emails, or generating an alert when a user tries to upload an entire customer database to a personal storage service. Raising user awareness about the risks of improper sharing remains a fundamental component of any DLP strategy.

Network firewall and perimeter security 🔥

The firewall is the cloud’s doorkeeper: it decides who comes in and who goes out. A well-configured firewall blocks most of the most basic attacks.

Main firewall features 🌐

Access control: defines who can communicate with what
Intrusion prevention: blocks known attack attempts
Traffic monitoring: logs and analyzes traffic
Data privacy: protects data in transit

Security groups: the resource bodyguard 🦾

Virtual firewalls that control inbound and outbound traffic. Essential for cloud security. Define clear rules and limit access only to the necessary ports and IPs.

Principles: deny by default, whitelist the minimum necessary, separate ingress from egress.
Practices: use security groups per tier (web/app/db), limit SSH/RDP to bastion/SSM, prefer private endpoints.
Visibility: enable flow logs for auditing and tuning rules.

Inbound and outbound rules 🚦

Inbound rules establish who can access resources. Outbound rules control what can leave. Review them regularly and close anything that isn’t needed.

Inbound: expose only necessary ports (e.g. 443), filter by CIDR or source (LB/WAF). No 0.0.0.0/0 on sensitive ports.
Outbound: limit egress to the Internet; use controlled NATs, egress-only for IPv6, and policies based on domains/services.
Change management: version the rules, validate in staging, automate deployment with IaC and controls.

Web Application Firewall (WAF) 🕸️

The WAF protects apps and APIs from the most common threats (and from a few overly curious users). It’s essential for anyone exposing web services on the Internet.

Most common external threats 🚨

DDoS: attacks aimed at saturating resources
Application vulnerabilities: SQL injection, XSS, etc.
Bots: scraping, brute force, malicious automation

Key WAF features 🛡️

Customizable rule-based filters
Protection against the OWASP Top 10
Bot and DDoS mitigation
Real-time monitoring and alerts

WAF best practices:

Initial “monitor” mode to reduce false positives, then gradual enforcement.
Integration with CI/CD to update rules alongside releases.
Rate limiting, geo/IP reputation, API protection (schema validation, JWT checks).

Operational checklist 🧰

IAM: MFA everywhere, protected SSO, minimal roles, quarterly permission review.
Secrets: centralized vault, automatic rotation, never in repos, access audits.
Data: classification, segmentation by environment/project, encrypted and tested backups.
Encryption: mandatory TLS, KMS-managed encryption at rest, key rotation.
Network: restrictive security groups, controlled egress, bastion/zero-trust for admins.
WAF/DDoS: OWASP Top 10 rules, rate limiting, bot and CDN protection.
DLP: rules on email/storage, anomaly alerts, user awareness.
Logging: log centralization, defined retention, alarms on critical events.

Related resources 🔗

Cloud security is never “finished”. It must be reviewed, updated, and tested regularly. And remember: the best defense is the awareness of whoever uses and manages the cloud.

Last updated on 17 August 2026

Cryptography 🔐