Unified Cloud Security for a Multi-Cloud FinTech: Replacing Native Tools, Manual Access, and Siloed Visibility Across AWS, GCP, and OCI

Customer Snapshot

Attribute	Details
Industry	Financial Services / FinTech
Cloud Environment	AWS (largest), GCP (medium), OCI (recent, 2 workloads)
Workloads	Kubernetes (EKS on AWS, GKE on GCP)
IAM	AWS IDC + GCP, Google Workspace → Keycloak → Cloud RBAC
Users & Accounts	~500 users, 10+ cloud accounts
Code & CI/CD	GitHub
VPN	Palo Alto GlobalProtect
Compliance	Data residency requirements across India, Middle East, US
Existing Security	Native AWS tools, native GCP tools, Checkmarx (SAST/Secrets), Akamai (API Security)
DAM Partner	Orva Networks (services partner for DAM and DPDP)
Primary Interest	Unified CSPM, Rightsizing, CWPP, JIT Cloud Access, DAM (data flow visibility)

The Situation: Mature, Multi-Cloud, and Manually Managed

This is a large FinTech organisation operating across three cloud providers with a sophisticated identity architecture and a significant Kubernetes footprint. AWS is the primary cloud, GCP is a substantial secondary environment, and OCI was recently introduced with two initial workloads. Their infrastructure supports operations across India, the Middle East, and the United States, with strict data residency requirements in all three geographies.

The security team is led by a Senior Director of Cyber Security with over 20 years of experience. The buying decision involves the Group CISO, the CTO as an influencer, and the security director as the hands-on evaluator. This is not a team that lacks expertise. It is a team that has outgrown the tooling model they built on.

Their current security posture is not broken. They have Checkmarx for code security (SAST and secrets scanning), Akamai for API security, and the native tools from AWS and GCP for cloud posture visibility. They have a services partner (Orva Networks) for Database Activity Monitoring and DPDP compliance. Their identity is managed through Google Workspace, federated via SAML, routed through Keycloak, and assigned to cloud roles via RBAC. The infrastructure works.

But the operational model does not scale. The team is context-switching between AWS and GCP native dashboards with no unified view. Rightsizing is done manually. Access management for 500 users across 10+ accounts has no PAM solution and is handled through manual processes. And their DAM partner is not solving the data-flow visibility question they actually need answered: where does the data reside, and where is it going?

The goal is consolidation without disruption. A single dashboard across clouds. Automated what is currently manual. And a platform that can grow into the OCI footprint as it matures.

The Core Challenge

Three clouds, 500 users, 10+ accounts, Kubernetes everywhere, data residency obligations in three regions, and a security team that has outgrown native tools but has not yet consolidated into a platform that sees everything in one place.

The fragmentation is not a tooling failure. It is a maturity inflection point. The team has done the right thing at every stage: used native tools while cloud footprint was simple, invested in specialised tools (Checkmarx, Akamai) where depth mattered, and engaged a partner for DAM/DPDP. But the sum of those correct individual decisions has produced a landscape where no single person can see the aggregate security posture without manually correlating outputs from multiple consoles.

Where the Gaps Were

Native Cloud Tools Cannot Provide Cross-Cloud Visibility

AWS Security Hub and GuardDuty give you AWS findings. GCP Security Command Center gives you GCP findings. Neither gives you both. For a team operating meaningfully in both clouds with Kubernetes workloads spanning AWS EKS and GCP GKE, the absence of a cross-cloud view creates three specific problems:

1. No unified prioritisation. A critical misconfiguration in GCP and a high-severity finding in AWS appear in different consoles with different severity models. The team cannot rank them against each other without manual normalisation.

2. No cross-cloud attack-path visibility. An identity federated from Google Workspace into both AWS and GCP roles may be over-permissioned in one cloud and appropriately scoped in another. Native tools show each side independently; they cannot show the aggregate risk of that identity across both clouds.

3. No consolidated compliance reporting. When data residency requirements span India, the Middle East, and the US, and infrastructure exists in both AWS and GCP in those regions, demonstrating compliance requires assembling evidence from two separate native platforms. That is weeks of manual work per audit cycle.

