안녕하세요, 카카오뱅크 어플리케이션 보안팀에서 블루팀 업무를 맡고 있는 Jinny입니다.

저희 블루팀에서는 앱을 통해 들어오는 외부 공격을 방어하고, 카카오뱅크가 보유한 주요 정보들을 안전하게 보호하기 위한 다양한 보안 업무를 수행하고 있습니다. 어찌 보면 고객의 정보와 자산을 방패막🛡️처럼 지켜드리는 것이 블루팀의 주된 목표인데요. 더 나아가 팀에서는, 보안 프로세스를 자동화하는 DevSecOps 분야에도 깊은 관심을 가지고 있습니다.

이 글에서는 카카오뱅크에서 진행 중인 다양한 보안 활동을 소개해드리면서, 이를 자동화하는 과정에서 블루팀이 겪은 고민과 경험을 나누고자 합니다.

잠깐! 보안 업계에서 통용되는 레드팀/블루팀 이란? 🤔
사이버보안 분야에서는 '레드팀/블루팀 시뮬레이션 공격 훈련'이 있는데요. 이를 참고하여 각각의 역할을 설명드리면 다음과 같습니다.
- 레드팀❤️: 공격자의 역할로, 시스템에 침투하여 보안 프로토콜을 넘어서려는 시도를 한다. 흔히 말하는 '화이트 햇'에 해당된다.
- 블루팀💙: 방어자의 역할로, 공격을 탐지하고 복구하는 역할을 담당한다. 또한 잠재적인 위험으로부터 시스템을 보호하는 업무를 수행한다.

DevSecOps에 대해 알아보자

1-devsecops-lifecycle-image
[그림 1] DevSecOps를 지탱하는 3가지 개념 - 개발(Dev), 보안(Sec), 운영(Ops)

아마 ‘DevOps’는 들어보셨어도 ‘DevSecOps’는 생소한 분들을 위해 개념 설명부터 시작하겠습니다. 😄

DevSecOps는 개발(Dev), 보안(Sec), 운영(Ops)을 하나의 통합된 프로세스로 결합하는 방식입니다. 이는 기존의 ‘개발’과 ‘운영’ 단계 사이에 ‘보안’ 단계를 추가한 개념으로, 소프트웨어 제공 사이클의 초기 단계부터 보안을 고려하여 설계 및 개발해 나가는 것을 핵심으로 합니다. 이 접근 방식은 보안이 단순히 추가적인 개념이 아닌, 개발 프로세스의 모든 단계에 내재된 것으로 역할을 확장시켜 추후 지속적인 보안 테스트와 모니터링을 가능하게 합니다. 이를 통해 서비스의 신뢰성과 안정성을 향상하고, 잠재적인 보안 사고의 위험을 최소화하는 것을 목표로 합니다.

이때 DevSecOps는 다음과 같은 5가지 주요 원칙에 근거하고 있습니다.

  1. 자동화(Automation): 보안 검사와 정책 준수를 자동화하여 프로세스를 가속화하고 인간의 실수 가능성을 줄입니다.
  2. 시프트레프트(Shift-Left): 보안을 개발 초기 단계부터 투입하여 보안 문제를 조기에 식별하고 수정합니다.
  3. 코드 및 구성 관리(Code and Configuration Management): 모든 코드와 구성 변경 사항을 추적, 관리하여 보안 위협을 최소화합니다.
  4. 지속적 테스트(Continuous Testing): 지속적으로 보안 테스트를 수행하여 취약점을 식별하고 조치합니다.
  5. 지속적 모니터링(Continuous Monitoring): 운영 중인 시스템을 지속적으로 모니터링하여 보안 위협을 감지하고 대응합니다.

