이 문서는 보안 및 기술 팀이 개발 보안 분야를 수립하고 현대화하는 데 도움이 됩니다. 이 분야는 보안, 엔지니어링 및 기술 팀이 소프트웨어가 혁신을 늦추지 않고 안전하게 설계, 빌드, 통합 및 배포되도록 하는 데 도움이 됩니다.
보안 분야는 조직이 전체 기술 자산에서 보안 결과를 일관되게 제공할 수 있도록 지원하는 관련 보안 작업의 그룹화입니다. 보안 채택 모델 내에서 분야는 비즈니스 시나리오 와 기술 구현 간의 브리지를 제공하여 보안 투자가 보안 채택 모델의 일부로 실제 측정 가능한 결과로 변환되도록 합니다.
왜 이 분야인가?
소프트웨어는 ID, 데이터, 인프라 및 비즈니스 프로세스와 긴밀하게 상호 연결됩니다. 개발 보안이 약하거나 일관성이 없는 경우 각 소프트웨어 릴리스는 공격자가 더 광범위한 조직 자산에 액세스하기 위해 악용하는 새로운 취약성을 도입할 수 있습니다.
효과적인 개발 보안 분야가 없으면 조직은 일반적으로 다음을 경험합니다.
- 개발 중에 도입된 소프트웨어 취약성으로 인한 위험이 증가했습니다.
- ID 및 데이터 간에 횡적 이동을 가능하게 하는 애플리케이션 손상입니다.
- 비즈니스 운영 및 수익 중단.
- 고객 및 규제된 데이터의 노출 또는 남용
- 장기 위험 및 수정 비용을 증가시키는 기술 부채 누적.
엄격한 개발 보안 체계는 각 릴리스가 위험을 가중시키기보다 줄이도록 보장합니다.
임무 및 결과
개발 보안 분야는 내부적으로 개발되었든 파트너가 개발하든 관계없이 배달 또는 혁신을 늦추지 않고 보안 표준에 맞게 모든 소프트웨어를 설계, 빌드, 통합 및 배포하도록 하여 조직의 위험을 줄입니다.
이 분야를 완성하는 조직은 다음을 달성합니다.
- 보안은 늦게 추가되는 대신 개발 프로세스에 기본 제공됩니다.
- 디자인 및 구현 결함의 이전 식별 및 수정.
- 보다 예측 가능하고 안전한 릴리스 주기.
- 재작업, 긴급 수정 및 운영 중단을 줄입니다.
- 시간이 지남에 따라 기술 및 보안 부채의 누적을 줄입니다.
개발 보안은 주기적으로 다시 설정되지 않고 각 릴리스에서 보안 태세가 지속적으로 향상되도록 합니다.
팀 작업의 변경 내용
개발 보안 분야는 개발자와 제품 팀의 현재 작업 방식에 맞춰, 개발 후반부에 통제 장치를 도입하거나 부담이 큰 검토 절차를 추가하거나 개발 과정에서 보안을 아예 생략하는 대신, 기존 개발 워크플로에 보안을 통합하는 데 중점을 두는 것이 중요합니다.
이 접근 방식은 종종 문제가 더 쉽고 비용이 적게 드는 경우 아이디어, 디자인 및 구현 초기에 보안 사고를 도입하여 왼쪽으로 이동하는 것으로 설명됩니다. 왼쪽으로 이동하는 것은 프로세스의 앞부분에서 아무 말도 하지 않는다는 것을 의미하지 않습니다. 대신, 제품 의사 결정을 개선하고 솔루션이 보안 및 비즈니스 요구 사항을 충족하도록 하기 위해 보안 정보에 입각한 토론을 조기에 도입합니다.
주요 원칙은 다음과 같습니다.
- 초기 통합: 테스트뿐만 아니라 아이디어 및 디자인 중에 보안을 고려합니다.
- 개발자 맞춤: 이미 작업 중인 개발 및 제품 팀 만나기
- 작고 점진적인 변화: 자동화와 도입 장벽이 낮은 개선을 우선하세요
- 지속적인 개선: 중요 시점이 아닌 지속적인 분야로 보안 처리
시간이 지남에 따라 일관된 통합은 소방 훈련을 줄이고 속도를 늦추지 않고 배달을 가속화합니다.
이 분야를 적용하는 방법
개발 보안 분야를 효과적으로 적용하려면 조직 전체에서 보안 애플리케이션 및 서비스를 빌드하고 유지 관리하는 일관된 접근 방식을 설정하는 데 집중합니다.
-
비즈니스 위험에 맞는 보안 개발 전략 정의
손상 위험을 줄이고 중요한 비즈니스 기능을 보호하기 위해 애플리케이션 및 서비스를 설계, 빌드 및 유지 관리하는 방법에 대한 명확한 접근 방식을 설정합니다. -
개발 및 엔지니어링 프로세스에 보안 포함
보안 관행이 사실 이후에 적용되지 않고 계획, 디자인, 개발 및 배포 활동에 통합되어 있는지 확인합니다. -
표준화된 보안 개발 사례 설정
보안 코딩, 테스트 및 릴리스 사례가 팀 및 프로젝트에서 일관되게 적용되도록 명확한 지침을 제공합니다. -
개발 보안을 중요 자산 및 비즈니스 시나리오에 맞게 조정
고부가가치 자산 및 주요 비즈니스 운영을 지원하는 애플리케이션 및 서비스에 대한 보호 우선 순위를 지정합니다. -
위험, 취약성 및 피드백에 따라 지속적으로 개선
취약성, 인시던트 및 테스트 결과의 인사이트를 사용하여 개발 사례를 강화하고 시간에 따른 위험을 줄입니다.
변경을 관리하세요
최신 개발 보안은 일반적으로 릴리스 전에 민첩한 전달과 필수 거버넌스 및 품질 사례를 결합하는 DevSecOps 접근 방식을 통해 구현됩니다.
DevSecOps는 속도와 보안 중에서 선택하는 대신 빠른 릴리스 주기를 방해하지 않으면서 긴급한 위험을 완화하기 위해 개발 수명 주기의 주요 측면을 보호하는 데 중점을 둡니다.
디자인 보호 – 입증된 보안 디자인 패턴을 사용하고 위협 모델링을 통해 디자인의 유효성을 검사합니다. 코드 보호 – 보안 코딩 사례를 따르고 소프트웨어 및 종속성 유효성을 검사합니다. 파이프라인 보안 – 파이프라인 프로세스의 유효성을 검사하고 손상 및 무단 변경으로부터 CI/CD 시스템을 보호합니다. 파이프라인 및 파이프라인을 통과하는 소프트웨어에 대한 변경 내용의 추적 가능성을 확인합니다. 보안 작업 – 배포된 워크로드가 구성, 패치 및 운영 모범 사례를 따르는지 확인합니다.
팀은 개발, 보안 및 운영 간의 협업을 지속적으로 개선하고, 기능 전달 목표와 안정성 및 위험 감소의 균형을 맞추어 결과를 개선할 수 있습니다.
이러한 지속적인 증분 개선은 개발 수명 주기 자체의 성숙뿐만 아니라 작업 프로덕션(수명 주기에서 생성된 소프트웨어 코드)에도 적용되어야 합니다.
DevSecOps 프로세스 정의
개발 보안은 일반적으로 완전히 형성되지 않고 시간이 지남에 따라 진화하는 DevSecOps 운영 모델을 통해 구현됩니다. DevSecOps는 지속적인 개선을 통해 더 나은 결과를 달성하기 위해 개발, 보안 및 작업을 함께 제공합니다.
대부분의 조직은 다음 단계를 진행합니다.
개발(개발) – 첫 번째 프로덕션 릴리스는 핵심 비즈니스 요구 사항을 충족하는 MVP(최소 실행 가능한 제품)를 제공하는 데 중점을 둡니다. DevOps – 초기 릴리스 후 팀은 지속적인 업데이트를 통한 신속한 반복, 운영 안정성 및 거버넌스에 집중합니다. DevSecOps – 협업이 성숙함에 따라 개발, 보안 및 운영이 함께 작동하여 프로세스를 지속적으로 개선하고 속도, 위험 및 안정성의 균형을 유지합니다.
이러한 진행을 통해 조직은 민첩성 또는 혁신을 희생하지 않고도 보안 결과를 개선할 수 있습니다.
보안 MVP 기준 설정
이 모델의 핵심 단계는 개발, 보안 및 운영 관점에서 MVP(실행 가능한 최소 제품)를 구성하는 것을 정의하는 것입니다. 이 공유 기준을 설정하면 팀 간에 명확성이 생성되고 시간이 지남에 따라 일관된 개선이 가능합니다.
| 구성 요소 | 세부 정보 |
|---|---|
| Dev(elopment) | 소프트웨어가 최소 비즈니스 및 기능 요구 사항을 충족하는지 확인합니다. |
| Sec(urity) | 소프트웨어가 최소 보안 및 규정 준수 요구 사항을 충족하는지 확인합니다. |
| Op(eration)s | 소프트웨어가 최소 품질, 안정성 및 운영 준비 요구 사항을 충족하는지 확인합니다. |
MVP 요구 사항은 조직 및 업계에 따라 다르며 위험 욕구, 규제 노출 및 비즈니스 중요도의 영향을 받습니다. 이러한 요구 사항은 종종 조직, 위협 환경 및 배달 모델이 변경됨에 따라 진화합니다.
지속적인 소프트웨어 개선
초기 프로덕션 릴리스 이후 워크로드는 지속적인 개선 주기로 전환됩니다. 이 단계에서 개발, 보안 및 운영은 소프트웨어와 배달 프로세스를 모두 구체화합니다. 보안 노력은 다음 사항에 중점을 두고 있습니다.
- 다른 엔지니어링 작업과 동일한 도구 및 우선 순위 지정 모델을 사용하여 기본적으로 보안을 개발 워크플로에 통합
- 표준 릴리스 주기의 일부로 보안 버그를 신속하게 식별, 우선 순위 지정 및 수정합니다.
이 방법은 prPaved Paths 같은 Microsoft SFI(Secure Future Initiative) 학습과 일치합니다. 여기서 보안 사례는 외부에서 적용되지 않고 플랫폼 및 프로세스에 기본 제공됩니다.
시간이 지남에 따라 이 지속적인 학습은 팀이 요구 사항을 구체화하고 협업을 간소화하며 배달 속도, 보안 및 안정성의 균형을 더 잘 조정하는 데 도움이 됩니다.
분야별 역할 및 협업자
개발자 보안 분야는 일반적으로 앱 및 제품 개발을 수행하는 팀에서 실행합니다.
이 분야의 주요 역할은 일반적으로 다음과 같습니다.
- 기술 제공 및 제품 관리자
- 소프트웨어 개발자(AI 개발 포함)
- 소프트웨어 보안 엔지니어
- DevOps 및 플랫폼 엔지니어
- 테스트 및 품질 엔지니어링 역할
- 공급망 및 종속성 보안 역할
주요 협력자는 다음과 같습니다.
- 비즈니스 및 기술 리더십 – 후원 및 우선 순위 지정 제공
- 아키텍처 역할 – 보안 디자인 및 통합 결정 안내
- 보안 전략, 통합 및 거버넌스 분야 역할 - 정책, 교육 및 감독 제공
- 인프라 및 플랫폼 팀 - 보안 개발 환경 사용
- 보안 작업(SecOps) – 애플리케이션이 공격을 받으면 모니터링 및 대응
다른 분야와의 맞춤
개발 보안은 다른 SAF 분야와 긴밀하게 통합됩니다.
- 액세스 및 ID – 개발자, 워크로드 및 서비스 ID를 보호합니다.
- 인프라 보안 – 애플리케이션 및 파이프라인을 실행하는 플랫폼을 보호합니다.
- 데이터 보안 – 중요한 데이터가 소프트웨어 수명 주기 내내 보호되도록 합니다.
- SecOps – 애플리케이션 수준 공격을 감지하고 대응합니다.
- 보안 전략, 통합 및 거버넌스 – 개발 사례를 엔터프라이즈 위험 우선 순위에 맞춥니다.
이러한 분야는 소프트웨어 보안이 더 광범위한 비즈니스 및 보안 결과를 지원하도록 보장합니다.
기술 핵심 요소와의 맞춤
개발 보안 분야에 대한 전략을 실행하려면 여러 기술 핵심 요소에 대한 보안 제어가 필요합니다.
기술 핵심 요소와의 맞춤에는 다음이 포함됩니다.
- ID: 개발자 및 워크로드 ID 및 자격 증명을 보호합니다.
- 엔드포인트: 개발자 워크스테이션 및 빌드 시스템을 보호합니다.
- 인프라: 코드, 파이프라인 및 워크로드를 호스팅하는 플랫폼을 보호합니다.
- 앱: 개발 보안 사례에 대한 주요 초점을 제공합니다.
- 데이터: 애플리케이션에서 사용, 생성 및 저장한 데이터를 보호합니다.
- 네트워크: 신뢰할 수 없는 네트워크에서 안전하게 작동하도록 소프트웨어를 디자인합니다.
- AI: 최신 애플리케이션에 사용되는 AI 구성 요소 및 모델을 보호합니다.
이러한 폭넓음은 이 분야가 실제 공격 경로를 다루도록 보장합니다.
다음 단계는 무엇인가요?
추가 개발 보안 전략 지침은 개발 보안 전략에 있습니다.
워크샵하기
Microsoft Unified는 조직이 개발자 보안 분야를 현대화하는 데 도움이 되는 전문가 주도 워크샵을 제공합니다. 이러한 워크샵은 다음과 같습니다.
- 아키텍처 및 전략 워크샵 - SAF(보안 채택 프레임워크) - 아키텍처 디자인 세션: 인프라 및 개발 보안 워크샵 은 개발 보안 현대화 및 인프라 보안과의 통합을 가속화하는 데 중점을 둡니다. 이 워크샵은 주요 학습 및 모범 사례에 초점을 맞춘 4시간 미만의 토론으로 제공됩니다.
- 기술 채택 워크샵: Microsoft Unified에는 조직이 이 다이어그램에 설명된 대로 Microsoft 개발 보안 기술의 사용에 대해 알아보고, 계획하고, 구현하고, 최적화하는 데 도움이 되는 워크샵이 있습니다.
Microsoft Security Development Lifecycle 검토
Microsoft 지속적인 보안 개발 수명 주기는 소프트웨어를 안전하게 개발하는 방법을 제공합니다. SDL(보안 개발 수명 주기)은 Microsoft DevOps 프로세스(DevSecOps 접근 방식이라고도 함)에 보안을 통합하는 데 사용하는 방법입니다. SAF 개발 보안 지침은 SDL 접근 방식과 사례를 조직에 맞게 조정하는 데 도움이 됩니다.
클래식 폭포에서 최신 DevOps 접근 방식에 이르기까지 모든 유형의 소프트웨어 개발 및 모든 플랫폼에 SDL 접근 방식에 설명된 사례를 적용할 수 있습니다. 일반적으로 적용되는 이 소프트웨어 보안 접근 방식은 모든 유형의 소프트웨어 및 플랫폼에서 작동합니다.
자세한 내용은 Microsoft Security Development Lifecycle(SDL) 참조하세요.
효과적인 개발 보안을 위해서는 SDL(
다음 단계
DevOps에서 DevSecOps로의 전환에 대해 알아봅니다.