자산 보호

자산에는 랩톱, 데이터베이스, 파일 및 가상 스토리지 계정과 같은 실제 및 가상 항목이 포함됩니다. 중요 비즈니스용 자산 보안은 스토리지, 데이터, 엔드포인트 디바이스 및 애플리케이션 구성 요소와 같은 기본 시스템의 보안에 의존하는 경우가 많습니다. 가장 중요한 기술 자산은 일반적으로 비즈니스 웹 사이트, 프로덕션 라인 및 통신과 같은 애플리케이션의 데이터 및 가용성입니다.

자산 보호는 보안 아키텍처, 표준 및 정책을 지원하는 컨트롤을 구현합니다. 각 자산 유형 및 보안 요구 사항은 고유합니다. 모든 자산 유형에 대한 보안 표준은 모든 인스턴스에 일관되게 적용되어야 합니다.

자산 보호는 모든 제어 유형에서 일관되게 실행하는 데 중점을 둡니다. 예방, 탐지 등은 정책, 표준 및 아키텍처에 맞게 조정됩니다.

자산 보호는 자산에 대한 기술 주제 전문가 역할을 합니다. 거버넌스, 아키텍처, 보안 운영 및 워크로드 팀과 같은 다른 분야에서 함께 작동합니다. 자산 보호는 정책 및 표준이 실현 가능하도록 보장하고, 제어를 구현하여 정책 및 표준을 지원할 수 있도록 합니다. 자산 보호는 지속적인 개선을 위한 피드백을 제공합니다.

참고

자산 보호는 일반적으로 자산을 유지 관리하는 IT 운영 팀에서 구현하며 보안 팀의 전문 지식으로 보완됩니다. 자세한 내용은 컨트롤을 팀으로 디자인을 참조하세요.

위협 행위자는 영구적이며 표준 및 정책의 적용에 따른 격차로 인해 발생하는 취약성을 찾습니다. 공격자는 중요 비즈니스용 데이터 또는 애플리케이션을 직접 대상으로 지정할 수 있습니다. 또한 중요 비즈니스용 데이터 및 애플리케이션에 대한 액세스 권한을 부여하는 인프라를 대상으로 지정할 수도 있습니다. 액세스 제어는 리소스에 대한 권한 있는 액세스를 관리하는 데 중점을 둡니다. 자산 보호는 리소스에 대한 액세스 또는 제어를 얻는 다른 모든 잠재적인 대역 외 방법을 다룹니다. 이 두 분야는 서로 보완적이며 아키텍처, 정책 및 표준을 충족하도록 함께 디자인되어야 합니다. 자세한 내용은 액세스 제어를 참조하세요.

다음 비디오를 시청하여 자산 보호의 기록 및 이전 자산과 새 자산을 안전하게 유지하는 방법에 대해 알아봅니다.

보안 확보

보안 확보는 조직의 현재 보안 표준, 정책 및 아키텍처를 충족하기 위해 리소스를 가져오는 데 중점을 둡니다. 활동에는 다음 두 가지 유형이 있습니다.

• 브라운필드: 현재 보안 표준 및 제어를 기존 자산으로 개조합니다. 조직은 보안을 낮은 우선 순위로 지정하여 IT 환경을 설계하고 운영할 수 있습니다. 이 방법은 약한 보안 구성, 업그레이드되지 않은 소프트웨어, 암호화되지 않은 통신 또는 스토리지, 레거시 소프트웨어 및 프로토콜 등의 “기술적인 문제”를 파생합니다. 보안 제어를 현재 접근 방식까지 끌어올릴 수 있습니다. 공격자가 이러한 기회를 악용하는 능력을 지속적으로 향상시키기 때문에 이러한 개선은 위험을 완화하는 데 중요합니다.
• 그린필드: 새 자산 및 새 자산 유형이 표준으로 구성되었는지 확인합니다. 이 프로세스는 인스턴트 레거시 또는 브라운필드나 현재 표준을 충족하지 않는 시스템을 지속적으로 만들지 않도록 하는 데 중요합니다. 이 기술적인 문제가 나중에는 해결하는 데 더 큰 비용이 들며, 이로 인해 완료될 때까지 위험 노출이 증가합니다.

