Cloud adoption across East Africa is accelerating. The AWS Africa (Cape Town) region brought low-latency cloud infrastructure closer to the continent, and Azure availability zones serve organisations across sub-Saharan Africa. Rwandan fintechs are building cloud-native from day one, Kenyan banks are moving workloads to hybrid cloud architectures, and SaaS companies across the region deploy on AWS and Azure to serve local and international clients.
Security has not kept pace. In penetration tests, cloud misconfigurations are among the most frequent and most damaging findings, and the pattern repeats: engineering teams deploy quickly, security review comes later (if at all), and basic configuration errors sit in production for months or years. Most of these findings are configuration mistakes rather than sophisticated attacks, and most have straightforward fixes.
This guide covers the most common cloud security gaps, the regulatory considerations for East African organisations (particularly BNR-regulated institutions in Rwanda), how cloud penetration testing differs from traditional infrastructure testing, and a practical security baseline every organisation should put in place.
Common cloud misconfigurations
The categories of finding below recur in penetration tests of organisations running on AWS and Azure, financial institutions included.
Overly permissive IAM roles and policies
This is the most common finding. Identity and access management (IAM) is the foundation of cloud security, and it is where many organisations go wrong. Typical findings: service accounts with AdministratorAccess when they need only S3 read access, developers with production database credentials in their personal AWS profiles, and IAM policies that use wildcard actions ("Action": "*") on wildcard resources ("Resource": "*") because that was easier than writing a scoped policy.
The impact is severe. A compromised developer workstation with overly permissive cloud credentials gives an attacker the same access the developer has, and if that access is admin-level, the attacker owns your entire cloud environment. Fix: Apply least-privilege IAM from day one. Use AWS IAM Access Analyzer or Azure Advisor to find overly permissive policies. Review IAM policies quarterly, and remove unused credentials as soon as you find them.
Publicly accessible storage buckets
S3 buckets and Azure Blob Storage containers with public access enabled are still a common finding. Typical exposures include database backups, application logs containing sensitive data, internal documents and, sometimes, customer data sitting in storage that anyone on the internet can read. AWS has added guardrails such as S3 Block Public Access at the account level, but organisations that created buckets before those controls existed often carry legacy misconfigurations.
Fix: Enable S3 Block Public Access at the account level. Audit every existing bucket for public access. Use AWS Config rules or Azure Policy to prevent anyone creating public storage. If public access is genuinely required (for static website hosting, for example), put CloudFront or Azure CDN with origin access control in front of the bucket instead of making the bucket itself public.
Gaps in encryption at rest and key control
Encryption at rest is a baseline expectation for any organisation handling sensitive data. Rwanda's data protection law (Law N° 058/2021) names encryption among the safeguards for sensitive personal data (Article 11) and requires appropriate technical measures for all personal data (Article 47). For BNR-regulated institutions using the cloud, Regulation N° 49/2022 on outsourcing expects data encryption from the provider, with the encryption key retained by the institution (Article 20). The cloud defaults now cover much of this. New S3 objects have been encrypted automatically since January 2023; DynamoDB tables, Azure Storage accounts and Azure managed disks are encrypted at rest by default; and new Azure SQL databases have Transparent Data Encryption (TDE) switched on. The gaps that remain are narrower. An RDS instance can only be encrypted when it is created, so older or hastily built instances often run without it. EBS encryption by default is an account-level setting that many teams never switch on. Azure SQL databases created before TDE became the default, or with TDE turned off, stay unencrypted, and so do S3 objects uploaded before 2023 to buckets without default encryption. For regulated institutions, the most common gap is key control: the defaults use keys the provider owns and manages, while BNR's outsourcing regulation expects the institution to retain the key.
Fix: Confirm what the defaults already cover, then close the gaps. In AWS, turn on EBS encryption by default in every region you use, create every RDS instance with encryption enabled, and use SSE-KMS with customer-managed keys for buckets that hold regulated data. In Azure, confirm TDE is on for every SQL database, and use customer-managed keys held in Azure Key Vault for storage accounts, managed disks and SQL wherever the institution must control the key. For existing unencrypted resources, plan a migration: create encrypted copies (for RDS, restore from an encrypted copy of a snapshot), then decommission the originals.
Treat encryption at rest as the baseline. The data protection law enforced by the National Cyber Security Authority (NCSA) requires appropriate technical measures for personal data and names encryption among the safeguards for sensitive data. BNR's outsourcing regulation expects encryption from cloud providers, with the key held by the institution. If you process financial data or personal information without encryption at rest, expect an auditor or examiner to ask why.
Missing CloudTrail and Activity Log monitoring
An attack you have no logs for is an attack you will not detect. CloudTrail in AWS and Activity Log in Azure record API calls and management operations across your cloud environment, and those records are the basis for incident detection, forensic investigation and compliance evidence. A common finding is CloudTrail that is switched off, not logging data events (S3 object access, Lambda invocations), or writing to a bucket that nobody monitors.
Fix: Enable CloudTrail in all regions, with data event logging for critical services. Send logs to a centralised, immutable S3 bucket with versioning enabled and deletion protected by multi-factor authentication (MFA Delete). In Azure, configure Activity Log to stream to a Log Analytics workspace. Set up alerts for the events that matter most: root account use, IAM policy changes, security group changes and failed authentication attempts.
Default security groups allowing broad inbound access
Security groups in AWS and Network Security Groups in Azure are your cloud firewall, and their default configurations are often too permissive. Common findings: SSH (port 22) and RDP (port 3389) open to 0.0.0.0/0 on production instances, database ports (3306, 5432, 1433) reachable from the internet, and security groups that were opened "temporarily" for debugging and never locked down again.
Fix: Restrict every inbound rule to specific IP ranges or security groups. Never allow 0.0.0.0/0 inbound on management ports. Use AWS Systems Manager Session Manager or Azure Bastion for administrative access instead of exposing SSH or RDP directly. Audit security groups monthly and remove any rule nobody can justify.
Data sovereignty and regulatory considerations
For East African organisations, particularly those regulated by BNR, where your data physically resides is a compliance question. The AWS Africa (Cape Town) region is the closest AWS region to East Africa, but data processed there is still outside Rwanda. Azure does not yet have a data centre in Rwanda.
BNR has not prohibited cloud use by supervised institutions. Regulation N° 49/2022 on outsourcing treats cloud computing as a form of outsourcing: a material outsourcing arrangement needs the Supervisory Authority's prior approval (Article 21), outsourcing outside Rwanda comes with conditions such as regulator access and service continuity (Article 18), and cloud providers are expected to offer strong authentication, access controls, tokenisation and data encryption (Article 20). In practice, that means doing due diligence on cloud providers, knowing where data is stored and processed, securing contractual protections for data access and portability, and documenting the risk assessment behind the decision to adopt cloud.
A common pattern is a hybrid approach. Sensitive data (core banking, customer personal data, transaction records) stays on-premises or in a private cloud within Rwanda, while less sensitive workloads (development environments, analytics, public-facing websites) run in public cloud. This balances the operational benefits of cloud against regulatory requirements. Rwanda's data protection law adds a storage rule of its own: under Article 50 of Law N° 058/2021, personal data must be stored in Rwanda, and storage outside Rwanda is permitted only if the controller or processor holds a valid registration certificate from the NCSA, the supervisory authority, authorising it.
Cloud penetration testing vs traditional infrastructure testing
Testing cloud environments calls for a different mindset and methodology from traditional infrastructure penetration testing, because the attack surface has moved.
Identity is the perimeter. In traditional infrastructure, attackers breach the network perimeter and move laterally. In the cloud, the perimeter is IAM. An attacker who compromises cloud credentials can reach resources from anywhere without ever touching your network. Cloud penetration testing therefore concentrates on IAM policy analysis, credential exposure (keys in code repositories, environment variables, metadata services) and privilege escalation paths within the IAM model.
API-based attacks are central to cloud security testing. Every action in AWS and Azure is an API call. Misconfigured API permissions, exposed API keys and insecure API integrations are primary attack vectors. Cloud testers assess how the application interacts with cloud service APIs and whether those interactions expose unintended access.
The shared responsibility model defines the testing scope. AWS and Azure are responsible for security of the cloud (physical infrastructure, the hypervisor, managed service internals). You are responsible for security in the cloud (IAM, network configuration, data encryption, application security). Cloud penetration testing focuses on your side of that divide.
AWS and Azure penetration testing policies: AWS no longer requires pre-approval for penetration testing against your own resources across its permitted services, per the AWS penetration testing policy. Microsoft similarly permits testing against your own subscriptions without prior notification under its penetration testing rules of engagement. Denial-of-service testing is prohibited on both platforms, and testing must stay within your own accounts and subscriptions. Review the current policies before testing begins.
Building a cloud security baseline
Every East African organisation running workloads on AWS or Azure should put these controls in place as a minimum baseline:
- Enable MFA on every user account, especially root and global administrator accounts. Use hardware security keys for the root account where possible.
- Apply least-privilege IAM. No wildcard policies. Scope permissions to specific services, actions and resources, and review them quarterly.
- Encrypt all data at rest. Turn on EBS encryption by default, create RDS instances encrypted, and confirm TDE is on for every Azure SQL database (S3, DynamoDB and Azure Storage encrypt by default). Use customer-managed keys (CMK) for regulated workloads.
- Encrypt all data in transit. Enforce TLS 1.2 as the minimum on every endpoint. Use HTTPS-only policies on load balancers and CDN distributions.
- Enable logging across the whole estate. CloudTrail in all regions with data events, and Azure Activity Log streamed to Log Analytics. Retain logs for at least one year.
- Restrict security groups. No 0.0.0.0/0 inbound on any port. Use bastion hosts or managed access services for administration.
- Separate environments. Use separate AWS accounts or Azure subscriptions for production, staging and development, and never share credentials between them.
- Use infrastructure as code. Provision all infrastructure through Terraform or CloudFormation. That gives you drift detection, peer review of changes and reproducible environments.
- Review and rotate credentials. Rotate access keys every 90 days. Remove unused credentials immediately. Use IAM roles instead of long-lived access keys wherever possible.
How we can help
IMIZI Cyber is a Kigali-based firm providing manual penetration testing for banks, fintechs, telecoms, government and healthcare institutions across Africa, including cloud security assessments of AWS and Azure environments. Our testing covers IAM policy analysis, network configuration review, storage and encryption assessment, and application-level testing of cloud-deployed services. We find the misconfigurations automated tools miss and give remediation guidance specific to your cloud architecture, reported in a form a board and a regulator can both act on.
For our testing methodology and deliverables, see our penetration testing service page. For broader assessment needs, including compliance gap analysis, see our security assessments service page. For the financial impact of getting cloud security wrong, see our analysis of data breach costs in East Africa.
Contact us to scope a cloud security assessment for your AWS or Azure environment.