제로 트러스트 도입을 위한 기법 및 기술 검토

Mudit Tyagi와 Ken Arora 작성

제로 트러스트의 ‘왜’—기본 원칙¹ —에서 한 걸음 더 나아가면, 다음으로 중요한 것은 ‘어떻게’—즉, 이러한 원칙을 구현하는 데 사용되는 기법과 기술입니다.

가장 넓은 관점에서 보면 제로 트러스트 원칙은 시스템 설계, 사용되는 하드웨어 플랫폼, 조달 절차를 비롯한 전체 애플리케이션 개발 수명 주기에 적용할 수 있습니다.² 그러나 이 백서에서는 런타임에 애플리케이션과 데이터를 보호하기 위한 제로 트러스트 구현의 운영 측면을 다룹니다. 

기법 및 기술

일반적으로 제로 트러스트 보안은 기술을 활용하여 다음 세 가지 목표 중 하나를 달성합니다:

1. 트랜잭션 제약 조건 적용: 누가 무엇을 누구에게 할 수 있는지.
2. 인간 시스템 운영자가 상황을 인식할 수 있도록 정보를 제공합니다.
3. 머신 러닝(ML) 기반 의심 지표와 해당 거래의 위험 대비 보상 프로필을 바탕으로 더욱 고도화된 위험 완화 및 문제 해결 조치를 수행합니다.

다음 그림은 이러한 전반적인 제로 트러스트 보안 트랜잭션 모델을 보여 주며, 이어지는 섹션에서는 각 기술 범주를 더욱 자세히 살펴봅니다.

그림 1: 제로 트러스트 보안 트랜잭션 모델.

시행: 인증 및 액세스 제어

동기

처음 두 기술인 인증과 액세스 제어는 서로 밀접하게 연관되어 있으며, “명시적으로 검증” 및 “최소 권한” 원칙에서 직접 비롯됩니다. 이러한 기술은 “누가 무엇을 할 수 있는가”를 통제하는 핵심이기 때문입니다. 보다 정교한 인증 구현 방식은 행위자의 지속적인 행동을 관찰하여 “지속적으로 평가”한다는 사고방식을 반영합니다.

인증

인증 기술의 핵심은 증명된 신원에 대한 신뢰를 구축하는 것입니다. 즉, 거래에서 누가 행위를 하는지를 확인하는 것입니다. 인증 절차는 다음 세 가지 요소로 구성됩니다. 

1. 행위자가 자신의 신원을 밝히는 증명 또는 주장을 제시합니다.
2. 일반적으로 행위자가 제공하며, 해당 증명이 사실임을 입증하는 데이터가 있습니다.
3. 시스템은 해당 증명이 사실일 가능성, 즉 행위자가 자신이 주장하는 바로 그 사람인지에 대해 판정하거나 결정을 내립니다. 아래 그림은 인증의 다양한 측면과 각 측면의 성숙도 모델을 보여 주며, 이어서 각 측면을 자세히 설명합니다.

그림 2: 제로 트러스트 보안 인증 성숙도 모델

증명

가장 기본적인 형태의 증명은 흔히 트랜잭션을 수행하려는 사람 또는 사람을 대신해 행동하는 에이전트인 ‘사용자’라고 합니다. 그러나 애플리케이션 내에서 제로 트러스트를 사용하는 경우 행위자는 워크로드(예: 프로세스, 서비스 또는 컨테이너)일 수 있으므로, 일반화된 신원 개념에는 이러한 행위자도 포함되어야 합니다. 그 밖의 경우에는 누가라는 개념에 사람이나 워크로드뿐만 아니라 신원에 관한 추가 고려 사항이나 차원도 포함됩니다. 이러한 관점에서 신원의 추가 차원에는 사용자/워크로드의 기기나 플랫폼, 상호작용에 사용되는 에코시스템 또는 에이전트의 위치가 포함될 수 있습니다. 예를 들어 ‘Alice’라는 사용자는 ‘ABC- 0001’로 태그된 PC에서 특정 브라우저 지문이 식별된 브라우저 인스턴스를 사용하고 있으며, IPv4 주소 10.11.12.13에서 접속했을 수 있습니다. 

신원 증명

일부 시스템에서는 인증되지 않은 사용자(때로는 ‘게스트’ 또는 ‘익명’ 사용자라고 함)가 제한된 범위의 트랜잭션을 수행할 수 있도록 허용합니다. 이러한 시스템에서는 신원을 증명하고 시스템이 판정을 내리는 추가 단계가 필요하지 않습니다. 그러나 특정 신원을 증명해야 하는 경우에는 일반적으로 다음과 같은 방법을 사용하여 해당 신원 증명을 뒷받침합니다:

• 비밀번호와 같은 공유 비밀 정보에 대한 지식.
• 서명된 인증서와 같이 신뢰할 수 있는 제3자가 발급한 일종의 자격 증명입니다.
• 사용자, 워크로드 또는 플랫폼에 대한 검증(디바이스 핑거프린팅과 같은 자동 방식 또는 CAPTCHA 챌린지와 같은 능동 방식).
• 행위자와 관련된 메타데이터(예: 지리적 위치, IP 평판 또는 액세스 시간).
• 수동형 생체 인식 분석 또는 애플리케이션 상호 작용의 워크플로 패턴과 같은 행동 분석.

높은 수준의 신뢰도가 필요한 경우 여러 방법을 함께 사용하는 경우가 많습니다. 이는 Google BeyondCorp 모델에서도 확인할 수 있습니다.³ 이 모델은 더 높은 가치의 트랜잭션을 허용하기 전에 다단계 인증(MFA)을 요구합니다. 더욱 정교한 인증 솔루션은 각 ID에 ‘신뢰도’를 부여하고 트랜잭션의 가치와 위험을 기준으로 각 트랜잭션 유형에 필요한 최소 신뢰도 수준을 지정합니다.

정적 인증과 동적 인증 비교

마지막으로, 이러한 방법 중 일부는 정적인 일회성 조치가 아니라 ‘지속적으로 평가’한다는 원칙에 따라 계속 수행될 수 있고 또 그렇게 해야 한다는 점에 유의해야 합니다. 이러한 경우 신원 증명에 부여된 신뢰도 점수는 시간이 지남에 따라 높아지거나 낮아질 수 있습니다. 예를 들어 단일 사용자 세션 내에서 브라우저 지문이나 IP 주소가 변경될 수 있으며, 이는 의심스러운 징후로 간주되어 신뢰도가 낮아질 수 있습니다. 또는 세션 중 행위자의 행동에 관한 데이터가 더 많이 수집됨에 따라 현재 행동이 과거 관찰 결과와 얼마나 일치하는지에 따라 신뢰도 점수가 높아지거나 낮아질 수 있습니다.

고급 시스템에서는 동적 인증과 액세스 제어가 긴밀하게 연동될 수 있습니다. 이러한 연동의 첫 번째 단계로, 앞서 언급했듯이 액세스 제어 정책에서 거래 유형별 최소 신뢰도 점수를 지정할 수 있습니다. 다음 단계에서는 액세스 제어 하위 시스템이 인증 하위 시스템에 피드백을 제공할 수 있으며, 일반적으로 신뢰도 점수를 최소 임계값까지 높이기 위해 추가 인증을 요청합니다.

접근 제어

인증 기술을 사용하여 트랜잭션을 수행하는 주체가 누구인지 확인했다면, 다음으로 살펴볼 질문은 다음과 같습니다. 해당 주체는 무엇을 할 수 있는가? 그리고 누구를 대상으로 할 수 있는가? 이는 접근 제어 기술의 영역입니다.

물리적 보안에 비유해 보겠습니다. 여러분이 군사 기지를 방문하려 한다고 가정해 보세요. 경비원은 여러분이 민간인인지, 정치인인지, 군인인지 확실히 확인한 후, 그 결과를 바탕으로 여러분이 출입할 수 있는 건물과 출입이 허용된 각 건물에 카메라를 반입할 수 있는지를 결정할 것입니다. 이러한 결정을 규정하는 정책은 매우 포괄적이어서 모든 건물에 일괄 적용될 수도 있고(예: “정치인은 모든 건물에 출입할 수 있다”), 더 세분화될 수도 있습니다(예: “정치인은 <A> 건물과 <B> 건물에만 출입할 수 있지만, 카메라는 <A> 건물에만 반입할 수 있다”).

사이버 보안 맥락에서 액세스 제어 기술은 제로 트러스트의 ‘최소 권한’ 원칙을 구현해야 합니다. 즉, 최적의 액세스 제어 정책은 행위자에게 필요한 권한만 정확히 허용하고 그 밖의 모든 권한은 허용하지 않아야 합니다. 또한 이상적이고 강력한 정책이라면 행위자 신원의 진위에 대해 특정한 최소 신뢰 수준이 충족되는 경우에만 권한을 허용해야 하며, 이 신뢰도 임계값은 허용되는 각 권한별로 세밀하게 지정되어야 합니다.

