AWS Permission Boundaries for Dummies

AWS 권한 경계(permission boundary)는 혼란스럽습니다. 저 역시 혼란스러웠고 이해하는 데 몇 년이 걸렸기에 그렇게 말씀드릴 수 있습니다. 또한 Corey Quinn도 그렇게 말했고, 누군가 이를 덜 혼란스럽게 설명해 달라고 요청했다는 점에서도 그렇습니다.

아마 실패하겠지만, 한번 해 보겠습니다.

요약: 일반 IAM 정책은 무언가를 할 수 있게 해 주기도 하고, 하지 못하게 막을 수도 있습니다. 권한 경계는 무언가를 하지 못하게 막기만 합니다. 주로 누군가에게 일부 IAM 업무를 맡기되, (본인이나 타인의) 권한을 상승시킬 수 있을 만큼의 IAM 업무는 맡기지 않도록 할 때 사용합니다. 일종의 안전장치입니다. 어떤 계정에서 누군가에게 IAM 관리를 맡기면서 권한 상승은 허용하고 싶지 않다면, 거의 항상 권한 경계가 필요합니다!

공식 AWS 문서에는 많은 세부 정보가 담겨 있지만, 여전히 다소 혼란스럽습니다. 이 글은 (한 가지 예외를 제외하면) 정책 작성의 세부 사항을 다루기보다는, 개념과 그것이 존재하는 이유를 이해하는 데 도움을 드리기 위한 것입니다.

바보 말고 초등학생이라 생각하고 다시 설명해 주세요

그렇게 원하신다면, 해 보겠습니다.

IAM 권한 경계가 등장하기 전에는, 누군가에게 자기 리소스의 IAM 권한을 관리하도록 허용하면서도 EC2 인스턴스나… 본인에게 과도한 권한을 부여해 보안 문제를 일으키지 않도록 하는 일이 정말 어려웠습니다. 특히 IAM 정책을 직접 작성하고 할당하도록 허용하려 할 때 문제가 되었습니다. 이것이 바로 위임 관리의 문제입니다. “IAM과 관련된 일부 업무는 관리하게 하되, 특정 업무는 못 하게 한다”는 것입니다.

이는 매우 흔한 시나리오입니다. 개발자는 애플리케이션 스택에서 인스턴스, lambda 함수, 컨테이너 작업을 위한 역할을 만들고 그 역할에 권한을 할당하는 일이 잦습니다. 인스턴스가 S3 버킷에서 데이터를 읽도록 허용하는 것처럼 단순한 일일 수도 있습니다. 그런데 보안 관점에서 보면 이는 다루기 까다롭습니다.

• 개발자가 직접 정책을 작성하게 하면 *.* 같은 과도한 권한을 추가할 수 있습니다.
• 개발자가 정책을 할당하게 하면 권한이 지나치게 많은 기존 정책을 연결할 수 있습니다.
• 개발자가 새 역할을 만들고 정책까지 할당하도록 허용하면… 동일한 문제가 발생합니다.

물론 보안 담당자나 상위 관리자가 이 모든 것을 처리하도록 할 수도 있지만, 그것은 비효율적입니다. 권한 경계를 사용하면 IAM 관리자를 두 단계로 둘 수 있습니다. 전반적인 보안 책임을 지는 상위 관리자와, 일상적인 업무를 처리하는 하위 관리자입니다.

권한 경계는 사람이나 대상이 가질 수 있는 최대 권한을 명시한 IAM 정책일 뿐입니다. 해당 정책을 연결해 두면, 그 대상을 관리하는 개발자는 경계에서 허용한 것보다 더 많은 권한을 절대 부여할 수 없습니다. 나아가 개발자가 새 역할과 사용자를 생성하고 권한을 할당하도록 허용하되, 생성하는 모든 것에 그 권한 경계를 적용하도록 요구할 수 있습니다. 따라서 개발자는 원하는 범위를 넘는 권한을 가진 무언가를 생성하거나 변경할 수 없습니다.

초등학생용 설명 같지는 않은데, 예를 들어 주시겠습니까

