제로 트러스트 보안: 제로 트러스트가 중요한 이유(접근 이상의 이유로)

지난 몇 년 동안 네트워크 및 애플리케이션 액세스의 주요 주제 중 하나는 "제로 트러스트"라는 개념이었습니다.  이 논문에서는 제로 트러스트가 핵심적으로 액세스뿐만 아니라 사이버 보안 공간 전반에 걸쳐 보다 광범위하게 적용될 수 있는 간단한 신념의 작은 집합으로 특징지어질 수 있는 방법을 보여줍니다. 

이 논문은 오늘날 애플리케이션 보안 비즈니스 리더에게 동기를 부여하는 기존 비즈니스 배경과 관련하여 제로 트러스트 주변의 광범위한 개념을 포괄하는 프레임워크를 제시합니다.  마지막으로, 이 논문은 현재 및 새로운 위협을 해결하는 도구와 보안 구현의 원동력인 제로 트러스트 신념 체계의 특성을 설명합니다. 이는 후속 논문의 초점이 될 것입니다.

본 논문의 목표는 두 가지입니다. 첫째, 애플리케이션 비즈니스 리더가 받아들여야 할 보안 사고방식을 전달하고, 둘째, 향후 백서에서 확장할 보안 실무자를 위한 프레임워크를 소개하는 것입니다. 

"제로 트러스트"라는 용어는 다양한 추상화 계층에서 여러 가지 개념과 연관됩니다. 때로는 특정 솔루션 아키텍처로, 때로는 특정 기술을 적용하기 위한 처방으로, 때로는 제품의 속성을 나타낼 때도 있습니다.  우리는 제로 트러스트 보안이 근본적으로 기술과 전술이 출현하고 특정 기술을 활용하여 광범위한 보안 위협을 해결하는 데 적용될 수 있는 사고방식, 즉 신념 체계라고 믿습니다.

제로 트러스트 보안(ZTS)의 기반이 되는 신념 체계는 수년 전 "심층 방어"로 시작된 보안 사고방식 진화의 다음 단계로 볼 수 있습니다.  심층 방어는 단일 방어막으로는 침해 가능성이 적지만 실제로 발생할 수 있다는 믿음에 근거하며, 주요 자산에 대한 보호 계층을 강화하면 그 가능성이 줄어들고 공격자의 속도가 느려지는 동시에 성공적인 공격을 위해 더 많은 리소스를 사용해야 한다는 것입니다.

제로 트러스트는 세 가지 측면에서 이러한 사고방식을 성숙시킨 것입니다.

• 첫째, 보호의 전제가 애플리케이션에 대한 액세스를 제어하는 단순한 "필터" 세트에서 모든 시스템 트랜잭션에 상황에 맞게 적용되는 보다 자산에 적합한 보호 세트로 발전합니다 .  각 거래의 사고방식은 다음을 이해하는 것입니다.  누가 누구 에게 어떤 행동을 시도하는가.  "누구"와 "누구"는 시스템 내부의 구성 요소이거나 시스템을 사용하는 모든 구성 요소일 수 있으며, 여기에는 인간, 자동화 또는 코드 조각이 포함될 수 있습니다.  신원이라는 개념은 누구 와 누구를 지칭하는 데 중요하며, 신원에 부여된 특권이라는 개념은 무엇을 할 수 있는지를 체계화하는 데 사용됩니다.
• 두 번째로, 보안 결정 평가를 정적이고 절대적인 것으로 여기지 않고 보다 동적이고 적응적인 것으로 간주하여 관찰된 행동에 비추어 지속적으로 재평가합니다.  각 거래의 처리에 대한 결정(상호 작용을 허용할지, 차단할지, 추가적인 신뢰를 구축할지 등)은 더 광범위한 비즈니스 맥락, 특히 위험 대 보상의 균형을 고려해야 합니다.
• 마지막으로, 아무리 많은 보호 계층이 제공되더라도 충분히 동기가 부여되었거나 운이 좋은 적은 보호 장치를 위반하거나 우회할 것이라는 것은 당연한 사실입니다. 따라서 모든 침해를 시기적절하게 탐지하고 악용 시도를 완화하는 것 역시 전반적인 전략의 핵심 부분이 되어야 합니다.

이러한 진화는 부분적으로 시간과 경험의 결과였지만 점점 더 두 가지 다른 애플리케이션 보안 추세의 합류로 인해 주도되고 있습니다.  특히 오늘날의 애플리케이션 아키텍처는 훨씬 더 큰 잠재적 애플리케이션 취약성 공간을 열어두고 있습니다. 특히 애플리케이션 인프라 "내부"에서 발생하는 위협이 그렇습니다. 이러한 취약성은 오늘날의 적대자들의 정교함이 높아짐에 따라 악용될 수 있습니다.  다행히도 보안 도구의 동시적 발전, 특히 이를 현대의 데이터 수집 및 분석 기능과 함께 사용하면 방어 전략의 핵심 구성 요소를 실질적으로 구현할 수 있게 되었습니다.

본 소개의 나머지 부분에서는 제로 트러스트 보안에 대한 접근 방식의 프레임워크와 범위에 대한 개요를 제시합니다.  여기에서 다음 섹션에서는 문제 진술과 제로 트러스트에 대한 다른 현대적 접근 방식과의 관계를 확장하여 솔루션 기술과 그 적용을 선택하는 데 지침이 되는 핵심 신념, 즉 "이유"에 대한 논의로 이어집니다.  향후 논문에서는 인증, 액세스 제어, AI 지원 분석과 같은 특정 기술에 대한 요구 사항인 "방법"을 자세히 살펴보고, 이것이 제로 트러스트 성숙도 모델과 관련이 있는지 알아볼 것입니다.

Simon Sinek의 "Start with Why" 접근 방식은 아래 그림 1에서 볼 수 있듯이 ZTS 프레임워크를 전달하는 효과적인 도구입니다.  이 그래픽을 외부에서 내부로 볼 수 있습니다. 먼저 ZTS가 해결하는 위협 클래스부터 시작하여 사용된 보안 방법을 자세히 살펴보고 마지막으로 모든 것을 공통 원칙으로 정리합니다.  아니면, 내부에서 외부로의 관점을 살펴볼 수도 있습니다. 핵심 신념을 북극성으로 삼고, 이를 바탕으로 적절한 도구와 기술을 찾아내고, 이를 통해 광범위한 위협에 대처하는 능력을 키울 수 있습니다.

그림 1 -- 제로 트러스트 보안: 신념 체계, 도구 및 이점.

이후 섹션에서는 이 다이어그램의 각 동심원 층을 자세히 살펴보겠지만 간략하게 설명하면 다음과 같습니다.

