보안 테스트에 대한 권장 사항

이 Azure 잘 설계된 프레임워크 보안 검사 목록 권장 사항에 적용됩니다.

엄격한 테스트는 좋은 보안 설계의 기초입니다. 테스트는 컨트롤이 의도한 대로 작동하는지 확인하기 위한 전술적 형식의 유효성 검사입니다. 테스트는 시스템의 취약성을 탐지하는 사전 예방적 방법이기도 합니다.

여러 관점에서 주기 및 확인을 통해 테스트 엄격성을 설정합니다. 플랫폼 및 인프라를 테스트하는 내부 아웃 뷰포인트와 외부 공격자처럼 시스템을 테스트하는 외부 평가를 포함해야 합니다.

이 가이드에서는 워크로드의 보안 상태를 테스트하기 위한 권장 사항을 제공합니다. 이러한 테스트 방법을 구현하여 공격에 대한 워크로드의 저항을 개선하고 리소스의 기밀성, 무결성 및 가용성을 유지합니다.

정의

주요 디자인 전략

테스트는 특히 보안을 위해 사용할 수 없는 전략입니다. 이를 통해 보안 문제가 악용되기 전에 사전에 검색하고 해결할 수 있으며 구현한 보안 컨트롤이 설계된 대로 작동하는지 확인할 수 있습니다.

테스트 범위에는 애플리케이션, 인프라 및 자동화된 사용자 프로세스가 포함되어야 합니다.

SDL에는 코드의 취약성을 파악하고, 런타임 구성 요소를 확인하고, 윤리적 해킹을 사용하여 시스템의 보안 복원력을 테스트하는 여러 유형의 테스트가 포함되어 있습니다. SDL은 키 시프트-왼쪽 작업입니다. 개발 프로세스 초기에 정적 코드 분석 및 IaC(Infrastructure as code)의 자동화된 검색과 같은 테스트를 실행해야 합니다.

테스트 계획에 참여합니다. 워크로드 팀은 테스트 사례를 설계하지 않을 수 있습니다. 이 작업은 종종 엔터프라이즈에서 중앙 집중화되거나 외부 보안 전문가에 의해 완료됩니다. 워크로드 팀은 보안 보증이 애플리케이션의 기능과 통합되도록 해당 디자인 프로세스에 참여해야 합니다.

공격자처럼 생각하십시오. 시스템이 공격을 받았다고 가정하여 테스트 사례를 디자인합니다. 이렇게 하면 잠재적인 취약성을 파악하고 그에 따라 테스트의 우선 순위를 지정할 수 있습니다.

반복 가능한 프로세스를 사용하여 구조적 방식으로 테스트를 실행합니다. 주기, 테스트 유형, 추진 요인 및 의도된 결과에 대한 테스트 엄격성을 구축합니다.

작업에 적합한 도구를 사용합니다. 워크로드를 사용하도록 구성된 도구를 사용합니다. 도구가 없는 경우 도구를 구입합니다. 빌드하지 마세요. 보안 도구는 매우 전문화되어 있으며 사용자 고유의 도구를 빌드하면 위험이 발생할 수 있습니다. 워크로드 팀에 전문 지식이 없는 경우 중앙 SecOps 팀 또는 외부 수단에서 제공하는 전문 지식과 도구를 활용합니다.

별도의 환경을 설정합니다. 테스트는 파괴적이거나 파괴적이지 않은 것으로 분류할 수 있습니다. 비동기 테스트는 침습적이지 않습니다. 문제가 있음을 나타내지만 문제를 해결하기 위해 기능을 변경하지 않습니다. 파괴적인 테스트는 침략적이며 데이터베이스에서 데이터를 삭제하여 기능을 손상시킬 수 있습니다.

프로덕션 환경에서 테스트하면 최상의 정보를 제공하지만 가장 많은 중단이 발생합니다. 프로덕션 환경에서는 비정상 테스트만 수행하는 경향이 있습니다. 비프로덕션 환경에서의 테스트는 일반적으로 중단이 적지만 보안에 중요한 방식으로 프로덕션 환경의 구성을 정확하게 나타내지 않을 수 있습니다.

IaC 및 자동화를 사용하여 배포하는 경우 테스트를 위해 프로덕션 환경의 격리된 복제본을 만들 수 있는지 여부를 고려합니다. 일상적인 테스트를 위한 지속적인 프로세스가 있는 경우 전용 환경을 사용하는 것이 좋습니다.