위의 5가지 주요 원칙들 중, 시프트레프트(Shift-Left) 방식은 말 그대로 ‘보안 프로세스를 가능한 한 초기 개발 단계로 옮기는 전략‘을 의미합니다. 전통적인 소프트웨어 개발 절차에서는 보안 검사와 테스트가 주로 개발이 끝나가는 막바지 단계에서 이루어졌습니다. Shift-Left 접근 방식은 보안 프로세스를 가능한 한 초기 개발 단계로 이동시켜 취약점의 조기 발견 및 조치하는 것을 목표로 합니다.

2-shiftleft-image
[그림 2] 보안 프로세스를 개발 초기부터 적용하여 취약점을 조기 식별 및 조치하는 시프트레프트(Shift-Left) 방식

취약점 조치에 대한 비용은 개발 프로세스가 진행될수록 증가합니다. 이미 설계와 구현이 완료된 상태에서 수정하는 것보다, 초기단계에 수정하였을 때 훨씬 수정이 용이합니다. 그러므로 초기 단계부터 보안을 고려한다면, 설계 및 개발 단계 이후에 발견되는 보안 취약점을 조기에 식별하고 미리 수정할 수 있어 그에 따른 시간과 비용을 절감할 수 있습니다.

카카오뱅크는 오픈 이래로 지금까지 다양한 영역에서 서비스를 지속적으로 확장해 왔는데요. 이에 발맞춰 릴리즈 속도🚀 또한 점점 더 빨라졌습니다. 이에 따라 저희 블루팀은 다음과 같은 몇 가지 우려사항에 직면했습니다. 😔

  • ✔️ 테스트 단계에서 발견된 취약점의 수정 비용은 초기 수정에 비해 상대적으로 큼
  • ✔️ 서비스 확대 속도에 맞춰 수동 점검의 질을 유지하는 데 어려움이 있음
  • ✔️ 공격자 중심의 보안 대응 체계로는 보안 위협을 효과적으로 제거하고 예방하기 어려움

이러한 우려사항에 대응하기 위해 저희 블루팀에서는, 취약점 점검 프로세스를 자동화하고 지속적인 테스트를 통해 보다 빠르고 효과적인 취약점 식별 및 조치 방안에 대해 고민하기 시작했습니다.

보안 검사의 종류: 정적/동적 점검

‘보안 자동화’는 개발 프로세스의 보안 활동을 자동화함으로써 보안을 강화하고 효율성을 증진시키는 데 목적을 둡니다. 또한 보안 자동화는 무엇보다도 코드 통합부터 테스트, 배포, 모니터링에 이르기까지 모든 단계에서 발생할 수 있는 ‘휴먼에러(Human Error)‘를 줄이는 데 큰 도움이 됩니다. 이를 통해 전반적인 보안의 수준을 높이며, 다양한 보안 위협으로부터 카카오뱅크 대내외 시스템을 안전하게 보호할 수 있습니다.

여기서 보안 자동화의 주요 요소는 다음과 같습니다.

  1. 보안 검사 자동화: 정적 코드 분석 도구를 사용해 코드 내 취약점을 식별하거나, 취약점 스캐너를 통해 소프트웨어나 시스템의 취약점을 탐지하는 등, 보안 검사를 자동화하여 보안 정책의 준수를 지원합니다.
  2. 보안 이벤트 모니터링 및 대응 자동화: 비정상적인 네트워크 트래픽 감지 및 차단, 악성 파일 자동 격리 등을 포함하여 보안 이벤트를 모니터링하고 신속하게 대응함으로써 보안 위협에 적극적으로 대처합니다.
  3. 보안 정책 및 규정 준수 자동화: 규정 준수를 자동으로 평가하고 보고서를 생성하거나 관련 요구사항에 맞는 구성 변경을 자동으로 적용하여 규정 준수를 달성하고 유지합니다.
  4. 보안 인프라 및 환경 구축 자동화: 인프라 보안 구성을 자동으로 적용하고, 모든 환경을 일관되게 유지하여 보안을 강화하고 관리 비용을 절감합니다.

보안 자동화 접근법은 작업 효율성을 높이고, 보안 위협 대응에 더 많은 자원을 할당할 수 있게 만들어 줍니다. 이는 전체적인 보안 프로세스를 견고하게 만들어 조직의 보안을 강화하고, 체계적으로 관리 및 운영하는데 큰 이점을 제공합니다. 이 중 보안 검사 자동화는 ‘취약점 점검 단계’를 포함하는데요. 취약점 점검 단계란, 소프트웨어나 시스템에서 보안 취약점을 발견하고 이를 해결하기 위한 프로세스를 자동화하는 것을 의미합니다. 이때 취약점 점검을 자동화하는 작업은 대부분 ‘정적 점검’과 ‘동적 점검’이라는 2가지 주요 접근 방식을 사용합니다.

1. 정적 점검(Static Analysis)

‘정적 점검’은 실행되지 않은 상태의 소스코드, 바이너리 파일 또는 구성 파일을 대상으로 소프트웨어 취약점을 분석하는 과정입니다. 이 과정은 코드 구조, 로직, 변수 사용 등을 검토하여 보안 관련 문제를 식별합니다. 이때 ‘정적 점검 도구’로 취약점을 자동 점검하여, 이를 통해 보다 효율적인 보안 관리가 이루어질 수 있습니다.

카카오뱅크에서는 정적 취약점 점검 도구를 지속적 통합(CI, Continuous Integration) 시스템과 연동하여, 코드 커밋 시 자동으로 취약점 검사를 실시합니다. 점검 대상의 언어와 룰셋(Ruleset)에 대해서는 주기적으로 검토 작업이 이루어지며, 필요에 따라 커스텀 룰셋을 추가하기도 합니다.

잠깐! 여기서 룰셋(Ruleset)이란? 🤔
소스코드의 잠재적 버그, 보안 취약점 등을 식별하기 위해 사용되는 규칙을 의미합니다. 예를 들어 소스코드에 하드코딩된 사용자 비밀번호나 API 키가 존재하지는 않은지, 사용자 입력이 SQL 쿼리에 직접 삽입 가능한지 등을 탐지하는 규칙이 있습니다.
이러한 절차를 통해, 개발자는 코드 작성 단계에서 발생할 수 있는 실수나 보안 이슈를 조기에 발견하고 수정할 수 있습니다.

3-static-analysis-review
[그림 3] 정적 취약점 점검 결과를 알려주는 담당자 리뷰

2. 동적 점검(Dynamic Analysis)

‘동적 점검’은 실행 중인 소프트웨어의 동작을 분석하여 취약점을 식별합니다. 웹 애플리케이션, API, 네트워크 서비스 등에 대한 테스트가 동적 점검에는 포함될 수 있습니다. 동적 점검은 실행 중인 소프트웨어가 대상이기에, 보다 실제 발생가능한 시나리오를 고려하여 보안 취약점을 발견하고 대응책을 수립하는 데 있어 효과적입니다.

카카오뱅크에서는 웹사이트와 API를 대상으로 동적 점검을 수행하고 있습니다. 웹 서비스의 경우, 프론트엔드(Frontend) 단의 코드를 기반으로 도구가 url 경로를 크롤링(Crawling)하여 요청을 보내는 형태의 동적 점검이 이루어집니다. 이와 달리 모바일 앱의 경우, 서버로 요청되는 특정 API를 대상으로 요청/응답값의 유효성을 검증하여 취약점을 식별하고 있습니다.

특정 API를 대상으로 동적 점검을 하기 위해서는 API 문서가 필요한데요. 직접 작성한 API 문서를 개발자가 동적 점검 담당자에게 제출하거나, 시스템을 통해 소스 코드에 남긴 주석을 기반으로 API 문서를 자동 생성하는 방식을 지원하고 있습니다. ‘동적 점검 도구’는 앞서 설명드린 방식으로 확보한 API 문서를 기반으로 요청을 조작하여 취약점 점검을 위한 공격을 수행합니다.

4-api-documentation
[그림 4] API 문서를 통한 동적 취약점 점검

