보안 테스트에 대한 권장 사항
이 Azure Well-Architected Framework 보안 검사 목록 권장 사항에 적용됩니다.
| SE:11 | 보안 문제를 방지하고, 위협 방지 구현의 유효성을 검사하고, 위협 탐지 메커니즘을 테스트하는 방법을 결합하는 포괄적인 테스트 처방을 설정합니다. |
|---|
엄격한 테스트는 좋은 보안 설계의 기초입니다. 테스트는 컨트롤이 의도한 대로 작동하는지 확인하기 위한 전술적 유효성 검사 형식입니다. 테스트는 시스템의 취약성을 탐지하는 사전 예방적 방법이기도 합니다.
여러 관점에서 주기 및 확인을 통해 테스트 엄격성을 설정합니다. 플랫폼 및 인프라를 테스트하는 내부 관점과 외부 공격자처럼 시스템을 테스트하는 외부 평가를 포함해야 합니다.
이 가이드에서는 워크로드의 보안 상태를 테스트하기 위한 권장 사항을 제공합니다. 이러한 테스트 방법을 구현하여 공격에 대한 워크로드의 저항을 개선하고 리소스의 기밀성, 무결성 및 가용성을 유지합니다.
정의
| 용어 | 정의 |
|---|---|
| AST(애플리케이션 보안 테스트) | 화이트박스 및 블랙박스 테스트 방법론을 사용하여 코드의 보안 취약성을 검사 Microsoft SDL(보안 개발 수명 주기) 기술입니다. |
| 블랙박스 테스트 | 시스템 내부를 모르고 외부에서 표시되는 애플리케이션 동작의 유효성을 검사하는 테스트 방법론입니다. |
| 블루 팀 | 전쟁 게임 연습에서 레드 팀의 공격을 방어하는 팀. |
| 침투 테스트 | 윤리적 해킹 기술을 사용하여 시스템의 보안 방어의 유효성을 검사하는 테스트 방법론입니다. |
| 레드 팀 | 적의 역할을 하고 전쟁 게임 연습에서 시스템을 해킹하려는 팀입니다. |
| SDL(Security Development Lifecycle) | 보안 보증 및 규정 준수 요구 사항을 지원하는 Microsoft에서 제공하는 일련의 사례입니다. |
| SDLC(소프트웨어 개발 수명 주기) | 소프트웨어 시스템 개발을 위한 다단계적이고 체계적인 프로세스입니다. |
| 화이트 박스 테스트 | 코드 구조가 실무자에게 알려진 테스트 방법론입니다. |
주요 디자인 전략
테스트는 특히 보안을 위해 신뢰할 수 없는 전략입니다. 이를 통해 보안 문제를 악용하기 전에 사전에 검색하고 해결할 수 있으며 구현한 보안 컨트롤이 설계된 대로 작동하는지 확인할 수 있습니다.
테스트의 scope 애플리케이션, 인프라 및 자동화된 인간 프로세스를 포함해야 합니다.
참고
이 지침은 테스트와 인시던트 대응을 구분합니다. 테스트는 프로덕션 이전의 문제를 이상적으로 해결하는 검색 메커니즘이지만 인시던트 대응의 일부로 수행되는 수정 또는 조사와 혼동해서는 안 됩니다. 보안 인시던트에서 복구하는 측면은 인시던트 대응 권장 사항에 설명되어 있습니다.
SDL에는 코드의 취약성을 파악하고, 런타임 구성 요소를 확인하고, 윤리적 해킹을 사용하여 시스템의 보안 복원력을 테스트하는 여러 유형의 테스트가 포함되어 있습니다. SDL은 키 시프트-왼쪽 작업입니다. 개발 프로세스 초기에 정적 코드 분석 및 IaC(Infrastructure as Code)의 자동화된 검사와 같은 테스트를 실행해야 합니다.
테스트 계획에 참여합니다. 워크로드 팀은 테스트 사례를 설계하지 않을 수 있습니다. 이 작업은 종종 엔터프라이즈에서 중앙 집중화되거나 외부 보안 전문가에 의해 완료됩니다. 워크로드 팀은 보안 보증이 애플리케이션의 기능과 통합되도록 디자인 프로세스에 참여해야 합니다.
공격자처럼 생각하십시오. 시스템이 공격을 받았다고 가정하여 테스트 사례를 디자인합니다. 이렇게 하면 잠재적인 취약성을 파악하고 그에 따라 테스트의 우선 순위를 지정할 수 있습니다.
반복 가능한 프로세스를 사용하여 구조적 방식으로 테스트를 실행합니다. 주기, 테스트 유형, 추진 요인 및 의도된 결과를 중심으로 테스트 엄격함을 구축합니다.
작업에 적합한 도구를 사용합니다. 워크로드를 사용하도록 구성된 도구를 사용합니다. 도구가 없는 경우 도구를 구입합니다. 빌드하지 마세요. 보안 도구는 매우 전문화되어 있으며 사용자 고유의 도구를 빌드하면 위험이 발생할 수 있습니다. 워크로드 팀에 전문 지식이 없는 경우 중앙 SecOps 팀 또는 외부 수단에서 제공하는 전문 지식과 도구를 활용합니다.
별도의 환경을 설정합니다. 테스트는 파괴적이거나 비폭력적인 테스트로 분류할 수 있습니다. 비동기 테스트는 침습적이지 않습니다. 문제가 있음을 나타내지만 문제를 해결하기 위해 기능을 변경하지 않습니다. 파괴적인 테스트는 침략적이며 데이터베이스에서 데이터를 삭제하여 기능을 손상시킬 수 있습니다.
프로덕션 환경에서 테스트하면 최상의 정보를 제공하지만 가장 많은 중단이 발생합니다. 프로덕션 환경에서는 비동기 테스트만 수행하는 경향이 있습니다. 비프로덕션 환경에서 테스트는 일반적으로 중단이 적지만 보안에 중요한 방식으로 프로덕션 환경의 구성을 정확하게 나타내지 않을 수 있습니다.
IaC 및 자동화를 사용하여 배포하는 경우 테스트를 위해 프로덕션 환경의 격리된 복제본을 만들 수 있는지 여부를 고려합니다. 일상적인 테스트를 위한 지속적인 프로세스가 있는 경우 전용 환경을 사용하는 것이 좋습니다.
항상 테스트 결과를 평가합니다. 결과가 작업의 우선 순위를 지정하고 업스트림 개선하는 데 사용되지 않는 경우 테스트는 낭비되는 작업입니다. 발견한 모범 사례를 포함한 보안 지침을 문서화합니다. 결과 및 수정 계획을 캡처하는 설명서는 공격자가 보안을 위반하려고 시도할 수 있는 다양한 방법에 대해 팀에 교육합니다. 개발자, 관리자 및 테스터를 위한 정기적인 보안 교육을 수행합니다.
테스트 계획을 설계할 때 다음 질문에 대해 생각해 보세요.
테스트가 실행되기를 얼마나 자주 예상하며 환경에 어떤 영향을 주나요?
실행해야 하는 다양한 테스트 유형은 무엇인가요?
테스트가 얼마나 자주 실행되기를 예상합니까?
워크로드를 정기적으로 테스트하여 변경 내용이 보안 위험을 초래하지 않고 회귀가 없는지 확인합니다. 또한 팀은 언제든지 수행될 수 있는 조직 보안 유효성 검사에 응답할 준비가 되어 있어야 합니다. 보안 인시던트에 대응하여 실행할 수 있는 테스트도 있습니다. 다음 섹션에서는 테스트 빈도에 대한 권장 사항을 제공합니다.
일상적인 테스트
일상적인 테스트는 표준 운영 절차의 일부로 정기적으로 수행되며 규정 준수 요구 사항을 충족합니다. 다양한 테스트는 서로 다른 주기로 실행될 수 있지만 핵심은 주기적으로 그리고 일정에 따라 수행된다는 것입니다.
각 단계에서 심층 방어를 제공하기 때문에 이러한 테스트를 SDLC에 통합해야 합니다. 테스트 제품군을 다양화하여 ID, 데이터 스토리지 및 전송 및 통신 채널에 대한 보증을 확인합니다. 수명 주기의 다른 지점에서 동일한 테스트를 수행하여 회귀가 없는지 확인합니다. 일상적인 테스트는 초기 벤치마크를 설정하는 데 도움이 됩니다. 그러나 이는 시작점에 불과합니다. 수명 주기의 동일한 지점에서 새 문제를 발견할 때 새 테스트 사례를 추가합니다. 테스트도 반복하여 개선됩니다.
각 단계에서 이러한 테스트는 해당 변경 내용의 보안 영향을 감지하기 위해 추가 또는 제거된 코드 또는 변경된 구성 설정의 유효성을 검사해야 합니다. 피어 리뷰와 균형이 잡힌 자동화를 사용하여 테스트의 효율성을 개선해야 합니다.
자동화된 파이프라인 또는 예약된 테스트 실행의 일부로 보안 테스트를 실행하는 것이 좋습니다. 보안 문제를 더 빨리 발견할수록 이를 유발하는 코드 또는 구성 변경을 더 쉽게 찾을 수 있습니다.
자동화된 테스트에만 의존하지 마세요. 수동 테스트를 사용하여 인간의 전문 지식만 파악할 수 있는 취약성을 감지합니다. 수동 테스트는 예비 사용 사례 및 알 수 없는 위험을 찾는 데 적합합니다.
즉석 테스트
즉석 테스트는 보안 방어의 특정 시점 유효성 검사를 제공합니다. 당시 워크로드에 영향을 줄 수 있는 보안 경고는 이러한 테스트를 트리거합니다. 경고가 비상 사태로 확대될 경우 조직의 의무에 따라 방어 전략의 효과를 확인하기 위해 일시 중지 및 테스트 사고방식이 필요할 수 있습니다.
즉석 테스트의 이점은 실제 인시던트에 대한 준비입니다. 이러한 테스트는 UAT(사용자 동의 테스트)를 수행하는 강제 함수일 수 있습니다.
보안 팀은 모든 워크로드를 감사하고 필요에 따라 이러한 테스트를 실행할 수 있습니다. 워크로드 소유자는 보안 팀과 쉽게 협업해야 합니다. 준비할 수 있도록 보안 팀과 충분한 리드 타임을 협상합니다. 이러한 중단이 필요하다는 것을 팀 및 이해 관계자에게 인정하고 전달합니다.
다른 경우에는 테스트를 실행하고 잠재적인 위협에 대해 시스템의 보안 상태를 보고해야 할 수 있습니다.
절충: 즉석 테스트는 중단 이벤트이므로 작업의 우선 순위를 다시 지정하여 다른 계획된 작업을 지연시킬 수 있습니다.
위험: 알 수 없는 위험이 있습니다. 즉석 테스트는 설정된 프로세스 또는 도구가 없는 일회성 작업일 수 있습니다. 그러나 주요 위험은 비즈니스 리듬의 잠재적 중단입니다. 이러한 위험을 혜택과 비교하여 평가해야 합니다.
보안 인시던트 테스트
원본에서 보안 인시던트 원인을 감지하는 테스트가 있습니다. 인시던트가 반복되지 않도록 이러한 보안 격차를 해결해야 합니다.
또한 인시던트에서는 기존 격차를 파악하여 시간이 지남에 따라 테스트 사례를 개선합니다. 팀은 인시던트에서 배운 교훈을 적용하고 정기적으로 개선 사항을 통합해야 합니다.
다양한 유형의 테스트는 무엇인가요?
테스트는 기술 및 테스트 방법론에 따라 분류할 수 있습니다. 이러한 범주와 접근 방식을 해당 범주 내에서 결합하여 전체 적용 범위를 가져옵니다.
여러 테스트 및 테스트 유형을 추가하여 다음을 발견할 수 있습니다.
보안 컨트롤 또는 보상 컨트롤의 간격입니다.
잘못된 구성.
가시성 및 검색 방법의 차이입니다.
좋은 위협 모델링 연습은 테스트 검사 및 빈도를 보장하기 위해 주요 영역을 가리킬 수 있습니다. 위협 모델링에 대한 권장 사항은 개발 수명 주기를 보호하기 위한 권장 사항을 참조하세요.
이러한 섹션에 설명된 대부분의 테스트는 일상적인 테스트로 실행할 수 있습니다. 그러나 반복성으로 인해 경우에 따라 비용이 발생하고 중단이 발생할 수 있습니다. 이러한 절충을 신중하게 고려하십시오.
기술 스택의 유효성을 검사하는 테스트
다음은 테스트 유형 및 포커스 영역의 몇 가지 예입니다. 이 목록은 일부만 포함하고 있습니다. 애플리케이션 스택, 프런트 엔드, 백 엔드, API, 데이터베이스 및 외부 통합을 포함하여 전체 스택을 테스트합니다.
데이터 보안: 데이터 암호화 및 액세스 제어의 효율성을 테스트하여 무단 액세스 및 변조로부터 데이터가 제대로 보호되는지 확인합니다.
네트워크 및 연결: 방화벽을 테스트하여 워크로드에 대한 예상, 허용 및 안전한 트래픽만 허용하는지 확인합니다.
애플리케이션: AST(애플리케이션 보안 테스트) 기술을 통해 소스 코드를 테스트하여 보안 코딩 사례를 따르고 메모리 손상 및 권한 문제와 같은 런타임 오류를 catch합니다. 자세한 내용은 이러한 커뮤니티 링크를 참조하세요.
ID: 역할 할당 및 조건부 검사가 의도한 대로 작동하는지 평가합니다.
테스트 방법론
테스트 방법론에 대한 많은 관점이 있습니다. 실제 공격을 시뮬레이션하여 위협 헌팅을 사용하도록 설정하는 테스트를 권장합니다. 잠재적인 위협 행위자, 기술 및 워크로드에 위협이 되는 악용을 식별할 수 있습니다. 공격을 가능한 한 현실적으로 만듭니다. 위협 모델링 중에 식별하는 모든 잠재적 위협 벡터를 사용합니다.
다음은 실제 공격을 통한 테스트의 몇 가지 이점입니다.
이러한 공격을 일상적인 테스트의 일부로 만들 때 외부 관점을 사용하여 워크로드를 검사 방어가 공격을 견딜 수 있는지 확인합니다.
학습한 교훈을 바탕으로 팀은 지식과 기술 수준을 업그레이드합니다. 팀은 상황 인식을 개선하고 사고에 대응하기 위한 준비 상태를 자체 평가할 수 있습니다.
시뮬레이션된 테스트의 몇 가지 예로는 블랙박스 및 화이트박스 테스트, 침투 테스트 및 전쟁 게임 연습이 있습니다.
블랙박스 및 화이트박스 테스트
이러한 테스트 유형은 두 가지 관점을 제공합니다. 블랙박스 테스트에서는 시스템 내부가 표시되지 않습니다. 화이트 박스 테스트에서 테스터는 애플리케이션을 잘 이해하고 있으며 실험을 수행하기 위한 코드, 로그, 리소스 토폴로지 및 구성에 액세스할 수도 있습니다.
침투 테스트를 통해 공격을 시뮬레이션하는 테스트
organization IT 또는 애플리케이션 팀에 속하지 않는 보안 전문가는 침투 테스트 또는 테스트를 수행합니다. 악의적인 행위자가 공격 표면을 scope 방식으로 시스템을 살펴봅니다. 그들의 목표는 정보를 수집하고, 취약성을 분석하고, 결과를 보고하여 보안 격차를 찾는 것입니다.
실무자는 전체 organization 중요한 데이터에 액세스해야 할 수 있습니다. 액세스가 오용되지 않도록 참여 규칙을 따릅니다. 관련 링크에 나열된 리소스를 참조하세요.
전쟁 게임 연습을 통해 공격을 시뮬레이션하는 테스트
시뮬레이션된 공격에 대한 이 방법론에는 두 개의 팀이 있습니다.
레드 팀은 실제 공격을 모델링하려는 악의적인 팀입니다. 성공하면 보안 디자인에서 차이를 찾고 위반의 폭발 반경 포함을 평가합니다.
블루 팀은 공격을 방어하는 워크로드 팀입니다. 공격을 탐지, 대응 및 수정하는 기능을 테스트합니다. 워크로드 리소스를 보호하기 위해 구현된 방어의 유효성을 검사합니다.
일상적인 테스트로 수행되는 경우 전쟁 게임 연습은 방어가 설계된 대로 작동하는지 지속적으로 가시성과 보증을 제공할 수 있습니다. 전쟁 게임 연습은 잠재적으로 워크로드 내의 수준에서 테스트할 수 있습니다.
현실적인 공격 시나리오를 시뮬레이션하는 데 널리 사용되는 선택은 Office 365용 Microsoft Defender 공격 시뮬레이션 훈련.
자세한 내용은 공격 시뮬레이션 훈련 대한 인사이트 및 보고서를 참조하세요.
레드 팀 및 블루 팀 설정에 대한 자세한 내용은 Microsoft Cloud Red Teaming을 참조하세요.
Azure 촉진
Microsoft Sentinel은 SIEM(보안 정보 이벤트 관리) 및 SOAR(보안 오케스트레이션 자동화 응답) 기능을 결합하는 네이티브 컨트롤입니다. 연결된 다양한 원본의 이벤트 및 로그를 분석합니다. 데이터 원본 및 해당 경고에 따라 Microsoft Sentinel은 인시던트 생성 및 조기 검색을 위한 위협 분석을 수행합니다. 지능형 분석 및 쿼리를 통해 보안 문제를 사전에 헌팅할 수 있습니다. 인시던트가 있는 경우 워크플로를 자동화할 수 있습니다. 또한 통합 문서 템플릿을 사용하면 시각화를 통해 신속하게 인사이트를 얻을 수 있습니다.
제품 설명서는 Microsoft Sentinel의 헌팅 기능을 참조하세요.
Microsoft Defender for Cloud는 다양한 기술 영역에 대한 취약성 검사를 제공합니다. 자세한 내용은 Microsoft Defender 취약성 관리 - 클라우드용 Microsoft Defender 사용하여 취약성 검사 사용을 참조하세요.
DevSecOps의 사례는 지속적인 지속적인 개선 사고방식의 일부로 보안 테스트를 통합합니다. 전쟁 게임 연습은 Microsoft의 비즈니스 리듬에 통합된 일반적인 관행입니다. 자세한 내용은 DevOps의 보안(DevSecOps)을 참조하세요.
Azure DevOps는 연속 통합/지속적인 배포 파이프라인의 일부로 자동화할 수 있는 타사 도구를 지원합니다. 자세한 내용은 Azure 및 GitHub에서 DevSecOps 사용 - Azure DevOps를 참조하세요.
관련 링크
참여 규칙을 따라 액세스가 오용되지 않도록 합니다. 시뮬레이션된 공격을 계획하고 실행하는 방법에 대한 지침은 다음 문서를 참조하세요.
Azure에서 DoS(서비스 거부) 공격을 시뮬레이션할 수 있습니다. Azure DDoS Protection 시뮬레이션 테스트에 명시된 정책을 따라야 합니다.
커뮤니티 링크
애플리케이션 보안 테스트: 도구, 유형 및 모범 사례 - GitHub 리소스 는 애플리케이션의 빌드 시간 및 런타임 방어를 테스트할 수 있는 테스트 방법론의 유형을 설명합니다.
PTES(Penetration Testing Execution Standard)는 일반적인 시나리오에 관한 지침과 기준을 설정하는 데 필요한 작업을 제공합니다.
OWASP 상위 10개 | OWASP Foundation 은 일반적인 위협을 다루는 애플리케이션 및 테스트 사례에 대한 보안 모범 사례를 제공합니다.
보안 검사 목록
전체 권장 사항 집합을 참조하세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기