AWS에서 iam:PassRole을 Resource: "*"로 허용하면 제한된 개발자나 CI/CD 역할도 서비스에 강력한 역할을 넘겨 계정 관리자 수준의 권한을 행사할 수 있다. Aleksander Roszig은 역할 범위와 전달 대상 서비스를 제한하고, 신뢰 정책과 조직 차원의 보호 장치를 함께 적용해야 한다고 설명한다.
iam:PassRole이 하는 일
Lambda 함수, EC2 인스턴스, ECS 작업 같은 AWS 리소스가 역할을 사용하려면 리소스를 생성하거나 업데이트할 때 해당 역할을 서비스에 연결해야 한다. 이때 호출자는 서비스 API 권한(예: lambda:CreateFunction)과 해당 역할에 대한 iam:PassRole 권한을 모두 가져야 한다. iam:PassRole은 주체가 특정 역할을 서비스에 전달할 수 있는지를 확인하는 권한이다.
따라서 iam:PassRole이 없어도 리소스 생성 권한만으로 리소스를 만들 수는 있지만 역할을 연결할 수는 없다. 반대로 호출자가 자신이 설정할 수 있는 서비스에 자신보다 강력한 역할을 전달할 수 있다면, 그 서비스가 호출자가 제어하는 코드를 실행하면서 해당 역할의 권한을 사용할 수 있다.
sts:AssumeRole은 호출 주체가 직접 역할을 맡는 API 호출이며 CloudTrail에 기록된다. 반면 iam:PassRole은 서비스가 역할을 맡도록 전달하는 권한으로, 별도의 API 호출이 아니며 CloudTrail에 PassRole 이벤트로 기록되지 않는다. 역할 전달은 CreateFunction이나 RunInstances 같은 API 요청의 매개변수에서 확인할 수 있다. 두 경우 모두 역할의 신뢰 정책이 중요하지만, iam:PassRole에는 호출자의 IAM 정책도 적용된다.
자주 발생하는 설정 문제와 제한 방법
Roszig은 AWS 보안 감사에서 흔히 보는 문제로 Resource: "*"에 대한 iam:PassRole, 자동화 환경의 iam:* 또는 Action: "*", iam:PassedToService 조건의 누락, 관리자 역할과 워크로드 역할의 이름 규칙이 겹치는 경우를 꼽는다. 이 설정들은 전달할 수 있는 역할이나 서비스의 범위를 넓혀 권한 상승 경로를 만들 수 있다.
역할을 전달할 수 있는 권한은 실제 워크로드에 필요한 역할 ARN으로 제한해야 한다. 예를 들어 lambda-exec-<app>-*나 ecs-task-<app>-*처럼 용도별 이름 규칙을 사용하고, 관리자 역할에는 워크로드 역할과 같은 이름 규칙을 적용하지 않는 방법이 있다. iam:PassedToService 조건을 추가하면 역할을 전달받을 수 있는 서비스도 제한할 수 있다.
역할의 신뢰 정책은 가능하면 하나의 서비스 주체만 신뢰하도록 좁힌다. 서비스 간 또는 계정 간 사용에는 aws:SourceArn과 aws:SourceAccount 같은 조건을 사용해 혼동된 대리인(confused deputy) 문제를 막을 수 있다. AWS Organizations에서는 서비스 제어 정책(SCP)으로 플랫폼 자동화 역할을 제외한 주체가 관리자 역할을 전달하지 못하도록 제한할 수 있다. 개발자가 직접 역할을 만들 수 있는 계정에서는 권한 경계(permission boundary)를 함께 적용해 새 역할의 권한이 경계를 넘지 않도록 할 수 있다.
배포 파이프라인이나 Terraform 실행 주체에는 배포 대상 애플리케이션의 워크로드 역할만 전달하도록 하고, 그 역할 자체의 권한까지 부여할 필요는 없다. 위험을 찾을 때는 개별 정책 문장만 보지 말고 주체, 역할, 서비스 간 권한 관계를 함께 살펴야 한다. Roszig은 IAM Access Analyzer로 와일드카드와 사용되지 않는 권한을 확인하고, CloudTrail에서 권한이 강한 역할 ARN이 요청 매개변수에 나타나는지 경고하도록 하는 방법을 제시한다.
자세한 내용은 AWS의 PassRole 문서, AWS의 최소 권한 모범 사례, 혼동된 대리인 문제 안내, AWS 보안 감사를 참고할 수 있다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요