취약점 자동화 진단 서비스, VulShot의 탄생

취약점 점검 자동화 프로세스는 요청 단계에서부터 자동으로 취약점을 점검하고, 발견된 문제를 관리 및 추적하는 전 과정을 포함합니다. 현재도 이를 위한 다양한 오픈소스 툴과 상용 솔루션들이 존재하지만, 저희는 단순한 점검 및 관리의 역할을 넘어서 사용자들에게 가이드를 제공하고, 보안에 대해 자유롭게 논의할 수 있는 플랫폼을 목표로 하고자 했습니다. 이를 위해 여러 도구를 테스트해보는 과정에서 고심을 거듭한 끝에, 마침내 카카오뱅크 내부 임직원들에게 딱 맞는 취약점 자동화 진단 서비스를 자체 개발하기로 결정했습니다.

그럼 간략하게 개발 과정을 짚어보며, 적용했던 기술과 그로부터 배운 점들에 대해 공유드리겠습니다. 😉

1. 서비스 목표 🎯

저희는 아래의 3가지 측면을 중점적으로 고려하여 개발을 시작했습니다.

(1) 편리성

개발자 A🧑‍💻: 보안 검사 프로세스가 복잡해서 어려움을 겪고 있어요. 어떻게 해야 할까요?

은행의 IT 환경은 망분리 정책을 시행함에 따라, 일반적으로는 점검 작업이 까다로울 수 있습니다. 이러한 제약으로 인해 자체 점검을 시도하는 개발자들은 종종 방화벽 문제로 어려움을 겪는데요. 이러한 경험이 쌓이다 보면, 결과적으로 점검에 대한 심리적 장벽을 높아지게 만들죠. 이를 해결하기 위해 취약점 점검 자동화 서비스에서는 점검 대상 사이트의 방화벽 정책을 자동으로 확인하고, 결과에 따라 방화벽 정책 신청을 지원하는 기능을 추가하여 사용자의 편의성을 높이고자 했습니다.

개발자 B👩‍💻: 보안 취약점이 나오긴 했는데, 이를 어떻게 조치해야 되나요?

보안 취약점 점검 후, 개발자들이 특히 어려워하는 부분은 조치 방안을 마련하는 것입니다. 취약점이 발견되면 필수적으로 조치를 취해야 하지만, 보안에 대한 지식을 보유한 분이라 할지라도 자신이 모르는 부분에 대해서는 적절한 해결 방법을 찾기가 어려울 수 있습니다. 이는 자동화 진단 서비스를 준비하는 단계에서 개인적으로 가장 크게 우려한 부분 중 하나였습니다. 이를 위해 자동화 진단 서비스를 개발하며 발견된 취약점들을 예시로, 취약점을 어떻게 수정할지에 대한 사용자 가이드를 제공하고자 했습니다.

(2) 보안성

개발자 C🧑🏻‍💻: 자동화 점검으로 전반적인 취약점을 전부 스캔했다고 보면 되는 걸까요?

카카오뱅크 서비스의 출시 속도가 빨라지고 점점 더 확장되면서, 보안 점검 담당자로서 ‘우리가 일정 수준의 점검의 퀄리티를 유지할 수 있을까?‘에 대해서도 고민하기 시작했는데요. 이를 극복하기 위해 자동화 점검 서비스에서는 전반적인 취약점 스캔은 물론이고, 일정 수준의 보안성 확보하고자 했습니다. 이에 광범위한 전수 테스트 과정을 거친 자동화 기술을 도입하여 전반적인 취약점 스캔을 효율적이면서도 정확하게 진행하고자 했습니다.

(3) 효율성

개발자 D👩🏽‍💻: 취약점을 진단하려고 하는데요, 혹시 웹(Web)에서 할 수 있을까요?

