DevSecOps 컨트롤

DevSecOps는 보안 프로세스 및 도구를 DevOps 개발 프로세스에 통합하여 혁신 보안을 적용합니다.

DevOps 자체는 높은 수준의 프로세스 변형이 있는 새로운 분야이므로, DevSecOps의 성공은 보안을 이해하고 이를 개발 프로세스에 신중하게 통합하는 것에 달려 있습니다. 보안 추가는 코드, 개발 프로세스 및 워크로드를 호스트하는 인프라에 대해 마찰이 적은 변경으로 시작해야 합니다. 먼저 DevOps 프로세스 및 기술에 낮은 부담을 주면서 보안에 가장 긍정적인 영향을 미치는 변경에 중점을 둡니다.

이 설명서에서는 CI/CD(연속 통합 및 지속적인 업데이트) DevOps 프로세스의 각 단계와 먼저 통합하도록 권장되는 보안 제어를 검토합니다.

계획 및 개발

일반적으로 최신 개발은 Agile 개발 방법론을 따릅니다. 스크럼은 모든 스프린트가 계획 활동으로 시작되는 Agile 방법론의 한 가지 구현입니다. 개발 프로세스의 이 부분에 보안을 도입하려면 다음을 중점으로 두어야 합니다.

• 잠재적인 공격자의 렌즈를 통해 애플리케이션을 보는 위협 모델링
• IDE(통합 개발 환경) 내 간단한 정적 분석 검사를 위한 IDE 보안 플러그인 및 사전 커밋 후크입니다.
• 동료 평가 및 보안 코딩 표준을 사용하여 효과적인 보안 코딩 표준, 동료 평가 프로세스 및 사전 커밋 후크를 식별합니다.

이러한 단계를 모두 추가해야 하는 것은 아닙니다. 그러나 각 단계는 보안 문제를 훨씬 저렴하고 쉽게 해결할 수 있는 초기에 표시하는 데 도움이 됩니다.

위협 모델링

위협 모델링은 의문의 여지 없이 가장 중요한 보안 방법입니다. 즉각적인 결과를 제공하고, 향후 모든 프로젝트에서 보안을 개선하도록 개발자의 보안 사고방식을 확립하는 데 도움이 됩니다.

위협 모델링은 간단한 개념이지만 필요한 경우에는 상세하고 기술적일 수 있습니다. 위협 모델링은 다음을 포함하는 애플리케이션의 현실적인 보안 보기를 표시하고 문서화합니다.

• 공격자가 애플리케이션의 디자인을 남용하는 방법
• 취약성을 해결하는 방법
• 문제 해결의 중요성

위협 모델링을 통해 공격자의 사고방식을 효과적으로 경험할 수 있습니다. 공격자의 눈을 통해 애플리케이션을 볼 수 있습니다. 공격자가 공격을 시도하기 전에 시도를 차단하는 방법을 알아봅니다. 팀이 디자인에서 가상 사용자를 사용하는 경우 공격자를 적대적인 가상 사용자로 취급할 수 있습니다.

간단한 질문 및 답변 방법부터 자세한 도구 기반 분석에 이르기까지 위협 모델링에 대해 게시된 접근 방식이 있습니다. STRIDE 모델 또는 OWASP 위협 모델링과 같은 방법론에 기반할 수 있습니다.

위협 모델링: 간단하게 시작

위협 모델링에 대한 몇 가지 접근 방식은 시간이 많이 걸리고 기술 집약적일 수 있으므로 기본 질문을 사용하여 더 간단한 접근 방식부터 시작하는 것이 좋습니다. 더 간단한 방법은 정밀하지는 않지만, 중요한 사고 프로세스를 시작하고 주요 보안 문제를 신속하게 식별할 수 있습니다.

다음과 같은 간단한 질문 방법을 통해 시작할 수 있습니다.

