2019.01.09

기고 | 역할 기반 접근 관리를 구현하는 5단계

Robert C. Covington | CSO
RBAC은 조직에서 자신의 역할에 따라 사용자에게 시스템 접근 권한을 할당하는 개념이다. 모든 직원에게 동일한 시스템 접근 권한이 주어질 필요한 게 아니라는 점을 기억하는 것이 중요하다.
Credit: GettyImages

오늘날 사이버보안에서 목격하는 온갖 고도화된 공격 시나리오에 아랑곳없이, 여전히 사소한 것들 때문에 무너지는 사례가 계속되고 있다.   

2017년 버라이즌 데이터 침해 사건 조사 보고서(2017 Verizon Data Breach Investigations Report)에 따르면 81%의 해킹 관련 보안 침해는 훼손된 인증 정보와 연관이 있었다. 게다가, 2018년의 크라우드스트라이크 침입 서비스 사례 책자(Crowdstrike Intrusion Services Casebook 2018)에 나온 것처럼 사소한 실패가 시스템 전체에 영향을 줄 수 있다. 이 책자에서는 거대 다국적 의류 회사 이용자가 커피숍에 앉아 공공 네트워크에서 작업한 사례를 서술했다. 이 이용자의 인증 정보는 훼손되었고, 이는 회사 인프라 전체의 훼손으로 이어졌다. 

간단해 보이는 접근 관리가 왜 이렇게까지 어려운 것일까? 아마도 이는 그냥 겉으로만 단순해 보이기 때문일 것이다. 예를 들어, 직원 20명과 5대의 시스템을 가진 회사를 생각해보자. 각 시스템에 대해 어떤 이용자는 파일을 읽기만 하고, 어떤 사용자는 파일을 읽고 쓸 수 있으며, 어떤 사용자는 관리자 접근 권한을 갖고, 어떤 사용자는 접근 권한이 아예 없을 수 있다. 이런 소규모 환경에서도 접근 설정의 변수는 어마어마하다. 

게다가 일반 소기업에서 접근 권한 관리는 기껏해야 형식적이고, 심지어 일부 기업에서는 ‘하나로 통일된’ 경우도 있다. 이 단순한 문제는 사실 전혀 단순하지 않다. 그러나, 이를 제대로 하지 못하면 시스템을 적당히 안전하게 유지할 가능성조차 아주 희박해진다. 

이 문제에 대한 해법은 전혀 새롭지 않다. 이는 정보 보안이 그렇게 주목받지 않았던 1970년대까지 거슬러 올라간다. 이는 역할 기반 접근 관리(Role-Based Access Control, RBAC)라고 불린다. 미국 국립표준기술원(NIST)의 문서에 따르면 최초의 정식 RBAC 모델은 1992년에 제안되었다. 따라서 우리는 오랫동안 이 문제에 대해 위력적인 해법을 알고 있었던 것이다. 

RBAC는 무엇인가? 
RBAC는 조직 내 이용자의 역할에 따라 시스템 접근을 할당한다는 발상과 다르지 않다. 일정 인력의 시스템 요구 사항을 분석하고, 공통 직무 책임과 시스템 접근 요구 사항에 기초하여 이용자를 역할로 묶는다. 이들에게 할당된 역할을 기준으로 각자에게 접근을 엄격히 배정한다. 각 역할에 설정된 접근 요건을 엄격히 준수한다면 접근 관리는 훨씬 쉬워진다.  

그러므로 문제는 ‘오랜 전통의 달성 가능한 방법이 있는데도 접근 관리를 제대로 하지 못하는 이유는 무엇일까?’다. RBAC는 분명 오늘날의 대세가 되고 있다. 모든 중요 기준들, 예컨대 PCI DSS, HIPAA, 그램-리치-블라일리(Gramm-Leach-Bliley) 등이 이 방식을 어떤 형태로든 요구하기 때문이다. 

