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