Azure에서 보안 애플리케이션 디자인

이 문서에서는 클라우드용 애플리케이션을 디자인할 때 고려할 보안 활동 및 컨트롤을 제공합니다. Microsoft SDL(보안 개발 수명 주기) 의 요구 사항 및 디자인 단계에서 고려해야 할 보안 질문 및 개념과 함께 학습 리소스를 다룹니다. 목표는 보다 안전한 애플리케이션을 설계하는 데 사용할 수 있는 활동 및 Azure 서비스를 정의하는 데 도움이 되는 것입니다.

이 문서에서는 다음 SDL 단계를 다룹니다.

• 학습
• 요구 사항
• 디자인

학습

클라우드 애플리케이션 개발을 시작하기 전에 시간을 내어 Azure의 보안 및 개인 정보를 파악합니다. 이 단계를 수행하면 애플리케이션에서 악용 가능한 취약성의 수와 심각도를 줄일 수 있습니다. 끊임없이 변화하는 위협 환경에 적절하게 대응할 준비가 됩니다.

학습 단계에서 다음 리소스를 사용하여 개발자가 사용할 수 있는 Azure 서비스 및 Azure의 보안 모범 사례를 숙지합니다.

• Azure의 개발자 가이드에서는 Azure 시작 방법을 보여 줍니다. 이 가이드에서는 애플리케이션을 실행하고, 데이터를 저장하고, 인텔리전스를 통합하고, IoT 앱을 빌드하고, 솔루션을 보다 효율적이고 안전한 방식으로 배포하는 데 사용할 수 있는 서비스를 보여 줍니다.

• Azure 개발자 를 위한 시작 가이드는 개발 요구 사항에 맞게 Azure 플랫폼을 사용하기 시작하려는 개발자를 위한 필수 정보를 제공합니다.

• SDK 및 도구 는 Azure에서 사용할 수 있는 도구를 설명합니다.

• Azure DevOps Services에서는 개발 협업 도구를 제공합니다. 도구에는 고성능 파이프라인, 무료 Git 리포지토리, 구성 가능한 Kanban 보드, 광범위한 자동화 및 클라우드 기반 부하 테스트가 포함되어 있습니다. DevOps 리소스 센터는 DevOps 사례, Git 버전 제어, 민첩한 방법, Microsoft에서 DevOps로 작업하는 방법 및 고유한 DevOps 진행 상황을 평가하는 방법을 학습하기 위한 리소스를 결합합니다.

• 프로덕션으로 푸시하기 전에 고려해야 할 상위 5가지 보안 항목은 Azure에서 웹 애플리케이션을 보호하고 가장 일반적이고 위험한 웹 애플리케이션 공격으로부터 앱을 보호하는 방법을 보여줍니다.

• Azure 용 Secure DevOps Kit는 광범위한 자동화를 사용하는 DevOps 팀의 포괄적인 Azure 구독 및 리소스 보안 요구 사항을 충족하는 스크립트, 도구, 확장 및 자동화의 컬렉션입니다. Azure용 보안 DevOps 키트는 보안을 원시 DevOps 워크플로에 원활하게 통합하는 방법을 보여 줄 수 있습니다. 이 키트는 개발자가 코딩 및 초기 개발 단계에서 보안 코드를 작성하고 클라우드 애플리케이션의 보안 구성을 테스트하는 데 도움이 되는 SVT(보안 확인 테스트)와 같은 도구를 다룹니다.

• Azure 보안 모범 사례 및 패턴 - Azure를 사용하여 클라우드 솔루션을 디자인, 배포 및 관리할 때 사용할 보안 모범 사례 모음입니다. 지침은 IT 전문가를 위한 리소스입니다. 여기에는 보안 Azure 솔루션을 빌드하고 배포하는 디자이너, 설계자, 개발자 및 테스터가 포함될 수 있습니다.

요구 사항

요구 사항 정의 단계는 애플리케이션의 정의와 애플리케이션이 릴리스될 때 수행하는 작업을 정의하는 중요한 단계입니다. 요구 사항 단계는 애플리케이션에 빌드하는 보안 제어에 대해 생각해 볼 때이기도 합니다. 이 단계에서는 보안 애플리케이션을 릴리스하고 배포할 수 있도록 SDL 전체에서 수행하는 단계도 시작합니다.

보안 및 개인 정보 보호 문제 고려

이 단계는 기본 보안 및 개인 정보 보호 문제를 고려하기에 가장 좋은 시기입니다. 프로젝트를 시작할 때 허용되는 수준의 보안 및 개인 정보를 정의하면 팀이 다음을 수행할 수 있습니다.

