다음을 통해 공유

개발 수명 주기를 보호하기 위한 권장 사항

  • 아티클

이 Azure 잘 설계된 프레임워크 보안 검사 목록 권장 사항에 적용됩니다.

SE:02 강화되고 대부분 자동화되고 감사 가능한 소프트웨어 공급망을 사용하여 보안 개발 수명 주기를 유지 관리합니다. 위협 모델링을 사용하여 보안이 무차별적인 구현으로부터 보호함으로써 보안 디자인을 통합합니다.

관련 가이드: 위협 분석

이 가이드에서는 개발 주기 전반에 걸쳐 보안 모범 사례를 적용하여 코드, 개발 환경 및 소프트웨어 공급망을 강화하기 위한 권장 사항을 설명합니다. 이 지침을 이해하려면 DevSecOps에 대한 지식이 있어야 합니다.

보안 주기의 다이어그램입니다.

DevSecOps는 다음을 통해 DevOps 프로세스에 보안을 통합합니다.

  • 보안 테스트 및 유효성 검사 자동화

  • 보안 파이프라인과 같은 도구를 구현하여 코드 및 IaC(Infrastructure as Code)에서 취약성을 검사합니다.

워크로드의 핵심은 비즈니스 논리를 구현하는 애플리케이션 코드입니다. 코드 및 코드 개발 프로세스는 기밀성, 무결성 및 가용성을 보장하기 위해 보안 결함이 없어야 합니다.

ID 및 네트워킹 및 기타 조치에 대한 컨트롤을 사용하여 인프라 평면만 보호하는 것만으로는 충분하지 않습니다. 코드 또는 손상된 코드 블록 의 잘못된 구현을 방지하여 전반적인 보안 태세를 강화합니다. 사용 평면, 즉 애플리케이션 코드도 강화해야 합니다. 보안을 개발 수명 주기에 통합하는 프로세스는 기본적으로 강화 프로세스입니다. 리소스 강화와 마찬가지로 코드 개발을 강화하는 것도 컨텍스트에 구애받지 않습니다. 애플리케이션의 기능 요구 사항이 아니라 보안을 강화하는 데 중점을 두고 있습니다. 강화와 관련된 자세한 내용은 리소스 강화에 대한 권장 사항을 참조 하세요.

정의

용어 정의
SDL(Security Development Lifecycle) 보안 보증 및 규정 준수 요구 사항을 지원하는 Microsoft에서 제공하는 일련의 사례입니다.
SDLC(소프트웨어 개발 수명 주기) 소프트웨어 시스템을 개발하기 위한 다단계적이고 체계적인 프로세스입니다.

주요 디자인 전략

보안 조치는 다음을 보장하기 위해 기존 SDLC(소프트웨어 개발 수명 주기)에 여러 지점에서 통합되어야 합니다.

  • 디자인 선택은 보안 격차로 이어지지 않습니다.

  • 애플리케이션 코드 및 구성은 악용 가능한 구현 및 부적절한 코딩 관행으로 인해 취약성을 만들지 않습니다.

  • 공급망을 통해 획득한 소프트웨어는 보안 위협을 도입하지 않습니다.

  • 애플리케이션 코드, 빌드 및 배포 프로세스는 변조되지 않습니다.

  • 인시던트에서 드러난 취약성이 완화됩니다.

  • 사용하지 않는 자산은 제대로 서비스 해제됩니다.

  • 규정 준수 요구 사항은 손상되거나 감소되지 않습니다.

  • 감사 로깅은 개발자 환경에서 구현됩니다.

다음 섹션에서는 일반적으로 실행되는 SDLC 단계에 대한 보안 전략을 제공합니다.

보안 요구 사항 수집 및 문서화

요구 사항 단계 의 목표는 애플리케이션 또는 애플리케이션의 새로운 기능에 대한 기능 및 비기능적 요구 사항을 수집하고 분석하는 것입니다. 이 단계는 애플리케이션의 목표에 맞게 조정된 가드레일을 쉽게 만들 수 있기 때문에 중요합니다. 애플리케이션의 데이터 및 무결성 보호는 개발 수명 주기의 모든 단계에서 핵심 요구 사항이어야 합니다.