항상 테스트 결과를 평가합니다. 결과가 작업의 우선 순위를 지정하고 업스트림을 개선하는 데 사용되지 않는 경우 테스트는 낭비되는 작업입니다. 발견한 모범 사례를 포함한 보안 지침을 문서화합니다. 결과 및 수정 계획을 캡처하는 설명서는 공격자가 보안을 위반하려고 할 수 있는 다양한 방법을 팀에 교육합니다. 개발자, 관리자 및 테스터를 위한 정기적인 보안 교육을 수행합니다.

테스트 계획을 설계할 때 다음 질문에 대해 생각해 보세요.

• 테스트가 얼마나 자주 실행되기를 예상하며 환경에 어떤 영향을 주나요?

• 실행해야 하는 다른 테스트 유형은 무엇인가요?

정기적으로 워크로드 테스트

워크로드를 정기적으로 테스트하여 변경 내용이 보안 위험을 초래하지 않고 회귀가 없는지 확인합니다. 또한 팀은 언제든지 수행될 수 있는 조직 보안 유효성 검사에 응답할 준비가 되어 있어야 합니다. 보안 인시던트에 대한 응답으로 실행할 수 있는 테스트도 있습니다. 다음 섹션에서는 테스트 빈도에 대한 권장 사항을 제공합니다.

일상적인 테스트

일상적인 테스트는 표준 운영 절차의 일부로 정기적으로 수행되며 규정 준수 요구 사항을 충족합니다. 다양한 테스트는 서로 다른 주기로 실행될 수 있지만 핵심은 주기적으로 그리고 일정에 따라 수행된다는 것입니다.

각 단계에서 심층 방어를 제공하기 때문에 이러한 테스트를 SDLC에 통합해야 합니다. ID, 데이터 스토리지 및 전송 및 통신 채널에 대한 보증을 확인하도록 테스트 제품군을 다양화합니다. 수명 주기의 다른 지점에서 동일한 테스트를 수행하여 회귀가 없는지 확인합니다. 일상적인 테스트는 초기 벤치마크를 설정하는 데 도움이 됩니다. 그러나 이는 시작점에 불과합니다. 수명 주기의 동일한 지점에서 새 문제를 발견할 때 새 테스트 사례를 추가합니다. 테스트도 반복하여 개선됩니다.

각 단계에서 이러한 테스트는 추가 또는 제거된 코드 또는 변경 내용의 보안 영향을 감지하기 위해 변경된 구성 설정의 유효성을 검사해야 합니다. 피어 리뷰와 균형 잡힌 자동화를 사용하여 테스트의 효율성을 개선해야 합니다.

자동화된 파이프라인 또는 예약된 테스트 실행의 일부로 보안 테스트를 실행하는 것이 좋습니다. 보안 문제를 더 빨리 발견할수록 이를 유발하는 코드 또는 구성 변경 내용을 더 쉽게 찾을 수 있습니다.

자동화된 테스트에만 의존하지 마세요. 수동 테스트를 사용하여 인간의 전문 지식만 파악할 수 있는 취약성을 감지합니다. 수동 테스트는 예비 사용 사례 및 알 수 없는 위험을 찾는 데 적합합니다.

즉석 테스트

즉석 테스트는 보안 방어에 대한 특정 시점 유효성 검사를 제공합니다. 해당 시점에 워크로드에 영향을 미칠 수 있는 보안 경고가 이러한 테스트를 트리거합니다. 조직의 명령에 따라 경고가 긴급 상황으로 확대되는 경우 방어 전략의 효율성을 확인하기 위해 일시 중지 및 테스트 사고방식이 필요할 수 있습니다.

즉석 테스트의 이점은 실제 인시던트에 대한 준비입니다. 이러한 테스트는 UAT(사용자 승인 테스트)를 수행하는 강제 함수일 수 있습니다.

보안 팀은 모든 워크로드를 감사하고 필요에 따라 이러한 테스트를 실행할 수 있습니다. 워크로드 소유자는 보안 팀과 쉽게 협력하고 협업해야 합니다. 준비할 수 있도록 보안 팀과 충분한 리드 타임을 협상합니다. 이러한 중단이 필요하다는 것을 팀 및 이해 관계자에게 인정하고 전달합니다.

다른 경우에는 테스트를 실행하고 잠재적인 위협에 대해 시스템의 보안 상태를 보고해야 할 수 있습니다.

절충: 즉석 테스트는 중단 이벤트이므로 작업의 우선 순위를 다시 지정하여 다른 계획된 작업이 지연될 수 있습니다.