• Microsoft의 간단한 질문 방법: 이 방법은 일반적인 보안 디자인 결함을 드러내도록 고안된, 기술적인 특정 질문을 합니다.
• OWASP 위협 모델링: 이 방법은 위협 모델링 프로세스를 시작하기 위해 간단하고 비기술적인 질문을 하는 데 중점을 둡니다.

팀에 더 적합한 방법에 따라 이러한 접근 방식 중 하나 또는 모두를 사용할 수 있습니다.

팀이 프로세스에 익숙해지면 Microsoft 보안 개발 수명 주기에서 고급 기술을 적용할 수 있습니다. 그러면 팀은 Microsoft 위협 모델링 도구와 같은 위협 모델링 도구를 통합하여 더욱 심층적인 인사이트를 얻고 프로세스를 자동화할 수 있습니다.

또 다른 유용한 리소스는 개발자를 위한 위협 모델링 가이드입니다.

IDE 보안 플러그 인 및 사전 커밋 후크

개발자는 배달 속도에 중점을 두며, 보안 제어로 인해 프로세스가 느려질 수도 있습니다. 일반적으로 파이프라인에서 보안 검사가 시작되면 속도가 느려집니다. 개발자는 리포지토리에 코드를 푸시한 후 잠재적 취약성에 대해 알게 됩니다. 프로세스를 가속화하고 즉각적인 피드백을 제공하려면 IDE 보안 플러그 인 및 사전 커밋 후크와 같은 단계를 추가하는 것이 좋습니다.

IDE(통합 개발 환경) 보안 플러그 인은 개발자가 익숙한 IDE 환경에서 개발 프로세스 중에 서로 다른 보안 문제를 식별합니다. 개발자의 서면 코드에 잠재적인 보안 위험이 있는 경우 플러그 인에서 즉각적인 피드백을 제공할 수 있습니다. 플러그 인은 타사 라이브러리 또는 패키지의 위험을 표시할 수도 있습니다. 선택한 IDE에 따라 많은 오픈 소스 또는 상용 플러그 인을 사용할 수 있고 보안 회사에서 제공합니다.

또 다른 옵션은 버전 제어 시스템에서 허용하는 경우 사전 커밋 프레임워크를 사용하는 것을 고려하는 것입니다. 사전 커밋 프레임워크는 개발자가 코드 검토를 위해 코드를 제출하기 전에 문제를 식별할 수 있는 Git 후크 스크립트를 제공합니다. 한 가지 예는 GitHub에서 설정할 수 있는 사전 커밋입니다.

동료 평가 및 보안 코딩 표준

끌어오기 요청은 개발 프로세스의 표준입니다. 끌어오기 요청 프로세스의 일부는 발견되지 않은 결함, 버그 또는 인적 실수와 관련된 문제를 찾아내기도 하는 동료 평가입니다. 끌어오기 요청을 만들기 전에, 동료 평가 프로세스 중에 개발자를 안내할 수 있는 보안 챔피언 또는 지식이 충분한 보안 팀원을 갖추는 것이 좋습니다.

보안 코딩 사례 지침은 개발자가 필수 보안 코딩 원칙과 그 적용 방법을 배우는 데 도움이 됩니다. OWASP 보안 코딩 사례와 같은 보안 코딩 사례가 사용 가능하고 이는 일반 코딩 사례와 통합되어 있습니다.

코드 커밋

일반적으로 개발자는 GitHub 또는 Azure Repos 같은 리포지토리에서 코드를 만들고, 관리하고, 공유합니다. 이 접근 방식은 개발자에게 쉽게 협업할 수 있는 중앙의 버전 제어 코드 라이브러리를 제공합니다. 그러나 단일 코드베이스에서 많은 협력자를 사용하도록 설정하면 변경 내용이 도입될 위험이 있습니다. 이러한 위험으로 인해 커밋에 자격 증명 또는 토큰이 의도치 않게 포함되거나 취약성이 발생할 수 있습니다.

