Azure의 중요 업무용 워크로드에 대한 보안 고려 사항

  • 아티클

보안은 기본 디자인 원칙 중 하나이며 중요 업무용 아키텍처 프로세스 내에서 일류 관심사로 취급되어야 하는 주요 디자인 영역이기도 합니다.

중요 업무용 디자인의 주요 초점은 애플리케이션이 성능 및 사용 가능한 상태를 유지하도록 안정성을 극대화하는 것입니다. 이 디자인 영역 내에 적용된 보안 고려 사항 및 권장 사항은 가용성에 영향을 미치고 전반적인 안정성을 저해할 수 있는 용량으로 위협을 완화하는 데 중점을 둡니다. 예를 들어 성공적인 DDoS(서비스 거부) 공격은 가용성 및 성능에 치명적인 영향을 미치는 것으로 알려져 있습니다. 애플리케이션이 SlowLoris와 같은 이러한 공격 벡터를 완화하는 방법은 전반적인 안정성에 영향을 줍니다. 따라서 애플리케이션은 애플리케이션 안정성을 직간접적으로 손상시키기 위한 위협으로부터 완전히 보호되어야 본질적으로 매우 중요합니다.

또한 특히 성능, 운영 민첩성 및 경우에 따라 안정성과 관련하여 강화된 보안 상태와 관련된 상당한 절판이 있는 경우가 많습니다. 예를 들어 심층 패킷 검사와 같은 NGFW(차세대 방화벽) 기능에 대한 인라인 NVA(네트워크 가상 어플라이언스)를 포함하면 확장성 및 복구 작업이 애플리케이션의 성능과 밀접하게 일치하지 않는 경우 상당한 성능 저하, 추가 운영 복잡성 및 안정성 위험이 발생합니다. 따라서 주요 위협 벡터를 완화하기 위한 추가 보안 구성 요소 및 사례도 애플리케이션의 안정성 목표를 지원하도록 설계되어 이 섹션에 제시된 권장 사항 및 고려 사항의 주요 측면을 형성해야 합니다.

중요

이 문서는 Azure Well-Architected 중요 업무용 워크로드 시리즈의 일부입니다. 이 시리즈에 익숙하지 않은 경우 중요 업무용 워크로드란?으로 시작하는 것이 좋습니다.

GitHub 로고중요 업무용 오픈 소스 프로젝트

참조 구현은 GitHub에서 사용할 수 있는 오픈 소스 프로젝트의 일부입니다. 코드 자산은 제로 트러스트 모델을 채택하여 보안 디자인 및 구현 접근 방식을 구조화하고 안내합니다.

제로 트러스트 모델과의 맞춤

Microsoft 제로 트러스트 모델은 애플리케이션의 모든 계층에 보안을 적용하는 사전 예방적이고 통합된 접근 방식을 제공합니다. 제로 트러스트 지침 원칙은 모든 트랜잭션을 명시적이고 지속적으로 확인하고, 최소 권한을 어설션하고, 인텔리전스 및 고급 검색을 사용하여 거의 실시간으로 위협에 대응하기 위해 노력합니다. 궁극적으로 애플리케이션 경계 내부 및 외부의 신뢰를 제거하고 시스템에 연결하려는 모든 항목에 대한 확인을 적용하는 데 중점을 두고 있습니다.

디자인 고려 사항