• 보안 문제와 관련된 위험을 이해합니다.
• 개발 중에 보안 버그를 식별하고 수정합니다.
• 전체 프로젝트에서 설정된 수준의 보안 및 개인 정보를 적용합니다.

애플리케이션의 요구 사항을 작성할 때 애플리케이션과 데이터를 안전하게 유지하는 데 도움이 되는 보안 제어를 고려해야 합니다.

보안 질문하기

다음과 같은 본인 확인 질문을 합니다.

• 애플리케이션에 중요한 데이터가 포함되어 있나요?

• 내 애플리케이션은 FFIEC(연방 금융 기관 심사 위원회) 또는 PCI DSS(결제 카드 산업 데이터 보안 표준)와 같은 업계 표준 및 규정 준수 프로그램을 준수해야 하는 데이터를 수집하거나 저장하나요?

• 내 애플리케이션은 개인 또는 고객 데이터를 자체적으로 또는 다른 정보와 함께 사용하여 한 사람을 식별, 연락 또는 찾는 데 사용할 수 있는 중요한 개인 또는 고객 데이터를 수집하거나 포함하나요?

• 내 애플리케이션에서 개인의 의료, 교육, 금융 또는 고용 정보에 액세스하는 데 사용할 수 있는 데이터를 수집하거나 포함하나요? 요구 사항 단계에서 데이터의 민감도를 식별하면 데이터를 분류하고 애플리케이션에 사용하는 데이터 보호 방법을 식별하는 데 도움이 됩니다.

• 내 데이터는 어디에 어떻게 저장되는가? 애플리케이션에서 예기치 않은 변경(예: 느린 응답 시간)에 사용하는 스토리지 서비스를 모니터링하는 방법을 고려합니다. 로깅에 영향을 미하여 더 자세한 데이터를 수집하고 문제를 심층 분석할 수 있나요?

• 내 애플리케이션을 공용(인터넷)에서 사용할 수 있나요? 아니면 내부적으로만 사용할 수 있나요? 애플리케이션을 공용으로 사용할 수 있는 경우 수집될 수 있는 데이터가 잘못된 방식으로 사용되지 않도록 보호하려면 어떻게 해야 할까요? 애플리케이션을 내부적으로만 사용할 수 있는 경우 조직에서 애플리케이션에 액세스할 수 있어야 하는 사용자와 액세스 권한이 있어야 하는 기간을 고려합니다.

• 애플리케이션 디자인을 시작하기 전에 ID 모델을 이해하시겠습니까? 사용자가 자신이 누구인지, 사용자에게 어떤 권한이 부여되었는지 확인할 수 있나요?

• 내 애플리케이션이 민감하거나 중요한 작업(예: 자금 이체, 문 잠금 해제 또는 약품 배달)을 수행하나요? 중요한 작업을 수행하는 사용자에게 작업을 수행할 권한이 있는지와 사용자가 자신이 말하는 사람이 누구인지 인증하는 방법을 확인하는 방법을 고려합니다. AuthZ(권한 부여)란 인증된 보안 주체에게 작업을 수행할 수 있게 사용 권한을 부여하는 작업입니다. 인증(AuthN)은 합법적인 자격 증명에 대해 당사자에게 이의를 제기하는 행위입니다.

• 내 애플리케이션은 사용자가 파일 또는 기타 데이터를 업로드하거나 다운로드할 수 있도록 허용하는 것과 같은 위험한 소프트웨어 활동을 수행하나요? 애플리케이션이 위험한 작업을 수행하는 경우 애플리케이션이 악의적인 파일 또는 데이터를 처리하지 못하도록 사용자를 보호하는 방법을 고려합니다.

OWASP 상위 10개 검토

OWASP 상위 10개 애플리케이션 보안 위험을 검토 하는 것이 좋습니다. OWASP 상위 10은 웹 애플리케이션에 대한 민감한 보안 위험을 해결합니다. 이러한 보안 위험을 인식하면 애플리케이션에서 이러한 위험을 최소화하는 요구 사항 및 설계 결정을 내리는 데 도움이 될 수 있습니다.

보안 제어를 사용하여 위반을 방지하는 것이 중요합니다. 그러나 위반이 발생된다고 가정하려고 합니다. 위반을 간주하면 보안에 관한 몇 가지 중요한 질문에 미리 답변할 수 있기 때문에, 긴급 상황에서 답변을 받을 필요가 없습니다.

• 공격을 검색하려면 어떻게 해야 하나요?
• 공격이나 위반이 있는 경우 어떻게 해야 하나요?
• 데이터 유출 또는 변조와 같은 공격으로부터 어떻게 복구할 수 있나요?