이러한 위험을 해결하기 위해 개발 팀은 리포지토리 검사 기능을 평가하고 구현해야 합니다. 리포지토리 스캐닝 도구는 리포지토리 내 소스 코드에 대한 정적 코드 분석을 수행합니다. 이 도구는 취약성 또는 자격 증명 변경 내용을 찾고 수정을 위해 발견된 항목에 플래그를 지정합니다. 이 기능은 인적 오류로부터 보호하는 역할을 하며, 많은 사람들이 동일한 리포지토리에서 공동 작업하는 분산 팀에 유용한 보호 기능입니다.

종속성 관리

현재 애플리케이션에 있는 코드의 최대 90%가 외부 패키지 및 라이브러리 요소를 포함하고 이를 기반으로 합니다. 소스 코드에서 종속성이 채택되면 잠재적인 위험을 해결하는 것이 필수적입니다. 많은 타사 라이브러리에 심각한 보안 문제가 있습니다. 또한 개발자는 최상의 수명 주기를 일관되게 따르지 않고 종속성을 최신 상태로 유지합니다.

개발 팀이 애플리케이션에 포함할 구성 요소를 알고 있는지 확인합니다. 알려진 원본에서 보안 및 최신 버전을 다운로드하려고 합니다. 또한 버전을 최신 상태로 유지하는 프로세스를 원합니다. 팀은 OWASP Dependency-Check Project, WhiteSource 등의 도구를 사용하여 수행할 수 있습니다.

종속성 취약성 또는 그 수명 주기에 중점을 두는 것만으로는 충분하지 않습니다. 패키지 피드 보안을 해결하는 것도 중요합니다. 패키지 관리 시스템을 대상으로 하는, 알려진 공격 벡터(타이포스쿼팅, 기존 패키지 손상, 대체 공격 등)가 있습니다. 따라서 책임 있는 패키지 관리 관리에서 이러한 위험을 해결해야 합니다. 자세한 내용은 프라이빗 패키지 피드를 사용할 때 위험을 완화하는 세 가지 방법을 참조하세요.

정적 애플리케이션 보안 테스트

팀에서 타사 라이브러리 및 패키지 관리를 해결한 후에는 포커스를 이동하고 코드 보안을 개선하는 것이 중요합니다. 코드 보안을 개선하기 위해 다음과 같이 여러 방식을 사용할 수 있습니다. IDE 보안 플러그 인을 사용할 수 있습니다. 또는 앞에서 설명한 대로 증분 정적 분석 사전 커밋 및 커밋 검사를 연결할 수 있습니다. 또한 전체 소스 코드 검사를 수행하여 이전 단계에서 놓친 실수를 파악할 수도 있습니다. 이 과정은 필수이지만, 코드 블록이 많으면 검사하는 데 몇 시간 또는 며칠 정도가 걸릴 수 있습니다. 따라서, 이 방법을 사용하면 개발 속도가 느려지고 부담이 발생할 수 있습니다.

그러나 팀은 정적 코드 검사 사례를 구현할 때 시작할 지점이 필요합니다. 한 가지 방법은 연속 통합 내부에 정적 코드 분석을 도입하는 것입니다. 이 방법은 코드 변경이 발생하는 즉시 보안을 확인합니다. 한 가지 예는 SonarCloud입니다. 이 도구는 다양한 언어에 대한 여러 SAST(정적 애플리케이션 보안 테스트) 도구를 래핑합니다. SonarCloud는 유지 관리에 중점을 두고 기술적인 문제를 평가하고 추적합니다. 또한 코드 품질 및 스타일을 살펴보고 보안 관련 검사기가 있습니다. 하지만 그러나 시장에서 사용할 수 있는 다른 많은 상업 및 오픈 소스 도구가 있습니다.

피드백 루프가 유효하도록 하려면 도구를 조정하는 것이 중요합니다. 가양성 문제를 최소화하고 해결할 문제에 대한 명확하고 실행 가능한 피드백을 제공하려고 합니다. 또한 결과가 있는 경우 기본 분기에 대한 코드 커밋을 방지하는 워크플로를 구현하는 것이 좋습니다. 품질 및 보안 결과를 모두 다루고 싶을 것입니다. 따라서 보안은 단위 테스트 환경의 일부가 됩니다.

