Kanji
・Ingeniero Cloud / Freelance ・Nacido en 1993 ・De Ehime / Residente en Shibuya, Tokio ・5 años de experiencia en AWS Detalles del perfil
Índice
AWS Config (hereafter referred to as Config) is a service that monitors the configuration and changes of AWS resources. Config can only obtain configuration information for AWS resources and cannot obtain configuration information for operating systems, applications, databases, etc.
There are limitations on the AWS resources that Config can record, so caution is required. For example, resources such as Organizations, all resources of IAM Identity Center, Systems Manager Parameter Store, and documents cannot be recorded.
Reference: Supported Resource Types for AWS Config - AWS Config
In addition to managing AWS resource configurations, Config can monitor resource settings by using AWS Config Rules (hereafter referred to as Config Rules).
When Config detects a configuration change, it can determine whether the resource is noncompliant based on the set rules, and if so, send a notification.
In on-premises environments, configuration management and change tracking are often handled using documents such as Excel and Word. In more automated systems, configuration management for operating systems may be performed using Ansible.
Configuration information in AWS can be recorded by AWS Config, but as mentioned above, there are limitations on the resources that can be recorded. While major AWS resources can be tracked, it is necessary to consider how to record changes for resources that cannot be tracked by Config.
Additionally, when using Config Rules, recording changes in the target AWS resources with Config is a prerequisite.
Enabling Config for all AWS accounts is generally recommended. However, if you “manage configuration and changes with another configuration management tool instead of Config” and “check for configuration deficiencies with another security check tool instead of Config Rules,” it is also an option not to implement Config.
For “managing configuration and changes with another configuration management tool instead of Config,” using an IaC tool is one option, but requiring the use of an IaC tool for the entire system may be difficult depending on the skill level of developers and operators.
If another SaaS tool is adopted company-wide, it is better to use that tool.
For “checking for configuration deficiencies with another security check tool instead of Config Rules,” the following options are available:
When using Config Rules as a security tool, it is necessary to clarify the security rules that the company must meet. Depending on these rules, it may be better to check for configuration deficiencies with another security check tool instead of using Config Rules.
Since it is difficult to create Config Rules from scratch, it is efficient to create Config Rules to meet security requirements by using conformance packs or Security Hub standards based on those requirements.
Conformance Pack Sample Templates for AWS Config - AWS Config
Security Hub standards reference - AWS Security Hub
If there are no specific security rules, it is recommended to first implement Config Rules recommended by the AWS Foundational Security Best Practices (FSBP) or AWS Well-Architected Framework conformance packs in Security Hub.
AWS Foundational Security Best Practices v1.0.0 (FSBP) standard - AWS Security Hub
Operational Best Practices for AWS Well-Architected Framework Reliability Pillar - AWS Config
Operational Best Practices for AWS Well-Architected Framework Security Pillar - AWS Config
Both the AWS Foundational Security Best Practices (FSBP) and the AWS Well-Architected Framework are best practices provided by AWS, but the AWS Foundational Security Best Practices focus more on security.
When setting Config Rules as guardrails, it is necessary to select which AWS resources will be tracked by Config. However, as in cases 1 and 2, excessive tracking can incur costs, so resources should be selected according to the characteristics of the resources in each AWS account.
Config is generally managed by the infrastructure team, but since only the system administrator understands the resources in the member account, it is better to manage on an application basis using internal workflows.
In case 3, if preventive control through security checks in the CI/CD pipeline is possible rather than detective control by Config, it is not necessary to track with Config. However, if there are cases where resources deployed during operation are manually changed, tracking with Config should be considered.
Reference: Recording AWS Resources with AWS Config - AWS Config
When enabling Config using Control Tower, it is possible to automatically exclude resources from being tracked by Config when issuing AWS accounts by using the solution described in the following blog.
Customize AWS Config resource tracking in AWS Control Tower environment | AWS Cloud Operations Blog
After roughly deciding on security rules and frameworks in 2. What Security Rules Must the Company Meet? , it is necessary to set more detailed rules.
If you apply the conformance packs or Security Hub standards of Config Rules as they are, rules that are not so important will also be set, so only select the rules that truly need to be addressed.
This rule selection is a labor-intensive task.
It is better to exclude rules that can be addressed by other controls, such as preventive control AWS services like SCP and identity access management, and other detective control AWS services like GuardDuty.
The selection process varies by company, and it is difficult to provide examples, so the explanation ends here.
1 and 2 are generally handled by the infrastructure team, but 3 is often handled by the system administrator who can make changes to the system.
For example, if it is detected that EC2 EBS is not encrypted, it is necessary to consider the impact of the change and take corrective action, so the system administrator will handle the operation.
Config can also execute remediation actions, so there are cases where noncompliant resources are automatically corrected.
If deploying with IaC, there will be a discrepancy with the configuration defined in the source code, so it is necessary to inform developers of the implementation.
The change history of resources tracked by Config may be used by both the infrastructure team and the system administrator, but Config logs are often centrally stored in the log management account, and the system administrator may not be able to analyze logs with Athena.
Even if Config is enabled at the organizational level, it is possible for the system administrator to analyze logs of their own AWS account using advanced queries.
Reference: Querying the Current Configuration State of AWS Resources with AWS Config - AWS Config