보안 테스트에 대한 권장 사항
이 Power Platform Well-Architected Security 체크리스트 권장 사항에 적용됩니다.
| 남동:09 | 보안 문제를 방지하고, 위협 예방 구현을 검증하고, 위협 탐지 메커니즘을 테스트하는 접근 방식을 결합한 포괄적인 테스트 체계를 수립합니다. |
|---|
엄격한 테스트는 좋은 보안 설계의 기초입니다. 테스트는 컨트롤이 의도한 대로 작동하는지 확인하기 위한 전술적인 검증 형태입니다. 테스트는 시스템의 취약점을 사전에 감지하는 방법이기도 합니다.
다양한 관점에서 케이던스와 검증을 통해 테스트 엄격성을 확립합니다. 플랫폼과 인프라를 테스트하는 내부 관점과 외부 공격자처럼 시스템을 테스트하는 외부 내부 평가를 포함해야 합니다.
이 가이드에서는 워크로드의 보안 상태를 테스트하기 위한 권장 사항을 제공합니다. 공격에 대한 워크로드의 저항력을 향상하고 리소스의 기밀성, 무결성 및 가용성을 유지하려면 이러한 테스트 방법을 구현하십시오.
정의
| 용어 | 정의 |
|---|---|
| 애플리케이션 보안 테스트(AST) | Microsoft 코드의 보안 취약점을 확인하기 위해 화이트박스 및 블랙박스 테스트 방법론을 사용하는 보안 개발 수명 주기(SDL) 기술입니다. |
| 블랙박스 테스트 | 시스템 내부에 대한 지식 없이 외부에서 볼 수 있는 애플리케이션 동작을 검증하는 테스트 방법론입니다. |
| 블루팀 | 워게임 훈련에서 레드팀의 공격을 방어하는 팀입니다. |
| 침투 테스트 | 시스템의 보안 방어를 검증하기 위해 윤리적 해킹 기술을 사용하는 테스트 방법론입니다. |
| 레드팀 | 워게임 훈련에서 적의 역할을 맡아 시스템 해킹을 시도하는 팀입니다. |
| 보안 개발 수명 주기(SDL) | 보안 보증 및 규정 준수 요구 사항을 지원하는 Microsoft 에서 제공하는 일련의 관행입니다. |
| 소프트웨어 개발 수명 주기(SDLC) | 소프트웨어 시스템 개발을 위한 다단계의 체계적인 프로세스입니다. |
| 화이트박스 테스트 | 코드의 구조가 실무자에게 알려진 테스트 방법론입니다. |
주요 디자인 전략
테스트는 특히 보안에 있어 협상할 수 없는 전략입니다. 이를 통해 보안 문제가 악용되기 전에 사전에 발견하고 해결할 수 있으며 구현한 보안 제어가 설계된 대로 작동하는지 확인할 수 있습니다.
테스트 범위에는 애플리케이션, 인프라, 자동화된 프로세스 및 인적 프로세스가 포함되어야 합니다.
참고
이 지침에서는 테스트와 인시던트 대응을 구분합니다. 테스트는 프로덕션 전에 문제를 이상적으로 해결하는 감지 메커니즘이지만 사고 대응의 일부로 수행되는 수정 또는 조사와 혼동되어서는 안 됩니다. 보안 인시던트 복구 측면은 보안 인시던트 대응 권장 사항에 설명되어 있습니다.
테스트 계획에 참여하십시오. 워크로드 팀이 테스트 케이스를 설계하지 않을 수도 있습니다. 해당 작업은 기업 내에서 중앙 집중화되거나 외부 보안 전문가가 완료하는 경우가 많습니다. 워크로드 팀은 보안 보증이 애플리케이션 기능과 통합되도록 설계 프로세스에 참여해야 합니다.
공격자처럼 생각하십시오. 시스템이 공격을 받았다는 가정하에 테스트 사례를 설계하십시오. 이렇게 하면 잠재적인 취약점을 발견하고 이에 따라 테스트 우선 순위를 지정할 수 있습니다.
구조화된 방식과 반복 가능한 프로세스로 테스트를 실행하세요. 케이던스, 테스트 유형, 추진 요인 및 의도된 결과를 중심으로 테스트 엄격성을 구축하세요.
작업에 적합한 도구를 사용하십시오. 워크로드에 작동하도록 구성된 도구를 사용하십시오. 도구가 없으면 도구를 구입하세요. 빌드하지 마세요. 보안 도구는 고도로 전문화되어 있으므로 자체 도구를 빌드하면 위험이 발생할 수 있습니다. 중앙 SecOps 팀이 제공하는 전문 지식과 도구를 활용하거나 워크로드 팀에 해당 전문 지식이 없는 경우 외부 수단을 활용하세요.
별도의 환경을 설정하세요. 테스트는 파괴 테스트와 비파괴 테스트로 분류할 수 있습니다. 비파괴 테스트는 침입적이지 않습니다. 문제가 있음을 나타내지만 문제를 해결하기 위해 기능을 변경하지는 않습니다. 파괴 테스트는 침입적이며 데이터베이스에서 데이터를 삭제하여 기능을 손상시킬 수 있습니다.
프로덕션 환경에서 테스트하면 최상의 정보를 얻을 수 있지만 가장 큰 혼란을 초래합니다. 프로덕션 환경에서는 비파괴 테스트만 수행하는 경향이 있습니다. 비프로덕션 환경에서의 테스트는 일반적으로 덜 방해가 되지만 보안에 중요한 방식으로 프로덕션 환경의 구성을 정확하게 나타내지 못할 수 있습니다.
환경 복사 기능을 사용하여 프로덕션 환경의 격리된 복제본을 생성할 수 있습니다. 배포 파이프라인이 설정되어 있으면 전용 테스트 환경에 솔루션을 배포할 수도 있습니다.
항상 테스트 결과를 평가하십시오. 작업의 우선 순위를 지정하고 업스트림을 개선하는 데 결과를 사용하지 않으면 테스트는 헛된 노력입니다. 모범 사례를 포함하여 발견한 보안 지침을 문서화하세요. 결과와 해결 계획을 담은 문서는 공격자가 보안을 침해하려고 시도할 수 있는 다양한 방법에 대해 팀에 교육합니다. 개발자, 관리자, 테스터를 대상으로 정기적인 보안 교육을 실시하세요.
테스트 계획을 설계할 때 다음 질문에 대해 생각해 보십시오.
- 테스트가 얼마나 자주 실행될 것으로 예상하며, 테스트가 환경에 어떤 영향을 미치는가?
- 실행해야 하는 다양한 테스트 유형은 무엇인가?
테스트가 얼마나 자주 실행될 것으로 예상하는가?
워크로드를 정기적으로 테스트하여 변경으로 인해 보안 위험이 발생하지 않고 회귀가 없는지 확인하십시오. 또한 팀은 언제든지 수행될 수 있는 조직 보안 검증에 대응할 준비가 되어 있어야 합니다. 보안 사고에 대응하여 실행할 수 있는 테스트도 있습니다. 다음 섹션에서는 테스트 빈도에 대한 권장 사항을 제공합니다.
정기 테스트
정기 테스트는 표준 운영 절차의 일부로 규정 준수 요구 사항을 충족하기 위해 정기적으로 수행됩니다. 다양한 테스트가 다양한 주기로 실행될 수 있지만 중요한 것은 주기적으로 일정에 따라 수행된다는 것입니다.
이러한 테스트는 각 단계에서 심층적인 방어를 제공하므로 SDLC에 통합해야 합니다. 신원, 데이터 저장 및 전송, 통신 채널에 대한 보장을 검증하기 위해 테스트 제품군을 다양화합니다. 수명 주기의 여러 지점에서 동일한 테스트를 수행하여 회귀가 없는지 확인합니다. 일상적인 테스트는 초기 벤치마크를 설정하는 데 도움이 됩니다. 그러나 이는 단지 시작점일 뿐입니다. 수명 주기의 동일한 지점에서 새로운 문제를 발견하면 새로운 테스트 사례를 추가하게 됩니다. 테스트는 반복을 통해 개선됩니다.
각 단계에서 이러한 테스트는 추가 또는 제거된 코드 또는 변경된 구성 설정의 유효성을 검사하여 해당 변경 사항이 보안에 미치는 영향을 검색해야 합니다. 동료 검토와 균형을 이루는 자동화를 통해 테스트 효율성을 향상해야 합니다.
자동화된 파이프라인 또는 예약된 테스트 실행의 일부로 보안 테스트를 실행하는 것을 고려하세요. 보안 문제를 빨리 발견할수록 보안 문제를 일으키는 코드나 구성 변경 사항을 더 쉽게 찾을 수 있습니다.
자동화된 테스트에만 의존하지 마십시오. 수동 테스트를 사용하여 인간의 전문 지식으로만 발견할 수 있는 취약점을 탐지합니다. 수동 테스트는 탐색적 사용 사례와 알려지지 않은 위험을 찾는 데 좋습니다.
즉석 테스트
즉석 테스트는 보안 방어에 대한 특정 시점 검증을 제공합니다. 해당 시점에 워크로드에 영향을 미칠 수 있는 보안 경고가 이러한 테스트를 트리거합니다. 조직의 명령에는 경보가 긴급 상황으로 확대되는 경우 방어 전략의 효율성을 확인하기 위해 일시 중지 및 테스트 사고 방식이 필요할 수 있습니다.
즉석 테스트의 이점은 실제 사건에 대비할 수 있다는 것입니다. 이러한 테스트는 UAT(사용자 승인 테스트)를 수행하도록 강제하는 기능일 수 있습니다.
보안 팀은 모든 워크로드를 감사하고 필요에 따라 이러한 테스트를 실행할 수 있습니다. 워크로드 담당자로서 보안 팀을 촉진하고 협업해야 합니다. 준비할 수 있도록 보안팀과 충분한 리드 타임을 협상하세요. 이러한 중단이 필요하다는 점을 팀과 이해관계자에게 인정하고 전달하세요.
다른 경우에는 잠재적인 위협에 대해 테스트를 실행하고 시스템의 보안 상태를 보고해야 할 수도 있습니다.
트레이드오프: 즉석에서 진행된 테스트는 방해가 되는 일이기 때문에 작업의 우선순위를 다시 정해야 하며, 이로 인해 다른 계획된 작업이 지연될 수 있습니다.
위험: 알려지지 않은 것에 대한 위험이 있습니다. 즉석 테스트는 확립된 프로세스나 도구 없이 일회성 작업이 될 수 있습니다. 그러나 가장 큰 위험은 비즈니스 리듬이 중단될 가능성이 있다는 것입니다. 이점과 관련하여 위험을 평가해야 합니다.
보안 인시던트 테스트
보안 인시던트의 원인을 근원적으로 찾아내는 테스트가 있습니다. 이러한 보안 허점을 해결하여 인시던트가 반복되지 않도록 해야 합니다.
또한 인시던트는 기존 격차를 발견하여 시간이 지남에 따라 테스트 사례를 개선합니다. 팀은 인시던트에서 학습한 교훈을 적용하고 정기적으로 개선 사항을 통합해야 합니다.
어떤 유형의 테스트가 있나요?
테스트는 기술 및 테스트 방법론을 기준으로 분류할 수 있습니다. 해당 범주 내에서 해당 범주와 접근 방식을 결합하여 완전한 적용 범위를 확보하세요.
여러 테스트와 테스트 유형을 추가하면 다음을 확인할 수 있습니다.
- 보안 제어 또는 보완 제어의 격차.
- 구성 오류.
- 가시성 및 탐지 방법의 격차.
좋은 위협 모델링 연습은 테스트 범위와 빈도를 보장하기 위한 주요 영역을 가리킬 수 있습니다. 위협 모델링에 대한 권장 사항은 개발 수명 주기 보호를 위한 권장 사항을 참조하세요.
이 섹션에 설명된 대부분의 테스트는 일상적인 테스트로 실행될 수 있습니다. 그러나 반복성은 경우에 따라 비용을 발생시키고 중단을 초래할 수 있습니다. 이러한 장단점을 신중하게 고려하십시오.
기술 스택을 검증하는 테스트
다음은 테스트 유형과 중점 영역에 대한 몇 가지 예입니다. 이 목록은 완전한 것이 아닙니다. 애플리케이션 스택, 프런트엔드, 백엔드, API, 데이터베이스 및 외부 통합을 포함한 전체 스택을 테스트합니다.
- 데이터 보안: 데이터 암호화 및 액세스 제어의 효과를 테스트하여 데이터가 무단 액세스 및 변조로부터 적절하게 보호되는지 확인하세요.
- 네트워크 및 연결: 방화벽을 테스트하여 워크로드에 예상되고 허용되고 안전한 트래픽만 허용하는지 확인하세요.
- 애플리케이션: 애플리케이션 보안 테스트(AST) 기술을 통해 소스 코드를 테스트하여 따라와 안전한 코딩 관행을 유지하고 메모리 손상 및 권한 문제와 같은 런타임 오류를 포착합니다.
- ID: 역할 할당과 조건 검사가 의도한 대로 작동하는지 평가합니다.
테스트 방법론
테스트 방법론에는 다양한 관점이 있습니다. 실제 공격을 시뮬레이션하여 위협 헌팅을 지원하는 테스트를 권장합니다. 워크로드에 위협을 가하는 잠재적인 위협 행위자, 해당 기술 및 악용을 식별할 수 있습니다. 공격을 최대한 사실적으로 구현하세요. 위협 모델링 중에 식별한 모든 잠재적 위협 벡터를 사용하십시오.
실제 공격을 통해 테스트하면 다음과 같은 이점이 있습니다.
- 이러한 공격을 일상적인 테스트의 일부로 만들 때는 외부 관점을 사용하여 작업 부하를 확인하고 방어가 공격을 견딜 수 있는지 확인합니다.
- 팀은 배운 교훈을 바탕으로 지식과 기술 수준을 업그레이드합니다. 팀은 상황 인식을 개선하고 인시던트 대응 준비 상태를 자체 평가할 수 있습니다.
시뮬레이션 테스트의 예로는 블랙박스 및 화이트박스 테스트, 침투 테스트, 워 게임 연습 등이 있습니다.
블랙박스 및 화이트박스 테스트
이러한 테스트 유형은 두 가지 다른 관점을 제공합니다. 블랙박스 테스트에서는 시스템 내부가 보이지 않습니다. 화이트박스 테스트에서 테스터는 애플리케이션을 잘 이해하고 실험 수행을 위한 코드, 로그, 리소스 토폴로지 및 구성에 액세스할 수도 있습니다.
침투 테스트를 통해 공격을 시뮬레이션하는 테스트
조직의 IT 또는 애플리케이션 팀에 속하지 않은 보안 전문가가 침투 테스트(또는 펜테스팅)를 수행합니다. 전문가는 악의적인 공격자가 공격 표면을 탐색하는 방식으로 시스템을 봅니다. 전문가의 목표는 정보를 수집하고, 취약점을 분석하고, 결과를 보고함으로써 보안 격차를 찾는 것입니다.
전문가는 전체 조직의 중요한 데이터에 액세스해야 할 수도 있습니다. 액세스가 오용되지 않도록 참여 규칙을 준수하세요. 관련 정보에 나열된 리소스를 확인하세요.
워 게임 연습을 통해 공격을 시뮬레이션하는 테스트
이 시뮬레이션 공격 방법론에는 두 팀이 있습니다.
- 레드 팀은 실제 공격을 모델링하는 적입니다. 성공하면 보안 설계의 취약점을 발견하고 침해 사고의 폭발 반경이 얼마나 넓은지 평가합니다.
- 블루 팀은 공격을 방어하는 워크로드 팀입니다. 그들은 공격을 탐지하고, 대응하고, 복구하는 능력을 테스트합니다. 워크로드 리소스를 보호하기 위해 구현된 방어 기능을 검증합니다.
일상적인 테스트로 수행되는 경우 워 게임 훈련은 방어가 설계된 대로 작동하는지 지속적인 가시성과 확신을 제공할 수 있습니다. 워 게임 연습은 잠재적으로 워크로드 내의 여러 수준에 걸쳐 테스트할 수 있습니다.
현실적인 공격 시나리오를 시뮬레이션하기 위해 널리 사용되는 선택은 Microsoft 공격 시뮬레이션 훈련용 Office 365 Defender입니다.
자세한 내용은 공격 시뮬레이션 교육에 대한 인사이트 및 보고서를 참조하세요.
레드팀 및 블루팀 설정에 대한 자세한 내용은 Microsoft 클라우드 레드팀 구성을 참조하세요.
Power Platform 간편 사용
Microsoft Microsoft Power Platform Sentinel 솔루션을 사용하면 고객이 다음과 같은 다양한 의심스러운 활동을 감지할 수 있습니다.
- 권한이 없는 지역에서 Power Apps 실행
- Power Apps로 의심스러운 데이터 파괴
- Power Apps의 대량 삭제
- Power Apps를 통한 피싱 공격
- 퇴사하는 직원에 의한 Power Automate 흐름 활동
- 환경에 추가된 Microsoft Power Platform 커넥터
- Microsoft Power Platform 데이터 손실 방지 정책 업데이트 또는 제거
자세한 내용은 Microsoft Sentinel 솔루션 개요 Microsoft Power Platform 를 참조하세요.
제품 설명서는 Sentinel의 Microsoft 사냥 기능을 참조하세요.
Microsoft Defender for Cloud는 다양한 기술 분야에 대한 취약성 스캐닝을 제공합니다. 자세한 내용은 Defender Vulnerability Management를 사용하여 취약성 스캐닝 활성화 Microsoft 를 참조하세요.
DevSecOps의 작업 방식은 지속적인 개선 사고방식의 일부로 보안 테스트를 통합합니다. 전쟁 게임 연습은 Microsoft회사의 업무 리듬에 통합된 일반적인 관행입니다. 자세한 내용은 DevOps(DevSecOps)의 보안을 참조하십시오.
Azure DevOps는 CI/CD(지속적 통합/지속적 배포) 파이프라인의 일부로 자동화할 수 있는 타사 도구를 지원합니다. 자세한 내용은 Azure 및 GitHub에서 DevSecOps 활성화를 참조하세요.
관련 정보
최신 침투 테스트와 보안 평가는 Microsoft 서비스 신뢰 포털에서 확인할 수 있습니다.
Microsoft Microsoft 클라우드 서비스에 대한 광범위한 테스트를 수행합니다. 이 테스트에는 침투 테스트가 포함되어 있으며 결과는 조직의 Service Trust Portal에 게시됩니다. 귀하의 조직은 Microsoft Power Platform 및 Microsoft Dynamics 365 서비스에 대해 자체 침투 테스트를 수행할 수 있습니다. 모든 침투 테스트는 따라와 Microsoft 클라우드 침투 테스트 참여 규칙을 준수해야 합니다. 많은 경우, Microsoft 클라우드는 공유 인프라를 사용하여 귀하의 자산과 다른 고객의 자산을 호스팅한다는 점을 기억하는 것이 중요합니다. 모든 침투 테스트를 귀하의 자산으로 제한하고 주변의 다른 고객에게 의도하지 않은 결과를 초래하지 않도록 해야 합니다.
액세스가 오용되지 않도록 참여 규칙을 준수하십시오. 시뮬레이션 공격 계획 및 실행에 대한 지침은 다음을 참조하세요.
Azure에서 DoS(서비스 거부) 공격을 시뮬레이션할 수 있습니다. Azure DDoS Protection 시뮬레이션 테스트에 제시된 정책을 따르세요.
보안 체크리스트
전체 권장 사항 세트를 참조하세요.