애플리케이션의 보안 상태를 평가할 때 각 고려 사항에 대한 기준으로 이러한 질문으로 시작합니다.

  • 주요 보안 취약성에 대한 완화의 유효성을 검사하기 위한 지속적인 보안 테스트입니다.

    • 보안 테스트는 자동화된 CI/CD 프로세스의 일부로 수행되는가?
    • 그렇지 않은 경우 특정 보안 테스트가 수행되는 빈도는 얼마나 입니까?
    • 테스트 결과가 원하는 보안 상태 및 위협 모델에 대해 측정되나요?

  • 모든 하위 환경의 보안 수준입니다.

    • 개발 수명 주기 내의 모든 환경에 프로덕션 환경과 동일한 보안 태세가 있나요?

  • 오류가 발생할 경우 인증 및 권한 부여 연속성.

    • 인증 또는 권한 부여 서비스를 일시적으로 사용할 수 없는 경우 애플리케이션이 계속 작동할 수 있나요?

  • 자동화된 보안 규정 준수 및 수정.

    • 주요 보안 설정에 대한 변경 내용을 검색할 수 있나요?
    • 비준수 변경 내용 수정에 대한 응답이 자동화되었나요?

  • 소스 코드 리포지토리를 통해 비밀 누출을 방지하기 위해 코드가 커밋되기 전에 비밀을 검색하는 비밀 검사입니다.

    • 코드의 일부로 자격 증명을 갖지 않고도 서비스에 대한 인증이 가능합니까?

  • 소프트웨어 공급망을 보호합니다.

    • 사용된 패키지 종속성 내에서 CVE(일반적인 취약성 및 노출)를 추적할 수 있나요?
    • 패키지 종속성을 업데이트하는 자동화된 프로세스가 있나요?

  • 데이터 보호 키 수명 주기.

    • 서비스 관리형 키를 데이터 무결성 보호에 사용할 수 있나요?
    • 고객 관리형 키가 필요한 경우 안전하고 신뢰할 수 있는 키 수명 주기는 어떻게 합니까?

  • CI/CD 도구에는 Azure 리소스 배포를 위해 고려된 모든 환경 구독에 대한 제어 평면 액세스를 용이하게 하기 위해 충분한 구독 수준 액세스 권한이 있는 Microsoft Entra 서비스 주체가 필요합니다.

    • 애플리케이션 리소스가 프라이빗 네트워크 내에서 잠겨 있는 경우 CI/CD 도구가 애플리케이션 수준 배포 및 유지 관리를 수행할 수 있도록 프라이빗 데이터 평면 연결 경로가 있습니다.
      • 이렇게 하면 복잡성이 더 늘어나고 필수 프라이빗 빌드 에이전트를 통해 배포 프로세스 내에서 시퀀스가 필요합니다.

디자인 권장 사항

  • Azure Policy 사용하여 모든 서비스에 대한 보안 및 안정성 구성을 적용하여 구성 시 컨트롤 플레인에서 편차를 수정하거나 금지하여 '악의적인 관리자' 시나리오와 관련된 위협을 완화하는 데 도움이 됩니다.

  • 프로덕션 구독 내에서 PIM(Microsoft Entra Privileged Identity Management)을 사용하여 프로덕션 환경에 대한 지속적인 제어 평면 액세스를 취소합니다. 이렇게 하면 추가 '검사 및 균형'을 통해 '악의적인 관리자' 시나리오에서 발생하는 위험을 크게 줄일 수 있습니다.

  • 애플리케이션 코드에서 자격 증명을 쉽게 제거하고 서비스 간 통신에 대한 ID 관리의 운영 부담을 제거하기 때문에 기능을 지원하는 모든 서비스에 Azure 관리 ID를 사용합니다.

  • 기능을 지원하는 모든 서비스에서 데이터 평면 권한 부여에 RBAC(Microsoft Entra 역할 기반 액세스 제어)를 사용합니다.

  • 애플리케이션 코드 내에서 자사 Microsoft ID 플랫폼 인증 라이브러리를 사용하여 Microsoft Entra ID 통합합니다.

  • 선택한 ID 플랫폼을 사용할 수 없거나 애플리케이션 권한 부여에 부분적으로만 사용할 수 있는 경우 성능이 저하되었지만 사용 가능한 환경을 허용하려면 보안 토큰 캐싱을 고려합니다.

    • 공급자가 새 액세스 토큰을 발급할 수 없지만 여전히 기존 토큰의 유효성을 검사하는 경우 애플리케이션 및 종속 서비스는 토큰이 만료될 때까지 문제 없이 작동할 수 있습니다.
    • 토큰 캐싱은 일반적으로 인증 라이브러리(예: MSAL)에 의해 자동으로 처리됩니다.

  • IaC(Infrastructure-as-Code) 및 자동화된 CI/CD 파이프라인을 사용하여 오류 상황을 포함한 모든 애플리케이션 구성 요소에 대한 업데이트를 구동합니다.

    • CI/CD 도구 서비스 연결이 중요한 중요한 정보로 보호되고 서비스 팀에서 직접 사용할 수 없어야 합니다.
    • 프로덕션 CD 파이프라인에 세분화된 RBAC를 적용하여 '악의적인 관리자' 위험을 완화합니다.
    • 프로덕션 배포 파이프라인 내에서 수동 승인 게이트를 사용하여 '악의적인 관리자' 위험을 더욱 완화하고 모든 프로덕션 변경에 대한 추가 기술 보증을 제공하는 것이 좋습니다.
      • 추가 보안 게이트는 민첩성 측면에서 절상될 수 있으며 수동 게이트에서도 민첩성을 유지할 수 있는 방법을 고려하여 신중하게 평가해야 합니다.

  • 모든 하위 환경에 대한 적절한 보안 태세를 정의하여 주요 취약성이 완화되도록 합니다.

    • 특히 데이터 반출과 관련하여 프로덕션과 동일한 보안 태세를 적용하지 마세요. 규제 요구 사항에서 개발자 민첩성을 크게 손상시킬 수 있으므로 이를 규정하지 않는 한.

  • 중요 업무용 워크로드에 대한 리소스를 포함하는 모든 구독에 대해 클라우드용 Microsoft Defender(이전의 Azure Security Center)을 사용하도록 설정합니다.

    • Azure Policy 사용하여 규정 준수를 적용합니다.
    • 기능을 지원하는 모든 서비스에 대해 Azure Defender를 사용하도록 설정합니다.

  • DevSecOps를 수용하고 CI/CD 파이프라인 내에서 보안 테스트를 구현합니다.

    • 테스트 결과는 자동화되거나 수동으로 릴리스 승인을 알리기 위해 규정 준수 보안 태세에 따라 측정되어야 합니다.
    • 각 릴리스에 대한 CD 프로덕션 프로세스의 일부로 보안 테스트를 적용합니다.
      • 각 릴리스의 보안 테스트가 운영 민첩성을 위태롭게 하는 경우 적절한 보안 테스트 주기가 적용되었는지 확인합니다.

  • 소스 코드 리포지토리 내에서 비밀 검사 및 종속성 검사를 사용하도록 설정합니다.