디자인

디자인 단계는 디자인 및 기능 사양에 대한 모범 사례를 설정하는 데 중요합니다. 프로젝트 전체에서 보안 및 개인 정보 이슈를 완화하는 데 도움이 되는 위험 분석을 수행하는 데도 중요합니다.

보안 요구 사항이 있고 보안 디자인 개념을 사용하는 경우 보안 결함에 대한 기회를 방지하거나 최소화할 수 있습니다. 보안 결함은 애플리케이션이 릴리스된 후 사용자가 악의적이거나 예기치 않은 작업을 수행할 수 있도록 하는 애플리케이션 디자인의 감독입니다.

디자인 단계에서는 계층에서 보안을 적용하는 방법도 고려해야 합니다. 한 수준의 방어만으로는 충분하지 않습니다. 공격자가 WAF(웹 애플리케이션 방화벽)를 지나면 어떻게 되나요? 다른 보안 제어를 통해 해당 공격을 방어하려고 합니다.

이 점을 염두에 두고 보안 애플리케이션을 디자인할 때 해결해야 하는 보안 컨트롤과 다음과 같은 보안 디자인 개념에 대해 설명합니다.

• 보안 코딩 라이브러리 및 소프트웨어 프레임워크를 사용합니다.
• 취약한 구성 요소를 검색합니다.
• 애플리케이션 디자인 중에 위협 모델링을 사용합니다.
• 공격 노출 영역을 줄입니다.
• ID 정책을 기본 보안 경계로 채택합니다.
• 중요한 트랜잭션에 대한 재인증이 필요합니다.
• 키 관리 솔루션을 사용하여 키, 자격 증명 및 기타 비밀을 보호합니다.
• 중요한 데이터를 보호합니다.
• 유사시 대기 조치를 구현합니다.
• 오류와 예외 처리를 활용합니다.
• 로깅 및 경고를 사용합니다.

보안 코딩 라이브러리 및 소프트웨어 프레임워크 사용

개발의 경우 보안 코딩 라이브러리와 보안이 포함된 소프트웨어 프레임워크를 사용합니다. 개발자는 보안 컨트롤을 처음부터 개발하는 대신 기존의 검증된 기능(암호화, 입력 삭제, 출력 인코딩, 키 또는 연결 문자열 및 보안 제어로 간주되는 기타 모든 기능)을 사용할 수 있습니다. 그러면 보안 관련 디자인 및 구현 결함을 방지할 수 있습니다.

프레임워크의 최신 버전과 프레임워크에서 사용할 수 있는 모든 보안 기능을 사용하고 있는지 확인합니다. Microsoft는 클라우드 애플리케이션을 제공하기 위해 모든 플랫폼 또는 언어로 작업하는 모든 개발자를 위한 포괄적인 개발 도구 집합을 제공합니다. 다양한 SDK 중에서 선택하여 선택한 언어로 코딩할 수 있습니다. 고급 디버깅 기능과 기본 제공 Azure 지원 있는 완전한 기능을 갖춘 IDE(통합 개발 환경) 및 편집기를 활용할 수 있습니다.

Microsoft는 Azure에서 애플리케이션을 개발하는 데 사용할 수 있는 다양한 언어, 프레임워크 및 도구를 제공합니다. 예를 들어, .NET 및 .NET Core 개발자용 Azure입니다. 제공하는 각 언어 및 프레임워크에 대해 빠른 시작, 자습서 및 API 참조를 찾아 빠르게 시작하는 데 도움이 됩니다.

Azure는 웹 사이트 및 웹 애플리케이션을 호스트하는 데 사용할 수 있는 다양한 서비스를 제공합니다. 이 서비스를 사용하면 .NET, .NET Core, Java, Ruby, Node.js, PHP 또는 Python과 같은 원하는 언어로 개발할 수 있습니다. Web Apps(Azure App Service Web Apps)는 해당 서비스 중 하나입니다.

Web Apps는 애플리케이션에 Microsoft Azure의 기능을 추가합니다. 여기에는 보안, 부하 분산, 자동 크기 조정 및 자동화된 관리가 포함됩니다. 패키지 관리, 스테이징 환경, 사용자 지정 작업기본, SSL/TLS 인증서, Azure DevOps, GitHub, Docker Hub 및 기타 원본의 지속적인 배포와 같은 Web Apps의 DevOps 기능을 활용할 수도 있습니다.