The team was explicit about this: they want a single dashboard across AWS, GCP, and OCI. Not three dashboards stitched together, but one platform with one finding model, one severity scale, and one compliance engine.

Rightsizing Done Manually Is Rightsizing Not Done

The team acknowledged they are doing rightsizing manually. In practice, this means it is done reactively (when cost becomes a concern) rather than continuously (as part of security and operational hygiene). Manual rightsizing at the scale of 10+ accounts across two primary clouds means:

• Over-provisioned compute instances running with more capacity (and more attack surface) than workloads require.
• Over-permissive IAM roles that were created with broad access and never scoped down because the manual review never happened.
• Idle resources consuming budget and expanding the blast radius without contributing to workload requirements.
• No baseline for anomaly detection. If you do not know what “right-sized” looks like, you cannot detect when resource usage deviates from normal, which is a signal for compromise or misuse.

Rightsizing is not just a cost optimisation exercise. It is a security surface reduction exercise. Every over-provisioned resource is an unnecessary attack surface. Every over-permissive role is a lateral movement path waiting to be exploited.

500 Users, 10+ Accounts, No PAM Solution

This is the gap that causes the most daily pain. Five hundred users with access to cloud infrastructure, managed through a flow that starts in Google Workspace, passes through Keycloak for federation, and lands in AWS and GCP roles via RBAC. The architecture is sound. The operational execution is manual.

What manual access management looks like at this scale:

• Access requests handled through informal channels (email, tickets, chat) without a structured approval workflow.
• No time-bound access. Once granted, access persists until someone remembers to revoke it. In practice, this means standing privileges accumulate over time.
• No audit trail for access decisions. Who approved what, when, and why is not systematically captured.
• Offboarding gaps. When users leave or change roles, access revocation depends on manual processes that are error-prone at scale.
• No coverage for non-human identities. Service accounts, CI/CD pipeline credentials, and automated processes are not subject to the same governance as human users because there is no tooling to enforce it.

The team described this as “a pain.” At 500 users across 10+ accounts, it is more than a pain. It is a compliance liability and a standing-privilege risk that compounds with every passing month.

Kubernetes Security Across Two (Soon Three) Clouds

Kubernetes is the primary workload platform. EKS on AWS handles the bulk of containerised workloads, with GKE on GCP as the secondary compute surface. As OCI matures, Kubernetes workloads there will follow. Each cloud provider’s managed Kubernetes service has its own security model, its own configuration nuances, and its own blind spots:

• EKS-specific risks: Pod execution roles with excessive IAM permissions, IRSA (IAM Roles for Service Accounts) misconfigurations, security groups on pod-level networking, control plane logging not enabled.
• GKE-specific risks: Workload Identity not configured (defaulting to node-level service accounts), Binary Authorization not enforced, legacy ABAC still active, Shielded GKE Nodes not enabled.
• Cross-cluster risks: Inconsistent pod security policies between EKS and GKE, no unified view of RBAC across clusters, network policies varying between providers.

Native Kubernetes security tooling from each cloud provider only sees its own clusters. A team running Kubernetes across AWS and GCP (and soon OCI) needs a platform that normalises Kubernetes security findings across providers and presents them in a single workload protection view.

Data Residency Without Data Flow Visibility

The organisation operates in India, the Middle East, and the United States, with explicit data residency requirements in each geography. They liked that Cloudanix can satisfy data residency requirements across these three regions. But there is a deeper problem: their existing DAM partner is handling Database Activity Monitoring and DPDP compliance, but is likely not solving the data-flow visibility question that matters most:

Where does the data reside, and where is the data going?

This is not a monitoring question. It is a governance question. When you operate across three geographies with data residency obligations, you need to know not just what data exists in which database, but what paths that data takes, between services, between regions, between clouds. A DAM solution that monitors queries without answering the residency and flow question leaves a compliance gap that auditors and regulators will eventually find.

The Cloudanix Solution: One Platform Across the Entire Surface

Cloudanix was introduced as a CNAPP+ platform addressing the full surface this team needs to cover: multi-cloud posture, Kubernetes workload protection, identity and access governance, rightsizing, and data-tier visibility, with the data residency flexibility their geography demands.