• 접근 방식의 핵심 신념은 다음과 같은 사용 사례의 프레이밍에서 비롯됩니다.
  “누가 누구에게 무엇을(행동) 시도하고 있는가?”
  • Who 와 Whom을 확립하려면 모든 신원 증명을 명확하게 검증하세요 .
  • Who를 설정한 후 최소 권한의 원칙을 사용하여 수행할 수 있는 작업을 제한합니다.
  • Who, What, Whom 의 세 가지 요소를 지속적으로 평가하고 재평가하며 정책 제약에 대해 계속 검증합니다.
  • 항상 침해와 손상이 발생할 것이라고 가정하세요 . 인증 사기 발생 가능성(잘못된 거래 승인으로 인한 비즈니스 영향에 따른 가중치 적용)을 기반으로 한 위험 대비 보상 분석( 무엇을 누구 에게)에 따라 수행되는 작업(무엇을 누구에게)이 사전 결정된 허용 가능한 안전 임계값을 초과할 경우 개입할 준비를 하세요.
• 사용된 방법은 다음과 같습니다.
  • 특정 신뢰 수준에서 Who를 결정하고, 특정 Whom 대상과 관련하여 해당 ID에 허용해야 하는 What(작업) 에 대한 권한을 제한하기 위한 인증 및 액세스 제어입니다 .
  • 각 거래의 전체 맥락을 관찰하고 지속적으로 평가하기 위한 가시성 과 ML 지원 분석 - 누가 누구에게 무엇을 했는지 .
  • 거래에 개입하기 위한 자동화된 위험 인식 수정 위험-보상 수준이 지정된 허용 한계값을 넘어설 때.
• 다음 방법을 적용하여 광범위한 사이버 공격에 대처하세요 .
  • 훼손 이나 데이터 유출과 같은 기존 공격 – 다음을 처리할 수 있습니다. 인증 및 액세스 제어 기술을 사용하여 정책에 따라 누가 무엇을 할 수 있는지 제한함으로써 신원 침해 또는 권한 상승을 탐지하여 이러한 공격을 차단합니다.
  • 가용성/DDoS 공격 -- 인증 및 액세스 제어를 위험 인식형 대책과 결합하여 이러한 공격에 대처합니다.  예를 들어, 인증되지 않았거나 인증이 부족한 행위자가 리소스를 많이 소모하는 거래를 시도하는 경우 해당 행위자의 액세스를 차단(또는 속도 제한)할 수 있습니다.
  • 랜섬웨어 나 공급망 공격과 같은 지능형 위협 - 누가 누구 에게 무엇을 하는지에 대한 동작의 변화와 이상을 감지하고 위험 인식적 대책을 결합하여 이러한 위협에 대처할 수 있습니다.

제로 트러스트 보안은 전체 애플리케이션, 인프라 및 제공 스택에 걸쳐 포괄적으로 확장되어야 하며 전체 개발 파이프라인을 포괄해야 합니다. 보다 구체적으로 여기에는 다음이 포함되어야 합니다.

• "상단부터 하단까지" 완전한 애플리케이션 및 인프라 스택
  • 서버, 네트워크 인터페이스 카드, 코프로세서, 시스템 보드 구성 요소를 포함한 하드웨어 컴퓨팅 기판
  • 하드웨어를 위한 하위 계층 펌웨어와 BIOS.
  • 하이퍼바이저나 런타임 익스큐티브와 같은 가장 낮은 계층의 운영 체제입니다.
  • 애플리케이션 수준/컨테이너 운영 체제 .
  • 상용 또는 오픈 소스인 타사 애플리케이션 구성요소를 가져옵니다.
  • 자체적으로 개발하거나 맞춤형으로 제작한 응용 소프트웨어입니다.
• 전체 "왼쪽에서 오른쪽으로" 애플리케이션 제공 스택
  • 각 "상단에서 하단까지" 스택 요소의 지속적인 유지 관리 및 업그레이드에 사용되는 공급망입니다.
  • 방화벽, 로드 밸런서, API 게이트웨이, 수신/송신/메시 컨트롤러, 인라인 사기 완화 장치 등 인라인 애플리케이션 제공 구성 요소입니다.
  • DNS(도메인 이름 시스템) 확인자와 같이 트래픽 처리에 간접적으로 영향을 미치는 모든 애플리케이션 제공 구성 요소나 SIEM(보안 정보 이벤트 관리) 솔루션 또는 연합 ID 서비스와 같이 간접적으로 메타데이터를 수신하는 모든 애플리케이션 제공 구성 요소입니다.

전통적으로, 제로 트러스트의 초점은 애플리케이션 개발 및 제공 팀에 맞춰져 왔으며, 이는 종종 Dev, DevOps, DevSecOps 및 SRE라는 페르소나로 표현됩니다.  우리가 이 점을 지적하는 이유는 더 큰 그림을 파악하기 위해서입니다. 즉, 제로 트러스트에 대한 포괄적인 접근 방식에는 이상적으로 비전통적인 페르소나와 인프라는 물론, 공급망 조달 전략과 같은 추가 워크플로도 포함되어야 합니다.

CIO와 CISO의 최우선 과제 중 하나는 비즈니스를 가속화하기 위해 정보 기술을 현대화하는 것입니다.  그들은 또한 기업 리스크 거버넌스에서 핵심적인 역할을 합니다.  그들의 목표는 기업이 새로운 디지털 경험으로 고객을 기쁘게 하고, 타사와의 디지털 연결을 통해 운영 효율성을 높이고, 직원들이 어디에서나 생산성을 발휘할 수 있도록 하는 동시에 비즈니스 위험을 최소화하는 것입니다. 이를 위해 CIO와 CISO 조직은 직원들이 민첩성을 위해 최신 기술, 아키텍처 및 모범 사례를 사용할 수 있도록 해야 하며, 동시에 동일한 직원에게 적절한 보안 조치를 취하고 사람들의 행동, 액세스하는 정보 및 손실 노출을 방지하기 위해 사용하는 기술에 대한 통제를 확립하도록 해야 합니다. 

조직에서는 시장 및 거시경제 상황의 변화, 소비자 행동, 공급망 및 보안 노출과 관련된 위험을 이해하고 통제해야 합니다.  위험을 정확하게 평가하고 신속하게 완화 조치를 취할 수 있는 능력은 기업에 경쟁 우위를 제공합니다.  본 논문에서는 보안 노출 위험에 초점을 맞추고 있습니다. 보안 노출 위험은 지적 재산 손실, 비즈니스 프로세스 중단, 개인 식별 정보 손실, 규제 기관의 벌금 등을 일으킬 수 있습니다.  보안 위험은 고려 중인 상황의 다음 측면을 평가하여 계산할 수 있습니다.

1. 관련 자산의 가치
   거래에 관련된 자산에는 서로 다른 중요도가 있습니다. 예를 들어, 개인 식별 정보로 구성된 데이터베이스는 기업이 만든 제품을 판매하는 소매점을 나열한 데이터베이스보다 더 가치가 있습니다.  보안 및 IT 팀은 모든 자산의 인벤토리를 생성하기 위해 결정론적 프로세스를 사용할 수 있으며, 자산의 "가치"를 나타내는 점수로 분류할 수 있습니다.