Alice는 어느 AWS 조직의 최상위 관리자입니다. 수백 개의 계정을 감독해야 하며, 각 계정에는 실제 애플리케이션 구축을 담당하는 자체 로컬 관리자와 개발자가 있습니다.

Bob은 그런 로컬 개발자 중 한 명입니다. Bob은 새 애플리케이션을 구축하고 있으며, 자신의 앱에 무엇이 필요한지 알고 있으므로 직접 역할과 정책을 만드는 편이 더 효율적입니다.

Alice는 Bob이 자신의 애플리케이션 일부에 대한 IAM을 관리하도록 허용하기로 합니다. 구체적으로는 다음과 같습니다.

• Bob은 자신의 인스턴스와 lambda 함수에 필요한 권한을 담은 새 IAM 정책을 작성하고 할당할 수 있습니다.
• 해당 구성 요소가 절대 접근해서는 안 되는 다른 AWS 서비스들이 사용 중입니다. 따라서 Service Control Policy로 그냥 차단할 수는 없습니다. 그렇게 하면 해당 서비스를 사용해도 되는 구성 요소까지 동작하지 않게 됩니다.
• Bob은 자신에게 새 정책을 할당할 수 없습니다.

전형적인 위임 관리 사례입니다. Bob은 IAM의 일부만 관리하도록 허용됩니다. 바로 이럴 때 권한 경계를 사용합니다.

• Alice는 Bob의 인스턴스와 lambda 함수가 통신할 수 있는 AWS 서비스(예: S3, SNS, SQS)에 대한 권한을 허용하는 권한 경계 “A”를 생성합니다.
• Alice는 Bob이 IAM 역할과 정책을 생성하고 할당할 수는 있지만 자기 자신에게는 할당할 수 없도록 하는 권한 경계 “B”를 생성합니다.
• Alice는 Bob에게 새 역할과 정책을 생성하고 할당할 수 있는 IAM 권한을 부여하되, 모든 새 역할에는 “A” 권한 경계가 적용되어야 한다고 요구합니다. 이는 해당 인스턴스와 lambda 함수가 경계에 정의된 것보다 많은 권한을 절대 가질 수 없으며, 더 적게는 가질 수 있음을 의미합니다.
• Alice는 Bob이 자기 자신에게 권한을 할당하지 못하도록 권한 경계 “B”를 Bob에게 적용합니다. 이제 Bob은 “A”를 적용한 상태로 배포해야 한다는 요건을 해제할 수 없습니다.

물론 이 문제에 접근하는 방법은 여러 가지가 있습니다. 다만 요약하자면, 어떤 계정에서 누군가에게 일부 IAM 관리를 맡기되 지나치게 많은 권한은 주고 싶지 않다면 권한 경계가 필요할 가능성이 높습니다.

여기서 Service Control Policy가 통하지 않는 이유를 다시 설명해 주세요

때로는 SCP가 통할 수도 있지만, SCP는 Organization에 속해 있어야만 사용할 수 있는 반면 권한 경계는 어떤 계정에서도 동작합니다. 또한 SCP는 어떤 API 호출을 할 수 있는지(따라서 어떤 AWS 서비스를 사용할 수 있는지)를 제한하는 데는 매우 유용하지만, 이런 수준의 세분성과 조건 처리를 위해 만들어진 것은 아닙니다.

위의 예를 생각해 보십시오. Alice는 계정 내 서비스에 대한 접근은 허용하되 Bob이 생성한 리소스로부터의 접근은 허용하지 않기 위해 리소스 식별자를 알아야 할 수도 있습니다. 이를 처리할 방법(예: 리소스 경로)이 있기는 하지만, 권한 경계 예시보다 결코 단순하지 않으며 지원되는 조건 키에 따라 항상 동작하지도 않습니다.

제 사고 대응 교육 환경에서는 계정 내 관리자 사용자(수강생)가 제 Organizations 수준 접근 권한을 훼손하거나 몇 가지 다른 작업을 하지 못하도록 SCP를 사용합니다. 하지만 이는 제가 그들에게 IAM 전체 권한을 부여했고, 그들이 이미 그러한 최상위 관리자이기 때문에 가능한 것입니다. 만약 그들이 과도한 권한을 가진 리소스를 생성하지 못하도록 제한하려면, 권한 경계를 사용하거나 미리 만들어 둔 특정 정책만 할당하도록 제한하는 SCP가 필요할 것입니다.

