Cloud migration has accelerated across every sector. According to the Flexera State of the Cloud 2025 report, more than 87% of enterprises today use at least two cloud platforms simultaneously. As this growth continues, so does the attack surface — and misconfigurations, improper access policies and lack of monitoring cost organizations millions of dollars annually. The Verizon Data Breach Investigations Report 2024 indicates that cloud misconfiguration accounts for more than 21% of all data breaches in enterprise organizations.
Securing AWS, Azure and GCP environments is not a one-time project — it is a continuous process that requires familiarity with each platform’s specifics, shared responsibility models and the native tools offered by cloud providers. In this article, I present specific steps, tools and configurations that nFlo applies during cloud security audits and deployments for our clients.
Why Does Public Cloud Require a Different Approach to Security Than On-Premises?
In an on-premises environment, an organization controls the entire physical layer — servers, switches, cabling, cooling and power systems. Perimeter security rested on the assumption that everything inside the network is trusted and threats come from the outside. This model, while imperfect, at least provided the illusion of full control.
Public cloud turns this model upside down. Physical infrastructure belongs to the provider — AWS, Microsoft or Google. Resources are shared at the hypervisor level, the network is programmable and configured through APIs, and data access occurs over the internet. This means the traditional perimeter ceases to exist, and any misconfiguration can immediately be exposed to the entire world.
New attack vectors in the cloud are fundamentally different from those known in on-premises environments. Attacks focus on credential theft, excessive permissions for service accounts, public exposure of resources (such as open S3 buckets) and exploitation of instance metadata services (IMDS). The Cloud Security Alliance 2024 report indicates that as many as 74% of cloud security incidents were the result of human error — not sophisticated technical attacks.
The elasticity of the cloud — the ability to launch hundreds of resources within minutes — is simultaneously its greatest risk. A developer can accidentally launch a public database instance without a password, leave an open management port accessible from the internet, or grant a role overly broad permissions. In an on-premises environment, such a mistake would require physical access to the infrastructure; in the cloud, a single click or a poorly thought-out Terraform file is sufficient.
Key differences requiring a different approach include: dynamic and ephemeral infrastructure (resources appear and disappear automatically), API programmability as the primary attack vector, usage-based billing (which means a compromised account generates costs), global reach (data may end up in an inappropriate geographic zone) and multi-cloud complexity. Cloud security must be embedded in DevOps processes, not added at the end as a protective layer.
Key principle: In the cloud, the default assumption must be Zero Trust — no user, service or resource is trusted by default. Every access requires verification, authorization and logging.
📚 Read the complete guide: Cloud Security / AWS: Bezpieczeństwo chmury publicznej - AWS, Azure, best practices
What Is the Shared Responsibility Model in the Context of AWS, Azure and GCP?
The Shared Responsibility Model is a fundamental principle of cloud security whose misunderstanding leads to the majority of serious incidents. Each of the three major providers defines it slightly differently, but the general principle is the same: the cloud provider is responsible for the security of the infrastructure, the customer is responsible for the security of what they place in the cloud.
In the case of AWS, the division is as follows: Amazon is responsible for the physical security of data centers, hardware, hypervisor software and network infrastructure. The customer is responsible for guest operating systems (in the case of IaaS), security group configurations, data encryption, identity and access management, and the configuration of services such as S3, RDS and Lambda. In other words: if you leave an S3 bucket public — that is your mistake, not Amazon’s.
Azure applies a similar model, but with a nuance arising from its broad SaaS offering (Microsoft 365). In the case of IaaS (virtual machines), responsibility for the operating system, applications and data lies with the customer. In the case of PaaS (App Service, Azure SQL), Microsoft manages the platform, but configuration, data and access remain the customer’s responsibility. Google Cloud Platform applies the same principles, emphasizing in its documentation that “security is everyone’s job.”
The practical consequences of this model are often surprising for organizations. Many companies assume that since they have moved their infrastructure to a reputable provider, its security is “taken care of.” Yet breaches such as Capital One (2019, misconfigured WAF on AWS), Uber (2022, Okta account takeover) and the Microsoft Exchange Online data leak (2023) show that the errors lie on the customer or operator side — not on the provider’s infrastructure side.
Practical note: Before each cloud service, ask yourself: “What happens if this service is publicly accessible by default?” For S3, Azure Blob Storage and Google Cloud Storage the answer is: “Your data will be accessible to the entire internet.” Check default settings for every newly created service.
Understanding the boundaries of responsibility has a direct impact on designing security policies. An organization must cover with its controls all the layers it is responsible for — from the operating system, through the configuration of managed services, all the way to access management and monitoring. The provider supplies the tools; the customer must use them correctly.
How to Secure Identity and Access in the Cloud — IAM, MFA, Roles, Policies?
Identity and Access Management (IAM) is the absolute foundation of cloud security. The takeover of a privileged account gives an attacker unrestricted access to all resources in the environment. That is why IAM hardening is the first step of every security audit conducted by nFlo.
The Principle of Least Privilege (PoLP) must be implemented consistently at all levels. In AWS, this means creating IAM policies with precisely defined actions, resources and conditions — never "Action": "*" or "Resource": "*" in production policies. In Azure, we apply Role-Based Access Control (RBAC) with custom roles instead of built-in Owner or Contributor roles. In GCP, the key is to use predefined roles at the project or folder level, never at the organization level for regular users.
Service accounts and roles for applications require particular attention. In AWS, every Lambda function, EC2 instance or ECS container should have a dedicated IAM role with the minimum permissions required to operate. In Azure, we use Managed Identities instead of storing credentials in code or environment variables. In GCP — Service Accounts with granularly defined roles. Particularly dangerous is attaching service accounts with administrative permissions to virtual machines accessible from the internet.
Multi-factor authentication (MFA) must be mandatory for all human accounts — without exception. In AWS, we configure a Service Control Policy (SCP) blocking access for users without active MFA. Azure Entra ID (formerly Azure AD) offers Conditional Access Policies enabling enforcement of MFA for specific applications, locations or risk levels. In GCP, we apply an Organization Policy with an MFA requirement along with Cloud Identity Aware Proxy (IAP) for access to internal resources.
Practical note: Never use the root account (AWS) or Global Administrator (Azure) for day-to-day work. The root account should have MFA enabled, possess no API keys and be used exclusively for tasks that cannot be performed any other way. There are literally only a handful of such tasks — changing billing details, account recovery, certain organization settings.
Rotation and management of access keys is another critical issue. API keys (AWS Access Keys, GCP Service Account Keys) should be rotated every 90 days. Tools such as AWS IAM Access Analyzer, Azure AD Access Reviews and GCP Security Command Center help identify unused permissions, API keys older than a specified time and excess access. In an ideal world, long-term keys are replaced with temporary tokens generated by AWS STS, Azure Managed Identities or GCP Workload Identity Federation.
Federated Identity and Single Sign-On (SSO) allow centralized access management. Integrating AWS IAM Identity Center (formerly SSO), Azure Entra ID and GCP Cloud Identity with a corporate IdP (Okta, Azure AD, Google Workspace) enables granting and revoking access in a single place. This is particularly important during employee offboarding — deactivating an account in the central IdP automatically removes access to all associated cloud environments.
How to Detect Misconfigurations — The Most Common Cloud Vulnerabilities?
Misconfigurations are the most common causes of cloud security breaches. Gartner estimates that through 2025, 99% of cloud security incidents will result from customer errors — not provider errors. That is why systematic detection and remediation of misconfigurations must be a continuous process, not a one-time project.
The most common AWS misconfigurations are: public S3 buckets without block public access enabled, Security Groups with open port 22 (SSH) or 3389 (RDP) accessible from 0.0.0.0/0, RDS instances without encryption and publicly accessible, CloudTrail not enabled in all regions, excessive IAM policies and lack of key rotation in AWS Secrets Manager or KMS. AWS Security Hub, integrating results from AWS Config Rules, Amazon GuardDuty and AWS Inspector, is used to detect these errors.
In Azure, typical vulnerabilities include: Storage Account with public blob access enabled, virtual machines with a public IP but without a Network Security Group, Microsoft Defender for Cloud (formerly Security Center) not enabled, SQL Server configurations without Transparent Data Encryption (TDE), Key Vault without soft-delete and purge protection, and excessive Owner role assignments. Azure Policy and Microsoft Defender for Cloud automatically detect these issues and assign them a Secure Score.
Google Cloud Platform has its own set of common misconfigurations: public Cloud Storage buckets, Compute Engine instances with a public IP and open management ports, Service Accounts with excessive permissions or with keys not rotated in over 90 days, Cloud Audit Logs not enabled for critical services, projects without VPC Service Controls enabled, and APIs without appropriate restrictions. Security Command Center (SCC) in its Premium version scans the GCP environment and classifies findings by threat level.
Cloud Security Posture Management (CSPM) is a class of tools specifically designed for the continuous monitoring of cloud environment configurations. Solutions such as Wiz, Orca Security and Lacework connect to the APIs of all major providers and continuously assess the security posture of resources. In multi-cloud environments, CSPM is essential — manually tracking configurations for hundreds of services across three clouds simultaneously is practically impossible.
Practical note: Infrastructure as Code (IaC) — Terraform, AWS CloudFormation, Bicep, Pulumi — should be scanned for misconfigurations before deployment. Tools such as Checkov, KICS (Checkmarx), tfsec and Terrascan integrate with CI/CD pipelines and block the deployment of resources with critical vulnerabilities. This “shift-left” approach eliminates errors before they reach production.
Regular penetration tests focused on the cloud complement automated scanning. Techniques such as SSRF (Server-Side Request Forgery) to extract EC2 instance metadata, privilege escalation through vulnerable IAM policies and supply chain attacks in CI/CD pipelines are characteristic of cloud environments and require specialized expertise. At nFlo, we conduct dedicated penetration tests of AWS, Azure and GCP environments with comprehensive reporting and support during remediation of identified vulnerabilities.
How to Monitor Cloud Security — CloudTrail, Azure Monitor, Cloud Audit Logs?
Security monitoring in the cloud begins with logging every action taken in the environment. API calls, configuration changes, logins, data operations — everything must be recorded in immutable logs stored outside the production environment. Without this, restoring the state after an incident and conducting forensics is impossible.
AWS CloudTrail is the foundation of monitoring in the Amazon ecosystem. CloudTrail records every API call — who, from where, when and what was done in your AWS account. A production configuration should include: a Trail with logging enabled in all regions (including global regions), an S3 bucket with MFA Delete and Object Lock enabled (Compliance mode), integration with CloudWatch Logs for real-time alerts, data event logging enabled (S3 GetObject/PutObject) for critical buckets and integration with AWS Security Hub. CloudTrail logs should be retained for a minimum of 13 months.
Azure Monitor together with Activity Log and Microsoft Sentinel creates a complete monitoring ecosystem in the Microsoft environment. Activity Log records operations at the subscription level — creating/deleting resources, role changes, Key Vault operations. Diagnostic Settings for individual resources (Storage Account, SQL Database, Key Vault) forward detailed logs to a Log Analytics Workspace. Microsoft Sentinel, as a cloud-native SIEM, allows correlating events, detecting anomalies and automating incident response using Playbooks (Logic Apps). Built-in detection rules cover, among others, impossible travel, mass resource deletion and logins from suspicious IPs.
Google Cloud offers Cloud Audit Logs consisting of three types: Admin Activity Logs (enabled by default, record configuration changes), Data Access Logs (require enabling, record data access) and System Event Logs (automatic, record system events). All logs go to Cloud Logging, from where they can be exported to BigQuery (historical analysis), Cloud Storage (archiving) or an external SIEM. Security Command Center integrates detection results with Event Threat Detection — a service that detects malicious activities based on log analysis.
Practical note: Store security logs outside the production account/subscription/project. An attacker who has taken over a production account will begin by deleting logs. In AWS, create a dedicated Logging Organization account with restricted access. In Azure, use a central Log Analytics Workspace in a dedicated Security subscription. In GCP, use a dedicated project for centralizing logs with a retention policy enabled.
Alerts and anomaly detection must be configured for key security events. A minimum list of alerts should include: logins to the root/global admin account, changes to IAM and RBAC policies, creation/deletion of API keys, changes to firewall rules, public exposure of resources (S3, Blob Storage, GCS), large data transfers outside the organization and disabling of logging or monitoring. AWS GuardDuty, Microsoft Defender for Cloud and GCP Security Command Center offer built-in detection rules, which should be supplemented with custom rules tailored to the organization’s specific characteristics.
Integration with SIEM (Security Information and Event Management) allows correlating events from multiple sources. Popular solutions include Microsoft Sentinel (particularly for Azure environments), Splunk with integrators for all three clouds, Elastic SIEM and Chronicle (Google). In multi-cloud environments, nFlo recommends centralizing logs from all clouds in a single SIEM, which enables detection of attacks moving between platforms (for example, Azure AD account takeover → access to AWS through federation).
How to Implement Data Encryption at Rest and in Transit?
Data encryption is one of the pillars of cloud security and a requirement of most compliance standards (GDPR, ISO 27001, PCI DSS, NIS2). In the AWS, Azure and GCP ecosystems, encryption is natively available for almost every service — the key is its correct configuration and encryption key management.
Encryption of data at rest should be enabled for all data repositories — without exception. In AWS, this applies to: Amazon S3 (Server-Side Encryption with KMS keys or SSE-S3), EBS Volumes (encryption through the default setting at the account level), RDS (encryption of instances and snapshots), DynamoDB (AWS-managed encryption or custom KMS keys), EFS and FSx. AWS Config Rules encrypted-volumes and rds-storage-encrypted automatically identify unencrypted resources. In Azure, encryption is enabled by default for Managed Disks, Azure Storage and Azure SQL Database, but older resources and configurations must be verified. In GCP, all data is encrypted by default by Google, but for sensitive data, Customer-Managed Encryption Keys (CMEK) or Customer-Supplied Encryption Keys (CSEK) should be used.
Encryption key management is an area that is often neglected. The difference between provider-managed encryption (SSE-S3, Google-managed keys) and customer-key encryption (AWS KMS CMK, Azure Key Vault, GCP Cloud KMS) is fundamental from a control perspective. If the provider manages the keys, they could technically decrypt your data. Organizations processing particularly sensitive data should use their own keys (BYOK — Bring Your Own Key) or even hardware security modules (HSM — Hardware Security Module): AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM.
Practical note: AWS KMS CMK, Azure Key Vault and GCP Cloud KMS offer automatic rotation of encryption keys. Enable automatic rotation with the maximum recommended period (AWS: annually, Azure Key Vault: from 30 days to 2 years). Key rotation does not require re-encrypting data — providers handle this transparently through wrapping Data Encryption Keys (DEK) with Key Encryption Keys (KEK).
Encryption of data in transit is today a standard — all communications between cloud services should use TLS 1.2 or higher. In AWS, S3 bucket policies can enforce access exclusively via HTTPS (aws:SecureTransport: true). For custom applications running on EC2 or ECS, we deploy TLS certificates through AWS Certificate Manager (ACM). Azure enforces TLS for all managed services, but for older configurations, minimum supported TLS versions should be verified. In GCP, all connections to managed services are encrypted, and for internal connections between services we apply VPC Service Controls and mTLS.
TLS certificates for custom applications are managed through: AWS Certificate Manager (free certificates for load balancers and CloudFront), Azure App Service Managed Certificates or Azure Key Vault, Google-managed certificates for Cloud Load Balancing or Let’s Encrypt integrated via Cert-Manager in GKE. The key principle: no self-signed certificates in production environments, and full automation of certificate renewal.
End-to-end encryption for particularly sensitive data — payment card numbers, medical data, biometric data — may require application-level encryption, where data is encrypted before reaching the database. In such a case, even a database administrator does not have access to decrypted data. In AWS, a similar effect is achieved through AWS Nitro Enclaves for isolated computation on sensitive data.
How to Secure the Network in the Cloud — VPC, Security Groups, WAF?
Network architecture in the cloud must be designed according to the principle of Defense in Depth — multilayered protection where breaching one layer does not automatically grant access to internal resources. The foundation is the correct design of the Virtual Private Cloud (VPC) and network segmentation.
VPC (Virtual Private Cloud in AWS and GCP, Virtual Network in Azure) creates an isolated network environment in the cloud. A proper VPC design assumes a division into public and private subnets: resources accessible from the internet (Load Balancers, NAT Gateway, bastion hosts) are placed in public subnets, while applications, databases and internal resources are placed exclusively in private subnets with no direct internet access. In AWS, we apply a three-tier model: Public Subnet (ALB/WAF) → Private Subnet (EC2/ECS applications) → Isolated Subnet (RDS, ElastiCache). Routing between subnets is controlled through Route Tables and Network ACLs.
Security Groups (AWS, GCP) and Network Security Groups (Azure) are the first line of defense at the network level. Key configuration principles: a default Deny All rule for inbound traffic, opening only necessary ports, restricting sources to specific CIDRs or other Security Groups (not 0.0.0.0/0), separate Security Groups for each application tier. In AWS, the best practice is referencing Security Groups rather than IP ranges — a rule “allow traffic from ALB SG to App SG” is more precise and resilient to IP changes than a CIDR range.
Practical note: Regularly audit Security Group and NSG rules. In AWS, use AWS Config Rule
restricted-sshandrestricted-common-portsor AWS Security Hub. Pay particular attention to rules with a source of 0.0.0.0/0 and the following ports: 22 (SSH), 3389 (RDP), 1433 (MSSQL), 3306 (MySQL), 5432 (PostgreSQL), 27017 (MongoDB), 6379 (Redis). None of these ports should be directly accessible from the internet in a production environment.
Web Application Firewall (WAF) protects web applications from application-layer attacks — SQL Injection, XSS, CSRF, bots, scrapers and OWASP Top 10 exploits. AWS WAF v2 integrates with CloudFront, ALB and API Gateway. Azure WAF works with Application Gateway and Azure Front Door. GCP Cloud Armor protects Load Balancers. A minimum WAF configuration includes: enabled managed rule sets (AWS Managed Rules, OWASP Core Rule Set), rate limiting for protection against application-layer DDoS, geo-blocking for regions from which traffic is not expected, and Detection mode (monitoring) before switching to Prevention mode (blocking) — to avoid false positives.
DDoS Protection is a separate protection layer for volumetric and protocol-based attacks. AWS Shield Standard is available free of charge for all customers and protects against most layer 3 and 4 attacks. AWS Shield Advanced (subscription) offers protection against sophisticated attacks, access to the AWS DDoS Response Team and a guarantee of cost reimbursement resulting from an attack. Azure DDoS Protection Basic is built into the platform; Azure DDoS Protection Standard (subscription per VNet) offers advanced mitigation profiles. GCP Cloud Armor Enterprise provides DDoS protection with ML-based adaptive protection.
Hybrid connections — Site-to-Site VPN or Direct Connect (AWS)/ExpressRoute (Azure)/Cloud Interconnect (GCP) — link the cloud environment with the on-premises network. Site-to-Site VPN is a cheaper but less performant solution (up to 1.25 Gbps per IPsec tunnel). Dedicated connections (Direct Connect, ExpressRoute, Interconnect) offer lower latency, higher throughput and do not use the public internet — which is a requirement of some regulations. In both cases, traffic encryption and strict routing rules limiting access between environments should be applied.
How to Manage Compliance in a Multi-Cloud Environment?
Managing compliance in an environment that uses multiple cloud platforms simultaneously is one of the most difficult operational challenges. Each platform offers its own compliance assessment tools, which must be combined into a coherent picture for auditors, regulators and management.
Standards and regulations applicable to cloud environments in Europe are primarily: GDPR — requiring data locality and data subject rights, NIS2 — the EU directive implemented in Poland through the Act on the National Cybersecurity System (2024 update), ISO 27001:2022 — the information security management standard (updated to include cloud requirements), PCI DSS 4.0 — the standard for organizations processing payment card data, SOC 2 Type II — a report for SaaS providers and DORA — Digital Operational Resilience Act for the financial sector (effective from 2025).
AWS offers AWS Config with over 300 built-in rules assessing compliance with CIS Benchmarks, PCI DSS, HIPAA, NIST and other standards. AWS Security Hub aggregates results from Config, GuardDuty, Inspector and Macie into a single dashboard with a security score. AWS Audit Manager automates the collection of audit evidence. Azure Policy and Microsoft Defender for Cloud’s Regulatory Compliance dashboard offer similar functionality with mapping to NIST 800-53, PCI DSS, ISO 27001 and other frameworks. In GCP, Security Command Center provides compliance visibility against the CIS GCP Foundations Benchmark, PCI DSS and NIST.
Practical note: Compliance does not equal security. An organization can be fully compliant with ISO 27001 certification requirements and simultaneously have critical vulnerabilities in its cloud configuration. Treat compliance as a minimum, not an end goal in itself. The real goal is the reduction of operational risk — compliance is its derivative.
Configuration management and drift detection are critical components of multi-cloud governance. “Configuration drift” means a deviation of the actual resource configuration from the state defined in IaC (Infrastructure as Code). AWS Config continuous compliance monitoring detects drifts in real time. Terraform Cloud/Enterprise offers drift detection as a built-in feature. Organizational policies — AWS Service Control Policies, Azure Policy Initiatives, GCP Organization Policy Constraints — define guardrails at the organization level, preventing the creation of non-compliant resources.
Centralized multi-cloud management requires tools that aggregate data from all platforms. Solutions such as Wiz, Orca Security, Prisma Cloud and Lacework offer unified security posture management covering all three major clouds. They allow normalization of results from different platforms, risk prioritization and tracking of vulnerability remediation progress in a single place. At nFlo, we use these tools when deploying solutions for clients operating in multi-cloud environments.
Documentation and audit evidence must be collected automatically. Manually collecting screenshots, console management exports and logs is error-prone and inefficient during audits covering hundreds of resources across three clouds. AWS Audit Manager, Azure Compliance Manager and GCP Assured Workloads automate the collection and organization of compliance evidence. Automated reports can be exported and delivered directly to auditors from the platforms.
What Does a Cloud Security Checklist Look Like?
The following table presents a strategic public cloud security checklist divided by area, priority and mapping to specific tools for each platform. The checklist is based on CIS Cloud Security Benchmarks, NIST CSF 2.0 recommendations and nFlo’s experience from 500+ security projects.
| Area | Security Control | Priority | AWS | Azure | GCP |
|---|---|---|---|---|---|
| Identity and access | No API keys for root/admin account | Critical | IAM Root Settings | Entra ID Global Admin | GCP Organization Admin |
| Identity and access | MFA for all IAM users | Critical | IAM MFA Policy + SCP | Entra Conditional Access | Cloud Identity MFA |
| Identity and access | Principle of Least Privilege | High | IAM Access Analyzer | Azure AD Access Reviews | IAM Recommender |
| Identity and access | API key rotation every 90 days | High | IAM Credential Report | Azure AD App Registrations | Service Account Key Rotation |
| Identity and access | SSO/Federated Identity | High | IAM Identity Center | Entra ID SAML/OIDC | Cloud Identity SSO |
| Logging and monitoring | CloudTrail/Activity Log/Audit Logs enabled in all regions | Critical | AWS CloudTrail | Azure Activity Log | Cloud Audit Logs |
| Logging and monitoring | Logs stored outside production account | Critical | S3 + Object Lock | Log Analytics (separate sub.) | Cloud Logging Export |
| Logging and monitoring | Alerts for critical events | High | CloudWatch Alarms | Azure Monitor Alerts | Cloud Monitoring Alerts |
| Logging and monitoring | SIEM integration | High | Security Hub → SIEM | Sentinel | Chronicle / SIEM |
| Logging and monitoring | Log retention min. 12 months | High | S3 Lifecycle | Log Analytics Retention | Cloud Logging Retention |
| Resource configuration | Block public access to storage | Critical | S3 Block Public Access | Storage Account Public Access | Uniform Bucket-Level Access |
| Resource configuration | No open management ports (SSH/RDP) from internet | Critical | Security Groups | NSG Rules | VPC Firewall Rules |
| Resource configuration | CSPM enabled and active | High | Security Hub | Defender for Cloud | Security Command Center |
| Resource configuration | IaC scanning in CI/CD | High | cfn-guard/Checkov | Checkov/KICS | Checkov/KICS |
| Resource configuration | Config drift detection | High | AWS Config | Azure Policy | Config Connector |
| Encryption | Storage encryption at rest | Critical | SSE-KMS | Azure Storage Encryption | CMEK |
| Encryption | Database encryption | Critical | RDS Encryption | TDE (SQL) / CMK | Cloud SQL CMEK |
| Encryption | TLS 1.2+ for all connections | High | ACM + ALB Policy | Azure Front Door / App GW | Cloud Load Balancing |
| Encryption | KMS/Key Vault/Cloud KMS key rotation | High | KMS Key Rotation | Key Vault Key Rotation | Cloud KMS Rotation |
| Encryption | No hardcoded secrets in code | High | AWS Secrets Manager | Azure Key Vault | Secret Manager |
| Network | Segmentation into public/private subnets | High | VPC Subnets | Azure VNet Subnets | GCP VPC Subnets |
| Network | WAF for web applications | High | AWS WAF | Azure WAF | Cloud Armor |
| Network | VPC Flow Logs enabled | High | VPC Flow Logs | NSG Flow Logs | VPC Flow Logs |
| Network | DDoS Protection | High | Shield Standard/Advanced | DDoS Protection Standard | Cloud Armor |
| Network | Private endpoints for managed services | Medium | VPC Endpoints | Private Endpoints | Private Service Connect |
| Compliance | Continuous compliance assessment (CIS/NIST/PCI) | High | Security Hub Standards | Defender Regulatory Comp. | Security Command Center |
| Compliance | Automated audit evidence collection | High | Audit Manager | Compliance Manager | Assured Workloads |
| Compliance | Penetration testing at least once per year | High | AWS Pentest Policy | Azure Pentest Policy | GCP Pentest Policy |
| Incident response | Cloud incident response plan | Critical | AWS IRP | Azure IRP | GCP IRP |
| Incident response | Automated remediation (SOAR) | High | Security Hub Actions | Sentinel Playbooks | SIEM + Cloud Functions |
How Does nFlo Audit and Secure Client Cloud Environments?
nFlo has carried out more than 500 security projects for over 200 clients in Poland and Europe, a significant proportion of which involve AWS, Azure and GCP cloud environments. Over the years, we have developed an audit and cloud security deployment methodology that combines automated scanning with manual verification and real penetration testing.
A cloud security audit at nFlo proceeds through several stages. The first step is the Discovery phase — automated collection of information about all resources in the environment using the native APIs of each platform. We inventory IAM accounts/users, compute resources, storage, databases, network configurations, security policies and logs. At this stage, we frequently uncover “shadow IT” — resources launched by developers without the knowledge of the security team and never mapped to compliance requirements.
The Assessment phase involves automated compliance evaluation against CIS Benchmarks for each platform (CIS AWS Foundations Benchmark 2.0, CIS Microsoft Azure Foundations Benchmark 2.0, CIS Google Cloud Platform Foundation Benchmark 2.0) supplemented by manual testing. We examine: the effectiveness of IAM policies (whether they genuinely implement the principle of least privilege), the real exploitability of detected vulnerabilities (not every “high” result from an automated scanner is in fact a high risk in a given environment), the quality of logging and the ability to reconstruct event history, encryption configurations and network architecture.
Practical note: In 98% of cloud audits conducted by nFlo, we discover at least one critical or high-severity vulnerability that the client was unaware of before the audit. The most common findings are: public S3/Blob Storage buckets containing customer data, API keys with administrator permissions in application code available on GitHub, and database instances directly accessible from the internet without connection encryption.
After the audit, we prepare a report with findings prioritized by real business risk — not just the technical CVSS score. For each vulnerability, we provide detailed remediation instructions, helper scripts (Terraform, Python/boto3, az CLI) and guidance on verifying correct remediation. We also offer participation in the remediation process — we do not leave clients alone with a list of problems to solve.
Security baseline deployments are a service where nFlo configures a complete security environment from scratch or adapts an existing environment to meet compliance requirements. This includes: configuring AWS Organizations/Azure Management Groups/GCP Organization with an account and policy hierarchy, implementing centralized logging and monitoring (AWS Security Hub + GuardDuty + CloudTrail, Microsoft Sentinel, GCP Security Command Center), configuring CSPM, implementing IaC policies that prevent the creation of non-compliant resources, and deploying incident management procedures and tools.
Continuous security monitoring (Managed Cloud Security) is a service where nFlo assumes responsibility for ongoing monitoring and threat response in clients’ cloud environments. This includes 24/7/365 monitoring, alert response within under 15 minutes, monthly security reports with trends and recommendations, and quarterly configuration reviews. A client retention rate of 98% demonstrates the effectiveness of this service. Clients report a 90% reduction in risk after 12 months of working with nFlo — measured by the number and severity of security incidents.
Related Concepts
Explore key terms related to cloud security in our cybersecurity glossary:
- Zero Trust — A security model that assumes no default trust for any user, device or network
- Encryption — The process of converting data into encrypted text unreadable without the appropriate key
- Firewall — A security system that monitors and controls network traffic
- SOC 2 — An AICPA audit standard assessing security, availability and confidentiality controls
- Cybersecurity — A collection of techniques, processes and practices for protecting IT systems
Learn More
Explore related articles in our knowledge base:
- IT Infrastructure Security — The Key to Protecting Modern Organizations
- 12 Tips on How to Improve Cybersecurity in Your Organization
- DDoS Attack Protection — Strategies, Implementation and Best Practices
- How to Implement an Effective Cybersecurity Incident Response Plan?
- What Is Data Protection and How to Implement Effective Procedures in Your Organization?
Check Our Services
Do you need support in the area of cloud security? See:
- Security Audits — comprehensive assessment of cloud environment security posture
- Penetration Testing — identification of vulnerabilities in AWS, Azure and GCP infrastructure
- SOC as a Service — round-the-clock security monitoring of cloud environments
Schedule a Free Consultation →
FAQ — Public Cloud Security
Is public cloud secure for sensitive data?
Yes, public cloud can be secure even for particularly sensitive data — provided it is correctly configured and appropriate control mechanisms are applied. AWS, Azure and GCP hold ISO 27001, PCI DSS, SOC 2 Type II and many other industry certifications. The key is understanding the Shared Responsibility Model and taking full responsibility for service configuration, access management, encryption and monitoring. Regulated organizations (financial sector, healthcare) successfully use public cloud by applying additional controls such as Customer-Managed Encryption Keys, VPC Service Controls and dedicated network connections.
How quickly can basic cloud security controls be deployed?
A basic security baseline for a new AWS, Azure or GCP environment can be deployed within 2–5 business days given the appropriate resources and competencies. This includes: configuring an account hierarchy with SCP/Azure Policy/Org Policy, enabling centralized logging (CloudTrail/Activity Log/Cloud Audit Logs), launching CSPM (Security Hub/Defender for Cloud/Security Command Center), configuring alerts for critical events and enforcing MFA for all users. A full deployment of a mature cloud security program — with IaC scanning, SOAR, incident response procedures and compliance — takes several weeks to several months depending on the scale of the environment.
How much does cloud security cost?
Cloud security costs consist of several elements: native security services from providers (AWS GuardDuty, Security Hub, Inspector; Microsoft Defender for Cloud; GCP Security Command Center Premium), CSPM/CNAPP tools (Wiz, Prisma Cloud, Orca — typically from $15,000 to $100,000 per year depending on the number of resources), logging and log storage costs (CloudWatch, Log Analytics, Cloud Logging — a few to several tens of percent of infrastructure costs) and external services (audits, penetration testing, managed security). Cloud security costs should be compared against the cost of an incident — according to the IBM Cost of a Data Breach 2024 report, the average cost of a data breach is $4.88 million globally.
What is CNAPP and do I need this solution?
CNAPP (Cloud-Native Application Protection Platform) is an integrated security platform combining CSPM (Cloud Security Posture Management), CWPP (Cloud Workload Protection Platform), CIEM (Cloud Infrastructure Entitlement Management) and container security functions. CNAPP solutions — such as Wiz, Prisma Cloud or Lacework — offer a holistic view of security across the entire cloud environment: from infrastructure configuration, through permissions, to vulnerabilities in running applications and containers. For organizations with mature cloud environments (above several hundred resources) or operating in multi-cloud environments, CNAPP is strongly recommended. For smaller environments, the native tools of individual platforms may be sufficient.
How often should I conduct a cloud security audit?
We recommend a model of continuous monitoring supplemented by periodic in-depth audits. Automated configuration scanning (via CSPM) should operate in real time, 24/7. A manual audit with penetration testing should be conducted at a minimum of once per year or after any significant architectural change (for example, migration to a new cloud or launch of a new application). Compliance standards such as PCI DSS and ISO 27001 require regular audits (typically annual). In regulated sectors (finance, healthcare, critical infrastructure) audits may be required more frequently. After every identified security incident, a retrospective audit should be conducted in the area affected by the incident.
Sources
- Flexera State of the Cloud Report 2025 — flexera.com/learn/cloud/state-of-the-cloud
- Verizon Data Breach Investigations Report 2024 — verizon.com/business/resources/reports/dbir
- IBM Cost of a Data Breach Report 2024 — ibm.com/reports/data-breach
- Cloud Security Alliance Cloud Threat Report 2024 — cloudsecurityalliance.org
- CIS AWS Foundations Benchmark v2.0 — cisecurity.org
- CIS Microsoft Azure Foundations Benchmark v2.0 — cisecurity.org
- CIS Google Cloud Platform Foundations Benchmark v2.0 — cisecurity.org
- NIST Cybersecurity Framework 2.0 — nist.gov/cyberframework
- AWS Security Best Practices — docs.aws.amazon.com/security
- Microsoft Azure Security Benchmark v3 — docs.microsoft.com/security/benchmark
- Google Cloud Security Foundations — cloud.google.com/security
Related topics
See also:
