Table of contents
들어가며
안녕하세요. 넥슨 인텔리전스랩스 탐지솔루션실 플랫폼쉴드팀 김민철, 공채원입니다.
탐지솔루션실은 대규모 데이터 속에서 다양한 이상 상황(Abnomaly)과 악의적인 유저(Abuser)를 탐지(Detect)하고 조치(Action)하여 유저가 쾌적하게 게임을 즐길 수 있도록 하는 조직입니다. 플랫폼쉴드팀은 그 중에서도 조치(Action)를 담당하는 팀입니다. ‘플랫폼쉴드’라는 보안플랫폼을 개발하고 운용하며 가입부터 탈퇴까지의 유저 라이프사이클 전반에 적용되는 여러 서비스들을 제공합니다.
이 글에서는 인텔리전스랩스의 내부 서비스들을 융합, 자동화하여 넥슨 계정 보안까지 4일이 소요되는 업무를 40분 만에 처리가 가능하도록 시스템을 구축한 경험을 공유합니다.
이 작업을 통해 다음과 같은 결과를 얻었습니다.
•
기술 및 서비스 요약
보안위험계정을 탐지하여 보호모드 대상자를 분류하는 고가용성 파이프라인
업무 효율성 및 고가용성 확보하기 위한 내부 서비스 연동
•
개선 결과
◦
이상 탐지부터 보호모드 적용까지의 기간 단축 99.31% (4일 → 40분)
◦
원클릭으로 탐지 된 계정에 대하여 보호모드 설정 (전 과정 자동화)
◦
내부 서비스 연동으로 업무 효율성 증진, 조직 간의 장점을 공유하는 시너지 효과
1. 배경
넥슨은 대한민국 게임 업계 1위 회사로 1996년 바람의나라를 시작으로 업계에서 가장 오랜 기간 다수의 게임을 운영하며 라이브 서비스 노하우를 축적하고 있는 회사입니다. 특히 인텔리전스랩스는 이런 노하우를 AI 기술과 접목하여 더 재미있고 효율적으로 게임을 즐길 수 있는 방법을 제공하는 것을 연구하고 있습니다.
AI 기술을 접목시키기 위해서는 대량의 양질의 데이터가 필요합니다. 인텔리전스랩스는 양질의 데이터를 확보하기 위해 다양한 장르의 게임으로부터 매일 100테라가 넘는 데이터를 수집하여 양질의 데이터로 축적하기 위해 연구하고 있습니다.
게임 분야는 데이터 노다지입니다. 개발자나 연구자들이 인공지능(AI) 기술과 연구, 경험을 쌓는데 게임이 최고입니다.
방은주, "게임은 데이터 노다지···IT기업 중 데이터 가장 좋아" (지디넷 코리아), 2021.07.13.
플랫폼쉴드팀은 이렇게 축적된 양질의 데이터를 활용하여 실시간으로 유저의 계정을 보호하기 위한 보안플랫폼을 개발하여 서비스하고 있습니다.
이 글에서는 평소 운영 중 겪은 번거로운 업무들을 타 부서들과 협업 하여 자동화 프로세스를 확립한 경험을 공유합니다.
1-1. 용어 설명
들어가기에 앞서 글에서 등장하는 용어에 대해서 설명 드리겠습니다.
보안위험계정
플랫폼쉴드팀에서는 수집한 데이터를 분석하여 보안이 취약한 계정은 “보안위험계정”으로 분류해 관리하고 있습니다. 이렇게 분류한 계정의 피해를 사전에 막기 위해 로그인 시 팝업을 띄워 비밀번호 변경 및 OTP 설정을 유도하고 있습니다.
그림 1: 보안위험계정의 PC 로그인 시 팝업
보호모드
보호모드는 계정을 보호하기 위한 로그인 제한 기능입니다. 보호모드는 사용자가 직접 설정할 수 있으며 보안에 취약한 계정으로 탐지되는 경우에 보안 시스템에 의해 자동으로 설정될 수 있습니다. 보호모드가 설정되면 본인인증 후 비밀번호를 새로 설정해야 합니다.
참고. 비밀번호를 주기적으로 변경해야 하는 이유
1-2. 프로젝트 배경
라이브 서비스를 운영하다 보면 다양한 문제를 마주하게 됩니다. 다양한 문제들 중에서 때에 따라 많은 비용이 발생하는 문제들도 존재합니다. 예를 들면, 수작업이 필요한 업무, 다양한 유관 부서와의 커뮤니케이션, 보고 및 결재 등이 있습니다. 수작업 중에 발생하는 담당자의 실수, 커뮤니케이션 간에 발생하는 오해, 보고 및 결재의 우선순위 지연 등이 있습니다.
이 프로젝트는 아래의 문제들로부터 시작되었습니다.
1.
이상 탐지 급증에 대한 분석 고정 비용 증가
#분석_수작업 #유관부서_커뮤니케이션
2.
고객 문의 대응의 담당자 의존성
#설정_수작업 #유관부서_커뮤니케이션
3.
문서 및 경험에 의존하는 프로세스
#수작업
이상 탐지 급증에 대한 분석 고정 비용 증가
첫 번째로 이상 탐지 급증에 대한 분석 고정 비용 증가입니다. 분석해야 할 데이터의 크기가 크면 클수록 요구되는 고정 비용은 커집니다. 아래 실제 상황을 기반으로 쓴 예시 시나리오를 통해서 살펴보겠습니다.
이상 패턴 탐지 - 단기
어느 날, 보안위험계정 탐지 건수가 평소 대비 몇 배로 급증했다는 알림을 받게 됩니다. 담당자는 평소 대비 급증한 탐지의 원인과 그로 인한 영향을 파악하기 위해 보안위험계정 데이터를 추출하고 분석합니다.
하루 반나절의 시간을 사용하여 특이사항이 없음을 확인하고 해당 계정들 중 작업장과 같이 악용 가능한 계정으로 판단되는 보안위험계정에 보호모드를 설정합니다. 그리고 추후 비슷한 상황에서 빠른 처리를 위해 작업한 내용을 정리하여 문서화합니다.
이상 패턴 탐지 - 장기
몇 달 뒤, 이전과 유사한 알림이 지속적으로 발생합니다. 담당자는 이전에 작업한 내용을 기반으로 처리하기 시작합니다. 그러나 이전과 달리 분석 대상이 수십 배 증가했기 때문에 데이터 양이 많아 분석까지 오랜 시간이 걸립니다. 분석 결과를 기다리며 다른 작업과 같이 처리하다보니 컨텍스트 스위칭이 자주 발생하게 되어 다른 업무에도 영향을 주게 됩니다.
최초 탐지로부터 4일이 경과하고 나서야 결과가 추출되어 결과를 기반으로 작업을 마무리하게 됩니다.
그림 2: 이상 패턴 탐지 - 탐지건수가 증가할수록 작업시간도 증가
이처럼 분석할 데이터의 크기가 커질수록 작업에 요구되는 시간이 증가하고 다른 업무에도 영향을 줄 수 있어서 문제 중 하나라고 생각했습니다.
고객 문의 대응 시 담당자 의존성
두 번째는 고객 문의 대응입니다. 고객 문의는 라이브 서비스 운영에서 많은 비중을 차지하는 업무입니다. 고객 문의가 접수된 경우 빠른 대응을 할 수 있도록 프로세스를 갖추고 있어야 안정적인 서비스 운영이 가능해집니다.
보호모드에 대한 고객 문의 대응은 주로 계정에 설정된 보호모드 해제와 관련된 문의입니다. 문의가 접수되면 보호모드가 설정된 사유를 파악하여 운영팀에 전달하고 특이사항이 발견되는 경우 분석한 정책에 대한 검토를 통해 서비스를 개선하는 프로세스입니다.
일반적으로 보호모드는 본인인증을 통하여 해제가 가능하므로 고객 문의가 접수되지 않지만 종종 본인 명의가 아닌 계정에 대해 보호모드 해제를 요청하는 문의가 접수됩니다. 이 경우 추가적인 검증이 필요해지며 그 때마다 계정에 대해서 추가적인 정보를 추출하고 분석하여 담당자와 직접 커뮤니케이션해야 했습니다. 담당자의 업무 진행 상황에 따라 응대가 늦어지는 경우도 있었습니다.
이처럼 직접 커뮤니케이션 방식은 유용하지만 담당자에 의존적이고 상황에 따라 시간이 소요되는 방식이었습니다.
문서 및 경험에 의존하는 프로세스
세 번째는 문서 및 경험에 의존하는 프로세스입니다. 잘 정리된 문서와 경험 많은 담당자가 있는 프로세스는 효율적이고 적절한 해결 방식으로 작동합니다. 다만 이러한 프로세스는 담당자가 부재중이거나 문서화가 적절히 최신화되어 있지 않은 경우 더 큰 비용을 지불하게 만듭니다.
반복적으로 작동하는 프로세스의 경우에는 비교적 문서 최신화가 잘되어 있고 여러 담당자가 존재하지만, 간헐적으로 발생하는 프로세스는 담당자가 변경되거나 문서의 최신화에 대한 신뢰도가 떨어지기 때문입니다.
1-3. 해결 방안
그림 3: 인텔리전스랩스 운영방향성
위에서 제시한 세 가지 문제는 관점에 따라 문제로 여겨지지 않을 수 있습니다.
제한된 비용을 관리하는 입장에서는 비용을 투자할 정도의 문제가 아닐 수도 있으며, 이미 처리되고 있는 프로세스를 문제라고 정의하여 개선하는 작업은 또 다른 문제를 만들 수 있기 때문이기도 합니다.
그러나 인텔리전스랩스에서는 운영 경험과 노하우를 서비스화 하는 것에 투자하는 조직입니다.
•
업무 중 습득한 운영 경험과 노하우를 개인만 활용하는 것을 지양
•
기술을 모르고도 기능을 사용할 수 있는 서비스를 만들기 위해 연구
이런 연구들이 쌓여서 게임 업계에 필요한 서비스가 만들어지고 서비스화 경험이 누적되어 점진적인 발전이 될 것이라고 믿기 때문입니다.
보안위험계정의 보호모드 프로세스의 자동화 도입은 위의 명분을 기반으로 진행되었습니다.
2. 구현 과정 및 예시
2-1. 프로젝트 설계
이미 존재하는 프로세스를 개선하는 작업에서 가장 중요한 것은 위에서 설명한 것과 같이 추가적인 비용이 발생하지 않도록 설계하는 것이라고 생각합니다.
그래서 코드 작업을 최소화 할 수 있게 구성하고자 했고 이미 존재하는 서비스 및 도구를 최대한 활용하였습니다.
graph LR A["넥슨 로그인"] C["계정 보호"] A<-->C
Mermaid
복사
그림 4: 프로젝트 이전- 모놀리틱 구조
프로젝트 이전에는 넥슨 로그인 서비스와 계정 보호 서비스가 연결된 시스템으로 넥슨 로그인 서비스에서 로그인에 대한 정보를 계정 보호 서비스로 전달하면 이 정보를 분석하여 이상 패턴을 탐지하고 보호모드를 설정하는 모놀리틱 구조였습니다.
모놀리틱 vs 마이크로서비스
모놀리틱 구조는 작업이 간편하고 배포가 단순하여 프로젝트 초기에 합리적이라는 장점이 있습니다. 하지만, 작은 변경에도 전체를 배포해야 하는 단점이 있습니다.
과거에는 하드웨어의 가격이 비싸서 별다른 선택지가 없었지만 현대에는 하드웨어 가격이 저렴해지고 인프라 환경이 많이 개선되면서 마이크로 서비스 구조가 각광을 받고 있습니다.
마이크로서비스의 장점은 서비스 간의 결합도가 낮아서 수평적 확장이 쉽고 기능 단위의 배포가 가능하여 서비스 중단에 대한 비용을 줄여준다는 것 입니다. 하지만, 서비스가 잘게 나뉘어져 있어서 관리가 복잡해진다는 단점 또한 존재합니다.
그러나 넥슨에는 이미 훌륭한 서비스들이 팀 별로 분리되어 있어서 마이크로 서비스 아키텍처를 도입하는데 문제가 없다고 판단했습니다.
다음은 이번 프로젝트를 진행하면서 필요한 기능/역할을 담당해 준 내부 서비스들입니다.
•
•
•
•
•
NCSR 전자결재 [기술 본부]
Nexon Customer Service Request의 약어
업무 요청자와 작업 담당자 간의 서비스 요청 단순화를 위한 내부 전자결재 시스템
graph TD A["넥슨 로그인"] B["라이브스트림"] C["계정 보호"] D["유저프로파일"] E["NCSR 전자결재"] F["신규 프로젝트"] A<-->C F<-->B F<-->D F<-->E F<-->C
Mermaid
복사
그림 5: 프로젝트 이후 관계도 - 마이크로 서비스
앞서 서론에서 설명한 시나리오처럼 분석 업무가 증가함에 따라 위와 같이 라이브스트림, 유저프로파일, NCSR 전자결재를 연계하는 신규 프로젝트를 진행하여 자동화 파이프라인 시스템을 구축하였습니다.
2-2. 보호모드 프로세스 자동화의 설계 및 구현
설계 및 구현에 대해 조금 더 자세히 살펴 보겠습니다.
graph TD
subgraph NP["신규 프로젝트"]
P["Protector"]
PS["Protector server"]
E["Enforcer"]
A["Airflow"]
end
NC["NCSR 전자결재"]
Q["보호모드 대기열"]
NL["넥슨 로그인"]
LS["라이브스트림"]
AP["계정 보호"]
UP["유저프로파일"]
NL<-->AP
P<-->LS
E<-->LS
A<-->UP
A-->LS
NC<-->PS
PS<-->AP
Q<-->P
Q<-->PS
Q<-->AP
Mermaid
복사
그림 6 : 시스템 상세 관계도
그림 7: 시스템 구조-상세 프로세스
구현 요소
본 프로젝트를 위해 직접 구현한 요소는 아래 4개 서비스입니다.
•
Airflow 기반 ETL: 추가 데이터 추출
•
Enforcer: 정책을 기준으로 보호모드 대상 여부 판단 (정책 별 enforcer 구동 가능)
•
Protector: NCSR 전자결재 생성 및 보호모드 대상자 대기열 등록 (정책 별 protector 구동 가능)
•
Protector server: NCSR 전자결재 승인 시 대기열에 등록된 대상자들 보호모드 적용 호출
그림 8: Enforcer, Protector, Protector Server
Airflow 기반의 ETL 프로세스
Apache Airflow는 데이터 엔지니어링 파이프라인을 위한 워크플로우 관리 플랫폼입니다. 현재 넥슨 내에서 수집된 데이터의 추출 작업을 배치 처리로 실행할 수 있게 Airflow를 구축하여 사용하고 있습니다. 이미 구축된 airflow 덕분에 데이터 추출부터 처리, 전송, 모니터링 및 알람까지 간단하게 사용할 수 있었습니다.
데이터 추출 및 처리 로직은 Zeppelin에서 pyspark로 작성하였으며 대상자 분류를 위해 결과를 kafka로 발행하였습니다.
Enforcer
대상자 분류 작업을 Airflow의 Task에 추가하지 않고 Enforcer를 따로 분리한 이유는 정책 관리 및 운영에 대한 필요성 때문이었습니다.
정책을 통한 보호모드 대상자 분류를 구현하기 위해 Casbin 라이브러리를 이용하여 ABAC 모델을 사용하였습니다.
매번 추가되는 정책을 처리하기 위해 python 코드를 수정하기보다 Casbin의 PERM 모델을 정의하여 다양한 접근 제어(Access Control)를 처리하게 하고 코드 작업 없이 정책 기반으로 조건 처리하고자 했습니다.
그림 9: casbin의 작동 프로세스
그림 10: casbin의 PERM 메타 모델 정의
Casbin의 PERM 메타 모델은 크게 request_definition, policy_definition, policy_effect, matchers와 같은 섹션들로 구성됩니다.
1.
request_definition: 요청을 정의하는 부분입니다. 예를 들어, 사용자(sub)가 오브젝트(obj)에 대해 어떤 행위(act)를 수행할 수 있는지를 정의하는 요청을 표현합니다.
2.
policy_definition: 정책을 정의하는 부분입니다. 예를 들어, 어떤 사용자가 어떤 오브젝트에 대해 어떤 행위를 할 수 있는지 정의하는 정책을 표현합니다.
3.
policy_effect: 정책의 효과를 정의하는 부분입니다. 일반적으로, 하나 이상의 정책이 매칭될 경우 어떻게 그 결과를 해석할 지를 정의합니다. 예를 들면, "어느 하나의 정책만 매치되어도 허용한다" 혹은 "모든 정책이 매치되어야 허용한다"와 같은 효과를 정의할 수 있습니다.
4.
matchers: 요청과 정책이 매칭되는지를 결정하는 식을 정의하는 부분입니다. 예를 들어, 요청의 사용자와 정책의 사용자가 같고, 요청의 오브젝트와 정책의 오브젝트가 같으며, 요청의 행위와 정책의 행위가 같을 때 매칭된다고 정의할 수 있습니다.
요약하면, request를 정의하고 matchers에 해당하는 policy가 존재하는 경우 해당 request는 policy_effect로 처리 됩니다.
casbin은 online editor를 지원하여 코드 구현 없이 온라인으로 접근 제어를 시뮬레이션 해 볼 수 있습니다.
그림 11: casbin - online editor
그림 12: casbin ABAC rule model 예제
Enforcer는 Airflow에서 처리된 message를 kafka를 통해 전달받아 ABAC model의 policy를 기반으로 보호모드 대상자 여부를 판별한 뒤 Protector가 처리할 수 있도록 메시지를 kafka로 다시 발행합니다.
최종적으로 코드 작업 없이 policy와 model만을 변경하여 다양한 Enforcer를 구동할 수 있도록 설계하였습니다.
Protector
분류된 보호모드 대상자를 라이브에 적용하기 전에 다음과 같은 처리를 위해 Protector를 구현하였습니다.
•
이력 및 결재 프로세스 관리
•
운영팀 검수 및 모니터링
그림 13: 내부 결재 및 운영팀 공유를 위한 NCSR 화면
모든 요소는 ELK 스택을 연동하여 Kibana로 대시보드를 용도에 맞게 생성하여 모니터링 하고 있습니다.
다양한 관점에서 대시보드를 생성할 수 있어서 개발을 위한 모니터링과 운영을 위한 대시보드를 따로 관리할 수 있게 되었습니다.
그림 14: Kibana 대시보드
부록. Kibana의 Unique Count 불일치 이슈
Protector Server
대기열에 등록된 보호모드 대상자들을 실제로 라이브에 적용하는 Protector Server를 구현하였습니다. Protector Server는 NCSR에서 결재가 승인되었을 때 webhook으로 결과를 받아 보호모드를 라이브에 적용합니다.
그림 15: 상세 프로세스
이번 프로젝트를 위해 저희가 직접 구현한 부분은 1) Airflow 기반의 ETL 프로세스, 2) Enforcer, 3) Protector, 그리고 4) Protector Server입니다. 이들은 기능 단위로 분리하여 마이크로서비스로 개발되었습니다. 각 마이크로서비스는 Kafka와 같은 메시지 큐를 활용하여 데이터를 비동기적으로 주고받음으로써, 서로 간의 결합도를 낮추고 단일 장애 지점(SPoF)의 위험을 감소 시켰습니다. 또한, 이러한 구조를 통해 시스템의 수평적 확장을 용이하게 하였습니다.
나가며
넥슨 내에 축적된 지식과 여러 서비스 덕분에 최소한의 코딩 작업으로도 빠르게 자동화 프로세스를 적용할 수 있었습니다. 이를 통해 4일 이상 소요되던 반복적인 업무를 40분 이내로 단축 시켰고, 계정을 빠르게 보호할 수 있는 기반을 만들었습니다.
앞으로 탐지솔루션실의 분석가분들과 함께 더 나은 정책을 연구하여 계정을 안전하고 빠르게 보호할 예정입니다.
마지막으로 이번 프로젝트를 진행하면서 “우분투”라는 가치를 크게 느꼈던 것 같아 공유하며 마무리하고자 합니다.
우분투
우분투, 개발자 분들이라면 리눅스 기반의 운영체제로 익숙하게 들어보셨을 단어인데요.
실제로는 아래와 같은 뜻을 갖고 있다고 합니다.
[우분투(Ubuntu)]란 남아프리카 반투어로 [네가 있으니 내가 있다]라는 윤리 사상을 일컫는 말로 공동체 정신, 인류애를 뜻하는 단어
우리는 서로의 필요에 의해서 존재합니다. “우리”가 될 동료를 구하고 있습니다.
그림 16: 우리들의 동료가 돼라!
Reference
[8] ABAC, Casbin
[11] Kibana, Elastic
함께 읽으면 좋은 글 
테크블로그 문의 devrel@nexon.co.kr