따라서 액세스 제어 솔루션의 가치는 이러한 이상적인 원칙에 얼마나 부합하는지를 기준으로 판단할 수 있습니다. 특히 제로 트러스트 보안 솔루션에는 액세스 제어가 반드시 포함되어야 하며, 아래에 제시되고 이어서 설명되는 기준에 따라 액세스 제어 기술을 평가해야 합니다.

그림 3: 제로 트러스트 보안 액세스 제어 성숙도 모델

1. 액세스 제어 권한은 얼마나 세분화되어 있나요?
   1. 작업의 세분화 수준, 즉 트랜잭션에서의 대상은 무엇인가요? 다음 중 어느 것인가요?
      1. 이진 방식: 모든 트랜잭션을 허용하거나 전혀 허용하지 않습니다. 군사 기지에 비유하면, 이는 “모든 군인은 어느 건물에나 출입할 수 있고 원하는 것은 무엇이든 할 수 있다”와 “민간인은 어떤 건물에도 출입할 수 없다”에 해당합니다.
      2. 개략적: API 엔드포인트 또는 트랜잭션의 ‘유형’(예: 파일 I/O, 네트워크 통신, 프로세스 제어) 단위로 세분화합니다. 앞의 예시에서는 허용되는 작업을 좀 더 세밀하게 구분하여 ‘정치인은 건물에 들어갈 수 있지만 사진을 찍을 수는 없다’와 같이 설정할 수 있습니다.
      3. 세분화: 하위 API 수준(즉, API의 매개변수나 버전에 따라 달라짐) 또는 트랜잭션의 ‘하위 유형’ 수준(예: 파일 I/O 읽기 전용 또는 TCP 수신 전용)입니다. 앞서 든 비유를 다시 한번 사용하면, 이를 통해 ‘민간인은 군인과 동행하는 경우에만 건물에 들어갈 수 있다’와 같이 더욱 세분화된 제어가 가능합니다. 
   2. 작업의 대상, 즉 트랜잭션에서의 대상을 세분화할 수 있는가? 다음 중 어느 수준인가?
      1. 대상 세분화 없음: 액세스 제어 정책에서 작업의 대상을 고려하지 않습니다. 이 예에서 이 접근 방식은 일부 건물에는 출입을 허용하지만 다른 건물에는 허용하지 않는 세분화 수준에 해당합니다. 여기서 건물은 ‘출입’ 작업의 대상입니다.
      2. 대상 세분화, 인프라 수준: 액세스 제어 정책에 작업 대상을 포함할 수 있지만, 대상의 IP 주소, DNS 이름 또는 Kubernetes(K8S) 컨테이너 이름과 같은 인프라별 태그/레이블을 사용합니다. 이를 통해 건물 단위로 정책을 세분화할 수 있지만, 군사 기지마다 건물 명명 규칙이 다를 수 있습니다.
      3. 대상 세분화, ID 인식: 액세스 제어 정책에는 작업의 대상을 포함할 수 있으며, 행위자(누구)를 식별하는 데 사용되는 것과 동일한 ID 네임스페이스(예: SPIFFE)를 사용하여 대상을 식별합니다. 이전 접근 방식에 비해 모든 군사 기지에서 건물을 식별하는 일관된 체계를 사용할 수 있으므로 정책의 이식성이 향상된다는 이점이 있습니다.
2. 액세스 제어 솔루션은 위험도가 낮은 작업과 높은 작업이라는 개념을 어떻게 처리하나요?
   1. 위험을 고려하지 않음: 액세스 제어 솔루션은 작업의 허용 여부를 결정할 때 모든 액세스 제어 권한을 동일하게 취급합니다.
   2. MFA를 통한 위험 관리: 액세스 제어 솔루션은 정책에서 허용된 일부 트랜잭션에도 다단계 인증을 요구하도록 지정할 수 있게 함으로써 위험을 관리합니다. 이는 트랜잭션에 관련된 행위자(누가), 작업(무엇을), 또는 대상(누구에게)을 기준으로 합니다.
   3. 신뢰도를 통한 위험 관리: 액세스 제어 솔루션은 정책에서 거래의 작업(무엇)과 대상(누구)을 기준으로 모든 거래에 행위자의 진위성에 대한 최소 신뢰 수준을 요구할 수 있도록 하여 위험을 관리합니다. MFA를 통해 신뢰도를 높일 수 있지만 다른 수단을 사용할 수도 있습니다. 한편, 거래 가치가 높고 행위자의 진위성이 충분히 확실하지 않은 경우에는 거래가 전혀 허용되지 않을 수도 있습니다.