2. 타협의 영향
   손상의 성격에 따라 손상에 따른 영향이 결정됩니다.  예를 들어, 개인 식별 정보가 포함된 데이터 저장소의 정보가 은폐되는 경우의 영향은 데이터 저장소의 가용성이 중단되는 경우보다 훨씬 큽니다.  다소 모호하기는 하지만 다양한 유형의 타협을 나열하고 이에 "영향" 점수를 할당하는 것이 가능합니다.


3. 타협 가능성
   거래로 인해 자산이 손상될 가능성은 해당 거래와 관련된 위험을 평가하는 데 있어 가장 불확정적인 요소입니다.  인간은 필요한 관찰 규모를 처리할 수 없으므로 조직에서는 기계 학습과 인공 지능을 사용하여 손상 가능성을 계산하는 데 있어 신뢰도를 높입니다.

지금의 과제는 모든 거래와 관련된 위험을 거의 실시간으로 계산하고, 잠재적인 침해의 영향을 통제하기 위한 적절한 완화 조치를 취하는 것입니다.

그림 2 - 비즈니스 압박으로 인해 새로운 관행이 생겨나고 이로 인해 위험이 증가합니다.

1. 사업 가속화 요구
   1. 디지털 경험
      소비자들은 디지털 경험에 대한 끝없는 욕구를 가지고 있으며, 다양한 플랫폼(PC, 태블릿, 휴대폰)에서 빈번한 개선을 요구합니다.
   2. 연결된 비즈니스
      디지털 비즈니스 프로세스에는 다른 기업이 제공하는 파트너, 공급업체, 유통업체 및 서비스와의 연결이 필요합니다.
   3. 모바일 인력
      직원은 실행 효율성을 위해 어디에서나 비즈니스 애플리케이션에 액세스할 수 있어야 합니다.


2. 비즈니스 요구 사항을 충족하기 위한 관행
   1. 애자일 개발 방법론
      기업들은 시기적절한 프로젝트 제공에 초점을 맞춘 순차적 폭포수 방식 대신, 고객 만족에 중점을 둔 점진적이고 반복적인 Agile 개발 방식으로 전환했습니다.
   2. 기성 소프트웨어 사용
      가능한 한 빠르게 새로운 디지털 경험을 제공하기 위해 개발자들은 업계 동료들이 오픈 소스로 공개한 코드를 재사용합니다.
   3. 계약 개발
      계약 개발자에게 업무를 아웃소싱하면 기업은 수요에 맞게 인력을 확장할 수 있습니다.
   4. 클라우드 인프라 활용
      클라우드의 민첩성, 유연성, 확장성과 사용 편의성 덕분에 개발자는 필요한 인프라를 필요에 따라 확보할 수 있습니다.
   5. SaaS 도입
      SaaS(Software as a Service)는 개인 데이터 센터에서 이러한 애플리케이션을 조달, 배포, 유지 관리하는 데 따르는 부담을 상당히 줄여주기 때문에 비즈니스 운영 애플리케이션에 유리합니다.
   6. 마이크로서비스 아키텍처
      팀은 마이크로서비스를 사용하여 지속적인 제공과 시장 출시 시간을 단축합니다.
   7. 분산 애플리케이션 구성 요소
      조직은 서비스의 기능을 개발하거나 제공하기 위한 최고의 도구를 제공하는 인프라에서 마이크로서비스를 실행하여 효율성을 달성합니다. 최근 레거시 워크플로우의 확장은 레거시 요소와 통신해야 하는 최신 애플리케이션 아키텍처를 사용하여 이루어지며, 둘은 종종 서로 다른 인프라에서 실행됩니다.
   8. 오픈 API
      다양한 서비스로 구성된 생태계는 기업이 모든 서비스를 자체적으로 개발하는 것보다 더 효율적입니다.
   9. 제3자와의 네트워크 연결
      기업은 암호화된 터널을 사용하여 파트너, 공급업체, 유통업체와 연결하여 비즈니스 프로세스를 자동화하고 간소화합니다.


3. 강화된 보안 위험
   1. 공격 표면 증가
      타사 소프트웨어와 오픈소스 라이브러리를 사용하면 공급망 공격의 기회가 생기고, 외부에서 개발된 소프트웨어의 모든 취약점이 상속됩니다.  계약 개발자는 기능적 기능을 제때 완료하는 데 동기를 부여받으며, 보안은 그들에게 중요하지 않습니다.  게다가 소프트웨어를 전달하고 프로젝트를 종료한 후에는 내부 팀이 코드를 검토하여 보안 취약점을 찾는 것이 어렵고 시간이 많이 걸립니다. 애자일 스프린트는 기능을 제공하는 데 매우 효율적이지만 개발 속도가 증가하면서 세부적인 보안 감사와 테스트를 위한 시간이 많이 남지 않습니다.  다른 마이크로서비스와 통신할 수 있는 취약한 마이크로서비스 하나가 있으면 전체 시스템의 보안 위험이 커집니다.

      상호 연결된 기업이 운영 효율성을 개선하더라도 심각한 결과는 이들 중 하나에서 발생하는 보안 허점이 다른 기업에도 영향을 미친다는 것입니다.  공격자는 가장 약한 연결 고리를 찾아 나머지를 통해 공격을 확산시킵니다. SaaS 플랫폼이나 클라우드 인프라의 취약성이나 보안 허점은 추가적인 공격 벡터가 되고, 공동 책임 모델은 조기 감지 및 해결을 복잡하게 만들 수 있습니다.

   2. 건축적 복잡성 증가
      다양한 아키텍처를 사용하여 개발되고 여러 인프라에 배포되는 분산 애플리케이션 요소는 보안 및 규정 준수 요구 사항이 다릅니다.  이로 인해 보안팀이 기업 애플리케이션과 데이터를 보호하고 규정 준수 요구 사항을 충족하는 데 적합한 메커니즘을 설계하고 배포하는 것이 복잡해집니다.
      
   3. 자금이 풍부하고, 동기 부여가 높으며, 기술이 뛰어난 해커
      2010년의 오로라 작전부터 2020년의 솔라게이트까지, 우리는 심각한 피해를 입힌 후에야 발견되는 첨단 사이버 공격을 10년 동안 경험해 왔습니다.  침해는 최고의 보안 기술을 갖추고 고도로 훈련된 보안팀이 운영하는 조직에서 발생했습니다.  공격자는 감지되기 전까지 오랫동안 이런 조직의 IT 인프라에 숨어 있었습니다.  지적 재산이 도난당하고, 개인 식별 정보가 도난당하고, 사업 운영이 중단되고, 조직이 랜섬웨어에 인질로 잡힌 가운데, IT 및 보안 팀은 사이버 공격을 막기 위해 고안된 규정을 준수하기 위해 최선을 다하고 있습니다.

