위급 상황에서 엔지니어의 프로덕션 접근 '권한 상승' 모델 4가지

최신 애플리케이션을 구축할 때 운영 이벤트 중의 접근 권한을 관리하는 일은 까다롭다. 보안 모범 사례에 명시된 바에 따르면 엔지니어(개발자와 운영 엔지니어)는 프로덕션 애플리케이션과 그 인프라에 대한 접근 권한을 최소화해야 한다. 비즈니스 요건이나 업계 규정에 따라 프로덕션에 대한 접근을 엄격히 제한해야 할 때도 있다.
 

그러나 업계 또는 비즈니스 요건이 없더라도 ‘최소 권한 원칙’과 같은 보안 모범 사례에 따르면 긴급 운영 문제 관리 담당을 포함한 엔지니어는 프로덕션에 대한 접근 권한이 최소화돼야 한다. 문제는 당직 엔지니어가 프로덕션 애플리케이션 내 문제를 처리해야 할 때 추가 권한이 필요할 때다. 프로덕션 서버 재부팅과 같은 동작은 당직 엔지니어의 정상적인 권한 범위를 넘어서는 것인데, 비상사태에서는 필요할 때가 있다.

이럴 때 당직 엔지니어는 평소에 권한이 없는 활동을 비상사태 중에 수행하기 위해 추가 권한이 임시로 필요하고 이를 위해 ‘권한 상승(permission escalation)’ 동작을 실행한다. 그런데 권한 상승 자체가 보안 취약성이 되는 상황에서 어떻게 엔지니어가 자신의 권한을 높일 수 있을까? 당직 엔지니어에게 필요한 추가 권한을 부여하되 그로 인한 보안 취약성은 최소화할 수 있는 권한 상승 방법 4가지를 살펴보자. 각각 장단점이 있다.
 

BTG(유리 깨기)

BTG(Break the Glass) 모델에서는 당직 엔지니어가 비상 상황에서만 사용할 권한 상승을 시스템 프로세스로부터 요청할 수 있다. 요청이 들어오면 자동 시스템은 필요한 추가 권한을 부여하되 즉시 그 사실을 기록한 후 해당 경영진에게 알림을 보낸다. 따라서 엔지니어는 본인이 실제 비상사태 중에 ‘유리 깨기’만 할 수 있고 그 외의 동작은 나중에 열릴 사건 검토 회의 등에서 소명해야 함을 알고 있기 때문에 반드시 필요한 경우를 제외하고는 추가 권한을 요청할 가능성이 낮다.

이 모델은 프로덕션 환경에서 실행하기가 매우 쉽다. 또한, 엔지니어가 비상사태 시 유연하게 대처할 수 있다. 단, 검토 과정이 사전 과정이 아닌 사후 과정이다. 엔지니어의 권한 상승을 일으킨 사건을 경영진이 사후에나 검토할 수 있다는 의미다. 예를 들어 불만을 품은 엔지니어가 BTG를 요청해 얻은 권한으로 비도덕적인 활동을 벌인다고 해도 경영진은 그런 활동이 일어난 후에나 알 수 있다. 따라서, BTG 모델은 보안 수준이 중간 정도인 환경에는 매우 좋지만, 높은 수준의 보안이 필요하거나 직원이 나쁜 짓을 벌일 가능성을 원천 차단해야 할 경우에는 사용하기 곤란하다.
 

기록 상승

기록 상승(Logged escalation) 모델에서는 부적절한 접근이 없는지 감시할 목적으로 기록되는 특정 명령어가 있으며 엔지니어가 평소의 권한 수준을 넘는 특정 권한 활동을 수행하려면 이 명령어를 사용해야 한다. 예를 들어, 엔지니어가 보호된 개인 네트워크에 접근해야 할 경우 이런 접근 권한을 부여하는 서버인 ‘배스천 호스트(bastion host)’에 로그인할 수 있다. 배스천 호스트는 엔지니어가 수행하는 모든 활동을 기록해 사후 조사할 수 있도록 지원한다. 그래야 악성 행위자가 보호 네트워크에 들어와 부적절한 행동을 하는 일은 막되 합법적인 활동은 여전히 정상적으로 수행할 수 있다.