예를 들어 사용자가 데이터를 업로드하고 조작할 수 있도록 하는 중요한 사용자 흐름을 지원해야 하는 애플리케이션을 고려해 보세요. 보안 디자인 선택은 사용자 ID 인증 및 권한 부여, 데이터에 대한 허용된 작업만 허용, SQL 삽입 방지 등 사용자가 애플리케이션과 상호 작용하는 것에 대한 보증을 포함해야 합니다. 마찬가지로 가용성, 확장성 및 유지 관리 효율성과 같은 비기능적 요구 사항을 다룹니다. 보안 선택에는 세분화 경계, 방화벽 수신 및 송신 및 기타 교차 절삭 보안 문제가 포함되어야 합니다.

이러한 모든 결정은 애플리케이션의 보안 상태를 잘 정의해야 합니다. 합의된 사양 에서 보안 요구 사항을 문서화하고 백로그에 반영합니다. 비즈니스 이해 관계자가 투자를 승인하지 않을 경우 비즈니스가 기꺼이 감수할 보안 투자와 장단위 및 위험을 명시적으로 명시해야 합니다. 예를 들어 Azure Front Door 또는 Azure 애플리케이션 Gateway와 같이 애플리케이션 앞에서 WAF(웹 애플리케이션 방화벽)를 사용해야 하는 필요성을 문서화할 수 있습니다. 비즈니스 이해 관계자가 WAF를 실행하는 추가 비용을 수락할 준비가 되지 않은 경우 애플리케이션 계층 공격이 애플리케이션으로 전달될 수 있는 위험을 감수해야 합니다.

보안 요구 사항 수집은 이 단계의 중요한 부분입니다. 이러한 노력이 없으면 디자인 및 구현 단계는 명시되지 않은 선택을 기반으로 하므로 보안 격차가 발생할 수 있습니다. 보안을 수용하기 위해 나중에 구현을 변경해야 할 수 있으며, 비용이 많이 들 수 있습니다.

보안 요구 사항을 기술 요구 사항으로 변환

디자인 단계에서 보안 요구 사항은 기술 요구 사항으로 변환됩니다. 기술 사양에서 구현 중에 모호성을 방지하기 위해 모든 디자인 결정을 문서화합니다. 다음은 몇 가지 일반적인 작업입니다.

시스템 아키텍처의 보안 차원 정의

보안 컨트롤을 사용하여 아키텍처를 오버레이합니다. 예를 들어 세분화 전략별 격리 경계, 애플리케이션 구성 요소에 필요한 ID 유형 및 사용할 암호화 방법의 유형에 따라 실용적인 컨트롤이 있습니다. 일부 예제 아키텍처는 ID 및 액세스 관리 및 네트워킹 문서의 예제 섹션에 있는 그림을 참조하세요.

플랫폼 제공 어던던스 평가

사용자와 클라우드 공급자 간의 책임 나누기를 이해하는 것이 중요합니다. 예를 들어 Azure 네이티브 보안 컨트롤과 겹치지 않도록 합니다. 더 나은 보안 범위를 얻고 개발 리소스를 애플리케이션의 요구에 다시 할당할 수 있습니다.

예를 들어 디자인에서 수신에서 웹 애플리케이션 방화벽을 요구하는 경우 해당 책임을 Application Gateway 또는 Azure Front Door와 같은 부하 분산 장치에 오프로드할 수 있습니다. 애플리케이션에서 기능을 사용자 지정 코드로 복제하지 마세요.

신뢰할 수 있는 프레임워크, 라이브러리 및 공급망 소프트웨어만 선택합니다. 또한 디자인에서 보안 버전 제어를 지정해야 합니다. 애플리케이션 종속성은 신뢰할 수 있는 당사자로부터 공급되어야 합니다. 타사 공급업체는 보안 요구 사항을 충족하고 책임 있는 공개 계획을 공유할 수 있어야 합니다. 필요한 조치를 취할 수 있도록 모든 보안 인시던트가 즉시 보고되어야 합니다. 또한 조직에서 특정 라이브러리를 금지할 수 있습니다. 예를 들어 소프트웨어는 취약성으로부터 안전할 수 있지만 라이선스 제한으로 인해 여전히 허용되지 않습니다.