Azure에서 웹 사이트와 웹 애플리케이션을 호스팅하는 데 사용할 수 있는 기타 서비스를 제공합니다. 대부분의 시나리오에서 Web Apps가 가장 적합한 선택입니다. 마이크로 서비스 아키텍처의 경우 Azure Service Fabric을 고려합니다. 코드가 실행되는 VM을 더 자세히 제어해야 하는 경우 Azure Virtual Machines를 고려 하세요. 이러한 Azure 서비스 중에서 선택하는 방법에 대한 자세한 내용은 Azure 앱 Service, Virtual Machines, Service Fabric 및 Cloud Services 비교를 참조하세요.

구성 요소에 업데이트 적용

취약성을 방지하려면 클라이언트 쪽 및 서버 쪽 구성 요소(예: 프레임워크 및 라이브러리)와 업데이트에 대한 종속성을 지속적으로 인벤토리에 포함해야 합니다. 새로운 취약성 및 업데이트된 소프트웨어 버전이 지속적으로 릴리스됩니다. 사용하는 라이브러리 및 구성 요소에 업데이트 또는 구성 변경 내용을 모니터링, 심사 및 적용하기 위한 지속적인 계획이 있는지 확인합니다.

도구 제안에 대해 알려진 취약성이 있는 구성 요소를 사용하는 방법은 OWASP(Open Web Application Security Project) 페이지를 참조하세요. 사용하는 구성 요소와 관련된 보안 취약성에 대한 이메일 경고를 구독할 수도 있습니다.

애플리케이션 디자인 중에 위협 모델링 사용

위협 모델링은 비즈니스 및 애플리케이션에 대한 잠재적인 보안 위협을 식별한 다음 적절한 완화가 이루어지도록 하는 프로세스입니다. SDL은 잠재적인 문제를 해결하는 것이 비교적 쉽고 비용 효율적일 때 팀이 디자인 단계에서 위협 모델링에 참여하도록 지정합니다. 디자인 단계에서 위협 모델링을 사용하면 총 개발 비용을 크게 줄일 수 있습니다.

위협 모델링 프로세스를 용이하게 하기 위해 비보안 전문가를 염두에 두고 SDL 위협 모델링 도구를 설계했습니다. 이 도구를 사용하면 위협 모델을 만들고 분석하는 방법에 대한 명확한 지침을 제공하여 모든 개발자가 위협 모델링을 더 쉽게 수행할 수 있습니다.

애플리케이션 디자인을 모델링하고 STRIDE 위협 스푸핑, 변조, 거부, 정보 공개, 서비스 거부 및 권한 상승 등 모든 신뢰 경계에서 디자인 오류를 조기에 catch할 수 있는 효과적인 방법을 입증했습니다. 다음 표에서는 STRIDE 위협을 나열하고 Azure에서 제공하는 기능을 사용하는 몇 가지 완화 예를 제공합니다. 이러한 완화는 모든 상황에서 작동하지 않습니다.

위협	보안 속성	잠재적인 Azure 플랫폼 완화
스푸핑	인증	HTTPS 연결이 필요합니다.
변조	무결성	SSL/TLS 인증서의 유효성을 검사합니다. SSL/TLS를 사용하는 애플리케이션은 연결하는 엔터티의 X.509 인증서를 완전히 확인해야 합니다. Azure Key Vault 인증서를 사용하여 x509 인증서를 관리합니다.
부인	부인 방지	Azure 모니터링 및 진단 사용하도록 설정합니다.
정보 공개	기밀성	미사용 및 전송 중인 중요한 데이터를 암호화합니다.
서비스 거부	사용 가용성	성능 메트릭에서 서비스 거부 상황 가능성을 모니터링합니다. 연결 필터를 구현합니다. 애플리케이션 디자인 모범 사례와 결합된 Azure DDoS 보호는 DDoS 공격에 대한 방어를 제공합니다.
권한 상승	권한 부여	Microsoft Entra ID Privileged Identity Management를 사용합니다.

공격 노출 영역 줄이기

공격 노출 영역은 잠재적 취약성이 발생할 수 있는 위치의 총 합계입니다. 이 문서에서는 애플리케이션의 공격 표면에 초점을 맞춥니다. 공격으로부터 애플리케이션을 보호하는 데 중점을 두고 있습니다. 공격 노출 영역을 최소화하는 간단하고 빠른 방법은 애플리케이션에서 사용되지 않는 리소스와 코드를 제거하는 것입니다. 애플리케이션 크기가 작을수록 공격 노출 영역이 작아집니다. 예를 들어 다음을 제거합니다.