BTG 모델과 비슷하게 기록 상승 모델에서는 적절한 권한이 있는 엔지니어라면 누구나 비상사태 때만이 아니라 적절한 모든 목적을 위해 프로덕션 네트워크에 접근할 수 있다. 단, 모든 행동이 투명하게 공개되어 나중에 분석할 수 있는 ‘유리 집’ 환경 내에서만 접근 권한이 있다. BTG 모델의 장점을 많이 공유하는 반면 단점도 비슷하다. 즉, 경영진은 비도덕적인 행위를 사전에 방지할 방법이 전혀 없고 발생한 후에나 인지하게 된다.
 

2인 상승

2인 상승(Two-person escalation) 모델은 BTG 모델의 단점을 보완한 것이다. 독립적인 두 사람이 문제 해결에 협력 중이고 두 사람 모두 권한 상승을 재가하는 경우에 한해 BTG 상승이 허용된다. 그다음에는 정책에 따라 BTG 하에서 취하는 모든 동작을 양 당사자가 검토해야 하고 양 당사자는 수행되는 모든 상승 활동에 관여해야 한다.

불만을 품은 직원이 BTG 상승을 남발해 프로덕션에 피해를 입힐 수 있는 가능성을 대부분 차단해 주기 때문에 기본 BTG 모델에 비해 보안 수준이 크게 향상된다. 단, 두 명의 직원이 무슨 동작이든 선제적으로 수행하기 위해 협력해야 한다. 어떤 한 직원도 다른 한 직원을 공범으로 두지 않고서는 시스템에 피해를 입힐 수 없으므로 전반적으로 보안이 상당히 개선된다. 단, 한 엔지니어가 다른 엔지니어의 도움으로 2인 BTG 접근권을 획득한 후 멋대로 독점 접근권을 행사하면 곤란하다. 이러한 문제가 발생하면 2인 상승 모델의 목적이 무색해진다.
 

한정 범위 툴

최대한의 보안을 위해서는 한정 범위 툴(Limited-scope tools)이 가장 좋은 모델이다. 이 모델에서는 프로덕션 애플리케이션을 운영 관리하는 데 필요한 특정 활동을 수행하는 커스텀 툴을 만든다. 정상 능력 범위를 벗어나는 동작을 수행해야 할 경우, 해당 접근 권한 부여를 목적으로 미리 설계된 툴을 사용해 해당 동작을 호출한다.

예를 들면, 당직 엔지니어가 프로덕션 서버를 재부팅해야 하면 프로덕션 서버에 ‘루트’로 로그인한 후 서버를 재부팅하는 것이 보통이다. 이렇게 하려면 대부분의 프로덕션 환경에서 용인되지 않는 수준의 권한을 부여해야 한다. 그런데, 버튼만 누르면 프로덕션 서버 재부팅을 시작할 수 있게 해 주는 웹 콘솔이 있다고 하자. 운영 엔지니어는 보통은 상승 권한이 필요한 특정 동작이라도 정상 권한을 활용해 수행할 수 있다.

한정 범위 툴 모델의 장점은 사용자에게 정확히 필요한 기능만 부여한다는 점이다. 최소 권한의 원칙도 지키면서 운영자에게 필요한 구체적인 기능을 부여한다. 커스텀 툴은 누가 언제 툴을 사용하는지 추적하기 때문에 기록 상승 모델처럼 관련 활동을 추적해 나중에 사고 검토 시에 조사할 수 있는 장점도 있다.

반면 한정 범위 툴 모델의 단점은 일반적인 상승 모델을 제공하지 않고 사전에 상정한 구체적인 기능에 한해서만, 해당 동작을 허용할 목적으로 만들어진 툴을 사용해 접근 권한을 제공한다는 점이다. 상승 권한이 필요한 동작을 수행해야 하는데 이용 가능한 툴이 없다면 운영 엔지니어로서는 문제를 해결할 방법이 없다.

따라서, 한정 범위 툴은 전체적으로 가장 좋고 안전한 모델이지만 단독으로 사용되는 경우는 많지 않고 예기치 않은 권한이 필요할 때를 대비해 다른 모델과 함께 쓰인다. 단, 그 경우에는 이 한정 범위 툴 모델 고유의 보안 장점이 약화될 가능성이 있다.
 

어떤 모델이 가장 좋을까

지금까지 살펴본 4가지 방법은 모두 모범 사례지만 모든 기업에 공통적으로 쓸 수 있는 만능 모델은 없다. 실제로 현장에서는 여러 방법을 조합해 사용하는 경우가 보통이다. 해당 기업과 업계에 적절한 프로세스와 복잡성, 운영 감시 방법을 선택한다면 애플리케이션과 그 보안을 지나치게 약화시키지 않고도 권한 상승을 실행할 수 있다.

editor@itworld.co.kr