위협 분석에 대한 권장 사항
이 Azure Well-Architected Framework 보안 검사 목록 권장 사항에 적용됩니다.
| SE:02 | 규정 준수 요구 사항, 업계 표준 및 플랫폼 권장 사항에 부합하는 보안 기준을 설정합니다. 시간이 지남에 따라 보안 태세를 유지하거나 개선하기 위해 기준에 따라 워크로드 아키텍처 및 작업을 정기적으로 측정합니다. |
|---|
관련 가이드: 개발 수명 주기를 보호하기 위한 권장 사항
워크로드의 디자인 단계에서 위협, 공격, 취약성 및 대응 조치를 식별하는 포괄적인 분석이 중요합니다. 위협 모델링 은 보안 요구 사항 정의, 위협 식별 및 완화, 이러한 완화 유효성 검사를 포함하는 엔지니어링 연습입니다. 애플리케이션 개발 또는 프로덕션의 모든 단계에서 이 기술을 사용할 수 있지만 새 기능의 디자인 단계에서 가장 효과적입니다.
이 가이드에서는 보안 격차를 신속하게 식별하고 보안 방어를 설계할 수 있도록 위협 모델링을 수행하기 위한 권장 사항을 설명합니다.
정의
| 용어 | 정의 |
|---|---|
| SDLC(소프트웨어 개발 수명 주기) | 소프트웨어 시스템 개발을 위한 다단계적이고 체계적인 프로세스입니다. |
| STRIDE | 위협 유형을 분류하기 위한 Microsoft 정의 분류입니다. |
| 위협 모델링 | 애플리케이션 및 시스템의 잠재적인 보안 취약성을 식별하고, 위험을 완화하고, 보안 제어의 유효성을 검사하는 프로세스입니다. |
주요 디자인 전략
위협 모델링은 organization SDLC에 통합해야 하는 중요한 프로세스입니다. 위협 모델링은 전적으로 개발자의 작업이 아닙니다. 이는 다음 간의 공동 책임입니다.
- 시스템의 기술적 측면을 담당하는 워크로드 팀입니다.
- 비즈니스 결과를 이해하고 보안에 대한 기득권을 가진 비즈니스 이해 관계자.
중요한 워크로드의 비즈니스 요구 사항과 관련하여 조직 리더와 기술 팀 간의 연결이 끊어지는 경우가 자주 있습니다. 이러한 연결 끊김으로 인해 특히 보안 투자에 원치 않는 결과가 발생할 수 있습니다.
워크로드 팀이 위협 모델링 연습을 수행하는 경우 비즈니스 및 기술 요구 사항을 모두 고려해야 합니다. 워크로드 팀과 비즈니스 관련자는 대책에 적절한 투자를 할 수 있도록 워크로드의 보안 관련 요구 사항에 동의해야 합니다.
보안 요구 사항은 위협 모델링의 전체 프로세스에 대한 가이드 역할을 합니다. 효과적인 연습을 하려면 워크로드 팀은 보안 사고방식을 갖고 위협 모델링 도구에 대해 학습해야 합니다.
연습의 scope 이해
scope 명확하게 이해하는 것은 효과적인 위협 모델링에 매우 중요합니다. 가장 중요한 영역에 노력과 리소스를 집중하는 데 도움이 됩니다. 이 전략에는 시스템의 경계를 정의하고, 보호해야 하는 자산의 인벤토리를 가져와 보안 제어에 필요한 투자 수준을 이해하는 작업이 포함됩니다.
각 구성 요소에 대한 정보 수집
워크로드 아키텍처 다이어그램은 시스템의 시각적 표현을 제공하므로 정보를 수집하기 위한 시작점입니다. 다이어그램은 시스템의 기술 차원을 강조 표시합니다. 예를 들어 사용자 흐름, 데이터가 네트워크를 통해 이동하는 방법, 데이터 민감도 수준 및 정보 유형, ID 액세스 경로를 보여 줍니다.
이 자세한 분석은 종종 디자인의 잠재적 취약성에 대한 인사이트를 제공할 수 있습니다. 각 구성 요소의 기능과 종속성을 이해하는 것이 중요합니다.
잠재적 위협 평가
외부 관점에서 각 구성 요소를 분석합니다. 예를 들어 공격자가 중요한 데이터에 얼마나 쉽게 액세스할 수 있나요? 공격자가 환경에 액세스할 수 있는 경우 횡적으로 이동하고 잠재적으로 다른 리소스에 액세스하거나 조작할 수 있나요? 이러한 질문은 공격자가 워크로드 자산을 악용하는 방법을 이해하는 데 도움이 됩니다.
산업 방법론을 사용하여 위협 분류
위협을 분류하는 방법 중 하나는 MICROSOFT 보안 개발 수명 주기에서 사용하는 STRIDE입니다. 위협을 분류하면 각 위협의 특성을 이해하고 적절한 보안 제어를 사용할 수 있습니다.
위협 완화
식별된 모든 위협을 문서화합니다. 각 위협에 대해 보안 제어 및 해당 컨트롤이 실패하는 경우 공격에 대한 대응을 정의합니다. 워크로드에서 식별된 취약성에 대한 노출을 최소화하는 프로세스 및 타임라인 정의하여 해당 취약성을 수정되지 않은 상태로 두지 않도록 합니다.
위반 가정 방법을 사용합니다. 기본 보안 제어가 실패할 경우 위험을 완화하기 위해 디자인에 필요한 컨트롤을 식별하는 데 도움이 될 수 있습니다. 기본 제어가 실패할 가능성을 평가합니다. 실패하는 경우 잠재적인 조직 위험 범위는 어떻게 됩니까? 또한 보상 컨트롤의 효과는 무엇인가요? 평가에 따라 심층 방어 조치를 적용하여 보안 제어의 잠재적 오류를 해결합니다.
예를 들면 다음과 같습니다.
| 이 질문하기 | 컨트롤을 확인하려면... |
|---|---|
| Microsoft Entra ID, 상호 인증을 사용한 TLS(전송 계층 보안) 또는 보안 팀이 승인한 다른 최신 보안 프로토콜을 통해 인증되는 연결은 다음과 같습니다. - 사용자와 애플리케이션 사이에 있나요? - 애플리케이션 구성 요소와 서비스 간? |
애플리케이션 구성 요소 및 데이터에 대한 무단 액세스를 방지합니다. |
| 애플리케이션에서 데이터를 쓰거나 수정해야 하는 계정으로만 액세스를 제한하고 있나요? | 무단 데이터 변조 또는 변경을 차단합니다. |
| 애플리케이션 활동이 기록되어 Azure Monitor 또는 유사한 솔루션을 통해 SIEM(보안 정보 및 이벤트 관리) 시스템에 공급되고 있나요? | 공격을 신속하게 탐지하고 조사합니다. |
| 보안 팀이 승인한 암호화로 중요한 데이터가 보호되고 있나요? | 미사용 데이터의 무단 복사를 차단합니다. |
| 인바운드 및 아웃바운드 네트워크 트래픽은 TLS를 통해 암호화됩니까? | 전송 중인 데이터의 무단 복사를 차단합니다. |
| 애플리케이션이 Azure DDoS Protection과 같은 서비스를 통한 DDoS(분산 서비스 거부) 공격으로부터 보호되고 있나요? | 애플리케이션에 과부하를 걸어 사용 불능 상태로 만들도록 디자인된 공격을 탐지합니다. |
| 애플리케이션이 로그인 자격 증명 또는 키를 저장하여 다른 애플리케이션, 데이터베이스 또는 서비스에 액세스하나요? | 공격에서 애플리케이션을 사용하여 다른 시스템을 공격할 수 있는지 파악합니다. |
| 애플리케이션 제어를 통해 규정 요구 사항을 충족할 수 있나요? | 사용자의 개인 데이터를 보호하고 규정 준수 벌금을 방지합니다. |
위협 모델링 결과 추적
위협 모델링 도구를 사용하는 것이 좋습니다. 도구는 위협을 식별하는 프로세스를 자동화하고 식별된 모든 위협에 대한 포괄적인 보고서를 생성할 수 있습니다. 관심 있는 모든 팀에 결과를 전달해야 합니다.
워크로드 팀의 백로그의 일부로 결과를 추적하여 적시에 책임을 지도록 합니다. 위협 모델링이 식별한 특정 위험을 완화할 책임이 있는 개인에게 작업을 할당합니다.
솔루션에 새 기능을 추가할 때 위협 모델을 업데이트하고 코드 관리 프로세스에 통합합니다. 보안 문제가 발견되면 심각도에 따라 문제를 심사하는 프로세스가 있는지 확인합니다. 이 프로세스는 문제를 해결하는 시기와 방법을 결정하는 데 도움이 됩니다(예: 다음 릴리스 주기 또는 더 빠른 릴리스에서).
중요 비즈니스용 워크로드 요구 사항을 정기적으로 검토합니다.
경영진 스폰서와 정기적으로 만나 요구 사항을 정의합니다. 이러한 검토는 기대치를 조정하고 운영 리소스를 이니셔티브에 할당할 수 있는 기회를 제공합니다.
Azure 촉진
Microsoft 보안 개발 수명 주기는 위협 모델링 프로세스를 지원하는 위협 모델링 도구를 제공합니다. 이 도구는 추가 비용 없이 사용할 수 있습니다. 자세한 내용은 위협 모델링 페이지를 참조하세요.
예제
이 예제는 보안 기준(SE:01)에 설정된 IT(정보 기술) 환경을 기반으로 합니다. 이 접근 방식은 다양한 IT 시나리오에서 위협 환경에 대한 광범위한 이해를 제공합니다.
개발 수명 주기 가상 사용자. 개발자, 테스터, 최종 사용자 및 관리자를 포함하여 개발 수명 주기에 관련된 많은 가상 사용자가 있습니다. 이러한 모든 항목이 손상되어 의도적으로 생성된 취약성 또는 위협을 통해 환경을 위험에 빠뜨릴 수 있습니다.
잠재적인 공격자. 공격자는 언제든지 쉽게 사용할 수 있는 광범위한 도구를 사용하여 취약성을 탐색하고 공격을 시작할 수 있다고 생각합니다.
보안 제어. 위협 분석의 일환으로 솔루션을 보호하는 데 사용할 Azure 보안 서비스와 해당 솔루션이 얼마나 효과적인지 식별합니다.
로그 컬렉션입니다. Azure 리소스 및 일부 온-프레미스 구성 요소의 로그를 Azure Log Analytics로 전송할 수 있으므로 개발된 솔루션의 동작을 이해하고 초기 취약성을 캡처하려고 할 수 있습니다.
SIEM(보안 정보 이벤트 관리) 솔루션. Microsoft Sentinel은 솔루션의 초기 단계에서도 추가될 수 있으므로 일부 분석 쿼리를 빌드하여 위협 및 취약성을 완화하고 프로덕션 환경에서 보안 환경을 예상할 수 있습니다.
클라우드용 Microsoft Defender 보안 상태를 개선하기 위해 몇 가지 보안 권장 사항을 만들 수 있습니다.
관련 링크
커뮤니티 링크
OWASP(Open Web Application Security Project)에서는 애플리케이션에 대한 위협 모델링 접근 방식을 문서화했습니다.
보안 검사 목록
전체 권장 사항 집합을 참조하세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기