위협 모델링

위협 모델링은 식별된 잠재적 위협을 사용하여 적절한 보안 완화를 개발하는 보안 디자인에 대한 위험 기반 접근 방식을 제공합니다. 발생할 확률이 다양한 가능한 위협이 많으며, 대부분의 경우 위협은 예기치 않은, 예측할 수 없는, 심지어 혼란스러운 방식으로 연결됩니다. 이러한 복잡성과 불확실성 때문에 기존의 기술 요구 사항 기반 보안 접근 방식은 중요 업무용 클라우드 애플리케이션에 적합하지 않습니다. 중요 업무용 애플리케이션에 대한 위협 모델링 프로세스가 복잡하고 굴하지 않을 것으로 예상합니다.

이러한 문제를 해결하는 데 도움이 되도록 계층화된 심층 방어 접근 방식을 적용하여 다음과 같은 방어 계층을 고려하여 모델링된 위협에 대한 보정 완화를 정의하고 구현해야 합니다.

  1. 기본 보안 기능 및 컨트롤이 있는 Azure 플랫폼.
  2. 애플리케이션 아키텍처 및 보안 디자인.
  3. 보안 Azure 리소스에 기본 제공, 사용 및 배포 가능한 보안 기능이 적용되었습니다.
  4. 애플리케이션 코드 및 보안 논리.
  5. 운영 프로세스 및 DevSecOps.

참고

Azure 랜딩 존 내에서 배포하는 경우 중앙 집중식 보안 기능 프로비저닝을 통한 추가 위협 완화 계층은 랜딩 존 구현을 통해 제공됩니다.

디자인 고려 사항

STRIDE 는 주요 위협 벡터에서 보안 위협을 평가하기 위한 간단한 위험 프레임워크를 제공합니다.

  • 스푸핑된 ID: 권한이 있는 개인을 가장합니다. 예를 들어 공격자가 다음을 사용하여 다른 사용자를 가장합니다.
    • ID
    • 인증
  • 변조 입력: 애플리케이션에 전송된 입력 수정 또는 애플리케이션 코드를 수정하기 위한 신뢰 경계 위반. 예를 들어 공격자가 SQL 삽입을 사용하여 데이터베이스 테이블의 데이터를 삭제합니다.
    • 데이터 무결성
    • 유효성 검사
    • 차단 목록/허용 목록
  • 작업 거부: 이미 수행된 작업을 반박하는 기능 및 증거를 수집하고 책임을 추진하는 애플리케이션의 기능. 예를 들어 악의적인 관리자를 추적할 수 없는 중요한 데이터가 삭제됩니다.
    • 감사/로깅
    • 서명
  • 정보 공개: 제한된 정보에 대한 액세스 권한을 얻습니다. 예를 들어 공격자가 제한된 파일에 액세스하는 경우를 예로 들어 보겠습니다.
    • 암호화
    • 데이터 반출
    • 맨 인 더 미들 공격
  • 서비스 거부: 악의적인 애플리케이션 중단으로 인해 사용자 환경이 저하됩니다. 예를 들어 Slowloris와 같은 DDoS 봇넷 공격입니다.
    • DDoS
    • 봇네트
    • CDN 및 WAF 기능
  • 권한 상승: 권한 부여 익스플로잇을 통해 권한 있는 애플리케이션 액세스 얻기 예를 들어 공격자가 URL 문자열을 조작하여 중요한 정보에 액세스합니다.
    • 원격 코드 실행
    • 권한 부여
    • 격리