Unified Multi-Cloud CSPM: AWS + GCP Today, OCI Tomorrow

Cloudanix connects to AWS accounts and GCP projects via read-only roles and service accounts. Agentless. No infrastructure changes. Findings from both clouds appear in a single dashboard with:

• Normalised severity model. A critical misconfiguration in GCP and a critical misconfiguration in AWS are scored on the same scale, enabling cross-cloud prioritisation without manual translation.
• Cross-cloud correlation. Identities, network paths, and data flows that span both clouds are visible as unified attack paths, not siloed findings.
• Aggregate posture view. The security director can see the overall posture across all accounts and projects, drill into specific clouds, and identify systemic issues that repeat across environments.
• 1,000+ security checks covering IAM, networking, storage, compute, logging, encryption, container configuration, and cloud-specific services across both AWS and GCP.

On OCI: Cloudanix has OCI CSPM on its roadmap. The team’s OCI footprint is early (two workloads), and as it matures, Cloudanix will extend the same unified dashboard to cover OCI alongside AWS and GCP. For today, the platform delivers the single-pane view across the two clouds where the vast majority of infrastructure lives, with OCI coverage planned as a natural extension.

Automated Rightsizing Recommendations

Cloudanix replaces the manual rightsizing process with automated, continuous analysis:

• IAM rightsizing. Observed permission usage over time, surfacing roles and policies that grant access far beyond what is actually used. Specific recommendations to scope permissions down to least privilege, with copy-paste-ready policy documents.
• Compute rightsizing signals. Resources running with capacity significantly beyond observed utilisation are flagged, reducing both cost and attack surface.
• Unused resource identification. Idle security groups, orphaned volumes, unattached elastic IPs, and dormant service accounts are surfaced for cleanup.
• Continuous, not periodic. Unlike manual reviews that happen quarterly (or never), Cloudanix monitors usage patterns continuously and surfaces rightsizing opportunities as they emerge.

For a team doing this manually today, the shift is from reactive cost reviews to continuous security-surface reduction. Every over-provisioned resource removed is one fewer thing an attacker can leverage.

Just-In-Time Access: Eliminating Standing Privilege for 500 Users

Cloudanix JIT access directly addresses the team’s most painful operational gap: manual access management with no PAM solution. The JIT model replaces standing privilege with time-bound, approval-gated elevation:

How it works for this team:

1. User requests access via Slack or Teams specifying the resource, the scope, and the duration needed.
2. Approval routes to the designated approver based on the resource and the requester’s role. Approval workflows are configurable per resource type, per team, per sensitivity level.
3. Access is granted for the approved duration only. The user receives scoped credentials that expire automatically.
4. Session is audited. Every action during the elevated session is logged with identity attribution.
5. Access auto-revokes. When the time window closes, permissions are removed. No manual cleanup. No forgotten elevated accounts.

Coverage across their stack:

• Cloud JIT: Time-bound elevation into AWS and GCP roles, replacing the permanent RBAC assignments that currently accumulate.
• Kubernetes JIT: Scoped, time-bound access to EKS and GKE clusters, namespaces, and workloads.
• Database JIT: Time-bound database access with identity-stamped audit, replacing shared passwords and permanent database credentials.
• Non-human identities: CI/CD pipelines, service accounts, and automated processes receive scoped, short-lived credentials rather than long-lived keys.

Integration with existing identity flow: Cloudanix operates as an access governance layer on top of the existing identity architecture. It does not replace Google Workspace, Keycloak, or the SAML federation. It enforces time-bound, audited access after authentication, adding the “when” and “for how long” controls that the current architecture lacks.

For 500 users across 10+ accounts, the immediate impact is the elimination of standing privilege accumulation, a complete audit trail for every access decision, and an end to the manual processes the team described as painful.

CWPP: Kubernetes Workload Protection Across EKS and GKE

Cloudanix provides Cloud Workload Protection for Kubernetes environments as a first-class capability, not a bolt-on:

EKS coverage (primary):

