A cloud security verification method and system, electronic device and computer-readable storage medium

Abstract

The present invention relates to the field of cloud security verification technology, and more specifically to a cloud security verification method and system, an electronic device, and a computer-readable storage medium. The method comprises generating and isolating an AKSK, wherein the AKSK is an access key pair used for identity authentication, simulating attack behavior in combination with the AKSK, and performing security capability verification based on the simulated attack behavior. The present invention generates an AKSK to simulate attacks in a real cloud environment, ensuring that the test scenario highly restores the real attack path, thereby solving the technical problem that traditional security testing mainly relies on static policy analysis (such as IAM policy syntax checking) and manual penetration testing, and cannot simulate the complete attack path after the AKSK is leaked in the real attack chain.

Description

Technical Field

[0001] The present invention belongs to the technical field of cloud security verification, and specifically relates to a cloud security verification method and system, an electronic device, and a computer-readable storage medium. Background Art

[0002] Traditional security testing mainly relies on static policy analysis (such as IAM policy syntax checking) and manual penetration testing. Static policy analysis mainly performs syntax checking on identity and access management (IAM) policies to evaluate the compliance of permission configurations. For example, by scanning the syntax rules of IAM policies, it is possible to detect problems such as overly broad permissions and lack of the principle of least privilege. On the other hand, manual penetration testing relies on security experts to manually simulate attack scenarios to discover potential security vulnerabilities and permission abuse issues. This method usually includes environmental information collection, vulnerability exploitation, permission escalation and other links to simulate potential attack paths. Some solutions simulate attacks through cloud services in a sandbox environment, but cannot truly reflect the security policies and protection effects of the production environment; some solutions rely on manual penetration testing and static log analysis, which have the limitations of low automation and insufficient real-time performance.

[0003] As can be seen from the above, the above methods all have certain limitations and cannot simulate the complete attack path after AKSK leakage in the real attack chain (such as key theft → unauthorized access → lateral penetration). Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the prior art, the present application aims to provide a cloud-based security verification method and system, an electronic device and a computer-readable storage medium.

[0005] In a first aspect, according to an embodiment of the present invention, a cloud security verification method is provided, which includes the following steps:

[0006] Generate and isolate AKSK, where AKSK is an access key pair used for authentication;

[0007] Combined with the AKSK, simulate attack behavior; and

[0008] Security capability verification is performed based on simulated attack behaviors.

[0009] In conjunction with the first aspect, in certain embodiments of the present invention, generating and isolating AKSK includes:

[0010] Generate AKSK through the cloud platform;

[0011] Bind the AKSK to the minimum permission policy for the corresponding scenario, where the minimum permission policy for the corresponding scenario is a rule that controls access rights and grants only the minimum permissions required to complete a specific task.

[0012] According to the minimum permission policy of the corresponding scenario, test resources are created to isolate the AKSK to ensure that the simulation operation only acts on the isolated environment, wherein the test resources refer to the isolated environment resources temporarily created for the simulated attack scenario.

[0013] In conjunction with the first aspect, in certain embodiments of the present invention, simulating attack behavior in conjunction with the AKSK includes:

[0014] A feature field is forcibly added to the API request header of the simulated attack so that security devices can identify and distinguish simulated traffic from real attacks. A digital signature is generated in combination with AKSK, and the signature hash value is embedded in the API request header to ensure that the identification cannot be forged.

[0015] In combination with the first aspect, in certain embodiments of the present invention, the simulated attack behavior includes at least one of key leakage, authority abuse, lateral penetration, and simulated cross-account attack.

[0016] In conjunction with the first aspect, in certain embodiments of the present invention, performing security capability verification based on simulated attack behavior includes:

[0017] Capture logs in real time;

[0018] Analyze response behavior based on the log;

[0019] Based on the analysis of the response behavior, a quantitative assessment is performed to obtain a security protection capability score; the quantitative assessment is to sum up several indicators with preset weights; the several indicators are associated with the response behavior, and the several indicators include those based on interception success rate and alarm delay.

[0020] In conjunction with the first aspect, in some embodiments of the present invention, the method further includes:

[0021] Clean up resources during the cloud security verification process;

[0022] The harmless cleanup of resources during the cloud security verification process includes at least one of automatically revoking keys, destroying test resources, and establishing an exception handling mechanism;

[0023] The construction of the exception handling mechanism includes: if resource cleanup fails, triggering an alarm and starting a manual review process.

[0024] In a second aspect, according to an embodiment of the present invention, a cloud security verification system is provided, applicable to the cloud security verification method according to any one of the first aspects, the cloud security verification system comprising:

[0025] An AKSK generation and isolation unit, configured to generate and isolate an AKSK, wherein the AKSK is an access key pair used for identity authentication;

[0026] an attack behavior simulation unit, configured to simulate attack behavior in combination with the AKSK of the AKSK generation and isolation unit; and

[0027] The security capability verification unit is used to perform security capability verification based on the simulated attack behavior of the attack behavior simulation unit.

[0028] In conjunction with the second aspect, in certain embodiments of the present invention, the cloud security verification system further includes:

[0029] Resource cleanup unit, used to clean up resources during the cloud security verification process;

[0030] The harmless cleanup of resources in the cloud security verification process includes at least one of automatically revoking keys, destroying test resources, and building an exception handling mechanism.

[0031] In a third aspect, according to an embodiment of the present invention, there is provided an electronic device, including:

[0032] one or more processors;