디자인 권장 사항

  • 각 스프린트 내에서 엔지니어링 예산을 할당하여 잠재적인 새로운 위협을 평가하고 완화를 구현합니다.

  • 모든 애플리케이션 서비스 팀에서 일관성을 유지하기 위해 일반적인 엔지니어링 기준 내에서 보안 완화를 캡처할 수 있도록 의식적인 노력을 적용해야 합니다.

  • 서비스 수준 위협 모델링별 서비스로 시작하고 애플리케이션 수준에서 스레드 모델을 통합하여 모델을 통합합니다.

네트워크 침입 보호

가용성을 유지하고 데이터 무결성을 보호하려면 중요 업무용 애플리케이션 및 포괄 데이터에 대한 무단 액세스를 방지하는 것이 중요합니다.

디자인 고려 사항

  • 제로 트러스트 위반된 상태를 가정하고 각 요청이 제어되지 않은 네트워크에서 시작된 것처럼 확인합니다.

    • 고급 제로 트러스트 네트워크 구현은 마이크로 세분화 및 분산 수신/송신 마이크로 경계를 사용합니다.

  • Azure PaaS 서비스는 일반적으로 퍼블릭 엔드포인트를 통해 액세스됩니다. Azure는 퍼블릭 엔드포인트를 보호하거나 완전히 비공개로 만드는 기능을 제공합니다.

    • Azure Private Link/프라이빗 엔드포인트는 개인 IP 주소 및 프라이빗 네트워크 연결을 사용하여 Azure PaaS 리소스에 대한 전용 액세스를 제공합니다.
    • Virtual Network 서비스 엔드포인트는 선택한 서브넷에서 선택한 PaaS 서비스에 대한 서비스 수준 액세스를 제공합니다.
    • Virtual Network 삽입은 App Service Environment 통한 App Service 같은 지원되는 서비스에 대한 전용 프라이빗 배포를 제공합니다.
      • 관리 평면 트래픽은 여전히 공용 IP 주소를 통해 이동합니다.

  • 지원되는 서비스의 경우 Azure 프라이빗 엔드포인트를 사용하는 Azure Private Link 악의적인 관리자가 외부 리소스에 데이터를 쓰는 등 서비스 엔드포인트와 관련된 데이터 반출 위험을 해결합니다.

  • 프라이빗 엔드포인트 또는 서비스 엔드포인트를 사용하여 Azure PaaS 서비스에 대한 네트워크 액세스를 제한하는 경우 애플리케이션을 배포하고 관리하기 위해 배포 파이프라인이 Azure 리소스의 Azure 컨트롤 플레인과 데이터 평면에 모두 액세스하려면 보안 네트워크 채널이 필요합니다.

    • Azure 리소스로 프라이빗 네트워크에 배포된 프라이빗 자체 호스팅 빌드 에이전트는 프라이빗 연결을 통해 CI/CD 함수를 실행하는 프록시로 사용할 수 있습니다. 빌드 에이전트에 별도의 가상 네트워크를 사용해야 합니다.
      • CI/CD 도구에서 프라이빗 빌드 에이전트에 연결해야 합니다.
    • 다른 방법은 파이프라인 내에서 즉시 리소스에 대한 방화벽 규칙을 수정하여 Azure DevOps 에이전트 공용 IP 주소에서 연결을 허용하고 작업이 완료된 후 방화벽이 제거되도록 하는 것입니다.
      • 그러나 이 방법은 Azure 서비스의 하위 집합에만 적용됩니다. 예를 들어 프라이빗 AKS 클러스터에서는 이 작업을 수행할 수 없습니다.
    • 애플리케이션 서비스 점프 상자에서 개발자 및 관리 작업을 수행하는 데 사용할 수 있습니다.

  • 관리 및 유지 관리 작업의 완료는 Azure 리소스의 데이터 평면에 대한 연결이 필요한 추가 시나리오입니다.

  • 해당 Microsoft Entra 서비스 주체가 있는 서비스 Connections Azure DevOps 내에서 사용하여 Microsoft Entra ID 통해 RBAC를 적용할 수 있습니다.

  • 서비스 태그를 네트워크 보안 그룹에 적용하여 Azure PaaS 서비스와의 연결을 용이하게 할 수 있습니다.

  • 애플리케이션 보안 그룹은 여러 가상 네트워크에 걸쳐 있지 않습니다.

  • Azure Network Watcher 패킷 캡처는 최대 5시간으로 제한됩니다.