“지속적으로 평가(및 재평가)한다”는 원칙에 따라, 행위자의 진위 여부에 대한 신뢰도는 시간이 지남에 따라 조정되어야 합니다. 단순한 솔루션에서는 단순히 시간 제한을 적용할 수 있으며, 보다 정교한 시스템에서는 시간 경과에 따른 행위자의 행동 관찰 결과를 바탕으로 신뢰도가 달라질 수 있습니다.

상황 인식: 가시성 및 머신러닝 지원 맥락 분석의 필요성

인증과 액세스 제어가 ‘항상 검증’ 및 ‘최소 권한’이라는 사고방식을 구현한 것이라면, 가시성과 맥락 분석은 ‘지속적인 평가’ 및 ‘침해를 전제로 함’ 원칙의 토대가 됩니다.

가시성은 분석에 반드시 선행되어야 합니다. 시스템은 볼 수 없는 것을 완화할 수 없기 때문입니다. 따라서 제로 트러스트 보안 솔루션의 효과는 시스템 운영 및 외부 컨텍스트에서 수집할 수 있는 텔레메트리의 깊이와 범위에 정비례합니다. 그러나 최신 가시성 인프라는 사람의 도움 없이 합리적인 시간 내에 처리할 수 있는 수준을 훨씬 뛰어넘는 방대한 양의 잠재적으로 유용한 데이터, 메타데이터 및 컨텍스트를 제공할 수 있습니다. 더 많은 데이터를 확보하는 동시에 해당 데이터에서 인사이트를 더 빠르게 도출하려면 인간 운영자를 위한 머신 지원이 핵심적으로 필요합니다.

이러한 지원은 일반적으로 규칙 기반 분석부터 통계적 방법, 고급 머신 러닝 알고리즘에 이르는 다양한 자동화 알고리즘을 통해 구현됩니다. 이러한 알고리즘은 쏟아지는 원시 데이터를 사람이 상황을 평가하고 필요한 경우 문제를 해결하는 데 활용할 수 있는, 이해하기 쉽고 실제 운영에 적용 가능한 상황 인식 정보로 변환합니다. 이러한 이유로 머신 러닝 기반 분석과 가시성은 서로 밀접하게 연관되어 있습니다.

원시 데이터(가시성)에서 조치(문제 해결)로 이어지는 일반적인 파이프라인은 아래와 같습니다:

그림 4: 제로 트러스트 가시성에서 문제 해결까지의 파이프라인

가시성

가시성은 제로 트러스트의 ‘지속적인 평가’ 원칙을 구현하는 방식, 즉 ‘어떻게’에 해당합니다. 여기에는 사용 가능한 데이터 입력의 목록을 관리하는 것(카탈로그)과 실시간 원격 측정 및 과거 데이터 보존(수집)이 포함됩니다.

제로 트러스트 가시성 구현의 성숙도를 평가할 때는 다음 네 가지 요소를 고려해야 합니다:

1. 지연 시간: 데이터가 실시간에 얼마나 가깝습니까?
   
   지연 시간은 잠재적 위협에 얼마나 신속하게 대응할 수 있는지를 결정하는 최소 한계를 나타냅니다. 제로 트러스트 솔루션의 지연 시간은 수초 이내여야 합니다. 그렇지 않으면 분석이 아무리 정확하더라도 데이터 유출/암호화 또는 리소스 고갈로 인한 가용성 저하와 같은 공격의 영향을 방지하기에는 너무 늦을 가능성이 큽니다. 더 정교한 시스템에서는 동기식 및 비동기식 완화 조치를 모두 지원할 수 있습니다. 동기식 완화는 완전한 가시성 확보와 분석이 완료될 때까지 트랜잭션이 완료되지 않도록 합니다. 동기식 완화는 트랜잭션에 지연을 추가할 가능성이 높으므로, 이 운영 모드는 특히 비정상적이거나 위험한 트랜잭션에만 적용하고, 그 외 모든 트랜잭션은 원격 측정 데이터를 전송하여 비동기식으로 분석되도록 합니다.
   
2. 활용 용이성: 데이터를 얼마나 쉽게 활용할 수 있는가?
   
   여러 소스 또는 여러 유형의 데이터 센서에서 데이터가 수신되는 경우 고려해야 할 사항이며, 이는 흔히 발생하는 상황입니다. 이 요소는 일반적으로 두 가지 하위 고려 사항으로 나뉩니다.
   
   구문 수준에서는 데이터를 추출하고 표현하는 방법을 고려합니다. 예를 들어, 한 소스에서는 소스 IP 평판이 syslog 메시지의 텍스트 필드(예: “악성”, “의심”, “알 수 없음” 등)로 수신되고, 다른 소스에서는 데이터 파일의 숫자형 이진 인코딩 필드로 수신된다면 표준 표현 방식을 정해야 합니다. 수신 데이터를 추출하여 해당 표현 방식으로 변환하려면 데이터 직렬화가 필요합니다.
   
   의미 수준에서는 소스마다 구문과 전송 방식뿐 아니라 의미 체계도 다를 수 있습니다. IP 평판을 다시 예로 들면, 한 제공업체는 위협 점수를 숫자로 제공하는 반면 다른 제공업체는 IP를 “TOR 노드”, “DNS 제어”, “피싱” 등의 범주로 분류할 수 있습니다. 가시성 솔루션은 수신 데이터를 일관된 구문으로 정규화하는 메커니즘도 제공해야 합니다.
   