위험: 알 수 없는 위험이 있습니다. 즉석 테스트는 설정된 프로세스나 도구가 없는 일회성 작업일 수 있습니다. 그러나 주된 위험은 비즈니스 리듬의 잠재적 중단입니다. 혜택을 기준으로 이러한 위험을 평가해야 합니다.

보안 인시던트 테스트

원본에서 보안 인시던트 원인을 감지하는 테스트가 있습니다. 인시던트가 반복되지 않도록 이러한 보안 격차를 해결해야 합니다.

또한 인시던트는 기존 격차를 발견하여 시간이 지남에 따라 테스트 사례를 개선합니다. 팀은 인시던트에서 배운 교훈을 적용하고 정기적으로 개선 사항을 통합해야 합니다.

다양한 테스트 사용

테스트는 기술 및 테스트 방법론에 따라 분류할 수 있습니다. 해당 범주 내에서 해당 범주와 접근 방식을 결합하여 완전한 범위를 얻습니다.

여러 테스트 및 테스트 유형을 추가하여 다음을 발견할 수 있습니다.

• 보안 컨트롤 또는 보상 컨트롤의 간격입니다.

• 구성이 잘못되었습니다.

• 관찰 가능성 및 검색 방법의 차이입니다.

좋은 위협 모델링 연습은 테스트 검사 및 빈도를 보장하기 위해 주요 영역을 가리킬 수 있습니다. 위협 모델링에 대한 권장 사항은 개발 수명 주기를 보호하기 위한 권장 사항을 참조 하세요.

이 섹션에서 설명하는 대부분의 테스트는 일상적인 테스트로 실행할 수 있습니다. 그러나 반복성은 경우에 따라 비용이 발생하고 중단을 일으킬 수 있습니다. 이러한 절충을 신중하게 고려하십시오.

기술 스택의 유효성을 검사하는 테스트

다음은 테스트 유형 및 해당 포커스 영역의 몇 가지 예입니다. 이 목록은 완전하지 않습니다. 애플리케이션 스택, 프런트 엔드, 백 엔드, API, 데이터베이스 및 외부 통합을 포함하여 전체 스택을 테스트합니다.

• 데이터 보안: 데이터 암호화 및 액세스 제어의 효율성을 테스트하여 무단 액세스 및 변조로부터 데이터가 제대로 보호되는지 확인합니다.

• 네트워크 및 연결: 방화벽을 테스트하여 워크로드에 대한 예상, 허용 및 안전한 트래픽만 허용하는지 확인합니다.

• 애플리케이션: AST(애플리케이션 보안 테스트) 기술을 통해 소스 코드를 테스트하여 보안 코딩 사례를 따르고 메모리 손상 및 권한 문제와 같은 런타임 오류를 catch합니다. 자세한 내용은 이러한 커뮤니티 링크를 참조하세요.

• ID: 역할 할당 및 조건부 검사가 의도한 대로 작동하는지 평가합니다.

테스트 방법론

테스트 방법론에 대한 많은 관점이 있습니다. 실제 공격을 시뮬레이션하여 위협 헌팅을 사용하도록 설정하는 테스트를 권장합니다. 잠재적인 위협 행위자, 기술 및 워크로드에 위협이 되는 악용을 식별할 수 있습니다. 공격을 가능한 한 현실적으로 만듭니다. 위협 모델링 중에 식별하는 모든 잠재적 위협 벡터를 사용합니다.

실제 공격을 통한 테스트의 몇 가지 장점은 다음과 같습니다.

• 이러한 공격을 일상적인 테스트의 일부로 만들 때는 외부 관점을 사용하여 워크로드를 확인하고 방어가 공격을 견딜 수 있는지 확인합니다.

• 학습한 교훈에 따라 팀은 지식과 기술 수준을 업그레이드합니다. 팀은 상황 인식을 개선하고 사고에 대응할 준비를 자체 평가할 수 있습니다.

위험: 일반적으로 테스트는 성능에 영향을 줄 수 있습니다. 파괴적인 테스트가 데이터를 삭제하거나 손상된 경우 비즈니스 연속성 문제가 있을 수 있습니다. 정보 노출과 관련된 위험도 있습니다. 데이터의 기밀성을 유지해야 합니다. 테스트를 완료한 후 데이터의 무결성을 확인합니다.

시뮬레이션된 테스트의 몇 가지 예로는 블랙박스 및 화이트 박스 테스트, 침투 테스트 및 전쟁 게임 연습이 있습니다.

블랙 박스 및 화이트 박스 테스트

