Network Architecture Risks
Similar to risks faced in IDCs, network architecture needs to be designed in the cloud to reduce network exposure and network attacks caused by unreasonable network architecture design. Network architecture risks refer to the risk of the network being accessed by any user from the Internet due to unreasonable network segmentation, asset exposure. The following are common network architecture risks in the cloud:
Category | Influencing Factors | Risk Level | Possible Risks |
Allowing high-risk ports | Common high-risk ports such as 22, 3389, 445, etc., are open on applications at the Internet boundary or can be accessed by the public network through mapping, etc. | High | Common high-risk ports can be exploited by hackers for malicious login, brute-force cracking, and vulnerability exploitation. High-risk ports directly exposed to the public network without port protection can put organizations internal assets at risk. |
Using overly permissive security groups or not updated and maintained | Security groups with overly permissive rules. Increasingly complex network architecture will also increase the management burden of multiple security groups. | High | Security groups are network access control policies applied to ECS instances. If there are policies with overly permissive rules of port access, it can expose intranet resources, making them easily discoverable by hackers in the internet. Additionally, when the network architecture becomes more complex (e.g., using multiple VPCs to build the network architecture, multiple accounts to create resources, or using CEN to build a unified intranet), security group rules will increase the management burden of network policies, which may result in ineffective updates and maintenance, thereby increasing the risk of network attacks. |
East-West network communication | Enterprises may use network components such as VPCs and CEN-TR to connect their intranets in the cloud and achieve full-meshed network communication. | High | East-West and VPC-to-VPC network traffic must be isolated and audited through security controls when networks are connected through CEN. Without proper security controls, the isolation strategy will fail, resulting in lateral attacks in the intranet. |
Network segmentation and isolation | During the initial cloud migration, the basic network architecture is not divided according to the principles of partitioning and domain separation, resulting in business accumulation in a single VPC or account. | Medium | When businesses are not divided according to the principles of network segmentation and domain separation, it means that the front-end, middleware, database services, etc., of the application system are concentrated in a single VPC. Often, the front-end is accessible to the Internet, and if there are open ports and application vulnerabilities, an attacker can use them to infiltrate the intranet. If no isolation is made, the attacker can directly access all resources in the VPC, steal data, sabotage systems, encrypt files for ransom, and cause serious losses. When the system becomes too complex, if it is not separated and isolated according to the principles of partitioning and domain separation, the scalability and flexibility of the system will be affected, which will affect system stability. |
Unprotected public network resources | When using cloud resources, public network EIPs are directly bound to ECS, ACK, etc., bypassing security protection and security monitoring to directly provide public network access | High | Binding ECS and other resources directly with a public network IP bypasses some security settings, creating blind spots in security protection and monitoring. If there are high-risk vulnerabilities or exposed ports on ECS, network attacks and sniffing cannot be detected in real-time. |
Identity Management Risks
Unlike the risks faced in IDCs, accessing cloud resources based on cloud platforms involves user interfaces and machine interfaces (accessing cloud resources using APIs or SDKs). Identity management risks are defined as the risks of legally using cloud resources, data leakage etc., due to identity abuse, excessive authorization, or AccessKey leakage. The following are common identity security risks in the cloud:
Category | Influencing Factors | Risk Level | Possible Risks |
Risk in RAM user configurations | RAM users do not enable multi-factor authentication, as required by security policies | High | If RAM users do not enable multi-factor authentication, it may result in unintended access, brute-force cracking, etc., which can then lead to unauthorized use of cloud resources, data leakage, etc. |
Overly permissive policies for RAM users | Medium | Overly permissive policies for RAM users may lead to authorization risks, resulting in resource abuse and data leakage. | |
Inactive RAM users | Medium | Inactive RAM users may lead to brute-force cracking and management risks. | |
Inactive AccessKeys | Medium | Inactive AccessKeys may lead to abnormal calls and management risks. | |
Credential leakage | Leakage of cloud account credentials | High | When workloads need to access cloud resources using APIs, AccessKey is the most important credential. By obtaining the AccessKey, one can obtain the permission to use cloud resources, access data, even control permissions etc. A common anti-patten is that AccessKeys written into code or tools. If an AccessKey is leaked, it can lead to risks such as data leakage and asset damage. |
Cloud account configuration risks | Configuration risks of cloud accounts | High | Using root user without allocating RAM users or RAM user AccessKeys, it may lead to risks such as unauthorized access and data leaks. |
Root AccessKeys | High | Creating root AccessKeys can lead to risks such as unauthorized access and data leaks. |
Workload Architecture Risks
Workloads in the cloud refer to the services that provide business values for organizations, such as ECS, Kubernetes, containers, etc. Workload architecture risks refer to the risks faced during the operations selected for workloads to provide business support, such as deployment methods, network connectivity methods, and access control. For example, ECS instances directly attach public network IPs to provide Internet services. However, this operation can be exploited by attackers. The following are common workload architecture risks:
Category | Influencing Factors | Risk Level | Possible Risks |
Unprotected workloads | Workloads are not protected by NAT, SLB, firewalls, etc. and directly provide services to the public using EIPs. | High | Binding ECS and other resources directly with a public network IP bypasses some security settings, creating blind spots in security protection and monitoring. If there are high-risk vulnerabilities or exposed ports on ECS, network attacks and sniffing cannot be detected in real-time. |
Overly permissive security groups | Overly permissive security groups usually fail to effectively protect workloads. | Medium | Too many ECS instances with different security requirements joined into the same security group may lead to potential risks such as unintended access. |
Unified login authentication and auditing | Workloads are not securely operated using bastion hosts | High | Failing to provide unified authentication and access control for workloads, when there is credential leakage or brute-force cracking, it is impossible to effectively control secure access to workloads. |
Workload operations are not centrally logged and audited | High | When a security event occurs, it is impossible to effectively trace and locate the attack. |