3. 완전성: 사용 가능한 데이터의 범위와 깊이는 어느 정도인가요?
   
   고품질 가시성 솔루션이 제공하는 핵심 가치 중 하나는 침해 가능성을 나타내는 징후로서 의심스러운 활동을 탐지하는 능력입니다. 이를 효과적으로 수행하려면 솔루션이 애플리케이션 제공과 관련된 모든 “계층”에서 텔레메트리 데이터를 수신해야 합니다. 여기에는 애플리케이션 자체는 물론 애플리케이션 인프라, 네트워크 인프라, 애플리케이션에 적용되거나 애플리케이션이 사용하는 모든 서비스, 심지어 클라이언트 장치에서 발생하는 이벤트까지 포함됩니다. 예를 들어, 이전에 한 번도 확인된 적 없는 새 장치에서 접속한 사용자는 그 자체로도 다소 의심스러울 수 있습니다. 여기에 네트워크 정보(예: 해외 국가의 GeoIP 매핑)가 결합되면 의심 수준은 더욱 높아집니다. 이러한 의심 수준은 사용자 신원에 대한 신뢰도 점수가 낮아지는 형태로 나타납니다. 제로 트러스트 보안 정책의 맥락에서 이 행위자가 고가치 거래(예: 해외 계좌로의 자금 이체)를 시도할 경우, 액세스 제어 솔루션은 낮은 신뢰도를 근거로 해당 거래를 차단할 수 있습니다.
   
   제로 트러스트 관점에서는 가시성 솔루션이 더 심층적이고 완전할수록 시스템이 거래를 적절히 제한하고 침해를 탐지하는 데 더욱 효과적일 수 있습니다.
   
4. 거버넌스: 법률 및 라이선스에 따른 데이터 사용 요건을 얼마나 잘 지원합니까?
   
   마지막으로, 모든 데이터 수집은 데이터의 보안, 보존 및 사용과 관련된 법률 및 라이선스 요건을 준수해야 합니다. 따라서 강력한 가시성 솔루션은 이러한 요구 사항을 각각 충족해야 합니다. 거버넌스에 따른 데이터 사용 제약 조건을 파악하여 제로 트러스트 가시성 솔루션에 반영해야 합니다. 예를 들어 IP가 개인 식별 정보(PII)로 간주되는 경우, 분석을 위한 IP 주소의 사용 및 장기 보존은 IP 주소의 허용된 사용 범위를 준수해야 합니다.

머신 지원을 활용한 맥락 분석

가시성 외에도 ‘지속적인 평가’를 구현하려면 유의미한 평가를 수행하는 데 필요한 분석 도구가 필요합니다. 즉, 제로 트러스트 솔루션에서 실제 운영에 활용할 수 있는 평가가 이루어져야 합니다.

분석 시 고려해야 할 사항 중 하나는 입력 데이터의 범위와 폭입니다. 분석 알고리즘의 입력은 단일 소스에서 제공되는 하나의 데이터 스트림으로 제한될 수도 있고, 다양한 데이터 소스와 인프라 및 애플리케이션의 모든 계층에서 제공되는 여러 스트림을 포괄할 수도 있습니다.

• 가장 기본적인 맥락화는 단일 데이터 ‘유형’ 또는 ‘스트림’(예: ‘시간 및 소스 IP 주소가 포함된 사용자 로그인 정보’ 이벤트 스트림)의 범위 내에서 이루어지며, 일반적으로 과거 맥락 및/또는 여러 사용자에 걸친 데이터를 활용합니다. 이러한 분석을 통해 ‘이 사용자 <X>는 이 시간대에 로그인한 적이 없다’ 또는 ‘이 사용자 <X>는 항상 다른 사용자 <Y>가 로그인한 직후에 로그인하는 것으로 보인다’와 같은 기본적인 인사이트를 얻을 수 있습니다. 전자는 신원에 대한 신뢰도를 낮출 수 있으며, 후자는 악의적일 가능성이 있는 상위 수준의 패턴을 나타낼 수 있습니다.
• 보다 고도화된 컨텍스트화는 단일 데이터 ‘유형’에 대해서만 시간 및 다중 인스턴스 범위를 고려하는 데 그치지 않고, 서로 다른 데이터 ‘유형’ 또는 ‘스트림’ 간의 시간적 상관관계도 분석합니다. 예를 들어 사용자 로그인 데이터를 애플리케이션 계층의 특정 작업(예: 송금 또는 이메일 연락처 업데이트)이나 네트워크 계층의 작업(예: IP 기반 지리적 위치 조회)과 연계하여 분석할 수 있습니다.

