Cloud security verification method and system, electronic equipment and computer readable storage medium

Abstract

The invention relates to the technical field of cloud security verification, in particular to a cloud security verification method and system, electronic equipment and a computer readable storage medium. The method comprises the steps of generating and isolating an AKSK which is an access key pair for identity verification, simulating an attack behavior in combination with the AKSK, and performing security capability verification based on the simulated attack behavior. According to the method, the AKSK is generated to simulate the attack in the real cloud environment, it is ensured that the test scene highly restores the real attack path, and the technical problem that the traditional security test mainly depends on static policy analysis (such as IAM policy grammar check) and artificial penetration test and cannot simulate the complete attack path after AKSK leakage in the real attack chain is solved.

Description

Technical Field

[0001] The present invention belongs to the technical field of cloud security verification, and particularly 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 detects 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 links such as environmental information collection, vulnerability exploitation, and privilege escalation to simulate potential attack paths. Some solutions simulate attacks through cloud services in a sandbox environment, but they cannot truly reflect the security policies and protection effects of the production environment; there are also some solutions that rely on manual penetration testing and static log analysis, with limitations such as 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 the leakage of AKSK in a real attack chain (such as key stealing → 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 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, there is provided a cloud security verification method, which includes the following steps:

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

[0007] Combine the AKSK and simulate attack behaviors; and

[0008] Based on the simulated attack behaviors, perform security capability verification.

[0009] Combined with the first aspect, in some embodiments of the present invention, the generating and isolating AKSK includes:

[0010] Generate AKSK through a 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 for controlling access permissions and only grants the minimum permissions required for the subject to complete a specific task;

[0012] Create test resources according to the minimum permission policy of the corresponding scenario to isolate the AKSK, ensuring that the simulated operations only act on the isolated environment, where the test resources refer to the isolated environment resources temporarily created for the simulation attack scenario.

[0013] Combined with the first aspect, in some embodiments of the present invention, the simulating attack behavior by combining the AKSK includes:

[0014] Forcibly add a feature field to the API request header of the simulated attack for the security device to identify and distinguish the simulated traffic from the real attack, generate a digital signature by combining the AKSK, and embed the signature hash value into the API request header to ensure that the identity cannot be forged.

[0015] Combined with the first aspect, in some embodiments of the present invention, the simulating attack behavior includes at least one of key leakage, privilege abuse, lateral penetration, and simulating cross-account attacks.

[0016] Combined with the first aspect, in some embodiments of the present invention, the verifying the security capabilities based on the simulating attack behavior includes:

[0017] Capture logs in real time;

[0018] Analyze the response behavior based on the logs;

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

[0020] Combined with the first aspect, in some embodiments of the present invention, it further includes:

[0021] Harmlessly clean up the resources in the cloud security verification process;

[0022] Harmlessly 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;

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

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

[0025] An AKSK generation and isolation unit for generating and isolating the AKSK, where the AKSK is an access key pair for authentication;

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

[0027] A security capability verification unit, configured to perform security capability verification based on the simulated attack behaviors of the attack behavior simulation unit.

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

[0029] A resource harmless cleaning unit, configured to harmlessly clean resources during the cloud security verification process;

[0030] Harmlessly cleaning resources during 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 external devices;

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

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

[0037] Compared with the prior art, the beneficial effects of the present invention are:

[0038] By generating AKSK to simulate attacks in a real cloud environment, the present invention ensures that the test scenario highly restores the real attack path, and solves the technical problem that traditional security tests mainly rely on static policy analysis (such as IAM policy syntax checking) and manual penetration testing, and cannot simulate the complete attack path after the leakage of AKSK in the real attack chain. Description of the Drawings

[0039] To more clearly illustrate the solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those skilled in the art, without creative efforts, other drawings can be obtained based on these drawings.

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

[0041] Figure 2 It is a schematic structural diagram of an electronic device according to an embodiment of the present invention. Detailed implementation manners

[0042] The following will further elaborate on the present application in conjunction with the drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the related invention, rather than limiting the invention. Additionally, it should be noted that for the convenience of description, only the parts related to the invention are shown in the drawings.

[0043] Currently, 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 leakage of AKSK in the real attack chain (such as key stealing → unauthorized access → lateral penetration).

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

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

[0046] The interaction rules of the cloud security verification system:

[0047] Data flow: AKSK and test resource ARN are used as the core concatenated fields, running through all units;

[0048] Event trigger: Each unit passes the task status (such as policy ready, attack completed, alarm triggered) through a message queue (such as AWS SQS).

[0049] ARN is a string format used in AWS to uniquely identify a resource. For example, arn:aws:s3:::test-bucket, and its function is to specify specific cloud resources, such as buckets, instances, etc.

[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 variable substitution of the smallest permission policy template for the JSON corresponding scenario, and automatically deploying an isolation environment (test bucket / VPC) according to the policy statement. "Corresponding" in the smallest permission policy for the corresponding scenario means that for example, if the test bucket uses an attack to cross-domain access other users, only the bucket and part of the IAM account policy will be automatically retained, and other policies will not be used. These policies are all generated by the system according to the attack scenario. The AKSK can be arbitrary, which can be actively generated by a machine or not actively generated by a machine.

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

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

[0053] In one embodiment, automatically deploying an isolation environment according to a policy statement includes creating resources according to the generated ARN rules and adding the isolated_test label to block production traffic.

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

[0055] SDK loading: Load the corresponding SDK (Boto3 / AzureCLI / gcloud) according to the cloud platform type (AWS / Azure / GCP).

[0056] The attack behavior simulation unit is used to simulate attack behaviors in combination with AKSK; in one embodiment, the simulated attack behaviors include at least one of a key leakage scenario, a privilege abuse scenario, a lateral penetration scenario, and a simulated cross-account attack scenario;

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

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

[0059] In one embodiment, the lateral penetration scenario includes cross-service attack chain orchestration (such as s3→ECS→RDS, performing multi-step attacks based on a playbook);

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

[0061] Attack traffic identification mechanism of the cloud security verification system

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

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

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

[0065] In one embodiment, response behavior analysis includes rule engine matching of expected interception effects (such as permission denial, WAF block), for example, predefined verification rules, matching log entries with error_code = AccessDenied or waf_action = BLOCK;

[0066] In one embodiment, quantitative evaluation includes calculating a comprehensive security protection score. For example, a radar chart is generated based on the interception success rate and alert latency, and the protection level (A - F) is obtained by weighting the threat level.

[0067] The alarm correlation analysis of this cloud security verification system

[0068] Multi-log correlation: Align IAM policy interception events (CloudTrail) with WAF block records (WAF Logs) and SIEM alerts (Splunk) according to a time window; SIEM is a security management system used for centralized collection, analysis, and reporting of security event logs, and its function is to monitor and respond to security threats in real time.

[0069] IAM (Identity and Access Management) policy: A set of rules defining resource access permissions in the cloud platform, used to limit the operation scope of AKSK.

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

[0071] In one embodiment, the automatic revocation key includes an immediately invalidated AKSK. For example, call the IAMDeleteAccessKey API and record the revocation operation audit log through Secrets Manager;

[0072] In one embodiment, destroying test resources includes hierarchical cleaning of network / storage / compute resources. For example, call the underlying API (such as AWS EC2 TerminateInstances) to forcibly terminate residual resources;

[0073] In one embodiment, building an exception handling mechanism includes: if resource cleaning fails (such as API rate limiting), trigger an alarm and start a manual review process.

[0074] As Figure 1 shown, in one embodiment, a cloud security verification method is provided. This cloud security verification method is applicable to the above cloud security verification system. The cloud security verification method includes:

[0075] Step S1, use the AKSK to generate and isolate the AKSK with the isolation unit, that is, this involves generating temporary credentials with a time window. Among them, AKSK (Access Key / Secret Key) is an access key pair for authentication. The Access Key is a public identifier, and the Secret Key is an encrypted credential. A key refers to in the fields of cloud computing and network security, a key usually refers to an access key (AK) and a secret key (SK). These two keys 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 requests to ensure the authenticity and integrity of the requests. AKSK (Access Key and Secret Key) refers to access and security keys with a time limit. They automatically expire after a certain period of time, thus providing a temporary and secure way to access cloud resources.

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

[0077] Step S11, generate the AKSK through the cloud platform native API (such as AWS STS AssumeRole). The key validity period is strictly bound to the attack simulation task cycle (for example, generated when the task starts and automatically expires when timed out or completed); and ensure security through an additional lifecycle management mechanism (such as regular rotation or manual cleaning after the task is completed).

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

[0079] First, define a policy template in JSON format (including the version number, authorization effect, and specific Action-Resource constraint combinations, such as only allowing the s3:GetObject permission to access a specific bucket. The JSON policy template uses a template engine to render the policy file). Then, when generating the AKSK, replace the placeholder variables reserved in the policy template (such as the test bucket name) with the generated isolation identifier (such as the task ID). Finally, generate a concrete permission policy through the SDK (such as the create_policy method of AWS boto3). (The generation of the concrete permission policy is automated according to the attack scenario. By deeply studying the attack path and cloud service characteristics, the system can automatically generate fine-grained and targeted permission policies based on specific attack simulation scenarios. These policies are generated through JSON templates and bound to the AKSK to ensure that they can only perform preset operations, which not only improves the authenticity and efficiency of the attack simulation but also minimizes security risks through permission isolation.) And attach it to the temporary key. The following gives a specific embodiment:

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

[0081] "Statement":[{" / / Subject of the permission statement, multiple sets of rules can be stacked

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

[0083] "Action":["s3:GetObject"], / / List of authorized API operations, limited to only allowing S3 object reading

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

[0085] / / ↑ Note: test-bucket is a placeholder and will be replaced with the isolation bucket name generated in step S13 (such as test-bucket- <task-id>)

[0086] The asterisk (*) is a wildcard, indicating that only access to all objects within the bucket is allowed, but does not include bucket-level operations (such as ListBucket)}}].

[0087] The least privilege policy for the corresponding scenario is a security principle designed to ensure that a user or system is only granted the minimum permissions required to perform its tasks, without providing additional, unnecessary permissions. This policy can effectively reduce security risks and prevent data leakage, system abuse, or other security incidents caused by excessive permissions. In a cloud computing environment, the least privilege policy for the corresponding scenario is typically implemented through identity and access management (IAM) policies.

[0088] Step S13, create test resources (such as a dedicated VPC subnet, a temporary bucket) according to the least privilege policy for the corresponding scenario to isolate the AKSK, ensuring that the simulation operations only act on the isolated environment, physically / logically separated from the production resources, that is, automatically deploy the isolated environment (test bucket / VPC) according to the policy statement. For example, create resources according to the generated ARN rules and add the isolated_test tag to block production traffic;

[0089] In one embodiment, according to the permission boundary solidified in step S12, call the VPC service to create a network isolation domain (for example, set the ACL rules for exclusive subnets to prohibit cross-subnet traffic), and at the same time, according to the arn rules declared in the Resource in the policy (such as arn:aws:s3:::test-bucket- <task-id> / *) Create a temporary storage bucket with a unique suffix and label it as "isolated_test" through the resource tagging system, achieving a two-way match between the permission policy in step S12 and the physical resources in step S13 - the AKSK can only access the target resources predefined by the policy, and these resources themselves are completely isolated from the production environment (business-critical resources such as the online core database and formal business storage buckets) through logical isolation (subnet ACL) and namespace isolation (the generated storage bucket name).

[0090] Among them, test resources refer to the isolated environment resources temporarily created for simulating attack scenarios and have the following characteristics:

[0091] Generation: Create or generate data or resources in real time when actually needed. In the field of information security, generation is usually used to create temporary access credentials or keys instead of pre-configured and statically stored credentials. This approach can improve security because even if the temporary credentials are leaked, their validity period is limited, thus reducing the risk of being maliciously exploited. For example, a task-specific storage bucket (test-bucket-<task ID>) is automatically created by code (such as aws s3api create-bucket of AWS CLI) when the task starts;

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

[0093] Automatic Destruction: Delete immediately after the task is completed (such as calling aws s3 rb s3: / / test-bucket-xxx --force to empty the storage bucket).

[0094] Simulation operations refer to non-destructive attack simulation behaviors performed on test resources. For example: Restricted API Calls: Under the constraint of the minimum permission policy for the corresponding scenario, simulate malicious code attempting to read an object from the test storage bucket (s3:GetObject), but unable to damage other services (such as unable to trigger a Lambda function).

[0095] Result Controllability: The operation only affects temporary resources (such as 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).

[0096] In one embodiment, production resources refer to the core resources carrying actual business (such as the online database, production environment s3 storage bucket), and need to be isolated from the test environment through the following two methods:

[0097] Logical Isolation: The IAM policy explicitly excludes access permissions for testing AKSK (e.g., specifying Resource: "arn:aws:s3:::prod-bucket / *" in the Deny rule).

[0098] Physical Isolation: Use completely independent AWS accounts or enforce isolation through resource tags (e.g., Environment: Prod) combined with SCP (Service Control Policy). SCP is a policy in AWS used to define organizational-level permission control, restricting the scope of operations for accounts or roles. Its role is to ensure the security of resources and prevent abuse.

[0099] Step S2: Use the attack behavior simulation unit combined with AKSK to simulate attack behaviors. That is, forcefully add a feature field (e.g., X-Simulated-Attack: true) to the API request header of the simulated attack for the security device to identify and distinguish simulated traffic from real attacks. Combine AKSK to generate a digital signature and embed the signature hash value into the request header (e.g., X-Signature: sha256(SecretKey+Timestamp)) to ensure that the identity cannot be forged.

[0100] In one embodiment, the simulated attack behaviors include at least one of the scenarios of key leakage, privilege abuse, lateral penetration, and simulated cross-account attack scenarios;

[0101] In one embodiment, in the key leakage scenario, simulate that malware obtains AKSK through methods such as environment variable leakage and log file residue. That is, simulate that malware deploys a simulation program in an isolated test environment and injects environment variables containing AKSK, and at the same time constructs log records containing false AKSK, simulating the process of malware scanning environment variables and parsing log files to steal credentials. For example, run an HTTP service with preset environment variables in a temporary container and trigger abnormal log writing, and use regular expression matching to extract AKSK fragments from the log. All operations during the process are carried out under the control of AKSK with the minimum permission policy corresponding to the relevant scenario, and the environment variables and log files are automatically cleaned up after testing to ensure the authenticity and harmlessness of the attack simulation. In one embodiment, preset environment variables (AWS_ACCESS_KEY_ID = xxx) in an isolated container, trigger simulated log writing, and extract the placeholder key.

[0102] "Malware" refers to a controllable test code module used to illegally obtain temporary access credentials (AKSK) in a simulated network attack, and its function is limited to specific test scenarios rather than actual damage;

[0103] "Environment variables" are key-value pair data stored in the operating system or container during the runtime of a cloud service instance, usually containing sensitive credentials such as AKSK. In a simulated attack, the configuration oversight of the development environment is reproduced by presetting environment variables containing AKSK.

[0104] "Log files" refer to the record files automatically generated during the operation of cloud applications. Plaintext AKSK may be written into error logs due to programming defects.

[0105] In one embodiment, in the scenario of privilege abuse, AKSK is actually used to perform operations beyond the scope (performing operations or resource accesses beyond what is allowed by the associated permission policy using temporary access credentials (such as temporary AK / SK); such operations are essentially privilege abuse and may be caused by incorrect policy configuration, credential leakage, or privilege escalation vulnerabilities, such as calling ec2:TerminateInstances to attempt to delete unauthorized ECS instances). In one embodiment, when calling the API, the DryRun=True parameter is forcibly appended (such as AWS EC2 TerminateInstances), and the AccessDenied response rate is statistically counted.

[0106] Simulate high-risk operations through the DryRun mode of cloud APIs, which only triggers policy verification without actual execution. (DryRun (simulated execution) is a special mode provided by cloud service APIs that allows users or programs to simulate the actual execution process of an operation without actually modifying resources or triggering side effects. Its core purpose is to verify operation permissions, parameter legality, or resource status and is commonly used in debugging or pre-check scenarios. Such as the dryRun parameter of AWS)

[0107] In one embodiment, in the scenario of lateral infiltration, the cloud platform security token service is called through AKSK (such as AWS STSGetSessionToken), temporary credentials are obtained, and cross-service attacks are attempted (such as infiltrating from an s3 bucket to an ECS instance).

[0108] The security token service is a component for issuing and managing temporary credentials provided by the cloud platform, used to generate access credentials with limited permissions and time validity (such as temporary AK / SK, security tokens). Typical representatives include:

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

[0110] Alibaba Cloud STS: Generates temporary tokens through the AssumeRole interface.

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

[0112] A cross-service attack refers to an attacker using a privilege vulnerability in a cloud service (such as an over-permissioned temporary credential) to move laterally to other services and perform unauthorized operations, forming an attack chain that cascades across multiple services.

[0113] The typical attack path is as follows:

[0114] Initial penetration: Access a low-privilege service (such as an s3 bucket) through a leaked AKSK.

[0115] Privilege detection: Use the current credential to attempt to call other service APIs (such as ECS, IAM, Lambda).

[0116] Lateral privilege escalation:

[0117] Scenario 1 - Data leakage: Obtain the startup script or configuration file of an ECS instance from an s3 bucket and extract sensitive information (such as a database password).

[0118] Scenario 2 - Service abuse: Use the read permission of s3 to obtain the Lambda function code, analyze the vulnerability, and trigger a malicious function to operate on the ECS instance.

[0119] Scenario 3 - Role hijacking: Call sts:AssumeRole to attempt to assume a higher-privilege role and then control the entire cloud account.

[0120] In one embodiment, in a simulated cross-account attack, an AKSK is used to attempt to access resources in other accounts (cross-account policy verification is required), and other account resources include bucket resources, computing resources, database resources, permission and identity resources, network resources, keys and sensitive data, etc.

[0121] Step S3: Use a security capability verification unit to perform security capability verification based on the simulated attack behavior.

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

[0123] Step S31: Real-time log capture; in one embodiment, obtain operation logs in real time through a cloud platform audit service API (such as AWS CloudTrail LookupEvents), and filter out requests related to the AKSK through the request_id value.

[0124] 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.

[0125] The request_id (Request ID) is a unique identifier automatically generated by the cloud platform for each API request, and is used to track the entire life cycle of a single request (such as request routing, processing, and response) in a distributed system. The request_id is attached in the return packet obtained each time an API is requested.

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

[0127] Among them, when detecting whether the IAM policy engine intercepts an unauthorized request, simulate API operations initiated by accounts or roles with different permissions, such as accessing unauthorized resources or performing unauthorized operations. If the API returns a 403 AccessDenied status code (or a similar access denial prompt), it can be confirmed that the interception is effective. The blocking rule is a set of predefined security policies in the cloud firewall (such as AWS WAF) (such as IP blacklist, malicious request pattern matching, SQL injection rules, etc.). When verifying, actively construct test requests that trigger these rules (such as injecting attack payloads, accessing illegal paths), observe whether the requests are blocked (such as returning 403 Forbidden or a custom interception page), and check whether the corresponding requests in the firewall interception log are marked as BLOCK actions. The cloud firewall performs "only log without blocking" or "degraded handling" on the simulated traffic according to the feature identifier to avoid misjudgment and interfering with production alarms. For the log audit system (such as SIEM tools Splunk, QRadar), this system centrally collects and analyzes cloud environment logs (such as API call records, user behavior logs). An alarm event refers to a security notification triggered according to set rules (such as "abnormal high-frequency AKSK calls", "cross-region login"). When checking, first perform abnormal behavior operations in 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 in the log query interface for the corresponding time period 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 identification, and operation details, and test whether the alarm notification channel can push messages normally.

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

[0129] Policy analysis: Analyze permission rules such as IAM policies, resource policies (such as S3 bucket policies), and service control policies (SCP).

[0130] Permission decision: Based on the principal, action, resource, and condition of the request, determine whether to allow or deny the request.

[0131] Policy merging: When multiple policies (such as user policies, resource policies, and organizational SCP) act simultaneously, merge the results according to the priority and logical operators (such as Deny taking precedence).

[0132] Step S33, based on the analysis of the response behavior, conduct a quantitative evaluation, that is, generate a security protection capability score according to the interception success rate and alarm delay (such as the time difference from the occurrence of the attack to the logging).

[0133] The two indicators of the interception success rate and alarm delay respectively characterize the cloud security protection effectiveness from the two dimensions of defense accuracy and response timeliness. The interception success rate reflects the protection accuracy of the policy configuration by statistically simulating the proportion of successful blocking of unauthorized operations by security devices (such as the IAM policy engine) in the attack (the number of successful interceptions / the total number of attack requests); the alarm delay evaluates the real-time perception ability of the security monitoring system by calculating the difference between the attack occurrence timestamp and the alarm event generation timestamp in the log audit system (Δt = T_alarm - T_attack).

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

[0135] First, standardize the interception success rate (P intercept ∈[0, 100%]) and alarm delay (t delay > 0), set the maximum tolerance delay threshold t max (such as 60 seconds), define the alarm timeliness factor η = 1 - min(t delay / t max , 1);

[0136] Then, weight and sum the two normalized indicators (interception success rate and alarm delay) according to the preset weights (such as the protection accuracy weight α = 0.7 and the response timeliness weight β = 0.3) to obtain the comprehensive score S = α × P intercept × 100 + β × η × 100, and give a readable evaluation level through piecewise mapping (such as S ≥ 90 for level A protection); during the scoring process, associate the threat level parameters of specific attack scenarios (such as the weight of the alarm delay for high-risk operations increases);

[0137] Finally, form a quantitative security capability portrait that takes into account both precise protection and agile response.

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

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

[0140] In one embodiment, automatically revoking keys:

[0141] (1) Invoke the cloud platform API (such as AWS IAM DeleteAccessKey) to immediately invalidate the AKSK;

[0142] (2) Adopt dual cleaning verification, 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).

