DevSecOps는 개발 및 운영 프로세스에 보안을 통합하는 핵심적인 IT 전략입니다. 다시말해, 개발의 시작인 코드 작성부터 배포 및 운영까지 소프트웨어 개발의 모든 단계에서 보안을 고려하는 것을 의미합니다. 이는 조직의 전반적인 보안 태세를 개선하고 더 안전한 소프트웨어를 제공하는데 있어 매우 강력한 방법이며, 이를 위해서 조직의 문화적 변화가 필요합니다.
DevSecOps의 주요 이점으로는 크게 5가지가 있습니다.
보안 취약점 감소: 개발 프로세스의 초기 단계부터 보안 취약점을 식별하고 해결하여 취약점을 효과적으로 제거할 수 있습니다.
빠른 개선 속도: 자동화된 테스트 및 배포를 통해 빠르게 보안 취약점을 개선하고 출시 속도를 높일 수 있습니다, 보안 요구사항을 서비스 개발의 마지막 단계에서 진행하는 것이 아닌, 지속적인 단계에서 보안 검수를 진행함으로 빠른 개선을 기대할 수 있습니다.
향상된 규정 준수: 규정 요구 사항을 개발 프로세스에 통합하여 규정 준수를 유지하는 데 도움이 됩니다.
비용 절감: 보안 결함으로 인한 비용을 줄이고 운영 효율성을 향상시킵니다.
협업 향상 및 보안 문화 개선: 개발, 보안 및 운영 팀 간의 협업을 통해 조직에 보안 문화를 개선할 수 있습니다.
DevSecOps는 6개의 단계로 구분지어 도입할 수 있습니다.
계획 및 준비: DevSecOps의 목표, 범위 및 성공 기준을 조직적으로 정의합니다.
문화 및 프로세스 변화: 조직 문화를 보안 중심으로 바꾸고 보안을 개발 프로세스에 통합합니다.
도구 및 기술 선택: 요구사항을 충족하는 적절한 DevSecOps 도구 및 기술을 선택합니다.
자동화 및 통합: 지속적 통합/지속적 배포(CI/CD) 파이프라인, 자동화된 보안 테스트 및 보안 모니터링을 적용하고 통합합니다.
측정 및 보고: DevSecOps의 목표를 측정하고 보고합니다.
지속적인 개선: 프로세스의 효율성을 지속적으로 개선하고 새로운 기술을 도전적으로 도입합니다.
DevSecOps의 구현 어려움?
많은 조직이 DevSecOps의 효율성을 알고, 도입을 시도하지만 구현 과정에서 다양한 어려움에 직면할 수 있습니다. 크게 5가지 정도의 구현/도입 어려움이 있는데요.
문화적 변화 DevSecOps의 가장 큰 어려움이라고 하면 엔지니어링 조직 문화를 변화시키는 것입니다. 개발, 보안 및 운영팀은 종종 서로 다른 목표와 우선순위를 가지고 있으며, 효과적으로 협력하기 위해서는 이러한 차이를 해소해야합니다. 성공적인 구현을 위해서는 조직 전체에서 보안을 중요시하는 문화를 조성해야합니다.
프로세스 및 도구 통합 개발, 보안 및 운영 프로세스를 통합해야합니다. 이는 다양한 팀에서 사용하는 다양한 도구를 통합하는 복잡한 작업이 될 수 있습니다. A팀은 CI/CD 파이프라인 중 Github Action을 이용하고 있고, B팀은 Jenkins를 이용하고 있다면 이는 도구를 통합하는데 있어 큰 장애물이 될 수 있습니다. DevSecOps를 성공적으로 구현하려면 조직은 프로세스와 도구를 서로 원활하게 통합하고 연동할 수 있게 구현해야 합니다.
전문 지식 부족 개발, 보안 및 운영분야의 전문 지식이 필요합니다. 각 팀의 지식 차이가 크고 목표에 대한 이해도가 다르다면 DevSecOps의 목표를 성공적으로 구현하고 유지 관리하는데 큰 비용이 발생할 수 있습니다. 즉, 조직적인 보안 전문 지식의 전체적인 수준을 향상시키는 것이 중요합니다.
지속적인 교육 및 훈련 DevSecOps는 지속적인 통합과 배포뿐만 아니라, 지속적인 교육과 훈련도 필요로 합니다. 엔지니어링 조직은 DevSecOps의 방법론 및 모범 사례에 대한 지식 수준을 유지해야 하고, 성공적인 구현을 위해 엔지니어링 팀은 지속적인 교육 및 훈련 기회를 제공받아야 합니다. 또한 구축 된 DevSecOps의 모범사례를 문서화 등으로 지속적인 공유가 이루어져야 합니다. .
측정 및 보고 DevSecOps의 성공을 측정하고 보고하는 방법을 확립해야 합니다. 이를 통해 엔지니어링 조직은 DevSecOps 목표 달성 여부를 지속적으로 확인할 수 있으며, 미비한 부분을 보완하기 위한 접점을 확인할 수 있습니다.
DevSecOps의 시작, Credential Detection First
DevSecOps를 시작하는 가장 좋은 방법 중 하나는 Credential 탐지부터 시작하는 것 입니다. Credential은 사용자의 아이디, 비밀번호와 같은 모두의 지식수준으로 이해할 수 있는 정보부터, API 키, 클라우드 인증 정보 등 민감한 정보를 포함합니다. Credential 유출의 위협을 엔지니어링 조직에게 설득하는 과정은 그리 어렵지 않습니다.
Credential 탐지는 소스코드, 문서, 협업공간, 로그 및 파일 등을 스캔하여 Credential을 식별하고 조치를 시작할 수 있는 프로세스입니다. DevSecOps의 시작을 Credential Detection 부터 시작한다면 조직은 빠르게 위협을 완화시키는 성공경험을 가질 수 있습니다.
Credential Detection을 DevSecOps의 시작과 함께한다면 장점은 아래와 같습니다.
문화적 변화의 어려움을 노출된 Credential 조치로 빠르게 설득할 수 있습니다. 보안팀의 입장에서 엔지니어링 유관 부서의 설득은 늘 어려운 문제 중 하나입니다. Credential의 설득 과정은 매우 간단합니다. 엔지니어링팀은 아이디와 패스워드를 포스티잇에 적어놓으면 안된다는걸 알고 있습니다. 소스코드에 Credential을 기입하면 안된다라는 쉬운 설득을 통해 DevSecOps 파이프라인을 시작 할 수 있습니다.
Credential Detection 도구를 각 개발의 프로세스와 다양한 협업 도구에 연동하여 모범사례를 만들 수 있습니다.Credential의 탐지도구, 그 중 Cremit은 다양한 도구와 쉽게 통합될 수 있습니다. 또한 영향범위 역시 크게 확대가 가능합니다. 한 예로, 소스코드에 기입되어 있는 Credential을 탐지하는 스캔 기능을 통해 위협을 확인할 수도 있으며 그 이전에 Pre-Commit Hook(소스코드의 commit, 업로드 시점)을 통해 레포지토리에서의 Credential 노출을 막을 수 있습니다. 또한 CI/CD(지속적 통합 및 배포) 도구와도 CLI를 통해 간단히 연동할 수 있으며 배포 전의 전체 단계에서 적용하는 성공 경험을 조직적으로 전파할 수 있습니다. 또한, Confluence, Notion, Jira 등 협업 시 자주 사용하는 도구와 연동되며 내부에 노출된 Credential을 엔지니어링팀과 같이 조치하며 개발단계 뿐만 아니라 조직적인 보안 인식 수준을 높일 수 있습니다.
전문 지식의 부족을 Credential 보안 교육으로 시작해보세요. SAST(Static Application Security Testing) 도구, DAST(Dynamic Application Security Testing) 도구, WAF(Web Application Firewall) 도구 등의 지식을 전파하는건 매우 힘든 일입니다. 한 예로 SQL Injection을 막기 위한 방법으로 ORM의 적용을 권고하고, Prepared Statement의 지식을 전파하는건 오래걸리고 힘든 일 입니다. Cremit의 Credential 탐지 기능을 통해 쉬운 지식(예로, 아이디 패스워드는 안전하게 관리되어야함)을 전파하고, 성공사례를 만들며 전문 지식을 전파하는 시작을 함께할 수 있습니다.
지속적인 교육 및 훈련의 시작도 Credential 탐지로 시작할 수 있습니다. Credential 유출에 대한 위협 교육은 그리 어렵지 않습니다. AWS Access Key가 유출되었을 경우의 훈련을 말씀드리겠습니다. Cremit 제품을 토대로 소스코드 저장소(Github, GitLab)을 스캔하고 노출된 AWS Access Key의 영향범위를 파악합니다. 조직에서 일반적으로 소스코드에 하드코드 되어있는 AWS의 자격증명(Credential)은 다수의 서비스에 사용되고 있을 가능성이 높아 영향범위 파악에는 자동화된 도구의 도움이 필요합니다. 이후 AWS Access Key를 새로 발급하고 AWS KMS와 같은 서비스(또는 Secret Manager 등)을 연동하는 모범사례를 배포합니다. 이를 통해 AWS Access Key가 외부에 유출되었을 경우를 가정한 훈련이 쉽게 완성될 수 있습니다.
측정 및 보고를 통한 지속적인 조직 목표 달성Credential의 내부 유출의 건수를 0건으로 만드는걸 목표로 하고, 지속적인 모니터링을 통해 빠르게 목표에 접근할 수 있습니다. 초기에 내부 노출이 된 Credential의 개수가 100개였다면, 매 달 20건씩 줄이는걸 목표로 5달만에 목표를 달성할 수 있습니다. 또한 이후엔 조직의 목표를 탐색 대상의 확대(Pre-Commit Hook, PR, CI/CD, 내부 문서)를 하며 점진적이며 도전적인 목표를 세워 성공사례를 지속적으로 남기고, 조직에 전파할 수 있습니다.
Cremit으로 시작하는 DevSecOps
Cremit 서비스는 빠르게 DevSecOps를 Self-Onboarding 할 수 있습니다. 어려운 구조를 가진 도구들은 전문가팀(Professional)이 필요할 수 있지만 개발이 필요 없는 방식과 쉬운 구성으로 인해 엔지니어링 팀과의 협업을 쉽게 할 수 있습니다.
엔지니어링팀에게 익숙하며 배포하기 편한 Cremit Ferret CLI 도구는 직관적이고, 이쁘며(사실 중요하지 않겠지만) 다양한 플랫폼에 지원되고 빠릅니다. 아래 예제에서는 Git의 Pre Commit Hook과 Cremit CLI를 연동하는 예제를 설명합니다.
먼저, https://start.cremit.io 에서 계정을 생성 또는 로그인합니다. 이후 Settings > CLI에 접근하여 키를 발급합니다. 해당 키는 CLI의 라벨 설정은 크리덴셜이 발견된 위치를 구분하기 위해 사용되며 Secret Table 등에서 확인하기 위해 사용됩니다. 라벨 설정 이후 발급받은 API Key는 아래 과정에서 사용되니 복사하여 저장해놓으시길 바랍니다.
생성을 하였다면 curl 명령어 또는 Cremit 제품 내에서 Cremit CLI 도구를 다운로드합니다. 현재 지원하고 있는 OS(Operating System)은 Apple MacOS(Intel, Silicon)과 Linux(x86_64, ARM)을 지원합니다.
아래 코드를 작업하는 Git Repository 내 아래 경로에 작성합니다.
.git/hooks/pre-commit
해당 코드는, Active한 Secret이 발견되었을 경우 이후의 단계가 진행되지 않게(exit 1) 하는 코드입니다. 코드 내 [YOUR-TOKEN] 값을 위의 라벨 설정 시 발급받은 키로 변경합니다.
적용 이후 Commit 시Secret Key가 포함된 값이 발견될 경우 아래 영상처럼 동작합니다.
해당 과정 중 발견된 기록은 Cremit 제품 내 Secret Table에서 확인하실 수 있습니다.
이를 통해 보안팀에서는 각 코드 레포지토리 또는 로컬 작업환경과 연계하여 중앙에서 Credential 위협을 모니터링하고 실제 배포되어 발생될 수 있는 위협을 사전에 차단할 수 있습니다.