제로 트러스트 프레임워크에서 특히 중요한 또 다른 분석 측면은 사람이 처리할 수 있는 능력을 넘어서는 규모와 속도로 수집되는 데이터를 다루는 것입니다. 따라서 사람이 이해할 수 있는 인사이트를 도출하려면 일정한 형태의 기계 지원이 필요합니다. 이 역시 지원의 정교화 수준을 단계적인 발전 과정으로 설명할 수 있습니다.

• 시각화만 제공: 첫 번째 단계는 통계와 이벤트를 가공 없이 표시하는 것으로, 일반적으로 관리 포털에서 제공되는 대시보드를 통해 이루어집니다. 표시되는 데이터는 수집된 데이터 스트림을 기반으로 합니다(일반적으로 시계열 데이터 또는 고정된 시간 범위 내 사용자/트랜잭션에 대한 종단면 데이터). 고급 대시보드에서는 데이터 정렬 및 그룹화뿐만 아니라 필터링을 통한 상세 분석 기능도 제공합니다. 이 모델에서는 사람이 모든 데이터 탐색, 이벤트 우선순위 지정, 분석 및 문제 해결을 수행하며, 자동화는 주로 데이터 탐색을 지원합니다.
• 시각화 및 구성 가능한 정적 규칙: 시각화에서 가장 일반적으로 확장되는 다음 단계는 사용자가 알림 또는 문제 해결을 위한 정적 규칙을 정의할 수 있도록 하는 것입니다. 이러한 규칙의 예로는 “<John>에게 <5분 동안 CPU 부하가 80%를 초과>하면 알림” 또는 “<API [Y]가 호출되고 국가가 [미국]이 아닌> 경우 <이메일을 통한 MFA> 요구” 등이 있습니다. 이러한 규칙은 솔루션 제공업체가 지정한 사전 정의 규칙으로 제한될 수 있으며, 더 고급화된 규칙 기반 하위 시스템에서는 SecOps 엔지니어가 작성한 사용자 지정 규칙도 허용할 수 있습니다. 어느 경우든 적용되는 규칙은 일반적으로 구성을 통해 제어되며, 필요한 경우 정의됩니다.
• 시각화 및 ML 지원: 그다음 단계에서는 행동 이상 및/또는 이전에 식별된 악성 트랜잭션의 패턴과 일치하는 트랜잭션을 찾아내는 고급 기법을 사용합니다. 다양한 기법이 사용되지만(기술적·비즈니스적 상충 관계에 대한 심층 논의는 이 문서의 범위를 벗어남), 고려해야 할 몇 가지 핵심 사항은 다음과 같습니다: 
  • 필요한 인적 노력: 일부 머신러닝 기법에는 ‘훈련’(즉, 지도 학습)이 필요합니다. 이는 적절한 규모의 데이터 집합을 신뢰할 수 있는 ‘분류기’를 사용해 사전에 분류해야 한다는 의미입니다. 신뢰할 수 있는 분류 결과를 얻기 위해 ‘분류기’ 역할을 결국 한 명 또는 여러 명의 사람이 맡는 경우가 많습니다. 이러한 경우에는 필요한 인적 노력을 고려해야 합니다. 다른 기법(즉, 비지도 학습)은 사람의 노력 없이 자체적으로 이상 징후를 탐지하거나 패턴을 인식합니다. 
  • 설명 가능성: 머신 러닝 시스템의 출력은 모델을 기준으로 입력 데이터를 평가한 결과입니다. 이 모델은 “이 사용자가 지난 한 달 동안 이 기기에서 확인된 적이 있는가?”와 같이 간단하고 답하기 쉬운 일련의 질문을 기반으로 할 수 있습니다. 또한 “이 사용자는 업무 시간 중에는 절대 로그인하지 않는 사용자들에게서 관찰한 일반적인 패턴에 해당한다”와 같이 쉽게 설명할 수 있는 유사성을 기반으로 할 수도 있습니다. 그 밖의 경우에는 쉽게 파악할 수 있는 상위 수준의 논리 없이 입력 데이터에 복잡한 벡터 대수 연산을 적용하는 방식으로 모델이 구성될 수 있습니다. 이 마지막 경우는 앞의 두 예보다 설명하기가 훨씬 어려우며, 일종의 “블랙박스”에 가깝습니다. 경우에 따라 설명 가능성은 사람이 이해하거나 감사할 수 있는지를 좌우하는 중요한 요소입니다. 이러한 경우에는 이해하기 어려운 모델보다 설명 가능한 모델이 훨씬 선호됩니다. 
  • 신뢰도 점수 제공 여부: 앞서 언급했듯이, 모델이 특정 결정에 대해 얼마나 확신하는지를 나타내는 지표, 즉 오탐 또는 미탐이 발생할 상대적 가능성을 보여 주는 지표는 매우 유용한 경우가 많습니다. 일부 알고리즘은 신뢰도 지표가 자연스럽게 출력되지만, 규칙 기반 알고리즘과 같은 경우에는 신뢰도 수준을 출력값 중 하나로 명시적으로 지정해야 합니다. 어느 경우든 신뢰도 점수를 제공할 수 있는 알고리즘이 그렇지 못한 알고리즘보다 더 견고합니다. 

