관련링크

지난 포스팅에선 네트워크 및 사용자 분리 등에 대해 말씀드렸습니다. 이러한 정책적인 보안성 수준 향상을 진행하면서 제일 고민한 부분이 개발 환경의 보안 수준 향상입니다. 개발 효율성 및 생산성을 놓치지 않고, 실질적인 보안성 향상에 도움이 되는 정책 및 기술을 적용하고 싶었습니다. 또한 현재 진행하고 있는 개발 프로세스를 크게 벗어나지 않길 바랐습니다.

단순히 보안 인증 취득에서 끝나는 것이 아니라 제품의 보안성 향상에 초점을 맞추었으며, 운영 관점뿐만 아니라 개발 관점에서도 도움이 되는 프로세스를 수립하는 것이 목표였습니다.

1. 시큐어코딩

와탭랩스는 Github를 이용해 코드 관리를 하고 있으며, Jenkins를 이용하여 개발, 운영 환경에 빌드 및 배포하고 있습니다. 또한 jira를 이용하여 모든 이슈를 추적하고 있습니다.

위 과정에 시큐어 코딩 분석 및 수정 단계를 도입하여 문제 상황을 사전에 차단하였습니다.

1) 시큐어 코딩 프로세스 수립

시큐어 코딩 서비스의 조건은 아래와 같습니다.

• 기존에 사용하고 있는 Github와 Jira 연동 가능
• 정적 분석, 오픈소스 종속성, 취약점 분석 등 다양한 기능
• 낮은 오탐 가능성

오픈소스, 유료 서비스 등 다양한 서비스의 파일럿을 진행하였습니다. 각 서비스별 장/단점이 명확하게 존재했으나 내부 프로세스와 가장 적합한 snyk를 도입하였습니다. github에 코드가 commit 되면 연동된 snyk 플러그가 시큐어 코딩을 체크합니다. 코드 취약점이 발생하게 되면 jira에 자동으로 취약점 티켓을 생성합니다. 생성된 티켓을 기반으로 개발팀에서 오탐여부를 판단한 후 취약점 조치를 진행합니다.

최종적으로 수립한 시큐어 코딩 프로세스는 다음과 같습니다.

• 개발자가 Github에 와탭 코드를 commit합니다.
• 와탭 프로젝트에 연동된 snyk가 자동으로 취약점을 탐색합니다.
• Jira에 취약점별로 티켓이 생성됩니다.
• 개발자가 해당 티켓의 오탐 여부를 판단합니다.
• 오탐이 아닌 경우 해당 취약점을 수정합니다.
• 수정된 취약점을 Github에 commit한 후 Jira 티켓을 close합니다.

Jira에 시큐어 코딩 증적 자료가 남게 되어 인증 취득에 엄청난 도움이 되었습니다.

현재는 Github와 Jira만 유료플랜으로 사용하고 있으며 snyk는 무료 플랜을 이용하고 있습니다. 탐지한 취약점의 보고서 기능이 존재하지 않는 것이 무료 플랜의 가장 큰 차이점이었지만 연동된 Jira 기능을 이용하여 보고서 생성이 가능하며, 이를 인증 증적 자료로 충분히 사용할 수 있습니다.

또한, 쉽게 알기 어려운 여러 취약점을 알 수 있는 프로세스가 수립되어 제품 내부 보안성 향상에 큰 도움이 되었습니다.

2. 클라우드 저장소 검토

와탭랩스는 100% 클라우드 환경으로 모든 데이터는 클라우드 저장소에 보관하고 있습니다. KMS, eSigner CKA과 같은 클라우드 서비스를 이용하고 있지만, 서비스를 사용할 수 없는 여러 인증서, 액세스 키 등 내부에서 사용하는 중요한 인증 데이터가 외부에 노출될 가능성이 언제나 존재하였습니다. 이를 탐지할 방법이 필요했습니다.

1) 탐지할 저장소 선택

탐지할 저장소는 아래와 같습니다.

• AWS S3
• Github repository

2) 탐지 방법

Github, S3, docker 등 다양한 저장소 탐지를 지원하는 오픈 서비스인 TruffleHog를 이용하여 주기적으로 취약점을 탐지하고 있습니다.

특히, 하드코딩된 개인키, 비밀키를 탐지할 수 있을 뿐만 아니라 pdf, 인코딩된 텍스트, 이미지 등에서도 탐지가 가능합니다.

와탭은 아래 2가지의 클라우드 저장소를 탐지하고 있습니다.

• S3 탐지 : IAM role을 이용하여 S3의 모든 버킷을 스캔합니다.
• Github 탐지: Github Action을 이용해 전체 repository를 스캔합니다.

   Found verified result 🐷🔑Detector Type:Decoder Type:Raw result:Rotation_guide:Project:Commit:Email:File:Line:Repository:Timestamp:
   

위 형식은 Github 탐지 양식이며, 이 밖에 저장소 별로 지원 양식은 상이합니다.

3) 탐지 후 조치

탐지 결과 양식을 살펴보시면 commit 이력과 함께 타입을 확인할 수 있습니다. 오탐 여부를 판단하신 후 오탐이 아닌 경우 담당자를 통해 조치를 진행합니다.

이때, 단순히 조치만 진행하는 것이 아니라 추후 동일 이슈 방지를 위해 해당 파일, 데이터가 올라게된 원인을 파악하여 전 개발자에 공유합니다.

취약점을 탐지하는 것도 중요하지만 이를 방지하는 것이 더 중요하기 때문입니다. 퍼블릭 저장소는 사용자 실수로 잘못된 데이터를 업로드할 가능성이 매우 크기때문에 주기적으로 취약점을 탐지하는 것을 추천드립니다.

다양한 저장소 탐지를 지원하는 오픈 서비스인 TruffleHog 홈페이지 바로가기

마지막 3탄에서는 규정/지침/절차 검토 사항, 개인정보 암호화 가이드 등 인증을 위해 필요한 절차들을 설명드리도록 하겠습니다.