미국의 연방, 주, 지방 정부 기관과 몇몇 미국 기업을 대상으로 끊임없이 사이버 공격이 가해진 후, 조 바이든 대통령은 2021년 5월 12일 국가의 사이버 보안을 개선하기 위한 행정 명령을 발표했습니다.  이 명령의 핵심 요소 중 하나는 정부 기관이 사이버 공격에 대비하기 위해 제로 트러스트 원칙을 활용해야 한다는 것입니다. 바이든 행정부는 이 명령에 따라 2022년 1월 26일 행정부 및 기관의 수장에게 관리예산국(OMB)의 각서를 보냈습니다.  OMB의 이 각서는 "연방 제로 트러스트 아키텍처(ZTA) 전략을 제시하여 기관이 2024 회계연도(FY) 말까지 특정 사이버 보안 표준과 목표를 충족하도록 요구하여 점점 더 정교해지고 지속되는 위협 캠페인에 대한 정부의 방어력을 강화합니다."¹  행정 명령과 OMB 각서는 모두 2020년 8월에 발표된 미국 국립표준기술원(NIST) 간행물 SP 800-207 에 설명된 제로 트러스트 아키텍처를 언급하며, 정부 기관이 이를 따를 것을 요구합니다.

정부 기관과 민간 부문의 사상적 리더들은 제로 트러스트 아키텍처를 설명하고 이를 도입하는 가장 좋은 방법에 대한 조언을 제공하는 논문을 발표했습니다. 이 논문에 담긴 아이디어를 아래에 요약했습니다. 이 논문에 담긴 아이디어와 제안의 중요한 본질은 모든 거래를 검토하여 누가 누구 를 대상으로 어떤 행동을 시도하는지 평가하고, 이와 관련된 위험을 계산하여 거래를 허용할지 거부할지 실시간으로 결정을 내리는 것입니다.

NIST 팀은 NIST SP 800-207 논문에서 제로 트러스트 원칙을 열거하고 추상적인 제로 트러스트 아키텍처(ZTA)를 정의합니다.² 또한, 그들은 다양한 제로 트러스트 접근 방식을 논의하고 추상 아키텍처를 배포하는 다양한 방법을 설명합니다.

이 논문에서 논의되는 주요 추상화는 서로 연계되어 작동하는 정책 결정 지점(PDP)과 정책 시행 지점(PEP)입니다.  정책 결정 지점은 정책 엔진(PE)과 정책 관리자(PA)로 구성됩니다.  정책 엔진은 신뢰 알고리즘을 사용하여 주체에게 리소스에 대한 액세스를 부여해야 하는지 여부를 결정합니다.  이러한 결정은 정책 관리자가 실행하며, 정책 시행 지점과 통신하여 새 세션을 허용하거나 거부하고 기존 세션을 수정하거나 종료합니다. 또한 이 논문에서는 신뢰 알고리즘의 변형, 제로 트러스트 환경을 위한 네트워크 구성 요소, 다양한 사용 사례 또는 배포 시나리오에 대해 설명합니다.  마지막으로, 공격자가 제로 트러스트 아키텍처를 방해할 수 있는 방법을 고려해야 하며, 구현자는 위협을 주의 깊게 살피고 제로 트러스트 아키텍처 구성 요소를 보호하기 위한 적절한 조치를 취해야 합니다.

사이버 보안 및 인프라 보안 기관(CISA)의 선도적 사상가들은 기관들이 제로 트러스트 계획을 개발하도록 돕는 목표로 제로 트러스트 성숙도 모델을 발표했습니다.³  이 작업은 NIST SP 800-207 논문에 설명된 추상적인 제로 트러스트 아키텍처를 기반으로 합니다.  저자들은 5개 영역을 식별하고 조직이 각 영역에서 제로 트러스트 원칙을 따르는 데 있어 일관된 진전을 이루어야 한다고 권고했습니다.  해당 영역은 (i) ID, (ii) 장치, (iii) 네트워크, (iv) 애플리케이션 워크로드, (v) 데이터입니다.  그들은 5가지 영역 각각에서 가시성과 분석, 자동화와 오케스트레이션을 활용할 것을 권고했습니다.

이 문서에서는 앞서 식별한 제로 트러스트의 5가지 기본 기둥에 대한 고수준 성숙도 모델을 제시한 다음 각 영역을 더욱 심층적으로 살펴봅니다.  조직에서는 성숙도 모델을 사용하여 현재 상태를 파악하고 최적의 상태로 나아가기 위한 반복적 과정을 설정할 수 있습니다.

Solar Winds 공격이 발견된 후, 국가안보국(NSA)은 "Zero Trust 보안 모델 도입"이라는 논문에서 사이버보안 팀에 Zero Trust 보안 모델을 도입하도록 조언하는 지침을 발표했습니다.⁴  국방정보시스템국(DISA)과 국가안보국 제로 트러스트 엔지니어링 팀의 전문가들이 국방부(DOD) 제로 트러스트 참조 아키텍처를 작성했습니다.⁵  저자는 다음과 같은 진술을 통해 제로 트러스트 도입의 필요성을 표현합니다. "DOD 내부 및 외부의 데이터 침해로 인해 노출된 취약성은 정보에 입각한 위험 기반 의사 결정을 용이하게 하는 새롭고 더욱 강력한 사이버 보안 모델이 필요하다는 것을 보여줍니다."⁶

이 참조 아키텍처는 NIST SP 800-207 제로 트러스트 아키텍처 문서에 정의된 추상화를 기반으로 권장 사항을 제시합니다.  이 문서에서는 상위 수준의 운영 모델을 제시하고 해당 요소를 자세히 설명합니다.  여기에는 높은 수준의 성숙도 모델과 다양한 관심 분야에 제로 트러스트 원칙을 적용하기 위한 역량 매핑도 포함됩니다.  이러한 문서는 조직이 현재 상태를 평가하고 계획을 수립하는 데 도움이 됩니다.

"위반을 가정"하는 태도를 갖고 제로 트러스트 원칙을 따르면 조직의 위험 관리 및 거버넌스 관행에 도움이 될 수 있습니다.  거래에 참여하는 행위자에 대한 "지속적인 모니터링" 및 "명시적 검증"의 제로 트러스트 원칙을 통해 조직은 모든 행위자와 그들의 활동에 대한 동적 위험 점수를 구축할 수 있습니다. 이는 기존 보안 프로그램을 개선하기 위해 "지속적인 적응형 위험 및 신뢰 평가"(CARTA) 방법론을 사용하라는 Gartner의 권장 사항과 일치합니다.  리소스에 대한 최소 권한 액세스만 허용하는 원칙을 채택하면 침해가 발생한 후에도 손실 위험이 줄어듭니다.  지속적인 모니터링과 명확한 검증을 통해 생성된 정보는 규정 준수 보고서를 생성하는 데에도 유용합니다.

이 섹션에서는 기업이 제로 트러스트 보안을 위해 도입해야 할 도구와 디자인에 대한 전략과 의사 결정을 뒷받침하는 사고방식(신념 체계, "이유")에 초점을 맞추고자 합니다.  사실, 오늘날의 제로 트러스트 솔루션에서 사용하는 모든 방법과 구성 요소 기술의 원동력은 4가지 간단한 핵심 원칙으로 요약할 수 있습니다.  이 섹션은 이러한 원칙을 나열하는 것으로 시작하고, 이어서 이러한 원칙을 애플리케이션 개발 라이프사이클의 더 넓은 맥락에서 어떻게 적용할 수 있는지에 대한 논의가 이어집니다. 즉, 이러한 원칙을 설계 단계에서부터 고려하는 방법과 애플리케이션의 배포/런타임에서 운영상으로 고려하는 방법을 설명합니다.