규칙 기반 접근 방식과 마찬가지로, ML 지원은 탐지에만 사용하거나 자동 조치와 연계할 수 있습니다. 또한 ML 지원은 규칙 기반 시스템과 함께 사용할 수 있으며, 이 경우 ML의 ‘판정’(또는 의견이나 신뢰도)을 규칙의 입력값으로 활용할 수 있습니다. 예를 들면 “<ML 평가기 [bot_detector_A]가 90%를 초과하는 신뢰도로 봇이라고 보고하면 작업 <X>를 수행한다.”와 같은 규칙을 만들 수 있습니다.

우회 대응: 위험 기반 자동 교정

제로 트러스트 사고방식의 마지막 원칙은 ‘침해를 가정하라’는 것입니다. 명확히 짚고 넘어가자면, 적절하게 구현된 인증 및 액세스 제어 방식은 압도적 다수의 악의적인 트랜잭션을 방지하는 데 효과적입니다. 그러나 만일의 가능성까지 경계한다면, 인증 및 액세스 제어의 강제 적용 메커니즘이 충분한 동기를 지녔거나 운이 좋은 공격자에 의해 결국 무력화될 것이라고 가정해야 합니다. 이러한 우회에 적시에 대응하는 데 필요한 침해 탐지에는 가시성과 머신 지원 분석이 필요합니다. 따라서 다른 강제 적용 메커니즘이 때때로 무력화될 수 있으므로, ML 지원 맥락 분석에 데이터를 제공하는 가시성 기술은 위험 기반 교정이라는 제로 트러스트 보안의 최후 방어 솔루션을 뒷받침하는 데 반드시 필요합니다. 

그림 5: 제로 트러스트 위험 인식 기반 대응

실제 악성 트랜잭션이 인증 및 액세스 제어를 우회한 ‘거짓 음성’ 사례에서는 자동화된 위험 기반 교정 메커니즘을 최후의 방어 수단으로 사용해야 합니다. 그러나 이 기술은 앞선 시행 검사를 통과한 트랜잭션을 대상으로 최후의 방어 수단으로 적용되므로, 실제로는 ‘참 음성’(유효하고 바람직한 트랜잭션)인 것을 ‘거짓 양성’(악성 트랜잭션으로 잘못 표시된 경우)으로 잘못 표시할 우려가 더 큽니다. 이러한 우려를 완화하려면 인증 또는 액세스 제어에서 어떤 이유로든 탐지되지 않은 잠재적 악성 행위에 대한 판단으로 인해 교정 조치를 실행할 때 다음 세 가지 요소를 고려해야 합니다:⁴