재정적으로 보안 확보는 일반적으로 일회성 투자의 자본 지출(CAPEX) 역학에 매핑됩니다. 보안에 대한 그린필드 예산은 자산 생성에 가능한 한 밀접하게 매핑되어야 하며, 각 새 소프트웨어 프로젝트, 주요 소프트웨어 업그레이드 또는 전체 클라우드 채택 이니셔티브에 대한 보안 예산의 예약된 비율을 사용해야 합니다. 많은 조직에서는 보안을 위해 예산의 약 10%를 예약합니다. 브라운필드 예산은 일반적으로 보안 제어를 현재 표준 및 규정 준수까지 끌어올리기 위해 자금이 투입되는 특별 프로젝트입니다.

보안 유지

시간이 지남에 따라 모든 것이 저하됩니다. 물리적인 항목은 마모됩니다. 환경은 소프트웨어, 보안 제어 및 보안과 같은 가상 항목을 중심으로 변경됩니다. 이러한 사항들이 변화하는 요구를 더 이상 충족하지 못할 수 있습니다. 다음과 같은 급속한 변화로 인해 오늘날 이러한 전환이 빠르게 이루어지고 있습니다.

• 디지털 트랜스포메이션을 통해 발생하는 비즈니스 요구 사항
• 신속한 클라우드 플랫폼 진화 및 기능 릴리스를 통해 발생하는 기술 요구 사항.
• 공격자 혁신 및 네이티브 클라우드 보안 기능의 급속한 발전을 통한 보안 요구 사항

이러한 동적 기능은 보안 작업, 액세스 제어, 특히 혁신 보안의 DevSecOps를 비롯한 보안의 모든 부분에 영향을 줍니다.

보안 유지에는 많은 요소가 포함됩니다. 자산 보호의 두 가지 특정 영역에 집중합니다.

• 지속적인 클라우드 개선: 클라우드에서 제공하는 보안 기능의 지속적인 개선을 수용합니다. 예를 들어, Azure Storage 및 Azure SQL Database와 같은 Azure의 많은 서비스는 시간이 지남에 따라 공격자를 방어하는 보안 기능을 추가했습니다.
• 소프트웨어 수명 종료: 운영 체제를 포함한 모든 소프트웨어는 보안 업데이트가 더 이상 제공되지 않는 경우 항상 수명이 종료됩니다. 이러한 상황은 비즈니스에 중요한 데이터와 애플리케이션을 저렴하고 쉬운 공격에 노출시킬 수 있습니다. SaaS(Software as a Service), 클라우드 인프라 및 플랫폼은 클라우드 공급자가 유지 관리하지만, 기업은 종종 설치, 작성 및 유지 관리해야 하는 상당한 양의 소프트웨어를 보유하고 있습니다.

수명이 종료된 소프트웨어를 업그레이드하거나 사용 중지할 계획입니다. 보안 상태에 투자하면 주요 보안 인시던트가 발생할 위험이 줄어듭니다. 보안 유지는 정기적이고 지속적인 투자의 OPEX(운영 지출) 역학의 일부입니다.

패치 딜레마

비즈니스 리더는 IT 및 보안 리더와 팀을 지원하는 것이 중요합니다. 적대적인 환경에서 복잡한 소프트웨어를 실행하려면 내재된 위험이 있습니다. 보안 및 IT 리더는 운영 위험 및 보안 위험에 대해 지속적으로 어려운 결정을 내립니다.

• 운영 위험: 시스템이 실행되는 소프트웨어의 변경으로 인해 비즈니스 프로세스가 중단될 수 있습니다. 이러한 변경 내용은 시스템을 조직에 맞게 사용자 지정할 때 수행한 가정에 영향을 줍니다. 이 사실 때문에 시스템을 변경하지 않아야 하는 것입니다.
• 보안 위험: 공격으로 비즈니스 가동 중지 시간이 발생할 위험이 있습니다. 공격자는 릴리스 시 모든 주요 보안 업데이트를 분석합니다. 보안 업데이트를 적용하지 않은 조직을 공격하기 위해 24~48시간 후에 작업 익스플로잇을 개발할 수 있습니다.

조직에는 기술의 지속적인 변화와 공격 기술의 진화로 인해 이러한 딜레마가 자주 발생할 수 있습니다. 비즈니스 리더는 복잡한 소프트웨어를 사용하여 비즈니스를 운영할 때의 위험을 인식해야 합니다. 다음 예제와 같은 비즈니스 프로세스 업데이트를 지원합니다.