이번 프로젝트를 통해, 기존에 사용하던 상용 솔루션을 카카오뱅크의 개발 프로세스에 맞춰 웹 서비스 형태로 개발하여 더 많은 사용자가 쉽게 접근할 수 있도록 개선하고자 했습니다. 또한, 일부 커스터마이징을 통해 기존 상용 솔루션으로는 점검하기 어려운 영역들도 함께 내재화하여 개발하고자 했습니다.

2. 점검 대상 항목 📌

앞서 설명드렸던 DevSecOps의 취지에 걸맞은 개발을 하기 위해, 사용자가 보안에 대한 깊은 배경지식이나 추가적인 작업 없이도 손쉽게 보안성 점검을 수행할 수 있도록 했습니다. 또한, 보안 점검의 결과를 내부 증적으로 축적하고 관리함으로써 외부기관 심사에 대비 및 활용하고자 했습니다.

더욱이 은행의 보안 취약점 점검 서비스였기에 전자금융기반시설 웹/모바일 애플리케이션 점검 항목을 우선적으로 검토하였고, 자체 스코어링 작업을 통해 ‘필수 점검 항목’과 ‘전체(Full) 점검 항목’을 각각 도출했습니다.

이때 ‘영향도’를 산정하기 위해 팀에서 자체적으로 3가지 요소를 기반으로 한 “영향도 공식“을 만들었는데요. (1) 피해의 심각성 및 기술적 영향도, (2) 공격벡터, (3) 파급도 각 항목에 대해 평가 결과를 점수화하여 High, Medium, Low 등급을 부여했습니다. 최종적으로는 아래와 같은 계산식을 통해 영향도를 측정하게 됩니다.

5-vulnerability-impace-formula-image

현재 모든 점검 대상에게는 기본적으로 전체(Full) 점검 항목을 권장하고 있으며, 담당자의 주기적인 검토를 통해 지속적으로 점검 항목들을 추가 및 보완해나가고 있습니다.

3. 주요 기능 ✅

위의 복잡다단한 고민 과정과 시행착오를 거쳐 2023년 8월, 마침내 개발단계부터 개발자가 직접 취약점을 스캐닝해 볼 수 있는 VulShot(Vulnerability Shot) 서비스가 오픈했습니다. 해당 서비스에서 제공하는 주요 기능을 소개드리면 다음과 같습니다. 🤩

  • ✔️ 웹 사이트 취약점 스캔
  • ✔️ API 취약점 스캔
  • ✔️ 모바일 보호로직 체크

서비스의 구성에 따라 웹 사이트/API에 대한 동적 점검을 수행할 수 있고, 모바일 앱 배포 전 보호로직 점검을 통해 보호로직이 잘 적용되었는지를 점검할 수 있습니다.

6-vulshot-main-feature-image
[그림 5] VulShot 서비스의 주요 기능

VulShot을 통한 사용자 중심 취약점 점검

앞서 설명드린 것처럼 VulShot에는 서비스의 취약점 점검을 위한 다양한 기능이 포함되어 있는데요. VulShot에서는 개발자가 직접 자유롭게 점검할 수 있는 ‘셀프(self) 점검’은 물론, 신규 서비스의 보안성 심의 및 대내외 중요 서비스에 대해 ‘정기 자동 점검’도 지원합니다. 그중 사용자 점검 시나리오를 활용하여 어떻게 취약점을 점검하는지 보여드리겠습니다.

아래 예시는 사용자가 VulShot에서 취약점 점검을 수행하는 시나리오인데요.

7-vulshot-user-senario-image
[그림 6] VulShot을 활용한 사용자 점검 시나리오

먼저 VulShot 사이트에서 접속한 뒤, 취약점 점검 요청 단계에서는 아래 3가지의 점검 요청을 선택을 할 수 있습니다.

  1. 웹 사이트에 대한 취약점 점검을 수행할 것인지
  2. API에 대한 취약점 점검을 요청할 것인지
  3. 모바일 보호로직 점검을 수행할 것인지

이 중 선택한 종류에 따라 취약점 점검이 수행되며, 점검이 완료된 후에는 점검 결과를 담은 알림 메시지가 자동으로 사용자에게 발송됩니다.