[0143] In one embodiment, destroying test resources: Delete isolated resources (such as destroying a temporary VPC, bucket) 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 is used for automating the creation, modification, and destruction of cloud resources); A VPC is a virtual private network provided in the cloud platform where users can create isolated network environments, including subnets, route tables, and network ACL rules, and its function is to isolate different resource groups to ensure network security.

[0144] In one embodiment, building an exception handling mechanism: If resource cleaning fails (such as API throttling), trigger an alarm and start a manual review process.

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

[0146] (1) Generation is bound to the task: Create AKSK through the cloud platform API, and its life cycle is strictly bound to the attack simulation task (generated when the task starts and automatically invalidates when it times out or is completed);

[0147] (2) The minimum permission policy for the corresponding scenario is used for forced isolation: Bind the minimum permission policy in JSON format for the corresponding scenario to the AKSK (such as only allowing reading of a specified bucket), and achieve logical isolation through an independent VPC subnet or a dedicated test resource group;

[0148] (3) Automated resource cleanup: After the task ends, immediately revoke the AKSK by calling the cloud platform API (such as DeleteAccessKey), and destroy the test resources through Infrastructure as Code (Terraform) to ensure zero residue.

[0149] The present invention is based on the accurate marking of simulated attacks based on traffic feature identifiers, specifically as follows:

[0150] (1) Request header implantation identifier: Forcefully add a feature field (such as X-Simulated-Attack: true) to the API request header of the simulated attack for security devices to identify and distinguish simulated traffic from real attacks;

[0151] (2) Signature verification linkage: Generate a digital signature in combination with the AKSK, and embed the signature hash value into the request header (such as X-Signature: sha256(SecretKey+Timestamp)) to ensure that the identifier cannot be forged;

[0152] (3) Security device collaborative processing: The cloud firewall performs "only record without blocking" or "degraded handling" on the simulated traffic according to the feature identifier to avoid misjudgment and interference with production alarms;

[0153] Break through the limitation that simulated traffic and real attacks cannot be distinguished in traditional solutions, and achieve accurate marking of attack behaviors and controllable risks.

[0154] The present invention realizes the multi-dimensional security capability evaluation of real-time verification, specifically as follows:

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

[0156] (2) Multi-dimensional verification rule engine: Preset a verification rule library (such as "overprivileged operations should trigger IAM rejection"), and use the rule engine to compare the log data with the expected behavior in real time to generate verification results;

[0157] (3) Quantitative scoring output: Output a quantitative scoring report of the security protection ability according to indicators such as the interception success rate (such as 95%) and alarm latency (≤500ms);

[0158] Replace traditional static policy checks and manual log analysis, and for the first time realize the automated and quantitative verification of cloud security protection capabilities.

