SCP가 IAM 권한과 결합하는 방법

조직의 액세스는 두 계층으로 제어됩니다. 하나는 AWS Organizations가 설정하는 SCP의 상한이고, 다른 하나는 계정 내에서 부여되는 IAM 권한입니다. 두 계층이 결합되는 방식을 이해하는 것은 거버넌스 영역에서 가장 자주 테스트되는 개념 중 하나입니다. 결과가 두 계층의 일치 여부에 따라 달라지기 때문입니다.

규칙은 간단하지만 엄격합니다. 작업은 적용되는 SCP와 계정의 IAM 정책 모두에서 허용될 때만 허용됩니다. 유효 권한은 두 권한의 교집합입니다. 일치하는 IAM 허용이 없는 SCP는 아무 권한도 부여하지 않으며, SCP에 의해 차단된 IAM 허용도 아무 권한을 부여하지 않습니다.

SCP가 작업을 허용하지만 이를 부여하는 IAM 정책이 없다면, IAM의 암시적 거부로 인해 결과는 거부됩니다. SCP는 작업을 가능하게 만들었을 뿐이며, 실제로 권한을 부여하려면 여전히 IAM이 필요합니다. 많은 학습자가 SCP가 권한 부여가 아니라 상한이라는 점을 잊습니다.

반대로 IAM 정책이 작업을 허용하지만 SCP가 이를 거부하면 결과는 거부됩니다. IAM이 얼마나 광범위하게 허용하더라도 SCP의 거부가 계정의 상한을 설정합니다. 이를 통해 조직은 로컬 관리자가 재정의할 수 없는 강력한 제한을 적용할 수 있습니다.

SCP와 IAM 정책 모두 작업을 허용하고 어디에도 명시적 거부가 없을 때만 요청이 허용됩니다. 이러한 교집합 논리는 권한 경계의 작동 방식과 유사하며, 두 가지가 동시에 적용되어 권한을 더욱 좁힐 수도 있습니다.

완전히 거버넌스가 적용된 환경에서는 여러 상한이 겹쳐 적용됩니다. SCP(계정 수준), 권한 경계(자격 증명 수준), 모든 세션 정책(세션 수준), 그리고 자격 증명 정책(권한 부여)이 이에 해당합니다. 유효 권한은 모든 상한의 교집합에 권한 부여를 더한 뒤, 명시적 거부를 제외한 결과입니다.

IAM 정책이 s3:* 및 ec2:*를 부여하고, 권한 경계는 s3:*만 허용하며, SCP는 s3:GetObject만 허용한다고 가정해 보겠습니다. 유효 권한은 세 계층의 교집합인 s3:GetObject뿐입니다. 각 상한이 권한 범위를 계속 줄여 나갑니다.

모든 계층에서 정책, SCP, 경계, 세션, 자격 증명 또는 리소스 중 어느 하나에 명시적 거부가 있으면 작업이 즉시 차단됩니다. 어떤 허용 조합도 이를 무시할 수 없습니다. 시나리오를 분석할 때는 먼저 명시적 거부가 있는지 확인하십시오. 발견되면 답은 거부입니다.

리소스 기반 정책은 자격 증명 정책과 독립적으로 동일 계정 액세스를 부여할 수 있지만, SCP는 여전히 보안 주체 계정의 권한 상한을 설정합니다. 계정 간 액세스에서는 양쪽 계정의 제어와 양쪽의 정책이 모두 적용됩니다. 교집합 규칙의 범위는 넓어지지만 핵심 원칙은 같습니다. 적용되는 모든 상한에서 허용되어야 합니다.

조직에서 예상치 못하게 액세스가 실패하면 바깥쪽으로 하나씩 확인하십시오. 먼저 자격 증명 정책이 작업을 허용하는지 확인하고, 그다음 권한 경계, 계정과 모든 상위 OU에 적용된 SCP, 세션 정책을 차례로 확인한 후, 마지막으로 모든 계층에서 명시적 거부를 검색하십시오. 작업을 포함하지 않는 첫 번째 상한이나 거부가 원인입니다.

SCP와 IAM은 교집합으로 결합됩니다. 작업에는 두 정책 모두의 허용과 모든 경계 및 세션 상한이 필요하며, 어디에도 명시적 거부가 없어야 합니다. SCP와 경계는 권한을 제한할 뿐이고, IAM 정책은 권한을 부여합니다. 작업을 허용하려면 모든 상한이 작업을 허용해야 하며, 하나 이상의 권한 부여도 있어야 합니다.

결합 논리를 테스트해 보십시오.

SCP와 IAM은 교집합으로 결합됩니다. 작업은 두 정책 모두가 허용하고, 모든 권한 경계 및 세션 정책 상한이 허용하며, 어디에도 명시적 거부가 없을 때만 허용됩니다. SCP와 경계는 제한만 하고, IAM 정책은 권한을 부여합니다. 어떤 계층에서든 명시적 거부가 있으면 항상 모든 허용보다 우선합니다.