이번 포스팅에서는 security hub의 finding에 대한 워크 플루 상태 4가지와 이미 삭제된 자원에 대해 자동으로 상태를 RESOLVED로 변경하는 방식에 대해 알아보고자 합니다.
우선 AWS 보안의 포괄적인 뷰를 제공하는 Security hub 는 4가지 status 가 존재합니다.
NEW - finding이 최초로 생성될 때
NOTIFIED - 리소스 소유자에게 결과에 대한 작업을 수행하도록 통지한 경우
SUPPRESSED - 결과가 조치가 필요하지 않는 경우
RESOLIVED - 결과를 검토하고 조치를 취한 이후
이를 통해 생성되는 findings 을 이해하고 어떤 후속 조치를 취해야 하는지를 분석할 수 있습니다. 하지만 포괄적인 뷰를 제공하는 security hub는 단일 계정, 단일 리전에만 활성화되어 있지 않는다는 것이 문제입니다. 하나의 security hub master 계정과 OU에 속하는 다수의 member 계정들 복수의 리전에서 생성하는 무수히 많은 finding에서 유의미한 분석과 결과를 얻기란 만만해 보이지 않습니다.
예를 들어 ec2 인스턴스의 오토 스케일링을 예를 들어 보겠습니다. 하루에도 무수히 많은 인스턴스들이 생성 되었다 사라지게 될 것이다. 하지만 이 일시적인 자원들이 생성해 내는 finding 이 인스턴스들이 사라진 이후에도 그대로 남아있는 아무 의미가 없는 쓰레기일뿐이며 관리자들이 finding을 분석하는데 방해가 될 뿐일것입니다.
삭제된 자원의 finding을 자동으로 resloved 처리하는 것은 결국 보안팀에게 쓸모없는 시간을 소비하는 것을 덜어주고 더 정제된 결과를 조사하고 조치를 취하는데 집중할 수 있도록 도와줄 것입니다.
위는 Security Hub 의 member 계정에서 자원이 삭제되었을 때 어떻게 자동으로 삭제된 자원의 finding을 RESOLVED로 업데이트하는 방식에 대한 아키텍처입니다.
대략적으로 보자면 유저의 삭제 로그를 event Bridge 에서 추려내 security hub의 admin 계정에게 전달합니다. 그리고 이 api 정보를 토대로 삭제된 대상의 finding 을 Lambda에서 RESOLVED로 업데이트한 후 Security hub의 member에게 다시 업데이트 정보를 전달하게 됩니다.
다시 한번 조금 더 자세히 이 과정을 살펴보겠습니다.
1. 유저가 EC2, IAM, S3 를 삭제한다.
2. CloudTrail 이 로그들을 Event Bridge로 포워딩한다.
3. Event Bridge의 event pattern (rule)에서 EC2, IAM, S3에 대한 삭제 API를 필터링한다.
4. EC2, IAM, S3 삭제에 대한 API를 admin account로 포워딩한다.
5. admin account 내에서 EC2, IAM, S3에 대한 삭제 API를 필터링한다.
(3번에서 이미 했는데 왜 다시 동일 작업을 하는지는 저는 잘 이해가 되지 않습니다..)
6. 해당 API가 Lambda Fucution 이 발동할 수 있도록 트리거를 발생시킨다.
7. Lambda 가 삭제된 자원에 대한 finding의 status를 RESOLVED로 업데이트한다.
8. Security hub admin account에서 member account에 업데이트 내용을 전파한다.
이번 포스팅에서 삭제된 자원에 대한 finding을 RESOLVED 처리하는 과정에 대해 알아봤습니다. Security hub의 경우 포괄적, 일관적 보안 뷰를 제공해주며 memeber 계정들까지 통합하게 됩니다. 엔터프라이즈 기업의 규모를 가정해보면 막대한 양의 finding 이 발생하게 되는데 이를 보안 관리자가 어떻게 운영할 수 있을까요. 이렇게 필요 없는 finding을 자동으로 조치함으로써 보안 운영의 수고를 덜어주고 더 중요한 finding 을 관리할 수 있게 도와줍니다.
아래의 글을 참조해 만들었습니다.