• 트랜잭션의 비즈니스 가치: 트랜잭션마다 위험과 보상의 수준이 다릅니다. 예를 들어, 은행 계좌를 조회하는 트랜잭션은 해외 계좌로 자금을 이체하는 트랜잭션보다 위험이 낮습니다. 마찬가지로 항공사의 경우, 항공권 구매는 현재 항공편 지연 정보를 표시하는 트랜잭션보다 비즈니스 보상이 더 큰 트랜잭션일 가능성이 높습니다. 비즈니스 가치란 잠재적인 비즈니스 보상에서 얻는 이점을 해당 트랜잭션의 위험 프로필과 비교하여 평가한 것입니다. 비즈니스 가치가 높은 고보상/저위험 트랜잭션에 비해 저보상/고위험 트랜잭션에는 추정에 기반한 교정 조치로 인한 “오탐”의 영향을 감수하는 것이 더 용인될 수 있습니다. 
• “악의성” 판단에 대한 신뢰도: 물론 모든 선제적 교정 조치 제안이 동일한 것은 아닙니다. 구체적으로, 앞서 언급한 위험과 보상 외에 또 다른 핵심 요소는 행위자의 검증된 신원에 대한 신뢰도와 같이 해당 트랜잭션에 관한 판단의 신뢰도입니다. 대략적으로 말하면, “거짓 음성”, 즉 시행 메커니즘이 작동했어야 하지만 작동하지 않았을 확률은 행위자에 대한 신뢰도에 반비례합니다. 또한 “거짓 음성”을 줄이는 것이 위험 기반 교정 조치의 목표이므로, 신뢰도가 낮을수록 시스템은 교정 조치를 적용하는 쪽으로 더 기울어야 합니다.
• 교정 조치의 영향: 마지막으로, 모든 교정 조치가 허용 또는 차단이라는 이분법적 결정으로 이루어지는 것은 아닙니다. 실제로 추가 자격 증명/MFA를 요청하거나 CAPTCHA와 같은 인증 과제를 제시하는 등 사용자에게 표시되는 방식부터, DLP와 같은 심층 트래픽 검사를 수행하거나 더 고도화된 고연산 분석을 수행하는 등 사용자에게 거의 드러나지 않는 방식까지 다양한 위험 완화 기법을 사용할 수 있습니다. 따라서 이러한 추가 위험 완화 조치를 수행할 때의 영향, 즉 사용자가 겪는 불편과 애플리케이션의 운영 비용(DLP 또는 연산 집약적 분석에 드는 비용 등)은 고려해야 할 세 번째 요소입니다. 영향이 적고 고객이 인지하지 못하는 교정 조치가 영향이 크고 고객에게 표시되는 인증 과제보다 선호되며, 트랜잭션을 전면 차단하는 것은 가장 바람직하지 않은 선택입니다. 다만 확신도가 높거나 다른 위험 완화 메커니즘으로 확신도를 충분히 높일 수 없는 위험한 트랜잭션의 경우에는 차단이 적절할 수 있습니다.

결론

제로 트러스트 보안은 심층 방어와 같은 기존 보안 접근 방식을 현대적으로 발전시킨 것으로, 보안을 트랜잭션 중심의 관점, 즉 ‘누가 무엇을 누구에게 하려고 하는가’라는 관점에서 바라봅니다. 이 접근 방식을 사용하면 애플리케이션에 대한 외부 액세스뿐만 아니라 애플리케이션 내부도 보호할 수 있습니다.⁵ 이러한 기본적인 트랜잭션 관점을 바탕으로, 제로 트러스트 보안은 오늘날의 더욱 복잡하고 까다로운 환경에서 애플리케이션을 보호하는 데 사용되는 일련의 핵심 원칙에 기반합니다. 이러한 원칙은 다시 이를 구현하는 일련의 하위 시스템 수준 솔루션 또는 방법에 매핑됩니다. 핵심 원칙과 각 원칙이 솔루션 방법에 매핑되는 방식은 아래에 요약되어 있습니다. 

그림 6: 제로 트러스트 보안의 핵심 원칙 및 보안 방법

인증, 액세스 제어, 가시성, 상황별 분석, 위험을 고려한 문제 해결 등의 도구는 매우 다양한 유형의 공격을 방지하는 데 필요하며 충분합니다.

리소스

_{¹ https://www.f5.com/services/resources/white-papers/why-zero-trust-matters-for-more-than-just-access}

_{² 제로 트러스트는 CI/CD 파이프라인의 ‘왼쪽’ 단계에도 적용할 수 있으며, 적용해야 합니다. 취약점 평가 도구, 정적 분석, CVE 데이터베이스, 오픈 소스 코드 평판 데이터베이스, 공급망 무결성 모니터링 시스템과 같은 도구는 제로 트러스트 사고방식에 부합합니다.}

_{³ https://cloud.google.com/beyondcorp-enterprise/docs/quickstart}

_{⁴ 상황별 위험 인식 액세스 제어와 위험 인식 교정이라는 일반적인 주제 사이의 경계는 모호하며, 일부 중복되는 부분이 있다는 점에 유의하세요.}

_{⁵ 흔히 ‘애플리케이션으로 향하는’ 보호를 뜻하는 ‘남북(North-South)’ 보호와 대비하여, ‘동서(East-West)’ 애플리케이션 내부 보호라고 합니다.}