결정은 기록이 아니라 실행이어야 한다
대부분의 AWS 접근 권한 재인증(Access Recertification) 프로세스는 구조적 결함을 안고 있다. 담당자가 리소스 목록을 검토하고 "승인/취소"를 클릭하면 사이클이 완료된 것으로 표시된다. 그런데 실제 AWS 리소스의 권한은 그대로다. 검토는 기록을 남겼지만, 실제 상태는 변하지 않았다. 취소한 접근 권한이 여전히 살아있는 것이다.
이 괴리는 컴플라이언스 관점에서 심각한 문제다. 감사 보고서에는 "재인증 완료"라고 적혀 있지만, 실제 최소 권한 원칙(Principle of Least Privilege)은 지켜지지 않고 있다. 이 문제를 해결하기 위해 만들어진 오픈소스 엔진이 VIGIL이다. AWS의 aws-samples 조직에 공개되어 있으며, 핵심 아이디어는 단순하다. 결정과 실행을 하나의 단계로 통합하는 것이다.
VIGIL의 동작 방식: 태그 기반 탐색과 즉시 적용
VIGIL은 네 가지 단계로 동작한다.
owner태그를 기준으로 리소스를 탐색하고, 각 리소스에 실제로 누가 접근 가능한지 파악한다.- 소유자에게 접근 권한을 유지(keep) / 축소(trim) / 제거(remove) 중 하나로 결정하게 한다.
- 해당 결정을 라이브 리소스에 즉시 적용한다.
- 이후 감사에 활용할 수 있도록 변경 이력을 기록한다.
기존 도구들이 결정을 티켓으로 남기고 실제 변경은 다음 분기로 미루는 방식이었다면, VIGIL은 결정이 곧 변경이다. 리뷰 사이클이 끝나는 시점에 AWS 상태도 함께 바뀐다.
범위 제한 적용(Scoped Enforcement)이 핵심인 이유
권한 제거를 단순하게 구현하면 IAM 정책 전체를 detach하거나 삭제하는 방식을 택하게 된다. 이는 해당 주체(principal)가 가진 모든 권한을 날려버리는 방식으로, 의도치 않은 서비스 장애를 유발한다. 보안을 강화하려다 인시던트를 만드는 가장 흔한 패턴이다.
VIGIL은 이 문제를 범위 제한 적용(Scoped Enforcement) 으로 해결한다. 접근 권한이 버킷 정책에서 온 경우 해당 버킷 정책에서 특정 principal 또는 특정 액션만 제거한다. 접근이 IAM 정책에서 비롯된 경우에는 공유 정책을 수정하는 대신, 리소스 범위를 지정한 명시적 Deny를 추가한다. 예를 들어 특정 버킷에 대한 s3:PutObject 권한만 제거하고 나머지는 그대로 유지하는 것이 가능하다.
# VIGIL이 생성하는 Explicit Deny 예시 (개념적 표현)
Effect: Deny
Action: s3:PutObject
Resource: arn:aws:s3:::specific-bucket/*
Principal: arn:aws:iam::123456789012:user/target-user
변경이 안전하고 좁은 범위로 이루어질 수 없다면 VIGIL은 변경을 중단하고 에러를 올린다. 광범위한 부작용이 우려되는 경우 아무것도 건드리지 않는다는 원칙이다. 실무에서 가장 중요한 설계 결정 중 하나다.
정리
- 기존 재인증 도구는 결정을 기록할 뿐 실제 권한 변경은 별도 작업으로 남겨두는 구조적 결함이 있다.
- VIGIL은
owner태그 기반 탐색과 즉시 적용을 통해 결정과 실행을 단일 단계로 통합한다. - 범위 제한 적용(Scoped Enforcement)으로 의도치 않은 권한 제거를 방지하며, 안전하지 않은 변경은 실행하지 않는다.