• Pod security misconfigurations: privileged containers, host network access, root execution, missing security contexts.
• IRSA (IAM Roles for Service Accounts) assessment: over-permissive roles attached to pods, roles granting cross-account access without justification.
• Network policy gaps: pods communicating across namespaces without restriction, services exposed without ingress controls.
• Image vulnerability scanning with EPSS and KEV correlation: not just CVE counts, but exploitability context.
• EKS control plane logging validation, node group configuration, and cluster endpoint access controls.

GKE coverage (secondary):

• Workload Identity configuration assessment.
• Binary Authorization enforcement validation.
• GKE-specific hardening checks (Shielded Nodes, private cluster mode, legacy ABAC detection).
• RBAC analysis for over-permissive ClusterRoleBindings and RoleBindings.

Cross-cluster normalisation:

• Findings from EKS and GKE are normalised to a single severity model.
• Inconsistencies between clusters (different pod security policies in EKS vs GKE for the same workload type) are surfaced as systemic issues.
• Unified RBAC view across all clusters, regardless of cloud provider.

For a team running Kubernetes primarily on AWS with GKE as secondary (and OCI coming), this means one Kubernetes security view across all environments, not per-cloud tooling that never correlates.

Database Activity Monitoring: Bridging the Data Flow Gap

The team’s existing DAM partner handles database monitoring and DPDP compliance at a basic level. But the critical gap they identified “where data resides and where data is going” is not being solved. Cloudanix Database Activity Monitoring bridges this gap:

• Query-level monitoring. Every database query is logged with identity attribution; who ran what, when, on which database, and what data was accessed.
• Dynamic PII masking. Sensitive fields are masked in real time based on the requester’s role and the data classification policy. Users without explicit PII access see masked values regardless of what they query.
• Destructive-query prevention. DROP, TRUNCATE, and bulk DELETE operations can be blocked or require explicit approval before execution, preventing accidental or malicious data destruction.
• Data residency visibility. Which databases contain what data classifications, in which regions, and what access patterns cross regional boundaries. This is the specific question their current partner is not answering.
• Keyless database access. Engineers connect to databases through Cloudanix using their existing IDE (DBeaver, DataGrip, TablePlus, pgAdmin) without ever seeing or storing database credentials. Access is identity-stamped and time-bound.
• Audit trail in customer-owned storage. All database activity logs land in the customer’s own S3 bucket, ensuring data sovereignty over the audit trail itself.

For a team operating across India, the Middle East, and the US with data residency obligations, the combination of query-level monitoring, data-flow visibility, and PII masking is not optional. It is the compliance layer that sits between “we have DAM” and “we can prove to regulators that data stays where it should.”

Data Residency: In-Region SaaS Across India, Middle East, and US

The team explicitly valued Cloudanix’s ability to satisfy data residency requirements across their three geographies. Cloudanix provides:

• In-region SaaS deployment in the US, India, and Middle East. Security data stays within the geography it originates from.
• CloudPrem option for teams that need the platform deployed entirely within their own cloud account, with zero data egress to Cloudanix infrastructure.
• Customer-owned audit storage: DAM logs, access audit trails, and compliance evidence stored in the customer’s own cloud storage in their chosen region.

For a FinTech operating under data residency obligations across three geographies, this is not a nice-to-have. It is a procurement requirement. Many CNAPP vendors operate SaaS-only from a single region (typically US), which creates a data-sovereignty conflict for organisations with Indian and Middle Eastern regulatory exposure.

GenAI-Powered Remediation

Every finding across AWS, GCP, and Kubernetes includes actionable remediation guidance:

• Step-by-step instructions specific to the cloud provider, service, and resource.
• Copy-paste-ready AWS CLI commands, gcloud commands, and kubectl commands.
• Terraform and CloudFormation snippets where applicable.
• Blast-radius context: what other resources are affected, what attack paths this finding enables.

For a team where the security director has 20+ years of experience and expects depth, not dashboards, this means findings come with the “so what” and the “now what” built in.

Platform Impact

30 min Agentless onboarding per cloud account | 10+ accounts Unified in a single dashboard | 500 users Under JIT governance | 3 geos Data residency in India, ME, US | 1,000+ checks Across AWS, GCP, EKS, GKE | Zero standing privilege Via time-bound JIT access

