서버 계정 통합 시스템 구축기

서비스 규모가 확장되고 점점 다양해지면서 운영해야하는 서버가 증가하였습니다. 따라서 각 서버에 생성되는 사용자 계정 또한 서버 대수에 비례하게 증가하였습니다. 시스템 관리자는 인사 변동이 발생할 때마다 계정을 삭제하거나 권한을 변경해야하는데 그에 따른 업무량의 증가는 감당하기 어려운 한계에 가까워졌습니다. 

사용자에게 발급된 계정은 각자가 직접 관리를 하도록 되어 있으므로, 사용자들 또한 수많은 서버의 패스워드를 변경해야하는 등의 애로가 있었습니다. 장기간 접속하지 않는 서버들도 있었고 그 상태로 패스워드가 만료되기도 하였습니다. 

또한, 보안취약점 조치에 치중되던 과거와 달리 최근 개정되는 각종 법령 및 ISMS 인증심사 기준은 접근제어 및 권한통제가 강조되는 것으로 보입니다. 그 기준을 충족하기 위해서는 사용자에게 필요한 권한만 최소한으로 차등 제공되어야 하나 수천 개의 계정을 개별적으로 관리하는 것은 매우 어려운 문제였습니다. 

 

Kerberos

커베로스

우리는 원도우의 액티브 디렉토리 처럼 복수 시스템의 계정을 중앙에서 일괄관리할 수 있으면 좋겠다고 생각했습니다. 전체 시스템의 계정 현황을 쉽게 조회하고, 각 사용자 정보도 바로 추출할 수 있을 것이고, 최소한 사용자들이 패스워드를 변경하는 일을 쉽게 해줄 수 있을 것입니다. 그래서 우선 리눅스 서버에 대해 커베로스(Kerberos)를 이용해 계정을 관리 할 수 있는 시스템을 구현하기로 결정했습니다. 

가장 먼저 커베로스 프로토콜의 동작 원리와 보안성에 대해 공부하기 시작했습니다. 이것은 그리스 신화에 나오는 하데스의 입구를 지키는 머리가 셋이 달린 개, 케르베로스(Cerberus)를 연상하게 됩니다. 커베로스는 미국 MIT의 아테나(Athena) 프로젝트의 일환으로 개발된 네트워크 환경에서 인증 및 액세스 제어를 제공하는 데 사용되는 표준 프로토콜입니다. (Miracle, 2008)

사용자가 특정 서버에 접속하고자 할 때, 아이디와 패스워드를 입력하여 커베로스 서버에 인증을 요청하면, 커베로스 서버는 사용자에게 세션 키와 티켓을 발행하여 반환하고, 티켓 그랜팅(ticket-granting) 서버에 세션 키를 전달합니다. 이후 사용자는 이 티켓으로 추가 인증 없이 특정 서버에 접속할 수 있게 됩니다. 

이 체계는 몇 가지 이점이 있습니다. 먼저 로컬 호스트는 사용자 계정의 패스워드 또는 패스워드 해시 값을 저장할 필요가 없습니다. 다음으로 사용자와 커베로스 서버 간에 공유하는 세션 키는 하루에 한번만 사용되므로, 브루트 포스(brute force) 공격의 대상이 되는 사용자 암호 또는 세션 키의 노출이 상당히 제한됩니다. (Udacity, 2016)

실제 도입을 결정하기 전에 커베로스를 사용하는 타사 사례를 조사하였으나, 순수하게 커베로스만을 운영하는 사례는 거의 없었고  대부분의 경우 추가의 솔루션을 포함한 다양한 형태로 운영되는 것으로 보였습니다. 우선은 다른 솔루션을 배제하니 리눅스 자체에서 커베로스를 지원하여 손쉽게 구축이 가능했습니다. 

 

FreeIPA

커베로스 서버를 구축하고 이를 이용해 호스트 추가 및 삭제, 계정 생성 및 삭제, 패스워드 변경 등을 할 수 있었습니다.  하지만 계정 관리만 할 수 있으니 아쉬웠습니다. 사용자가 쉽게 자신의 정보를 조회할 수 있고, 서비스 및 SUDO권한에 대한 관리도 가능하면 좋을 것입니다. 커베로스 서버가 한 대 뿐이면 장애 시에 심각한 문제가 되므로 클러스터를 구성하는 것도 필요했습니다. 그래서 이런 요구사항을 모두 충족시키는 FreeIPA를 찾아냈습니다. 

FreeIPA는 MIT 커베로스, 389 디렉토리 서버, Dogtag 인증 시스템, SSSD 등을 통합한 보안 정보 관리 솔루션입니다. 389 디렉토리 서버는 리눅스에서 실행되는 오픈 소스 LDAP 서버이고, Dogtag 인증 시스템은 PKI 배포를 관리하는 시스템이며, SSSD는 인증 리소스에 대한 액세스를 제공하는 데몬입니다. 이 모든 기능들은 레드햇에서 공식적으로 지원하여 구축하는 과정은 매우 수월했습니다. 

구축을 완료한 뒤에 기능 테스트를 수행하여 요구사항들을 전부 충족하는 것을 확인했습니다. 그러나 장애 및 성능 테스트 시에 몇가지 테스트 케이스에서 예상과 다른 결과를 발견했습니다. 

테스트 케이스 일부