필자는 RBAC가 보다 빈번하게 쓰이지 않는 한 이유는 중소기업의 경우 직원이 회사에 들어올 때마다 이를 일시적으로 이행하는 것이 더 쉬워 보이기 때문이라는 생각이다. 다만 문제는 시스템이 몇 개만 돼도 변화의 여지가 많아 지속성을 상실한다는 점이다.  

역할 기반 접근 관리의 장점은 무엇인가? 
RBAC를 올바르게 이행한다면 접근 권한 할당은 체계적이고 반복 가능한 것이 된다. 나아가 이용자 권한을 감사하기가 훨씬 더 쉽고, 따라서 파악된 문제를 교정하는 것도 훨씬 더 용이하다.  

RBAC는 부담스럽게 들릴 수 있지만 실제로는 이행하기 쉬우며, 접근 권한 관리가 진행됨에 따라 더욱 쉬워지고 더욱 안전해진다. 

자신의 데이터가 침해될 수 있음을 유의하라.   

RBAC vs. ABAC vs. ACL 
RBAC에는 대안/변형이 있고, 대표적 사례는 아래와 같다: 

액세스 컨트롤 리스트(Access control lists, ACL) – ACL은 특정 객체, 예컨대 문서 등의 접근 권한을 일정 이용자 또는 이용자 그룹으로 정의하는 방법이다. 간단한 실례로서 ACL은 한 부서의 이용자가 문서를 변경할 수 있도록 허용하지만, 다른 부서의 이용자는 문서를 읽기만 할 수 있도록 허용하는 데 쓰일 수 있다. 

속성 기반 액세스 제어(Attribute-based access control, ABAC) – ABAC는 정책 기반 액세스 제어라고도 알려져 있으며 이용자 부서, 일중 시간, 접근 위치, 접근 유형 등 각종 속성을 이용해 이용자의 접근 요청을 허용할 것인지 결정한다. 

이러한 기법들은 RBAC의 기본 개념을 넘어서는 미시적 제어를 추가로 제공하지만, 또한 필수적 허가를 생성하고 유지하는 데 따른 노력이 크게 필요할 수 있다. RBAC는 일정 직위를 가진 이용자의 권한이 같은 역할을 하는 모든 다른 사람에게도 허여된다는 점에서 보다 단순화되고 관리하기 용이한 기법일 것이다. 한편 이들 기법은 제어를 강화하기 위해 결합되어 사용될 수 있다.  

RBAC 구현 
이쯤 되면 RBAC에 대한 관심이 보다 높아졌을 것이다. 그렇다면 이제 이를 구현하기 위한 간단한 5단계 접근법을 알아보자.  

1. 시스템 인벤토리를 작성한다 
이미 목록화한 것이 아니라면, 접근 제어를 해야 할 필요가 있는 자원을 파악한다. 예를 들어 이메일 시스템, 고객 데이터베이스, 계약 관리 시스템, 파일 서버상의 중요 폴더 등이다. 

2. 인력을 분석하고 역할을 생성한다 
직원을 공통적 접근 요건을 갖는 역할로 분류한다. 역할을 지나치게 많이 정의하려는 유혹을 자제하라. 최대한 단순하고 계층적으로 유지하라. 

예를 들어, 이메일, 인트라넷 사이트 등 어떤 직원에게든 필요한 액세스인 기본 이용자 역할을 설정할 수 있고, 또 다른 역할이라면 고객 데이터베이스로의 읽기/쓰기 접근 권한을 갖는 고객 서비스 직원이 있을 것이다. 그리고 고객 데이터베이스 관리자라면 고객 데이터베이스를 종합적으로 제어할 수 있을 것이다.  

3. 역할을 할당한다 
역할과 접근 권한을 정의했다면 각 직원이 어떤 역할에 속하는지 결정하고 이에 따라 접근 권한을 배정한다. 