파이프라인 보안

개발 수명 주기의 모든 항목이 파이프라인을 통과하기 때문에 DevOps는 자동화를 한 차원 더 끌어올립니다. CI/CD(지속적인 통합 및 지속적인 업데이트)는 최신 개발 주기의 핵심 부분입니다. CI/CD에서 팀은 정기적으로 개발자 코드를 중앙 코드베이스에 병합하고 표준 빌드 및 테스트 프로세스를 자동으로 실행합니다.

인프라 파이프라인은 개발의 중심 부분입니다. 그러나 파이프라인을 사용하여 스크립트를 실행하거나 프로덕션 환경에 코드를 배포하면 특유의 보안 문제가 발생할 수 있습니다. CI/CD 파이프라인이 악성 코드를 실행하거나, 자격 증명이 도난당하도록 허용하거나, 공격자에게 액세스할 수 있는 노출 영역을 제공하는 방법이 되지 않도록 해야 합니다. 또한 팀에서 릴리스하려는 코드만 배포하도록 해야 합니다.

DevOps 팀은 파이프라인에 대해 적절한 보안 제어가 구현되었는지 확인해야 합니다. 선택한 플랫폼에 따라 해당 위험을 해결하는 방법에 대한 다양한 지침이 있습니다. 자세한 내용은 Azure Pipelines 보안을 참조하세요.

빌드 및 테스트

많은 조직에서 빌드 및 릴리스 파이프라인을 사용하여 코드 빌드 및 배포 프로세스를 자동화하고 표준화합니다. 릴리스 파이프라인을 사용하면 개발 팀이 코드 섹션을 대규모로 빠르게 반복적으로 변경할 수 있습니다. 팀은 기존 환경을 다시 배포하거나 업그레이드하는 데 많은 시간을 할애할 필요가 없습니다.

또한 릴리스 파이프라인을 사용하면 팀이 개발 환경에서 테스트 환경을 거쳐 궁극적으로 프로덕션으로 코드 수준을 올릴 수 있습니다. 자동화의 일환으로 개발 팀은 테스트 환경에 코드를 배포할 때 스크립팅된 자동화 테스트를 실행하는 보안 도구를 포함해야 합니다. 테스트에는 취약성 또는 퍼블릭 엔드포인트를 확인하기 위한 애플리케이션 기능 단위 테스트가 포함되어야 합니다. 테스트는 의도적인 액세스를 보장합니다.

동적 애플리케이션 보안 테스트

기존의 폭포 개발 모델에서 보안은 일반적으로 프로덕션으로 이동하기 직전 마지막 단계에서 도입되었습니다. 가장 널리 사용되는 보안 접근 방식 중 하나는 침투 테스트입니다. 침투 테스트를 통해 팀은 공격자 사고방식에 가장 가까운 블랙박스 보안 관점에서 애플리케이션을 살펴볼 수 있습니다.

침투 테스트는 여러 작업 포인트로 구성되며 그 중 하나는 DAST(동적 애플리케이션 보안 테스트)입니다. DAST는 애플리케이션이 특수 제작된 요청에 어떻게 응답하는지 확인하여 실행 중인 애플리케이션의 보안 문제를 찾는 웹 애플리케이션 보안 테스트입니다. DAST 도구는 웹 애플리케이션 취약성 검사기라고도 합니다. 한 가지 예는 오픈 소스 도구인 OWASP ZAP(Zed Attack Proxy)입니다. 실행 중인 웹 애플리케이션에서 취약성을 찾습니다. OWASP ZAP이 검사를 수행하는 방법에는 구성에 따라 수동 기준 검사 또는 전체 검사 등 여러 가지가 있습니다.

