[보안맨] IT 서비스 제공업체(IT Service Provider) 관리보안

안녕하세요, 보안맨 입니다.

이번 기고글은 "IT 서비스 제공업체(or IT Service Provider) 관리보안" 입니다.

신 기술의 발달 또는 회사 예산 등 여러 이유로 회사 IT인프라 환경을 fully 자체 구성해 서비스를 운영하는 곳은 점차 줄어들고 있는데요. 역으로, IDC (인터넷 데이터 센터) 또는 상용 클라우드 서비스 등을 통해 회사 IT 인프라 환경에 대한 전반적인 운영관리를 전문 IT 업체에 '위탁' 합니다. 이 때, 통상적으로 양 사간 계약서와 함께 SLA (Service Level Agreement) 계약도 함께 체결해 R&R 을 구분하는데요.

국내 정보보호 관리체계 인증 기준에서는 ISO27001 인증 기준과 달리, IT 서비스 제공업체 관련 구체적인 요건을 언급하고 있지는 않습니다. 다만, 유사 영역인 '외부자 계약 시 보안'에서는 아래와 같이 명시하고 있습니다.

외부 서비스를 이용하거나 외부자에게 업무를 위탁하는 경우 이에 따른 정보보호 및 개인정보보호 요구사항을 식별하고, 관련 내용을 계약서 또는 협정서 등에 명시하여야 한다.

필자는 외국계 금융회사에 근무했을 당시, IT Auditor (감사사)로부터 'IT 서비스 제공업체 관리 미흡'으로 부정적인 평가를 받았었는데요. 

1) 어떤 부분이 문제점이었는지

2) 어떤 방식으로 개선해 나갔는지

3) 아쉬웠던 점

실무 경험을 기반으로 위 3가지 steps 에 나누어 말씀 드리겠습니다.

1) 문제점

당시 국내에서 큰 규모의 IDC 사업을 영위하는 'C' 회사와 '정보처리시스템 위탁' 계약을 체결했었는데요. 당시 IT Auditor 로부터 크게 3가지 형태의 문제가 제기 되었습니다.

- 기업 간 정보 공유 시, confidential 내용 (네트워크 구성도 문서에 설정된 파일 암호 정보)이 평문으로 이메일에 노출

- A 회사의 월간 업무 현황 (e.g. UPS 점검 현황 등)을 점검/관리하지 않음

- 전산실 내 조명 시설이 설치되어 있지 않음 등

회사 내에 전산실 관리 지침은 존재했지만, 구체적인 절차서, 실행 계획은 없었기 때문에 돌이켜 보면 당연한 결과였습니다. 전산실 제반 업무에 대해 IDC 업체에 전적으로 업무를 맡기면서, 실정을 잘 살펴보지 않고 적절하다고 판단한 부분이 실책 이었습니다.

Figure1. 비밀번호 메일 노출 (a.k.a. IT staff 보안인식 부재)

2) 개선 사항

크게 두가지 기반의 업무 개선이 빠르게 이루어 졌습니다.

- IT 서비스 프로바이더 관리 절차서 수립

- 해당 기업과 SLA 기반 항목 조율/보완 및 실질적 점검 업무 수행

절차서 수립을 위해 다음 steps 을 고려했습니다.

1) Local 규정/요구사항 list-up (e.g. 전자금융감독규정 내 전산실 보호 대책, ISMS 등)

2) 본사(해외) 규정, ISO27001 등 해외 best practices list-up

3) 위 1),2) 간 Gap Analysis - ※ 보수적 요구사항 채택

4) 관련 기업/부서와 논의에 따른 최종 요구사항, 통제항목 선정

5) 최종 수립

Figure2. 갭분석 비교표 (예시)

 기존에 만들어진 SLA 문서의 적절성을 세밀하게 살펴보고, 위 수립된 절차서 내 요구사항과 비교/검토해, gap 이 큰 부분은 요건에 반영될 수 있도록 추진 했습니다. 관련 회사와 많은 공수 등을 소요해 업무를 진행했던 기억이 있습니다.

 예를 들어, SLA 항목에 UPS 등 전산 장비에 대한 점검을 어느 부서가 하는지, 어떤 주기로 점검하는지 구체적으로 명시되어 있지 않았는데, 구체화하는 과정을 통해 관련 업체가 적절히 업무를 처리하지 않으면, penalty 가 주어지도록 SLA 지표를 체계화 했습니다.

Figure3.service indexes of a system (examples)

 위의 표는, 시스템 가용성에 관한 SLA 관리 지표를 세밀한 등급으로 나누어 관리는 외국 어떤 기업의 템플릿을 예시화 한 입니다. 회사마다 SLA 에 대한 용어, 규모, 계약 방식 등이 상이할 수는 있습니다. 다만 고객사의 담당자라면, 서비스 제공자가 제공하는 기존 SLA 양식 및 내용 등을 답습하는 것이 아니라, 고객사(회사)의 환경, 특이사항 등이 반영될 수 있도록 서로간의 접접을 잘 모색할 필요가 있겠습니다.

3) 고려 사항

두 가지 어려웠던 점이 있습니다.

첫 번째는 Vendor Management 입니다.

해당 업체는 국내에서 굉장히 큰 IT 기업이었습니다. 그에 반해 필자가 몸담고 있던 회사는 외국의 지사 수준의 기업이다 보니, 돌이켜 보면 영업 입장에서는 다른 대기업 고객에 비해 매력적이지 않다고 판단할 수도 있을 것 같습니다.

필자의 회사(소규모 고객사)가 여러 보안 또는 IT 요구사항을 빈번히 요구하자, 분명한 선을 긋고 계약서 내 체결된 항목에 한한 지원만 가능하다는 입장을 내비쳤습니다. 물론 업체 입장에서 충분히 가능한 입장이며, 한편으로 고객사 입장에서 무리한 보안 요구사항은 갑질로 여겨질 수 있는 민감한 사안일 수 있습니다. 

결론적으로, 기존 '운영 위탁' SLA 계약이 포괄적으로 구성되어 있고, 이를 바로잡고자 하는 고객사의 의견이 모두 반영되지 않고, 적절한 선에서 타협이 이루어진 부분은 아쉬웠습니다. (물론 해당 업체, 제 3자의 의견은 다를 수 있습니다. )

두 번째는, 내부 전문 인력의 부재 입니다.

IDC 업체와 '특정 서비스 구간 네트워크 장애 시 고객사 통보 건수' 관련 기준을 새롭게 산정해야 했습니다. IT 부서 내 네트워크 전문가가 없다보니, IDC 업체 담당자의 의견을 거의 100% 수용해 기준이 마련되었습니다. SLA 지표에 반영되는 중요한 항목이고, 고객사 입장에서 반드시 바라보아야할 key factor 가 있음에도 불구하고, 고객 입장의 관점이 관철되지 못했습니다.

단기적으로는 내부 네트워크 전문가가 없는 점이 회사 예산 측면에서 유리할 수 있지만, 장기적으로는 각 IT 영역별 전문가가 있어야 하는 점을 느낄 수 있었습니다.

본 기고글이 현업에 도움 되셨으면 좋겠습니다.

고맙습니다.