MFA만으로 충분하지 않을 때

클라우드 보안의 제1원칙은 "항상 MFA를 사용하라"입니다. 왜일까요? 퍼블릭 클라우드 컴퓨팅으로 이전하면 사실상 모든 관리 인터페이스를 단일 포털이나 API로 통합한 다음… 사용자 이름, 비밀번호, 그리고 (경우에 따라) MFA로만 보호한 채 인터넷에 올려두는 셈이기 때문입니다. 페더레이션을 사용하는 경우에도 마찬가지입니다.

그러나 여러 대형 침해 사고에서 드러났듯이, Uber 사례를 포함해 MFA조차 항상 충분하지는 않습니다.

이는 클라우드와 기존 인프라 사이에서 반드시 이해해야 할 가장 중요한 차이 중 하나이며, "아이덴티티가 새로운 경계"라는 말이 계속 들리는 이유이기도 합니다. 클라우드 이전에는 프라이빗 네트워크 내부에서(또는 VPN, 점프 박스와 같은 통제된 접근 지점을 통해) 데이터센터를 관리했습니다. 클라우드에서는 이 모든 것이 기본적으로 인터넷에 노출되며, 특히 원격 근무 직원과 관리자를 지원하는 경우가 많아진 지금은 이를 통제하기가 어렵습니다.

MFA는 사용자/관리자 인증을 보호하는 효과적인 방법입니다. 비교적 안전한 수준(메시지 기반 MFA)부터 매우 안전한 수준(하드웨어 키)까지 다양한 선택지가 있습니다. 하지만 MFA에도 문제가 있습니다. 사용자가 지속적인 권한으로 지속적인 접근 권한을 보유한다는 점입니다. 사용자에게 역할을 부여하면, 인증 이후 언제든 해당 권한을 사용할 수 있습니다. 공격자는 이를 알고 있으며 인증된 접근 권한을 확보하기 위한 다양한 기법을 개발해 왔습니다. 공격자는 다음과 같이 행동합니다.

• 특히 MFA가 사용되지 않는 경우, 정적 자격 증명을 악용합니다.
• 일부 MFA를 우회합니다. 예를 들어 SIM 스와핑으로 휴대폰에 전송되는 문자 메시지를 가로챕니다.
• 관리자를 사회공학적으로 속여 MFA를 비활성화하게 하거나 공격자가 통제하는 기기로 재설정하게 합니다.
• 사용자를 사회공학적으로 속여 MFA 코드를 가로챕니다.
• 사용자가 이미 인증을 마친 뒤 해당 시스템에서 세션 자격 증명을 탈취하고, 이를 공격자가 통제하는 시스템에서 사용합니다.

공격자는 일단 접근 권한을 확보하면 권한을 탐색하기 시작하고, 결국 이를 악의적인 활동에 사용합니다.

최소 권한은 허상입니다

핵심 문제는 특정 시점에 수행해야 하는 작업이 아니라, 앞으로 수행할 수도 있는 작업을 기준으로 권한을 부여한다는 점입니다를 포함해 MFA조차 항상 충분하지는 않습니다. 사용자, 특히 관리자는 가능한 모든 작업에 대한 최대 권한 집합을 보유합니다. 세상의 모든 보안 표준은 IAM이 기본 거부와 최소 권한을 따라야 한다고 말하지만, 이는 어느 정도 허상입니다. "최소 권한" 집합이 언젠가 필요할 최대 권한 집합으로 정의되기 때문입니다. 항상 필요한 권한이 아니라 말입니다를 포함해 MFA조차 항상 충분하지는 않습니다.

