서로 다른 학문 분야가 결합되어 프로세스를 더 효율적으로 만들어낼 수 있다는 것은 흥미로운 일입니다. 2009년에 DevOps가 개발팀과 운영팀 간의 마찰을 해소하기 위해 고안되었습니다. 결과적으로 산업은 두 팀을 결합하여 개발팀이 코드 작성부터 프로덕션 배포까지 전체 주기에 책임을 지는 방향으로 나아갔습니다. 물론, 개발한 사람들보다 세세한 부분을 누가 더 잘 이해할 수 있겠습니까?
이러한 변화 이후, 기능이 신속하게 출시되고 새로운 기능의 시장 진입 시간이 급속하게 단축되는 것을 보았습니다. DevOps는 또한 MLOps, DataOps, GitOps와 같은 많은 다른 실천 방법들의 기초 역할을 했으며, 의심할 여지없이 더 많은 방법들이 등장했습니다.
오늘은 여러분 중 많은 분들이 익숙할 수 있는 DevSecOps(개발 보안 운영)라는 한 가지 실천 방법에 대해 이야기하겠습니다. 그래서, DevSecOps란 무엇인가요?
보안은 기존에는 생각의 뒷전으로 취급되어 왔습니다. 팀은 먼저 기능을 프로덕션으로 출시한 다음 보안 검토나 사고 발생 시 보안 개선을 배포하기 위해 서둘러야 했습니다. 사이버 보안, 공급망 및 기타 정교한 공격이 급증함에 따라 산업은 빠르게 깨달았습니다. 개발과 운영과 마찬가지로 보안도 프로세스의 일부여야 한다는 것을. 보안은 가능한 한 초기에 개발 수명주기에 포함되어야 하며, 나중에 보안을 다루는 것은 비용이 많이 들 수 있습니다(아키텍처 및 운영 측면에서 모두).
이제 우리가 배포하는 코드가 효율적이면서도 안전한지를 확인할 수 있도록 개발 라이프사이클의 다양한 단계에서 어떻게 적용할 수 있는지에 대해 논의해 보겠습니다.
보통 기능을 배포하는 과정은 다음을 포함합니다:
- 개발 – 기능이 구축
- 배포 – 아티팩트가 생성되고 전달을 준비하는 단계
- 배포 – 기능이 릴리스 되어 프로덕션 환경에 배포되는 단계
개발 단계에서 우리가 만드는 기능의 보안 포지션을 강화할 수 있는 단계에 대해 논의해 보겠습니다.
개발 단계에서, 기능은 설계 검토, 코딩, 그리고 풀 리퀘스트 검토를 거칩니다. 설계 검토의 일환으로 기능 소유자는 API 계약이 어떻게 보이는지, 어떤 종류의 데이터베이스를 사용하는지, 인덱싱, 캐싱 전략, 사용자 경험 등에 대해 논의합니다 (전체 목록이 아님). 보안 중심 문화에서는 위협 모델링도 중요합니다.
위협 모델링 수행
간단히 말해서, 위협 모델링은 “취약점 식별, 위험 평가 수행 및 권장된 완화 조치 구현을 통해 제품/조직의 보안 포지션을 흔들리지 않게 하는 과정”입니다.“
이를 이해하기 위해 예를 들어보겠습니다. 제품 카탈로그에서 제품을 나열하는 API를 개발 중이라고 상상해보세요.
- 제품 카탈로그에서 제품을 나열합니다.
- 제품이나 제품 유형을 검색합니다.
GET /api/products?search=laptop
위협 모델은 다음과 같이 보일 수 있습니다:
| functionality | vulnerability | risk assessment | recommended mitigation |
|---|---|---|---|
| 인증되지 않은 사용자가 제품을 검색할 수 있음 | 위협 요인이 DDoS (분산 서비스 거부)를 수행할 수 있음, 데이터베이스 및 API 인프라를 압도함 | 높음 – 서비스를 중단시키고 가용성을 낮출 수 있음 | DDoS 공격을 방지하기 위해 API 게이트웨이나 속도 제한기 사용 |
| 사용자가 검색 필드에 쿼리 문자열을 입력함 | 삽입 “1=1″과 같은 SQL Injection 공격을 수행할 수 있음 | 높음 – 공격자가 제품 테이블을 삭제할 수 있음 | 입력에 적합한 유효성 검사/사용자 입력 데이터 정제를 수행해야 함 |
| 사용자가 제품 세부 정보를 받음 | 내부 필드 노출은 데이터베이스 ID, 상태 코드 및 버전 번호와 같은 정보를 공격자에게 제공하여 데이터베이스 또는 기본 시스템 구조에 대한 중요 정보를 알려줄 수 있습니다. | 중간 – 공격자는 이러한 내부 구현을 사용하여 정보 수집과 같은 공격을 수행할 수 있습니다. | 사용자에게 필요한 세부 정보만 보내세요. |
제품 엔드포인트를 살펴볼 때 고려할 사항입니다. 가장 좋은 부분은 이러한 취약점을 인식하기 위해 보안 전문가일 필요가 없다는 것입니다.
Microsoft Threat 모델링 도구 및 OWASP Threat Dragons와 같은 도구를 사용하여 식별할 수 있습니다.
Microsoft Threat 모델링 도구의 위협 모델 예시
분석 보기
위협 모델링 도구의 분석 보기는 API에서 발생할 수 있는 다양한 공격을 보여줍니다.
팀과 위협 모델을 검토하면 가능한 많은 보안 취약점을 식별하고 완화하는 데 뇌품 세션으로 작용할 수 있습니다.
- 약한 암호화 사용. 예를 들어, SHA1 또는 MD5 사용은 취약하다고 간주됩니다.CA530은 코드에서 약한 해시 함수가 사용될 때 C#이 만드는 경고의 한 예입니다.
- SQL 인젝션 공격. CA2100은 코드가 인젝션 공격에 취약한지 확인하는 예입니다
- 하드코딩된 암호, 취약한 인증 및 권한 부여 메커니즘, 그리고 인프라 구성 오류 도 정적 분석기로 감지할 수 있습니다 ..
이 공간에는 기존 도구도 있습니다. SonarQube, CodeQL, Roslyn Analyzer, OWASP Dependency Check, 그리고 Snyk가 이 공간에서 훌륭한 제품을 제공하고 있습니다.
정적 분석을 빌드 파이프라인에 통합하는 것도 중요합니다. 다음과 같은 이점을 제공합니다:
- 개발자들에게 일관된 취약점 탐지 경험을 제공합니다.
- 각 프로덕션 배포가 이러한 단계를 거쳐야 하기 때문에 서비스의 보안 포즈처를 개선합니다.
보안 측면에서의 코드 리뷰
전통적으로 코드 리뷰는 버그 식별과 최상의 실천 방법 보장에 중점을 두지만, 보안 관점에서도 평가하는 것이 중요합니다. 각 풀 리퀘스트의 보안 영향을 고려함으로써 향후 위협을 예방하고 응용 프로그램의 무결성을 보호할 수 있습니다.
결론
결론적으로, 사이버 보안 분야의 성장으로 인해 보안을 고려하는 것이 중요합니다.초기 단계에서 보안을 고려해야 합니다. 이를 위해 위협 모델링과 자동 정적 분석을 정기적인 개발 주기에 통합하십시오.
다음 기사에서는 배포 중에 어떤 보안 관행을 적용할 수 있는지, 컨테이너 이미지를 스캔하고, 동적 응용프로그램 보안 테스팅 (DAST), 및 아티팩트 서명을 통해 공급망 공격으로부터 서비스를 보호하는 방법에 대해 논의할 것입니다.
Source:
https://dzone.com/articles/building-security-into-design-phase