제로 트러스트 솔루션을 근본적으로 시스템 상호 작용에 대한 신뢰 구축으로 이해한다면 - " 누가 누구 에게 무엇을 하고 있는가?" - 상호 작용에 적합한 수준의 신뢰를 구축하는 것은 네 가지 구성 요소로 나눌 수 있습니다.

이름에서 알 수 있듯이, 제로 트러스트 사고방식은 "맹목적으로 신뢰하지 말고, 항상 확인하세요"라는 것입니다.  따라서 시스템 내의 모든 행위자(시스템 상호작용의 Who 및 Whom )는 다음을 수행할 수 있어야 합니다.

1. 시스템이 익명의 신원(항공사 예약 시스템의 익명 브라우저 등)에서 출처를 찾거나 익명의 신원으로 향하는 상호 작용을 허용하는 경우, "익명" 신원의 특별한 경우를 포함하여 신원을 증명합니다.  다른 모든 ID의 경우, 행위자는 시스템이 허용하는 네임스페이스에서 자신이 누구 인지 명시할 수 있어야 합니다.
2. 행위자의 증명된 신원에 대한 담보 "증거"를 수신하고 검증합니다(익명이 아닌 증명된 신원의 경우).  "증명"의 특성(암호, 인증서, 동작 등)은 다양할 수 있으며 해당 증명의 강도도 다양할 수 있지만 시스템은 증명에 대해 어느 정도의 확신을 가질 수 있어야 합니다.  간단한 시스템은 증명에 대한 신뢰도에 대해 이진법적 예/아니오 관점을 가질 수 있는 반면, 보다 진보된 시스템은 위험-보상 기반 정책의 일부로 명시적으로 참조할 수 있는 숫자형 신뢰도 점수를 가질 수 있습니다.  시스템은 또한 능동적인 도전에 대한 대응이나 행위자의 행동에 대한 수동적인 관찰과 같은 다른 수단을 통해 신뢰를 증가시키거나 감소시킬 수 있습니다.
3. 과거 행동과 현재 행동을 비교하여 추가적인 맥락화를 기반으로 입증된 신원에 대한 확신도를 평가하고 조정합니다.  예를 들어, 시스템은 행위자의 이전 및 현재 지리적 위치, 하드웨어 플랫폼, IP 주소, 평판 등과 같은 행위자에 대한 이전 메타데이터를 유지 관리하여 신원 "증명"에 대한 신뢰도를 높이거나 낮추는 목표로 사용할 수 있습니다.

또한 명시적 확인 원칙은 신원뿐만 아니라 거래의 내용인 작업에도 적용될 수 있습니다.  일반적인 사용 사례로는 작업이 API 호출로 표현되는 경우(예: 데이터베이스 쿼리를 수행하는 API)가 있습니다.  이 예에서 명시적 확인 원칙은 API를 호출하는 행위자의 신원에 대한 확신을 갖는 데 사용될 수 있을 뿐만 아니라 API 작업의 사용의 정확성을 확인하는 데에도 사용될 수 있습니다. 예를 들어, API에 전달된 매개변수가 적절한 제약 조건을 준수하는지 확인하는 것입니다.

성숙한 제로 트러스트 사고방식에서는 "증거"가 거의 절대적이지 않습니다.  신원 인증 정보가 도용될 수 있고 기기가 손상될 수 있으며, API 매개변수 제약 조건이 불완전한 경우가 많습니다. 따라서 제로 트러스트 맥락에서 "신뢰"라는 용어는 증명된 신원 또는 거래 매개변수가 합법적일 가능성이 얼마나 되는지에 대한 표시로 해석되어야 합니다.  따라서 "신뢰" 수준은 거래를 허용, 차단 또는 추가 검사하기로 결정하는 데 있어 유일한 요소는 아니지만 하나의 핵심 요소로 간주되어야 합니다.

거래에 참여하는 행위자 간에 허용 가능한 수준의 "신뢰"가 확립되면, 제로 트러스트 접근 방식에서는 행위자(일반적으로 요청자, " Who" )에게 해당 시스템에서 달성하도록 설계된 작업을 수행하는 데 필요한 최소한의 권한만 부여해야 합니다.  이 원칙은 "긍정적 보안 모델"이라고도 하는 것을 구현합니다. 이는 모든 작업이 기본적으로 허용되지 않고 시스템 작동에 필요한 특정 권한만 부여되는 접근 방식입니다.  예를 들어, 예약 시스템에서는 익명의 사용자가 항공편 일정을 검색할 수 있도록 허용할 수 있지만, 애플리케이션 설계 요구 사항에 따라 익명 사용자는 항공편을 예약할 수 없습니다.

이러한 특권은 개별 배우 또는 배우 계층에 적용될 수 있습니다.  일반적으로 애플리케이션 소비자는 인간 행위자이거나 인간의 대리인이며 "익명 사용자", "고객", "파트너" 또는 "직원"과 같은 클래스로 그룹화됩니다.  신뢰도가 낮은 행위자 계층은 일반적으로 인증을 통과하는 데 더 낮은 신뢰 임계값을 요구하지만, 액세스할 수 있는 API의 수도 적거나 덜 민감합니다.  애플리케이션이나 해당 인프라 내부의 행위자(예: 애플리케이션 내의 특정 서비스나 컨테이너)는 "컨테이너 <X> 및 <Y>만 데이터베이스에 액세스할 수 있고, <X>만 개체 저장소에 쓸 수 있지만 <Y> 및 <Z>는 읽을 수 있습니다."와 같이 보다 사용자 정의된 권한을 가질 수 있습니다.

최소 권한을 구현하는 데 있어 중요한 고려 사항은 사전에 신중하게 고려하여 보다 맞춤화된 방식으로 적용하려는 노력입니다.⁷ 구체적으로, 모든 행위자 또는 행위자 클래스에 일반적인 권한 집합을 적용하는 대신, 성숙한 제로 트러스트 구현은 어떤 작업이 시도되고 있는지에 대한 보다 세부적인 보기를 가져야 합니다.   예를 들어, 매우 거친 수준에서 "파일 시스템 액세스"는 권한을 부여받을 수 있지만 "파일 시스템 읽기"는 실제로 필요한 권한을 더 엄격하게 지정하여 긍정적 보안 모델을 고품질로 구현할 수 있습니다.