사용자가 역할을 전환하고 세션마다 다른 권한을 사용하도록 허용하는 경우에도, 사용자는 사실상 언제든 그 역할에 접근할 수 있습니다. 실제로 최소 권한은 사용자 단위뿐 아니라 시간 단위로도 제한되어야 합니다. 전통적으로 우리는 역할을 할당하는 방식으로 권한을 관리해 왔고, 역할은 특정 범위에서 권한을 갖습니다. "귀하는 이 5개 계정에서는 관리자이고 나머지 98개 계정에서는 일반 사용자입니다"와 같은 식입니다. 심지어 한 사용자에게 여러 역할을 할당하는 경우도 많으며, 이때 권한이 합쳐지거나 사용자가 작업에 따라 역할을 바꿔 가며 사용하게 됩니다.

만약 지속적인 권한을 없앤다면 공격자의 활동이 얼마나 더 어려워질지 생각해 보십시오. 사용자가 인증 후 모든 권한에 접근하는 대신, 매우 제한된 권한만으로 접근하고 잠재적으로 위험한 작업을 하려면 권한을 상승시켜야 하도록 하는 것입니다.

동적 권한 부여로 보안 강화하기

MFA나 그 밖의 인증 계층 보안을 없애자는 것이 아닙니다. 이러한 수단은 여전히 매우 중요하지만, 때로는 충분하지 않습니다. 인터넷 노출이 본질적으로 더 큰 클라우드 보안에서는 특히 그렇습니다. 다만 클라우드에는 장점도 있으며, 여기에는 세션 기반 페더레이션과 (개별 API 호출 수준까지 내려가는) 세분화된 권한 부여가 포함됩니다.

언젠가 필요할 수 있는 모든 권한에 대한 지속적인 접근 권한을 사용자에게 부여하는 대신, 더 제한된 접근 권한을 제공하고 사용자가 상승된 권한을 요청하도록 합니다. 이는 새로운 개념이 아니며, 특권 사용자 관리 제품이 수년간 사용해 온 방식입니다. 그러나 이러한 제품은 프록시 세션이나 임시 비밀번호 교체와 같은 번거로운 기법에 여전히 의존하는 경우가 많았습니다. 클라우드는 네이티브 IAM 모델이 본질적으로 세션 기반이고 권한이 정책 문서(일반적으로 JSON으로 작성)에 정의되기 때문에 본래 더 유연합니다.

당사의 FireMon Authorization Control과 같은 도구가 바로 이렇게 작동합니다. 오픈 소스 사례로는 Netflix ConsoleMe를 살펴보십시오. 사용자는 필요할 때 접근 권한을 요청하고, 플랫폼은 정책을 통해 승인에 필요한 조건을 판단합니다. 관리자나 동료의 승인과 같은 조건이 충족되면, 사용자는 해당 세션 동안 역할을 사용할 권한을 부여받습니다. 플랫폼은 "요청이 이루어진 IP 주소에서만 이 세션을 허용"과 같은 조건을 삽입할 수도 있습니다. 이러한 요청은 일반적으로 대역 외로 이루어지며 승인에는 ChatOps 같은 별도 채널을 사용해, 특히 민감한 운영 환경 접근의 경우 의도적으로 눈에 띄는 프로세스가 되도록 합니다.

권한 부여 계층의 보안은 개발자와 사용자부터 보안 관리자에 이르기까지 모두의 업무를 실제로 더 수월하게 만듭니다. 잠재적으로 필요한 모든 권한을 미리 파악할 필요가 없습니다. 대신 사용자가 필요할 때 필요한 것을 요청합니다. 정책은 보안을 저해하지 않으면서 해당 접근 권한을 제공하는 가장 마찰이 적은 경로를 결정합니다. ChatOps 같은 도구를 사용하면 개발자가 새 계정에 대한 접근을 요청하고 수 초 내에 답변을 받을 수 있으며, 며칠 또는 몇 주가 걸릴 수 있는 티켓 시스템에 요청을 제출할 필요가 없습니다.

권한 부여 단계에 보안을 더함으로써 마찰과 관리 부담을 줄이는 동시에 자격 증명 탈취와 인증 침해의 영향을 축소할 수 있습니다.