디자인 권장 사항

  • 외부 공격 표면을 줄이기 위해 애플리케이션이 비즈니스 목적을 충족하는 데 필요한 절대 최소값으로 공용 네트워크 액세스를 제한합니다.

  • 프라이빗 빌드 에이전트를 처리할 때 인터넷에 직접 RDP 또는 SSH 포트를 열지 마세요.

    • Azure Bastion을 사용하여 Azure Virtual Machines 대한 보안 액세스를 제공하고 인터넷을 통해 Azure PaaS에서 관리 작업을 수행합니다.

  • DDoS 표준 보호 계획을 사용하여 애플리케이션 내의 모든 공용 IP 주소를 보호합니다.

  • 웹 애플리케이션 방화벽 정책과 함께 Azure Front Door를 사용하여 여러 Azure 지역에 걸쳐 있는 글로벌 HTTP/S 애플리케이션을 제공하고 보호합니다.

    • 헤더 ID 유효성 검사를 사용하여 Azure Front Door instance 발생한 트래픽만 허용하도록 공용 애플리케이션 엔드포인트를 잠급니다.

  • 심층 패킷 검사 또는 TLS 검사와 같은 추가 인라인 네트워크 보안 요구 사항이 있는 경우 Azure Firewall 프리미엄 또는 NVA(네트워크 가상 어플라이언스)를 사용해야 합니다. 최대 고가용성 및 중복성을 위해 구성되었는지 확인합니다.

  • 패킷 캡처 요구 사항이 있는 경우 제한된 캡처 창에도 불구하고 Network Watcher 패킷을 사용하여 캡처합니다.

  • 네트워크 보안 그룹 및 애플리케이션 보안 그룹을 사용하여 애플리케이션 트래픽을 마이크로 분할합니다.

    • 보안 어플라이언스 사용하여 애플리케이션 내 트래픽 흐름을 필터링하지 않습니다.
    • Azure Policy 사용하여 특정 NSG 규칙을 적용하는 것은 항상 애플리케이션 서브넷과 연결됩니다.

  • NSG 흐름 로그를 활성화하고 Traffic Analytics로 제공하여 내부 및 외부 트래픽 흐름에 대한 인사이트를 얻습니다.

  • 사용 가능한 경우 Azure Private Link/프라이빗 엔드포인트를 사용하여 애플리케이션 디자인 내에서 Azure PaaS 서비스에 대한 액세스를 보호합니다. Private Link를 지원하는 Azure 서비스에 대한 자세한 내용은 Azure Private Link 가용성을 참조하세요.

  • 프라이빗 엔드포인트를 사용할 수 없고 데이터 반출 위험이 허용되는 경우 Virtual Network 서비스 엔드포인트를 사용하여 가상 네트워크 내에서 Azure PaaS 서비스에 대한 액세스를 보호합니다.

    • 중요한 데이터 반출 채널이 도입되므로 모든 서브넷에서 기본적으로 가상 네트워크 서비스 엔드포인트를 사용하도록 설정하지 마세요.

  • 하이브리드 애플리케이션 시나리오의 경우 프라이빗 피어링을 사용하여 ExpressRoute를 통해 온-프레미스에서 Azure PaaS 서비스에 액세스합니다.

참고

Azure 랜딩 존 내에 배포할 때는 랜딩 존 구현을 통해 온-프레미스 데이터 센터에 대한 네트워크 연결이 제공된다는 점에 유의하세요. 한 가지 방법은 프라이빗 피어링으로 구성된 ExpressRoute를 사용하는 것입니다.

데이터 무결성 보호

암호화는 데이터 무결성을 보장하기 위한 중요한 단계이며 궁극적으로 광범위한 위협을 완화하기 위해 적용할 수 있는 가장 중요한 보안 기능 중 하나입니다. 따라서 이 섹션에서는 애플리케이션 안정성을 손상시키지 않고 데이터를 보호하기 위해 암호화 및 키 관리와 관련된 주요 고려 사항 및 권장 사항을 제공합니다.

