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

이 문서에서는 클라우드용 애플리케이션을 디자인할 때 고려해야 할 보안 및 제어 작업에 관해 설명합니다. Microsoft SDL(Security Development Lifecycle)의 요구 사항 및 디자인 단계에서 고려해야 할 보안 질문 및 개념과 함께 학습 리소스를 다룹니다. 더 안전한 애플리케이션을 디자인하는 데 사용할 수 있는 작업과 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용 보안 DevOps 키트는 광범위한 자동화를 사용하는 DevOps 팀의 포괄적인 Azure 구독 및 리소스 보안 요구 사항을 충족시키는 스크립트, 도구, 확장, 자동화 컬렉션입니다. Azure용 보안 DevOps 키트는 보안을 원시 DevOps 워크플로에 원활하게 통합하는 방법을 보여 줄 수 있습니다. 이 키트는 개발자가 코딩 및 초기 개발 스테이지에서 보안 코드를 작성하고 클라우드 애플리케이션의 보안 구성을 테스트하는 데 도움이 되는 SVT(보안 확인 테스트)와 같은 도구를 다룹니다.

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

요구 사항

요구 사항 정의 단계는 애플리케이션을 정의하고 애플리케이션이 릴리스되면 수행할 작업을 정의하는 데 중요한 단계입니다. 요구 사항 단계에서는 애플리케이션에 빌드할 보안 제어에 관해서도 고려합니다. 이 단계에서는 보안 애플리케이션을 릴리스하고 배포하기 위해 SDL 전체에서 수행할 단계도 시작합니다.

보안 및 개인 정보 이슈 고려

이 단계는 기본적인 보안 및 개인 정보 이슈를 고려하는 데 가장 적합한 시간입니다. 팀이 프로젝트 시작 시 허용 가능한 수준의 보안 및 개인 정보를 정의하면 다음과 같은 이점이 있습니다.

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

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

본인 확인 질문

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

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

• 내 애플리케이션에서 FFIEC(Federal Financial Institution Examination Council) 또는 PCI DSS(Payment Card Industry Data Security Standards)와 같은 업계 표준 및 규정 준수 프로그램을 준수해야 하는 데이터를 수집하거나 저장하나요?

• 내 애플리케이션에서 한 사람을 식별하거나 연락하거나 찾기 위해 단독으로 사용하거나 다른 정보와 함께 사용할 수 있는 중요한 개인 또는 고객 데이터를 수집하거나 포함하나요?

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

• 내 데이터는 어디에 어떻게 저장되나요? 애플리케이션이 사용하는 스토리지 서비스를 모니터링하여 응답 속도 저하 등의 예기치 않은 변경 내용을 파악하는 방법을 고려합니다. 로깅에 영향을 주어 더 자세한 데이터를 수집하고 문제를 심층적으로 분석할 수 있나요?

• 내 애플리케이션은 공개적으로(인터넷에서) 사용할 수 있나요? 아니면 내부적으로만 사용할 수 있나요? 애플리케이션을 공용으로 사용할 수 있으면 수집할 수 있는 데이터를 잘못된 방식으로 사용하지 않도록 어떻게 보호하나요? 애플리케이션을 내부적으로만 사용할 수 있으면 조직에서 애플리케이션에 액세스할 수 있는 사람과 액세스할 수 있는 기간을 고려합니다.

• 애플리케이션 디자인을 시작하기 전에 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 App Service, Virtual Machines, Service Fabric 및 Cloud Services 비교를 참조하세요.

구성 요소에 업데이트 적용

취약성을 방지하려면 클라이언트 측 및 서버 측 구성 요소(예: 프레임워크와 라이브러리)와 업데이트에 대한 종속성을 지속해서 인벤토리에 저장해야 합니다. 새로운 취약점과 업데이트된 소프트웨어 버전이 지속해서 릴리스됩니다. 사용하는 라이브러리와 구성 요소에 대한 업데이트나 구성 변경 사항을 모니터링하고 심사하며 적용할 지속적인 플랜이 있는지 확인합니다.

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

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

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

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

애플리케이션 디자인을 모델링하고 모든 신뢰 경계에 걸쳐 STRIDE 위협(스푸핑, 변조, 부인, 정보 공개, 서비스 거부 및 권한 상승)을 열거하면 디자인 오류를 조기에 발견하는 효과적인 방법으로 입증되었습니다. 다음 테이블에는 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 Service Encryption을 사용하는 스토리지 계정과 같은 다른 위치에 저장해야 합니다. 해당 데이터 저장소에 액세스하기 위해 애플리케이션에서 사용하는 비밀은 Azure Key Vault에서 유지할 수 있습니다.

중요한 데이터와

데이터 보호는 보안 전략의 필수 부분입니다. 데이터를 분류하고 데이터 보호 요구 사항을 식별하면 데이터 보안을 염두에 두고 앱을 디자인할 수 있습니다. 저장된 데이터를 민감도와 비즈니스에 미치는 영향에 따라 분류(범주화)하면 개발자가 데이터와 연결된 위험을 파악할 수 있습니다.

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

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

암호화 사용

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

하드 코딩 방지

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

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

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

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

유사시 대기 조치 구현

애플리케이션은 실행 중에 발생하는 오류를 일관된 방식으로 처리할 수 있어야 합니다. 애플리케이션은 모든 오류를 포착하고 유사시 조치를 수행하거나 닫습니다.

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

오류와 예외 처리를 활용합니다.

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

다음 사항을 확인합니다.

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

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

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

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

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

로깅과 경고 사용

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

사용자가 사이트에 제출하는 민감한 데이터를 로그하지 않도록 합니다. 중요한 데이터의 예는 다음과 같습니다.

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

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

다음 단계

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

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