DevSecOps 파이프라인에서 권한 상승을 확인하는 법

전제조건
- CI/CD 도구(Jenkins, GitLab CI 등)와 해당 파이프라인에 접근 가능한 계정
- 최소 권한 원칙이 적용된 IAM 정책이 존재할 것
- 테스트용 리포지터리와 간단한 스크립트가 준비돼 있어야 함

단계 1 – 권한 검증용 스크립트 배포
1. 리포지터리 루트에 `check_priv.sh` 파일을 만든다.
2. 내용은 현재 실행 유저의 IAM 역할을 출력하고, `aws sts get-caller-identity` 를 호출하도록 한다.
3. 파일에 실행 권한(`chmod +x`)을 부여한다.

단계 2 – 파이프라인에 스크립트 삽입
1. CI 설정 파일(`.gitlab-ci.yml` 혹은 `Jenkinsfile`)에 아래와 같은 단계 추가:
```
stage: test
script:
- ./check_priv.sh
```
2. 커밋하고 파이프라인을 트리거한다.

단계 3 – 결과 분석
- 파이프라인 로그에 `AssumedRoleUser` 혹은 `Account` 정보가 출력되면 현재 잡이 어떤 권한으로 실행되는지 확인 가능.
- 기대값: 빌드 전용 읽기 전용 역할이 표시되어야 함.

성공/실패 판단 기준
- 성공: 로그에 최소 권한(예: `arn:aws:iam::123456789012:role/ci-readonly`)이 명시되고, 해당 역할로는 S3 버킷 쓰기나 IAM 정책 수정이 불가능함을 `aws s3 cp` 혹은 `aws iam create-role` 명령으로 검증했을 때 AccessDenied 오류가 발생한다.
- 실패: 로그에 예상보다 높은 권한(예: `AdministratorAccess`)이 표시되고, 추가 명령이 정상 실행된다면 권한 상승 위험이 존재한다.

재현해봤더니 파이프라인이 기본적으로 `AdministratorAccess` 역할을 상속받고 있었다. 권한을 제한하는 IAM 정책을 별도 적용하고, `assume-role` 옵션을 명시적으로 지정한 뒤 다시 검증했을 때 정상적으로 최소 권한만 부여되는 것을 확인했다. 이렇게 단계별 로그와 명령 결과를 교차 검증하면 DevSecOps 환경에서 권한 상승을 조기에 탐지하고 차단할 수 있다.