• 아직 릴리스되지 않은 기능의 코드.
• 디버깅 지원 코드입니다.
• 사용되지 않거나 사용되지 않는 네트워크 인터페이스 및 프로토콜입니다.
• 사용하지 않는 가상 머신 및 기타 리소스.

리소스의 정기적인 클린 수행하고 사용하지 않는 코드를 제거하는 것은 악의적인 행위자가 공격할 기회가 적도록 하는 좋은 방법입니다.

공격 노출 영역을 줄이는 더 구체적이고 심층적인 방법은 공격 노출 영역 분석을 완료하는 것입니다. 공격 표면 분석을 사용하면 보안 취약성을 검토하고 테스트해야 하는 시스템 부분을 매핑할 수 있습니다.

공격 표면 분석의 목적은 애플리케이션의 위험 영역을 이해하여 개발자와 보안 전문가가 애플리케이션의 공격에 열려 있는 부분을 인식하도록 하는 것입니다. 그런 다음 공격에 노출될 가능성을 최소화하는 방법을 찾고, 공격 노출 영역이 변경되는 시기와 방법을 추적하고, 위험 관점에서 의미하는 바를 추적할 수 있습니다.

공격 노출 영역 분석을 사용하면 다음을 식별할 수 있습니다.

• 보안 취약성을 검토하고 테스트하는 데 필요한 시스템 기능과 파트.
• 심층 방어 보호(방어해야 하는 시스템의 일부)가 필요한 코드의 위험 수준이 높은 영역입니다.
• 공격 표면을 변경하고 위협 평가를 새로 고쳐야 하는 경우

공격자가 잠재적인 약점 또는 취약성을 악용할 기회를 줄이려면 애플리케이션의 전체 공격 표면을 철저히 분석해야 합니다. 시스템 서비스에 대한 액세스를 사용하지 않게 설정하거나 제한하고, 최소 권한 원칙을 적용하며, 가능한 경우 항상 계층적 방어를 사용하는 것도 포함됩니다.

SDL의 확인 단계에서 공격 표면 검토를 수행하는 것에 대해 설명합니다.

참고 항목

위협 모델링과 공격 노출 영역 분석의 차이점은 무엇인가요? 위협 모델링은 애플리케이션에 대한 잠재적인 보안 위협을 식별한 다음, 적절한 위협 완화 조치가 있는지 확인하는 프로세스입니다. 공격 표면 분석은 공격에 열려 있는 코드의 위험 수준이 높은 영역을 식별합니다. 여기에는 위험이 높은 애플리케이션의 영역을 방어하는 방법을 찾고 애플리케이션을 배포하기 전에 해당 코드 영역을 검토하고 테스트하는 것이 포함됩니다.

기본 보안 경계로서의 ID 정책 채택

클라우드 애플리케이션을 디자인할 때 네트워크 중심 접근 방식에서 ID 중심 접근 방식으로 보안 경계의 초점을 확장하는 것이 중요합니다. 지금까지 기본 온-프레미스 보안 경계는 조직의 네트워크였습니다. 대부분의 온-프레미스 보안 디자인은 네트워크를 기본 보안 피벗으로 사용합니다. 클라우드 애플리케이션의 경우 ID를 기본 보안 경계로 간주하여 더 나은 서비스를 제공합니다.

웹 애플리케이션 개발에 대한 ID 중심 접근 방식을 개발하기 위해 수행할 수 있는 작업은 다음과 같습니다.

• 사용자에 대해 다단계 인증을 적용합니다.
• 강력한 인증 및 권한 부여 플랫폼을 사용합니다.
• 최소 권한 원칙을 적용합니다.
• JIT(Just-In-Time) 액세스를 구현합니다.

사용자에 대한 다단계 인증 적용

2단계 인증을 사용합니다. 2단계 인증은 인증의 사용자 이름과 암호 형식에 내재된 보안 약점을 방지할 수 있기 때문에 인증 및 권한 부여의 현재 표준입니다. Azure 관리 인터페이스(Azure Portal/원격 PowerShell) 및 고객 관련 서비스에 대한 액세스는 Microsoft Entra 다단계 인증을 사용하도록 설계 및 구성되어야 합니다.

강력한 인증 및 권한 부여 플랫폼을 사용합니다.

사용자 지정 코드 대신 플랫폼 제공 인증 및 권한 부여 메커니즘을 사용합니다. 사용자 지정 인증 코드 개발은 오류가 발생하기 쉽기 때문입니다. 상용 코드(예: Microsoft)는 보안을 위해 광범위하게 검토되는 경우가 많습니다. Microsoft Entra ID (Microsoft Entra ID)는 ID 및 액세스 관리를 위한 Azure 솔루션입니다. 이러한 Microsoft Entra 도구 및 서비스는 안전한 개발에 도움이 됩니다.