그냥 Deny 정책을 쓰면 안 되나요

그렇지 않습니다. 권한 경계가 존재하기 전에 그 방법을 시도해 보았는데, 복잡성은 차치하더라도 허점이 너무 많았습니다.

간단한 예를 하나만 더 들어 주시겠습니까

물론입니다. 저희가 직접 사용하는 사례를 소개합니다.

일부 사용자는 저희가 자신의 계정에서 IAM을 변경하도록 허용합니다. 이를 위해 교차 계정 역할을 사용합니다. 사용자가 해당 역할을 배포할 때, 저희가 스스로의 권한을 변경할 수 없도록 하는 권한 경계를 적용합니다. 이로써 권한 상승을 방지합니다.

이해한 것 같은데, 이 IAM 정책들은 서로 어떻게 작용합니까

정책 로직 평가에 관한 AWS 문서를 확인해 보시기 바랍니다. 다만 제 요약 정리는 다음과 같습니다.

• Service Control Policy는 계정 내에서 누구든 할 수 있는 작업을 제한합니다(예: 서비스를 켜고 끌 수 있음).
• IAM 권한 정책은 사용자와 역할이 계정 내에서 작업을 수행하도록 허용합니다.
• IAM 리소스 정책은 사용자와 역할이 해당 정책이 연결된 리소스와 상호작용하도록 허용합니다.
• 권한 경계는 사용자나 역할이 가질 수 있는 최대 권한을 정합니다. 무언가를 할 수 있게 허용하지는 않지만, 하지 못하게 막을 수는 있습니다.

이 정책들은 모두 함께 작동합니다. 어떤 작업을 수행하려면 스택 어딘가에 그 작업을 허용하는 권한이 있어야 하고, 어디에도 그 작업을 막는 거부 정책이 없어야 합니다. 단 하나의 Deny라도 있으면 위치와 관계없이 모든 Allow보다 우선합니다.

권한 경계를 언제 사용해야 하는지 다시 알려 주세요

어떤 계정에서 누군가에게 IAM의 일부를 관리하도록 허용하되 그 범위를 제한하고 싶을 때, 권한 경계를 떠올리셔야 합니다.

저희의 새로운 FireMon Authorization Control과 같은 고급 IAM 도구를 사용하는 경우에도, 특히 민감도가 높은 계정에서는 여전히 권한 경계가 필요할 수 있습니다.

포함하겠다고 말씀드린 그 하나의 예시는 무엇인가

권한 경계(permission boundary)는 특정 작업을 수행하지 못하도록 막기 위한 것이지만, 여전히 모든 허용 권한을 명시해야 합니다. 다시 말해, 해당 사용자/역할이 하지 않기를 원하는 한 가지 작업을 차단하기 위해 DENY 문으로 권한 경계를 작성하더라도, ALLOW * 문이 함께 있어야 하며 그렇지 않으면 해당 사용자/역할은 아무 작업도 할 수 없습니다.

이 부분이 처음에 저를 헷갈리게 했던 지점입니다. Amazon의 설명을 잘못 읽고 권한 경계만으로 작업을 차단할 수 있다고 생각했기 때문입니다. 차단할 수는 있지만, 오늘은 다루지 않으려는 리소스 정책 사용 사례를 제외하면 권한 경계에는 허용하려는 모든 항목도 함께 포함되어야 합니다. 권한 경계에서 한 가지를 DENY하고 일반 IAM 권한 정책에서 다른 항목을 ALLOW하는 방식으로는 동작하지 않습니다. 권한 경계에도 ALLOW 문이 있어야 합니다(그리고 네, 저는 편법으로 여기서 때때로 ALLOW *를 사용합니다).

여전히 헷갈립니다

저에게 이메일을 보내 주십시오. 정말로, 이 내용은 충분히 헷갈릴 만합니다.