4. 일회성 변경을 삼간다 
이례적 요구로 일시적으로 특정 직원에게 변경을 허용하는 일을 자제하라. 그렇게 되면 RBAC 시스템이 이내 엉망이 될 것이다. 필요 시 역할을 변경하고, 또는 정말 필요할 때에만 새 역할을 추가하라. 

5. 감사 
역할과, 이에 할당된 직원, 직원에게 할당된 접근을 정기적으로 검토한다. 어떤 역할에 특정 시스템으로의 불필요한 접근이 할당되었음을 발견하면 역할을 변경하고, 해당 역할 안의 모든 직원의 접근 수준을 조정한다. 

예를 들어, 의료 단체는 의료 기록으로의 접근을 제어하는 것에 관한 규제 준수 요구로 RABC를 이용해 진료 의사 유형에 따라 의료 기록으로의 접근을 정확히 정의한다. 의사는 자신이 관리하는 환자의 기록에 거의 무제한으로 접근할 수 있겠지만, 응대 직원이라면 예약을 관리할 기본적 연락 정보로 제한될 수 있을 것이다. 적절히 계층화된 역할들 내에 직원이 많이 있다면 RBAC는 HIPPA, 여타 규제에 준해 데이터 접근을 제어할 수 있는 효과적인 수단이다. 

RBAC를 설정하는 유용한 툴들이 있다. 예컨대 마이크로소프트 액티브 디렉토리는 시작점으로 활용할 수 있는 빌트-인 역할이 설정되어 있다. 그로부터 고유한 상황에 맞춰 확장해나갈 수 있을 것이다. 아울러 역할을 기준으로 권한 할당을 자동화하는 ID 관리 시스템도 이용할 수 있다. 

*Robert C. Covington은 중소기업 보안과 규제 컨설팅 업체인 ‘고투가이(Go To Guy)’의 설립자이자 정보보안과 규제 요구 관련 사업을 하는 togoCIO.com의 대표다. ciokr@idg.co.kr



2019.01.09

기고 | 역할 기반 접근 관리를 구현하는 5단계

Robert C. Covington | CSO
RBAC은 조직에서 자신의 역할에 따라 사용자에게 시스템 접근 권한을 할당하는 개념이다. 모든 직원에게 동일한 시스템 접근 권한이 주어질 필요한 게 아니라는 점을 기억하는 것이 중요하다.
Credit: GettyImages

오늘날 사이버보안에서 목격하는 온갖 고도화된 공격 시나리오에 아랑곳없이, 여전히 사소한 것들 때문에 무너지는 사례가 계속되고 있다.   

2017년 버라이즌 데이터 침해 사건 조사 보고서(2017 Verizon Data Breach Investigations Report)에 따르면 81%의 해킹 관련 보안 침해는 훼손된 인증 정보와 연관이 있었다. 게다가, 2018년의 크라우드스트라이크 침입 서비스 사례 책자(Crowdstrike Intrusion Services Casebook 2018)에 나온 것처럼 사소한 실패가 시스템 전체에 영향을 줄 수 있다. 이 책자에서는 거대 다국적 의류 회사 이용자가 커피숍에 앉아 공공 네트워크에서 작업한 사례를 서술했다. 이 이용자의 인증 정보는 훼손되었고, 이는 회사 인프라 전체의 훼손으로 이어졌다. 

간단해 보이는 접근 관리가 왜 이렇게까지 어려운 것일까? 아마도 이는 그냥 겉으로만 단순해 보이기 때문일 것이다. 예를 들어, 직원 20명과 5대의 시스템을 가진 회사를 생각해보자. 각 시스템에 대해 어떤 이용자는 파일을 읽기만 하고, 어떤 사용자는 파일을 읽고 쓸 수 있으며, 어떤 사용자는 관리자 접근 권한을 갖고, 어떤 사용자는 접근 권한이 아예 없을 수 있다. 이런 소규모 환경에서도 접근 설정의 변수는 어마어마하다. 

