Benchmark: 3.1.2 Limit system access to the types of transactions and functions that authorized users are permitted to execute
Description
Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. System account types include individual, shared, group, system, anonymous, guest, emergency, developer, manufacturer, vendor, and temporary. Other attributes required for authorizing access include restrictions on time-of-day, day-of-week, and point-oforigin. In defining other account attributes, organizations consider system-related requirements (e.g., system upgrades scheduled maintenance,) and mission or business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements).
Usage
Install the mod:
mkdir dashboardscd dashboardspowerpipe mod initpowerpipe mod install github.com/turbot/steampipe-mod-aws-complianceStart the Powerpipe server:
steampipe service startpowerpipe serverOpen http://localhost:9033 in your browser and select 3.1.2 Limit system access to the types of transactions and functions that authorized users are permitted to execute.
Run this benchmark in your terminal:
powerpipe benchmark run aws_compliance.benchmark.nist_800_171_rev_2_3_1_2Snapshot and share results via Turbot Pipes:
powerpipe benchmark run aws_compliance.benchmark.nist_800_171_rev_2_3_1_2 --shareControls
- Auto Scaling launch config public IP should be disabled
- DMS replication instances should not be publicly accessible
- EBS snapshots should not be publicly restorable
- EC2 instances should have IAM profile attached
- EC2 instances should be in a VPC
- EC2 instances should not have a public IP address
- ECS task definition container definitions should be checked for host mode
- EKS clusters endpoint should restrict public access
- EMR cluster Kerberos should be enabled
- EMR cluster master nodes should not have public IP addresses
- ES domains should be in a VPC
- Ensure IAM policy should not grant full access to service
- IAM groups should have at least one user
- IAM groups, users, and roles should not have any inline policies
- IAM policy should not have statements with admin access
- IAM root user hardware MFA should be enabled
- IAM root user MFA should be enabled
- IAM root user should not have access keys
- IAM users with console access should have MFA enabled
- IAM users should be in at least one group
- IAM user MFA should be enabled
- IAM user should not have any inline or attached policies
- IAM user credentials that have not been used in 90 days should be disabled
- Lambda functions should be in a VPC
- Lambda functions should restrict public access
- RDS DB instances should prohibit public access
- RDS snapshots should prohibit public access
- Redshift clusters should prohibit public access
- S3 bucket policy should prohibit public access
- S3 buckets should prohibit public read access
- S3 buckets should prohibit public write access
- S3 public access should be blocked at account level
- S3 public access should be blocked at bucket levels
- SageMaker notebook instances should not have direct internet access
- SSM documents should not be public
- VPC default security group should not allow inbound and outbound traffic
- VPC internet gateways should be attached to authorized vpc
- VPC route table should restrict public access to IGW
- VPC security groups should restrict ingress access on ports 20, 21, 22, 3306, 3389, 4333 from 0.0.0.0/0
- VPC security groups should restrict ingress SSH access from 0.0.0.0/0
- VPC security groups should restrict ingress TCP and UDP access from 0.0.0.0/0
- VPC subnet auto assign public IP should be disabled