마지막으로, 최소 권한의 보다 정교한 구현은 "명시적으로 확인"의 성숙한 구현과 함께 작동할 수 있습니다. 즉, 행위자의 승인된 권한을 절대적인 것으로 보지 않고 대신 인증에서 제공하는 신뢰에 근거한다고 볼 수 있습니다.  따라서, 증명된 신원( Who )에 대한 신뢰도가 최소 임계값을 충족하는 경우에만 권한이 부여되며, 이 임계값은 시도되는 작업에 대해 구체적으로 지정됩니다. 예를 들어, 특히 영향력이 큰 일부 작업(예: 시스템 종료)의 경우 해당 작업을 수행하는 사람이 관리자라는 확신도가 90% 이상 필요할 수 있습니다.  이 예에서 시스템 종료가 시도될 때 신원에 대한 시스템의 신뢰도가 80%에 불과하다면 시스템은 작업을 허용하기 전에 증명된 신원의 신뢰도 점수를 높이기 위한 추가 검증이 필요합니다.

명시적 검증과 최소 권한은 핵심 개념이지만, 지속적인 평가 원칙은 이러한 원칙이 지속적으로 평가되어야 한다는 사실을 포착합니다. 즉, 다음과 같은 의미입니다.

1. 모든 거래는 검증과 특권을 거쳐야 합니다.  즉, "사용자 세션의 첫 번째 트랜잭션"이나 "Docker 컨테이너 워크로드를 통해 시작된 트랜잭션"과 같이 트랜잭션의 하위 집합만 검사 대상이 되어서는 안 됩니다.  이는 당연한 것처럼 들릴 수 있지만, 많은 제로 트러스트 구현은 설계가 좋지 않거나 가시성이 부족하여 모든 거래를 검증하지 않습니다.  이 분야의 일반적인 단점은 외부 행위자에게만 제로 트러스트를 적용하고 내부 행위자에게는 적용하지 않는 것, 그리고/또는 제로 트러스트 판결이 장기간 동안 유효하다고 가정하는 데에서 발생합니다.
2. 평가의 핵심 요소(행위자의 신원에 대한 확신과 해당 행위자에게 허용된 권리) 는 역동적이고 변화의 대상 이라고 보아야 합니다.  예를 들어, 신원에 대한 신뢰도는 관찰된 동작과 사이드밴드 메타데이터를 기반으로 시간이 지남에 따라 증가하거나 감소할 수 있으며, 따라서 모든 신뢰 기반 정책도 변화하는 신뢰도에 따라 동적으로 조정되어야 합니다.  또한, 정책에 의해 이전에 부여된 권한 임계값이 조금 후에 철회되거나 일부 작업에 필요한 최소 신뢰 수준이 변경될 수 있습니다.  정책 변경에 대한 시간 척도는 다를 것입니다. 느리게(인간의 운영 프로세스에 따른 시간 척도) 또는 빠르게(자동화된 거버넌스 에이전트를 통해) 변경될 수도 있지만 시스템은 동적으로 대응하고 이러한 변경 사항을 준수할 수 있어야 합니다.

마지막 원칙은 건강한 편집증을 배경으로 매우 동기가 부여된 적대자가 있다는 가정에 근거합니다.  구체적으로 전제는 "당신이 침해당했다고 가정한다"이며, 여기서 "침해"는 "거부되어야 했지만(완벽한 지식과 실행으로) 대신 허용된 거래"로 정의됩니다.  이러한 탈출의 근본 원인은 불완전한 지식(예: 감지되지 않은 사기 자격 증명에서 비롯된 인증의 잘못된 높은 신뢰 점수)이거나 구현 제한(예: 부여된 권한에 대한 충분히 세부적인 구체성이 부족함, 예: "열린 네트워크 연결"을 권한으로 갖지만 네트워크 대상의 지리적 위치를 기반으로 구별할 수 없음)이거나, 제로 트러스트의 불완전한 구현(예: 내부적으로 사용되는 취약한 오픈 소스 구성 요소에 제로 트러스트를 적용하지 않음)으로 인해 발생할 수 있습니다.

따라서 제로 트러스트 사고방식은 이러한 침해의 영향을 가장 잘 관리하고 최소화하는 방법도 다루어야 합니다.

이 원칙의 구현은 다른 원칙들보다 다양하지만 일반적으로 다음과 같이 나타납니다.

• 먼저, 정책상 허용되기는 하지만 의심스러운 거래를 식별합니다.  "의심스럽다"는 말은 종종 문맥에 따라 달라지지만, 일반적인 해석은 다음과 같습니다. (a) 과거에 관찰된 동작과 매우 다른 비정상적인 거래, (b) 개별적으로는 정상적이지만 전체적으로는 비정상적인 거래 그룹 - 예를 들어, 파일을 읽고 쓰는 것은 흔할 수 있지만 초당 1000개 파일의 속도로 읽고 쓰는 것은 비정상적일 수 있음, 또는 (c) 바람직하지 않고 이전에는 보지 못했던 시스템 영향과 관련된 작업 - 예를 들어 특정 거래가 TOR 노드에 대한 네트워크 연결을 열거나 시스템 CPU 부하를 크게 증가시키는 패턴이 있습니다.
• 그런 다음 완전히 자동화된 워크플로 또는 하이브리드 인간 제어/ML 지원 워크플로를 통해 심층 분석을 수행하여 해당 거래가 유효하지 않은지 확인합니다.  해당 거래가 무효하다고 판단되면 완화 조치를 취합니다.  이는 일반적인 정책 업데이트의 형태를 취할 수도 있고, 추가적인 완화 계층으로서 다른 정책 기반 완화책에 대한 "백스톱" 역할을 할 수도 있습니다.

정책 기반 조정을 사용하는 접근 방식을 선택한 경우, 사용 가능한 정적 정책 도구를 활용하여 조정을 적용할 수 있습니다.  정책 기반 조정의 예로는 트랜잭션 세부 액세스 제어 권한을 제한하는 것(즉, 누가 누구 에게 무엇을 할 수 있는지 더 이상 허용하지 않음) 또는 대신 특정 작업을 수행하는 행위자(또는 행위자 클래스)에 대해 더 엄격한 "증명 표준"을 적용하는 것(즉, MFA 또는 더 높은 신뢰 점수 요구)이 있습니다. 

대신 추가 "백스톱" 계층을 사용하는 접근 방식을 선택하는 경우 이 전략은 세밀한 단계 또는 거친 단계 모두로 구현될 수 있습니다.  가장 세분화된 전략은 특정 위험-보상 비율을 넘는 거래만을 정확하게 차단하는 것이지만, 이 솔루션을 구현하는 데 추가 분석이 필요한 경우 허용된 일부 거래에 허용할 수 없는 수준의 지연이 추가될 가능성도 있습니다.  대신, 해당 행위자의 미래 거래를 샌드박싱하거나 행위자가 시스템에서 완전히 참여하는 것을 금지하는 등 보다 거친 전략을 사용할 수 있습니다.  극단적인 경우에는 파일 I/O를 종료하는 것과 같은 보다 거친 완화 방법이 적절할 수도 있습니다. 

