AuthN/AuthZ 갭이 갖는 의미

클라우드에서 "아이덴티티가 새로운 경계"라는 말은 이미 상식이 되었습니다. 발표 자료나 기사에 쉽게 넣을 수 있는 좋은 표현이지만, 이를 실행 가능한 지침으로 바꾸는 일은 조금 더 어렵습니다. 오늘은 제가 "AuthN/AuthZ 갭"이라고 부르는 클라우드 IAM의 한 가지 측면에만 집중하고자 합니다. 사실 이는 페더레이션을 사용할 때면 언제나 발생하는 문제이지만, 클라우드 관리 플레인은 항상 인터넷에 노출되어 있기 때문에 클라우드에서는 그 위험이 더 큽니다.

먼저 AuthN과 AuthZ에 대해 간단히 살펴보겠습니다.

• AuthN은 인증입니다. 자신이 특정 엔터티임을 증명하는 행위입니다. 평범한 사용자에게 이는 대개 사용자 이름, 비밀번호, 그리고 경우에 따라 MFA를 의미합니다.
• AuthZ는 인가입니다. 어떤 작업이 허용되는지 확인하는 행위입니다. IaaS 클라우드에서는 웹 콘솔/포털을 사용할 때조차 거의 항상 API 호출로 귀결됩니다.

인증과 인가는 서로 다른 작업이며, 흐름도 다릅니다. 웹사이트에 로그인할 때 우리는 인증을 수행하고, 이는 일반적으로 세션을 생성합니다. 무언가를 클릭할 때마다 자격 증명을 다시 입력할 필요는 없으며, 브라우저가 일정 기간 동안 유효한 토큰을 함께 전송할 뿐입니다. 반면 인가는 적절한 권한이 있는지 확인하기 위해 작업을 시도할 때마다 검사되는 것이 일반적입니다.

생각해 보면, 일단 세션 토큰을 획득하고 나면 코드에서 새로운 검사를 강제하지 않는 한 다시 확인되지 않습니다. 인증은 해당 세션 동안 유효하므로, 인가 범위 내에 있는 작업은 무엇이든 수행할 수 있습니다. 플랫폼/시스템에 따라 이러한 임시 자격 증명은 취소되거나 계정이 완전히 삭제된 후에도 계속 작동합니다. 이것이 바로 AuthN/AuthZ 갭입니다.

저는 클라우드 사고 대응을 가르칠 때 이 주제에 많은 시간을 할애합니다. 경험이 풍부한 보안 대응 담당자조차 그 의미를 항상 이해하고 있지는 않다는 것을 알게 되었기 때문입니다. 클라우드 자격 증명이 탈취된 경우를 생각해 보십시오. 자격 증명을 취소하거나 삭제하더라도, 공격자가 활성 세션을 열어 둔 상태라면 여전히 인가된 작업을 실행할 수 있습니다. 이는… 좋지 않은 상황입니다.

어떻게 해결할 수 있을까요?

해당 자격 증명을 어떻게 사용하고 있는지에 따라 다르지만, 가장 쉬운 방법은 대개 인가를 변경하는 것입니다. 엔터티에 거부 정책을 적용하거나 허용된 작업을 제거하기만 하면 됩니다. 공격자가 수행하는 모든 API 호출마다 이 정책이 평가되기 때문입니다. 가장 간단한 방법이기는 하지만, 실행 중인 작업을 중단시킬 수 있으므로 항상 최선은 아닙니다(탈취된 자격 증명이 항상 사용자에게만 연결된 것은 아닙니다). 클라우드 제공업체의 지원 범위에 따라 다음과 같은 다른 방법도 있습니다.

• API 호출의 출발지 IP를 제한하는 조건을 추가합니다.
• 특정 날짜/시간 이전에 생성된 모든 세션을 거부합니다.

이 문제는 클라우드 제공업체 내부에서보다 클라우드 제공업체로 페더레이션할 때 마주칠 가능성이 더 높습니다. 방금 AWS에서 테스트를 해 보았는데, IAM 사용자를 삭제한 후 열려 있던 세션의 액세스 권한이 꽤 빠르게 사라졌습니다. 그러나 외부 아이덴티티 제공업체에서 페더레이션해 들어오는 경우에는 반드시 그렇지 않으며, AWS 내부에서도 일부 서비스는 활성 세션 중에 자격 증명을 다시 확인하지 않습니다(예: 액세스를 허용하던 역할을 삭제한 후에도 제 Session Manager 세션은 약 15분 이상 유지되었습니다).

이는 알려지지 않은 거대한 취약점이 아니라, 클라우드 보안 통제와 사고 대응 플레이북을 개발할 때 염두에 두어야 할 사항입니다. 자격 증명의 종류에 따라 수명이 다르며, 이는 클라우드 제공업체 간에도, 동일한 제공업체 내에서도 다릅니다. 사용하는 아이덴티티 제공업체와 자격 증명을 취소하려는 지점 또한 변수로 작용합니다. 예를 들어 Active Directory에 있는 사용자를 AWS로 페더레이션하고, 그 사용자가 AWS에서 역할을 맡아 해당 역할의 세션 자격 증명을 가져왔다면, AD에서 사용자를 제한하더라도 맡은 역할의 자격 증명을 취소하거나 제한해야 합니다. AWS는 세션이 종료되어 인증을 다시 검증하기 전까지는 AD에서의 사용자 세션이 더 이상 유효하지 않다는 사실을 전혀 알지 못합니다.

내부적으로 저희는 자체 Authorization Control 도구를 사용하는 방식으로 전환했습니다. 이 도구는 개발자의 속도를 늦출 수 있는 마찰을 더하지 않으면서 ChatOps를 통해 제한이 적용된 세션 생성을 지원합니다. 아직 정식 출시되지는 않았으나, 얼리 액세스 기간 중에 직접 사용해 보고 싶으시다면 rich.mogull@firemon.com으로 직접 이메일을 보내 주십시오.