GitLab은 유일무이한 진정한 엔드 투 엔드(end-to-end) DevOps 플랫폼입니다. GitLab은 더 높은 수준의 보안을 지원하는 동시에 최신 애플리케이션 개발 이슈를 해결할 수 있도록 지원합니다. GitLab은 SCM과 CI 모두에서 인정받는 리더기업이며, 최근에는 애플리케이션 보안 분야의 유망주이기도 합니다. GitLab은 DevOps 플랫폼에 보안 기능을 구축했으며, 업계 분석가들은 GitLab의 보안 기능을 포인트 타 보안 솔루션과 직접 비교한 다양한 보고서를 작성하였습니다.
GitLab과 같은 통합 플랫폼은 다음과 같은 개별 툴이 제공할 수 없는 장점을 가집니다.
- 전체적인(End-to-End) 가시성 및 감사 가능성: 누가 무엇을, 어디서, 언제 변경했는지.
- 일관된 정책 적용 및 관리: 어떤 정책이 어디에 사용되는지, 예외에 대해 수행되는 모든 작업.
- 보다 광범위한 엔드 투 엔드 컨텍스트를 통한 더욱 지능적인 대응.
- 단순화된 툴 체인의 공격 표면 감소.
애플리케이션 보안을 강화하기 위한 4단계
스타트업에서 글로벌 기업에 이르기까지 약 3천만 명 이상의 사용자가 있는 GitLab은 보안을 깊이 있게 고려해야 합니다. 다음은 강력한 DevSecOps 플랫폼과 종합적인 보안 프로그램을 결합하여 소프트웨어 공급망을 신속하게 제어하고 파악할 수 있도록 지원하는 4가지 방법입니다. 보안 강화를 위해서는 부서 간 협업과 함께 인력, 프로세스 및 툴의 조합이 필요합니다.
1단계: 새로운 공격 표면을 고려하여 보안 위생 상태를 평가합니다.
가장 피해가 큰 공격조차도 기본 보안(패치나 암호 등)의 안일함을 파고드는 경향이 있으며 오랜 기간 동안 사용된 공격 방법을 사용합니다. 새로운 권장 사항은 아닐 수 있지만, 보안의 범위를 넓혀 다음과 같이 권장합니다. 보안 정책을 다시 살펴보고 소프트웨어 개발 툴 체인, 컨테이너, Orchestrator 및 인프라와 같은 새로운 공격 영역을 코드로 고려하십시오. 보안(secret)이 탐지 되는지 확인하세요. MFA(Multi-Factor-Authentication)가 사용되는지 확인하세요. 관리자 설정(admin setting)에서 가시성 및 액세스 제어(Control access and visibility)를 확인하세요.
2단계: 스캔, 정책 및 규정 준수 자동화
표준화된 CI 파이프라인 내에서 보안 스캔을 자동화하세요. 대부 분의 사용자는 SAST 및/또는 페너레이션 테스트를 사용하고 더 많은 사용자가 dependency 스캐닝을 추가하고 있습니다. 각 스캔 유형은 다양한 유형의 취약성을 발견하지만, 포인트 솔루션을 사용하여 애플리케이션 프로젝트 전체에 광범위한 스캔을 적용하는 경우 막대한 비용이 발생할 수 있습니다. 여러 스캔 유형을 다른 기종 툴 체인에 통합하려고 하면 복잡성과 비용이 가중됩니다.
GitLab의 단일 플랫폼에는 SAST, DAST, dependency, container scanning, secrets detection, API 퍼징을 포함한 fuzz testing 등을 통해 앱 보안 스캔이 포함됩니다. GitLab 앱 보안 스캔을 통해 다음 세 가지 작업을 수행할 수 있습니다.
- 서드 파티 코드와 컨테이너 코드를 포함한 모든 코드를 검색합니다. GitLab Ultimate의 Auto DevOps 기능을 통해 사용되는 보안 스캔을 쉽게 구성할 수 있습니다.
- 코드의 모든 변경 사항을 스캔합니다. GitLab의 내장 앱 보안 테스트는 하나의 공통 UI로 여러 스캔 방법을 사용하여 코드의 모든 변경을 검사합니다. GitLab CI 기능 내의 리뷰 앱을 활용하여 CI 파이프라인 내에서 DAST를 실행할 수도 있습니다. 코드가 기본 브랜치에 push 되기 전에 스캔이 수행되므로 공유 환경에 대한 취약점을 줄일 수 있습니다.
- Fuzz Testing을 사용하여 알려진 CVE의 서명이 없는 안전하지 않은 논리 결함을 찾습니다. GitLab의 보안 스캔에는 웹 API에 대한 커버리지 기반 테스트와 동작 테스트가 모두 포함됩니다. fuzz 테스트는 다른 스캐너와 함께 CI 파이프라인에 통합되어 있기 때문에 결과를 쉽게 사용할 수 있으며 독립형 fuzz 테스트보다 설정이 쉽습니다.
자동화는 매우 좋은 기술이지만, 표준화되고 제어된 CI 프로세스에도 적용되어야 합니다. CNCF는 "소프트웨어 공급망을 최대한 자동화하면 인적 오류와 구성 드리프트 가능성을 크게 줄일 수 있습니다.”라고 당부합니다. 모든 프로젝트에 사용할 수 있는 표준화된 CI 템플릿을 사용해야 하는지, 업계 표준에 규정 준수를 자동으로 적용하는지, 취약점이 발견될 때 예외 정책이 있는 MR을 누가 승인할 수 있는지에 대한 의문을 가져야 합니다.
정책을 자동화하면 더욱 일관된 규정 준수를 보장하는 동시에 감사 작업도 줄어듭니다. CI/CD 자동화는 다음과 같은 공통된 제어 기능을 적용합니다.
- Merge Request 업무 분리
- ID 및 액세스 승인 제어
- 구성 관리 및 변경 제어
- 구성 및 파이프라인 변경에 대한 액세스 제한
- protected 브랜치 및 환경
- 감사(Auditing)
- 라이센스 코드 사용
- 보안 테스트(Security testing)
GitLab Ultimate는 단일 DevOps 플랫폼 내에서 많은 컴플라이언스 기능을 제공합니다. 수많은 컴플라이언스 기능, 컴플라이언스 관리 및 감사 보고서와 함께 컴플라이언스 대시보드가 포함됩니다. 즉, 정책이 일관되게 적용될 수 있도록 가능한 한 자동화를 적용합니다.
3단계: 소프트 웨어 팩토리 자체 보안
GitLab의 DevOps 플랫폼은 액세스와 소프트웨어 팩토리 정책, 그리고 측정할 수 있는 반복 프로세스를 한 곳에서 관리하여 소프트웨어 팩토리 자체를 보호하는 데 필요한 작업을 단순화합니다. GitLab의 보안 팀은 다음과 같은 모범 사례와 프로젝트에 대한 블로그 기사를 제공합니다.
- 제로 트러스트(Zero Trust) 원칙을 적용(최소 권한 액세스와 같은 개념)합니다. GitLab은 제로 트러스트를 통해 리모트 환경을 완벽히 보호합니다.
- 새로운 기술의 지속적인 통합은 생산성과 보안 모두에 중점을 두고 있습니다. 예를 들어, Hashicorp Vault와의 통합에서는 공급망 환경에서 운영되는 모든 엔티티가 정기적인 키 순환으로 강화된 인증 메커니즘을 사용하여 상호 인증하도록 요구할 수 있습니다.
- GitLab 인스턴스 강화를 권장합니다. GitLab 인스턴스 강화의 가장 좋은 사례는 제품을 개선하고 프로세스를 더욱 강화하기 위한 공개 프로젝트가 진행될 때 실행하는 것입니다. 강화된 UBI 기반 클라우드 기본 GitLab 이미지는 정기적으로 확인 및 검증해야 합니다.
- CI/CD 변수는 파이프라인의 동작을 제어할 수 있습니다. 범위 환경은 CI/CD 변수를 사용할 수 있는 환경(예: production)을 정의하여 CI/CD 변수의 범위를 제한할 수 있습니다.
4 단계: 지속적인 평가 및 개선과 함께 반복
최신 소프트웨어 공급망을 보호하려면 위의 1~3단계를 지속해서 재검토해야 합니다. 툴 체인 또는 환경이 복잡할수록 앱과 공급망을 보호하는 데 있어 최신 상태를 유지하는 것이 더 어려워집니다. 현대의 애플리케이션 개발 프로세스에서는 소프트웨어 팩토리가 빌드된 후 코드를 검사하는 대신 보안 및 제어에 대한 툴링을 통해 소프트웨어 팩토리의 새로운 사고방식을 요구합니다. 새로운 사고방식은 특히 비용을 더 투자해야 하는 기존 툴에 부담을 느낄 수 있습니다.
보안 기능이 내장된 GitLab의 DevOps 플랫폼은 소프트웨어 공급망 보호의 지속적인 개선을 할 수 있지만 확실히 보장되지는 않습니다. 만약 Solarwinds 사태와 같은 고도로 표적화된 공격이 지속된다면, 최고의 방어 조치에도 취약점이 발견될 수 있습니다. GitLab이나 다른 어떠한 벤더도 공급망 공격과 같은 사태로부터 고객을 보호할 수 있다고 말할 수 없습니다. Defense-in-Depth 전략은 항상 최고이며 GitLab과 같은 단일 DevSecOps 플랫폼의 단순성은 작업을 단순화하고 가시성 및 컨트롤 포인트를 개선할 수 있는 강력한 보안 기능입니다.
원문: https://about.gitlab.com/blog/2021/04/28/devops-platform-supply-chain-attacks