외국계 금융회사의 IT 직무분리

안녕하세요,

본 기고글 주제는 “외국계 금융회사의 IT 직무분리” 입니다.

직무라는 단어의 사전적 의미는 “과업 및 작업의 종류와 수준이 비슷한 업무들의 집합(Job)” 입니다. 회사 내 사업 부서, IT 부서, 경영 부서 등 각 조직에 따른 역할이 존재하는 부분 또한 직무라고 표현할 수 있을 것 같습니다. 직무 및 직무 분리라는 개념이 굉장이 광범위 할 수 있으므로 정보보호 관리체계 내 IT 직무 분리에 대해 다루겠습니다.

한 회사 내 직무 분리 체계를 갖추고 운영하는 것은 중요하지만 어려운 것이 사실입니다. 이렇다 할 정답도 없습니다. 예를 들어, 직무 분리를 구체적으로 어느 영역에 어느 수준까지 적용해야 하는지에 대한 구체적인 가이드는 찾기 어려운 것 같습니다. 또한 소규모 조직의 경우, 직원 한 사람이 다수의 정보처리시스템을 운영하면서, 동시에 보안 감사 업무를 맡아 처리하기도 합니다. 까다롭기만한 직무 분리를 해야하는 이유는 무엇일까요? 필자는 정보보호 관리체계 인증기준에서 답을 찾을 수 있다고 생각합니다.

“2.2.2 직무분리 - 권한 오/남용 등으로 인한 잠재적인 피해 예방을 위하여 직무 분리 기준을 수립하고 적용하여야 한다. 다만 불가피하게 직무 분리가 어려운 경우 별도의 보완대책을 마련하여 이행하여야 한다.”

즉, 직원 한 사람이 여러 권한을 보유한 경우, 권한이 분리된 경우보다 IT 사고 발생 가능성이 높기 때문 입니다. 합당한 예시는 아닐 수 있겠지만 AWS (CSP, Cloud Service Provider)에서는 클라우드 환경 내 root(관리자) 권한 사용을 자제하고, IAM (Identity and access management) 기반에 따라 적절히 권한을 분리해 사용하도록 권고하고 있습니다. 다만, 클라우드 환경을 통해 빠르게 시스템을 개발/배포하고 서비스를 운용하는 회사의 경우, 특성상 개발자들에게 많은 시스템 계정 권한을 부여하기도 합니다. 위에도 말씀 드렸다시피 정답은 없습니다. 직무 분리가 어렵다면, 모니터링 및 그에 따른 책임 추적성을 확보할 수 있는 통제 방안을 마련하면 될 것 입니다.

필자가 실제 외국계 금융회사에서 겪은 직무 분리 관련 주요 에피소드는 다음과 같습니다.

• ●본사 IT 정책/지침서에 따른 직무 운영

상위 정책서에는 “4-eyes principle” 라는 개념이 존재했고, 이를 각종 통제 절차 등 수립할 때 항상 고려했습니다. 즉, 모든 업무를 진행할 때 단독으로 처리하는 것이 아닌, 최소 1명 이상의 승인/검토자를 두어야 한다는 의미입니다.

본사 IT 정책서 내 각 IT 직무에 따른 담당자의 역할 및 책임이 명확히 부여되어 있었습니다. 예를 들어, 보안 담당자의 경우 역할 및 그에 따른 미션이 비교적 명확히 부여되었습니다. 대표적으로 아래와 같은 미션이 주어졌습니다.

• -지역(자회사가 따라야 하는 각 국가 내 법령) 보안 규제 준수

• -본사 정책서 현지화

• -연간 보안 계획 수립

• -정기적인 보안 교육 수립/시행/지원

개발자의 경우, 배포 담당자, 소스코드 개발 담당자, 테스트 담당자 등 역할에 따른 해야할 일이 다양한데 이를 지침서 내 업무 역할 별 Matrix 화 하여 명확히 구분했습니다.

Figure 1. 개발자 직무 별 권한 표 (예시)

※ 금융회사의 경우, 전자금융감독규정 제26조(직무의 분리)에 따른 직무 분리를 권고하고 있습니다. 다만, 필자 외국계 회사 특성상 본사의 정책/지침/가이드라인이 세부적으로 명시되어 있으며 로컬 규정의 권고사항도 충족하므로, 본사 에피소드를 중점적으로 기술하였습니다.

• ●예외 정책 수립/운영

본사 정책에 따라 운영되지 못하는 경우, 내부 승인 및 대체 방안을 적용 했습니다. 개발자의 경우, 역할에 따른 담당 인원이 별도 존재하는 것이 바람직하지만 예산 등 을 고려하면 적용이 불가능했습니다. 따라서 일부 인원이 여러 직무를 수행하고, 그에 따른 자회사 별도 통제 프로세스를 수립했습니다.

대표적으로 특수 권한 계정 사용 프로세스를 말씀 드리고 싶습니다.

• -Step1. 평소 특수 권한 계정 사용을 위한 관련 로그인 정보를 소스코드 개발 담당자와 인프라 담당자가 반반씩 정보를 나눠 안전한 장소에 보관

• -Step2. 필요 시(긴급 배포, 장애 처리 등) 내부 상위 직책자의 승인

• -Step3. 관련 로그인 정보를 합한 뒤, 소스코드 개발자가 사용

• -Step4. 로그인 정보 (패스워드) 변경 후, 다시 각 담당자가 반씩 나누어 보관

또한 본사 정책서에는 IT Risk Manager 를 별도로 두어야 한다는 조항이 있었습니다. 이 부분 또한 현실적으로 적용이 어려워, “정보보호위원회” 를 최대한 활용하는 방향으로 가닥을 잡았습니다. 대략적으로 아래와 같은 프로세스를 적용했습니다.

• -정보 보안 담당자는 월 1회 위험 현황 식별

• -식별된 위험을 바탕으로 위 "위험 관리 방법론"을 고려한 보안 대책 등 수립

※ 필요시, 관련 실무진과 협의

• -정보보호 위원회 심의/의결

• -경영진 보고

• -본사 Chief Information Security Officer (이하 'CISO') 현황 공유