Why Native Tools and Point Solutions Hit a Ceiling Here

This team’s architecture (Google Workspace → Keycloak → RBAC federation into AWS and GCP, with EKS and GKE running containerised workloads, and data residency across three regions) is sophisticated. The native tools they are using (AWS Security Hub, GuardDuty, GCP SCC) were appropriate at an earlier maturity stage. They hit a ceiling when:

1. The second cloud became material. GCP is not a sandbox; it is a production environment. The moment both clouds carry production workloads, native tools create a visibility gap that no amount of manual correlation can sustainably close.

2. 500 users exceeded manual access governance capacity. Ten users with manual access management is fine. Fifty is a stretch. Five hundred without a PAM solution is a risk that compounds monthly.

3. Kubernetes became the primary compute surface. Cloud-level CSPM that does not see inside Kubernetes workloads misses the majority of the attack surface when containers are where applications actually run.

4. Data residency became a hard constraint. Operating in India, the Middle East, and the US with regulatory obligations means security tooling itself must respect sovereignty. A SaaS-only platform with a single deployment region fails this test.

5. The third cloud arrived. OCI with two workloads today. More tomorrow. Each additional cloud provider multiplies the native-tool problem linearly. A unified platform absorbs additional clouds without additional operational overhead.

The consolidation from native tools to a CNAPP+ platform is not about replacing tools that are failing. It is about replacing a model that cannot scale with a team’s infrastructure growth without proportional headcount investment.

The Outcome

The organisation gains a single platform and a single dashboard across their AWS and GCP environments (with OCI planned as the footprint grows), replacing the context-switching between native cloud security tools that provided no cross-cloud correlation. Manual rightsizing is replaced with continuous, automated recommendations. Five hundred users move from accumulated standing privilege to time-bound JIT access with full audit trails. Kubernetes workloads across EKS and GKE are protected under a unified CWPP layer. And the data-flow visibility gap their existing DAM partner leaves open is addressed with query-level monitoring, dynamic masking, and regional data-residency controls.

Key Results

✅ Single Multi-Cloud Dashboard: AWS and GCP unified, with OCI planned as footprint grows. ✅ Eliminated Manual Access Management: JIT replaces standing privilege for 500 users across 10+ accounts. ✅ Automated Rightsizing: Continuous least-privilege and resource optimisation replacing manual reviews. ✅ Kubernetes Protection: EKS and GKE workloads under unified CWPP with cross-cluster visibility. ✅ Data Residency Compliance: In-region SaaS across India, Middle East, and US with customer-owned audit storage. ✅ Data Flow Visibility: DAM with query-level monitoring and PII masking answering the “where is data going” question. ✅ Unified Audit Trail: Every access decision, every database query, every configuration change — identity-stamped and exportable. ✅ 30-Minute Onboarding: Agentless, no infrastructure changes, findings the same day.

Running Multi-Cloud FinTech Infrastructure with Kubernetes and Manual Access Management?

If your organisation operates across AWS and GCP (or more), runs Kubernetes as the primary compute surface, manages hundreds of users without a PAM solution, and needs data residency across multiple geographies (Cloudanix was built for exactly this inflection point. One platform, one dashboard, JIT access, CWPP, DAM, and rightsizing) without adding five more tools to your stack.

Book a Free Assessment to see your multi-cloud environment through Cloudanix (unified findings, access governance, and Kubernetes security posture) in under 30 minutes.

Related Resources

• PAM for Cloud Infrastructure: Why Traditional PAM Falls Short and What to Do
• Kubernetes Security Checklist 2026: Hardening EKS, AKS & GKE
• Still Manually Granting Cloud Access? Here’s Why Your Security & Productivity Are Suffering
• What is CNAPP (Cloud Native Application Protection Platform)?
• Multi-Cloud CSPM for GCP-Heavy FinTech with GKE Workloads
• PAM for Credential Management, Password Rotation, and More in the Cloud
• From Tool Sprawl to a Single Dashboard: E-Commerce Cloud Security
• Implementing JIT Access in AWS, Azure & GCP
• Container Security and Real-Time Visibility for Modern Cloud
• The End of Permanent Access: Next-Generation JIT for Granular Database Security