[AWS] IAM 권한 : 그룹 권한과 인라인 권한 차이 정리

 

다음과 같이 AppDevelopers 라는 사용자 그룹을 만들었다.

 

이 사용자 그룹에는 AmazonEC2ReadOnlyAccess 정책을 추가해준다.

이제 사용자를 만들어보자.

 

 

test-user-01 이름의 사용자를 만들어 해당 사용자를 이전에 만들어둔 AppDevelopers 그룹에 속하도록 설정한다.

 

 

사용자 권한을 비교하기 위해 AppDevelopers 그룹에 속하면서 AmazonS3FullAccess를 직접 연결한 사용자도 만들어준다.

 

 

 

이렇게 두 사용자를 만들었으면, S3 권한을 비교 및 분석해보도록 하자.

 

 

test-user-01 로 IAM 로그인 한 뒤, S3를 생성해보도록 하자.

 

이처럼 권한이 없어 생성할 수 없다는 오류 메세지가 뜬다.

 

 

 

 

---

 

실습 결과

• test-user-01은 그룹 정책(AppDevelopers)만 적용되어 있어 S3 생성 권한이 없었고, 실제로 S3를 생성하려고 하면 권한 부족 오류가 발생했다.
• 반면, 그룹 정책(AppDevelopers) + 직접 연결한 정책(AmazonS3FullAccess)이 적용된 사용자라면 S3를 문제없이 생성할 수 있었다.

 

 

이를 통해 확인할 수 있는 중요한 포인트는 다음과 같다.

• 그룹 정책만 있는 사용자는 해당 그룹에서 허용한 권한만 사용할 수 있다.
• 직접 연결된 정책(인라인 또는 관리형 정책)은 그룹 정책과 결합되어 권한이 확장될 수 있다.
• AWS는 권한을 평가할 때 항상 암시적 거부 → 그룹/사용자 정책 평가 → 명시적 거부 확인 순으로 처리한다.
  1. 암시적 거부: 기본적으로 아무 정책도 없으면 접근 불가다. 즉, IAM 사용자나 그룹에 명시적으로 허용 정책이 없으면 기본적으로 거부된다.
  2. 그룹/사용자 정책 평가
     : 사용자가 속한 그룹 정책과 사용자에게 직접 연결된 정책을 확인한다. 만약 이 정책 중 하나라도 Allow로 허용하면, 요청을 일시적으로 허용 후보로 판단한다.
  3. 명시적 거부
     : 정책에 Deny가 있으면 무조건 거부한다. 이는 Allow보다 우선순위가 높다.

 

위 절차에 따라 그룹에만 속한 사용자인 test-user-01은 S3 생성 권한이 암시적으로 거부된 권한이기 때문에 실제 S3를 생성하려고 할 때 오류가 발생하는 것이다. 반면, 그룹 + 직접 정책과 연결되어있는 사용자인 test-user-02는 S3 생성 권한을 직접 설정해주었기 때문에 해당 요청을 허용한 것이다.

 

따라서 권한 차이는 “그룹만 속한 사용자” vs “그룹 + 직접 정책” 구조적 차이로 나타난다.

 

이번 실습을 통해 IAM 권한 구조와 정책 우선순위, 적용 범위를 직접 경험하면서 이해할 수 있었다. 향후 사용자 및 그룹 권한을 설계할 때, 최소 권한 원칙(Least Privilege Principle)을 적용하는 것이 얼마나 중요한지도 체감할 수 있는 좋은 기회였다.