[0159] The present invention adopts a simulation engine with deep integration of the attack chain and cloud APIs, specifically as follows:

[0160] (1) Standardized API Attack Simulation: Execute attack behaviors (such as calling ec2:TerminateInstances to simulate instance deletion) entirely based on publicly available APIs of cloud platforms (such as AWS SDK), avoiding underlying invasive operations.

[0161] (2) DryRun Mode Risk Control: Enable the DryRun mode of cloud services (such as dryRun = True for AWS API) in high-risk operations, only verifying the effectiveness of permission policies without actually executing operations.

[0162] (3) Adaptive Attack Path Generation: Automatically generate attack chains according to the resource topology of the cloud environment (such as infiltrating from a bucket to a database), covering the entire link of key leakage → unauthorized access → lateral infiltration.

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

[0164] The present invention has the following advantages:

[0165] (1) Seamless integration of real attack simulation and harmless production environment

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

[0167] Utilize the resource isolation mechanism and automated cleaning technology to avoid interference of simulation operations on actual business, and achieve "real attack behavior, zero operation risk".

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

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

[0170] Support joint verification of multi-dimensional security capabilities (permission control, intrusion detection, audit tracking), breaking through the limitations of traditional static analysis or post-event log auditing.

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

[0172] Full life cycle management of AKSK and test resources (generation → use → destruction) to eliminate the risk of key residue or test resource leakage.