디자인 고려 사항

  • Azure Key Vault 특정 기간 내에 자격 증명 모음당 제한이 적용된 키 및 비밀에 대한 트랜잭션 제한이 있습니다.

  • Azure Key Vault 키, 비밀 및 인증서에 대한 액세스 권한이 자격 증명 모음 수준에서 적용되므로 보안 경계를 제공합니다.

    • Key Vault 액세스 정책 할당은 키, 비밀 또는 인증서에 개별적으로 권한을 부여합니다.
      • 이제 특정 키, 비밀 또는 인증서에 대한 세분화된 개체 수준 권한을 사용할 수 있습니다.

  • 역할 할당이 변경된 후 역할을 적용할 최대 10분(600초)의 대기 시간이 있습니다.

    • 구독당 Azure 역할 할당은 2,000개로 제한됩니다.

  • Azure Key Vault 기본 HSM(하드웨어 보안 모듈)에는 FIPS 140 유효성 검사가 있습니다.

  • Azure Key Vault 가용성을 유지하고 데이터 손실을 방지하는 데 도움이 되는 고가용성 및 중복성을 제공합니다.

  • 지역 장애 조치(failover) 중에는 Key Vault 서비스가 장애 조치(failover)되는 데 몇 분 정도 걸릴 수 있습니다.

    • 장애 조치(failover) 중 Key Vault 읽기 전용 모드가 되므로 방화벽 구성 및 설정과 같은 키 자격 증명 모음 속성을 변경할 수 없습니다.

  • 프라이빗 링크를 사용하여 Azure Key Vault 연결하는 경우 지역 장애 조치(failover) 중에 연결을 다시 설정하는 데 최대 20분이 걸릴 수 있습니다.

  • 백업은 비밀, 키 또는 인증서의 특정 시점 스냅샷 Azure 외부에서 해독할 수 없는 암호화된 Blob으로 만듭니다. Blob에서 사용 가능한 데이터를 얻으려면 동일한 Azure 구독 및 Azure 지리 내에서 Key Vault 복원해야 합니다.

    • 백업 중에 비밀이 갱신되어 불일치가 발생할 수 있습니다.

  • 서비스 관리형 키를 사용하여 Azure는 회전과 같은 키 관리 기능을 수행하여 애플리케이션 작업의 scope 줄입니다.

  • 규정 제어는 서비스 암호화 기능에 고객 관리형 키를 사용하도록 규정할 수 있습니다.

  • 트래픽이 Azure 데이터 센터 간에 이동하면 기본 네트워크 하드웨어에서 MACsec 데이터 링크 계층 암호화를 사용하여 Microsoft에서 제어하지 않거나 Microsoft를 대신하여 제어되지 않는 물리적 경계 외부에서 전송 중인 데이터를 보호합니다.

디자인 권장 사항

  • 가능한 경우 데이터 보호를 위해 서비스 관리형 키를 사용하여 암호화 키를 관리하고 키 회전과 같은 운영 작업을 처리할 필요가 없습니다.

    • 명확한 규정 요구 사항이 있는 경우에만 고객 관리형 키를 사용합니다.

  • 추가 암호화 메커니즘 또는 고객 관리형 키를 고려해야 하는 경우 모든 비밀, 인증서 및 키에 대한 보안 리포지토리로 Azure Key Vault 사용합니다.

    • 삭제된 개체에 대한 보존 보호를 허용하도록 사용하도록 설정된 일시 삭제 및 제거 정책으로 Azure Key Vault를 프로비저닝합니다.
    • 애플리케이션 프로덕션 환경에 HSM 지원 Azure Key Vault SKU를 사용합니다.

  • 각 지역 배포 스탬프 내에 별도의 Azure Key Vault instance 배포하여 지역화를 통해 장애 격리 및 성능 이점을 제공하고 단일 Key Vault instance 적용되는 확장 제한을 탐색합니다.

    • 애플리케이션 전역 리소스에 전용 Azure Key Vault instance 사용합니다.

  • 권한 부여를 제한하여 비밀, 키 및 인증서를 특수한 사용자 지정 Microsoft Entra 역할로 영구적으로 삭제하도록 제한하여 최소 권한 모델을 따릅니다.

  • 암호화 키와 Key Vault 내에 저장된 인증서가 백업되어 가능성 없는 이벤트 Key Vault 오프라인 복사본을 사용할 수 없게 됩니다.

  • Key Vault 인증서를 사용하여 인증서 조달 및 서명을 관리합니다.

  • 키 및 인증서 교체를 위한 자동화된 프로세스를 설정합니다.

    • 공공 인증 기관과 함께 인증서 관리 및 갱신 프로세스를 자동화하여 관리를 용이하게 합니다.
      • 자동화된 인증서 갱신을 보완하기 위해 경고 및 알림을 설정합니다.

  • 키, 인증서 및 비밀 사용을 모니터링합니다.

