{"id":22000,"date":"2023-01-09T01:40:33","date_gmt":"2023-01-08T18:40:33","guid":{"rendered":"https:\/\/renovacloud.com\/?p=22000"},"modified":"2024-12-05T14:02:49","modified_gmt":"2024-12-05T07:02:49","slug":"26-aws-security-best-practices-to-adopt-in-production-part-1","status":"publish","type":"post","link":"https:\/\/renovacloud.com\/en\/26-aws-security-best-practices-to-adopt-in-production-part-1\/","title":{"rendered":"26 AWS Security Best Practices to Adopt In Production &#8211; Part 1"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">One of the most important pillars of a well-architected framework is security. Thus, it is important to follow these AWS security best practices to prevent unnecessary security situations.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">So, you\u2019ve got a problem to solve and turned to AWS to build and host your solution. You create your account and now you\u2019re all set up to brew some coffee and sit down at your workstation to architect, code, build, and deploy. Except, you aren\u2019t!<\/span><\/p>\n<p><span style=\"font-weight: 400;\">There are many things you must set up if you want your solution to be operative, secure, reliable, performant, and cost effective. And, first things first, the best time to do that is now \u2013 right from the beginning, before you start to design and engineering.<\/span><\/p>\n<h2><b>Initial AWS Setup<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Never, ever, use your <\/span><i><span style=\"font-weight: 400;\">root<\/span><\/i><span style=\"font-weight: 400;\"> account for everyday use. Instead, head to Identity and Access Management (IAM) and create an administrator user. Protect and lock your <\/span><i><span style=\"font-weight: 400;\">root<\/span><\/i><span style=\"font-weight: 400;\"> credentials in a secure place (is your password strong enough?) and, if your <\/span><i><span style=\"font-weight: 400;\">root<\/span><\/i><span style=\"font-weight: 400;\"> user has keys generated, now is the best time to delete them.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">You will absolutely want to activate Multi Factor Authentication (MFA) too for your root account. You must end up with a root user with MFA and no access keys. And you won\u2019t use this user unless strictly necessary.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Now, about your newly created admin account, <\/span><a href=\"https:\/\/sysdig.com\/blog\/why-mfa-prevents-attacks\/\" rel=\"noopener\"><span style=\"font-weight: 400;\">activating MFA for it is a must<\/span><\/a><span style=\"font-weight: 400;\">. It\u2019s actually a requirement for every user in your account if you want to have a security first mindset (and you actually want to), but especially so for power users. You will only use this account for administrative purposes.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-21961\" src=\"http:\/\/renovacloud.com\/wp-content\/uploads\/2023\/01\/AWS-security-best-practices-02.png\" alt=\"\" width=\"700\" height=\"385\" \/><\/p>\n<p><span style=\"font-weight: 400;\">For daily use, you need to go to the IAM panel and create users, groups, and roles which can access only the resources to which you explicitly grant permissions.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Now you have:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><i><span style=\"font-weight: 400;\">Root<\/span><\/i><span style=\"font-weight: 400;\"> account (with no keys) securely locked into a safe.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Admin account for administrative use.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Several users, groups, and roles for day to day use.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">All of them should have MFA activated and strong passwords.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">You are almost ready to begin your actual work, but first, a word of caution about the AWS shared responsibility model.<\/span><\/p>\n<h2><b>AWS Shared Responsibility Model<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Security and compliance is a shared responsibility between AWS and the customer. AWS operates, manages, and controls the components from the host operating system and virtualization layer, down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software, as well as the configuration of the AWS provided <\/span><a href=\"https:\/\/sysdig.com\/blog\/aws-security-groups-guide\/\" rel=\"noopener\"><span style=\"font-weight: 400;\">security group<\/span><\/a><span style=\"font-weight: 400;\"> firewall.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-21963\" src=\"http:\/\/renovacloud.com\/wp-content\/uploads\/2023\/01\/AWS-security-best-practices-03.png\" alt=\"\" width=\"700\" height=\"470\" \/><\/p>\n<p><span style=\"font-weight: 400;\">Therefore, the management and application of diligent AWS security is the responsibility of the customer.<\/span><\/p>\n<h2><b>AWS Cloud Security Best Practices Checklist<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">In this section we will walk through the most common AWS services and provide 26 security best practices to adopt.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">AWS Security best practices with open source \u2013 <\/span><a href=\"https:\/\/cloudcustodian.io\/\" rel=\"noopener\"><span style=\"font-weight: 400;\">Cloud Custodian<\/span><\/a><span style=\"font-weight: 400;\"> is a <\/span><a href=\"https:\/\/sysdig.com\/learn-cloud-native\/cloud-security\/cloud-security-posture-management\/\" rel=\"noopener\"><span style=\"font-weight: 400;\">Cloud Security Posture Management<\/span><\/a><span style=\"font-weight: 400;\"> (CSPM) tool. <\/span><a href=\"https:\/\/sysdig.com\/products\/secure\/cspm-cloud-security-posture-management\/\" rel=\"noopener\"><span style=\"font-weight: 400;\">CSPM tools<\/span><\/a><span style=\"font-weight: 400;\"> evaluate your cloud configuration and identify common configuration mistakes. They also monitor cloud logs to detect threats and configuration changes.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Now let\u2019s walk through service by service.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><strong>AWS security best practices by service<\/strong><\/td>\n<td><\/td>\n<td><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td><strong>High Risk \ud83d\udfe5\ud83d\udfe5\ud83d\udfe5<\/strong><\/td>\n<td><strong>Medium Risk \ud83d\udfe8\ud83d\udfe8<\/strong><\/td>\n<td><strong>Low Risk \ud83d\udfe9<\/strong><\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#IAM\" rel=\"noopener\"><span style=\"font-weight: 400;\">AWS IAM<\/span><\/a><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#1\" rel=\"noopener\"><span style=\"font-weight: 400;\">(1)<\/span><\/a><span style=\"font-weight: 400;\"> IAM policies should not allow full \u201c*\u201d administrative privileges<\/span><\/p>\n<p><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#4\" rel=\"noopener\"><span style=\"font-weight: 400;\">(4)<\/span><\/a><span style=\"font-weight: 400;\"> IAM root user access key should not exist<\/span><\/p>\n<p><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#6\" rel=\"noopener\"><span style=\"font-weight: 400;\">(6)<\/span><\/a><span style=\"font-weight: 400;\"> Hardware MFA should be enabled for the root user<\/span><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#3\" rel=\"noopener\"><span style=\"font-weight: 400;\">(3)<\/span><\/a><span style=\"font-weight: 400;\"> IAM users\u2019 access keys should be rotated every 90 days or less<\/span><\/p>\n<p><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#5\" rel=\"noopener\"><span style=\"font-weight: 400;\">(5)<\/span><\/a><span style=\"font-weight: 400;\"> MFA should be enabled for all IAM users that have a console password<\/span><\/p>\n<p><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#7\" rel=\"noopener\"><span style=\"font-weight: 400;\">(7)<\/span><\/a><span style=\"font-weight: 400;\"> Password policies for IAM users should have strong configurations<\/span><\/p>\n<p><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#8\" rel=\"noopener\"><span style=\"font-weight: 400;\">(8)<\/span><\/a><span style=\"font-weight: 400;\"> Unused IAM user credentials should be removed<\/span><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#2\" rel=\"noopener\"><span style=\"font-weight: 400;\">(2)<\/span><\/a><span style=\"font-weight: 400;\"> IAM users should not have IAM policies attached<\/span><\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#s3\" rel=\"noopener\"><span style=\"font-weight: 400;\">Amazon S3<\/span><\/a><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#10\" rel=\"noopener\"><span style=\"font-weight: 400;\">(10)<\/span><\/a><span style=\"font-weight: 400;\"> S3 buckets should have server-side encryption enabled<\/span><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#9\" rel=\"noopener\"><span style=\"font-weight: 400;\">(9)<\/span><\/a><span style=\"font-weight: 400;\"> S3 Block Public Access setting should be enabled<\/span><\/p>\n<p><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#11\" rel=\"noopener\"><span style=\"font-weight: 400;\">(11)<\/span><\/a><span style=\"font-weight: 400;\"> S3 Block Public Access setting should be enabled at the bucket level<\/span><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#cloudtrail\" rel=\"noopener\"><span style=\"font-weight: 400;\">AWS CloudTrail<\/span><\/a><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#12\" rel=\"noopener\"><span style=\"font-weight: 400;\">(12)<\/span><\/a><span style=\"font-weight: 400;\"> CloudTrail should be enabled and configured with at least one multi-Region trail<\/span><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#13\" rel=\"noopener\"><span style=\"font-weight: 400;\">(13)<\/span><\/a><span style=\"font-weight: 400;\"> CloudTrail should have encryption at rest enabled<\/span><\/p>\n<p><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#14\" rel=\"noopener\"><span style=\"font-weight: 400;\">(14)<\/span><\/a><span style=\"font-weight: 400;\"> Ensure CloudTrail log file validation is enabled<\/span><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#config\" rel=\"noopener\"><span style=\"font-weight: 400;\">AWS Config<\/span><\/a><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#15\" rel=\"noopener\"><span style=\"font-weight: 400;\">(15)<\/span><\/a><span style=\"font-weight: 400;\"> AWS Config should be enabled<\/span><\/td>\n<td><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#ec2\" rel=\"noopener\"><span style=\"font-weight: 400;\">Amazon EC2<\/span><\/a><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#16\" rel=\"noopener\"><span style=\"font-weight: 400;\">(16)<\/span><\/a><span style=\"font-weight: 400;\"> Attached EBS volumes should be encrypted at rest<\/span><\/p>\n<p><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#19\" rel=\"noopener\"><span style=\"font-weight: 400;\">(19)<\/span><\/a><span style=\"font-weight: 400;\"> EBS default encryption should be enabled<\/span><\/td>\n<td><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#17\" rel=\"noopener\"><span style=\"font-weight: 400;\">(17)<\/span><\/a><span style=\"font-weight: 400;\"> VPC flow logging should be enabled in all VPCs<\/span><\/p>\n<p><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#18\" rel=\"noopener\"><span style=\"font-weight: 400;\">(18)<\/span><\/a><span style=\"font-weight: 400;\"> The VPC default <\/span><a href=\"https:\/\/sysdig.com\/blog\/aws-security-groups-guide\/\" rel=\"noopener\"><span style=\"font-weight: 400;\">security group<\/span><\/a><span style=\"font-weight: 400;\"> should not allow inbound and outbound traffic<\/span><\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#DMS\" rel=\"noopener\"><span style=\"font-weight: 400;\">AWS DMS<\/span><\/a><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#20\" rel=\"noopener\"><span style=\"font-weight: 400;\">(20)<\/span><\/a><span style=\"font-weight: 400;\"> AWS Database Migration Service replication instances should not be public<\/span><\/td>\n<td><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#ebs\" rel=\"noopener\"><span style=\"font-weight: 400;\">Amazon EBS<\/span><\/a><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#21\" rel=\"noopener\"><span style=\"font-weight: 400;\">(21)<\/span><\/a><span style=\"font-weight: 400;\"> Amazon EBS snapshots should not be public, determined by the ability to be restorable by anyone<\/span><\/td>\n<td><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#opensearch\" rel=\"noopener\"><span style=\"font-weight: 400;\">Amazon OpenSearch Service<\/span><\/a><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#22\" rel=\"noopener\"><span style=\"font-weight: 400;\">(22)<\/span><\/a><span style=\"font-weight: 400;\"> Elasticsearch domains should have encryption at rest enabled<\/span><\/td>\n<td><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#SageMaker\" rel=\"noopener\"><span style=\"font-weight: 400;\">Amazon SageMaker<\/span><\/a><\/td>\n<td><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#23\" rel=\"noopener\"><span style=\"font-weight: 400;\">(23)<\/span><\/a><span style=\"font-weight: 400;\"> SageMaker notebook instances should not have direct internet access<\/span><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#Lambda\" rel=\"noopener\"><span style=\"font-weight: 400;\">AWS Lambda<\/span><\/a><\/td>\n<td><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#24\" rel=\"noopener\"><span style=\"font-weight: 400;\">(24)<\/span><\/a><span style=\"font-weight: 400;\"> Lambda functions should use supported runtimes<\/span><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#KMS\" rel=\"noopener\"><span style=\"font-weight: 400;\">AWS KMS<\/span><\/a><\/td>\n<td><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#25\" rel=\"noopener\"><span style=\"font-weight: 400;\">(25)<\/span><\/a><span style=\"font-weight: 400;\"> AWS KMS keys should not be unintentionally deleted<\/span><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#guarduty\" rel=\"noopener\"><span style=\"font-weight: 400;\">Amazon GuardDuty<\/span><\/a><\/td>\n<td><\/td>\n<td><a href=\"https:\/\/sysdig.com\/blog\/26-aws-security-best-practices\/?utm_source=duckbill&amp;utm_medium=newsletter&amp;ck_subscriber_id=1190072794#26\" rel=\"noopener\"><span style=\"font-weight: 400;\">(26)<\/span><\/a><span style=\"font-weight: 400;\"> GuardDuty should be enabled<\/span><\/td>\n<td><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2><b>AWS Identity And Access Management (IAM)<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">AWS Identity and Access Management (IAM) helps enforce least privilege access control to AWS resources. You can use IAM to restrict who is authenticated (signed in) and authorized (has permissions) to use resources.<\/span><\/p>\n<h3><b>1_Do not allow full \u201c*\u201d administrative privileges on IAM policies \ud83d\udfe5\ud83d\udfe5\ud83d\udfe5<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">IAM policies define a set of privileges that are granted to users, groups, or roles. Following standard security advice, you should grant least privilege, which means to allow only the permissions that are required to perform a task.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-21965\" src=\"http:\/\/renovacloud.com\/wp-content\/uploads\/2023\/01\/AWS-security-best-practices-04-350x356-1.png\" alt=\"\" width=\"350\" height=\"356\" \/><\/p>\n<p><span style=\"font-weight: 400;\">When you provide full administrative privileges instead of the minimum set of permissions that the user needs, <\/span><a href=\"https:\/\/sysdig.com\/blog\/threat-detection-aws-cloud-containers\/\" rel=\"noopener\"><span style=\"font-weight: 400;\">you expose the resources to potentially unwanted actions<\/span><\/a><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For each AWS account, list the customer managed policies available:<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">aws iam list-policies &#8211;scope Local &#8211;query &#8216;Policies[*].Arn&#8217;<\/span><\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\">The previous command will return a list of policies along with their Amazon Resource Names (ARNs). Using these ARNs, now retrieve the policy document in JSON format:<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">aws iam get-policy-version<\/span><\/p>\n<p><span style=\"font-weight: 400;\">&#8211;policy-arn POLICY_ARN<\/span><\/p>\n<p><span style=\"font-weight: 400;\">&#8211;version-id v1<\/span><\/p>\n<p><span style=\"font-weight: 400;\">&#8211;query &#8216;PolicyVersion.Document&#8217;<\/span><\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\">The output should be the requested IAM policy document:<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">{<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0&#8220;Version&#8221;: &#8220;2012-10-17&#8221;,<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0&#8220;Statement&#8221;: [<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8220;Sid&#8221;: &#8220;1234567890&#8221;,<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8220;Effect&#8221;: &#8220;Allow&#8221;,<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8220;Action&#8221;: &#8220;*&#8221;,<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8220;Resource&#8221;: &#8220;*&#8221;<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0]<\/span><\/p>\n<p><span style=\"font-weight: 400;\">}<\/span><\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\">Look into this document for the following elements:<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">&#8220;Effect&#8221;: &#8220;Allow&#8221;, &#8220;Action&#8221;: &#8220;*&#8221;, &#8220;Resource&#8221;: &#8220;*&#8221;<\/span><\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\">If these elements are present, then the customer-managed policy allows full administrative privileges. This is a risk and must be avoided, so you will need to tune these policies down to pinpoint exactly what actions you want to allow for each specific resource.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Repeat the previous procedure for the other IAM customer managed policies.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If you want to detect the use of full administrative privileges with open source, here is a Cloud Custodian rule:<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">&#8211; name: full-administrative-privileges<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0description: IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered a standard security advice to grant least privilege -that is, granting only the permissions required to perform a task. Determine what users need to <\/span><b>do<\/b><span style=\"font-weight: 400;\"> and then craft policies <\/span><b>for<\/b><span style=\"font-weight: 400;\"> them that <\/span><b>let<\/b><span style=\"font-weight: 400;\"> the users perform only those tasks, instead <\/span><b>of<\/b><span style=\"font-weight: 400;\"> allowing full administrative privileges.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0resource: iam-policy<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0filters:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0&#8211; type: used<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0&#8211; type: has-allow-all<\/span><\/p><\/blockquote>\n<h3><b>2_Do not attach IAM policies to users \ud83d\udfe9<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">By default, IAM users, groups, and roles have no access to AWS resources.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-27403\" src=\"http:\/\/renovacloud.com\/wp-content\/uploads\/2023\/01\/AWS-BEST-PRACTICE-POLICY.png\" alt=\"\" width=\"610\" height=\"400\" \/><\/p>\n<p><span style=\"font-weight: 400;\">IAM policies grant privileges to users, groups, or roles. We recommend that you apply IAM policies directly to groups and roles but not to users. Assigning privileges at the group or role level reduces the complexity of access management as the number of users grows. Reducing access management complexity might in turn reduce the opportunity for a principal to inadvertently receive or retain excessive privileges.<\/span><\/p>\n<h3><b>3_Rotate IAM users\u2019 access keys every 90 days or less \ud83d\udfe8\ud83d\udfe8<\/b><\/h3>\n<p><a href=\"https:\/\/docs.aws.amazon.com\/general\/latest\/gr\/aws-access-keys-best-practices.html\" rel=\"noopener\"><span style=\"font-weight: 400;\">AWS recommends<\/span><\/a><span style=\"font-weight: 400;\"> that you rotate the access keys every 90 days. Rotating access keys reduces the chance that an access key that is associated with a compromised or terminated account is used. It also ensures that data cannot be accessed with an old key that might have been lost, cracked, or stolen. Always update your applications after you rotate access keys.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-27405\" src=\"http:\/\/renovacloud.com\/wp-content\/uploads\/2023\/01\/AWS-BEST-PRACTICE-API-KEYS.png\" alt=\"\" width=\"610\" height=\"400\" \/><\/p>\n<p><span style=\"font-weight: 400;\">First, list all IAM users available in your AWS account with:<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">aws iam list-users &#8211;query &#8216;Users[*].UserName&#8217;<\/span><\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\">For all the users returned by this command, determine each active access key lifetime by doing:<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">aws iam list-access-keys &#8211;user-name USER_NAME<\/span><\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\">This should expose the metadata for each access key existing for the specified IAM user. The output will look like this:<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">{<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0&#8220;AccessKeyMetadata&#8221;: [<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8220;UserName&#8221;: &#8220;some-user&#8221;,<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8220;Status&#8221;: &#8220;Inactive&#8221;,<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8220;CreateDate&#8221;: &#8220;2022-05-18T13:43:23Z&#8221;,<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8220;AccessKeyId&#8221;: &#8220;AAAABBBBCCCCDDDDEEEE&#8221;<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0},<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8220;UserName&#8221;: &#8220;some-user&#8221;,<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8220;Status&#8221;: &#8220;Active&#8221;,<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8220;CreateDate&#8221;: &#8220;2022-03-21T09:12:32Z&#8221;,<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8220;AccessKeyId&#8221;: &#8220;AAAABBBBCCCCDDDDEEEE&#8221;<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0]<\/span><\/p>\n<p><span style=\"font-weight: 400;\">}<\/span><\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\">Check the <\/span><span style=\"font-weight: 400;\">CreateDate<\/span><span style=\"font-weight: 400;\"> parameter value for each active key to determine its creation time. If an active access key has been created before the last 90 days, the key is outdated and must be <\/span><a href=\"https:\/\/aws.amazon.com\/blogs\/security\/how-to-rotate-access-keys-for-iam-users\/\" rel=\"noopener\"><span style=\"font-weight: 400;\">rotated<\/span><\/a><span style=\"font-weight: 400;\"> to secure the access to your AWS resources.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Repeat for each IAM user existing in your AWS account.<\/span><\/p>\n<h3><b>4_Ensure that IAM root user access keys do not exist \ud83d\udfe5\ud83d\udfe5\ud83d\udfe5<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">As we stated during your initial setup, we highly recommend that you remove all access keys that are associated with the root user. This limits the vectors that can be used to compromise your account. It also encourages the creation and use of role-based accounts that are least privileged.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The following Cloud Custodian rule will check if root access keys have been used on your account:<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">&#8211; name: root-access-keys<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0description: The root user account is the most privileged user <\/span><b>in<\/b><span style=\"font-weight: 400;\"> an AWS account. AWS Access Keys provide programmatic access to a given AWS account. It is recommended that all access keys associated <\/span><b>with<\/b><span style=\"font-weight: 400;\"> the root user account be removed.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0resource: account<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0filters:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0&#8211; type: iam-summary<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0key: AccountAccessKeysPresent<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0value: 0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0op: gt<\/span><\/p><\/blockquote>\n<h3><b>5_Enable MFA for all IAM users that have a console password \ud83d\udfe8\ud83d\udfe8<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Multi-factor authentication (MFA) adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS website, they are prompted for their username and password. In addition, they are prompted for an authentication code from their AWS MFA device.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-27407\" src=\"http:\/\/renovacloud.com\/wp-content\/uploads\/2023\/01\/AWS-BEST-PRACTICE-mfa.png\" alt=\"\" width=\"610\" height=\"400\" \/><\/p>\n<p><span style=\"font-weight: 400;\">We recommend that you <\/span><a href=\"https:\/\/sysdig.com\/blog\/why-mfa-prevents-attacks\/\" rel=\"noopener\"><span style=\"font-weight: 400;\">enable MFA for all accounts<\/span><\/a><span style=\"font-weight: 400;\"> that have a console password. MFA is designed to provide increased security for console access. The authenticating principal must possess a device that emits a time-sensitive key and must have knowledge of a credential.<\/span><\/p>\n<h3><b>6_Enable hardware MFA for the root user \ud83d\udfe5\ud83d\udfe5\ud83d\udfe5<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Virtual MFA might not provide the same level of security as hardware MFA devices. A hardware MFA has a minimal attack surface, and cannot be stolen unless the malicious user gains physical access to the hardware device. We recommend that you use only a virtual MFA device while you wait for hardware purchase approval or for your hardware to arrive, especially for root users.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">To learn more, see <\/span><a href=\"https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/id_credentials_mfa_enable_virtual.html\" rel=\"noopener\"><span style=\"font-weight: 400;\">Enabling a virtual multi-factor authentication (MFA) device (console)<\/span><\/a><span style=\"font-weight: 400;\"> in the IAM User Guide.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Here is a Cloud Custodian rule to detect lack of root hardware MFA:<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">&#8211; name: root-hardware-mfa<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0description: The root user account is the most privileged user <\/span><b>in<\/b><span style=\"font-weight: 400;\"> an AWS account. MFA adds an extra layer <\/span><b>of<\/b><span style=\"font-weight: 400;\"> protection on top <\/span><b>of<\/b><span style=\"font-weight: 400;\"> a username and password. With MFA enabled, when a user signs <\/span><b>in<\/b><span style=\"font-weight: 400;\"> to an AWS website, they will be prompted <\/span><b>for<\/b><span style=\"font-weight: 400;\"> their username and password <\/span><b>as<\/b><span style=\"font-weight: 400;\"> well <\/span><b>as<\/b> <b>for<\/b><span style=\"font-weight: 400;\"> an authentication code <\/span><b>from<\/b><span style=\"font-weight: 400;\"> their AWS MFA device. It is recommended that the root user account be protected <\/span><b>with<\/b><span style=\"font-weight: 400;\"> a hardware MFA.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0resource: account<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0filters:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0&#8211; or:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8211; type: iam-summary<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0key: AccountMFAEnabled<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0value: 1<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0op: ne<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8211; and:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8211; type: iam-summary<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0key: AccountMFAEnabled<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0value: 1<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0op: eq<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&#8211; type: has-virtual-mfa<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0value: <\/span><b>true<\/b><\/p><\/blockquote>\n<h3><b>7_Ensure those password policies for IAM users have strong configurations \ud83d\udfe8\ud83d\udfe8<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">We recommend that you enforce the creation of strong user passwords. You can set a password policy on your AWS account to specify complexity requirements and mandatory rotation periods for passwords.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">When you create or change a password policy, most of the password policy settings are enforced the next time users change their passwords. Some of the settings are enforced immediately.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">What constitutes a strong password is a subjective matter, but the following settings will put you on the right path:<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">RequireUppercaseCharacters: <\/span><b>true<\/b><\/p>\n<p><span style=\"font-weight: 400;\">RequireLowercaseCharacters: <\/span><b>true<\/b><\/p>\n<p><span style=\"font-weight: 400;\">RequireSymbols: <\/span><b>true<\/b><\/p>\n<p><span style=\"font-weight: 400;\">RequireNumbers: <\/span><b>true<\/b><\/p>\n<p><span style=\"font-weight: 400;\">MinimumPasswordLength: 8<\/span><\/p><\/blockquote>\n<h3><b>8_Remove unused IAM user credentials \ud83d\udfe8\ud83d\udfe8<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">IAM users can access AWS resources using different types of credentials, such as passwords or access keys. We recommend you remove or deactivate all credentials that were unused for 90 days or more to reduce the window of opportunity for credentials associated with a compromised or abandoned account to be used.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">You can use the IAM console to get some of the information that you need to monitor accounts for dated credentials. For example, when you view users in your account, there is a column for Access key age, Password age, and Last activity. If the value in any of these columns is greater than 90 days, make the credentials for those users inactive.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">You can also use credential reports to monitor user accounts and identify those with no activity for 90 or more days. You can download credential reports in .csv format from the IAM console.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For more information, check out <\/span><a href=\"https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/best-practices.html\" rel=\"noopener\"><span style=\"font-weight: 400;\">AWS security best practices for IAM<\/span><\/a><span style=\"font-weight: 400;\"> in more detail.<\/span><\/p>\n<h2><b>Conclusion<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Going all cloud opens a new world of possibilities, but it also opens a wide door to attacking vectors. Each new AWS service you leverage has its own set of potential dangers you need to be aware of and well prepared for.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Luckily, cloud native security tools like <\/span><span style=\"font-weight: 400;\">Renova Cloud, an AWS Consulting Partner with a focus on Security, can guide you through these best practices<\/span><span style=\"font-weight: 400;\">, and help you meet your compliance requirements.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Subscribe now to learn more about <\/span><a href=\"https:\/\/docs.aws.amazon.com\/awscloudtrail\/latest\/userguide\/best-practices-security.html\" rel=\"noopener\"><span style=\"font-weight: 400;\">security best practices in AWS<\/span><\/a><span style=\"font-weight: 400;\"><a href=\"https:\/\/renovacloud.com\/en\/26-aws-security-best-practices-to-adopt-in-production-part-2\/\" target=\"_blank\" rel=\"noopener\"> part 2<\/a> and <a href=\"https:\/\/renovacloud.com\/en\/26-aws-security-best-practices-to-adopt-in-production-part-3\/\" target=\"_blank\" rel=\"noopener\">part 3<\/a>.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>One of the most important pillars of a well-architected framework is security. Thus, it is important to follow these AWS security best practices to prevent unnecessary security situations. So, you\u2019ve got a problem to solve and turned to AWS to build and host your solution. You create your account and now you\u2019re all set up [&#8230;]\n","protected":false},"author":19,"featured_media":22053,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[861],"tags":[],"class_list":["post-22000","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/posts\/22000","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/users\/19"}],"replies":[{"embeddable":true,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/comments?post=22000"}],"version-history":[{"count":5,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/posts\/22000\/revisions"}],"predecessor-version":[{"id":27409,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/posts\/22000\/revisions\/27409"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/media\/22053"}],"wp:attachment":[{"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/media?parent=22000"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/categories?post=22000"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/tags?post=22000"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}