소프트웨어에 대한 모든 기여자가 이 지침을 따르도록 하려면 승인 및/또는 승인되지 않은 프레임워크, 라이브러리 및 공급업체 목록을 유지 관리합니다. 가능하면 개발 파이프라인에 가드레일을 배치하여 목록을 지원합니다. 가능한 한 도구 사용을 자동화하여 취약성에 대한 종속성을 검사합니다 .

애플리케이션 코드에서 구현해야 하는 보안 디자인 패턴을 결정합니다.

패턴은 분할 및 격리, 강력한 권한 부여, 균일한 애플리케이션 보안 및 최신 프로토콜과 같은 보안 문제를 지원할 수 있습니다. 격리 패턴과 같은 일부 운영 패턴은 잠재적으로 보안 취약성을 초래할 수 있는 소프트웨어의 사용을 확인하고 차단하는 데 도움이 될 수 있습니다.

자세한 내용은 보안을 지원하는 클라우드 디자인 패턴을 참조하세요.

애플리케이션 비밀을 안전하게 저장

애플리케이션에서 사용하는 애플리케이션 비밀 및 사전 공유 키의 사용을 안전하게 구현합니다. 자격 증명 및 애플리케이션 비밀은 소스 코드 트리에 저장해서는 안 됩니다. Azure Key Vault와 같은 외부 리소스를 사용하여 잠재적인 공격자가 소스 코드를 사용할 수 있게 되면 더 이상 액세스할 수 없도록 합니다. 일반적으로 비밀을 방지하는 방법을 찾습니다. 가능하면 관리 ID를 사용하는 것이 해당 목표를 달성하는 한 가지 방법입니다. 자세한 내용은 애플리케이션 비밀 관리에 대한 권장 사항을 참조 하세요.

테스트 계획 정의

보안 요구 사항에 대한 명확한 테스트 사례를 정의합니다. 파이프라인에서 해당 테스트를 자동화할 수 있는지 여부를 평가합니다. 팀에 수동 테스트 프로세스가 있는 경우 해당 테스트에 대한 보안 요구 사항을 포함합니다.

참고 항목

이 단계에서 위협 모델링을 수행합니다. 위협 모델링은 디자인 선택이 보안 요구 사항에 부합하는지 확인하고 완화해야 하는 격차를 노출할 수 있습니다. 워크로드가 매우 중요한 데이터를 처리하는 경우 위협 모델링을 수행하는 데 도움을 줄 수 있는 보안 전문가에게 투자합니다.

초기 위협 모델링 연습은 소프트웨어의 아키텍처 및 상위 수준 디자인이 정의될 때 디자인 단계에서 수행해야 합니다. 이 단계에서 수행하면 잠재적인 보안 문제가 시스템 구조에 통합되기 전에 식별할 수 있습니다. 그러나 이 연습은 일회성 활동이 아닙니다. 소프트웨어의 진화를 통해 계속되어야 하는 지속적인 프로세스입니다.

자세한 내용은 위협 분석에 대한 권장 사항을 참조 하세요.

안전한 개발 및 테스트 사례

개발 및 테스트 단계에서 목표는 코드, 빌드 및 배포 파이프라인의 보안 결함 및 변조를 방지하는 것입니다.

보안 코드 사례에 대해 잘 학습

개발 팀은 안전한 코딩 사례에 대한 공식적이고 전문적인 교육을 받아야 합니다. 예를 들어 웹 및 API 개발자는 교차 사이트 스크립팅 공격으로부터 보호하기 위해 특정 교육이 필요할 수 있으며, 백 엔드 개발자는 SQL 삽입 공격과 같은 데이터베이스 수준 공격을 방지하기 위해 심층 학습을 활용할 수 있습니다.

개발자는 프로덕션 소스 코드에 액세스하려면 이 교육을 완료해야 합니다.