• Microsoft ID 플랫폼은 개발자가 사용자를 안전하게 로그인하는 앱을 빌드하는 데 사용하는 구성 요소 세트입니다. 이 플랫폼은 단일 테넌트 LOB(기간 업무) 앱을 빌드하는 개발자와 다중 테넌트 앱을 개발하려는 개발자를 지원합니다. 기본 로그인 외에도, Microsoft ID 플랫폼을 사용하여 빌드된 앱에서는 Microsoft API 및 사용자 지정 API를 호출할 수 있습니다. Microsoft ID 플랫폼은 OAuth 2.0 및 OpenID Connect 등의 산업 표준 프로토콜을 지원합니다.

• Azure AD B2C(Azure Active Directory B2C )는 고객이 애플리케이션을 사용할 때 자신의 프로필을 등록, 로그인 및 관리하는 방법을 사용자 지정하고 제어하는 데 사용하는 ID 관리 서비스입니다. 여기에는 iOS, Android 및 .NET용으로 개발된 애플리케이션이 포함됩니다. Azure AD B2C는 고객 ID를 보호하면서 이러한 작업을 사용하도록 설정합니다.

최소 권한 원칙 적용

최소 권한이라는 개념은 사용자에게 작업을 수행하는 데 필요한 정확한 수준의 액세스 및 제어를 제공하는 것을 의미합니다.

소프트웨어 개발자가 관리자 권한을 기본 해야 합니까? 관리자 도우미 개인용 컴퓨터의 관리 제어에 액세스해야 합니까? 소프트웨어에 대한 액세스 평가도 다르지 않습니다. Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 사용자에게 애플리케이션에서 다른 기능과 권한을 부여하는 경우 모든 사용자에게 모든 항목에 대한 액세스 권한을 부여하지는 않습니다. 각 역할에 필요한 항목에 대한 액세스를 제한하여 보안 이슈 발생 위험을 제한합니다.

애플리케이션이 액세스 패턴 전체에서 최소 권한을 적용하는지 확인합니다.

참고 항목

최소 권한 규칙은 소프트웨어 및 소프트웨어를 만드는 사용자에게 적용해야 합니다. 소프트웨어 개발자에게 너무 많은 액세스 권한이 부여되면 IT 보안에 큰 위험이 될 수 있습니다. 개발자에게 악의적인 의도가 있거나 너무 많은 액세스 권한이 부여되면 결과가 심각할 수 있습니다. 개발 수명 주기 동안 개발자에게 최소 권한 규칙을 적용하는 것이 좋습니다.

JIT(Just-In-Time) 액세스 구현

JIT(Just-In-Time) 액세스를 구현하여 권한의 노출 시간을 더욱 낮춥니다. Microsoft Entra Privileged Identity Management를 사용하여 다음을 수행합니다.

• 사용자에게 JIT만 필요한 권한을 부여합니다.
• 권한이 자동으로 해지된다는 확신을 가지고 짧은 기간 동안 역할을 할당합니다.

중요한 트랜잭션에 대한 재인증 필요

사이트 간 요청 위조(XSRF 또는 CSRF라고도 함)는 악의적인 웹앱이 클라이언트 브라우저와 해당 브라우저를 신뢰하는 웹앱 간의 상호 작용에 영향을 주는 웹 호스팅 앱에 대한 공격입니다. 웹 브라우저는 웹 사이트에 대한 모든 요청과 함께 일부 형식의 인증 토큰을 자동으로 보내기 때문에 교차 사이트 요청 위조 공격이 가능합니다. 이러한 형태의 악용은 공격이 사용자의 이전에 인증된 세션을 활용하기 때문에 원클릭 공격 또는 세션 타기 라고도 합니다.

이러한 종류의 공격을 방어하는 가장 좋은 방법은 구매, 계정 비활성화 또는 암호 변경과 같은 모든 중요한 트랜잭션 전에 사용자만 제공할 수 있는 항목을 사용자에게 요청하는 것입니다. 사용자에게 암호를 다시 입력하거나 Captcha를 완료하거나 사용자에게만 있는 비밀 토큰을 제출하도록 요청할 수 있습니다. 가장 일반적인 방법은 비밀 토큰입니다.

키 관리 솔루션을 사용하여 키, 자격 증명 및 기타 비밀 보호

