Kanji
・클라우드 엔지니어 / 프리랜서 ・1993년생 ・에히메현 출신 / 도쿄도 시부야구 거주 ・AWS 경력 5년 프로필 상세
목차
AWS Config(이하 Config)는 AWS 리소스의 구성 및 변경 사항을 모니터링하는 서비스입니다.Config는 AWS 리소스에 대한 구성 정보만 얻을 수 있으며 운영 체제, 애플리케이션, 데이터베이스 등에 대한 구성 정보는 얻을 수 없습니다.
Config가 기록할 수 있는 AWS 리소스에는 제한이 있으므로 주의가 필요합니다.예를 들어 조직과 같은 리소스, IAM Identity Center의 모든 리소스, Systems Manager Parameter Store 및 문서는 기록할 수 없습니다.
참조: AWS Config에 지원되는 리소스 유형 - AWS Config
Config는 AWS 리소스 구성을 관리하는 것 외에도 AWS Config 규칙(이하 Config 규칙)을 사용하여 리소스 설정을 모니터링할 수 있습니다.
Config가 구성 변경을 감지하면 설정된 규칙에 따라 리소스가 비준수인지 여부를 판단하고, 비준수인 경우 알림을 보낼 수 있습니다.
온프레미스 환경에서는 구성 관리 및 변경 추적이 Excel, Word 등의 문서를 사용하여 처리되는 경우가 많습니다.더욱 자동화된 시스템에서는 Ansible을 사용하여 운영 체제에 대한 구성 관리를 수행할 수 있습니다.
AWS의 구성 정보는 AWS Config를 통해 기록할 수 있지만, 위에서 언급한 것처럼 기록할 수 있는 리소스에는 제한이 있습니다.주요 AWS 리소스는 추적이 가능하지만 Config에서 추적할 수 없는 리소스에 대해서는 변경 사항을 기록하는 방법을 고려할 필요가 있습니다.
또한 Config Rules를 사용할 때 Config를 사용하여 대상 AWS 리소스의 변경 사항을 기록하는 것이 전제 조건입니다.
일반적으로 모든 AWS 계정에 대해 Config를 활성화하는 것이 좋습니다.그러나 “Config 대신 다른 구성 관리 도구로 구성 및 변경 사항을 관리”하고 “Config Rules 대신 다른 보안 검사 도구로 구성 결함을 확인”하는 경우에는 Config를 구현하지 않는 옵션이기도 합니다.
“Config 대신 다른 구성 관리 도구로 구성 및 변경 사항을 관리”하려면 IaC 도구를 사용하는 것도 하나의 옵션이지만, 전체 시스템에 대해 IaC 도구를 사용하도록 요구하는 것은 개발자 및 운영자의 기술 수준에 따라 어려울 수 있습니다.
전사적으로 다른 SaaS 도구를 채택하는 경우 해당 도구를 사용하는 것이 좋습니다.
“구성 규칙 대신 다른 보안 검사 도구를 사용하여 구성 결함을 확인”하는 경우 다음 옵션을 사용할 수 있습니다.
Config Rules를 보안 도구로 활용하는 경우 회사가 준수해야 하는 보안 규칙을 명확히 할 필요가 있습니다.이러한 규칙에 따라 구성 규칙을 사용하는 대신 다른 보안 검사 도구를 사용하여 구성 결함을 확인하는 것이 더 나을 수도 있습니다.
처음부터 Config Rule을 생성하는 것은 어렵기 때문에 해당 요구 사항을 기반으로 Conformance Pack이나 Security Hub 표준을 사용하여 보안 요구 사항을 충족하는 Config Rule을 생성하는 것이 효율적입니다.
AWS Config용 적합성 팩 샘플 템플릿 - AWS Config
Security Hub 표준 참조 - AWS Security Hub
구체적인 보안 규칙이 없는 경우 AWS Foundational Security Best Practices(FSBP) 또는 AWS Well-Architected Framework 적합성 팩에서 권장하는 구성 규칙을 먼저 Security Hub에 구현하는 것이 좋습니다.
AWS 기초 보안 모범 사례 v1.0.0(FSBP) 표준 - AWS Security Hub
AWS Well-Architected 프레임워크 안정성 원칙에 대한 운영 모범 사례 - AWS Config
AWS Well-Architected 프레임워크 보안 원칙에 대한 운영 모범 사례 - AWS Config
AWS 기초 보안 모범 사례(FSBP)와 AWS Well-Architected 프레임워크는 모두 AWS에서 제공하는 모범 사례이지만, AWS 기초 보안 모범 사례는 보안에 더 중점을 둡니다.
Config Rules를 가드레일로 설정할 때 Config에서 추적할 AWS 리소스를 선택해야 합니다.다만, 1번과 2번의 경우처럼 과도한 추적은 비용이 발생할 수 있으므로 각 AWS 계정의 리소스 특성에 맞게 리소스를 선택해야 합니다.
Config는 일반적으로 인프라팀에서 관리하지만, 멤버 계정의 리소스는 시스템 관리자만 이해하므로 내부 워크플로를 활용하여 애플리케이션 단위로 관리하는 것이 좋습니다.
3번의 경우 Config에 의한 탐지제어가 아닌 CI/CD 파이프라인의 보안점검을 통한 예방제어가 가능하다면 Config로 추적할 필요가 없다.다만, 운영 중에 배포된 리소스를 수동으로 변경하는 경우가 있는 경우에는 Config를 통한 추적을 고려해야 합니다.
참조: AWS Config를 사용하여 AWS 리소스 기록 - AWS Config
Control Tower를 사용하여 Config를 활성화하면 다음 블로그에 설명된 솔루션을 사용하여 AWS 계정 발급 시 Config가 추적하는 리소스를 자동으로 제외할 수 있습니다.
AWS Control Tower 환경에서 AWS Config 리소스 추적 사용자 정의 |AWS 클라우드 운영 블로그
2.회사가 준수해야 하는 보안 규칙은 무엇입니까? , 보다 자세한 규칙을 설정할 필요가 있습니다.
Conformance Pack이나 Config Rules의 Security Hub 표준을 그대로 적용하면 그다지 중요하지 않은 규칙도 설정되므로 꼭 해결해야 할 규칙만 선택하세요.
이 규칙 선택은 노동 집약적인 작업입니다.
SCP 및 ID 액세스 관리와 같은 예방 제어 AWS 서비스, GuardDuty와 같은 기타 탐지 제어 AWS 서비스 등 다른 제어로 처리할 수 있는 규칙을 제외하는 것이 좋습니다.
선정 과정은 기업별로 다르며, 예시를 제시하기 어려우므로 여기서 설명을 마치겠습니다.
1번과 2번은 일반적으로 인프라팀에서 처리하지만, 3번은 시스템을 변경할 수 있는 시스템 관리자가 처리하는 경우가 많습니다.
예를 들어 EC2 EBS가 암호화되지 않은 것으로 감지되면 변경으로 인한 영향을 고려하고 수정 조치를 취해야 시스템 관리자가 작업을 처리하게 됩니다.
Config는 수정 작업을 실행할 수도 있으므로 규정을 준수하지 않는 리소스가 자동으로 수정되는 경우가 있습니다.
IaC로 배포할 경우 소스코드에 정의된 구성과 불일치하므로 개발자에게 구현 내용을 알려야 한다.
Config에서 추적한 리소스의 변경 내역은 인프라팀과 시스템 관리자 모두 사용할 수 있지만, Config 로그는 로그 관리 계정에 중앙에 저장되는 경우가 많아 시스템 관리자가 Athena로 로그를 분석하지 못할 수도 있습니다.
조직 수준에서 Config가 활성화되어 있어도 시스템 관리자는 고급 쿼리를 사용하여 자신의 AWS 계정의 로그를 분석할 수 있습니다.
참조: AWS Config를 사용하여 AWS 리소스의 현재 구성 상태 쿼리 - AWS Config