정책 중심적 거버넌스

보안 규칙은 궁극적으로 모든 애플리케이션 서비스 및 팀에서 일관되고 전체적으로 적용되는 경우에만 효과적입니다. Azure Policy 중요 업무용 애플리케이션에 대한 일반적인 엔지니어링 기준을 지속적으로 준수하도록 보안 및 안정성 기준을 적용하는 프레임워크를 제공합니다. 보다 구체적으로 Azure Policy ARM(Azure Resource Manager) 컨트롤 플레인의 핵심 부분을 형성하고, 권한 있는 사용자가 수행할 수 있는 작업을 제한하여 RBAC를 보완하고, 활용 플랫폼 서비스에서 중요한 보안 및 안정성 규칙을 적용하는 데 사용할 수 있습니다.

따라서 이 섹션에서는 중요 업무용 애플리케이션에 대한 Azure Policy 기반 거버넌스 사용을 둘러싼 주요 고려 사항 및 권장 사항을 살펴보고 보안 및 안정성 규칙이 지속적으로 적용되도록 합니다.

디자인 고려 사항

  • Azure Policy 프라이빗 엔드포인트 사용 또는 가용성 영역 사용과 같은 보안 및 안정성 규칙을 적용하여 규정 준수를 촉진하는 메커니즘을 제공합니다.

참고

Azure 랜딩 존 내에서 배포하는 경우 중앙 집중식 기준 정책 할당의 적용이 랜딩 존 관리 그룹 및 구독에 대한 구현에 적용될 가능성이 높다는 점에 유의하세요.

  • Azure Policy 프로비저닝 및 구성과 같은 자동화된 관리 작업을 구동하는 데 사용할 수 있습니다.

    • 리소스 공급자 등록.
    • 개별 Azure 리소스 구성의 유효성 검사 및 승인

  • Azure Policy 할당 scope 적용 범위를 지정하고 Azure Policy 정의의 위치는 사용자 지정 정책의 재사용 가능성을 알려줍니다.

  • Azure Policy 특정 scope 정의 수와 같은 몇 가지 제한이 있습니다.

  • DINE(존재하지 않는 경우 배포) 정책을 실행하는 데 몇 분 정도 걸릴 수 있습니다.

  • Azure Policy 규정 준수 보고 및 보안 감사에 대한 중요한 입력을 제공합니다.

디자인 권장 사항

  • 규정 및 규정 준수 요구 사항을 Azure Policy 정의에 매핑합니다.

    • 예를 들어 데이터 상주 요구 사항이 있는 경우 사용 가능한 배포 지역을 제한하는 정책을 적용해야 합니다.

  • 이 조건이 Azure Policy 할당에 매핑되어 규정 준수를 적용하도록 모든 Azure 서비스에 대해 안전하고 신뢰할 수 있는 구성 정의를 캡처하는 일반적인 엔지니어링 기준을 정의합니다.

    • 예를 들어 Azure Policy 적용하여 모든 관련 서비스에 가용성 영역 사용하도록 적용하여 안정적인 지역 내 배포 구성을 보장합니다.

중요 업무용 참조 구현에는 샘플 일반적인 엔지니어링 조건을 정의하고 적용하기 위한 다양한 보안 및 안정성 중심 정책이 포함되어 있습니다.

  • Azure Policy 사용하여 일반적인 엔지니어링 기준을 기준으로 서비스 구성 드리프트를 모니터링합니다.