[0173] Full-process automation (attack simulation, result analysis, resource recovery) adapts to the CI / CD pipeline to meet the continuous security verification requirements in the cloud-native scenario. CI / CD (Continuous Integration / Continuous Delivery): A software development practice of continuous integration / continuous delivery. This solution supports automated security testing integrated with it.

[0174] (4) Precise marking and risk controllability

[0175] Adopt traffic feature identification technology to implant marks in simulated attack requests, enabling security devices to distinguish simulated traffic from real attacks and avoiding misjudgment from interfering with the normal alarm system.

[0176] All operations are strictly restricted within the minimum permission policy scope of the corresponding scenario to ensure that unauthorized attempts only trigger alarms without actually executing high-risk operations (such as deleting production data).

[0177] (5) Cost and efficiency optimization

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

[0179] Deeply integrate with the cloud platform through standardized APIs, reduce customization development costs, and are applicable to unified security verification in multi-cloud / hybrid cloud environments.

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

[0181] One or more processors 10;

[0182] A memory 20 configured to store one or more computer programs;

[0183] A communication interface 30 configured to enable the processor 10 and the memory 20 to communicate with external devices;

[0184] When the computer program is executed by the one or more processors 10, the electronic device is caused to execute the cloud security verification method.

[0185] In one embodiment, the electronic device can be a laptop computer, a tablet computer, a mobile device, a smart phone, a smart watch or other electronic devices.