[0033] a memory configured to store one or more computer programs;

[0034] a communication interface configured to enable the processor and the memory to communicate with an external device;

[0035] When the computer program is executed by the one or more processors, the electronic device executes the cloud security verification method as described in the first aspect.

[0036] In a fourth aspect, according to an embodiment of the present invention, a computer-readable storage medium is provided, comprising a computer program, which, when executed on an electronic device, enables the electronic device to execute the cloud security verification method as described in the first aspect.

[0037] Compared with the prior art, the present invention has the following beneficial effects:

[0038] The present invention generates AKSK to simulate attacks in a real cloud environment, ensuring that the test scenario highly restores the real attack path. It solves the technical problem that traditional security testing mainly relies on static policy analysis (such as IAM policy syntax checking) and manual penetration testing, and cannot simulate the complete attack path after AKSK leakage in the real attack chain. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the solutions in the embodiments of the present invention, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.

[0040] Figure 1 is a flow chart of a cloud security verification method according to an embodiment of the present invention;

[0041] Figure 2 FIG. 1 is a schematic structural diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0042] The present application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are intended only to illustrate the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the invention are shown in the accompanying drawings.

[0043] Currently, traditional security testing mainly relies on static policy analysis (such as IAM policy syntax checking) and manual penetration testing, which cannot simulate the complete attack path after AKSK leakage in a real attack chain (such as key theft → unauthorized access → lateral penetration).

[0044] In order to overcome the deficiency of the above-mentioned traditional security testing that cannot simulate the complete attack path after the AKSK leakage in the real attack chain, the present invention provides a cloud security verification method.

[0045] In one embodiment, a cloud security verification system is provided, which includes: an AKSK generation and isolation unit, an attack behavior simulation unit, and a security capability verification unit.

[0046] The cloud security verification system interaction rules:

[0047] Data flow: AKSK and test resource ARN are core concatenated fields and run through all units;

[0048] Event triggering: Each unit transmits task status (such as policy readiness, attack completion, alarm triggering) through a message queue (such as AWS SQS).

[0049] An ARN is a string format used to uniquely identify resources in AWS, such as arn:aws:s3:::test-bucket. It is used to specify specific cloud resources, such as storage buckets and instances.

[0050] Among them, the AKSK generation and isolation unit is used to generate and isolate AKSK. In one embodiment, the AKSK generation and isolation unit involves generating temporary credentials with a time window, rendering and replacing the minimum permission policy template of the corresponding JSON scenario, and automatically deploying an isolated environment (test bucket / VPC) according to the policy statement. In the minimum permission policy of the corresponding scenario, "corresponding" means that, for example, if the test bucket uses an attack to access other users across domains, only the bucket and some IAM account policies will be automatically retained, and other policies will not be used. These policies are all generated by this system based on the attack scenario. AKSK can be arbitrary, and can be actively generated by the machine, or it can be actively generated without the machine.

[0051] In one embodiment, generating temporary credentials with a time window includes calling a cloud platform STS API (such as AWSAssumeRole) to generate an AKSK.

[0052] In one embodiment, the minimum permission policy template rendering and variable replacement for the JSON corresponding scenario includes using a template engine to render the policy file, replacing test-bucket- <task-id>Call the IAM API to attach the policy to the temporary credentials.

[0053] In one embodiment, automatically deploying an isolated environment based on the policy statement includes creating resources based on the generated ARN rules and adding an isolated_test tag to block production traffic.

[0054] Multi-cloud adaptation design of cloud security verification system:

[0055] SDK loading: Load the corresponding SDK (Boto3 / Azure

[0056] CLI / gcloud).

[0057] The attack behavior simulation unit is used to simulate attack behaviors in conjunction with AKSK. In one embodiment, the simulated attack behaviors include at least one of a key leakage scenario, a permission abuse scenario, a lateral penetration scenario, and a simulated cross-account attack scenario.

[0058] In one embodiment, the key leakage scenario includes programmatically simulating environment variable / log leakage; for example, presetting an environment variable (AWS_ACCESS_KEY_ID=xxx) in an isolated container, triggering simulated log writing and extracting a placeholder key;

[0059] In one embodiment, the permission abuse scenario includes verifying the policy interception effect through the DryRun mode; for example, forcing the addition of the DryRun=True parameter when calling the API (such as AWS EC2 TerminateInstances) and counting the AccessDenied response rate;

[0060] In one embodiment, the lateral penetration scenario includes orchestrating a cross-service attack chain (e.g., s3 → ECS → RDS, executing a multi-step attack based on a script);

[0061] In one embodiment, simulating a cross-account attack scenario includes simulating cross-account resource access (requiring pre-configured cross-account policies); for example, constructing a cross-account API request (such as arn:aws:s3:::OtherAccountBucket / *) to verify the VPC endpoint policy blocking capability;

[0062] Cloud Security Verification System Attack Traffic Identification Mechanism

[0063] Request header tag: Automatically add X-Simulated-Attack: <task-id>With signature hash X-Signature:sha256(SK+Timestamp);

[0064] The security capability verification unit is used to verify security capabilities based on simulated attack behaviors; the security capability verification unit involves real-time log capture, response behavior analysis and quantitative evaluation.

[0065] In one embodiment, real-time log capture includes real-time aggregation of multi-source logs (CloudTrail / WAF / SIEM); in one embodiment, subscribing to Kafka log streams and associating AKSK operation chains by request_id; Kafka is a distributed stream processing platform used for real-time data pipelines and streaming processing, and is used for real-time capture and analysis of log streams.

