SSM Policy for Instances Assumed to Be Compromised
If I wanted to apply a very limited custom SSM policy to instances that were assumed to be compromised, what could I remove from the AmazonSSMManagedInstanceCore managed policy? The basic need is to be able to patch the instance, run commands, change a configuration (e.g. local config file), and initiate a remote session.
- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
In order to patch instances, run commands, change a configuration and initiate a remote session, you would need to retain the following permissions from the AmazonSSMManagedInstanceCore policy:
- ssm:DescribeAssociation
- ssm:GetDeployablePatchSnapshotForInstance
- ssm:GetDocument
- ssm:DescribeDocument
- ssm:GetManifest
- ssm:GetParameter
- ssm:GetParameters
- ssm:ListAssociations
- ssm:PutInventory
- ssm:PutComplianceItems
- ssm:PutConfigurePackageResult
- ssm:UpdateAssociationStatus
- ssm:UpdateInstanceAssociationStatus
- ssm:UpdateInstanceInformation
- ssmmessages:CreateControlChannel
- ssmmessages:CreateDataChannel
- ssmmessages:OpenControlChannel
- ssmmessages:OpenDataChannel
- ec2messages:AcknowledgeMessage
- ec2messages:DeleteMessage
- ec2messages:FailMessage
- ec2messages:GetEndpoint
- ec2messages:GetMessages
- ec2messages:SendReply
You could remove permissions that grant broader access to other SSM resources or functionalities that are not needed in a compromised instance situation. For example, you could probably remove permissions like ssm:ListInstanceAssociations or ssm:ListComplianceItems.
Relevanter Inhalt
AWS OFFICIALAktualisiert vor einem Jahr- AWS OFFICIALAktualisiert vor 10 Monaten