펜 테스트의 단점은 시간이 많이 걸린다는 것입니다. 완전한 펜 테스트는 최대 몇 주가 걸릴 수 있으며 DevOps 개발 속도가 빨라서 해당 시간 프레임이 지속 불가능할 수 있습니다. 그러나 SAST 및 다른 단계에서 누락되는 문제를 파악하기 위해 개발 프로세스 중에 침투 테스트의 더 가벼운 버전을 추가하는 것은 여전히 ​​가치가 있습니다. OWASP ZAP과 같은 DAST 도구가 도움이 될 수 있습니다.

개발자는 파이프라인에서 OWASP ZAP을 작업으로 통합합니다. 실행하는 동안 OWASP ZAP 스캐너가 컨테이너에서 스핀업되고 검사한 다음, 결과를 게시합니다. 이 접근 방식은 완전한 침투 테스트가 아니기 때문에 완벽하지 않을 수 있지만 여전히 가치가 있습니다. 이는 개발 주기에서 보안 태세를 개선하기 위한 또 하나의 품질 측정입니다.

클라우드 구성 유효성 검사 및 인프라 검사

애플리케이션에 대한 코드 검색 및 보안뿐만 아니라 애플리케이션이 배포되는 환경도 안전하게 유지해야 합니다. 안전한 환경은 신속하게 움직이고, 혁신하고, 새로운 기술을 사용하고자 하는 조직에 핵심적인 요소입니다. 또한 보안 환경을 통해 팀은 새 실험 환경을 신속하게 만들 수 있습니다.

Azure 기능을 통해 조직은 Azure Policy와 같은 환경에서 보안 표준을 만들 수 있습니다. 팀은 Azure Policy를 사용하여 정책 집합을 만들 수 있습니다. 정책 집합은 공용 IP 주소와 같은 특정 워크로드 유형 또는 구성 항목의 생성을 방지합니다. 이러한 가드 레일을 통해 팀은 혁신과 거버넌스의 균형을 유지하면서 안전하고 통제된 환경에서 실험할 수 있습니다.

DevOps가 개발자와 작업을 서로 단계별로 가져올 수 있는 방법 중 하나는 기존 인프라를 IaC(Infrastructure as Code) 접근 방식으로 변환하도록 지원하는 것입니다.

IaC(Infrastructure as Code)는 설명적 모델에서 인프라(네트워크, 가상 머신, 부하 분산 장치 및 연결 토폴로지)를 관리하는 작업을 말합니다. IaC는 DevOps 팀이 소스 코드에 사용하는 것과 동일한 버전 관리 모델을 사용합니다. 동일한 소스 코드가 동일한 이진을 생성한다는 원칙과 마찬가지로 IaC 모델은 적용될 때마다 동일한 환경을 생성합니다. IaC는 지속적인 업데이트와 함께 사용되는 핵심 DevOps 사례입니다.

DevSecOps는 보안을 원점 회귀하며 보안이 애플리케이션 보안뿐만 아니라 인프라 보안에 관한 것임을 보여 줍니다. DevSecOps에서 인프라 보안을 지원하는 방법 중 하나는 인프라가 클라우드에 배포되기 전에 보안 검사를 포함하는 것입니다. 인프라가 코드가 되면 애플리케이션 보안과 동일한 보안 작업을 인프라에 적용합니다. 선택한 IaC 전략에 따라 인프라 보안 검사를 실행하는 데 사용할 수 있는 보안 도구가 있습니다.

클라우드를 채택하게 되면서, 컨테이너화는 팀에서 애플리케이션 아키텍처를 결정할 때 널리 사용되는 접근 방식이 되었습니다. 일부 컨테이너 리포지토리는 이미지를 검사하여, 알려진 취약성이 있는 패키지를 포착합니다. 컨테이너에 오래된 소프트웨어가 포함될 위험이 여전히 있습니다. 이러한 위험 때문에 보안 위험에 대해 컨테이너를 검사하는 것이 필수적입니다. 많은 오픈 소스 및 상용 보안 도구가 이 영역을 대상으로 하며, CD 프로세스의 긴밀한 통합을 지원하고 있습니다. 보안 도구를 사용하면 팀이 코드 제공 인프라용 DevSecOps를 채택하고 컨테이너를 사용하는 방법을 보다 구체적으로 알아볼 수 있습니다.