게다가 일반 소기업에서 접근 권한 관리는 기껏해야 형식적이고, 심지어 일부 기업에서는 ‘하나로 통일된’ 경우도 있다. 이 단순한 문제는 사실 전혀 단순하지 않다. 그러나, 이를 제대로 하지 못하면 시스템을 적당히 안전하게 유지할 가능성조차 아주 희박해진다. 

이 문제에 대한 해법은 전혀 새롭지 않다. 이는 정보 보안이 그렇게 주목받지 않았던 1970년대까지 거슬러 올라간다. 이는 역할 기반 접근 관리(Role-Based Access Control, RBAC)라고 불린다. 미국 국립표준기술원(NIST)의 문서에 따르면 최초의 정식 RBAC 모델은 1992년에 제안되었다. 따라서 우리는 오랫동안 이 문제에 대해 위력적인 해법을 알고 있었던 것이다. 

RBAC는 무엇인가? 
RBAC는 조직 내 이용자의 역할에 따라 시스템 접근을 할당한다는 발상과 다르지 않다. 일정 인력의 시스템 요구 사항을 분석하고, 공통 직무 책임과 시스템 접근 요구 사항에 기초하여 이용자를 역할로 묶는다. 이들에게 할당된 역할을 기준으로 각자에게 접근을 엄격히 배정한다. 각 역할에 설정된 접근 요건을 엄격히 준수한다면 접근 관리는 훨씬 쉬워진다.  

그러므로 문제는 ‘오랜 전통의 달성 가능한 방법이 있는데도 접근 관리를 제대로 하지 못하는 이유는 무엇일까?’다. RBAC는 분명 오늘날의 대세가 되고 있다. 모든 중요 기준들, 예컨대 PCI DSS, HIPAA, 그램-리치-블라일리(Gramm-Leach-Bliley) 등이 이 방식을 어떤 형태로든 요구하기 때문이다. 

필자는 RBAC가 보다 빈번하게 쓰이지 않는 한 이유는 중소기업의 경우 직원이 회사에 들어올 때마다 이를 일시적으로 이행하는 것이 더 쉬워 보이기 때문이라는 생각이다. 다만 문제는 시스템이 몇 개만 돼도 변화의 여지가 많아 지속성을 상실한다는 점이다.  

역할 기반 접근 관리의 장점은 무엇인가? 
RBAC를 올바르게 이행한다면 접근 권한 할당은 체계적이고 반복 가능한 것이 된다. 나아가 이용자 권한을 감사하기가 훨씬 더 쉽고, 따라서 파악된 문제를 교정하는 것도 훨씬 더 용이하다.  

RBAC는 부담스럽게 들릴 수 있지만 실제로는 이행하기 쉬우며, 접근 권한 관리가 진행됨에 따라 더욱 쉬워지고 더욱 안전해진다. 

자신의 데이터가 침해될 수 있음을 유의하라.   

RBAC vs. ABAC vs. ACL 
RBAC에는 대안/변형이 있고, 대표적 사례는 아래와 같다: 

액세스 컨트롤 리스트(Access control lists, ACL) – ACL은 특정 객체, 예컨대 문서 등의 접근 권한을 일정 이용자 또는 이용자 그룹으로 정의하는 방법이다. 간단한 실례로서 ACL은 한 부서의 이용자가 문서를 변경할 수 있도록 허용하지만, 다른 부서의 이용자는 문서를 읽기만 할 수 있도록 허용하는 데 쓰일 수 있다. 

속성 기반 액세스 제어(Attribute-based access control, ABAC) – ABAC는 정책 기반 액세스 제어라고도 알려져 있으며 이용자 부서, 일중 시간, 접근 위치, 접근 유형 등 각종 속성을 이용해 이용자의 접근 요청을 허용할 것인지 결정한다. 

