Azure 보안 모범 사례

이 문서에서는 고객이 학습한 교훈과 사용자 환경의 경험을 기반으로 하는 권장 보안 모범 사례를 설명합니다.

비디오 프레젠테이션은 Azure 보안 모범 사례를 참조하세요.

1. 사용자: 클라우드 보안 여정에 대한 팀 교육

{b>팀은 진행 중인 여정을 이해해야 합니다.

무엇을?

다음을 포함하여 클라우드 보안 경험 및 탐색할 변경 내용에 대해 보안 및 IT 팀에 교육합니다.

  • 클라우드의 위협
  • 공유 책임 모델 및 보안에 미치는 영향
  • 일반적으로 클라우드 채택과 함께 제공되는 문화권 및 역할 및 책임에 대한 변경

그 이유는

클라우드 보안에는 사고방식과 접근 방식의 변화가 필요합니다. 보안이 조직에 제공하는 결과는 변경되지 않지만 클라우드에서 이러한 결과를 수행하는 가장 좋은 방법은 크게 변경 될 수 있습니다.

클라우드로의 전환은 단독 주택에서 고층 아파트 건물로 이사하는 것과 비슷합니다. 여전히 배관 및 전기와 같은 기본 인프라는 있지만 사교, 요리, TV 및 인터넷 등과 같은 유사한 활동을 하게 됩니다. 그러나 건물과 함께 제공되는 제반 시설, 건물을 제공하고 유지 관리하는 사람, 일상생활에는 상당한 차이가 있는 경우가 많습니다.

누가?

CIO 또는 CISO에서 기술 실무자에 이르기까지 보안 책임이 있는 보안 및 IT 조직의 모든 사용자는 변경 내용을 잘 알고 있어야 합니다.

방법은?

클라우드 환경으로 전환하는 동안 성공적으로 배포하고 운용하는 데 필요한 컨텍스트를 팀에 제공합니다.

Microsoft는 고객과 IT 조직이 클라우드로의 여정에 대해 학습한 다음 단원을 게시했습니다.

자세한 내용은 Azure Security Benchmark 역할, 책임 및 책임을 참조하세요.

2. 사용자: 클라우드 보안 기술에 대한 팀 교육

사용자들은 어떤 방향으로 진행할 것인지 이해해야 합니다.

무엇을?

팀이 다음을 비롯한 클라우드 리소스 보안에 대한 기술 교육을 받을 수 있는 시간을 확보하도록 해야 합니다.

  • 클라우드 기술 및 클라우드 보안 기술
  • 권장 구성 및 모범 사례
  • 추가적인 기술 세부 사항을 배울 수 있는 위치

그 이유는

기술 팀은 정보에 입각한 보안 결정을 내리기 위해 기술 정보에 액세스해야 합니다. 기술 팀은 업무에 대한 신기술을 배우는 데 능숙하지만 클라우드의 세부 정보가 너무 많아서 매일 규칙적으로 학습하는 것이 어려울 수 있습니다.

따라서 기술 학습을 위한 전담 시간을 따로 확보합니다. 학습은 사람들이 클라우드 보안을 평가하는 능력에 대한 신뢰를 구축할 시간을 확보하는 데 도움이 됩니다. 또한 기존 기술과 프로세스를 조정하는 방법도 고려할 수 있게 됩니다.

누가?

클라우드 기술과 직접 상호 작용하는 모든 보안 및 IT 역할 부서는 클라우드 플랫폼 및 보안 유지 방법에 대한 기술적 학습 시간을 따로 할애해야 합니다.

보안, IT 기술 관리자 및 프로젝트 관리자는 클라우드 리소스 보안을 위한 몇 가지 기술 세부 정보를 숙지할 수 있습니다. 이러한 과정은 클라우드 이니셔티브를 보다 효과적으로 이끌고 조정하는 데 도움이 됩니다.

방법은?

기술 보안 전문가가 클라우드 자산을 보호하는 방법을 습득할 수 있는 자기 주도식 교육을 받을 시간을 확보하도록 합니다. 항상 가능한 것은 아니지만 숙련된 강사 및 실습 랩을 통해 공식 교육에 액세스할 수 있습니다.

Important

ID 프로토콜은 클라우드의 액세스 제어에 중요하지만 온-프레미스 보안에서 우선 순위가 지정되지 않는 경우가 많습니다. 보안 팀은 이러한 프로토콜 및 로그를 숙지하는 데 집중해야 합니다.

Microsoft는 기술 전문가가 기능을 향상하는 데 도움이 되는 광범위한 리소스를 제공합니다. 이러한 리소스는 다음과 같습니다.

3. 프로세스: 클라우드 보안 결정에 대한 책임 할당

아무도 보안 결정을 내릴 책임이 없는 경우 보안 결정이 내려지지 않습니다.

무엇을?

엔터프라이즈 Azure 환경에 대해 각 보안 결정 유형을 내릴 책임이 있는 사용자를 선택합니다.

그 이유는

보안 결정에 대한 명확한 소유권은 클라우드 채택 속도를 높이고 보안을 강화합니다. 소유권의 부족은 일반적으로 아무도 결정을 내릴 수있는 권한을 느끼지 않기 때문에 마찰을 만듭니다. 결정을 요청할 사람이 누군지 아무도 모르며 정보에 입각한 결정을 내릴 책임이 있는 사람도 없습니다. 마찰은 종종 다음을 방해합니다.

  • 비즈니스 목표
  • 개발자 타임라인
  • IT 목표
  • 보안 보증

마찰로 인해 다음이 발생할 수 있습니다.

  • 보안 승인을 기다리는 중단된 프로젝트
  • 보안 승인을 기다릴 수 없는 안전하지 않은 배포

누가?

보안 리더십은 클라우드에 대한 보안 결정을 내릴 책임이 있는 팀 또는 개인을 선택합니다.

방법은?

주요 보안 결정을 내릴 책임이 있는 그룹 또는 개인을 선택합니다.

이러한 소유자, 연락처 정보를 문서화하고 보안, IT 및 클라우드 팀 내에서 정보를 널리 공유합니다. 사회화는 모든 역할 담당자가 쉽게 연락할 수 있도록 합니다.

이러한 영역은 일반적으로 보안 결정이 필요한 영역입니다. 다음 표에서는 의사 결정 범주, 범주 설명 및 자주 결정을 내리게 되는 팀을 보여 줍니다.

Decision 설명 일반적인 팀
네트워크 보안 Azure Firewall, 네트워크 가상 어플라이언스 및 연결된 라우팅, WAF(웹 애플리케이션 방화벽), NSG, ASG 등을 구성하고 기본. 네트워크 보안에 중점을 두는 인프라 및 엔드포인트 보안
네트워크 관리 엔터프라이즈 차원의 가상 네트워크 및 서브넷 할당을 관리합니다. 중앙 IT 운영의 기존 네트워크 운영 팀
서버 엔드포인트 보안 서버 보안(패치, 구성, 엔드포인트 보안 등)을 모니터링하고 수정합니다. 중앙 IT 운영 및인프라 및 엔드포인트 보안 팀이 공동으로
인시던트 모니터링 및 응답 클라우드용 Microsoft Defender, Microsoft Entra ID Protection 등 SIEM 또는 원본 콘솔에서 보안 인시던트를 조사하고 수정합니다. 보안 운영
정책 관리 Azure RBAC(Azure 역할 기반 액세스 제어), 클라우드용 Defender, 관리자 보호 전략 및 Azure Policy를 사용하여 Azure 리소스를 제어하는 방향을 설정합니다. 정책 및 표준 및보안 아키텍처 팀이 공동으로
ID 보안 및 표준 Microsoft Entra 디렉터리, PIM/pam 사용, 다단계 인증, 암호/동기화 구성, 애플리케이션 ID 표준에 대한 방향을 설정합니다. ID 및 키 관리, 정책 및 표준보안 아키텍처 팀이 공동으로

참고 항목

  • 의사 결정권자가 이러한 책임을 위해 클라우드 영역에서 적절한 교육을 받을 수 있도록 보장합니다.
  • 장기적으로 레코드를 제공하고 조직을 안내하기 위해 의사 결정이 정책 및 표준에 문서화되어 있는지 확인합니다.

4. 프로세스: 클라우드에 대한 인시던트 대응 프로세스 업데이트

미리 계획하십시오. 위기가 발생하는 동안에는 위기에 대비할 시간이 없습니다.

무엇을?

Azure 클라우드 플랫폼에서 보안 인시던트에 대비합니다. 이 준비에는 채택한 네이티브 위협 탐지 도구가 포함됩니다. 인시던트 조사, 수정 및 위협 헌팅 중에 최선을 다해 작업할 수 있도록 프로세스를 업데이트하고, 팀을 준비하고, 시뮬레이션된 공격을 연습합니다.

그 이유는

활성 공격자는 조직에 즉각적인 위험을 초래합니다. 상황은 신속하게 제어하기 어려울 수 있습니다. 공격에 빠르고 효과적으로 대응합니다. 이 IR(인시던트 대응) 프로세스는 엔터프라이즈 데이터, 시스템 및 계정을 호스팅하는 모든 클라우드 플랫폼을 포함하여 전체 자산에 효과적이어야 합니다.

유사한 측면도 많이 있지만, 클라우드 플랫폼은 기술적으로 온-프레미스 시스템과 다릅니다. 온-프레미스 시스템은 일반적으로 다른 형태로 정보를 사용할 수 있기 때문에 기존 프로세스를 중단할 수 있습니다. 보안 분석가는 상황을 느리게 만들 수 있는 익숙하지 않은 환경에 빠르게 대응해야 한다는 난제가 있을 수 있습니다. 이 문은 클래식 온-프레미스 아키텍처 및 네트워크/디스크 포렌식 접근 방식에서만 학습된 경우에 특히 그렇습니다.

누가?

IR 프로세스 현대화는 일반적으로 보안 운영 팀이 주도합니다. 이러한 작업은 종종 기술 및 전문 지식을 위해 다른 그룹의 지원과 함께 제공됩니다.

  • 스폰서쉽: 보안 운영 디렉터 또는 이에 상응하는 스폰서 프로세스 현대화

  • 실행: 기존 프로세스를 조정하거나 처음으로 작성하는 작업은 다음과 같은 공동 작업입니다.

    • 보안 운영 팀: 인시던트 관리 팀 또는 리더십은 주요 외부 이해 관계자에 대한 프로세스 및 통합 업데이트를 주도합니다. 이러한 팀에는 법률 및 커뮤니케이션 또는 홍보 팀이 포함됩니다.
    • 보안 운영 팀: 보안 분석가는 기술 인시던트 조사 및 심사에 대한 전문 지식을 제공합니다.
    • 중앙 IT 운영 팀: 이 팀은 직접, 탁월한 클라우드 센터를 통해 또는 외부 컨설턴트를 통해 클라우드 플랫폼에 대한 전문 지식을 제공합니다.

방법은?

프로세스를 업데이트하고, 팀이 활성 공격자를 찾을 때 수행할 작업을 알 수 있도록 준비시킵니다.

  • 프로세스 및 플레이북: 기존 조사, 수정 및 위협 헌팅 프로세스를 클라우드 플랫폼 작동 방식의 차이점에 맞게 조정합니다. 차이점으로는 새 도구 또는 다른 도구, 데이터 원본, ID 프로토콜 등이 있습니다.
  • 교육: 분석가에게 전반적인 클라우드 변환, 플랫폼 작동 방식에 대한 기술 세부 정보, 새 프로세스 또는 업데이트된 프로세스에 대해 교육합니다. 이 정보를 통해 변경될 수 있는 사항과 필요한 사항을 얻을 수 있는 위치를 알 수 있습니다.
  • 주요 초점 영역: 리소스 링크에 설명된 많은 세부 정보가 있지만, 이러한 영역은 교육 및 계획 작업에 집중할 수 있는 위치입니다.
    • 공유 책임 모델 및 클라우드 아키텍처: 보안 분석가 입장에서 Azure는 많은 서비스를 제공하는 소프트웨어 정의 데이터 센터입니다. 이러한 서비스에는 Azure SQL Database Azure Functions와 같이 온-프레미스와 다른 VM 및 기타 서비스가 포함됩니다. 가장 좋은 데이터는 서비스 로그 또는 특수화된 위협 탐지 서비스에 있습니다. Microsoft에서 운영하고 여러 고객에게 제공되는 기본 OS/VM에 대한 로그에는 이러한 서비스가 없습니다. 분석가는 이 컨텍스트를 이해하고 일상적인 워크플로에 통합해야 합니다. 이렇게 하면 필요한 데이터, 이러한 데이터를 가져올 위치 및 데이터 형식을 알 수 있습니다.
    • 엔드포인트 데이터 원본: 클라우드 호스팅 서버에서 공격 및 맬웨어에 대한 인사이트 및 데이터를 가져오는 것은 종종 네이티브 클라우드 검색 도구를 사용하여 더 빠르고 쉽고 정확합니다. 클라우드용 Microsoft Defender 및 EDR(엔드포인트 감지 및 응답) 솔루션과 같은 도구는 기존의 직접 디스크 액세스 접근 방식보다 더 정확한 데이터를 제공합니다. 직접 디스크 포렌식은 가능하며 법적 절차에 필요한 시나리오에 사용할 수 있습니다. 자세한 내용은 Azure의 컴퓨터 법의학을 참조하세요. 하지만 이 방법은 종종 공격을 감지하고 조사하는 가장 비효율적인 방법입니다.
    • 네트워크 및 ID 데이터 원본: 클라우드 플랫폼의 많은 기능은 주로 액세스 제어를 위해 ID를 사용합니다. 이 액세스 제어에는 Azure Portal에 대한 액세스가 포함되지만 네트워크 액세스 제어도 광범위하게 사용됩니다. 이 액세스 제어를 사용하려면 분석가는 클라우드 ID 프로토콜을 보다 폭넓게 이해하면서 인시던트 조사 및 수정을 지원하기 위한 공격자 활동 및 합법적인 사용자 활동을 전체적으로 파악해야 합니다. ID 디렉터리와 프로토콜은 온-프레미스 디렉터리와 다릅니다. 일반적으로 LDAP, Kerberos, NTLM 및 Active Directory가 아닌 SAML, OAuth 및 OpenID Connect 및 클라우드 디렉터리를 기준으로 합니다.
    • 연습: 시뮬레이트된 공격 및 대응은 조직의 근육 메모리 및 기술 준비 상태를 구축하는 데 도움이 될 수 있습니다. 이를 통해 보안 분석가, 위협 헌터, 인시던트 관리자 및 조직의 기타 이해 관계자는 준비를 갖출 수 있습니다. 직무 학습 및 조정은 인시던트 대응의 자연스러운 부분이지만 위기 상황에서 필요한 학습량을 최소화하기 위해 준비할 수 있습니다.

주요 리소스

자세한 내용은 Azure에 대한 Azure Security Benchmark 인시던트 대응 프로세스를 참조하세요.

5. 프로세스: 보안 상태 관리 설정

첫째, 자신을 잘 파악하세요.

무엇을?

다음을 통해 Azure 환경의 보안 상태를 적극적으로 관리하고 있는지 확인합니다.

  • 책임의 명확한 소유권을 할당:
    • 보안 상태 모니터링
    • 자산에 대한 위험 완화
  • 이러한 작업 자동화 및 단순화

그 이유는

일반적인 보안 예방 위험을 빠르게 식별하여 수정하면 조직에 대한 전반적인 위험을 크게 줄일 수 있습니다.

클라우드 데이터 센터의 소프트웨어 정의 특성을 통해 광범위한 자산 계측을 통해 소프트웨어 취약성 또는 보안 잘못된 구성과 같은 보안 위험을 지속적으로 모니터링할 수 있습니다. 개발자와 IT 팀이 VM, 데이터베이스 및 기타 리소스를 배포할 수 있는 속도 때문에 리소스를 안전하고 적극적으로 모니터링하도록 구성해야 합니다.

이러한 새로운 기능은 새로운 가능성을 제공하지만, 가치를 실현하려면 사용 책임을 할당해야 합니다. 빠르게 진화하는 클라우드 작업과 발맞춰 실행하려면 사용자 프로세스를 가능한 한 간단하고 자동화된 상태로 유지해야 합니다. “드라이브 단순성” 보안 원칙을 참조하세요.

참고 항목

단순화 및 자동화 목표는 직무를 없애는 것이 아니라 IT 및 DevOps 팀과 연계하고 이러한 팀을 교육하는 것과 같은 더 높은 가치의 인간 활동에 집중할 수 있도록 반복적인 작업의 부담을 없애는 것입니다.

누가?

이 사례는 일반적으로 두 가지 책임 집합으로 나뉩니다.

  • 보안 상태 관리: 이 기능은 종종 기존 취약성 관리 또는 거버넌스 기능이 발전한 것입니다. 결과에는 클라우드용 Microsoft Defender 보안 점수 및 기타 데이터 원본을 사용하여 전반적인 보안 상태를 모니터링한 내용이 포함됩니다. 또한 위험을 완화하고 보안 리더십에 위험을 보고하기 위해 리소스 소유자와 적극적으로 협력하는 과정이 포함됩니다.

  • 보안 수정: 이러한 위험을 해결하기 위한 책임을 해당 리소스 관리를 담당하는 팀에 할당합니다. 이 책임은 자체 애플리케이션 리소스를 관리하는 DevOps 팀 또는 중앙 IT 운영의 기술별 팀에 속합니다.

    • 컴퓨팅 및 애플리케이션 리소스
      • App Services: 애플리케이션 개발 및 보안 팀
      • 컨테이너: 애플리케이션 개발 또는 인프라/IT 작업
      • VM, 확장 집합, 컴퓨팅: IT/인프라 작업
    • 데이터 및 스토리지 리소스
      • SQL, Redis, Data Lake Analytics, 데이터 레이크 저장소: 데이터베이스 팀
      • 스토리지 계정: 스토리지 및 인프라 팀
    • ID 및 액세스 리소스
      • 구독: ID 팀
      • 키 자격 증명 모음: ID 또는 정보/데이터 보안 팀
    • 네트워킹 리소스: 네트워크 보안 팀
    • IoT 보안: IoT 운영 팀

방법은?

보안은 모두에게 필요합니다. 하지만 모든 사람이 그것이 얼마나 중요한지, 무엇을 해야 하는지, 어떻게 해야 하는지 알고 있는 것은 아닙니다.

  • 리소스 소유자는 가용성, 성능, 비용 및 기타 성공 요인에 대해 책임을 져야 하는 것처럼 보안 위험에 대한 책임을 져야 합니다.
  • 보안 위험이 자산에 중요한 이유, 위험을 완화하기 위해 수행할 수 있는 작업 및 생산성 손실을 최소화하면서 구현하는 방법을 명확하게 이해하면서 리소스 소유자를 지원합니다.

Important

리소스를 보호하는 이유, 보호 대상 및 방법에 대한 설명은 종종 다양한 리소스 유형 및 애플리케이션에서 유사하지만 각 팀이 이미 잘 알고 있는 관심 분야와의 관계를 파악하는 것이 중요합니다. 보안 팀은 이러한 팀의 성공에 주력하는 신뢰할 수 있는 어드바이저 및 파트너의 역할을 하는 IT 및 DevOps 대응 팀과 협력할 수 있습니다.

도구: 클라우드용 Microsoft Defender의 보안 점수는 다양한 자산에 대해 Azure에서 가장 중요한 보안 정보를 평가합니다. 이 평가는 상태 관리의 시작점이 될 수 있으며 필요에 따라 사용자 지정 Azure 정책 및 기타 메커니즘으로 보완할 수 있습니다.

주기: 보안 점수를 검토하고 특정 개선 목표를 사용하여 이니셔티브를 계획하도록 정기적인 주기(일반적으로 매월)를 설정합니다. 필요에 따라 주기를 늘릴 수 있습니다.

가능한 경우 참여를 높이기 위해 흥미로운 경쟁 만들기 및 점수가 가장 크게 향상된 DevOps 팀을 위한 포상과 같은 활동을 게임으로 제공합니다.

자세한 내용은 Azure Security Benchmark 보안 상태 관리 전략을 참조하세요.

6. 기술: 암호 없는 인증 또는 다단계 인증 필요

전문 공격자가 관리자의 암호를 추측하거나 도용할 수 없도록 하는 기업용 보안을 원하시나요?

무엇을?

모든 중요한 영향을 미치는 관리자가 암호 없는 인증 또는 다단계 인증을 사용하도록 요구합니다.

그 이유는

골동품 해골 키가 현대의 강도로부터 집을 보호하지 않는 것처럼 암호는 일반적인 공격으로부터 계정을 보호 할 수 없습니다. 기술 세부 정보는 pa$$word 중요하지 않음을 참조하세요.

과거에는 다단계 인증은 부담스러운 추가 단계였습니다. 오늘날 암호 없는 접근 방식은 사용자가 Windows Hello 및 모바일 디바이스에서 얼굴 인식과 같은 생체 인식 접근 방식을 사용하여 로그인하는 방식을 개선합니다. 또한 제로 트러스트 접근 방식은 신뢰할 수 있는 디바이스를 저장합니다. 이 방법을 사용하면 대역 외 다단계 인증 작업을 성가시게 하는 메시지를 줄일 수 있습니다. 자세한 내용은 사용자 로그인 빈도를 참조하세요.

누가?

암호 및 다단계 이니셔티브는 일반적으로 ID 및 키 관리 또는 보안 아키텍처로 인해 발생합니다.

  • 스폰서쉽: CISO, CIO 또는 ID 디렉터는 일반적으로 이 작업을 후원합니다.
  • 실행: 실행은 다음과 관련된 공동 작업입니다.

방법은?

암호 없는 또는 다단계 인증을 구현합니다. 관리자가 필요할 때 사용하는 방법을 교육하고 관리자가 서면 정책을 사용하여 따라야 합니다. 다음 기술 중 하나 이상을 사용합니다.

참고 항목

이제 문자 메시지 기반 다단계 인증은 공격자가 비교적 손쉽게 우회할 수 있으며 암호 없는 보다 강력한 다단계 인증에 집중할 수 있도록 합니다.

자세한 내용은 모든 Microsoft Entra ID 기반 액세스에 대한 Azure Security Benchmark 강력한 인증 제어를 참조하세요.

7. 기술: 네이티브 방화벽 및 네트워크 보안 통합

네트워크 공격에 대한 시스템 및 데이터 보호를 간소화합니다.

무엇을?

Azure Firewall, AZURE WAF(Web App Firewall) 및 DDoS(분산 서비스 거부) 완화를 네트워크 보안 접근 방식에 통합하여 네트워크 보안 전략 및 유지 관리를 간소화합니다.

그 이유는

단순성은 혼동, 구성 오류 및 기타 인적 오류로 인한 위험 가능성을 줄여주기 때문에 보안에 매우 중요합니다. “드라이브 단순성” 보안 원칙을 참조하세요.

방화벽 및 WAF는 악의적인 트래픽으로부터 애플리케이션을 보호하기 위한 중요한 기본 보안 제어이지만 설정 및 유지 관리는 복잡할 수 있으며 보안 팀은 많은 시간과 관심을 쏟아야 할 수 있습니다(자동차에 맞춤형 애프터마켓 부품을 추가하는 것과 유사함). Azure의 네이티브 기능은 방화벽, 웹 애플리케이션 방화벽, DDoS(분산 서비스 거부) 완화 등의 구현 및 작업을 간소화할 수 있습니다.

이를 통해 팀은 좀 더 가치 있는 다음과 같은 보안 작업에 시간과 관심을 쏟을 수 있게 됩니다.

  • Azure 서비스의 보안 평가
  • 보안 작업 자동화
  • 애플리케이션 및 IT 솔루션과 보안 통합

누가?

  • 스폰서쉽: 보안 리더십 또는 IT 리더십은 일반적으로 네트워크 보안 전략 업데이트를 후원합니다.
  • 실행: 전략을 클라우드 네트워크 보안 전략에 통합하는 것은 다음과 같은 공동 작업입니다.
    • 보안 아키텍처: 클라우드 네트워크 및 클라우드 네트워크 보안 팀장과 함께 클라우드 네트워크 보안 아키텍처를 설정합니다.
    • 클라우드 네트워크는 중앙 IT 운영을 이끌고 Cloud Network 보안은 인프라 보안 팀을 이끌고 있습니다.
      • 보안 설계자와 함께 클라우드 네트워크 보안 아키텍처를 설정합니다.
      • 방화벽, NSG 및 WAF 기능을 구성하고 애플리케이션 설계자와 함께 WAF 규칙 작업을 수행합니다.
    • 애플리케이션 설계자: 네트워크 보안 팀과 협력하여 WAF 규칙 집합 및 DDoS 구성을 빌드하고 구체화하여 가용성을 방해하지 않으면서 애플리케이션을 보호합니다.

방법은?

작업을 간소화하려는 조직에는 다음 두 가지 옵션이 있습니다.

  • 기존 기능 및 아키텍처 확장: 많은 조직에서는 기존 투자를 기술 및 프로세스 통합에 활용하도록 기존 방화벽 기능의 사용을 확장하도록 선택하는 경우가 많습니다. 특히 클라우드를 처음 채택할 때 더욱 그렇습니다.
  • 네이티브 보안 제어 수용: 더 많은 조직에서 타사 기능 통합의 복잡성을 방지하기 위해 네이티브 컨트롤을 사용하는 것을 선호하기 시작했습니다. 이러한 조직은 일반적으로 부하 분산, 사용자 정의 경로, 방화벽 또는 WAF 자체의 잘못된 구성 위험 및 다양한 기술 팀 간의 인계 지연을 방지하려고 합니다. 이 옵션은 타사 기능보다 더 쉽게 기본 제공 기능을 자동화하고 계측할 수 있으므로 조직은 IaC(infrastructure as Code) 접근 방식을 수용하는 조직에 유용합니다.

Azure 네이티브 네트워크 보안 기능에 대한 설명서는 다음에서 찾을 수 있습니다.

Azure Marketplace에는 많은 타사 방화벽 공급자가 포함되어 있습니다.

자세한 내용은 Azure Security Benchmark DDOS 보호웹 애플리케이션 방화벽 보호를 참조하세요.

8. 기술: 네이티브 위협 탐지 통합

Azure 시스템 및 데이터에 대한 공격 검색 및 대응을 간소화합니다.

무엇을?

네이티브 위협 탐지 기능을 보안 작업 및 SIEM에 통합하여 위협 탐지 및 대응 전략을 간소화합니다.

그 이유는

보안 작업의 목적은 환경에 액세스하는 활성 공격자가 미치는 영향을 줄이는 것입니다. 이러한 영향은 MTTA(평균 승인 시간) 및 MTTR(평균 수정 시간) 인시던트를 통해 측정합니다. 이 사례를 사용하려면 인시던트 대응의 모든 요소에서 정확도와 속도가 모두 필요합니다. 이러한 결과로 인해 도구의 품질과 프로세스 실행 효율성이 가장 중요해졌습니다.

기존 도구 및 접근 방식을 사용하여 높은 위협 탐지 효과를 얻기는 어렵습니다. 이 도구와 접근 방식은 클라우드 기술의 차이와 빠른 변화 속도로 인해 온-프레미스 위협 탐지를 위해 설계되었습니다. 기본적으로 통합된 검색은 현재 위협 및 클라우드 플랫폼 변경을 따라갈 수 있는 클라우드 공급자가 기본 산업 규모 솔루션을 제공합니다.

이러한 네이티브 솔루션을 사용하면 보안 운영 팀이 인시던트 조사 및 수정에 집중할 수 있습니다. 익숙하지 않은 로그 데이터에서 경고를 만들고 도구와 유지 관리 작업을 통합하여 시간 낭비 없이 해당 항목에 집중할 수 있습니다.

누가?

일반적으로 보안 운영 팀에서 구동합니다.

  • 스폰서쉽: 이 작업은 일반적으로 보안 운영 디렉터 또는 동등한 역할 담당자가 후원합니다.
  • 실행: 네이티브 위협 탐지를 통합하는 것은 다음과 같은 솔루션과 관련된 공동 작업입니다.
    • 보안 운영: SIEM 및 인시던트 조사 프로세스에 경고를 통합합니다. 보안 운영 팀은 분석가에게 클라우드 경고와 그 의미 및 네이티브 클라우드 도구를 사용하는 방법을 교육할 수 있습니다.
    • 인시던트 준비: 클라우드 인시던트를 연습에 통합하고 팀 준비를 위해 연습을 수행해야 합니다.
    • 위협 인텔리전스: 클라우드 공격에 대한 정보를 연구하고 통합하여 컨텍스트 및 인텔리전스를 팀에 알릴 수 있습니다.
    • 보안 아키텍처: 네이티브 도구를 보안 아키텍처 설명서에 통합합니다.
    • 정책 및 표준: 조직 전체에서 네이티브 도구를 사용하도록 설정하기 위한 표준 및 정책을 설정합니다. 규정 준수를 모니터링합니다.
    • 인프라 및 엔드포인트중앙 IT 작업: 검색을 구성 및 사용하도록 설정하고 자동화 및 인프라를 코드 솔루션으로 통합합니다.

방법은?

사용 중인 모든 리소스에 대해 클라우드용 Microsoft Defender에서 위협 탐지를 사용하도록 설정하고 각 팀이 위에서 설명한 대로 이러한 리소스를 프로세스에 통합하도록 합니다.

자세한 내용은 Azure 리소스에 대한 Azure Security Benchmark 위협 검색을 참조하세요.

9. 아키텍처: 단일 디렉터리 및 ID에 대해 표준화

여러 ID 및 디렉터리를 처리하고 싶어하는 사람은 없습니다.

무엇을?

단일 Microsoft Entra 디렉터리에서 표준화합니다. Azure의 각 애플리케이션 및 사용자에 대해 단일 ID를 표준화할 수 있습니다.

참고 항목

이 모범 사례는 특히 엔터프라이즈 리소스를 나타냅니다. 파트너 계정의 경우 디렉터리에 계정을 만들고 기본 필요가 없도록 Microsoft Entra B2B를 사용합니다. 고객 또는 시민 계정의 경우 Azure AD B2C를 사용하여 관리합니다.

그 이유는

여러 계정 및 ID 디렉터리가 불필요한 마찰을 일으키며, 이로 인해 매일 워크플로에서 다음 작업이 혼동됩니다.

  • 생산성 사용자
  • 개발자
  • IT 및 ID 관리자
  • 보안 분석가
  • 기타 역할

여러 계정 및 디렉터리를 관리하면 잘못된 보안 사례가 발생할 경우 도움이 될 수 있습니다. 이러한 사례에는 여러 계정의 암호 재사용과 같은 항목이 포함됩니다. 공격자가 대상으로 지정할 수 있는 부실 또는 중단된 계정이 발생할 가능성이 높아집니다.

특정 애플리케이션 또는 워크로드에 대해 사용자 지정 LDAP 디렉터리를 빠르게 설치하는 것이 더 쉬울 수도 있지만, 이 작업을 수행하면 통합 및 관리해야 할 작업이 훨씬 더 많아집니다. 이 작업은 기존 엔터프라이즈 테넌트를 사용하는 대신 추가 Azure 테넌트 또는 온-프레미스 Active Directory 포리스트를 설정하도록 선택하는 것과 비슷합니다. 자세한 내용은 단순성 위한 보안 원칙을 참조하세요.

누가?

단일 Microsoft Entra 디렉터리에서 표준화는 종종 팀 간 작업입니다. 이러한 작업은 보안 아키텍처 또는 ID 및 키 관리 팀에서 주도합니다.

  • 스폰서쉽: ID 및 키 관리보안 아키텍처는 일반적으로 이 작업을 후원하지만 일부 조직에서는 CISO 또는 CIO의 후원이 필요할 수 있습니다.
  • 실행: 실행은 다음과 관련된 공동 작업입니다.
    • 보안 아키텍처: 이 팀은 이 프로세스를 보안 및 IT 아키텍처 문서/다이어그램에 통합합니다.
    • 정책 및 표준: 이 팀은 정책을 문서화하고 규정 준수를 모니터링합니다.
    • ID 및 키 관리 또는 중앙 IT 운영: 이러한 팀은 기능을 사용하도록 설정하고 계정, 교육 등을 통해 개발자를 지원하여 정책을 구현합니다.
    • 애플리케이션 개발자 또는 중앙 IT 작업: 이러한 팀은 애플리케이션 및 Azure 서비스 구성에서 ID를 사용합니다. 책임은 DevOps 채택 수준에 따라 달라집니다.

방법은?

새로운 {b>그린필드브라운필드

  • Greenfield: 모든 엔터프라이즈 ID가 각 사용자에 대해 단일 계정으로 단일 Microsoft Entra 디렉터리를 사용할 수 있다는 명확한 정책을 설정하고 구현합니다.

  • 브라운필드: 많은 조직에는 여러 레거시 디렉터리와 ID 시스템이 있는 경우가 많습니다. 지속적인 관리 마찰 비용이 정리를 위한 투자를 초과하는 경우 이러한 레거시 항목을 해결합니다. ID 관리 및 동기화 솔루션은 이러한 문제 중 일부를 완화할 수 있지만 보안 및 생산성 기능의 긴밀한 통합이 부족합니다. 이러한 기능을 사용하면 사용자, 관리자 및 개발자에게 원활한 환경을 제공할 수 있습니다.

ID 사용을 결합할 이상적인 시기는 다음과 같은 애플리케이션 개발 주기 동안입니다.

  • 클라우드용 애플리케이션을 현대화합니다.
  • DevOps 프로세스를 사용하여 클라우드 애플리케이션을 업데이트합니다.

독립적인 사업부 또는 규정 요구 사항을 위해 별도의 디렉터리를 유지할 타당한 이유가 있지만 다른 모든 상황에서는 여러 디렉터리를 유지하지 않아야 합니다.

자세한 내용은 Azure Security Benchmark Microsoft Entra 중앙 ID 및 인증 시스템을 참조하세요.

Important

단일 계정 규칙의 유일한 예외는 IT 관리자 및 보안 분석가를 포함한 권한 있는 사용자가 관리 작업에 비해 표준 사용자 작업에 대해 별도의 계정을 가질 수 있다는 것입니다.

자세한 내용은 Azure Security Benchmark 권한 있는 액세스를 참조하세요.

10. 아키텍처: 키 대신 ID 기반 액세스 제어 사용

무엇을?

가능한 경우 키 기반 인증 대신 Microsoft Entra ID를 사용합니다. 예를 들어 Azure 서비스, 애플리케이션, API가 있습니다.

그 이유는

키 기반 인증을 사용하여 클라우드 서비스 및 API에서 인증을 받을 수 있습니다. 그러나 키를 안전하게 관리해야 하며, 특히 대규모로 잘 하기는 어렵습니다. 보안 키 관리는 개발자 및 인프라 전문가와 같은 비보안 전문가에게는 어려운 일이며 보안을 유지하지 못하는 경우가 많으며, 종종 조직에 주요 보안 위험을 초래합니다.

ID 기반 인증은 완성도 높은 기능으로 이러한 많은 문제를 극복합니다. 이 기능에는 비밀 순환, 수명 주기 관리, 관리 위임 등이 포함됩니다.

누가?

ID 기반 액세스 제어 구현은 종종 팀 간 작업입니다. 이러한 작업은 보안 아키텍처 또는 ID 및 키 관리 팀에서 주도합니다.

  • 스폰서쉽: 일부 조직에는 CISO 또는 CIO의 스폰서쉽이 필요할 수 있지만 일반적으로 이러한 작업은 보안 아키텍처 또는 ID 및 키 관리를 통해 지원됩니다.
  • 실행: 다음과 관련된 공동 작업:
    • 보안 아키텍처: 이 팀은 보안 및 IT 아키텍처 다이어그램 및 문서에 모범 사례를 통합합니다.
    • 정책 및 표준: 이 팀은 정책을 문서화하고 규정 준수를 모니터링합니다.
    • ID 및 키 관리 또는 중앙 IT 운영: 이러한 팀은 기능을 사용하도록 설정하고 계정, 교육 등을 통해 개발자를 지원하여 정책을 구현합니다.
    • 앱 개발자 또는 중앙 IT 작업: 애플리케이션 및 Azure 서비스 구성에서 ID를 사용합니다. 책임은 DevOps 채택 수준에 따라 달라집니다.

방법은?

ID 기반 인증을 사용하기 위한 조직의 기본 설정 및 관행을 지정하려면 프로세스를 따르고 기술을 사용하도록 설정해야 합니다.

프로세스

  1. 기본 ID 기반 인증 및 허용 가능한 예외를 명확하게 설명하는 정책 및 표준을 설정합니다.
  2. 개발자와 인프라 팀에게 새 접근 방식을 사용하는 이유, 수행해야 하는 작업 및 수행 방법을 교육합니다.
  3. 새로운 Azure 서비스 및 새 애플리케이션과 같이 현재와 미래에 채택되는 새로운 그린필드 기능부터 시작하여 기존 브라운필드 구성의 클린 후속 작업으로 실용적인 방식으로 변화를 구현합니다.
  4. 규정 준수를 모니터링하고 개발자 및 인프라 팀과 함께 후속 조치를 수행하여 고쳐 나갑니다.

기술

서비스 또는 자동화와 같은 사람이 아닌 계정의 경우 관리 ID를 사용합니다. Azure 관리 ID는 Microsoft Entra 인증을 지원하는 Azure 서비스 및 리소스에 인증할 수 있습니다. 소스 코드 또는 구성 파일에 자격 증명을 하드 코딩하는 것을 방지하기 위해 미리 정의된 액세스 권한 부여 규칙을 통해 인증을 사용할 수 있습니다.

관리 ID를 지원하지 않는 서비스의 경우 Microsoft Entra ID를 사용하여 리소스 수준에서 권한이 제한된 서비스 주체를 만듭니다. 인증서 자격 증명을 사용하여 서비스 주체를 구성하고 클라이언트 비밀로 대체해야 합니다. 두 경우 모두 Azure 관리 ID와 함께 Azure Key Vault 를 사용할 수 있으므로 Azure 함수와 같은 런타임 환경에서 키 자격 증명 모음에서 자격 증명을 검색할 수 있습니다.

자세한 내용은 Azure Security Benchmark 애플리케이션 ID를 참조하세요.

11. 아키텍처: 단일 통합 보안 전략 수립

보트가 앞으로 나아갈 수 있도록 모두가 같은 방향으로 노를 저어야 합니다.

무엇을?

모든 팀이 엔터프라이즈 시스템과 데이터를 허용하고 보호하는 단일 전략에 부합하는지 확인합니다.

그 이유는

팀이 공통 전략을 따르지 않고 격리된 상태에서 작업할 경우 개별적인 작업으로 인해 실수로 서로의 작업이 약화될 수 있습니다. 이러한 전략적 불일치는 불필요한 마찰을 만들어 모든 사람들의 목표 달성을 지연시킬 수 있습니다.

많은 조직에서 일관되게 발생해 온 구분 작업 방식의 한 가지 예는 자산의 구분입니다.

  • 네트워크 보안: 플랫 네트워크를 구분하기 위한 전략을 개발합니다. 이 전략은 종종 물리적 사이트, 할당된 IP 주소/범위 또는 유사한 항목을 기준으로 보안을 강화합니다.
  • ID 팀: 조직에 대한 이해와 지식을 기준으로 그룹 및 Active Directory OU(조직 구성 단위)에 대한 전략을 개발합니다.
  • 애플리케이션 팀: 이러한 시스템에서 작업하는 것은 어렵습니다. 제한된 투입과 비즈니스 운영, 목표 및 위험에 대한 이해 부족 상태로 설계되었기 때문입니다.

이러한 제한이 발생하는 조직에서 팀은 방화벽 예외에 대한 충돌을 자주 경험합니다. 팀이 예외를 승인하기 때문에 충돌은 보안에 부정적인 영향을 미칠 수 있습니다. 비즈니스에 필요한 애플리케이션 기능에 대한 배포 속도가 느려지므로 생산성은 보안에 부정적인 영향을 줍니다.

보안은 비판적 사고를 유도하여 건전한 마찰을 일으킬 수 있지만, 이러한 충돌은 목표를 방해하는 비정상 마찰만 만들어냅니다. 자세한 내용은 보안 전략 지침을 참조 하세요.

누가?

  • 스폰서쉽: 통합 전략은 일반적으로 CIO, CISO 및 CTO가 공동으로 후원합니다. 이러한 스폰서쉽은 종종 몇 가지 높은 수준의 요소에 대한 비즈니스 리더십 지원과 함께 제공되며 각 팀의 대표가 후원합니다.
  • 실행: 보안 전략은 모든 사용자가 구현해야 합니다. 다양한 팀의 데이터를 통합하여 소유권, 승인 및 성공 가능성을 높입니다.
    • 보안 아키텍처: 이 팀은 보안 전략 및 결과 아키텍처를 구축하기 위한 작업을 주도합니다. 보안 아키텍처는 팀의 피드백을 적극적으로 수집하고 다양한 대상을 위해 프레젠테이션, 문서 및 다이어그램으로 문서화합니다.
    • 정책 및 표준: 이 팀은 적절한 요소를 표준 및 정책으로 캡처한 다음, 규정 준수를 모니터링합니다.
    • 모든 기술 IT 및 보안 팀: 이러한 팀은 입력 요구 사항을 제공한 다음 엔터프라이즈 전략에 맞게 조정하고 구현합니다.
    • 애플리케이션 소유자 및 개발자: 이러한 팀은 해당 팀에 적용되는 전략 설명서를 읽고 이해합니다. 이상적으로는 자신의 역할에 맞게 지침을 조정합니다.

방법은?

모든 팀의 투입 및 적극적인 참여를 포함하는 클라우드용 보안 전략을 구축하고 구현합니다. 프로세스 설명서 형식은 다를 수 있지만 항상 다음이 포함됩니다.

  • 팀의 적극적인 투입: 조직의 사용자가 적극적으로 참여하지 않으면 전략은 실패하게 마련입니다. 이상적으로는 모든 팀이 동일한 방에 모여 협력하면서 전략을 구축하도록 하는 것이 좋습니다. 고객과 함께 진행하는 워크샵에서는 조직이 사실상 사일로에서 운영되며 이러한 모임을 통해 사람들이 처음으로 만나는 경우가 많습니다. 우리는 포용성이 필요하다는 사실을 알게되었습니다. 일부 팀이 초대되지 않은 경우 일반적으로 모든 참가자가 참가할 때까지 이 모임을 반복해야 합니다. 참가하지 않으면 프로젝트가 진행되지 않습니다.
  • 명확하게 문서화 및 전달: 모든 팀은 보안 전략을 인식해야 합니다. 이상적으로 보안 전략은 전체 기술 전략의 보안 구성 요소입니다. 이 전략에는 보안을 통합하는 이유, 보안에서 중요한 사항 및 성공적인 보안 구현 방식이 포함됩니다. 이 전략에는 애플리케이션 및 개발 팀이 관련 없는 정보를 읽지 않고도 명확하고 체계적인 지침을 얻을 수 있도록 하기 위한 특정 지침이 포함되어 있습니다.
  • 안정적이지만 유연함: 전략을 비교적 일관되고 안정적으로 유지하지만 아키텍처와 설명서를 통해 명확성을 추가하고 클라우드의 동적 특성을 수용해야 할 수 있습니다. 예를 들어 악의적인 외부 트래픽을 필터링하는 작업은 타사의 차세대 방화벽 사용 방식에서 Azure Firewall로 전환하고 수행 방법에 대한 다이어그램 및 지침을 조정하더라도 일관되게 전략적 명령으로 유지됩니다.
  • 세분화로 시작: 해결해야 할 크고 작은 전략 문제가 있지만 어딘가에서 시작해야 합니다. 엔터프라이즈 자산 세분화를 사용하여 보안 전략을 시작합니다. 이 구분은 나중에 변경하기 어려운 기본 결정이며 비즈니스 투입 및 많은 기술 팀이 모두 필요합니다.

Microsoft는 Azure에 구분 전략을 적용하기 위한 비디오 지침을 게시했습니다. 엔터프라이즈 구분네트워크 보안 조정에 대한 문서가 게시되어 있습니다.

클라우드 채택 프레임워크에는 팀이 다음을 수행할 수 있도록 도와주는 지침이 포함되어 있습니다.

자세한 내용은 Azure Security Benchmark 거버넌스 전략을 참조하세요.