《DataDog:2023年云安全现状报告(英文版)(19页).pdf》由会员分享,可在线阅读,更多相关《DataDog:2023年云安全现状报告(英文版)(19页).pdf(19页珍藏版)》请在三个皮匠报告上搜索。
1、research/security/cloud security/aws/google cloud/azure/security research/threat detectionSecurely conguring the potentially thousands of cloud identities,workloads,and other resources neededto support the high pace of modern software development is dicultbut also critical to prevent attackersfrom b
2、reaching these systems,where security gaps too often go unnoticed.For this report,we analyzed security posture data from a sample of thousands of organizations that useAWS,Azure,or Google Cloud.In particular,we focused on understanding how organizations approach andmitigate common risks that frequen
3、tly lead to documented public cloud security incidents.(A detailedmethodology is available in the annex.)Our ndings suggest that,while some elements of strong cloudsecurity posture show signs of improvement,organizations still face signicant challenges.These includemanaging static,long-lived credent
4、ials;securely conguring user roles,access,and privileges within cloudresources;and enforcing best-practice safeguards such as multi-factor authentication(MFA).FACT Long-lived credentials continue to be a riskLong-lived credentialsi.e.,those that are static and do not expireare well-known as a major
5、cause ofcloud security breaches,and they continue to be a widespread issue in cloud environments.These types ofcredentials are widely regarded as insecure,not only because they never expire but also because they caneasily be leaked in source code,container images,or conguration les.Indeed,leaks of l
6、ong-livedcredentials are one of the most common causes for security breaches in the cloud.Despite common knowledge of this attack vector,we identied that organizations still have room to improvein replacing long-lived credentials with more secure solutions that use centralized identity management an
7、dshort-lived credentials.We analyzed usage of long-lived credentials across AWS,Azure,and Google Cloudand found common trends across accounts in all three platforms.In AWS,percent of IAM users haveactive access keys.In Azure AD,percent of applications have active credentials,while percent ofGoogle C
8、loud service accounts have active access keys.The lower number for Google Cloud is likely due tothe presence of service accounts created and managed by Google,which developers typically do not use forother purposes.Across AWS,Azure,and Google Cloud,roughly half of access keys are more than year old,
9、and more thanone in are older than years old.This demonstrates that access keys tend to live for longer than theyshould.TWEETSHAREFor AWS,we were able to compare these gures with historical data that we compiled for our report.Since that time,the situation with AWS credentials has unfortunately not
10、improved.Many of the percentof IAM users that have access keysup from percent from one year agodo not actively use them.Among these users:Nearly half(percent)have an access key that has not been used in the past days,up from percent a year ago.One in three have active credentials that are older than
11、 year and have not been used in the past days,up from percent a year ago.TWEETSHAREIts generally recommended to avoid long-lived credentials,both for humans and workloads,and instead touse identity federation and platform authentication.For AWS,this means using IAM Identity Center(formerly AWS SSO)f
12、ederated with a central identity provider and avoiding IAM users.On Google Cloud,service accounts should not have access keys,and organizations should instead use secure authenticationmechanisms that create time-bound credentials,such as service account impersonation,instance roles,orworkload identi
13、ty.In Azure,organizations should avoid the use of Azure AD application credentials whenpossible and instead opt for managed identities and workload identity.“Long-lived credentials can be avoided in almost all use cases in the cloud in?.Its great to seecloud providers make federation available in a
14、growing number of scenarios.Additionally,one ofthe biggest benefits of temporary credentials is support for rich attribution.Actions performed inthe cloud can be attributed to specific runs of CI jobs or instances of an auto-scaled application.This can be invaluable for troubleshooting,not just secu
15、rity.Their time-limited nature also makesattribution of compromise easierone needs only query several hours of logs,rather thanpotentially months or years.”Aidan SteeleSenior Engineer and AWS Serverless HeroFACT MFA for cloud access is not suciently enforcedUnlike on-premise environments,cloud provi
16、ders administrative interfaces are APIs that are,by design,exposed to the internet.This is why,in the cloud,identity is the new perimeterand securing identities isof paramount importance.Using and enforcing MFA is one of the most basic and eective steps in thateort.Data from both Microsoft and Googl
17、e indicates that usage of MFA can prevent the vast majority ofaccount takeovers.MFA can be enforced at the account or tenant level,and organizations should considerits useparticularly phishing-resistant methods such as FIDO security keysas an essential part of ahealthy cloud security posture.In our
18、research,we analyzed MFA usage in AWS and Azure ADreliably reporting on MFA usage in GoogleCloud is not feasible at this time due to some limitations of Google Workspace Audit logs(e.g.,logins usingpasskeys do not appear as MFA events).For each organization,we analyzed the percentage of its users th
19、athad successfully authenticated without MFA in October.In AWS,we identied that nearly a third(percent)of IAM users with console access have no MFAenforced,aecting two out of ve organizations.We also found that percent of AWS organizations hadone or more IAM users authenticate to the AWS console wit
20、hout using MFA,and only percent of Azureorganizations had all Azure AD users authenticate with MFA.TWEETSHAREThese ndings illustrate that,while industry statistics suggest MFA adoption is increasing,a substantialportion of organizations are not proactively enforcing it,leaving them at increased risk
21、 of credential theft orpassword-stung attacks.In AWS,its recommended to avoid using IAM users and instead rely on a third-party identity provider thatallows MFA to be enforced.If you do use IAM users in AWS,you can enforce MFA through the use of theaws:MultiFactorAuthPresent condition key.In Azure A
22、D,MFA should typically be made mandatory by usinga conditional access policy and ensuring that legacy authentication is disabled.In Google Workspace,MFAcan be enforced at the organization or organization unit level.FACT In AWS,IMDSv is still widely unenforced,butadoption is risingIn AWS,enforcing th
23、e Instance Metadata Service V(IMDSv)is critical to protect against server-siderequest forgery(SSRF)attacks,one of the most common ways attackers steal and abuse cloud credentials.IMDSv enforces the presence of additional HTTP headers,making it much harder for attackers to stealcredentials from an EC
24、 instance.Although IMDSv was released in,our study shows that,at the time,only percent of ECinstances were enforcing the usage of IMDSv.Today,percent of EC instances enforce IMDSv.Organizations enforce IMDSv on percent of their EC instances on average,up from percent inSeptember.Although current ado
25、ption is still insucient,were glad that organizations are starting toincrease enforcement of IMDSv.TWEETSHAREHowever,enforcement varies based on age of deployment.Just percent of EC instances older than oneyear enforce IMDSv,compared to percent of instances launched in the past several weeks.Thisrei
26、nforces that organizations are increasingly aware of IMDSv,and that shorter-lived EC instances that aredesigned to be easily taken down or re-deployed benet more from recent security improvements.When an instance is insecurely congured and does not enforce IMDSv,its still possible to use italthough
27、an attacker would likely opt to use the insecure IMDSv.We identied that nearly three out of fourEC instances(percent)had only used IMDSv over the-day period between October and October,showing the disconnect between whats enforced and whats actually used.In fact,this means that thevast majority of E
28、C instances could enforce IMDSv without any functional impact or disruption.Itsrecommended to enforce IMDSv on all your EC instances.(See also AWS own guide.)TWEETSHAREYou can enforce IMDSv on your instances through the use of service control policies(SCPs).AWS has alsorecently released a setting at
29、 the Amazon Machine Instance(AMI)level that enforces IMDSv by default forall EC instances launched from that AMI.Finally,the AWS documentation features a dedicated guide abouttransitioning to IMDSv.“Seeing improvement in IMDSv?enforcement in?likely shows that the most impactful changehas been AWS im
30、plementing more secure defaults within its AMIs and Compute services.Manycompanies are also recognizing the critical importance of enforcing IMDSv?usage on the internetedges of their environments.However,there is a long road ahead,as SSRF and proxy attacks arestill largely obscure concepts unknown t
31、o many builders in the cloud.Cloud providers are startingto provide more detailed warnings and click-through advisory notices when permitting less secureoptions in some services.Compute services and,in particular,IMDS are worthy of such warnings.Additionally,feedback and pressure should continue to
32、be placed on commercial products that donot support IMDSv?.”Houston HopkinsSenior Security Engineering Manager,Cloud Security at RobinhoodFACT Adoption of public access blocks in cloud storageservices is increasingPublic storage buckets are now a well-understood source of data leakage in cloud envir
33、onments.Attackersstealing sensitive data from cloud storage have been documented countless times,including in.Thesebreaches are often due to the complexity of securely conguring storage buckets,and although buckets areprivate by default,there are many mechanisms by which they can inadvertently be ma
34、de publicly available.In addition,some storage buckets were created a long time agofor instance,Amazon S was publiclyreleased in,more than years agobefore some modern safeguards were commonplace.Today,cloud providers implement mechanisms to proactively block public access to cloud storage,even onmis
35、congured buckets,and prevent buckets from becoming publicly available by mistake.These allowpractitioners to secure a whole AWS account,Azure storage account,or Google Cloud project at once andensure that human error doesnt turn into a data breach.(Note that we did not include Google CloudStorage in
36、 our analysis,because public access in Google Cloud is typically blocked at the project,folder,ororganization level through an organization policy constraint.)On AWS,we identied that nearly three-quarters(percent)of S buckets are covered by a public Saccess block,either at the bucket or account leve
37、l,up from half(percent)in October.This showsthat organizations are increasingly aware of this mechanism,introduced in.TWEETSHAREOn Azure,two out of ve blob storage containers(percent)are in a storage account that proactivelyblocks public access,making sure that any dangerously congured blob storage
38、it contains is not eectivelymade public.Overall,a small portion(.percent)of Amazon S buckets are public(i.e.,they have a public bucket policyand are not covered by a public access block at the account or bucket level).Similarly,a small number ofAzure storage blob containers(percent)are publicly acce
39、ssible and in a storage account not blockingpublic access.While these buckets dont necessarily contain sensitive data,they could inadvertentlybecome repositories for sensitive information in the future.TWEETSHAREWe believe that more organizations proactively block S public access due to wider awaren
40、ess of thispractice,the high number of documented security breaches related to public access,and because AWSintroduced the S public access block in.Microsoft also released the equivalent Azure feature in.In addition,since April,AWS has been blocking public access by default on all buckets,which is n
41、otthe case for Azurealthough its also planned in the near future.Organizations should continue to audit theconguration of their storage buckets and ensure public access blocks are enforced,except in specic usecases where public access is warranted or necessary.In many such cases,leveraging a content
42、 distributionnetwork(CDN)service such as Amazon CloudFront or Azure CDN is more performant,cost-eective,andsecure than exposing buckets directly.FACT A substantial portion of cloud workloads areexcessively privilegedIn cloud environments,conguring permissions can be a tedious task that often leads t
43、o workloads havingmore privileges than needed.Often,a seemingly innocuous set of permissions could allow an attacker toescalate their privileges.While full administrator access is relatively simple to identify,shadowadministrator permissionswhich allow an identity to indirectly escalate their privil
44、eges and accesssensitive dataare typically harder to spot.In AWS,only a small number(.percent)of Amazon EC instances have full administrator privileges.Anattacker compromising such an instancefor example,by exploiting a web application that runs on itwould be able to obtain the credentials made avai
45、lable via the instance metadata service and therebyaccess sensitive data in the account.But this gure doesnt tell the full story.An attacker does not need full administrator privileges to have asubstantial impactthere are other,more common and challenging-to-uncover types of permissions theycan leve
46、rage.We found that:.percent of EC instances have risky permissions that allow lateral movement in the account,such asconnecting to other instances using SSM Sessions Manager.percent allow an attacker to gain full administrative access to the account by privilege escalation,such as permissions to cre
47、ate a new IAM user with administrator privileges.percent have excessive data access,such as listing and accessing data from all S buckets in theaccount.(Note that these conditions are not mutually exclusivea specic instance can fall into several of thesecategories.)Overall,nearly one in four EC inst
48、ances(percent)have administrator or highly sensitive permissions tothe AWS account they run in.TWEETSHAREOn Google Cloud,percent of virtual machines(VMs)have privileged editor permissions on the projectthey run in,through the use of the default compute service account with the unrestricted cloud-pla
49、tformscope.In addition,percent have full read access to Google Cloud Storage(GCS)buckets and BigQuerydatasets through the same mechanismso in total,more than one in three Google Cloud VMs(percent)have sensitive permissions to a project.TWEETSHAREOrganizations using Google Cloud should enable the Dis
50、able automatic IAM grants for default serviceaccounts organization policy and ensure that virtual machines use a non-default service account.Managing IAM permissions of cloud workloads is not an easy task.Administrator access is not the only riskto monitorits critical to also be wary of sensitive pe
51、rmissions that allow a user to access sensitive data orescalate privileges.Because cloud workloads are a common entry point for attackers,its critical to ensurepermissions on these resources are as limited as possible.“Insecure default configurations from cloud providers optimize for the ease of ini
52、tial adoption,butthey are often at odds with the level of hardening required for most production deployments.Initial configurations such as over-privileged IAM roles and permissive firewall rules tend to haveinertiaonce deployed and working,they are more challenging to lock down after the fact.There
53、fore,the discipline of hardening the security of initial configurations early in the deploymentlifecycle is a key virtue of a mature cloud-native organizations culture.”Brad GeesamanStaff Security Engineering,Ghost SecurityFACT Many virtual machines remain publicly exposed tothe internetExposing vir
54、tual machines(VMs)to the public internet is a signicant risk in cloud environments.Attackersfrequently target exposed services by running brute-force attacks or exploiting known protocol-levelvulnerabilities such as BlueKeep,which the US Cybersecurity and Infrastructure Security Agency(CISA)stillrep
55、orts as one of the most commonly exploited vulnerabilities of.We identied that percent of EC instances,percent of Azure VMs,and percent of Google Cloud VMsare publicly exposed to the interneti.e.,they have at least one port allowing trac from the internet.Among instances that are publicly exposed,HT
56、TP and HTTPS are the most commonly exposed ports,andare not considered risky in general.After these,SSH and RDP remote access protocols are common.Themost commonly exposed database technologies are MongoDB,Redis,MSSQL,and Elasticsearch.TWEETSHAREWe hypothesize that the higher public exposure and str
57、ong prevalence of open SSH and RDP ports in GoogleCloud is due to the fact that default pre-populated rewall rules in the default network allow SSH and RDPfrom the internet.While developers can disable provisioning of this network for new projects through theskip default network creation organizatio
58、n policy constraint,it does not apply to existing projects.TheSecure your cloud infrastructure with Datadog.LEARN MOREMethodologyFindings are based on data collected between September and October.PopulationFor this report,we analyzed the cloud security posture of a sample of thousands of organizatio
59、ns.Data inthis report has come from customers of Datadog Cloud Security Management(CSM)and is likely skewedtoward the positive as a result of these organizations increased maturity.Fact resulting dierences in percentage of internet-exposed VMs show once again the practical impact thatinsecure defaul
60、ts can have on organizations security posture.Across all cloud platforms,organizations should avoid exposing VMs to the public internet and instead useIAM-based secure access mechanisms such as AWS SSM Sessions Manager,Amazon EC Instance Connect,Google Cloud Identity-Aware Proxy(IAP),Google Cloud OS
61、 Login,or Azure Bastion.This especially applies todatabase systems running on VMs,since databases typically contain sensitive data and are straightforwardfor attackers to discoverfor instance,through passive network scanning search engines like Shodan orCensys.Databases should be kept on internal ne
62、tworks and accessed through one of the mechanismspreviously mentioned.ConclusionOur ndings reect ongoing improvements in security posture across cloud environments in AWS,GoogleCloud,and Azure.We believe this is due to the cloud providers working to deliver more secure defaults ontheir platforms,as
63、well as adoption of solutions that scan for insecure congurationsnot to mentiongreater awareness around cloud security risks in general.That said,improving and maintaining cloud security posture is an ongoing processin complexenvironments with accelerated software development life cycles,its not alw
64、ays easy to identify and xissues such as long-lived credentials,lagging MFA adoption,IMDSv enforcement,or excessive privileges.Continuously scanning for miscongurations and quickly remediating these issues when they are discoveredremain the best strategies for strengthening cloud security,so breache
65、s can be avoided and developers cancontinue shipping software at speed and scale.For AWS,we considered IAM users that have at least one active access key.When an IAM user had severalactive access keys,we considered only the oldest one.For Google Cloud,we considered service accounts that are not disa
66、bled and have at least one active accesskey.We excluded from our analysis Google-managed service accounts for which its not possible to createuser-managed access keys.For Azure AD,we considered Azure AD app registrations that had active“password”credentials(corresponding to static access keys that c
67、an be exchanged for OAuth.access tokens).Fact For AWS,we considered IAM users that have a“console prole”enabled and no MFA device attached.Forhistorical console authentication events in AWS,we analyzed days of CloudTrail logs and queried ConsoleLogin events whose outcome was successful.We excluded S
68、AML federated authentications.Wedetermined that an authentication event was using MFA if the additionalEventData.MFAUsed was set to Yes,in accordance with the AWS documentation.For Azure AD,we analyzed days of Azure AD sign-in logs and queried successful authentication eventsonly.We then considered
69、that an attempt had used MFA if one of the following was true:The properties.authenticationRequirement eld was set to multiFactorAuthentication(this wouldbe explicit use of MFA).If the eld properties.authenticationDetails.authenticationStepResultDetail was any of the valuesbelow,meaning that the eve
70、nt corresponds to a re-authentication event that previously required pleted in the cloudhas expired due to the policies configured on tenantregistration promptedsatisfied by claim in the token satisfied by claim provided by external providersatisfied by strong authenticationskipped as flow exercised
71、 was windows broker logon flowskipped due to location skipped due to registered deviceskipped due to remembered devicesuccessfully completedFact In the graph that depicts average enforcement of IMDSv,we computed for each organization thepercentage of its EC instances where IMDSv is enforced and aver
72、aged this number across allorganizations.We used this method so as not to overrepresent organizations that have a large number ofEC instances and instead to measure adoption trends.For historical data,we queried days of CloudTrail logs and used the eld userIdentity.sessionContext.ec2RoleDelivery to
73、determine if IMDSv had been used to request initial session credentials.We onlyanalyzed CloudTrail generated by EC instances,meaning where userIdentity.session_name starts with i-.Fact For AWS,we considered an S bucket public if both of the following were true:The bucket policy allows s3:GetObject o
74、n all objects in the bucket to a wildcard principal.The public access block conguration of neither the bucket nor the AWS account has restrict_public_buckets set to true.We considered that an S bucket is“covered by a public access block”if the bucket public access blockconguration or the AWS account
75、 public access block conguration has the four settings block_public_acls,block_public_policy,ignore_public_acls,and restrict_public_buckets set to true.We excluded from the analysis S buckets that are made public through the static website feature,as this isa valid use case for public S buckets that
76、 is not necessarily covered by CloudFront,and also because itgives a strong signal that the bucket was explicitly meant to be public by design.For Azure,we considered that an Azure blob storage container is publicly accessible if both of the followingwere true:Its PublicAccess eld was set to blob or
77、 container.The storage account it resides in does not block public accessi.e.,its allowBlobPublicAccessattribute is not set to false.Fact For AWS,we considered that an EC instance has an administrative role if it has an instance role thatsattached to either the AdministratorAccess AWS-managed policy
78、,or to a custom policy that has at leastone statement allowing all actions on all resources,with no conditions.We considered that an EC instance has“excessive data access”if one of the following conditions was true:Its instance role has any of the following combinations of permissions on the resourc
79、e*,through aninline or attached policy.s3:listallmybuckets,s3:listbucket,s3:getobjectdynamodb:listtables,dynamodb:scandynamodb:listtables,dynamodb:exporttabletopointintimeec2:describesnapshots,ec2:modifysnapshotattributeec2:describesnapshots,ebs:listsnapshotblocks,ebs:listchangedblocks,ebs:getsnapsh
80、otblockrds:describedbclustersnapshots,rds:modifydbclustersnapshotattributerds:describedbsnapshots,rds:modifydbsnapshotattributesecretsmanager:listsecrets,secretsmanager:getsecretvaluessm:describeparameters,ssm:getparameterssm:describeparameters,ssm:getparameterssecretsmanager:getparametersbypath Its
81、 instance role is attached to one of the following AWS managed policies(which all meet the criteriaabove).AdministratorAccessAdministratorAccess-AmplifyAmazonApplicationWizardFullaccessAmazonDataZoneProjectRolePermissionsBoundaryAmazonDocDBConsoleFullAccessAmazonDocDBElasticFullAccessAmazonDocDBFull
82、AccessAmazonDynamoDBFullAccessAmazonDynamoDBFullAccesswithDataPipelineAmazonDynamoDBReadOnlyAccessAmazonEC2FullAccessAmazonEC2RoleforDataPipelineRoleAmazonElasticMapReduceforEC2RoleAmazonElasticMapReduceFullAccessAmazonElasticMapReduceReadOnlyAccessAmazonElasticMapReduceRoleAmazonGrafanaRedshiftAcce
83、ssAmazonLaunchWizard_FullaccessAmazonLaunchWizardFullaccessAmazonLaunchWizardFullAccessV2AmazonMacieServiceRoleAmazonMacieServiceRolePolicyAmazonRDSFullAccessAmazonRedshiftFullAccessAmazonS3FullAccessAmazonS3ReadOnlyAccessAmazonSageMakerFullAccessAmazonSSMAutomationRoleAmazonSSMFullAccessAmazonSSMRe
84、adOnlyAccessAWSBackupServiceRolePolicyForBackupAWSCloudTrailFullAccessAWSCodePipelineReadOnlyAccessAWSCodeStarServiceRoleAWSConfigRoleAWSDataExchangeFullAccessAWSDataExchangeProviderFullAccessAWSDataLifecycleManagerServiceRoleAWSDataPipelineRoleAWSElasticBeanstalkCustomPlatformforEC2RoleAWSElasticBe
85、anstalkFullAccessAWSElasticBeanstalkReadOnlyAccessAWSIoTDeviceTesterForFreeRTOSFullAccessAWSLambdaFullAccessAWSLambdaReadOnlyAccessAWSMarketplaceSellerFullAccessAWSMarketplaceSellerProductsFullAccessAWSOpsWorksRoleDatabaseAdministratorDataScientistNeptuneConsoleFullAccessNeptuneFullAccessReadOnlyAcc
86、essSecretsManagerReadWriteServerMigrationServiceRoleSystemAdministratorVMImportExportRoleForAWSConnectorWe considered that an EC instance has“permissions allowing privilege escalation”if one of the followingconditions was true:Its instance role has any of the following combinations of permissions on
87、 the resource*,through aninline or attached policy.iam:createaccesskeyiam:createloginprofileiam:updateloginprofileiam:updateassumerolepolicyiam:createpolicyversioniam:attachrolepolicyiam:putrolepolicyiam:createuser,iam:putuserpolicy,iam:createaccesskeyiam:createuser,iam:putuserpolicy,iam:createlogin
88、profileiam:createuser,iam:addusertogroup,iam:createaccesskeyiam:createuser,iam:addusertogroup,iam:createloginprofileiam:createuser,iam:attachuserpolicy,iam:createaccesskeyiam:createuser,iam:attachuserpolicy,iam:createloginprofileiam:passrole,lambda:createfunction,lambda:addpermissioniam:passrole,cod
89、estar:createprojectiam:passrole,datapipeline:createpipelineiam:passrole,cloudformation:createstackiam:passrole,lambda:createfunction,lambda:createeventsourcemappingiam:passrole,lambda:createfunction,lambda:invokefunctioniam:passrole,ec2:runinstances Its instance role is attached to one of the follow
90、ing AWS managed policies(which all meet the criteriaabove):AdministratorAccessAdministratorAccess-AmplifyAmazonDynamoDBFullAccessAmazonDynamoDBFullAccesswithDataPipelineAmazonEC2ContainerServiceFullAccessAmazonEC2SpotFleetTaggingRoleAmazonECS_FullAccessAmazonElasticMapReduceFullAccessAmazonElasticMa
91、pReduceRoleAutoScalingServiceRolePolicyAWSBatchServiceRoleAWSCodeStarServiceRoleAWSDataPipelineRoleAWSEC2FleetServiceRolePolicyAWSEC2SpotFleetServiceRolePolicyAWSEC2SpotServiceRolePolicyAWSElasticBeanstalkFullAccessAWSElasticBeanstalkManagedUpdatesServiceRolePolicyAWSElasticBeanstalkServiceAWSLambda
92、_FullAccessAWSLambdaFullAccessAWSMarketplaceFullAccessAWSMarketplaceImageBuildFullAccessAWSOpsWorksRegisterCLIAWSServiceRoleForAmazonEKSNodegroupAWSServiceRoleForGammaInternalAmazonEKSNodegroupAWSServiceRoleForSMSDataScientistEC2FleetTimeShiftableServiceRolePolicyIAMFullAccessServerMigrationServiceL
93、aunchRoleWe considered that an EC instance has“permissions allowing lateral movement”if one of the followingconditions was true:Its instance role has any of the following combinations of permissions on the resource*,through aninline or attached policy.ec2-instance-connect:sendsshpublickeyssm:startse
94、ssionssm:sendcommandec2:getserialconsoleaccessstatus,ec2:describeinstances,ec2:describeinstancetypes,ec2-instance-connect:sendserialconsolesshpublickey Its instance role is attached to one of the following AWS managed policies(which all meet the criteriaabove).AdministratorAccessAmazonApplicationWiz
95、ardFullaccessAmazonLaunchWizardFullaccessAmazonSSMAutomationRoleAmazonSSMFullAccessAmazonSSMMaintenanceWindowRoleAmazonSSMServiceRolePolicyAWSOpsWorksCMServiceRoleEC2InstanceConnectWhen computing eective permissions of an IAM role,SCPs and permissions boundaries were not taken intoaccount.For Google
96、 Cloud,we considered that:a VM has administrator privileges on the project when the default compute service account is used withthe cloud-platform scope.a VM has read access to the projects cloud storage when the default compute service account is usedwith the devstorage.read_only scope.We excluded
97、VMs in a project where the default compute service account had not been granted editor orowner access.In other words,we did take into account the case where the recommended automaticIamGrantsForDefaultServiceAccounts organization policy is in eect,“neutralizing”the default permissions ofthe default
98、compute service account.Fact For AWS,we considered that a virtual machine is publicly available if all of the following were true:It has a public IP address attached.Its in a public subnet(i.e.,a subnet that has a default route to an internet gateway).It has a security group that allows at least one
99、 port from./that is not blocked by the network ACLattached to the subnet.For Azure,we considered that a virtual machine is publicly available if both of the following were true:It has a network interface with a public IP and a network security group that allows at least one port from./.It has a netw
100、ork interface with a public IP with the deprecated“basic”SKU and no network security groupattached.For Google Cloud,we considered that a virtual machine is publicly available if both of the following weretrue:It has a network interface with a public IP.At least one of the rewall rules that apply to
101、the instance allows at least one port from./,takinginto account deny rules and relative priority.For Google Cloud,we dene“rewall rules that apply to the instance”as:Firewall rules that apply to the whole network where the virtual machine is located Firewall rules that apply to the service account th
102、e virtual machine usesFor all three clouds,we did not take into account port ranges wider than ports.This is because when alarge number of ports are open(e.g.,-,),its not possible to assume the original intent.In the graph showing the distribution of open ports across publicly exposed instances,a specic instancemay have one or multiple open ports and might consequently appear in several categories.We purposely did not include the HTTP and HTTPS ports in the graph,as exposing web applications to theinternet is not generally regarded as a bad practice.TERMSPRIVACYCOOKIES Datadog