또한 내부 피어 코드 검토를 수행하여 지속적인 학습을 촉진해야 합니다.

보안 테스트 도구 사용

위협 모델링을 수행하여 애플리케이션 아키텍처의 보안을 평가합니다.

SAST(정적 애플리케이션 보안 테스트)를 사용하여 취약성에 대한 코드를 분석합니다. 이 방법론을 개발자 환경에 통합하여 취약성을 실시간으로 검색합니다.

런타임 중에 DAST(동적 애플리케이션 보안 테스트)를 사용합니다. 이 도구 체인은 보안 도메인의 오류를 확인하고 일련의 공격을 시뮬레이션하여 애플리케이션의 보안 복원력을 테스트할 수 있습니다. 가능하면 이 도구를 빌드 파이프라인에 통합합니다.

보안 코딩 방법에 대한 업계 표준을 따릅니다. 자세한 내용은 이 문서의 커뮤니티 리소스 섹션을 참조하세요.

Linter 및 코드 분석기를 사용하여 자격 증명이 소스 코드 리포지토리로 푸시되지 않도록 합니다. 예를 들어 .NET 컴파일러 플랫폼(Roslyn) 분석기는 애플리케이션 코드를 검사합니다.

빌드 프로세스 중에 파이프라인 추가 기능을 사용하여 소스 코드에서 자격 증명을 catch합니다. 연속 통합 프로세스의 일부로 타사 라이브러리 및 프레임워크 구성 요소와 같은 모든 종속성을 검사합니다. 도구에서 플래그를 지정한 취약한 구성 요소를 조사합니다. 코드 변동, 테스트 결과, 검사 범위를 검사하는 다른 코드 검사 작업과 이 작업을 결합합니다.

테스트 조합을 사용합니다. 일반적인 보안 테스트에 대한 자세한 내용은 보안 테스트 권장 사항을 참조하세요.

충분한 코드 작성

코드 공간을 줄이면 보안 결함이 발생할 가능성도 줄어듭니다. 코드를 복제하는 대신 이미 사용 중이며 보안 유효성 검사를 통해 수행된 코드 및 라이브러리를 다시 사용합니다.

Azure 기능을 활용하는 것은 불필요한 코드를 방지하는 또 다른 방법입니다. 한 가지 방법은 관리되는 서비스를 사용하는 것입니다. 자세한 내용은 PaaS(Platform as a Service) 옵션 사용을 참조하세요.

기본적으로 거부 방식의 코드를 작성합니다. 액세스가 필요한 엔터티에 대해서만 허용 목록을 만듭니다. 예를 들어 권한 있는 작업을 허용해야 하는지 여부를 결정해야 하는 코드가 있는 경우 거부 결과가 기본 사례이고 허용 결과는 코드에서 특별히 허용된 경우에만 발생하도록 작성해야 합니다.

개발자 환경 보호

개발자 워크스테이션은 노출을 방지하기 위해 강력한 네트워크 및 ID 제어로 보호되어야 합니다. 보안 업데이트가 부지런히 적용되는지 확인합니다.

빌드 에이전트는 높은 권한을 가지며 빌드 서버 및 코드에 액세스할 수 있습니다. 워크로드 구성 요소와 동일한 엄격성으로 보호해야 합니다. 즉 , 빌드 에이전트에 대한 액세스는 인증 및 인증되어야 하며, 방화벽 컨트롤을 사용하여 네트워크로 분할되어야 하며, 취약성 검사의 대상이 되어야 합니다. Microsoft 호스팅 빌드 에이전트는 자체 호스팅 빌드 에이전트보다 선호되어야 합니다. Microsoft 호스팅 에이전트는 파이프라인의 각 실행마다 클린 가상 머신과 같은 이점을 제공합니다.

사용자 지정 빌드 에이전트는 관리 복잡성을 늘리며 공격 벡터가 될 수 있습니다. 빌드 컴퓨터 자격 증명은 안전하게 저장해야 하며 파일 시스템에서 임시 빌드 아티팩트도 정기적으로 제거해야 합니다. Azure DevOps와의 통신 끌어오기 모델을 사용하므로 빌드 에이전트에서 나가는 트래픽만 허용하여 네트워크 격리를 달성할 수 있습니다.

