개발 보안 분야를 만들거나 현대화할 때 이 문서에서는 보안을 개발 사례에 통합하면 개발자 작업(DevOps)에서 DevSecOps(Developer-security-operations)로 전환할 수 있는 방법을 간략하게 설명하고 애플리케이션 배달을 보호합니다.
최신 조직은 신속한 소프트웨어 개발에 의존하여 혁신을 제공하고, 변화하는 비즈니스 요구 사항에 대응하며, 경쟁 우위를 유지합니다. DevOps를 사용하면 지속적인 통합 및 전달을 통해 이러한 민첩성을 구현할 수 있습니다. 그러나 속도가 향상되면 새로운 보안 위험도 발생합니다.
연속 릴리스 주기는 디자인 결정과 프로덕션 배포 사이의 시간을 줄여 다음과 같은 약점이 프로덕션 환경에 도입될 가능성을 높입니다.
- 애플리케이션 디자인 약점
- 취약한 종속성
- 구성 오류
- 인프라 자동화 결함
- 잘못된 비밀 관리 또는 위생.
DevOps 위험
최신 DevOps 환경은 개발, 파이프라인 및 프로덕션 시스템에서 공격 표면을 확장합니다. 소스 코드 리포지토리, 파이프라인 및 자동화 시스템과 같은 DevOps 도구는 공격자의 고부가가치 대상입니다.
악성 코드가 초기에 도입되면 기존 보안 검사를 통과하고 프로덕션 시스템에 도달할 수 있습니다.
일반적인 공격 목표는 다음과 같습니다.
- 빌드 아티팩트에서 악성 코드를 삽입합니다.
- 개발자 ID 또는 서비스 계정을 손상합니다.
- 프로덕션 데이터 액세스 또는 내보내기
공격자는 종종 사용자 지정 애플리케이션 및 개발 환경을 대상으로 하여 다음 액세스 권한을 얻습니다.
- 중요한 조직 또는 고객 데이터입니다.
- 독점 비즈니스 논리 및 지적 재산권.
- 손상된 개발 시스템을 통한 프로덕션 인프라.
- 소프트웨어 공급망을 통한 다운스트림 고객 손상.
잠재적인 보안 위험은 다음 다이어그램에 요약되어 있습니다.
애플리케이션 및 개발 위험
애플리케이션 워크로드는 개발 중에 도입된 약점 또는 빌드 및 배포에 사용되는 인프라의 손상으로 손상될 수 있습니다.
| 위험 | 대상 | 잠재적 결과 |
|---|---|---|
| 앱 디자인/구현 | 디자인 또는 개발 중에 발생하는 보안 문제는 다음과 같은 공격 기술에 워크로드를 노출할 수 있습니다. - 잘못된 입력 유효성 검사 - 안전하지 않은 인증 또는 권한 부여 논리 - 약하거나 잘못 구현된 암호화 - 애플리케이션 논리를 통해 중요한 데이터 노출 |
이러한 약점을 통해 공격자는 다음을 수행할 수 있습니다. - 애플리케이션 데이터 액세스 또는 조작 - 권한 없는 작업 실행 - 이식된 논리 결함을 통해 영구 액세스를 유지합니다. |
| 개발 인프라/자동화 | 공격은 다음을 대상으로 할 수 있습니다. - 소스 코드 리포지토리 - 파이프라인 빌드 - 배포 자동화 - IaC(Infrastructure-as-code) 템플릿 - 엔드포인트 또는 서비스 ID 개발 |
침해가 발생하면 공격자가 다음을 수행할 수 있습니다: - 빌드 아티팩트에 악성 코드 삽입 - 배포 구성 수정 - 이식된 논리 결함을 통해 영구 액세스 유지 - 프로덕션 환경에서 사용되는 자격 증명 또는 비밀을 가져옵니다. |
| 개발자 소프트웨어 공급망 | 애플리케이션은 일반적으로 다음을 사용합니다. - 타사 라이브러리 - 오픈 소스 패키지 - 컨테이너 이미지 - 플랫폼 서비스 |
이러한 종속성을 통해 도입된 취약성 또는 악성 코드는 다음에 영향을 줄 수 있습니다. - 조직 프로덕션 워크로드 - 고객 또는 파트너 환경 |
보안을 개발 프로세스에 통합하면 이러한 위험이 프로덕션 릴리스로 전파될 가능성이 줄어듭니다.
왼쪽으로 이동
시프트 레프트는 개발 수명 주기의 더 이른 단계에서 보안을 통합하는 보안 엔지니어링 접근 방식입니다.
조직에서는 프로세스 후반부에 보안의 유효성을 검사하는 대신 다음을 포함했습니다.
- 구상
- Design
- 발달
- Operations
이렇게 하면 수정 비용 및 위험 노출이 줄어듭니다.
이 접근 방식을 지원하기 위해 조직은 "
- 문제가 비용이 많이 들고 해결하기 어려운 경우 늦지 않고 프로세스 초기에 SDL(보안 개발 수명 주기) 과 같은 구조적 모범 사례를 사용합니다.
- 이 접근 방식을 유지하려면 GRC(거버넌스, 위험 및 규정 준수)를 개발 전략에 통합합니다.
DevSecOps란?
DevSecOps는 아이디어 시작부터 디자인, 개발 및 운영에 이르기까지 DevOps를 확장하고 보안을 소프트웨어 개발 수명 주기의 모든 단계로 포함함으로써 Shift Left 접근 방식을 제공합니다.
기존 개발 방식에서 보안 유효성 검사는 릴리스 전에 최종 품질 게이트로 수행되는 경우가 많습니다. 이로 인해 지연이 발생했고, 수정 비용이 증가했으며, 취약성이 수명 주기 후반까지 지속될 수 있게 되었습니다.
DevSecOps는 보안을 이전에 전환하고 개발 및 운영 프로세스에 지속적으로 포함합니다.
DevSecOps는 개발, 운영 및 보안 팀 간의 마찰을 줄이고, 혁신 속도, 안정성 및 보안 복원력의 공유 목표를 조정하고, 팀이 가장 중요한 문제를 조기에 지속적으로 해결할 수 있도록 합니다.
DevSecOps는 보안을 다음으로 통합합니다.
- 아키텍처 디자인
- 애플리케이션 구현
- 인프라 자동화
- 배포 및 운영 프로세스
Benefits
DevSecOps를 사용하면 개발, 보안 및 운영 팀이 다음을 수행할 수 있습니다.
- 수명 주기의 앞부분에서 문제를 식별하고 수정합니다.
- 프로덕션 환경에서의 노출을 줄입니다.
- 위험을 관리하는 동안 배달 속도를 유지합니다.
보안은 배달 후 적용된 컨트롤이 아니라 소프트웨어를 빌드하고 전달하는 방법의 일부가 됩니다.
보안 혁신 수명 주기
혁신은 일반적으로 다음 두 가지 수명 주기 단계를 통해 진행됩니다.
| 단계 | 세부 정보 |
|---|---|
| 아이디어 인큐베이션 | 기능은 초기 프로덕션 사용을 위해 설계, 구현 및 유효성 검사됩니다. 그것은 새로운 아이디어로 시작 |
| 초기 릴리스 |
첫 번째 프로덕션 릴리스는 안전한 제품 사용을 위한 최소 제품 기준을 충족합니다. - 개발: 기능은 최소 비즈니스 요구 사항을 충족합니다. - 보안: 기능은 프로덕션 사용을 위한 규정 준수, 보안 및 안전 요구 사항을 충족합니다. - 작업: 기능은 프로덕션 시스템이 되기 위한 최소 품질, 성능 및 지원 가능성 요구 사항을 충족합니다. |
초기 릴리스 후에는 워크로드가 다음과 같이 진화함에 따라 개발이 반복됩니다.
- 위험 허용 범위 변경
- 애플리케이션 요구 사항 및 완성도
- 규정 의무
- 위협 조건
개발에 보안 통합
기존 개발 방법은 설계 및 구현이 완료된 후 릴리스되기 전에 마지막 게이트로서 수명 주기 후반에 보안의 유효성을 검사합니다. 최신 개발 환경에서는 유효성 검사 지연이 증가합니다.
- 취약성 복잡성
- 수정 비용
- 운영 지연 및 중단
- 활성 악용에 대한 위험 노출 증가
DevSecOps는 개발 및 운영 전반에 걸쳐 보안을 지속적으로 통합하여 이전 문제를 해결하고 위험을 줄이며 일관성을 개선합니다.
주요 사례
효과적이고 확장 가능하며 지속 가능하려면 기존 개발 프로세스에 보안을 포함해야 합니다. 별도의 또는 병렬 워크플로에서 구현되지 않고 앱이 디자인, 빌드, 배포 및 작동하는 방식에 직접 통합되어야 합니다. 다음이 권장됩니다.
- 아이디어에서 개발, 배포 및 진행 중인 작업을 통해 엔드 투 엔드 워크플로를 매핑합니다.
- 수명 주기의 각 단계에서 보안에 대한 명확한 역할, 도구 및 책임 정의
- 취약성, 결함 및 디자인 문제에 대한 일관된 수정 경로를 설정합니다.
워크로드 위험에 따라 보안 사례를 조정합니다. 중요 비즈니스용 애플리케이션은 더 엄격해야 하지만 위험 수준이 낮은 시나리오는 간소화된 접근 방식을 따를 수 있습니다.
최소한 다음을 수행해야 합니다.
- 개발 수명 주기와 관련된 단계, 사람 및 기술을 식별합니다.
- 보안 활동을 별도의 검사점으로 처리하는 대신 각 단계에 통합하는 방법을 정의합니다.
- 수명 주기 동안 주요 변경 내용과 일상적인 수정 사항을 모두 처리하기 위한 프로세스를 설정합니다.
개발 및 배포에 대한 보안 자동화
자동화는 개발 및 운영 전반에 걸쳐 일관되고 대규모로 보안을 적용하는 데 필수적입니다.
- 보안 제어 및 도구를 CI/CD 파이프라인에 직접 통합합니다.
- 위협 모델링, 코드 검색, 유효성 검사 및 정책 적용과 같은 주요 활동을 자동화합니다.
- IaC(Infrastructure as Code)를 사용하여 반복 가능하고 안전한 배포를 사용하도록 설정합니다.
Azure 랜딩 존과 같은 플랫폼 기반 요소는 다음과 같은 방식으로 이 접근 방식을 지원할 수 있습니다.
Azure 랜딩 존 같은 플랫폼 기반은 보안, 거버넌스 및 DevOps 통합을 위한 표준화된 패턴을 제공하여 이 방법을 지원할 수 있습니다.
예상 결과
DevOps에서 DevSecOps로 전환하는 조직은 다음을 수행할 수 있습니다.
- 취약성이 프로덕션 워크로드에 도입될 가능성을 줄입니다.
- 개발 인프라 또는 자동화를 악용하는 공격자의 기능 제한
- 진화하는 공격 기술에 대한 애플리케이션의 복원력 향상
- 규정 및 조직 규정 준수 요구 사항 지원
- 운영 또는 보안 위험을 증가하지 않고 혁신 속도 유지
여정 탐색에 대한 팁
DevSecOps를 채택하려면 조직 및 문화적 변경이 필요합니다.
교육 및 문화 변화
이러한 단계는 중요한 초기 단계입니다. 개발자 팀은 DevSecOps 모델을 이해하려면 새로운 기술을 개발하고 새로운 관점을 채택해야 합니다.
교육 및 문화 변화는 개인이 변화의 가치를 완전히 이해하고 볼 수 있도록 시간, 초점, 임원 후원 및 정기적 인 후속 조치가 필요합니다.
문화와 기술을 크게 변경하면 때로는 개인의 전문적인 정체성을 활용하여 강한 저항의 잠재력을 창출할 수 있습니다. 각 개인과 상황에 대한 변화의 이유, 내용 및 방법을 이해하고 표현하는 것이 중요합니다.
변경에는 시간이 걸립니다.
팀이 새로운 방식으로 일을 하는 것의 의미에 적응할 수 있는 한 빨리 움직일 수 있습니다. 팀은 변환하는 동안 기존 작업을 수행해야 합니다.
가장 중요한 사항의 우선 순위를 신중하게 지정하고 이러한 변경이 발생할 수 있는 속도에 대한 기대치를 관리하는 것이 중요합니다.
가장 중요하고 기본이 되는 요소부터 우선하는 단계적 접근 전략에 집중하는 것은 조직에 큰 도움이 됩니다.
변경으로 인해 일시적인 불편이 발생합니다
모든 새로운 기술, 방법론 및 기타 변경으로 인해 마찰과 혼란이 발생합니다. 제한된 혜택 또는 위험 감소로 프로세스를 느리게 하는 비정상 마찰을 피하면서 위험을 줄이기 위해 중요한 사고를 유도하는 건강한 마찰에 집중하는 것이 중요합니다.
제한된 리소스
조직에서 일반적으로 초기에 직면하는 과제는 보안 및 애플리케이션 개발 모두에서 인재와 기술을 찾는 것입니다.
조직에서 보다 효과적으로 공동 작업을 시작하면 보안 사고방식을 가진 개발자나 개발 배경을 가진 보안 전문가와 같은 숨겨진 인재를 찾을 수 있습니다.
지속적인 교대 근무
앱은 빠르게 변화하고 있습니다. 새로운 기능 외에도 클라우드, 서버리스 및 AI와 같은 기술이 도입되면서 애플리케이션의 기술 정의 및 구성이 근본적으로 변화하고 있습니다.
이러한 변화는 개발 관행, 애플리케이션 보안을 변화시키고 있으며, 심지어 비개발자가 애플리케이션을 만들 수 있도록 합니다.
SRE 모델 고려
일부 DevSecOps 구현은 운영 및 보안 책임을 SRE(사이트 안정성 엔지니어) 역할로 결합합니다.
이러한 모델은 작동할 수 있지만 기존 엔터프라이즈 문화 및 관행과는 매우 다른 경우가 많습니다.
SRE 모델을 고려하는 경우 먼저 이 지침에 설명된 실질적인 빠른 승리 및 증분 진행률을 사용하여 DevOps에 보안을 포함시켜 ROI(투자 수익률)를 확보하고 즉각적인 요구를 충족하는 것이 좋습니다.
이렇게 하면 운영 및 개발 담당자에게 보안 책임이 증분적으로 추가되어 팀이 SRE 엔드 스테이트에 더 가까워지게 됩니다.
다음 단계
보안 개발 모범 사례에 대해 알아봅니다.