물론, 다른 모든 조건이 동일하다면 일반적으로 보다 세분화된 백스톱 완화책이 더 바람직합니다. 그러나 종종 사용 가능한 솔루션 기술의 제약에 따라 균형을 맞춰야 하며, 조립식 백스톱은 보통 백스톱이 없는 것보다 낫습니다.  예를 들어, 의심되는 랜섬웨어를 방지하기 위한 거친 대응책이 파일 I/O를 비활성화하는 것이라면, 그 대응의 부작용은 공격자가 시스템에서 확인되지 않은 채 계속 작동하도록 허용하는 대안보다 여전히 나을 수 있습니다. 물론, 무위로 인한 결과가 랜섬웨어에 의해 암호화된 파일 시스템일 경우를 가정합니다. 

제로 트러스트를 이용한 안전한 애플리케이션 개발을 위한 가장 좋은 시작점은 당연히 처음부터입니다. 제로 트러스트 원칙을 구현하는 데 필요한 기본 원칙은 애플리케이션 개발 프로세스의 설계 단계에 반영되어야 합니다.  따라서 CI/CD 파이프라인에 통합된 운영상의 제로 트러스트 솔루션에 대한 논의는 최우선적으로 고려해야 할 기본 요소에 대한 이해로 시작해야 합니다.

이러한 기본 요소의 핵심은 시스템 동작의 원하는/의도된 동작을 포착해야 하며, 편차를 감지하고 조치를 취할 수 있는 충분한 가시성과 제어 기능이 결합되어야 합니다.  의도된 상호작용은 각 행위자( Who )가 각 대상( Whom )에 대해 원하는 일련의 작업( What )을 정의하는 데 사용됩니다.  그러나 의도한 상호작용 패턴이 알려지지 않은 시나리오나 환경이 있을 수도 있습니다. 이러한 경우 조직은 보다 심층적인 가시성을 활용하여 적절한 상호작용 세트를 "발견"할 수 있습니다.⁸ 이를 정책으로 제정할 수 있다.

예를 들어, 애플리케이션의 외부 API에 대한 ID 기반 액세스 제어에 초점을 맞춘 오늘날의 ZTNA 솔루션에서는 인증 API에 대한 가시성과 제어가 필요합니다.  또는 클라우드 워크로드 보호 플랫폼(CWPP) 컨텍스트에서 손상된 컨테이너 워크로드를 감지하려면 각 컨테이너가 수행하는 작업에 대한 가시성과 실시간 수정이 필요한 경우 실시간으로 확인할 수 있는 기능이 필요합니다.

다음은 설계 프로세스의 일부가 되어야 하는 기초 고려 사항과 관련된 상위 수준 "버킷" 목록이며, 각 핵심 포인트에 대해 생각해야 할 구체적인 질문을 제공하는 추가 드릴다운이 포함되어 있습니다.

• 시스템의 블랙박스 인터페이스(입력 및 출력)는 무엇입니까?
  • 애플리케이션과 상호 작용하는 사용자 유형은 관리자, 인증된 사용자, 인증되지 않은 사용자, 파트너로 구분되며, 이들은 무엇을 해야 합니까?
  • 모든 통신은 정의된 API를 통한 것인가요, 아니면 "원시" 네트워크 통신이나 데이터베이스나 객체 저장소와 같은 데이터 저장소를 통한 통신인가요?
    • API 통신의 경우, API는 사용자가 API와 상호작용할 수 있는 범위와 이러한 상호작용을 둘러싼 제약(예: 매개변수 제약, 속도 제한 등) 측면에서 얼마나 잘 정의되어 있습니까? 
    • 모든 네트워크 통신에서 전송되는 모든 데이터는 암호화됩니까?
    • "원시" 데이터 인터페이스가 있는 경우(예: 정보가 객체 저장소나 데이터베이스를 통해 클라이언트와 애플리케이션 간에 공유되는 경우), 누가 언제 어떤 정보에 액세스했는지 추적하는 감사 로그가 있습니까?
• 마찬가지로, 내부 "화이트박스" 수준에서 외부에서 제공되는 모든 서비스를 포함하여 전체 애플리케이션을 구성하는 구성 요소 서비스는 무엇이며, 이러한 구성 요소는 어떻게 통신합니까?
  • 이러한 서비스들은 어떻게 통신합니까? 사용되는 API는 무엇이며, 해당 상호 작용에 대한 제약 조건(역할, 액세스 제어, 속도 제한, 매개변수 등)은 무엇입니까?
    • 위와 비슷한 질문이 API의 형식성과 제약, 통신 암호화와 관련된 문제에도 존재합니다.
    • "내부"(예: 워크로드/컨테이너 간) 통신은 공유 메모리 및 파일 시스템 기반 인터페이스를 사용할 가능성이 더 높습니다. 이러한 인터페이스는 식별해야 합니다.
• 시스템은 블랙박스 인터페이스와 내부 통신 경로에 대한 접근을 제한하기 위해 어떤 제어 메커니즘을 제공합니까?
  • 특정 API를 호출할 수 있는 사람(어떤 역할)을 나타내는 정책이 있습니까? 그리고 정책을 위반하면 어떻게 됩니까?  마찬가지로, 잘못된 매개변수나 너무 높은 빈도로 호출되는 것과 같은 API의 모든 종류의 남용을 감지하고 완화하기 위한 수단은 무엇입니까?  다른 시스템의 맥락적 입력을 기반으로 해당 정책을 동적으로 업데이트할 수 있습니까?
  • 마찬가지로, 파일 시스템, 개체 저장소, 데이터베이스 테이블 등 다른 형태의 작업 간 통신을 누가 어떤 파일/저장소/테이블에 액세스할 수 있는지 제한하고 해당 리소스의 남용을 방지하는 정책이 있습니까(예: "SELECT * from <table>")?
• 시스템은 블랙박스 인터페이스와 내부 커뮤니케이션 경로에 대한 액세스를 제한하기 위해 어떤 가시성(대시보드, 로그, 통계)을 제공합니까?
  • 시스템은 누가 언제 어떤 API를 호출하는지 식별할 수 있습니까?  이 데이터는 보관되나요? 그렇다면 얼마나 오랫동안 보관되나요?  이러한 데이터는 얼마나 빨리(실시간, 매시간 등) 제공됩니까?  데이터의 소비성은 어느 정도입니까? 구조화되지 않은 파일 로그입니까? 아니면 보안 이벤트 및 사고 관리(SEIM) 서비스로 전송할 수 있는 구조화된 JSON(JavaScript Object Notation)입니까? 아니면 빅데이터 데이터베이스 테이블에 기록된 데이터입니까?
  • 메모리, 파일, 객체, 데이터베이스 등 다른 통신 경로에 관한 동일한 질문에 대한 답은 무엇입니까?  누가 무엇을 하는가?  해당 데이터는 어떻게 노출되나요?
• 통신 경로 외에 시스템은 리소스의 과도한 가입이나 과도한 소비를 방지하기 위해 어떤 다른 제어 및 가시성을 제공합니까 ?
  • 시스템은 CPU, 메모리, 대역폭, Pod 크기 조정 등 리소스 소비 지표에 대한 가시성을 갖추고 있습니까?  그렇다면 해당 데이터의 세분성은 어느 정도이며, 얼마나 활용 가능합니까?
  • 시스템에 리소스 소비에 대한 제어나 보호책(작업당 메모리/CPU/파일 IO 제한, 프로세스 생성 시스템 호출 추적, Pod의 확장/축소 제한, 다른 서비스를 호출하는 API에 대한 속도 제한)이 있습니까?