소스 코드 리포지토리도 보호 해야 합니다. 알아야 할 기준으로 코드 리포지토리에 대한 액세스 권한을 부여하고 공격을 피하기 위해 가능한 한 취약성 노출을 줄입니다. 보안 취약성에 대한 코드를 검토하는 철저한 프로세스를 갖습니다. 이러한 용도로 보안 그룹을 사용하고 비즈니스 근거를 기반으로 하는 승인 프로세스를 구현합니다.

배포 파이프라인에서 코드 보호

코드를 보호하는 것만으로는 충분하지 않습니다. 악용 가능한 파이프라인에서 실행되는 경우 모든 보안 작업은 쓸모가 없으며 불완전합니다. 악의적인 행위자가 파이프라인에서 악성 코드를 실행하지 못하도록 하려면 빌드 및 릴리스 환경도 보호 해야 합니다.

애플리케이션에 통합된 모든 구성 요소의 최신 인벤토리 유지 관리

애플리케이션에 통합된 모든 새 구성 요소는 공격 표면을 증가합니다. 새 구성 요소를 추가하거나 업데이트할 때 적절한 책임 및 경고를 보장하려면 이러한 구성 요소의 인벤토리가 있어야 합니다. 빌드 환경 외부에 저장합니다. 정기적으로 매니페스트가 빌드 프로세스의 내용과 일치하는지 확인합니다. 이렇게 하면 백도어 또는 기타 맬웨어가 포함된 새 구성 요소가 예기치 않게 추가되지 않도록 하는 데 도움이 됩니다.

파이프라인 작업

  • Azure Marketplace와 같은 신뢰할 수 있는 원본에서 파이프라인의 작업을 끌어오세요. 파이프라인 공급업체에서 작성한 작업을 실행합니다. GitHub 작업 또는 GitHub Actions를 사용하는 것이 좋습니다. GitHub 워크플로를 사용하는 경우 Microsoft에서 작성한 작업을 선호합니다. 또한 파이프라인의 보안 컨텍스트에서 실행되므로 작업의 유효성을 검사합니다.

  • 파이프라인 비밀입니다. 파이프라인 내에서 실행되는 배포 자산은 해당 파이프라인의 모든 비밀에 액세스할 수 있습니다. 불필요한 노출을 방지하기 위해 파이프라인 의 여러 단계에 적절한 구분을 적용합니다. 파이프라인에 기본 제공되는 비밀 저장소를 사용합니다. 경우에 따라 비밀을 사용하지 않도록 할 수 있습니다. 워크로드 ID(파이프라인 인증용) 및 관리 ID(서비스-서비스 인증)의 사용을 살펴봅니다.

다른 환경을 별도로 유지

다른 환경에서 사용되는 데이터는 별도로 유지되어야 합니다. 이러한 환경에 는 프로덕션에 있는 엄격한 보안 제어가 없을 수 있으므로 낮은 환경에서는 프로덕션 데이터를 사용하면 안 됩니다. 비프로덕션 애플리케이션에서 프로덕션 데이터베이스로 연결하지 말고 비프로덕션 구성 요소를 프로덕션 네트워크에 연결하지 마세요.

점진적 노출

점진적 노출을 사용하여 선택한 기준에 따라 사용자의 하위 집합에 기능을 릴리스합니다. 문제가 있는 경우 해당 사용자에게 미치는 영향이 최소화됩니다. 이 방법은 노출 영역을 줄이기 때문에 일반적인 위험 완화 전략입니다. 기능이 완성되고 보안 보증에 대한 신뢰도가 높아짐에 따라 더 광범위한 사용자 집합에 점진적으로 릴리스할 수 있습니다.

프로덕션에서 코드 보호

프로덕션 단계에서는 보안 격차를 해결할 수 있는 마지막 책임 있는 기회를 제공합니다. 프로덕션에서 릴리스된 골든 이미지의 기록을 유지합니다.

