This paper will mainly introduce how to quickly find the positioning and repair cases of OSS buckets that are not configured to prevent hotlinking in the process of enterprise cloud by using the function of “Configuration Audit”.
preface
Configure audit (Config) integrates your resources scattered in various regions into a global resource list, which can be easily searched for global resources; At the same time, IT helps you record the history of configuration changes of IT resources on the cloud, continuously and automatically evaluate the compliance of resource configuration on the cloud, and realize IT compliance governance on the cloud. This article describes how to use configuration auditing (CONFIG) to help you quickly find and fix cases of OSS buckets that are not configured against hotlinking.
The actual case
Company A has 10 vertical business departments, each of which is allocated 1 to 2 OSS buckets for storing operational pictures and directly displaying the picture content using OSS generated links on the web page. We know that the cost of OSS is divided into storage fee and traffic fee. When a large number of external requests are made to obtain picture resources, the traffic fee shall be borne by the customers themselves. In order to prevent illegal websites from misappropriating picture resources, OSS has developed the “Anti-hotlinking” function. For detailed function description, please refer to: Hotlinking protection company A intends to use this technical solution and needs to enable hotlinking protection for OSS buckets and set the referer whitelist to.alibaba.com and.aliyun.com. As a classmate of the operation and maintenance of the company, I do not want to check and refer to the documentation for configuration of every Bucket. At the same time, I also need to make additional measures to prevent Bucket configuration from being modified twice.
At this time, he remembered a cloud product of Ali Cloud: Configuration Audit (CONFIG).
The ability to configure auditing (CONFIG) can be summarized into three points:
- Unified resource perspective, multi-region, and even cross-account;
- Rule checks whether the resource allocation meets the requirements;
- Continuously monitor resources and repair capabilities;
How does configuration auditing (Config) work?
The configuration data for the resource is centrally stored in a configuration audit (CONFIG) database via asynchronous message notifications. Rules are adopted by timing, change passive triggers, user active way to trigger the database to evaluate the allocation of resources, will assess the results presented to users, at the same time will according to the rules set up to judge whether need to be revised, such as correction tasks, new resources configuration data will be configuration audit (Config) perception into the evaluation of the next cycle. Let’s take A look at how the operation and maintenance students of Company A complete their tasks through configurable audit (Config).
Set up rules
Open the configuration audit console, enter the rule list, and click “New Rule” to see a large number of hosting rules provided by configuration audit (Config) for users (hosting rules are developed by the platform and provided to users). This rule can be searched by searching “Anti-hotlinking” or “Referer” : Anti-hotlinking function is enabled in the OSS storage space.
So apply the rule,
Step 1: Set the rule name, customized risk level, and customized remarks information;
Step 2: You can limit the scope of resources to be checked according to the actual business scenario; The options include resource ID, resource group ID, region, label, etc.
Step 3: Set the permitted whitelist of the referer and whether the referer is allowed to be null;
Step 4: Set whether auto repair is enabled or not. We’ll skip it for now and discuss it later. Step 5: Preview and submit
Rule evaluation
After the rule is created, the rule starts to evaluate the compliance of the Bucket configuration in stock. Refer to the evaluation instructions of the rule, “If the anti-hotlinking function of OSS storage space is enabled, it is deemed to be in compliance”. This rule checks if it is compliant to enable anti-hotlinking by checking the RefererList in the Bucket configuration information. The Referer is not empty.
An evaluation result will be generated after the completion of rule evaluation, with the number of cumulative evaluation resources, compliance resources and non-compliance resources marked; You can configure it manually based on the results of this check. Note: Additional OSS buckets are also automatically checked for compliance.
The following figure shows the test results: a total of 23 OSS buckets were tested, and 23 were non-compliant, indicating that none of the 23 OSS buckets had enabled hotlinking prevention function.
How to repair
If the number of buckets is high, heavy manual configuration may lead to operational errors. Don’t worry, configuration auditing (CONFIG) provides the ability to fix non-compliant resources assessed by rules in conjunction with OOS. You can modify the details in the rule details page ->, and then click “Modify configuration” to complete the modified configuration.
Note that there is an option for “Auto Correction/Manual Correction”, we have checked “Manual Correction” for the time being.
At this time, the “Perform Manual Correction” button will appear in the Correction Details TAB. Click this button to manually trigger the repair task for non-compliant resources.
Since the repair task is asynchronous, you can directly go to the object store console -> bucket -> permission management -> anti hotlinking to check whether the fix is successful, or you can wait a little time (about 10 minutes) to configure audit (CONFIG) console to check the latest configuration information.
As shown in the figure above, the repair action has been completed and the OSS Bucket anti-hotlinking has been set normally. Go back to the configuration audit console and wait for a while. The resource change data triggered by the repair will flow back to the configuration audit (CONFIG) trigger rule for another evaluation.
Continue to evaluate and repair
How do you ensure that other operations personnel do not change this configuration in the future? The internal workings of the organization can barely get the job done, but people will always make mistakes. We can leverage the continuous detection and repair capabilities of configuration auditing (CONFIG). In the previous configuration repair setting, change the “Manual Execution” to “Automatic Execution”. Once the resource has been changed unreasonably, the configuration audit (CONFIG) will identify and automatically correct it to the correct configuration to prevent abnormal modification.
For example, if we change the configuration rule for an OSS Bucket in the OSS console to:Changed to alibaba.com.alibaba-inc.com
Wait a few minutes, we will find:
Here are the OSS buckets with the wrong anti-hotlinking list that we just set. At this time, the automatic correction has been triggered. The reason why there is still one shown as non-compliance is that the configuration audit (CONFIG) needs to wait for the correct set after correction to reach the centralized database before the rule evaluation can be carried out again. Assess non-compliance resources into compliance status.
! [image.png](/imgyuanyyyy
Let’s go back to the OSS Bucket console again to see if the latest resource configuration is in effect.
The configuration has been reset back to.alibaba.aliyun.com.
conclusion
The above is the entire content of using configuration audit (CONFIG) to detect non-compliant configuration and continue automatic repair. We complete the process from problem discovery and resource location to manual and automatic change and allocation through setting rules, rule evaluation and repair, forming a closed loop of problem in configuration audit (CONFIG). The original link
This article is the original content of Aliyun, shall not be reproduced without permission.