키와 자격 증명을 잃는 것은 일반적인 문제입니다. 키와 자격 증명을 잃는 것보다 더 나쁜 것은 권한이 없는 당사자가 액세스 권한을 얻는 것입니다. 공격자는 자동화된 수동 기술을 활용하여 GitHub와 같은 코드 리포지토리에 저장된 키와 비밀을 찾을 수 있습니다. 이러한 공용 코드 리포지토리 또는 다른 서버에 키와 비밀을 배치하지 마세요.

항상 키 관리 솔루션에 키, 인증서, 비밀, 연결 문자열을 둡니다. 키와 비밀이 HSM(하드웨어 보안 모듈)에 저장되는 중앙 집중식 솔루션을 사용할 수 있습니다. Azure는 Azure Key Vault를 사용하여 클라우드에서 HSM을 제공합니다.

Key Vault는 비밀 저장소입니다. 애플리케이션 비밀을 저장하기 위한 중앙 집중식 클라우드 서비스입니다. Key Vault는 애플리케이션 비밀을 단일 중앙 위치에 유지하고 보안 액세스, 권한 제어 및 액세스 로깅을 제공하여 기밀 데이터를 안전하게 유지합니다.

비밀은 개별 자격 증명 모음에 저장됩니다. 각 자격 증명 모음에는 액세스를 제어하기 위한 자체 구성 및 보안 정책이 있습니다. REST API 또는 대부분의 프로그래밍 언어에 사용할 수 있는 클라이언트 SDK를 통해 데이터에 액세스합니다.

Important

Azure Key Vault는 서버 애플리케이션에 대한 구성 비밀을 저장하도록 디자인되었습니다. 앱 사용자에 속하는 데이터를 저장하기 위한 것이 아닙니다. 이는 성능 특성, API 및 비용 모델에 반영됩니다.

사용자 데이터는 TDE(투명한 데이터 암호화)가 있는 Azure SQL Database 인스턴스 또는 Azure Storage 서비스 암호화를 사용하는 스토리지 계정과 같은 다른 곳에 저장해야 합니다. 애플리케이션에서 이러한 데이터 저장소에 액세스하는 데 사용하는 비밀은 Azure Key Vault에 보관할 수 있습니다.

중요한 데이터와

데이터 보호는 보안 전략의 필수적인 부분입니다. 데이터를 분류하고 데이터 보호 요구 사항을 식별하면 데이터 보안을 염두에 두고 앱을 디자인하는 데 도움이 됩니다. 민감도 및 비즈니스 영향별로 저장된 데이터를 분류(분류)하면 개발자가 데이터와 관련된 위험을 결정할 수 있습니다.

데이터 형식을 디자인할 때 적용 가능한 모든 데이터에 중요한 레이블을 지정합니다. 애플리케이션에서 해당 데이터를 중요한 것으로 처리하는지 확인합니다. 이러한 방법은 중요한 데이터를 보호하는 데 도움이 될 수 있습니다.

• 암호화를 사용합니다.
• 키 및 암호와 같은 비밀을 하드 코딩하지 마세요.
• 액세스 제어 및 감사가 준비되어 있는지 확인합니다.

암호화 사용

데이터 보호는 보안 전략의 필수적인 부분입니다. 데이터가 데이터베이스에 저장되어 있거나 위치 간에 이동하는 경우 미사용 데이터 암호화(데이터베이스에 있는 동안)와 전송 중인 데이터 암호화(사용자, 데이터베이스, API 또는 서비스 엔드포인트를 오가는 중)를 사용합니다. 항상 SSL/TLS 프로토콜을 사용하여 데이터를 교환하는 것이 좋습니다. 암호화에 최신 버전의 TLS를 사용하는지 확인합니다(현재 버전 1.2).

하드 코딩 방지

소프트웨어에서 하드 코딩해서는 안 되는 몇 가지 사항이 있습니다. 호스트 이름 또는 IP 주소, URL, 전자 메일 주소, 사용자 이름, 암호, 스토리지 계정 키 및 기타 암호화 키를 예로 들 수 있습니다. 코드의 주석 섹션을 포함하여 코드에서 하드 코딩할 수 있거나 하드 코딩할 수 없는 사항에 대한 요구 사항을 구현하는 것이 좋습니다.

코드에 주석을 넣을 때 중요한 정보를 저장하지 않도록 합니다. 해당 정보에는 메일 주소, 암호, 연결 문자열, 조직의 누군가만 알 수 있는 애플리케이션에 관한 정보, 공격자가 애플리케이션이나 조직을 공격할 때 이점을 줄 수 있는 기타 모든 정보가 포함됩니다.

