설정된 규칙을 기반해 구성과 구성의 시간에 따른 변화를 기록할 수 있으며 이를 통해 필요할 경우 인프라를 빠르게 롤백하고 문제점을 찾아낼 수 있음
예1) 보안 그룹에 제한되지 않은 SSH 접근이 있나? 예2) 버킷에 공용 액세스가 있나? 예3) 시간이 지나며 변화한 ALB 구성이 있나? 이럴 경우 규칙이 규정을 준수하든 아니든 변화가 생길 때마다 SNS 알림을 받을 수 있음
리전별 서비스이기 때문에 모든 리전별로 구성해야 하며 데이터를 중앙화하기 위해 리전과 계정 간 데이터를 통합할 수 있음
모든 리소스의 구성을 S3에 저장해 나중에 분석할 수 있음 예) Athena와 같은 서버리스 쿼리 엔진을 통해 분석
Config Rules
Config에 적용되는 규칙
AWS관리형 Config 규칙 (75종의 규칙 존재)
스스로 Config 규칙을 생성해도 되며 이 경우 Lambda를 이용해 스스로 규칙을 정의해야 함 예) 각 EBS 디스크가 gp2 유형인지 평가, 개발 계정의 EC2 인스턴스가 t2. micro 유형인지 평가
몇몇 규칙들은 구성이 변화할 때마다 평가되거나 트리거됨 예) EBS 디스크에 새 구성이 생길 때마다 EBS 디스크의 유형을 평가하거나 정기적으로 규칙이 평가되도록 함
어떤 동작을 미리 예방하거나 차단할 수는 없으며 IAM 같은 보안 매커니즘을 대신할 수 없음 하지만 구성의 개요나 리소스의 규정 준수 여부를 Config 규칙을 통해 알 수 있음
Config 규칙을 사용하기 위해서는 결제가 필요하며 각 리전당 기록된 구성 항목별로 3센트를 지불해야 하며 리전당 Config 규칙 평가별로 0.1센트를 지불해야 함
AWS Config Resource
리소스의 규정 준수 여부를 시간 별로 볼 수 있음 예) 보안 그룹은 규정 미준수 상태
리소스 구성을 시간 별로 볼 수 있음 예) 언제, 누가 변경했는지 등
CloudTrail과 연결해 리소스에 대한 API 호출을 볼 수 있어 일어나는 모든 일을 전부 파악할 수 있음
Config Rules – Remediations
Config 내에서 행동을 차단할 수는 없지만 SSM 자동화 문서를 이용해서 규정을 준수하지 않는 리소스를 수정할 수 있음
예) IAM 액세스 키의 만료 여부를 모니터링할 때 키가 90일 이상 보관된 경우 규정을 준수하지 않은 상태 이 때 규정 미준수를 예방하지는 못하지만, 리소스가 규정을 미준수할 때마다 수정 작업을 트리거할 수 있음 RevokeUnusedIAMUserCredentials 이름의 SSM 문서를 이용해 리소스에 적용하면 이것이 IAM 액세스 키를 비활성화시킴
만약 계속 스크립트를 하고 싶다면 람다 함수를 실행하는 문서를 생성해서 원하는 작업을 실행할 수도 있음
수정 작업은 재시도 될 수 있으며 리소스를 자동 수정했음에도 여전히 규정을 미준수한다면 5번까지 재시도될 수 있음
Config Rules – Notifications
EventBridge를 사용해 리소스가 규정을 미준수했을 때마다 알림을 보낼 수 있음
예) 보안 그룹을 모니터링하다가 규정 미준수 상태가 됐다면 EventBridge에서 이벤트를 트리거해서 원하는 리소스에 넘김
모든 구성 변경과 모든 리소스의 규정 준수 여부 알림을 Config에서 SNS로 보낼 수 있음
한 구성 항목이 있고 특정 이벤트에만 적용되게 필터링하고 싶다면 SNS 필터링을 사용해 SNS Topic을 필터링할 수 있음
또한 알림을 전송할 수 있음 예) 관리자 이메일이나 Slack 채널로 알림을 보내 한 곳에 집중시킴
<Config 실습>
Config 구성 리전에서 지원하는 모든 리소스를 기록할 것인지, 특정 리소스만 기록할 것인지 설정하며 리소스 범주와 리소스 유형을 열람 가능 또한 글로벌 리소스인 IAM 사용자, 그룹, 역할, 고객 관리형 정책 등을 포함할 수 있음 하지만 Config는 유료 서비스이므로 많은 리소스를 기록할수록 요금이 늘어남을 기억해야함 모든 리소스 구성을 기록하기 위해서는 서비스 연결 역할을 생성해야 하며, 이를 통해 모든 정보는 S3 버킷으로 전달됨 또한 SNS Topic으로 모든 구성 변화와 알림을 스트리밍도 할 수 있음
AWS 관리형 규칙을 정의할 수도 있음
이후 구성을 검토하여 생성
SettingsRulesRevies
Config 생성 확인 리소스로 가서 계정 내에서 탐색된 일부 리소스를 확인할 수 있으며 라우팅 테이블, 서브넷, VPC 등이 탐색됨 리소스 타임 라인은 리소스와 관련된 모든 이벤트를 표시하며 Configutaion change와 CloudTrail Event도 존재
Config Rule 생성 보안 그룹의 타임 라인을 살펴본 후 보안 그룹의 규정 준수 여부를 확인하고 규칙을 추가할 수도 있음 AWS 관리형 규칙을 추가하거나 AWS Lambda로 생성한 사용자 지정 규칙을 추가할 수 있음
AWS 관리형 규칙을 추가하기 위해 적용 가능한 규칙으로 특정 AMI를 이용해 계정 내 실행되고 있는 인스턴스를 찾는 규칙인 approved-amis-by-id를 선택
이 규칙은 특정 AMI를 이용해 EC2 인스턴스 실행 여부를 확인하도록 할 수 있으며 리소스가 변경될 때마다 이것을 트리거 가능 모든 EC2 인스턴스를 지정할 수 있으며 규칙을 위한 매개변수로 계정 내 검증된 AMI ID 목록으로 지정해야 함 이 매개변수는 규칙과 입력값이 이를 이용해 EC2 인스턴스의 규정 준수 여부를 판단하는데 사용됨
EC2 인스턴스가 많지 않기 때문에 위의 규칙은 취소한 후 이외에 SSH를 위한 규칙인 restricted-ssh를 클릭하여 생성하여 SSH 트래픽이 어느 곳에도 들어오지 못하도록 만드는 규칙을 보안 그룹에 적용 이는 소스의 구성이 변환할 때마다 트리거되도록 할 수 있음 이는 보안 그룹 리소스가 변환될 때마다 규칙을 평가하게 되며 EC2 보안 그룹에만 규칙이 적용되고 이에 대한 매개변수는 없음 이를 작성하여 첫 번째 규칙을 생성
Config Rule 확인 보안 그룹 규칙에서 규정 미준수였던 상태에 대해 잘못된 규칙을 삭제하면 리소스 평가가 다시 트리거 되어 준수 상태가 됨 이후 리소스 타임라인으로 가서 확인을 하면 구성 변화가 생긴 것을 볼 수 있음 또한 규정 준수 뒤에 RevokeSecurityGroupIngress를 삭제했기 때문에 CloudTrail 이벤트가 발생한 것도 볼 수 있음
구성 변화를 살펴보면 포트 22를 가지고 있는 규칙이 삭제되었지만 Config가 restrict-ssh 규칙을 다시 실행해 리소스가 구성 상태가 되어 리소스의 규정 준수 여부를 수정했다는 것을 알 수 있음
규칙의 Actions에서 Manage remediation을 하면 규칙을 수정할 수 있으며 규칙을 보면 수정 관리가 있고 수동 수정과 자동 수정이 존재 자동 수정은 재시도 회수와 재시도 간격을 설정할 수 있고 수동 수정을 선택하면 수정 action을 선택해야 함 수정 action에는 준수 상태가 아닐 때 스냅샷을 삭제하거나 이미지를 삭제하는 등의 액션이 정의되어 있는 AWS가 정의한 SSM 자동화 문서들이 존재하여 이외에도 스스로 만들 수도 있어 규칙에 맞는 수정 액션을 정의할 수 있음
예) AttachEBSVolume을 선택하면 미준수 리소스에 기반한 비율 제한 값을 설정할 수 있으며 리소스 ID 매개변수를 수정 액션에 보낼 수 있음
+) 이외에도 Config의 Aggregators는 다수의 계정을 통합하는 일을 하여 이에 대한 정의도 가능하며 SNS Topic으로 모든 데이터를 전송하는 설정을 하거나 CloudWatch나 Events 규칙 콘솔로 CloudWatch Events 규칙을 설정해 특정 규칙에 대한 특정 미준수 이벤트를 막을 수 있음
