Periodically review public and cross-account access
To maintain business flexibility, enterprises often grant external access to their cloud resources. For example, a supplier might need to access cloud resources within an enterprise account. Improperly configured external access creates significant security risks for enterprise assets and data. For instance, an unintentionally public OSS bucket can lead to a data breach. Therefore, it is important to periodically review external access, including public and cross-account access. This practice helps you promptly identify such access, determine its appropriateness, and remove unnecessary external access permissions.
Priority
Low
Not recommended
Enabling public-read-write or public-read access for an OSS bucket. This increases the risk of an enterprise data breach.
Granting a temporary RAM role to an external account. For example, an external software supplier for your enterprise might need to assume a RAM role to access cloud resources and complete a software deployment. If the role is not promptly removed after use, it remains exposed to the external account for an extended period.
Failing to periodically review public and cross-account access. This prevents you from promptly detecting and removing improper external access, which can lead to security risks.
Implementation guide
Public and cross-account access is typically granted in the following ways:
Enabling public access. For example, setting an OSS bucket to public-read-write or public-read.
Using resource-based authorization to allow anonymous or cross-account access. For example, using a bucket policy.
Allowing other accounts to assume one of your RAM roles for cross-account access. For more information, see Access resources across Alibaba Cloud accounts.
Alibaba Cloud provides the access analytics feature to help you quickly detect external access. You can also use EventBridge to quickly configure alerting. For detailed steps on how to audit and converge access, see Detect and converge external access using access analytics.
Use access analytics to periodically review public and cross-account access. When you create an external access analyzer, you can select one of the following two analysis scopes. The analysis scope is the analyzer's trust zone. The analyzer monitors supported resources within the trust zone and considers access to these resources by identities within the zone to be trusted.
Resource directory: Identities from all accounts within the current account's resource directory are considered trusted. Identities from accounts outside the resource directory are considered untrusted.
Current account: Identities within the current account are considered trusted. Identities from other accounts are considered untrusted.
If your enterprise uses multiple Alibaba Cloud accounts, you can use the Set up a landing zone feature in Cloud Governance Center. This feature provides a comprehensive solution for building a multi-account architecture for your enterprise in a resource directory. This lets you analyze access at the resource directory level, review your entire multi-account organization, and promptly detect cross-account access from outside your organization.
Configure monitoring and alerting. Use EventBridge to send analysis results from access analytics to your operations and maintenance (O&M) team through channels such as email. This lets you immediately detect unexpected external access and reduce enterprise security risks.
Pay special attention to public access for OSS buckets to prevent sensitive data leakage.
If you find that an OSS bucket is publicly accessible, promptly evaluate whether the access is appropriate. For unexpected public access, you can quickly block it using the Block Public Access feature. If static resources in your OSS bucket, such as images, videos, and documents, need to be public, use CDN for distribution. CDN supports origin fetch from private OSS buckets. You do not need to make the OSS bucket public. This practice can reduce traffic costs and improve resource loading speed.
If you use a resource directory to build a multi-account architecture, you can use a control policy to prevent OSS buckets from being set to public. The following code provides a sample policy:
{ "Version": "1", "Statement": [ { "Effect": "Deny", "Action": [ "oss:PutObject", "oss:PutObjectAcl" ], "Resource": "*", "Condition": { "StringEquals": { "oss:x-oss-object-acl": [ "public-read", "public-read-write" ] } } }, { "Effect": "Deny", "Action": "oss:PutBucket", "Resource": "*", "Condition": { "StringEquals": { "oss:x-oss-acl": [ "public-read", "public-read-write" ] } } } ] }