Organizations와 SCP, 허용하지 않고 한도만 정하는 정책
조직 정책이 허용해도 실제 권한이 생기지는 않아요. SCP가 정하는 상한과 IAM 권한, 관리 계정에 적용되지 않는 경계를 살펴봐요.
이 글의 목차천장이지 문이 아니다4
건물 임대차 계약서에 “이 층에서는 화기를 쓸 수 없다”는 조항이 있다고 해 볼게요. 이 조항은 입주자에게 무언가를 할 수 있게 해 주지 않아요. 할 수 있는 일의 바깥 경계를 그을 뿐이에요. 입주자가 실제로 무엇을 하려면 계약과 별개로 열쇠와 출입증을 받아야 해요.
계정이 하나에서 여럿으로 늘어나면 이 구분이 필요해져요. AWS Organizations는 계정 여럿을 한 조직으로 묶는 장치이고, 그 조직에 거는 서비스 제어 정책(SCP)은 계약서의 조항 쪽에 해당해요. 여기서 어긋나는 곳이 정확히 한 군데예요.
천장이지 문이 아니다
문서가 이 성격을 한 문장으로 못 박아 두었어요. SCP는 결코 권한을 부여하지 않으며, 조직 안의 사용자와 역할이 가질 수 있는 최대 권한을 지정하는 접근 통제라는 것이에요.
문서가 이 대목에서 가리키는 곳이 권한이 최종적으로 어떻게 결정되는지 정리한 IAM의 평가 논리예요. 여러 층의 정책이 겹칠 때 어느 한 층이라도 막으면 막힌다는 것이 요지예요.
같은 문서는 그 뒤에 실무에서 더 자주 부딪히는 문장을 덧붙여요. 사용자와 역할은 여전히 적절한 권한 정책으로 권한을 받아야 하고, 권한 정책이 하저도 없는 사용자는 SCP가 모든 서비스와 모든 작업을 허용하더라도 아무 접근 권한이 없다는 것이에요.
정책이 평가되는 방식도 앞 시리즈에서 본 원칙과 같아요. 문서는 SCP 평가가 기본 거부 모델을 따르며 명시적으로 허용되지 않은 권한은 거부된다고 적고, 그래서 SCP를 켜면 모든 서비스와 작업을 허용하는 기본 정책이 자동으로 붙는다고 설명해요. 열지 않기로 한 문을 기본값으로 두고 필요한 것만 여는 구조가 여기서도 반복돼요.
같은 문서에는 조직을 처음 만들 때의 치명적인 실수도 적혀 있어요. 최상위에서 허용 문장이 빠지면 조직 안의 모든 구성원 계정이 사실상 아무 작업도 하지 못하게 된다는 것이에요. 천장을 낮추는 정책이라 잘못 낮추면 바닥까지 닿아요.
그래서 여기서 나오는 실패가 두 방향이에요. 한쪽은 SCP만 만들어 두고 권한을 주지 않아 아무것도 안 되는 경우예요. 다른 한쪽은 반대로, 앞 시리즈에서 다룬 역할에 넉넉한 권한을 붙여 두고 SCP가 알아서 막아 줄 것이라 기대하는 경우예요. 둘 다 두 층을 한 층으로 본 결과예요.
IAM의 읽기 권한과 SCP의 제한을 각각 바꿔 보세요.
IAM 권한
권한 없음SCP 한도
읽기 허용 범위IAM 권한
권한 없음SCP 한도
읽기 명시적 거부IAM 권한
읽기 허용SCP 한도
읽기 허용 범위IAM 권한
읽기 허용SCP 한도
읽기 명시적 거부SCP가 허용해도 IAM 권한이 없으면 읽지 못해요. IAM 권한이 있어도 SCP가 명시적으로 거부하면 막혀요.
SCP 한도 안이어도 IAM 권한이 없어요. SCP는 읽기 권한을 새로 주지 않아요.
멤버 계정의 일반 IAM 주체이며 다른 거부 정책은 없는 예시예요. 관리 계정·서비스 연결 역할·리소스 정책은 다루지 않아요.
막히지 않는 자리가 있다
두 번째로 걸리는 곳은 적용 범위예요. 문서는 SCP가 구성원 계정에만 영향을 주며 관리 계정의 사용자와 역할에는 아무 영향이 없다고 적어요. 조직을 만든 계정에서 시험해 보고 “안 막히는데?”라고 결론 내리면 정확히 반대로 이해하게 돼요.
AWS도 이 성질을 전제로 관리 계정 운영 방침을 따로 안내해요. 관리 계정에서는 일상적인 작업을 하지 말고 조직 관리에만 쓰라는 것이 요지예요. 상한이 걸리지 않는 자리이므로 그 자리에서 일하지 않는 것으로 대신 막는 셈이에요.
빠지는 자리가 하나 더 있어요. 다른 AWS 서비스가 통합을 위해 쓰는 서비스 연결 역할은 SCP로 제한되지 않아요. 그래서 통제 범위를 그릴 때는 “조직 전체”가 아니라 “구성원 계정의 사용자와 역할”이라고 적어 두는 편이 사실에 가까워요.
이 성질은 앞 글에서 본 상태 저장 방화벽과 구조가 닮았어요. 규칙 자체보다 그 규칙이 어디에 적용되는지가 결과를 정해요. 규칙은 맞는데 적용 대상이 다르면 아무 일도 일어나지 않아요.
| 설정 | 실제 의미 | 확인할 점 |
|---|---|---|
| SCP가 허용 | 그 작업의 상한을 열어 둠 | 실제 권한은 별도 정책에서 받아야 함 |
| 권한 정책이 허용 | 해당 정책이 작업을 허용 | SCP와 다른 거부 조건도 평가됨 |
| 관리 계정에서 실행 | SCP의 제한 대상이 아님 | 구성원 계정에서 적용 범위 확인 |
세 번째 줄이 조직을 처음 만들 때 반드시 한 번은 밟는 자리예요.
무엇을 위에서 잠글 것인가
상한을 정한다는 발상이 값을 하는 지점은 “실수로도 못 하게” 만들고 싶은 일들이에요. 감사 기록을 끄는 일, 특정 지역에 자원을 만드는 일, 조직에서 계정을 빼내는 일 같은 것들은 정상적인 작업 중에 필요할 일이 거의 없고 벌어지면 되돌리기 어려워요.
앞 글에서 감사 기록이 사고 뒤에는 소급해서 만들 수 없다고 적었는데, 그 기록을 끄는 동작을 조직 차원에서 막아 두면 그 성질이 한 겹 더 단단해져요. 개별 계정의 관리자가 아무리 넓은 권한을 갖고 있어도 위에서 닫아 둔 것은 열 수 없기 때문이에요.
저는 왜 아직 안 썼나
제가 만드는 앱은 계정이 하나뿐이라 이 장치가 아직 필요하지 않아요. 그런데도 문서를 읽어 둔 이유가 있어요.
계정을 나눌지 고민한 적이 있었어요. 개발과 운영을 한 계정에서 굴리다 보면 실수로 운영 쪽을 건드릴 여지가 생기고, 그걸 사람의 주의력으로만 막고 있었기 때문이에요. 나눠 보려다가 계정 하나를 더 만드는 순간 청구와 권한과 기록이 전부 두 벌이 된다는 것을 알고 미뤘어요. 지금은 앞 글에서 정리한 역할 분리로 버티고 있고, 사람이 둘 이상이 되면 그때 나누기로 했어요.
제 경우에는 우선 역할을 나누는 쪽을 골랐어요. 하지만 혼자라도 개발과 운영을 더 강하게 분리해야 하면 계정 분리가 필요할 수 있겠죠. 사람 수를 기준으로 외우기보다, 어떤 실수가 어느 환경까지 닿아도 되는지부터 생각하는 편이 도움이 됐어요.