• 소프트웨어 유지 관리를 비즈니스 운영 가정, 일정, 예측 및 기타 비즈니스 프로세스에 통합합니다.
• 유지 관리를 더 쉽게 만들고 비즈니스 운영에 미치는 영향을 줄이는 아키텍처에 투자합니다. 이 방법은 클라우드 서비스 또는 서비스 지향 아키텍처로 마이그레이션하여 기존 아키텍처를 업데이트하거나 새 아키텍처로 완전히 전환하는 것을 포함할 수 있습니다.

비즈니스 리더십 지원이 없으면 보안 및 IT 리더가 중요한 비즈니스 목표를 지원하는 데 방해가 됩니다. 그들은 승자 없는 정치 상황을 지속적으로 관리해야 합니다.

네트워크 격리

네트워크 격리는 더 이상 보호할 수 없지만 즉시 사용 중지할 수 없는 이전 자산을 보호하기 위한 유효한 옵션일 수 있습니다. 이 시나리오는 일반적으로 수명 종료 운영 체제 및 애플리케이션에 대해 발생할 수 있습니다. OT(운영 기술) 환경 및 레거시 시스템에서 일반적입니다.

보호할 수 없는 자산이 자산 보호의 일부로 식별되더라도 격리 자체는 액세스 제어로 간주됩니다. 자세한 내용은 방화벽을 피하고 잊어버리기를 참조하세요.

수명이 끝날 때 일부 시스템은 연결을 끊고 완전히 격리하기가 어렵습니다. 이러한 안전하지 않은 시스템은 프로덕션 네트워크에 완전히 연결되지 않는 것이 좋습니다. 이 구성을 통해 공격자는 시스템을 손상시키고 조직의 자산에 액세스할 수 있습니다.

10년 이상 잘 작동해 온 컴퓨터 기술을 업그레이드하거나 교체하는 것은 결코 저렴하거나 쉽지 않습니다. 해당 기능에 대한 설명서는 제한될 수 있습니다. 여러 중요 비즈니스 자산에 대한 제어권을 상실할 경우 비즈니스에 미치는 잠재적 영향은 종종 업그레이드 또는 교체 비용을 초과합니다. 격리할 수 없는 이러한 자산의 경우 조직은 클라우드 기술 및 분석으로 워크로드를 현대화하여 업그레이드 또는 교체 비용을 상쇄하거나 정당화할 수 있는 새로운 비즈니스 가치를 창출할 수 있다는 것을 종종 알게 됩니다.

보안을 유지하는 것은 끊임없이 변화하는 세상에서는 어려운 문제입니다. 현대화할 자산과 최대한 보호할 자산을 지속적으로 결정하는 것이 중요합니다. 비즈니스 위험 및 비즈니스 우선 순위를 사용하여 평가합니다.

시작

자산 보호를 시작하려면 조직에서 다음 단계를 수행하는 것이 좋습니다.

• 잘 알려진 리소스 우선 집중: 팀이 이미 잘 알고 있는 클라우드의 가상 머신, 네트워크 및 ID를 생각해 보세요. 이 기술을 사용하면 즉시 발전을 이룰 수 있으며 클라우드용 Microsoft Defender와 같은 네이티브 클라우드 도구를 사용하여 관리 및 보안 목표를 보다 쉽게 달성할 수 있습니다.

• 공급업체/업계 기준에서 시작: 다음과 같은 잘 알려진 검증된 솔루션을 사용하여 보안 구성을 시작합니다.

  • Azure Security Benchmark의 보안 기준. Microsoft는 개별 Azure 서비스에 맞게 조정된 보안 구성 지침을 제공합니다. 이러한 기준은 각 서비스의 고유한 특성에 Azure 보안 벤치마크를 적용합니다. 이 방법을 사용하면 보안 팀이 각 서비스를 보호하고 필요에 따라 구성을 구체화할 수 있습니다. 자세한 내용은 Azure에 대한 보안 기준을 참조하세요.
  • Microsoft 보안 기준. Microsoft는 Windows, Microsoft Office 및 Microsoft Edge를 포함하여 일반적으로 사용되는 기술에 대한 보안 구성 지침을 제공합니다. 자세한 내용은 Microsoft 보안 기준.Microsoft-security-baselines)을 참조하세요.
  • CIS 벤치마크. CIS(인터넷 보안 센터)는 많은 제품 및 공급업체에 대한 특정 구성 지침을 제공합니다. 자세한 내용은 CIS 벤치마크를 참조하세요.