버전이 지정된 아티팩트 유지

배포된 모든 자산 및 해당 버전의 카탈로그를 유지합니다. 이 정보는 인시던트 심사 중, 문제를 완화할 때 및 시스템을 다시 작동 상태로 되돌릴 때 유용합니다. 버전이 지정된 자산을 게시된 CVE(Common Vulnerability and Exposures) 공지와 비교할 수도 있습니다. 이러한 비교를 수행하려면 자동화를 사용해야 합니다.

긴급 수정

자동화된 파이프라인 디자인에는 일반 배포와 긴급 배포를 모두 지원할 수 있는 유연성이 있어야 합니다. 이러한 유연성은 신속하고 책임 있는 보안 수정을 지원하는 데 중요합니다.

릴리스는 일반적으로 여러 승인 게이트와 연결됩니다. 보안 수정을 가속화하는 긴급 프로세스를 만드는 것이 좋습니다. 프로세스에는 팀 간의 통신이 포함될 수 있습니다. 파이프라인은 일반 배포 수명 주기 외부에서 발생하는 보안 수정, 중요한 버그 및 코드 업데이트를 처리하는 빠른 롤 포워드 및 롤백 배포를 허용해야 합니다.

참고 항목

항상 편의성보다 보안 수정의 우선 순위를 지정합니다. 보안 수정은 회귀 또는 버그를 도입해서는 안 됩니다. 긴급 파이프라인을 통해 수정을 가속화하려면 우회할 수 있는 자동화된 테스트를 신중하게 고려합니다. 실행 시간에 대해 각 테스트 값을 평가합니다. 예를 들어, 단위 테스트는 일반적으로 빠르게 완료됩니다. 통합 또는 엔드투엔드 테스트는 장기간 실행할 수 있습니다.

수명 주기 내내 코드 보안 유지 관리

이 단계 의 목표는 보안 상태가 시간이 지남에 따라 감소하지 않도록 하는 것입니다. SDLC는 진행 중인 민첩한 프로세스입니다. 이전 단계에서 다루는 개념은 시간이 지남에 따라 요구 사항이 변경되기 때문에 이 단계에 적용됩니다.

패치 관리. 보안 패치 및 업데이트를 사용하여 소프트웨어, 라이브러리 및 인프라 구성 요소를 최신 상태로 유지합니다.

지속적인 개선. 코드 검토, 피드백, 학습된 교훈 및 진화하는 위협을 고려하여 소프트웨어 개발 프로세스의 보안을 지속적으로 평가하고 개선합니다.

부실하거나 더 이상 사용되지 않는 레거시 자산을 해제합니다. 이렇게 하면 애플리케이션의 노출 영역이 줄어듭니다.

유지 관리에는 인시던트 수정도 포함됩니다. 프로덕션에서 문제가 발견되면 다시 발생하지 않도록 신속하게 프로세스에 다시 통합해야 합니다.

위협 환경을 따라가기 위해 보안 코딩 사례를 지속적으로 개선합니다.

Azure 촉진

Microsoft SDL(보안 개발 수명 주기)은 개발 수명 주기에 적용할 수 있는 보안 사례를 권장합니다. 자세한 내용은 Microsoft 보안 개발 수명 주기를 참조 하세요.

DevOps용 Defender 및 SAST 도구는 GitHub Advanced Security 또는 Azure DevOps의 일부로 포함됩니다. 이러한 도구는 조직의 보안 점수를 추적하는 데 도움이 될 수 있습니다.

다음 리소스에 설명된 Azure 보안 권장 사항을 따릅니다.

소스 코드에서 자격 증명을 찾으려면 GitHub Advanced Security 및 OWASP 소스 코드 분석 도구와 같은 도구를 사용하는 것이 좋습니다.

애플리케이션에서 오픈 소스 코드의 보안 유효성을 검사합니다. 이러한 무료 도구 및 리소스는 평가에 도움이 될 수 있습니다.

보안 검사 목록

전체 권장 사항 집합을 참조하세요.

보안 검사 목록