이러한 테스트 유형은 두 가지 관점을 제공합니다. 블랙박스 테스트에서는 시스템 내부가 표시되지 않습니다. 화이트 박스 테스트에서 테스터는 애플리케이션을 잘 이해하고 있으며 실험을 수행하기 위한 코드, 로그, 리소스 토폴로지 및 구성에 액세스할 수도 있습니다.

위험: 두 유형의 차이는 선행 비용입니다. 화이트 박스 테스트는 시스템을 이해하는 데 걸리는 시간 측면에서 비용이 많이 들 수 있습니다. 화이트 박스 테스트를 수행하려면 특수 도구를 구매해야 하는 경우도 있습니다. 블랙 박스 테스트는 램프 업 시간이 필요하지 않지만 효과적이지 않을 수 있습니다. 문제를 발견하기 위해 추가적인 노력을 기울여야 할 수도 있습니다. 그것은 시간 투자 절충입니다.

침투 테스트를 통해 공격을 시뮬레이션하는 테스트

조직의 IT 또는 애플리케이션 팀에 속하지 않는 보안 전문가는 침투 테스트 또는 펜테스트를 수행합니다. 악의적인 행위자가 공격 표면의 범위를 지정하는 방식으로 시스템을 살펴봅니다. 그들의 목표는 정보를 수집하고, 취약성을 분석하고, 결과를 보고하여 보안 격차를 찾는 것입니다.

절충: 침투 테스트는 즉흥적으로 수행되며, 일반적으로 제3자 실무자가 제공하는 유료 제공이므로 중단 및 금전적 투자 측면에서 비용이 많이 들 수 있습니다.

위험: 테스트 연습은 런타임 환경에 영향을 줄 수 있으며 일반 트래픽의 가용성을 방해할 수 있습니다.

실무자는 전체 조직의 중요한 데이터에 액세스해야 할 수 있습니다. 참여 규칙을 따라 액세스가 오용되지 않도록 합니다. 관련 링크에 나열된 리소스를 참조하세요.

전쟁 게임 연습을 통해 공격을 시뮬레이션하는 테스트

시뮬레이션된 공격의 이 방법론에는 두 개의 팀이 있습니다.

• 빨간색 팀은 실제 공격을 모델링하려는 악의적인 팀입니다. 성공하면 보안 디자인에서 차이를 찾고 위반의 폭발 반경 포함을 평가합니다.

• 파란색 팀은 공격을 방어하는 워크로드 팀입니다. 공격을 탐지, 대응 및 수정하는 기능을 테스트합니다. 워크로드 리소스를 보호하기 위해 구현된 방어의 유효성을 검사합니다.

일상적인 테스트로 수행되는 경우, 전쟁 게임 연습은 방어가 설계대로 작동하는지 지속적으로 가시성과 보증을 제공할 수 있습니다. 전쟁 게임 연습은 잠재적으로 워크로드 내의 수준에서 테스트할 수 있습니다.

사실적인 공격 시나리오를 시뮬레이션하는 인기 있는 선택은 Office 365용 Microsoft Defender 공격 시뮬레이션 훈련.

자세한 내용은 공격 시뮬레이션 훈련 대한 인사이트 및 보고서를 참조하세요.

레드 팀 및 블루 팀 설정에 대한 자세한 내용은 Microsoft Cloud Red Teaming을 참조 하세요.

Azure 촉진

Microsoft Sentinel은 SIEM(보안 정보 이벤트 관리)과 SOAR(보안 오케스트레이션 자동화 응답) 기능을 결합하는 네이티브 컨트롤입니다. 연결된 다양한 원본의 이벤트 및 로그를 분석합니다. Microsoft Sentinel은 데이터 원본 및 해당 경고를 기반으로 인시던트 생성 및 조기 검색을 위한 위협 분석을 수행합니다. 지능형 분석 및 쿼리를 통해 보안 문제를 사전에 찾아낼 수 있습니다. 인시던트가 있는 경우 워크플로를 자동화할 수 있습니다. 또한 통합 문서 템플릿을 사용하면 시각화를 통해 신속하게 인사이트를 얻을 수 있습니다.

제품 설명서는 Microsoft Sentinel의 헌팅 기능을 참조하세요.

클라우드용 Microsoft Defender 다양한 기술 영역에 대한 취약성 검사를 제공합니다. 자세한 내용은 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 은 일반적인 위협을 다루는 애플리케이션 및 테스트 사례에 대한 보안 모범 사례를 제공합니다.

보안 검사 목록

전체 권장 사항 집합을 참조하세요.