다음 위협 모델을 구축할 때 반드시 포함해야 할 요소

저희는 DisruptOps에서 위협 모델을 작업하고 있으며, 이에 따라 다양한 접근 방식에 대한 지식을 다시 정리해 보기로 했습니다. 금방 눈에 띈 한 가지는, 제가 본 위협 모델링 관련 문서나 도구 가운데 CI/CD 파이프라인을 다루는 것이 거의 없다는 점이었습니다.

이것은. 분명한. 문제입니다. 위협 모델에 파이프라인을 포함하십시오.

지난 몇 년간 저는 다양한 자문 업무와 함께 수십 건의 클라우드 보안 평가를 직접 수행했습니다. 저는 개발/배포 파이프라인을 항상 평가 범위에 포함하는데, 비교적 큰 보안 문제가 발견되는 곳이 바로 이 영역인 경우가 많습니다. 누군가가 어딘가의 템플릿을 변경하거나 저장된 키를 탈취해 기반 인프라를 수정할 수 있다면, 아무리 안전한 클라우드 환경이라도 사상누각에 가깝습니다.

대부분의 위협 모델은 데이터 흐름도나 아키텍처에서 출발하며, 이를 통해 애플리케이션의 위협을 단계별로 모델링할 수 있습니다(저는 Microsoft에서 나온 STRIDE를 선호합니다). 이는 애플리케이션 기능은 다루지만 파이프라인은 다루지 않습니다.

파이프라인에 그때그때의 *du jour* 위협 모델을 적용할 때는 개발자/관리자를 사용자로 취급하고, 파이프라인에 저장된 자격 증명이 있다면 파이프라인 자체도 사용자로 취급하십시오(환경에 어떻게 연결되는지를 고려해서 말입니다).

예를 들어, 누군가 Jenkins로 향하는 API 호출을 위조해 운영 애플리케이션의 변경을 유발할 수 있습니까? (Jenkins가 흔히 구성되는 방식을 보면 아마 가능할 것입니다.) 작업 변경과 코드 변경에 대한 부인은 어떻습니까? 파이프라인 내 권한 상승은 어떻습니까?

파이프라인은 보안 검증을 그다지 잘 견디지 못하는 경향이 있으므로, 앞으로의 보안 기본 원칙 관련 게시물에서 이를 다루겠습니다. 제가 위험을 줄이기 위해 파이프라인 배포와 연결된 인프라 양쪽 모두에 가드레일을 권장하는 편이라는 점은 그리 놀랍지 않으실 것입니다. 예를 들어 CI 서버는 외부에 공개되거나 공개될 수 있는 상태여서는 안 됩니다. 강화형 가드레일을 사용해 해당 서버가 인터넷 게이트웨이가 없는 네트워크 세그먼트에 있고 동시에 보안 그룹이 퍼블릭 액세스를 허용하지 않도록 보장할 수 있습니다(더 나아가 CI 서버가 항상 elastic load balancer 뒤에 있도록 보장하면 더욱 좋습니다).

애플리케이션의 공격 표면이 그 구성 요소에만 국한되던 시절은 이미 오래전에 끝났습니다. 클라우드에서는 대부분의 애플리케이션이 파이프라인을 통해 공급되며, 파이프라인은 광범위한 접근 권한과 저장된 자격 증명 때문에 가장 취약한 급소가 될 가능성이 매우 큽니다.