[0186] According to another embodiment of the present invention, there is provided a computer-readable storage medium including a computer program, which when running on an electronic device, causes the electronic device to execute the cloud security verification method.

[0187] In the description of this specification, the descriptions referring to terms such as "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" mean that the specific features, structures, materials, or characteristics described in connection with the embodiments or examples are included in at least one embodiment or example of the present invention. In addition, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, without contradiction, those skilled in the art may connect and combine the various embodiments or examples described in the specification, as well as the features of the various embodiments or examples.

[0188] In addition, terms such as "first" and "second" are only used for description and should not be construed as indicating or implying relative importance or implicitly indicating the quantity of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one feature. In the description of the present invention, unless otherwise clearly and specifically defined, the meaning of "a plurality" is two or more.

[0189] Any process or method description in the flowchart or other descriptions herein can be understood as representing modules, segments, or portions of executable instructions, including one or more steps for implementing specific logical functions or processes. And the scope of the preferred embodiments of the present invention includes additional implementations, where, according to the functions involved, these functions can be executed in a substantially simultaneous manner or in the reverse order relative to the order shown or discussed, which should be understood by those skilled in the art in the field related to the embodiments of the present invention.

[0190] The logic and / or steps represented in the flowchart and / or other content described herein. For example, it can be considered an ordered list of executable instructions for implementing logical functions, which 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 systems that can obtain instructions from the instruction execution system and execute the instructions), apparatus, or device), or used in combination 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 transmit a program for use in an instruction execution system, apparatus, or device, or in combination with such an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection (electronic device) with one or more wires, a portable computer diskette (magnetic device), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable read-only memory (CDROM). In addition, a computer-readable medium can even be paper or other suitable media on which a program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other media and then editing, interpreting, or otherwise processing it as appropriate, and then storing it in a computer memory.