이러한 기법들은 RBAC의 기본 개념을 넘어서는 미시적 제어를 추가로 제공하지만, 또한 필수적 허가를 생성하고 유지하는 데 따른 노력이 크게 필요할 수 있다. RBAC는 일정 직위를 가진 이용자의 권한이 같은 역할을 하는 모든 다른 사람에게도 허여된다는 점에서 보다 단순화되고 관리하기 용이한 기법일 것이다. 한편 이들 기법은 제어를 강화하기 위해 결합되어 사용될 수 있다.  

RBAC 구현 
이쯤 되면 RBAC에 대한 관심이 보다 높아졌을 것이다. 그렇다면 이제 이를 구현하기 위한 간단한 5단계 접근법을 알아보자.  

1. 시스템 인벤토리를 작성한다 
이미 목록화한 것이 아니라면, 접근 제어를 해야 할 필요가 있는 자원을 파악한다. 예를 들어 이메일 시스템, 고객 데이터베이스, 계약 관리 시스템, 파일 서버상의 중요 폴더 등이다. 

2. 인력을 분석하고 역할을 생성한다 
직원을 공통적 접근 요건을 갖는 역할로 분류한다. 역할을 지나치게 많이 정의하려는 유혹을 자제하라. 최대한 단순하고 계층적으로 유지하라. 

예를 들어, 이메일, 인트라넷 사이트 등 어떤 직원에게든 필요한 액세스인 기본 이용자 역할을 설정할 수 있고, 또 다른 역할이라면 고객 데이터베이스로의 읽기/쓰기 접근 권한을 갖는 고객 서비스 직원이 있을 것이다. 그리고 고객 데이터베이스 관리자라면 고객 데이터베이스를 종합적으로 제어할 수 있을 것이다.  

3. 역할을 할당한다 
역할과 접근 권한을 정의했다면 각 직원이 어떤 역할에 속하는지 결정하고 이에 따라 접근 권한을 배정한다. 

4. 일회성 변경을 삼간다 
이례적 요구로 일시적으로 특정 직원에게 변경을 허용하는 일을 자제하라. 그렇게 되면 RBAC 시스템이 이내 엉망이 될 것이다. 필요 시 역할을 변경하고, 또는 정말 필요할 때에만 새 역할을 추가하라. 

5. 감사 
역할과, 이에 할당된 직원, 직원에게 할당된 접근을 정기적으로 검토한다. 어떤 역할에 특정 시스템으로의 불필요한 접근이 할당되었음을 발견하면 역할을 변경하고, 해당 역할 안의 모든 직원의 접근 수준을 조정한다. 

예를 들어, 의료 단체는 의료 기록으로의 접근을 제어하는 것에 관한 규제 준수 요구로 RABC를 이용해 진료 의사 유형에 따라 의료 기록으로의 접근을 정확히 정의한다. 의사는 자신이 관리하는 환자의 기록에 거의 무제한으로 접근할 수 있겠지만, 응대 직원이라면 예약을 관리할 기본적 연락 정보로 제한될 수 있을 것이다. 적절히 계층화된 역할들 내에 직원이 많이 있다면 RBAC는 HIPPA, 여타 규제에 준해 데이터 접근을 제어할 수 있는 효과적인 수단이다. 

RBAC를 설정하는 유용한 툴들이 있다. 예컨대 마이크로소프트 액티브 디렉토리는 시작점으로 활용할 수 있는 빌트-인 역할이 설정되어 있다. 그로부터 고유한 상황에 맞춰 확장해나갈 수 있을 것이다. 아울러 역할을 기준으로 권한 할당을 자동화하는 ID 관리 시스템도 이용할 수 있다. 

*Robert C. Covington은 중소기업 보안과 규제 컨설팅 업체인 ‘고투가이(Go To Guy)’의 설립자이자 정보보안과 규제 요구 관련 사업을 하는 togoCIO.com의 대표다. ciokr@idg.co.kr

X