IAM 정책 평가, 거부가 이기는 순서

거부가 하나라도 있으면 허용은 무효입니다

권한이 왜 막혔는지 알려면 평가 순서를 알아야 합니다. 원칙은 단순합니다. 기본은 거부이고, 허용이 있으면 허용되며, 명시적 거부가 있으면 다른 어떤 허용보다 먼저 이깁니다. 그래서 '관리자 권한을 줬는데도 막힌다'는 상황의 원인은 거의 명시적 거부입니다. 거부는 여러 곳에 있을 수 있습니다. 사용자에게 붙은 정책, 역할에 붙은 정책, 조직 수준의 제한, 자원 자체에 붙은 정책이 모두 평가에 참여합니다. 그래서 진단은 '허용을 더 주는 것'이 아니라 '어디에 거부가 있는지 찾는 것'이 되어야 합니다. 허용을 더 주면 범위만 넓어지고 증상은 그대로입니다.

확인 순서를 네 자리로 고정합니다

진단 시간을 줄이는 방법은 확인 순서를 고정하는 것입니다. 1단계로 요청한 주체가 사용자인지 역할인지 확인합니다. 둘은 붙은 정책이 다릅니다. 2단계로 그 주체에 직접 붙은 정책에서 해당 작업에 대한 거부를 찾습니다. 3단계로 조직 수준의 제한을 확인합니다. 여기서 막히면 개별 계정에서는 아무리 허용해도 통하지 않습니다. 4단계로 자원 쪽 정책을 봅니다. 저장소나 열쇠 관리처럼 자원에 정책을 붙일 수 있는 서비스에서는 이쪽이 원인인 경우가 많습니다. 네 자리를 순서대로 보면 추측 없이 원인에 도달합니다.

진단 시간을 금액으로 비교합니다

학습용 가정으로 계산합니다. 가정값은 권한 오류 문의가 월 6건이고, 순서를 모르는 상태에서는 건당 40분이 걸린다고 두겠습니다. 월 240분이고 내부 시간 비용을 시간당 30,000원으로 가정하면 120,000원입니다. 확인 순서를 고정하면 건당 10분으로 줄어 월 60분, 30,000원입니다. 중간 계산값인 절감액은 월 90,000원입니다. 최종 효과에는 잘못된 조치가 줄어드는 몫이 더해집니다. 순서 없이 진단하면 임시로 넓은 권한을 주고 끝내는 경우가 생기는데, 그 권한이 그대로 남아 다음 점검에서 축소 대상이 됩니다.

조건이 붙은 허용은 다르게 동작합니다

결론을 뒤집는 조건은 정책의 조건절입니다. 허용에 조건이 붙어 있으면 그 조건을 만족하지 않을 때 허용이 적용되지 않습니다. 접속 주소 범위, 다단계 인증 사용 여부, 특정 태그 존재 같은 조건이 자주 쓰입니다. 그래서 거부를 찾지 못했는데도 막힌다면 조건절을 확인합니다. 두 번째 조건은 권한 경계 설정입니다. 주체에 상한을 두는 설정이 있으면 허용된 범위 안에서만 동작하므로, 정책에는 허용이 있어도 상한 밖이면 막힙니다. 그래서 진단 문서에는 거부, 조건절, 권한 상한 세 항목을 점검 목록으로 적어 둡니다.

서버 운영 실행 전 점검표

• 기본 거부와 명시적 거부의 우선순위를 이해했다
• 주체·직접 정책·조직 제한·자원 정책 순서로 확인했다
• 거부가 없는데 막히면 조건절을 확인했다
• 권한 상한 설정의 존재를 점검했다