[0191] It should be understood that parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can 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 well-known in the art can be used: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits having appropriate combinations of logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), and so on.

[0192] Those skilled in the art can understand that all or part of the steps carried by the methods of implementing the above embodiments can be completed by relevant hardware of program instructions, 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 embodiments.

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

[0194] What is described above is only the specific implementation of the present invention, which does not limit the protection scope of the present invention. Any fabrication and modification within the technical scope of the present invention that are easily conceivable by any person skilled in the art should be included within the protection scope of the present invention. Therefore, the protection scope of the claims should be taken as the protection scope of the present invention.

Claims

1. A cloud security verification method, characterized in that: include: Generate and isolate AKSK, where AKSK is an access key pair used for identity authentication; Combined with the AKSK, simulate attack behavior; and Security capability verification is performed based on simulated attack behaviors.

2. The cloud security verification method according to claim 1, characterized in that: The generating and isolating AKSK comprises: Generate AKSK through the cloud platform; Bind the AKSK to the minimum permission policy of the corresponding scenario, wherein the minimum permission policy of the corresponding scenario is a rule for controlling access rights, which only grants the subject the minimum permission required to complete a specific task; 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.

3. The cloud security verification method according to claim 1, characterized in that: 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 the security device 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.

4. The cloud security verification method according to claim 1, characterized in that: The simulated attack behavior includes at least one of key leakage, privilege abuse, lateral penetration, and simulated cross-account attack.

5. The cloud security verification method according to claim 1, characterized in that: The security capability verification based on simulated attack behavior includes: Capture logs in real time; Based on the log, analyzing the response behavior; Based on the analysis of the response behavior, a quantitative evaluation is performed to obtain a security protection capability score; the quantitative evaluation is to sum a number of 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.

6. The cloud security verification method according to claim 1, characterized in that: Also includes: Clean up resources in 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; The construction of the exception handling mechanism includes: if resource cleanup fails, triggering an alarm and starting a manual review process.

7. Cloud security verification system, characterized in that, The cloud security verification method according to any one of claims 1 to 6, wherein the cloud security verification system comprises: An AKSK generation and isolation unit, used for generating and isolating AKSK, wherein AKSK is an access key pair used for identity authentication; an attack behavior simulation unit, used 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.

8. The cloud security verification system according to claim 7, characterized in that: Also includes: Resource harmless cleaning unit, used to harmlessly clean up resources during 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.

9. 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-6.

10. 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-6.

Images