Restrict image export, image sharing, and snapshot sharing permissions to prevent accidental data breaches.
Security risk
Image sharing and export features improve efficiency for developers and deployments. However, these features also introduce data security challenges. Improper permission settings or careless image creation can lead to the intentional or unintentional leakage of core code, environment configuration, and sensitive data. For example, an employee might use export permissions to copy a production server image and obtain sensitive information. Additionally, if you do not thoroughly clean up test data, configuration files, or temporary credentials when you create an image, this information can be exposed accidentally when the image is used or shared. This poses the following security risks:
Static data snapshots: Images and snapshots capture the complete state of an Elastic Compute Service (ECS) instance at a specific point in time. This includes not only the operating system and application files but also various types of sensitive data, such as:
Identity credentials: Secure Shell Protocol (SSH) private keys, API AccessKeys, database connection strings, and hard-coded application passwords.
User data: Company core code, database information, and private user data.
System traces: Shell command history (.bash_history), temporary files, and logs and caches from various applications.
Risk of permission divergence: Sharing and exporting operations extend data access permissions from a controlled internal environment to a broader, sometimes uncontrollable, scope. If an image containing sensitive information is shared with the wrong account or exported to an offline environment, the data can be misused or exploited by malicious actors.
Best practices
Image creation
Before you create an image, log on to the instance and check for sensitive information. If an image contains logon information, such as SSH keys, this information is written to new instances created from the image. This occurs even if you choose to attach a new key pair or use a password to log on when you create the instance. This means the original key pairs and passwords from the image can still be used to access the new instance.
Clean up user password information:
Linux: Check and remove unnecessary user information from /etc/shadow and /etc/passwd.
Windows: Run the System Preparation (Sysprep) tool to generalize the image. This operation resets the computer system ID (SID), clears current user information, and requires you to create a new account or reset the administrator password during the next startup. Also, manually delete all unnecessary local accounts in Local Users and Groups (lusrmgr.msc).
Delete all SSH keys:
Linux: Delete key files (especially id_rsa and authorized_keys) from /root/.ssh and all user home directories (/home/*/.ssh).
Windows: Delete key files from C:\Users\Administrator\.ssh and all user home directories (C:\Users\*\\.ssh). Also, check and clear all cached credentials in Credential Manager.
Clear Shell history:
Linux: Run history -c and delete the .bash_history file from /root/.bash_history and all user home directories (/home/*/.bash_history).
Windows: Run Clear-History to clear the current PowerShell session history. Then, delete the PowerShell history file for all users. This file is typically located at AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt.
Clean up temporary files and logs:
Linux: Clear the /tmp and /var/tmp directories. Review and clean up the logs in the /var/log directory.
Windows: Run the Disk Cleanup tool (cleanmgr.exe) to clear system temporary files, the recycle bin, and other items. Also, use the wevtutil cl <LogName> command (for example, wevtutil cl System) or Event Viewer to manually clear all major Windows Event logs, such as application, security, and system logs.
Remove hard-coded credentials: Check application code and configuration files to ensure they do not contain hard-coded sensitive information, such as database passwords or API keys.
Clean up business data and application caches: Clear business data and cache directories from applications such as web servers and databases.
Compliance capabilities
Block: Prohibit image exports and the sharing of images and snapshots
For Resource Access Management (RAM) users or user groups with low trust levels, explicitly prohibit them from performing high-risk operations on core image assets. Use a Deny policy to enforce this restriction and block them from sharing and exporting images. At the organization or account level, you can use a RAM policy to block the export of images and the sharing of images and snapshots.
For enterprise users:
Log on to the Resource Directory console with your Alibaba Cloud account, click Control Policy in the menu bar on the left, create a custom policy, and paste the following JSON content.
This policy denies the export of images and the sharing of images and snapshots.
{ "Version": "1", "Statement": [ { "Action": [ "ecs:ExportImage", "ecs:ModifyImageSharePermission" ], "Resource": "*", "Effect": "Deny" }, { "Action": [ "resourcesharing:CreateResourceShare", "resourcesharing:AssociateResourceShare" ], "Resource": "*", "Condition": { "StringEquals": { "resourcesharing:RequestedResourceType": [ "Snapshot", "Image" ] } }, "Effect": "Deny" } ] }In Resource Directory, select an appropriate node and attach the policy. The policy then blocks the specified operations for all accounts under that node.
For non-enterprise users:
Log on to the RAM console with your Alibaba Cloud account. In the navigation pane on the left, click Policies. Create a custom policy with the same content as shown above.
Attach the access policy to a RAM user, RAM user group, or RAM role. For more information, see Manage access policy authorization.