Most conversations about Web3 security start with the smart contract. That is understandable given how much reporting focuses on exploited logic bugs and reentrancy attacks, but it misses where a substantial share of crypto losses actually originate: the cloud infrastructure sitting underneath the protocol. Node operators, exchanges and DeFi teams run their validators, indexers, RPC endpoints, key management services and CI/CD pipelines on AWS or GCP, and a misconfigured IAM role or an exposed storage bucket can hand an attacker everything a perfect contract audit was meant to protect.
The contributing factor in the Harmony Horizon Bridge compromise included AWS-related infrastructure weaknesses alongside the multisig key exposure that ultimately enabled the theft. Multiple DeFi teams have separately leaked private keys through environment variables inadvertently printed into CI/CD build logs, or through storage buckets left with public read permissions during a rushed deployment. None of these incidents required breaking cryptography. They required an attacker to notice a permission that should never have been granted in the first place.
Security4Web3 treats cloud infrastructure as a first-class part of the People, Process and Technology stack that keeps crypto operations secure. This post sets out the specific AWS and GCP hardening priorities that matter for blockchain infrastructure: identity and access management, secrets handling, key management architecture, network isolation, audit logging and the shared responsibility boundary that too many crypto teams misunderstand.
The Cloud Misconfiguration Risk for Crypto Firms
Cloud misconfiguration is not a niche category of risk for crypto companies. It is consistently one of the leading causes of security incidents across the industry, and the consequences are more severe than for a typical SaaS business because the assets exposed are frequently bearer instruments: whoever holds the private key controls the funds, with no chargeback, no card network dispute process and no practical means of clawback once a transaction confirms on-chain.
A handful of failure patterns recur across incident reports and post-mortems:
- Publicly readable storage buckets containing configuration files, backups or
.envfiles with embedded credentials. - Over-permissioned service roles, particularly for CI/CD pipelines, that retain broad administrative access long after the initial deployment that justified them.
- Unencrypted storage volumes holding wallet databases, seed material or session tokens.
- Long-lived static credentials embedded in automation scripts instead of short-lived, role-assumed access.
- No multi-factor authentication on the cloud account's root or organisation-management identity, leaving the single most powerful credential in the entire estate protected by a password alone.
Each of these is well understood and each has a documented, mature remediation path. The reason they persist is organisational, not technical: infrastructure teams under delivery pressure grant broad permissions to unblock a deployment and rarely return to narrow them, and security review of cloud configuration is treated as a one-off audit exercise rather than a continuous control.
IAM Hardening: The Most Common Misconfiguration Patterns
Identity and access management is the control plane for everything else in a cloud environment. Get IAM wrong and every other control, from encryption to logging, becomes something an attacker can potentially disable or bypass once they have assumed the right role.
The AdministratorAccess anti-pattern
The single most common finding in cloud security reviews of crypto infrastructure is a CI/CD or deployment role attached to an AdministratorAccess policy in AWS, or an equivalent broad Owner or Editor role in GCP. This is almost always a legacy decision made to get a pipeline working quickly, and it is rarely revisited. A compromised GitHub Actions runner or a leaked deployment token under this configuration gives an attacker the same level of control an organisation's most senior cloud engineer has, including the ability to create new IAM users, disable logging, or modify KMS key policies to permit unauthorised decryption.
Least privilege as an operating discipline, not a one-time project
Least privilege means every identity, human or machine, holds only the permissions required for its specific function, scoped to the specific resources it needs to touch. For crypto infrastructure this typically means separate, narrowly scoped roles for: node deployment, RPC endpoint management, database administration, key management operations, and monitoring or observability tooling. No single role should combine the ability to modify infrastructure with the ability to access or export cryptographic key material.
Root account and MFA
The AWS account root user and the GCP organisation super-admin identity should never be used for day-to-day operations. Both should be protected with hardware-backed multi-factor authentication, have their credentials stored in a sealed, access-logged process (ideally aligned with the organisation's broader privileged access management programme), and be subject to alerting on any sign-in attempt.
Federated identity over static IAM users
Wherever possible, human access to AWS and GCP should be federated through single sign-on with short-lived, role-assumed credentials rather than long-lived IAM user access keys. Static access keys are a persistent liability: they do not expire on their own, they are frequently copied into scripts or password managers, and a leaked key gives an attacker a valid credential until someone notices and revokes it.
The most sophisticated smart contract audit in the world cannot protect a protocol whose private keys sit in plaintext inside an S3 bucket that a misconfigured IAM policy left publicly readable. Cryptographic assurance at the application layer means nothing if the infrastructure layer beneath it was never hardened.
Secrets Management: Private Keys Have No Place in Environment Variables
Private keys, API credentials, RPC provider tokens and database passwords are secrets, and secrets require a dedicated management system, not an environment variable file sitting next to application code. Plaintext environment variables are readable by any process on the host, are frequently logged inadvertently by application error handlers, and in CI/CD systems are a recurring source of leaks when build logs capture and retain environment state.
AWS Secrets Manager and Parameter Store
AWS offers two services for this purpose. Secrets Manager is purpose-built for credentials that require automatic rotation, fine-grained access policies and native integration with services like RDS for rotating database passwords. Systems Manager Parameter Store is a lower-cost option suited to configuration values that change less frequently and do not require automated rotation. For anything touching signing infrastructure, including validator credentials or hot wallet API keys, Secrets Manager's rotation and audit capabilities justify the additional cost.
GCP Secret Manager
GCP's equivalent, Secret Manager, provides versioned secret storage with IAM-controlled access at the individual secret level, integrated audit logging through Cloud Audit Logs, and support for automatic rotation via Cloud Functions triggers. The same principle applies regardless of provider: secrets should be retrieved at runtime by an authenticated service identity with access scoped to only the specific secrets that service needs, never checked into source control, and never baked into a container image layer where they persist in the image history even after removal from a later layer.
CI/CD secrets specifically
GitHub Actions, GitLab CI and similar platforms store pipeline secrets separately from application secrets managers, and this is where a disproportionate number of crypto leaks originate. Secrets referenced in workflow files can be exposed through debug logging, through forked pull request workflows that trigger with elevated permissions, or through a compromised third-party action. Pipeline secrets should be scoped to the minimum required environment, rotated on a fixed schedule, and never used to hold long-lived credentials for production signing infrastructure. This is closely tied to the broader discipline covered in our guide to CI/CD pipeline security, and to the DevSecOps practices described in DevSecOps for Web3.
Cloud KMS vs HSM: When to Use Each for Crypto Key Management
One of the most consequential architecture decisions a crypto infrastructure team makes is where cryptographic key material actually lives. Cloud-native key management services and dedicated hardware security modules solve overlapping but distinct problems, and conflating them leads to either unnecessary cost or insufficient assurance.
AWS KMS and GCP Cloud KMS
AWS KMS and GCP Cloud KMS are fully managed, multi-tenant key management services. They are well suited to envelope encryption of application data, encrypting secrets at rest, signing operations for non-custodial application logic, and general infrastructure encryption needs such as encrypting EBS volumes, RDS databases or Cloud Storage buckets. Customer-managed keys in both services cannot be exported in plaintext, and both support detailed access policies and audit logging of every cryptographic operation performed against a key.
When an HSM is the right call
A dedicated hardware security module, whether AWS CloudHSM, GCP's HSM-backed Cloud KMS tier, or a standalone appliance, becomes necessary when the organisation crosses specific thresholds: institutional custody of client assets, regulatory or licensing requirements mandating documented key ceremonies, a need for single-tenant hardware isolation rather than shared cloud infrastructure, or a requirement that key material be generated and remain exclusively within a FIPS-validated hardware boundary with no path to provider-mediated access at all. Our detailed guide to HSM private key management covers ceremony design, quorum-based access and rotation procedures in depth.
A practical decision rule
If the key in question protects infrastructure, application secrets or internal service-to-service authentication, cloud KMS is almost always sufficient and considerably cheaper to operate. If the key in question can authorise the movement of customer or treasury funds, particularly at institutional scale, the organisation should default to HSM-backed custody with documented, witnessed key generation and multi-party access controls. Teams sometimes assume KMS provides equivalent assurance because it is described as hardware-backed under the hood; the meaningful difference is tenancy, exportability control and the audit trail required to satisfy a regulator or an institutional counterparty during due diligence.
Network Security: VPCs, Security Groups and Node Isolation
Blockchain infrastructure has a network exposure profile that differs from typical web applications, because RPC endpoints and peer-to-peer node ports are frequently exposed to the public internet by design, and a single misconfigured security group can turn a validator or archive node into an open door.
Segregating node types by network zone
Validator nodes, RPC endpoints intended for internal use, and any publicly facing API layer should sit in separate subnets within a dedicated VPC (AWS) or VPC network (GCP), with routing and security group rules that prevent lateral movement between zones. A validator node should never be directly reachable from the public internet; it should communicate only with peer nodes and, where required, a tightly restricted internal RPC gateway.
Security Groups and firewall rules
AWS Security Groups and GCP firewall rules should be scoped by specific port and source range rather than left open to 0.0.0.0/0. RPC endpoints intended for internal tooling should be restricted to known internal CIDR ranges or accessed exclusively through a VPN or bastion host, never exposed directly. Any publicly facing RPC endpoint should sit behind a reverse proxy or API gateway that enforces rate limiting and request validation before traffic reaches the node itself.
VPC Service Controls and private connectivity
GCP's VPC Service Controls allow an organisation to define a security perimeter around sensitive services, such as Secret Manager and Cloud KMS, preventing data exfiltration even if an IAM credential is compromised, because API calls originating from outside the defined perimeter are rejected regardless of credential validity. AWS achieves a comparable effect through VPC endpoints combined with resource policies that restrict access to specific VPCs. Both mechanisms are underused in crypto infrastructure deployments, where teams frequently rely on IAM policy alone as the only access boundary.
Container deployment controls
For teams running containerised node infrastructure, GCP's Binary Authorization enforces that only signed, verified container images from an approved build pipeline can be deployed to production, which closes off a supply chain attack path where a compromised or tampered image is deployed directly. AWS equivalent controls can be implemented through ECR image scanning combined with signature verification enforced at the ECS or EKS admission control layer.
Cloud Audit Logging for Forensic Readiness
When an incident occurs, the difference between a rapid, evidence-backed response and weeks of uncertainty is almost always the quality of the logs that were being collected before the incident happened. Cloud audit logging is not optional infrastructure hygiene; it is the forensic record a crypto firm will depend on if it ever needs to explain to auditors, regulators, insurers or affected users exactly what happened.
AWS CloudTrail
CloudTrail should be enabled across every region, including regions the organisation does not actively use, since an attacker with compromised credentials can deploy resources in an unmonitored region specifically to avoid detection. Logs should be written to a dedicated, access-restricted S3 bucket in a separate account from production workloads, with object-lock or equivalent immutability enabled so that an attacker who gains administrative access cannot delete the trail of their own actions.
GCP Cloud Audit Logs
Cloud Audit Logs in GCP similarly record admin activity, data access and system events, and should be exported to a separate, access-restricted logging project with retention policies that satisfy both operational forensic needs and any applicable regulatory retention requirement. Data access logs, which are not enabled by default for most services, should be explicitly turned on for any service touching key material or customer data.
What good logging enables
Comprehensive, tamper-resistant audit logging is what allows a security team to answer the questions that matter most in the first hours of an incident: which identity performed the action, from what network location, using what credential, and what else did that identity touch in the surrounding time window. Without this, incident response becomes speculative. With it, an organisation can produce a defensible, evidence-based account of a breach, which matters enormously for regulatory reporting, insurance claims and rebuilding user trust.
The Cloud Shared Responsibility Model for Crypto Firms
Both AWS and GCP operate under a shared responsibility model: the provider secures the underlying physical infrastructure, hypervisor and, for managed services, the platform itself, while the customer is responsible for identity configuration, data protection, network configuration, application security and workload hardening. This boundary is well documented and broadly understood across the technology industry.
What crypto firms frequently underestimate is not the boundary itself but the consequence of failure on the customer's side of it. A misconfiguration that causes a data breach for a typical business is a serious but generally recoverable incident: notify affected parties, rotate credentials, absorb reputational damage. The equivalent misconfiguration at a crypto firm, if it exposes a private key or signing credential, results in an irreversible transfer of funds with no recourse. There is no chargeback mechanism on a public blockchain.
This asymmetry means the customer side of the shared responsibility boundary needs to be resourced and reviewed as though it were a primary security control, not a secondary IT function. That includes periodic, structured configuration reviews rather than one-off audits, automated configuration drift detection so that a permission granted temporarily during an incident does not silently remain in place for months, and clear internal ownership for every category of cloud configuration, from IAM policy to KMS key policy to network firewall rule.
Security4Web3's approach treats cloud infrastructure hardening as inseparable from the rest of an organisation's security programme. A well-designed multisig or a properly ceremonied HSM key generation process delivers little protection if the infrastructure surrounding it, the IAM roles that can modify its policies, the CI/CD pipeline that deploys its code, and the network path an attacker would need to reach it, has not received the same level of scrutiny.
Frequently Asked Questions
What is the most common cloud misconfiguration affecting crypto firms?
Over-permissive IAM policies are the most frequent root cause, particularly CI/CD service roles granted broad administrative permissions for convenience during setup and never scoped down afterwards. Closely behind is credential material, including private keys and API secrets, stored in plaintext in environment variables, configuration files or object storage buckets that are not properly access-restricted.
Should a crypto firm use AWS KMS or a hardware security module?
Cloud KMS is appropriate for encrypting data at rest, envelope encryption of application secrets, and signing operations that do not involve custody of end-user or treasury assets. An HSM, whether cloud-hosted or on-premises, is required when the organisation performs institutional custody, must meet regulatory key-ceremony or audit requirements, or needs cryptographic guarantees that keys never exist outside dedicated, tamper-resistant hardware.
Can a public cloud provider see or access our private keys?
With properly configured customer-managed keys in AWS KMS or GCP Cloud KMS, the provider cannot export key material in plaintext, though the provider's infrastructure does perform the cryptographic operations. For organisations that require assurance that key material never transits provider-controlled infrastructure in any recoverable form, a dedicated HSM with customer-held key ceremonies is the more defensible control.
How should node operators store RPC endpoint credentials and validator keys?
Validator and RPC credentials should be stored in a dedicated secrets manager such as AWS Secrets Manager or GCP Secret Manager, retrieved at runtime by services with narrowly scoped IAM roles, and never committed to source control, baked into container images or passed as plaintext environment variables in CI/CD pipeline logs.
Is the cloud shared responsibility model different for crypto companies?
The technical boundary is the same as for any cloud tenant: the provider secures the underlying infrastructure and the customer secures identity, data, configuration and workloads running on it. What differs for crypto firms is consequence. A misconfiguration that would cause a data breach for a typical SaaS company can cause irreversible, unrecoverable loss of funds for a crypto firm, which means the customer side of that boundary must be held to a materially higher operational standard.