[0066] In one embodiment, the response behavior analysis includes a rule engine matching expected interception effects (e.g., permission denial, WAF blocking), such as predefined validation rules, matching error_code=AccessDenied or waf_action=BLOCK log entries;

[0067] In one embodiment, the quantitative assessment includes calculating a comprehensive security protection score, for example, generating a radar chart based on the interception success rate and the alarm delay, and combining the threat level weighting to derive the protection level (AF);

[0068] Alarm correlation analysis of the cloud security verification system

[0069] Multi-log correlation: Align IAM policy interception events (CloudTrail) with WAF blocking records (WAF Logs) and SIEM alerts (Splunk) according to time windows. SIEM is a security management system used to centrally collect, analyze, and report security event logs for real-time monitoring and response to security threats.

[0070] IAM (Identity and Access Management) policy: A set of rules that defines resource access permissions in the cloud platform and is used to limit the scope of AKSK operations.

[0071] In one embodiment, the cloud security verification system also includes a resource harmless cleaning unit, which is used to harmlessly clean up resources in the cloud security verification process. The harmless cleaning of resources in the cloud security verification process includes at least one of automatically revoking keys, destroying test resources, and building an exception handling mechanism.

[0072] In one embodiment, automatically revoking the key includes immediately invalidating the AKSK, for example, by calling the IAMDeleteAccessKey API and recording an audit log of the revocation operation through Secrets Manager;

[0073] In one embodiment, destroying the test resources includes layered cleanup of network / storage / computing resources, for example, calling an underlying API (such as AWS EC2 TerminateInstances) to forcibly terminate residual resources;

[0074] In one embodiment, building an exception handling mechanism includes: if resource cleanup fails (such as API throttling), triggering an alarm and starting a manual review process.

[0075] like Figure 1 As shown, in one embodiment, a cloud security verification method is provided, which is applicable to the above-mentioned cloud security verification system, and the cloud security verification method includes:

[0076] Step S1, using the AKSK generation and isolation unit to generate and isolate AKSK, that is, this involves generating temporary credentials with a time window, where AKSK (Access Key / Secret Key) is an access key pair used for authentication, Access Key is a public identifier, and Secret Key is an encrypted credential. In the field of cloud computing and network security, keys usually refer to access keys (Access Key, AK) and secret keys (Secret Key, SK), which together constitute a set of security credentials. The access key (AK) is used to identify the user or application requesting access to cloud resources, while the secret key (SK) is used to encrypt and sign the request to ensure the authenticity and integrity of the request. AKSK (Access Key and Secret Key) refers to access and security keys with time limits. They automatically expire after a certain period of time, thereby providing a temporary and secure way to access cloud resources.

[0077] In one embodiment, step S1 specifically includes:

[0078] In step S11, an AKSK is generated through the cloud platform's native API (such as AWS STS AssumeRole). The key validity period is strictly bound to the attack simulation task cycle (for example, it is generated when the task starts and automatically expires after timeout or completion); and security is ensured through additional lifecycle management mechanisms (such as regular rotation or manual cleanup after task completion).

[0079] Step S12: Bind the AKSK to the minimum permission policy for the corresponding scenario. In one embodiment, the policy rules of the minimum permission policy for the corresponding scenario are generated through a JSON template, and permission binding is achieved by programmatically calling the cloud platform IAM service interface, as follows:

[0080] First, a JSON-formatted policy template is defined (including a version number, authorization validity, and a specific Action-Resource constraint combination, such as the s3:GetObject permission that only allows access to a specific bucket. The JSON policy template uses a template engine to render the policy file). Then, when generating the AKSK, the reserved placeholder variables in the policy template (such as the test bucket name) are replaced with the generated isolation identifier (such as the task ID). Finally, a concrete permission policy is generated through an SDK (such as the create_policy method in AWS boto3). (Concrete permission policies are automatically generated based on attack scenarios. By thoroughly studying attack paths and cloud service characteristics, the system can automatically generate fine-grained, targeted permission policies based on specific attack simulation scenarios. These policies are generated through a JSON template and bound to the AKSK, ensuring that they can only execute preset operations. This not only improves the authenticity and efficiency of attack simulations, but also minimizes security risks through permission isolation.) This policy is then attached to the temporary key. A specific implementation example is given below:

[0081] For example, {"Version":"2012-10-17", / / IAM policy syntax standard version identifier, AWS specific format requirements

[0082] "Statement":[{ / / Permission statement subject, multiple sets of rules can be superimposed

[0083] "Effect":"Allow", / / Authorization behavior type (Allow / Deny), here is to allow access

[0084] "Action":["s3:GetObject"], / / Authorize API operations list, limiting only S3 object reading

[0085] "Resource":"arn:aws:s3:::test-bucket / *" / / Bound resource path rule, the format is AWS resource ARN

[0086] / / ↑Note: test-bucket is a placeholder. It will be replaced by the name of the isolated bucket generated in step S13 during actual runtime (such as test-bucket- <task-id>)

[0087] / / * is a wildcard character, which allows access to all objects in the bucket, excluding bucket-level operations (such as ListBucket).

[0088] The least privilege policy (Least Privilege Policy) is a security principle designed to ensure that users or systems are granted only the minimum permissions required to perform their tasks, without providing additional, unnecessary permissions. This policy can effectively reduce security risks and prevent data leaks, system abuse, or other security incidents caused by excessive permissions. In cloud computing environments, the least privilege policy is often implemented through identity and access management (IAM) policies.

[0089] Step S13: Create test resources (such as a dedicated VPC subnet and a temporary storage bucket) based on the minimum permission policy for the corresponding scenario to isolate AKSK and ensure that simulation operations only act on the isolated environment, which is physically / logically separated from production resources. That is, the isolated environment (test storage bucket / VPC) is automatically deployed according to the policy statement. For example, resources are created based on the generated ARN rules and the isolated_test tag is added to block production traffic.

[0090] In one embodiment, according to the permission boundary solidified in step S12, the VPC service is called to create a network isolation domain (for example, an ACL rule is set in the dedicated subnet to prohibit cross-subnet traffic), and at the same time, according to the arn rule declared in the resource in the policy (such as arn:aws:s3:::test-bucket- <task-id> / *) creates a temporary bucket with a unique suffix and marks it as "isolated_test" through the resource tag system. This achieves a two-way match between the permission policy in step S12 and the physical resources in step S13. AKSK can only access the target resources predefined by the policy. These resources themselves are completely separated from the production environment (business-critical resources such as the online core database and official business buckets) through logical isolation (subnet ACL) and namespace isolation (generated bucket name).

[0091] Test resources refer to isolated environment resources temporarily created for simulating attack scenarios and have the following characteristics:

[0092] Generate: Create or generate data or resources in real time when they are actually needed. In the field of information security, generate is often used to create temporary access credentials or keys, rather than pre-configured and statically stored credentials. This practice can improve security because even if temporary credentials are leaked, their validity period is limited, thus reducing the risk of malicious exploitation. For example, a task-specific bucket (test-bucket-<task ID>) is automatically created by code when the task starts (such as the AWS CLI's aws s3api create-bucket);

[0093] Physical / logical isolation: Block communication with the production network through independent VPC subnets and network ACL rules, or use tags (such as Environment:Test) to mark the isolation boundary;

[0094] Automatic destruction: The bucket is deleted immediately after the task is completed (for example, calling aws s3 rb s3: / / test-bucket-xxx --force to empty the bucket).

[0095] Simulated operations refer to non-destructive attack simulation behaviors performed on test resources, such as restricted API calls: Under the minimum permission policy constraints of the corresponding scenario, simulate malicious code attempts to read objects from the test bucket (s3:GetObject), but cannot damage other services (such as being unable to trigger Lambda functions).

[0096] Controllable results: The operation only affects temporary resources (for example, reading a temporarily generated test file fake-data.txt from test-bucket-xxx), ensuring physical isolation from production data (such as the real customer order table).

[0097] In one embodiment, production resources refer to core resources that carry actual business (such as online databases and production environment S3 storage buckets), which need to be isolated from the test environment in the following two ways:

[0098] Logical isolation: The IAM policy explicitly excludes access permissions for the test AKSK (for example, specifying Resource:"arn:aws:s3:::prod-bucket / *" in the Deny rule).

[0099] Physical isolation: Use completely separate AWS accounts or enforce isolation through resource tags (such as Environment:Prod) combined with SCPs (Service Control Policy). SCPs are policies used in AWS to define organization-level permission controls, limiting the scope of operations for an account or role. Their purpose is to ensure resource security and prevent abuse.

[0100] In step S2, the attack behavior simulation unit is used in combination with AKSK to simulate the attack behavior. That is, a characteristic field (such as X-Simulated-Attack: true) is forcibly added to the API request header of the simulated attack so that the security device can identify and distinguish the simulated traffic from the real attack. A digital signature is generated in combination with AKSK, and the signature hash value is embedded in the request header (such as X-Signature: sha256 (SecretKey + Timestamp)) to ensure that the identification cannot be forged.

[0101] In one embodiment, the simulated attack behavior includes at least one of a key leakage scenario, a permission abuse scenario, a lateral penetration scenario, and a simulated cross-account attack scenario;

[0102] In one embodiment, a malicious program is simulated in a key leakage scenario to obtain the AKSK through environmental variable leakage, log file residue, etc. Specifically, the malicious program is simulated by deploying a simulation program in an isolated test environment and injecting an environment variable containing the AKSK. Simultaneously, log records containing a fake AKSK are constructed, simulating the malicious program's process of scanning environment variables and parsing log files to steal credentials. For example, an HTTP service with preset environment variables is run in a temporary container, triggering abnormal log writing, and extracting AKSK fragments from the log using regular matching. All operations in the process are performed under the control of the AKSK with the minimum permission policy bound to the corresponding scenario, and the environment variables and log files are automatically cleaned up after the test, ensuring the authenticity and harmlessness of the attack simulation. In one embodiment, an environment variable (AWS_ACCESS_KEY_ID=xxx) is preset in the isolated container, triggering simulated log writing and extracting the placeholder key.

[0103] "Malicious Program" means a controllable test code module used to illegally obtain temporary access credentials (AKSK) in simulated network attacks. Its functionality is limited to specific test scenarios and does not involve actual damage.

[0104] Environment variables are key-value pairs that store configuration information within the operating system or container during the runtime of a cloud service instance. These typically contain sensitive credentials such as AKSK. Simulated attacks use environment variables containing AKSK to replicate development environment configuration errors.

[0105] "Log File" refers to the record file automatically generated during the operation of the Cloud Application. Due to programming defects, the AKSK may be written into the error log in plain text.

[0106] In one embodiment, AKSK is actually used to perform out-of-scope operations in a permission abuse scenario (out-of-scope operations refer to the use of temporary access credentials (such as temporary AK / SK) to perform operations or resource access beyond the scope permitted by the associated permission policy; such operations are essentially permission abuse and may be caused by policy misconfiguration, credential leakage, or privilege escalation vulnerabilities, such as calling ec2:TerminateInstances to attempt to delete an unauthorized ECS instance). In one embodiment, the DryRun=True parameter is mandatory when calling the API (such as AWS EC2 TerminateInstances), and the AccessDenied response rate is counted.

[0107] Simulate high-risk operations through the cloud API's DryRun mode, triggering policy verification without actually executing them. (DryRun (simulated execution) is a special mode provided by cloud service APIs that allows users or programs to simulate the actual execution of an operation without actually modifying resources or triggering side effects. Its core purpose is to verify operation permissions, parameter validity, or resource status, and is often used in debugging or pre-inspection scenarios. For example, AWS's dryRun parameter)

[0108] In one embodiment, in a lateral penetration scenario, AKSK calls the cloud platform security token service (such as AWS STSGetSessionToken) to obtain temporary credentials and attempt a cross-service attack (such as penetrating from an S3 bucket to an ECS instance).

[0109] The Security Token Service is a temporary credential issuance and management component provided by the cloud platform. It is used to generate access credentials with limited permissions and time limits (such as temporary AK / SK, security tokens). Typical examples include:

[0110] AWS STS: Issues temporary credentials through APIs such as GetSessionToken and AssumeRole.

[0111] Alibaba Cloud STS: Generate a temporary token through the AssumeRole interface.

[0112] Azure AD Security Token Service: Issues OAuth tokens for accessing resources.

[0113] A cross-service attack occurs when an attacker exploits a permission vulnerability in a cloud service (such as over-authorized temporary credentials) to move laterally to other services and perform unauthorized operations, forming an attack chain that connects multiple services in series.

[0114] The typical attack path is as follows:

[0115] Initial exploitation: Accessing low-privileged services (such as s3 buckets) via a leaked AKSK.

[0116] Permission detection: Use the current credentials to try to call other service APIs (such as ECS, IAM, and Lambda).

[0117] Horizontal privilege escalation:

[0118] Scenario 1 - Data Leakage: Obtaining the ECS instance startup script or configuration file from an S3 bucket to extract sensitive information (such as database passwords);

[0119] Scenario 2 - Service Abuse: Exploiting S3 read permissions to obtain Lambda function code, analyze vulnerabilities, and trigger malicious functions to operate on ECS instances;

[0120] Scenario 3 - Role Hijacking: Call sts:AssumeRole to attempt to assume a higher-privileged role and thereby control the entire cloud account.

[0121] In one embodiment, in a simulated cross-account attack, AKSK is used to attempt to access other account resources (cross-account policy verification needs to be configured), other account resources such as bucket resources, computing resources, database resources, permissions and identity resources, network resources, keys and sensitive data, etc.

[0122] Step S3, using a security capability verification unit to perform security capability verification based on simulated attack behavior;

[0123] In one embodiment, step S3 specifically includes:

[0124] Step S31, real-time log capture; in one embodiment, the operation log is obtained in real time through the cloud platform audit service API (such as AWS CloudTrail LookupEvents), and requests related to AKSK are filtered out by the request_id value.

[0125] Operation logs are audit data of all API requests and resource changes recorded by the cloud platform, used to track the behavior of users, services, or systems in the cloud environment;

[0126] The request_id (request ID) is a unique identifier automatically generated by the cloud platform for each API request. It is used to track the entire lifecycle of a single request (such as request routing, processing, and response) in a distributed system. The request_id is included in the response packet received for each API request.

[0127] Step S32: Analyze the response behavior based on the logs. In one embodiment, detect whether the IAM policy engine intercepts unauthorized requests (via the AccessDenied status code returned by the API); verify whether the cloud firewall (such as AWS WAF) triggers blocking rules (via request response time and interception logs); and check whether the log audit system (such as a SIEM tool) generates an alarm event (such as "abnormal AKSK usage behavior").

[0128] Among them, when detecting whether the IAM policy engine intercepts unauthorized requests, it simulates accounts or roles with different permissions to initiate API operations, such as accessing unauthorized resources or performing unauthorized operations. If the API returns a 403AccessDenied status code (or a similar access denied prompt), it can be confirmed that the interception is effective. The blocking rules are a set of predefined security policies in the cloud firewall (such as IP blacklists, malicious request pattern matching, SQL injection rules, etc.) (such as IP blacklists, malicious request pattern matching, SQL injection rules, etc.). During verification, test requests that trigger these rules are actively constructed (such as injecting attack payloads, accessing illegal paths), and observing whether the request is blocked (such as returning 403Forbidden or a custom interception page), and checking whether the corresponding request in the firewall interception log is marked as a BLOCK action. The cloud firewall performs "recording only without blocking" or "downgrading" on the simulated traffic based on feature identifiers to avoid misjudgment and interference with production alarms. For log auditing systems (such as SIEM tools Splunk and QRadar), the system will centrally collect and analyze cloud environment logs (such as API call records and user behavior logs). Alarm events are security notifications triggered according to set rules (such as "abnormally high-frequency AKSK calls" and "cross-region logins"). During the inspection, first perform abnormal behavior operations on the SIEM platform (such as initiating a large number of high-risk API calls with a single AKSK in a short period of time), and then filter the alarm types for the corresponding time period on the log query interface to confirm whether alarm entries that meet the rules are generated. At the same time, verify whether the alarm content contains key data such as the specific event time, user ID and operation details, and test whether the alarm notification channel is pushing messages normally.

[0129] The IAM policy engine is the core security component within the cloud platform, responsible for real-time evaluation of whether API requests are authorized. Its core functions include:

[0130] Policy parsing: Parse IAM policies, resource policies (such as S3 bucket policies), service control policies (SCPs), and other permission rules.

[0131] Permission decision: Determine whether to allow or deny a request based on the request subject (Principal), operation (Action), resource (Resource), and condition (Condition).

[0132] Policy merging: When multiple policies (such as user policies, resource policies, and organization SCPs) are in effect simultaneously, the results are merged based on priority and logical operators (such as Deny takes precedence).

[0133] Step S33: Based on the analysis of the response behavior, a quantitative evaluation is performed, that is, a security protection capability score is generated according to the interception success rate and the alarm delay (such as the time difference from the occurrence of the attack to the log record).

[0134] The interception success rate and alert latency metrics characterize cloud security protection effectiveness from the perspectives of defense accuracy and real-time response, respectively. The interception success rate measures the percentage of unauthorized operations successfully blocked by security devices (such as the IAM policy engine) during simulated attacks (number of successful interceptions divided by total number of attack requests), reflecting the accuracy of policy configuration. Alert latency evaluates the real-time perception capabilities of the security monitoring system by calculating the difference between the attack occurrence timestamp and the alert event generation timestamp in the log audit system (Δt = Talarm - Tattack).

[0135] The method for generating a security protection capability score based on indicator normalization and weighting includes the following steps:

[0136] First, the interception success rate (P intercept ∈[0,100%], alarm delay (t delay >0) for normalization and set the maximum tolerable delay threshold t max (e.g. 60 seconds), define the alarm time factor η=1-min(t delay / t max ,1);

[0137] Then the two normalized indicators (interception success rate and alarm delay) are weighted and summed according to the preset weights (such as protection accuracy weight α = 0.7, response real-time weight β = 0.3) to obtain the comprehensive score S = α × P intercept ×100+β×η×100, and the readability evaluation level is given through segmented mapping (e.g., S ≥ 90 is Class A protection); the threat level parameters of specific attack scenarios are associated with the scoring process (e.g., the alarm delay weight is increased for high-risk operations);

[0138] Ultimately, a quantitative security capability portrait is formed that takes into account both precise protection and agile response.

[0139] In one embodiment, the cloud security verification method further includes:

[0140] Step S4: Use the resource harmless cleaning unit to harmlessly clean up the resources in the cloud security verification process; harmless cleaning up the resources in the cloud security verification process includes at least one of automatically revoking keys, destroying test resources, and building an exception handling mechanism.

[0141] In one embodiment, keys are automatically revoked:

[0142] (1) Calling a cloud platform API (such as AWS IAM DeleteAccessKey) to immediately invalidate the AKSK;

[0143] (2) Double cleanup verification is adopted, that is, the main process deletes resources through the API, and the backup process forcibly reclaims residual instances through the underlying interface (such as the Kubernetes controller).

[0144] In one embodiment, the test resources are destroyed: isolated resources (such as destroying a temporary VPC and a storage bucket) are deleted through an Infrastructure as Code (IaC) tool (such as Terraform, which is an IaC tool used to define and manage cloud resources through code and to automate the creation, modification, and destruction of cloud resources); VPC is a virtual private network provided by the cloud platform, in which users can create an isolated network environment, including subnets, routing tables, and network ACL rules, which is used to isolate different resource groups and ensure network security.

[0145] In one embodiment, an exception handling mechanism is constructed: if resource cleanup fails (such as API throttling), an alarm is triggered and a manual review process is started.

[0146] As can be seen from the above, the present invention constructs a harmless closed-loop control mechanism based on AKSK, which is as follows:

[0147] (1) Generation and task binding: AKSK is created through the cloud platform API, and its life cycle is strictly bound to the attack simulation task (generated when the task starts and automatically expires after timeout or completion);

[0148] (2) Enforce isolation with the minimum permission policy for the corresponding scenario: Bind the minimum permission policy for the corresponding scenario in JSON format to AKSK (e.g., only allow reading of the specified bucket), and implement logical isolation through an independent VPC subnet or dedicated test resource group;

[0149] (3) Automated resource cleanup: After the task is completed, the cloud platform API (such as DeleteAccessKey) is called to immediately revoke the AKSK, and the test resources are destroyed through Infrastructure as Code (Terraform) to ensure zero residual.

[0150] The present invention accurately marks simulated attacks based on traffic feature identification, as follows:

[0151] (1) Request header embedding: A signature field (e.g., X-Simulated-Attack: true) is forcibly added to the API request header of the simulated attack, allowing security devices to identify and distinguish simulated traffic from real attacks.

[0152] (2) Signature verification linkage: Combined with AKSK to generate a digital signature, the signature hash value is embedded in the request header (such as X-Signature: sha256 (SecretKey + Timestamp)) to ensure that the identity cannot be forged;

[0153] (3) Collaborative processing of security devices: The cloud firewall performs "recording without blocking" or "downgrading" on simulated traffic based on feature identification to avoid false alarms that interfere with production;

[0154] It breaks through the limitation of traditional solutions that simulated traffic cannot be distinguished from real attacks, and achieves accurate marking of attack behaviors and risk control.

[0155] The present invention implements a multi-dimensional security capability assessment with real-time verification, as follows:

[0156] (1) Real-time response capture: Instantly obtain security device response data (such as IAM policy interception status code and WAF blocking log) through the cloud platform audit log streaming interface (such as AWS CloudTrail real-time event streaming);

[0157] (2) Multi-dimensional verification rule engine: A preset verification rule base (such as "unauthorized operations should trigger IAM rejection") is used to generate verification results by comparing log data with expected behavior in real time through the rule engine;

[0158] (3) Quantitative scoring output: Output a quantitative scoring report of security protection capability based on indicators such as interception success rate (e.g., 95%) and alarm delay (≤500ms);

[0159] It replaces traditional static policy checks and manual log analysis, and realizes the digital and quantitative verification of cloud security protection capabilities for the first time.

[0160] This invention uses a simulation engine that deeply integrates the attack chain with the cloud API, as follows:

[0161] (1) Standardized API attack simulation: Execute attack behaviors (such as calling ec2:TerminateInstances to simulate instance deletion) based entirely on the cloud platform's public API (such as AWS SDK) to avoid underlying intrusive operations.

[0162] (2) DryRun mode risk control: Enable the cloud service DryRun mode (such as dryRun=True for AWS API) in high-risk operations, which only verifies the validity of the permission policy without actually performing the operation.

[0163] (3) Adaptive attack path generation: Automatically generate attack chains based on the cloud environment resource topology (such as penetration from storage bucket to database), covering the entire chain from key leakage → unauthorized access → lateral penetration.

[0164] Solve the problem of disconnection between traditional penetration testing tools and cloud-native APIs, and achieve seamless integration of attack simulation and cloud platform capabilities.

[0165] The present invention has the following advantages:

[0166] (1) Integration of real attack simulation and harmless production environment

[0167] By generating AKSK and binding the minimum permission policy for the corresponding scenario, the attack chain (such as key leakage, unauthorized access, and lateral penetration) is simulated in a real cloud environment to ensure that the test scenario highly restores the real attack path.

[0168] By utilizing resource isolation mechanisms and automated cleanup technologies, we can prevent simulated operations from interfering with actual business, thus achieving "realistic attack behavior and zero operational risk."

[0169] (2) Real-time verification of security protection capabilities

[0170] Execute attack behaviors through the cloud platform's standard API, capture security device responses in real time (such as IAM policy interception, cloud firewall blocking, and log alerts), and directly verify the immediate effectiveness of protection rules.

[0171] It supports joint verification of multi-dimensional security capabilities (authorization control, intrusion detection, and audit tracking), breaking through the limitations of traditional static analysis or post-log auditing.

[0172] (3) Closed-loop control and automated testing

[0173] Full lifecycle management of AKSK and test resources (generation → use → destruction) eliminates the risk of key residue or test resource leakage.

[0174] Full-process automation (attack simulation, results analysis, and resource recovery) adapts to CI / CD pipelines, meeting the continuous security verification requirements of cloud-native scenarios. CI / CD (Continuous Integration / Continuous Delivery) is a software development practice, and this solution supports integrated automated security testing.

[0175] (4) Accurate labeling and controllable risks

[0176] Traffic feature identification technology is used to embed tags in simulated attack requests, allowing security devices to distinguish simulated traffic from real attacks, avoiding misjudgment and interference with normal alarm systems.

[0177] All operations are strictly limited to the minimum permission policy scope of the corresponding scenario, ensuring that unauthorized attempts only trigger alarms and do not actually perform high-risk operations (such as deleting production data).

[0178] (5) Cost and efficiency optimization

[0179] Replace traditional manual penetration testing, reduce dependence on security experts, and improve test coverage and frequency.

[0180] Through deep integration with cloud platforms through standardized APIs, customized development costs are reduced and it is suitable for unified security verification in multi-cloud / hybrid cloud environments.

[0181] Figure 2 FIG. 1 shows a structural diagram of an electronic device according to another embodiment of the present invention. Figure 2 As shown, the electronic device includes:

[0182] one or more processors 10;

[0183] a memory 20 configured to store one or more computer programs;

[0184] a communication interface 30 configured to enable the processor 10 and the memory 20 to communicate with an external device;

[0185] When the computer program is executed by the one or more processors 10, the electronic device executes the cloud security verification method.

[0186] In one embodiment, the electronic device may be a laptop computer, a tablet computer, a mobile device, a smartphone, a smart watch, or other electronic devices.

[0187] According to another embodiment of the present invention, a computer-readable storage medium is provided, comprising a computer program, which enables the electronic device to execute the cloud security verification method when the computer program is executed on the electronic device.

[0188] Throughout this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples" indicate that a particular feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any appropriate manner in any one or more embodiments or examples. Furthermore, those skilled in the art may connect and combine the various embodiments or examples described in this specification, as well as features of the various embodiments or examples, without conflicting requirements.

[0189] Furthermore, terms such as "first" and "second" are used for descriptive purposes only and should not be interpreted as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, features defined as "first" and "second" may explicitly or implicitly include at least one feature. Throughout the description of the present invention, unless otherwise explicitly and specifically defined, "plurality" means two or more.

[0190] Any process or method description in the flowchart or other descriptions herein can be understood as representing a module, segment or portion of executable instructions, including one or more steps for implementing a specific logical function or process. The scope of the preferred embodiments of the present invention includes additional implementations, in which, depending on the functions involved, these functions can be performed in a substantially simultaneous manner or in a reverse order relative to the order shown or discussed, which should be understood by those skilled in the art to which the embodiments of the present invention relate.

[0191] The logic and / or steps represented in the flowcharts or other content described herein can be considered, for example, an ordered list of executable instructions for implementing logical functions, and can be contained in any computer-readable medium for use by an instruction execution system, apparatus, or device (a computer-based system, a system including a processor, or other system that can retrieve instructions from an instruction execution system, apparatus, or device and execute them), or in conjunction with such instructions to execute a system, apparatus, or device. For the purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use in, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (non-exhaustive) of computer-readable media include: an electrical connection with one or more wires (electronic devices), a portable computer disk cartridge (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CD-ROM). Furthermore, the computer-readable medium may even be the paper or other suitable medium on which the program can be printed, as the program can be obtained electronically, for example by optically scanning the paper or other medium, and then edited, interpreted or processed in another suitable manner if necessary, and then stored in the computer memory.

[0192] It should be understood that parts of the present invention may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or combination of the following known in the art may be used: a discrete logic circuit having logic gates for implementing logic functions on data signals, an application-specific integrated circuit having appropriate combinational logic gates, a programmable gate array (PGA), a field programmable gate array (FPGA), and the like.

[0193] Those skilled in the art will appreciate that all or part of the steps carried out by the method for implementing the above embodiments can be completed by program instructions related to hardware, and the program can be stored in a computer-readable storage medium. When executed, it includes one or a combination of the steps of the method embodiment.

[0194] Furthermore, the functional units in the embodiments of the present invention may be integrated into a single processing module, or each unit may exist physically independently, or two or more units may be integrated into a single module. The aforementioned integrated module may be implemented in the form of hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as a standalone product, it may be stored in a computer-readable storage medium. The storage medium may be a read-only memory, a magnetic disk, or an optical disk, etc.

[0195] The foregoing description is merely a specific embodiment of the present invention and does not limit the scope of protection of the present invention. Any person skilled in the art will readily conceive of modifications and variations within the technical scope of the present invention, all of which are intended to be encompassed within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be the scope of protection of the claims.

Claims

1. A cloud security verification method, characterized in that: include: Generate and isolate AKSK, where AKSK is an access key pair used for authentication; Combined with the AKSK, simulate attack behavior; and Verify security capabilities based on simulated attack behaviors; The generating and isolating AKSK includes: Generate AKSK through the cloud platform; Bind the AKSK to the minimum permission policy for the corresponding scenario, where the minimum permission policy for the corresponding scenario is a rule that controls access rights and grants only the minimum permissions required to complete a specific task. Create test resources based on the minimum permission policy for the corresponding scenario to isolate the AKSK and ensure that the simulated operation only acts on the isolated environment, where the test resources refer to the isolated environment resources temporarily created for the simulated attack scenario; The combination of the AKSK and the simulated attack behavior includes: A feature field is forcibly added to the API request header of the simulated attack so that security devices can identify and distinguish simulated traffic from real attacks. A digital signature is generated in combination with AKSK, and the signature hash value is embedded in the API request header to ensure that the identification cannot be forged.

2. The cloud security verification method according to claim 1, wherein: The simulated attack behavior includes at least one of key leakage, authority abuse, lateral penetration and simulated cross-account attack.

3. The cloud security verification method according to claim 1, wherein: The security capability verification based on simulated attack behavior includes: Capture logs in real time; Analyze response behavior based on the log; Based on the analysis of the response behavior, a quantitative assessment is performed to obtain a security protection capability score; the quantitative assessment is to sum up several indicators with preset weights; the several indicators are associated with the response behavior, and the several indicators include those based on interception success rate and alarm delay.

4. The cloud security verification method according to claim 1, wherein: Also includes: Clean up resources during the cloud security verification process; The harmless cleanup of resources during the cloud security verification process includes at least one of automatically revoking keys, destroying test resources, and establishing an exception handling mechanism; The construction of the exception handling mechanism includes: if resource cleanup fails, triggering an alarm and starting a manual review process.

5. Cloud security verification system, characterized in that, The cloud security verification method according to any one of claims 1 to 4, wherein the cloud security verification system comprises: An AKSK generation and isolation unit, configured to generate and isolate an AKSK, wherein the AKSK is an access key pair used for identity authentication; an attack behavior simulation unit, configured to simulate attack behavior in combination with the AKSK of the AKSK generation and isolation unit; and The security capability verification unit is used to perform security capability verification based on the simulated attack behavior of the attack behavior simulation unit.

6. The cloud security verification system according to claim 5, characterized in that: Also includes: Resource cleanup unit, used to clean up resources during the cloud security verification process; The harmless cleanup of resources in the cloud security verification process includes at least one of automatically revoking keys, destroying test resources, and building an exception handling mechanism.

7. An electronic device, characterized in that include: one or more processors; a memory configured to store one or more computer programs; a communication interface configured to enable the processor and the memory to communicate with an external device; When the computer program is executed by the one or more processors, the electronic device executes the cloud security verification method as described in any one of claims 1 to 4.

8. A computer-readable storage medium comprising a computer program, characterized in that When the computer program runs on an electronic device, the electronic device executes the cloud security verification method as described in any one of claims 1 to 4.

Images