이러한 질문을 명확하게 묻는 것은 Zero Trust를 구현하기 위해 기반에 격차가 있는 곳을 발견하는 데 도움이 됩니다.  종종 설계 초기에 질문만 하는 것만으로도 최소한의 추가 설계 작업으로 격차를 해소할 수 있습니다.  그리고 격차가 지속될 경우, 격차를 인식하는 것만으로도 보안에 더욱 집중하거나 취약한 위협 영역을 식별하는 데 도움이 됩니다.

이런 종류의 사전 보안 개발 분석을 수행하는 것은 제로 트러스트 사고방식의 중요한 부분입니다.  하지만 이러한 사실에도 불구하고 오늘날 제로 트러스트의 초점은 대부분 초기 설계 이후에 발생하는 일에 맞춰져 있으며, 대부분 기업은 제로 트러스트의 설계 이후 측면에 주로 초점을 맞춥니다.  그러나 설계 단계에서 Zero Trust의 효과적인 구현에 대한 요구 사항을 신중하게 고려하면 애플리케이션이 배포된 후 "구멍을 패치"하는 데 필요한 훨씬 더 큰 증분적 노력을 방지할 수 있습니다.

"침해 가정"이라는 사고방식의 전제가 구현하듯이 보안 실무자는 충분히 동기가 부여된 적이 악의적인 거래를 실행할 수 있을 것이라고 가정해야 합니다. 이는 정책 규칙을 충족하지만 완벽한 세상에서는 허용되어서는 안 되는 누가 누구에게 무엇을 하는지에 대한 사례입니다.  이런 경우에는 일반적으로 거래 패턴과 시스템 부작용에 대한 관찰을 기반으로 해당 사례를 찾을 수 있는 효과적인 "백스톱" 메커니즘을 갖는 데 중점을 둡니다. 이는 앞서 "침해 가정" 섹션에서 설명한 바와 같습니다.

그러나 신원 개념과 마찬가지로 특정 거래가 악의적인지 여부를 아는 것은 결코 완벽할 수 없습니다.  따라서 ID와 마찬가지로 이상적인 제로 트러스트 솔루션은 거래의 적법성에 대한 "신뢰도" 점수를 보고해야 합니다. 예를 들어, 데몬이 10초 동안 일반 파일 속도의 10배를 읽고 쓰는 것을 보면 악의성에 대한 신뢰 점수가 70%가 될 수 있지만 속도가 100배 증가하고 1분 동안 지속되면 신뢰도가 95%로 높아질 수 있습니다. 이 예에서 향후 파일 쓰기를 억제하는 시정 조치를 취하더라도 여전히 잘못된 응답, 즉 "거짓 양성"이 될 가능성(30% 또는 5%)이 있습니다.  따라서 수정 여부를 결정할 때는 거짓 양성으로 인한 위험과 악의적인 행동을 허용함으로써 발생할 수 있는 잠재적 영향을 고려해야 합니다.

이 예의 요점은 사용자에게 표시되는 시정 조치를 취하기로 한 모든 결정을 강조하는 것입니다. 실제로는 의심스러운 활동과 관련된 모든 위험, 비용, 보상을 고려한 비즈니스 결정입니다.  거래에 추가적인 마찰을 도입하면 해당 가치를 받지 못할 확률이 높아지지만, 개입하거나 마찰을 추가하지 않으면 손상 위험이 발생합니다. 따라서 이런 경우에 행동할 것인지(또는 행동하지 않을 것인지)에 대한 결정은 세 가지 입력에 따라 달라집니다.

1. 악의적인 거래가 계속되도록 방치할 경우 어떤 위험이 있나요?
   이러한 위험은 은행 자금 이체와 같은 직접적인 금전적 비용일 수도 있고, 주요 기록이 암호화되어 몸값을 요구하는 경우와 같은 운영적 비용이나 웹사이트 훼손과 같은 브랜딩적 비용과 같은 간접적 비용일 수도 있습니다. 개인 고객 데이터 유출 등 법적 비용이나 규정 준수 비용이 발생할 수도 있습니다. 본질적으로 위험 할당은 거버넌스 문제이며, 적절한 거버넌스에서는 애플리케이션에 대한 위험을 이해하고 정량화합니다.


2. 시정 조치를 취하면 어떤 부작용이 있나요?
   부작용은 (a) 도입된 마찰 및 (b) 폭발 영역의 차원을 따라 표현될 수 있습니다. 마찰 합법적인 거래가 진행되기가 얼마나 더 어려운가를 나타내는 것으로, 약간 불편한 경우(예: 추가 인증 수준)부터 불가능한 경우(거래가 허용되지 않는 경우)까지 다양합니다. 폭발 지역 다른 독립적인 거래도 영향을 받는지 여부와, 영향을 받는다면 몇 건인지를 나타냅니다.  예를 들어, 특정 사용자를 차단하면 해당 사용자에게만 영향을 미치지만, 로깅 서비스를 종료하면 모든 사용자와 거래에 대한 감사 가능성에 영향을 미칩니다. 


3. 해당 거래가 악의적이라는 믿음에 대한 확신은 무엇입니까? 
   자신감을 쌓는 것은 일반적으로 더 많은 데이터 포인트를 수집하고 더 많은 데이터 소스에서 상관관계를 찾는 것을 의미하는데, 둘 다 시간이 걸리므로 이러한 균형은 실제로 "행동하기로 결정하기 전에 얼마나 오랫동안 지켜봐야 할까?"라는 것입니다.

따라서 제로 트러스트 전략은 침해가 발생할 수 있다는 사실을 받아들여야 하지만, 신중한 접근 방식은 허용되지만 의심스러운 거래를 수정할 때 위험 대 보상 접근 방식을 채택해야 합니다.  이러한 균형은 다양한 애플리케이션 트랜잭션의 위험 수준과 수정 조치를 적용하는 결과, 그리고 위험 수준이 예상 비즈니스 보상을 초과하는 경우에만 수정 조치를 적용하는 것을 이해하게 됩니다.

¹ https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf

² https://csrc.nist.gov/publications/detail/sp/800-207/final

³ https://www.cisa.gov/zero-trust-maturity-model

⁴ https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF

⁵ https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf

⁶ https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf

⁷ 앞서 설명한 내용은 설계 단계부터 시작됩니다.

⁸ 또는 적어도 시스템에 필요한 것으로 보이는 "적절하다고 생각되는" 상호작용 세트입니다.  관찰에서 얻은 상호작용 집합이 불완전하거나 기존에 위험이 존재할 수 있는 위험이 항상 있습니다.  그러므로 설계에 있어서 사전에 생각하는 것이 언제나 바람직합니다.