기본적으로 개발 프로젝트의 모든 항목이 배포될 때 공용 지식이라고 가정합니다. 프로젝트에 어떤 종류의 중요한 데이터도 포함하지 마세요.

앞서 Azure Key Vault에 관해 설명했습니다. Key Vault를 사용하여 하드 코딩하는 대신 키 및 암호와 같은 비밀을 저장할 수 있습니다. Azure 리소스에 대한 관리 ID와 함께 Key Vault를 사용하는 경우 Azure 웹앱은 소스 제어 또는 구성에 비밀을 저장하지 않고도 비밀 구성 값에 쉽고 안전하게 액세스할 수 있습니다. 자세한 내용은 Azure Key Vault를 사용하여 서버 앱의 비밀 관리를 참조하세요.

장애로부터 안전한 측정값 구현

애플리케이션은 실행 중에 발생하는 오류를 일관된 방식으로 처리할 수 있어야 합니다. 애플리케이션은 모든 오류를 catch해야 하며 안전하거나 닫혀 실패합니다.

또한 의심스럽거나 악의적인 작업을 식별할 수 있는 충분한 사용자 컨텍스트로 오류를 로그해야 합니다. 지연된 포렌식 분석을 허용하려면 로그를 충분한 시간 동안 보존해야 합니다. 로그는 로그 관리 솔루션에서 쉽게 사용할 수 있는 형식이어야 합니다. 보안과 관련된 오류에 대한 경고가 트리거되는지 확인합니다. 로깅 및 모니터링이 부족하여 공격자가 시스템을 추가로 공격하고 지속성을 기본 수 있습니다.

오류 및 예외 처리 활용

올바른 오류 및 예외 처리를 구현하는 것은 방어 코딩의 중요한 부분입니다. 시스템을 안정적이고 안전하게 만들려면 오류와 예외를 처리하는 것이 중요합니다. 오류 처리에 실수하면 공격자에게 정보를 유출하고 공격자가 플랫폼과 디자인에 관해 더 자세히 이해하는 데 도움이 되는 등 다양한 종류의 보안 취약성을 초래할 수 있습니다.

다음 사항을 확인합니다.

• 코드에서 중복된 try/catch 블록을 방지하기 위해 중앙 집중식 방식으로 예외를 처리합니다.

• 모든 예기치 않은 동작은 애플리케이션 내에서 처리됩니다.

• 사용자에게 표시되는 메시지는 중요한 데이터를 누출하지 않지만 문제를 설명하기에 충분한 정보를 제공합니다.

• 예외를 로그하고 법정 또는 인시던트 대응 팀이 조사하는 데 충분한 정보를 제공합니다.

Azure Logic Apps는 종속 시스템으로 인한 오류 및 예외를 처리하기 위한 일류 환경을 제공합니다. Logic Apps를 사용하여 기업 및 조직에서 앱, 데이터, 시스템 및 서비스를 통합하기 위해 작업과 프로세스를 자동화하는 워크플로를 만들 수 있습니다.

로깅 및 경고 사용

보안 조사를 위해 보안 문제를 기록하고 문제에 대한 경고를 트리거하여 사람들이 문제에 대해 적시에 알 수 있도록 합니다. 모든 구성 요소에 대한 감사 및 로깅을 사용하도록 설정합니다. 감사 로그는 사용자 컨텍스트를 캡처하고 모든 중요한 이벤트를 식별해야 합니다.

사용자가 사이트에 제출하는 중요한 데이터를 기록하지 않는지 확인합니다. 중요한 데이터의 예는 다음과 같습니다.

• 사용자 자격 증명
• 주민등록번호 또는 기타 식별 정보
• 신용 카드 번호 또는 기타 재무 정보
• 상태 정보
• 암호화된 정보의 암호를 해독하는 데 사용할 수 있는 개인 키 또는 기타 데이터
• 애플리케이션을 보다 효과적으로 공격하는 데 용할 수 있는 시스템 또는 애플리케이션 정보

애플리케이션이 성공 및 실패한 사용자 로그인, 암호 재설정, 암호 변경, 계정 잠금 및 사용자 등록과 같은 사용자 관리 이벤트를 모니터링하는지 확인합니다. 이러한 이벤트에 대한 로깅은 잠재적으로 의심스러운 동작을 감지하고 대응하는 데 도움이 됩니다. 애플리케이션에 액세스하는 사용자와 같은 운영 데이터도 수집할 수 있습니다.

다음 단계

다음 문서에서는 보안 애플리케이션을 개발하고 배포하는 데 도움이 되는 보안 제어 및 활동을 권장합니다.

• 보안 애플리케이션 개발
• 보안 애플리케이션 배포