프로덕션으로 이동하여 운영

솔루션이 프로덕션에 전달되면 보안 상태를 계속해서 감독하고 관리하는 것이 중요합니다. 프로세스의 이 단계에서는 클라우드 인프라와 애플리케이션 전반에 집중해야 합니다.

구성 및 인프라 검사

여러 구독에서 클라우드 구독 및 리소스 구성에 대한 가시성을 확보하기 위해 AzSK 팀의 Azure 테넌트 보안 솔루션을 사용합니다.

Azure에는 모니터링 및 보안 기능이 포함됩니다. 이러한 기능은 조사 및 잠재적 수정이 필요한 비정상적인 이벤트나 구성을 검색하고 경고를 표시합니다. 클라우드용 Microsoft Defender 및 Microsoft Sentinel과 같은 기술은 기본적으로 Azure 환경에 통합되는 자사 도구입니다. 이러한 기술은 환경 및 코드 보안 도구를 보완합니다. 또한 조직에서 빠르고 안전하게 실험하고 혁신할 수 있도록 철저한 보안 모니터링을 제공합니다.

침투 테스트

침투 테스트는 공격자가 악용할 취약성을 만들 수도 있는, 인프라 또는 애플리케이션 구성의 취약성을 확인할 때 권장되는 방법입니다.

많은 제품 및 파트너가 침투 테스트 서비스를 제공합니다. Microsoft는 Azure의 침투 테스트에 대한 지침을 제공합니다.

일반적으로 테스트에는 다음 테스트 유형이 포함됩니다.

• 엔드포인트에서 테스트하여 취약성 발견
• 엔드포인트의 퍼지 테스트(잘못된 형식의 입력 데이터를 제공하여 프로그램 오류 찾기)
• 엔드포인트의 포트 검색

실행 가능한 인텔리전스

이 지침의 도구와 기술은, 신속하게 움직이며 혁신 주도를 목표로 하는 새로운 기술을 실험하고자 하는 조직을 위해 전체적인 보안 모델을 제공합니다. DevSecOps의 핵심 요소는 데이터 기반, 이벤트 기반 프로세스입니다. 이러한 프로세스는 팀이 잠재적인 위험을 식별, 평가, 대응하는 데 도움이 됩니다. 많은 조직에서 경고 및 사용량 현황 데이터를 ITSM(IT 서비스 관리) 플랫폼에 통합하기로 결정합니다. 그러면 팀은 다른 인시던트 및 요청에 사용하는 것과 동일한 구조화된 워크플로를 보안 이벤트에 가져올 수 있습니다.

피드백 루프

이러한 모든 기술과 도구를 통해 팀은 조사 및 잠재적 해결이 필요한 위험과 취약성을 찾고 플래그를 지정할 수 있습니다. 운영 팀이 경고를 받거나 지원 티켓을 조사할 때 잠재적인 문제를 발견하면, 항목에 플래그를 지정하여 검토하기 위해 개발 팀으로 돌아가는 경로가 필요합니다. 원활하고 협력적인 피드백 루프는 문제를 신속하게 해결하고 취약성의 위험을 가능한 한 최소화하는 데 매우 중요합니다.

피드백에 대한 일반적인 패턴은 Azure DevOps 또는 GitHub와 같은 개발자 작업 관리 시스템에 이 패턴을 통합하는 것입니다. 조직은 개발자가 계획하고 조치를 취할 수 있도록 경고 또는 인시던트를 작업 항목에 연결할 수 있습니다. 이 프로세스는 개발자가 개발, 테스트 및 릴리스를 포함하여 표준 워크플로 내에서 문제를 해결할 효과적인 방법을 제공합니다.