8-alarm-message-image
[그림 7] 점검 완료 알림 메시지 (예시)

알림 메시지를 받은 사용자는 VulShot 사이트에 다시 접속하여 점검 결과를 확인한 후, 취약점이 있는 경우 가이드를 참고하여 취약점을 조치합니다. 취약점 결과 페이지에 하단에는 댓글 기능이 있어, 해당 이슈에 대해 담당자와 어떻게 취약점 조치를 할지 등을 논의할 수도 있습니다. 가이드와 질의응답을 통해 취약점 조치가 완료되면, 사이트에서 재점검 요청을 통해 취약점이 잘 조치되었는지 담당자에게 확인 요청을 할 수 있습니다.

9-vulshot-test-result-sql-injection-issue-image
[그림 8] 점검 결과를 확인할 수 있는 취약점 상세 결과 페이지 (예시)

정적 점검과 동적 점검 모두 CI/CD 파이프라인 구동 기능도 지원하고 있는데요. GitLab에서 정적점검 파이프라인을 연동하면 소스코드 커밋 시에 자동으로 정적 점검을 수행할 수 있고, 배포 다음 단계에 동적 점검 연동 시 배포된 서비스를 대상으로 동적 점검을 수행합니다. 개발/테스트 서버의 경우 배포가 수시로 일어나기 때문에 배포 시 마다 동적 점검을 수행하기엔 적합하지 않을 수 있는데요. 이에 따라 파이프라인 연동 외에도 점검 주기를 설정하여 하루에 한번 특정 시간에 점검을 수행하도록 설정할 수도 있습니다.

10-ci-cd-flow-chart-image
[그림 9] CI/CD 보안 점검 순서도

이외에도 자주 발생하는 취약점에 대한 시큐어 코딩(Secure Coding) 가이드, 정적 점검과 동적 점검의 결과를 통합 분석하는 하이브리드 분석(Hybrid Analysis), 정적/동적 분석의 배포 증적 생성 자동화 및 관리 기능 등을 제공하고 있습니다. 앞으로도 사내 개발자가 보다 편리하게 VulShot 서비스를 사용할 수 있도록 여러 편의 기능과 점검 도구의 성능을 고도화하기 위한 추가 개발을 계획하고 있습니다.

11-vulshot-website-screenshot-image
[그림 10] VulShot 서비스에서 이용 가능한 다양한 기능들

마무리하며

VulShot은 카카오뱅크에 합류한 이후, 제 손으로 직접 탄생시킨 첫 번째 서비스인데요. ‘예방 주사’를 의미하는 ‘Shot’에다가 ‘취약점’을 뜻하는 ‘Vulnerability’의 앞 글자를 따와서 만든 VulShot의 담당자로서, 그만큼 더 애정을 가지고 해당 서비스를 발전시켜 나가고 있습니다.

특히 DevSecOps 개념을 적용하면서 조직 내에서 DevSecOps를 원활하게 도입하고자 할 때, 조직 간의 원활한 소통과 협업이 필수적임을 깨달았습니다. DevSecOps 체계를 구축하는 과정에서 많은 담당자들과 요청을 주고받으며 여러 유관 부서와의 협업을 진행했는데요. 그때마다 항상 적극적으로 지원해 주시고 참여해 주신 모든 분들께 진심으로 감사드립니다. 이렇게 탄생한 VulShot 서비스는 보안 점검에 대한 전문가가 아니더라도 누구나 쉽게 사용할 수 있는 보안 플랫폼을 목표로 합니다. 그리고 이 목표를 실현하는 것이 블루팀에서 제가 맡은 역할이라 생각합니다. 🙋‍♀️

그럼 앞으로도 카카오뱅크 안에서 DevSecOps 개념이 잘 뿌리내리고, 모두가 자연스럽게 DevSecOps가 적용된 서비스와 환경을 누릴 수 있도록 계속해서 노력하겠습니다. 감사합니다.