표. 테스트 케이스 일부

 

시스템 구축

지금까지 학습과 테스트를 통해 커버로스 프로토콜을 이용하여 다수의 서버 계정을 단일한 시스템에서 관리 및 통제할 수 있는 방법이 마련되었으며, 그 결과로 구현된 서버 계정 통합 시스템의 구성은 다음과 같습니다. 이를 통해 직면했던 문제들을 해결할 수 있게 되었습니다. 

서버 계정 통합 시스템의 구성도

그림. 서버 계정 통합 시스템의 구성도

 

구축된 시스템은 다음과 같은 기능을 제공합니다. 단일한 인터페이스에서 계정 관련 정보를 모두 조회할 수 있고, 각 계정별 권한을 통제할 수 있습니다. 모든 서버의 계정을 단일한 시스템에서 일괄 관리할 수 있으므로,  휴직자 및 퇴사자 등 불필요한 계정이 있는지 추적할 수 있고, 패스워드가 만료된 계정을 조회할 수 있게 되었습니다. 각 계정별로 접속이 승인된 대상 서버와 서비스가 무엇인지 추적할 수 있습니다. 또한 각 계정별로 관리자 권한으로 실행할 수 있는 명령어 등의 권한을 통제할 수 있습니다. 또한 웹 콘솔 뿐만 아니라 CLI, REST API와 같은 인터페이스도 제공합니다. 관리자는 웹 콘솔 또는 CLI를 이용해 모든 관리 기능을 이용할 수 있습니다. 사용자는 프로필 관리, 패스워드 변경, 권한 조회 등을 할 수 있습니다. 또한 REST API를 이용해 관리 기능을 자동화할 수도 있습니다. 

 

서비스 적용 및 정책 재수립

기존에 관리되지 않거나 불필요한 계정이 이관되는 것을 방지하기 위해 모든 로컬 계정을 폐기하고, 전체 계정을 모두 새로 생성하기로 결정했습니다. 이 과정에서 발생하는 업무 혼선을 최소화하기 위해 단계를 나누어 관리자 계정, 사용자 계정, 배포 계정 순으로 적용하였습니다. 대상 서버도 점진적으로 확대하여 사전에 검토한 사례 외에 예외 사항의 발생에 대처하고 그 과정에서 운영 노하우를 습득할 수 있었습니다. 이 과정에서 예상치 못했던 성능 저하 등과 같은 이슈들이 발견되었고 캐시 최적화 등을 통해 모든 문제들을 해결하였습니다. 

새로운 시스템의 적용과 함께 계정 관리에 대한 정책도 ISMS 인증심사 기준에 적합하게 다시 수립하였습니다. 사용자 계정은 터미널 및 응용 프로그램 등으로 접근권한을 분류하여 차등 부여하였습니다. 사용자의 터미널 계정에는 기본적으로 관리자 권한을 부여하지 않으며, 아래와 같은 예시와 같이 필요 시에만 최소한의 권한만 부여했습니다. 

  • 관리자 권한으로만 접근 가능한 경로의 읽기 권한
  • 서버 운영에 데몬의 시작과 중지 권한

ISMS 인증 기준에 따르면 직무별 또는 역할별 정보시스템 접근권한을 정의한 접근권한 분류 체계를 관리해야 하며, 접근권한은 업무 수행에 필요한 최소한으로 할당하여야 하며, 업무 담당자 직무에 따라 차등 부여하여야 합니다. 관리자 및 특수 권한의 할당 및 사용 시에는 책임자의 승인을 받아야 합니다. 관리자 권한은 사용자를 최소한으로 제한하고 별도의 목록으로 관리하는 등의 통제절차를 수립해야 하며, 특수 권한은 필요한 경우에만 할당하고 식별이 가능하도록 관리되어야 합니다. 

기존에는 서버 계정 신청서를 작성할 때 서버명과 계정명을 기재하여 책임자의 승인을 받도록 했으나, 이제는 서비스명과  목적을 상세하게 기재하여 목적에 따라 결재라인을 달리 하도록 신청 절차를 변경했습니다. 또한 관리 부서에서는 정기적으로 사용자 계정 전체에 대해 그 적정성을 검토 및 조치하고, 장기 미사용 계정을 삭제하는 절차를 다시 확립하였습니다.

 

맺음말

지금까지 서버계정 통합시스템을 구축하게 된 과정에 대해 간략히 서술해 보았습니다. 물론 이 밖에 실제 라이브 시스템을 원활하게 운영하기까지 많은 시행착오와 트러블슈팅 과정을 거쳤고 때로는 시스템을 통채로 재구축하여 마이그레이션을 하기도 하는 등 다양한 중간 과정이 있었습니다만 결과적으로 서버계정 관리의 중앙화를 성공함으로써 업무 편의성을 향상시켰기에 계정관리 및 권한통제, ISMS 인증기준 충족 등 많은 부분에서 긍정적인 효과를 볼 수 있었습니다.

그러나 우리의 여정은 여기에서 끝나지 않았습니다. 지금까지는 기반시스템을 구축하고 안착시키는 것을 목표로 했다면 이제부터는 더 나은 업무환경을 위해 앞으로 이 시스템을 어떻게 활용할 것인지에 대해 고민하고 노력을 해볼까 합니다.

 

참고 자료