주요 정보

이러한 핵심 요소는 자산 보호 프로세스를 안내하는 데 도움이 됩니다.

책임을 맡은 팀

보안에 대한 책임은 항상 다른 모든 위험과 혜택을 소유하는 비즈니스의 궁극적인 리소스 소유자에게 있어야 합니다. 보안 팀과 주제 전문가는 책임 있는 소유자에게 위험, 완화 및 실제 구현 수행에 대해 조언을 제공할 책임이 있습니다.

자산 보호 책임은 엔터프라이즈 차원의 자산을 관리하는 IT 운영 팀, 워크로드 자산을 담당하는 DevOps 및 DevSecOps 팀, IT 또는 DevOps 및 DevSecOps 팀과 함께 작업하는 보안 팀이 수행할 수 있습니다.

조직이 클라우드로 이동함에 따라 이러한 책임 중 많은 부분(예: 펌웨어 및 가상화 솔루션 업데이트)이 클라우드 공급자로 이전하거나 보안 구성 검사 및 수정 등이 더 쉬워질 수 있습니다.

공유 책임 모델에 대한 자세한 내용은 클라우드의 공유 책임을 참조하세요.

클라우드 탄력성

온-프레미스 리소스와 달리 클라우드 리소스는 짧은 시간 동안만 존재할 수 있습니다. 필요에 따라 워크로드는 작업을 수행하기 위해 더 많은 서버, Azure Functions 및 기타 리소스의 인스턴스를 만들 수 있습니다. Azure는 나중에 리소스를 제거합니다. 이 시나리오는 몇 달 내에 발생할 수 있지만 때로는 몇 분 또는 몇 시간 내에 발생할 수 있습니다. 자산 보호 프로세스 및 측정에서 이러한 가능성을 고려합니다.

클라우드 탄력성을 위해서는 많은 프로세스를 조정해야 합니다. 정적 보고서 대신 주문형 인벤토리를 사용하여 가시성을 향상시킵니다. 클라우드 탄력성은 문제를 해결하는 기능도 향상시킵니다. 예를 들어 보안상의 이유로 새 가상 머신을 빌드하는 작업이 빠르게 진행될 수 있습니다.

예외 관리

자산에 대한 모범 사례를 식별한 후에는 자산의 모든 인스턴스에 일관되게 적용합니다. 임시 예외를 만들어야 하지만 특정 만료 날짜가 있는 예외를 관리해야 할 수도 있습니다. 임시 예외가 영구적인 비즈니스 위험이 되지 않도록 합니다.

값 측정과 관련된 문제

자산 보호의 비즈니스 가치를 측정하기 어려울 수 있습니다. 문제의 영향은 실제 오류가 발생할 때까지 명확하지 않습니다. 취약성에 대한 보안이 업데이트되지 않을 위험은 조용하게 찾아오며 보이지 않습니다.

자동화된 정책 선호

자산 보호를 위해 Azure Policy와 같은 자동화된 적용 및 수정 메커니즘을 선호합니다. 이 방법은 수동 작업을 반복적으로 수행하여 비용 및 의욕 저하 문제를 피하도록 도와줍니다. 또한 사람의 실수로 인한 위험도 줄여줍니다.

Azure Policy를 사용하면 중앙 팀이 클라우드 전체의 자산에 사용할 구성을 지정할 수 있습니다.

컨트롤을 팀으로 디자인

모든 컨트롤은 주요 관련자와의 파트너 관계로 디자인해야 합니다.

• 자산 보호는 자산에 대한 실무 전문 지식, 사용 가능한 컨트롤 및 컨트롤 구현의 타당성을 제공합니다.
• 거버넌스 팀은 컨트롤이 보안 아키텍처, 정책 및 표준, 규정 준수 요구 사항에 어떻게 부합하는지에 대한 컨텍스트를 제공합니다.
• 보안 작업은 탐지 컨트롤에 대한 지침을 제공합니다. 경고 및 로그를 보안 운영 도구, 프로세스 및 학습에 통합합니다.
• 공급업체 및 클라우드 공급자는 시스템 및 구성 요소에 대한 심층적인 실무 전문 지식을 제공하여 고객 기반에서 알려진 문제를 방지할 수 있습니다.

다음 단계

검토할 다음 분야는 보안 거버넌스입니다.