전용 관리 그룹에서 여러 프로덕션 구독이 있는 중요 업무용 시나리오의 경우 관리 그룹 scope 할당의 우선 순위를 지정합니다.

  • 가능한 경우 기본 제공 정책을 사용하여 사용자 지정 정책 정의를 유지 관리하는 운영 오버헤드를 최소화합니다.

  • 사용자 지정 정책 정의가 필요한 경우 적절한 관리 그룹 scope 정의를 배포하여 포괄 환경 구독에서 다시 사용할 수 있도록 하여 프로덕션 환경과 하위 환경에서 정책을 다시 사용할 수 있도록 합니다.

    • 애플리케이션 로드맵을 Azure 로드맵에 맞출 때 사용 가능한 Microsoft 리소스를 사용하여 중요한 사용자 지정 정의를 기본 제공 정의로 통합할 수 있는지 살펴봅니다.

참고

Azure 랜딩 존 내에서 배포할 때 광범위한 Azure 자산 내의 모든 애플리케이션에서 재사용할 수 있도록 중간 회사 루트 관리 그룹 scope 내에 사용자 지정 Azure Policy 정의를 배포하는 것이 좋습니다. 랜딩 존 환경에서 특정 중앙 집중식 보안 정책은 기본적으로 더 높은 관리 그룹 범위 내에서 적용되어 전체 Azure 자산에서 보안 규정 준수를 적용합니다. 예를 들어 Azure 정책을 적용하여 VM 확장을 통해 소프트웨어 구성을 자동으로 배포하고 규정 준수 기준 VM 구성을 적용해야 합니다.

  • Azure Policy 사용하여 애플리케이션 전체에서 일관된 태그 지정 스키마를 적용합니다.
    • 필요한 Azure 태그를 식별하고 추가 정책 모드를 사용하여 사용량을 적용합니다.

애플리케이션이 Microsoft Mission-Critical 지원을 구독하는 경우 적용된 태그 지정 스키마가 의미 있는 컨텍스트를 제공하여 애플리케이션에 대한 심층적인 이해를 통해 지원 환경을 보강해야 합니다.

  • Microsoft Entra 활동 로그를 애플리케이션에서 사용하는 전역 Log Analytics 작업 영역으로 내보냅니다.
    • Azure 활동 로그가 장기 보존을 위해 운영 데이터와 함께 전역 Storage 계정 내에 보관되었는지 확인합니다.

Azure 랜딩 존에서 Microsoft Entra 활동 로그도 중앙 집중식 플랫폼 Log Analytics 작업 영역으로 수집됩니다. 이 경우 전역 Log Analytics 작업 영역에서 여전히 Microsoft Entra ID 필요한 경우 평가해야 합니다.

  • 보안 정보 및 이벤트 관리를 클라우드용 Microsoft Defender(이전의 Azure Security Center)과 통합합니다.

Virtual Machines 사용할 때 IaaS 관련 고려 사항

IaaS Virtual Machines 사용해야 하는 시나리오에서는 몇 가지 세부 사항을 고려해야 합니다.

디자인 고려 사항

  • 이미지가 배포된 후에는 자동으로 업데이트되지 않습니다.
  • 업데이트 실행 중인 VM에 자동으로 설치되지 않습니다.
  • 이미지 및 개별 VM은 일반적으로 기본적으로 강화되지 않습니다.

디자인 권장 사항

  • SSH, RDP 또는 기타 프로토콜에 대한 액세스를 제공하여 공용 인터넷을 통해 Virtual Machines 직접 액세스를 허용하지 않습니다. 항상 소수의 사용자 그룹에 대한 액세스가 제한된 Azure Bastion 및 jumpboxes를 사용합니다.
  • 네트워크 보안 그룹, (Azure) 방화벽 또는 Application Gateway(수준 7)를 사용하여 송신 트래픽을 필터링하고 제한하여 직접 인터넷 연결을 제한합니다.
  • 다중 계층 애플리케이션의 경우 다른 서브넷을 사용하고 네트워크 보안 그룹을 사용하여 그 사이에 대한 액세스를 제한하는 것이 좋습니다.
  • 가능한 경우 공개 키 인증의 사용 우선 순위를 지정합니다. Azure Key Vault 같은 안전한 장소에 비밀을 저장합니다.
  • 인증 및 액세스 제어를 사용하여 VM을 보호합니다.
  • 중요 업무용 애플리케이션 시나리오에 설명된 것과 동일한 보안 사례를 적용합니다.

Azure의 IaaS 워크로드에 대한 보안 모범 사례뿐만 아니라 해당되는 경우 위에서 설명한 대로 중요 업무용 애플리케이션 시나리오에 대한 보안 사례를 따르고 적용합니다.

다음 단계

중요 업무용 애플리케이션 시나리오의 운영 절차에 대한 모범 사례를 검토합니다.

운영 프로시저