제로 트러스트 보안: 제로 트러스트가 중요한 이유(액세스 제어 그 이상)
초록
지난 몇 년간 네트워크 및 애플리케이션 액세스 분야의 주요 화두 중 하나는 ‘제로 트러스트’라는 개념이었습니다. 이 백서에서는 제로 트러스트의 핵심을 몇 가지 단순한 신념으로 정의할 수 있으며, 이러한 신념이 액세스뿐만 아니라 사이버 보안 전반에 걸쳐 폭넓게 적용될 수 있음을 보여줍니다.
본 백서는 제로 트러스트를 둘러싼 광범위한 개념을 포괄하는 프레임워크를 제시하고, 이를 오늘날 애플리케이션 보안 비즈니스 리더들의 의사결정에 영향을 미치는 기존 비즈니스 환경과 연계합니다. 마지막으로, 본 백서는 현재 및 새롭게 부상하는 위협에 대응하는 도구와 보안 구현의 원동력인 제로 트러스트 신념 체계를 구체적으로 설명합니다. 이러한 도구와 보안 구현은 후속 백서에서 중점적으로 다룰 예정입니다.
이 백서의 목표는 두 가지입니다. 첫째, 애플리케이션 비즈니스 리더가 갖춰야 할 보안 사고방식을 전달하고, 둘째, 향후 백서에서 더욱 구체화할 보안 실무자용 프레임워크를 소개하는 것입니다.
ZTS: 기술이 아닌 원칙에서 시작하기
‘제로 트러스트’라는 용어는 다양한 추상화 계층에서 여러 개념과 연관되어 사용됩니다. 때로는 특정 솔루션 아키텍처를, 때로는 특정 기술을 적용하라는 지침을, 또 때로는 제품의 속성을 가리키기도 합니다. 저희는 제로 트러스트 보안이 본질적으로 하나의 사고방식, 즉 신념 체계라고 생각합니다. 여기에서 기법과 전술이 도출되고 특정 기술이 활용되며, 이를 통해 광범위한 보안 위협에 대응할 수 있습니다.
제로 트러스트 보안(ZTS)의 기반이 되는 신념 체계는 수년 전 ‘심층 방어’에서 시작된 보안 사고방식 진화의 다음 단계로 볼 수 있습니다. 심층 방어는 개별 방어막이 뚫릴 가능성이 작지만 실제로 존재하더라도 핵심 자산에 대한 보호 계층을 늘리면 그 가능성을 낮출 수 있으며, 공격자의 진행 속도를 늦추는 동시에 공격에 성공하기 위해 더 많은 자원을 투입하도록 만든다는 믿음에 기반합니다.
제로 트러스트는 이러한 보안 사고방식을 다음 세 가지 측면에서 한층 발전시킨 것입니다:
- 첫째, 보호의 전제를 애플리케이션에 대한 액세스를 통제하는 단순한 ‘필터’ 집합에서 모든 시스템 트랜잭션에 상황에 맞게 적용되는, 자산에 더욱 적합한 보호 체계로 발전시킵니다. 각 트랜잭션에서는 다음을 파악해야 합니다. 누가 누구에게 어떤 작업을 시도하고 있는가. 여기서 ‘누가’와 ‘누구에게’는 사람이든, 자동화된 요소든, 코드 조각이든 관계없이 시스템 내부에 있거나 시스템을 사용하는 모든 구성 요소가 될 수 있습니다. 누가 및 누구에게인지를 규정하는 데는 ID 개념이 핵심이며, ID에 부여된 권한 개념은 무엇을 할 수 있는지를 명문화하는 데 사용됩니다.
- 둘째, 보안 의사 결정에 대한 평가를 정적이고 절대적인 것이 아니라 더욱 동적이고 적응적인 것으로 간주합니다, 따라서 관찰된 행동을 바탕으로 지속적으로 재평가해야 합니다. 각 트랜잭션을 어떻게 처리할지, 즉 상호 작용을 허용할지, 차단할지, 추가적인 신뢰를 확보할지 등에 관한 결정은 더 광범위한 비즈니스 맥락, 특히 위험과 보상 간의 상충 관계도 고려해야 합니다.
- 마지막으로, 아무리 많은 보호 계층을 마련하더라도 충분한 동기가 있거나 운이 좋은 공격자는 보호 체계를 뚫거나 우회할 수밖에 없다는 점을 전제로 합니다. 따라서 침해 발생 시 이를 신속하게 탐지하고 공격 시도의 피해를 완화하는 것 역시 전체 전략의 핵심 요소가 되어야 합니다.
이러한 발전은 부분적으로 시간과 경험의 산물이지만, 점차 다른 두 가지 애플리케이션 보안 동향이 맞물리면서 가속화되고 있습니다. 구체적으로 오늘날의 애플리케이션 아키텍처는 잠재적인 애플리케이션 취약점의 범위를 훨씬 더 넓혔으며, 특히 애플리케이션 인프라 ‘내부’에서 발생하는 위협은 갈수록 정교해지는 오늘날의 공격자들에게 악용될 수 있습니다. 다행히 보안 도구도 함께 발전했으며, 특히 최신 데이터 수집 및 분석 기능과 결합해 사용할 경우 방어 전략의 핵심 요소를 실질적으로 구현할 수 있게 되었습니다.
이 서론의 나머지 부분에서는 제로 트러스트 보안에 대한 당사의 접근 방식과 그 범위를 뒷받침하는 프레임워크를 개괄적으로 소개합니다. 이어지는 섹션에서는 문제 정의와 다른 최신 제로 트러스트 접근 방식과의 관계를 자세히 살펴보고, 솔루션 기술의 선택과 적용을 이끌어야 할 핵심 신념, 즉 ‘왜’에 대해 논의합니다. 향후 백서에서는 제로 트러스트 성숙도 모델과 관련하여 인증, 액세스 제어, AI 지원 분석과 같은 특정 기술에 요구되는 사항, 즉 ‘어떻게’를 심층적으로 다룰 예정입니다.
ZTS: '왜'에서 시작한다
아래 그림 1에서 볼 수 있듯이, 사이먼 시넥의 ‘왜에서 시작하라(Start with Why)’ 접근법은 ZTS 프레임워크를 설명하는 데 효과적인 도구입니다. 이 그림은 외부에서 내부로 살펴볼 수 있습니다. 먼저 ZTS가 대응하는 위협 유형에서 시작해 사용되는 보안 방법을 자세히 살펴본 다음, 최종적으로 이를 공통 원칙으로 요약하는 방식입니다. 또는 핵심 신념을 나침반으로 삼는 내부에서 외부로의 관점에서 볼 수도 있습니다. 이러한 핵심 신념에서 적절한 도구와 기법이 도출되고, 이를 통해 광범위한 위협에 대응할 수 있게 됩니다.
이후 섹션에서는 이 다이어그램의 각 동심원 계층을 자세히 살펴보지만, 간단히 요약하면 다음과 같습니다:
- 핵심 신념 은 사용 사례를 다음과 같이 정의하는 데서 비롯됩니다:
“누가 누구에게 무엇(행동)을 시도하는가?”- To establish 누가 그리고 누구에게인지를 확인하려면, 명시적으로 검증해야 합니다 모든 신원 증명을.
- 일단 누가인지 확인되면 최소 권한 원칙을 적용하여 무엇을 수행할 수 있는지 제한합니다.
- 지속적으로 평가하고 재평가하며 다음 세 가지 요소를 모두 검토합니다. 누가, 무엇을, 누구에게, 그리고 정책 제약 조건을 준수하는지 계속 검증합니다.
- 항상 보안 침해와 시스템 손상이 발생할 것이라고 가정하십시오. 행위(무엇을 누구에게 Whom)에 대한 위험 대비 보상 분석(인증 과정에서 사기가 발생할 가능성에 잘못된 거래 승인이 비즈니스에 미치는 영향을 가중치로 반영한 분석) 결과가 사전에 정해진 허용 가능한 안전 임계값을 초과하면 개입할 준비를 하십시오.
- 사용되는 방법은 다음과 같습니다:
- 인증과 접근 제어를 통해 일정 수준의 신뢰도로 누구인지를 확인한 다음, 해당 신원에 허용할 행위의 권한을 특정 대상에 대해 제한합니다.
- 가시성 및 머신러닝 기반 분석을 통해 각 트랜잭션의 전체 맥락, 즉 누가 누구에게 무엇을 하는지 지속적으로 관찰하고 평가합니다.
- 자동화된 위험 인식형 대응 위험 대비 보상 수준이 지정된 허용 임계값을 초과하면 트랜잭션에 개입합니다.
- 광범위한 사이버 공격에 대응 하기 위해 다음 방법을 적용합니다:
- 다음과 같은 전통적인 공격: 웹사이트 변조 또는 데이터 유출 – 이러한 공격은 ID 침해 또는 권한 상승을 탐지하고 인증 및 액세스 제어 기술을 사용하여 정책에 따라 누가 무엇을 할 수 있는지 제한함으로써 대응할 수 있습니다.
- 가용성/DDoS 공격 -- 인증 및 액세스 제어와 위험 인식형 대응 조치를 결합하여 이러한 공격에 대처할 수 있습니다. 예를 들어, 리소스를 많이 사용하는 트랜잭션을 시도하는 인증되지 않았거나 인증 수준이 낮은 행위자의 액세스를 차단하거나 속도를 제한합니다.
- 지능형 위협, 예를 들어 랜섬웨어 또는 공급망 공격 -- 이러한 위협은 누가 누구에게 무엇을 하는지에 대한 행동의 변화와 이상 징후를 탐지하고, 이를 위험 인지형 대응과 연계하여 해결할 수 있습니다.
ZTS의 범위
제로 트러스트 보안은 애플리케이션, 인프라 및 배포 스택 전반에 걸쳐 포괄적으로 적용되어야 하며, 전체 개발 파이프라인을 아울러야 합니다. 구체적으로는 다음이 포함되어야 합니다:
- 완전한 ‘최상위부터 최하위까지’의 애플리케이션 및 인프라 스택
- 서버, 네트워크 인터페이스 카드, 보조 프로세서 및 시스템 보드 구성 요소를 포함한 하드웨어 컴퓨팅 기반
- 하드웨어용 저수준 펌웨어 및 BIOS.
- 하이퍼바이저 또는 런타임 실행 환경과 같은 최하위 계층의 운영 체제.
- 애플리케이션 수준/컨테이너 운영 체제.
- 상용 또는 오픈 소스 형태로 가져온 타사 애플리케이션 구성 요소.
- 사내에서 개발했거나 맞춤 제작된 모든 애플리케이션 소프트웨어.
- 전체 "왼쪽에서 오른쪽으로" 애플리케이션 제공 스택
- 각 ‘상위에서 하위로’ 이어지는 스택 요소의 지속적인 유지 관리 및 업그레이드에 사용되는 공급망.
- 방화벽, 로드 밸런서, API 게이트웨이, 인그레스/이그레스/메시 컨트롤러, 인라인 사기 방지 장치 등 인라인 방식으로 배치되는 모든 애플리케이션 전송 구성 요소.
- 도메인 이름 시스템(DNS) 리졸버와 같이 트래픽 처리에 간접적으로 영향을 미치거나, 보안 정보 및 이벤트 관리(SIEM) 솔루션 또는 페더레이션 ID 서비스와 같이 메타데이터를 간접적으로 수신하는 모든 애플리케이션 전송 구성 요소.
전통적으로 제로 트러스트는 애플리케이션 개발 및 제공 팀에 초점을 맞춰 왔으며, 이러한 팀은 흔히 Dev, DevOps, DevSecOps, SRE와 같은 역할로 구분됩니다. 여기서 이를 언급하는 주된 이유는 더 큰 그림을 강조하기 위해서입니다. 즉, 제로 트러스트에 대한 포괄적인 접근 방식에는 비전통적인 역할과 인프라는 물론, 공급망 조달 전략과 같은 추가 워크플로도 포함하는 것이 바람직합니다.
문제 정의
CIO와 CISO의 최우선 과제 중 하나는 비즈니스 성장을 가속화할 수 있도록 정보 기술을 현대화하는 것입니다. 또한 이들은 기업의 위험 거버넌스에서도 핵심적인 역할을 합니다. 이들의 목표는 비즈니스 위험을 최소화하는 동시에 새로운 디지털 경험으로 고객 만족도를 높이고, 제3자와의 디지털 연결을 통해 운영 효율성을 향상하며, 직원들이 어디서나 생산적으로 일할 수 있도록 지원하는 것입니다. 이를 위해 CIO 및 CISO 조직은 인력이 최신 기술과 아키텍처, 모범 사례를 활용해 민첩하게 업무를 수행할 수 있도록 자율성을 부여하는 한편, 동일한 인력에게 적절한 보안 조치를 취하고 손실 위험을 방지하기 위해 사람들의 행동과 이들이 접근하는 정보 및 사용하는 기술에 대한 통제 체계를 수립하도록 해야 합니다.
조직은 시장 및 거시경제 여건의 변화, 소비자 행동, 공급망, 보안 위협 노출과 관련된 위험을 파악하고 통제해야 합니다. 위험을 정확하게 평가하고 신속하게 완화 조치를 취할 수 있는 역량은 기업의 경쟁 우위가 됩니다. 이 백서에서는 지적 재산 손실, 비즈니스 프로세스 중단, 개인 식별 정보 유출, 규제 기관의 벌금 등을 초래할 수 있는 보안 위협 노출 위험에 중점을 둡니다. 보안 위험은 검토 중인 상황의 다음 측면을 평가하여 산정할 수 있습니다:
- 관련 자산의 가치
트랜잭션에 관련된 자산은 중요도가 서로 다릅니다. 예를 들어, 개인 식별 정보로 구성된 데이터베이스는 기업이 생산한 제품을 취급하는 소매점의 위치를 나열한 데이터베이스보다 더 가치가 높습니다. 보안 및 IT 팀은 결정론적 프로세스를 사용하여 모든 자산의 인벤토리를 생성하고, 자산의 ‘가치’를 나타내는 점수에 따라 분류할 수 있습니다. - 침해의 영향
침해의 성격에 따라 그로 인한 영향이 결정됩니다. 예를 들어, 개인 식별 정보가 포함된 데이터 저장소에서 정보가 은밀히 탈취될 경우의 영향은 데이터 저장소의 가용성이 저해되는 경우보다 훨씬 큽니다. 다소 모호할 수 있지만, 다양한 침해 유형을 나열하고 각각에 ‘영향’ 점수를 부여할 수 있습니다. - 침해 가능성
트랜잭션이 자산 침해로 이어질 확률은 해당 트랜잭션과 관련된 위험을 평가할 때 가장 불확실한 요소입니다. 인간은 필요한 관측 규모를 감당할 수 없으므로, 조직은 침해 확률 계산의 신뢰도를 높이기 위해 머신 러닝과 인공 지능을 활용합니다.
당면 과제는 모든 개별 트랜잭션과 관련된 위험을 거의 실시간으로 산정하고, 잠재적인 침해의 영향을 통제하기 위해 적절한 완화 조치를 취하는 것입니다.
문제 인식
비즈니스 가속화에 대한 요구는 사이버 보안 위험을 악화시키는 새로운 관행으로 이어집니다. 아래에서 이 점을 더 자세히 살펴보겠습니다.
- 비즈니스 가속화 요구
- 디지털 경험
소비자들은 디지털 경험을 끊임없이 원하며, 여러 플랫폼(PC, 태블릿, 휴대폰)에서 지속적인 개선을 요구합니다. - 연결된 비즈니스
디지털 비즈니스 프로세스에는 파트너, 공급업체, 유통업체 및 다른 기업이 제공하는 서비스와의 연결이 필요합니다. - 모바일 인력
직원들은 업무 수행의 효율성을 높이기 위해 어디서나 비즈니스 애플리케이션에 액세스할 수 있어야 합니다.
- 디지털 경험
- 비즈니스 요구 사항을 충족하기 위한 실무 방안
- 애자일 개발 방법론
기업들은 프로젝트의 적시 납품에 중점을 두는 순차적 워터폴 방식 대신, 고객 만족을 최우선으로 하는 점진적이고 반복적인 애자일 개발 방식으로 전환했습니다. - 기성 소프트웨어 활용
새로운 디지털 경험을 최대한 빠르게 제공하기 위해 개발자들은 업계 동료들이 오픈 소스로 공개한 코드를 재사용합니다. - 외주 개발
외부 계약 개발자에게 업무를 맡기면 기업은 필요에 따라 인력을 확충할 수 있습니다. - 클라우드 인프라 활용
클라우드의 민첩성, 유연성, 확장성과 편리한 사용성 덕분에 개발자는 필요한 인프라를 온디맨드로 확보할 수 있습니다. - SaaS 도입
서비스형 소프트웨어(SaaS)는 사설 데이터 센터에서 이러한 애플리케이션을 조달, 배포 및 유지 관리하는 데 따르는 상당한 부담을 줄여 주므로 비즈니스 운영 애플리케이션에 유용합니다. - 마이크로서비스 아키텍처
팀은 마이크로서비스를 활용하여 지속적 배포를 실현하고 출시 기간을 단축합니다. - 분산 애플리케이션 구성 요소
조직은 서비스 기능을 개발하거나 제공하는 데 가장 적합한 도구를 갖춘 인프라에서 마이크로서비스를 실행하여 효율성을 높입니다. 최근에는 레거시 워크플로를 확장할 때 레거시 요소와 통신해야 하는 최신 애플리케이션 아키텍처를 사용하며, 이 둘은 서로 다른 인프라에서 실행되는 경우가 많습니다. - 개방형 API
다양한 서비스로 구성된 에코시스템을 활용하는 것이 기업이 모든 서비스를 자체적으로 개발하는 것보다 더 효율적입니다. - 타사와의 네트워크 연결
기업은 비즈니스 프로세스를 자동화하고 간소화하기 위해 파트너, 공급업체 및 유통업체와 암호화된 터널을 통해 서로 연결합니다.
- 애자일 개발 방법론
- 보안 위험 증가
- 공격 표면 확대
타사 소프트웨어와 오픈 소스 라이브러리를 사용하면 공급망 공격의 기회가 생기며, 외부에서 개발된 소프트웨어의 모든 취약점까지 그대로 이어받게 됩니다. 계약직 개발자는 기능을 기한 내에 완성하는 데 중점을 두므로 보안은 주요 관심사가 아닙니다. 또한 소프트웨어를 납품하고 프로젝트에서 빠진 후에는 내부 팀이 코드를 검토하여 보안 허점을 찾는 데 많은 시간과 노력이 듭니다. 애자일 스프린트는 기능을 신속하게 제공하는 데 매우 효과적이지만, 개발 속도가 빨라지면서 상세한 보안 감사와 테스트에 충분한 시간을 할애하기 어렵습니다. 다른 마이크로서비스와 통신할 수 있는 마이크로서비스 하나에 취약점이 있으면 전체 시스템의 보안 위험이 커집니다. 상호 연결된 기업은 운영 효율성을 높이지만, 그중 어느 한 곳의 보안 허점이 모두에게 영향을 미칠 수 있다는 심각한 문제가 있습니다. 공격자는 가장 취약한 연결 고리를 찾아 나머지 시스템으로 침투합니다. SaaS 플랫폼이나 클라우드 인프라의 취약점 또는 보안 소홀은 또 다른 공격 경로가 되며, 공동 책임 모델로 인해 조기 탐지와 해결이 복잡해질 수 있습니다. - 아키텍처 복잡성 증가
서로 다른 아키텍처로 개발되어 여러 인프라에 배포된 분산 애플리케이션 구성 요소는 각기 다른 보안 및 규정 준수 요구 사항을 갖습니다. 이로 인해 보안 팀이 엔터프라이즈 애플리케이션과 데이터를 보호하기 위한 적절한 메커니즘을 설계하고 배포하며, 규제 준수 요구 사항을 충족하기가 복잡해집니다. - 자금력이 풍부하고 동기가 강하며 숙련된 해커
2010년 오퍼레이션 오로라부터 2020년 솔라게이트에 이르기까지, 지난 10년간 막대한 피해가 발생한 후에야 발견되는 지능형 사이버 공격이 이어졌습니다. 최고 수준의 보안 기술을 갖추고 고도로 훈련된 보안 팀이 운영하는 조직에서도 침해 사고가 발생했습니다. 공격자들은 탐지되기 전까지 오랜 기간 이러한 조직의 IT 인프라에 잠복했습니다. IT 및 보안 팀이 사이버 공격을 방지하기 위한 규정을 준수하는 데 필요한 수준 이상으로 최선을 다했음에도 불구하고, 지적 재산과 개인 식별 정보가 탈취되고 비즈니스 운영이 중단되었으며 조직은 랜섬웨어의 인질이 되었습니다.
- 공격 표면 확대
미국 정부 지침
미국의 여러 연방, 주 및 지방 정부 기관과 다수의 미국 기업을 겨냥한 지속적인 사이버 공격이 잇따르자, 조 바이든 대통령은 2021년 5월 12일 국가 사이버 보안 개선에 관한 행정명령을 발표했습니다. 이 명령의 핵심 요소 중 하나는 정부 기관이 사이버 공격에 대비하기 위해 제로 트러스트 원칙을 적용하도록 하는 것입니다. 바이든 행정부는 이 명령에 이어 2022년 1월 26일 행정부처 및 기관의 장을 대상으로 관리예산실(OMB) 각서를 발표했습니다. 이 OMB 각서는 “갈수록 정교해지고 지속되는 위협 활동에 대한 정부의 방어 역량을 강화하기 위해 각 기관이 2024 회계연도(FY) 말까지 구체적인 사이버 보안 표준과 목표를 달성하도록 요구하는 연방 제로 트러스트 아키텍처(ZTA) 전략을 제시합니다.”1 행정명령과 OMB 각서는 모두 미국 국립표준기술연구소(NIST) 간행물 SP 800-207에 설명된 제로 트러스트 아키텍처를 언급하며, 정부 기관이 이를 따르도록 요구합니다. 이 간행물은 2020년 8월에 발행되었습니다.
Zero trust 아키텍처 및 성숙도 모델
정부 기관과 민간 부문의 오피니언 리더들은 제로 트러스트 아키텍처를 설명하고 이를 가장 효과적으로 도입하는 방법에 대한 조언을 제공하는 문서들을 발표했습니다. 아래에서는 이 문서들에 담긴 아이디어를 요약합니다. 이러한 문서에 담긴 아이디어와 제안의 핵심은 모든 트랜잭션을 검토하여 누가 is attempting 어떤 작업을 on 누구에게시도하는지 평가하고, 관련 위험을 계산한 결과를 바탕으로 해당 트랜잭션의 허용 여부를 실시간으로 결정하는 것입니다.
미국 국립표준기술연구소(NIST): Zero trust architecture
NIST 팀은 NIST SP 800-207 문서에서 제로 트러스트의 원칙을 열거하고 추상적인 제로 트러스트 아키텍처(ZTA)를 정의합니다.2 또한 제로 트러스트 접근 방식의 다양한 변형을 논의하고 추상 아키텍처를 배포하는 여러 방법을 설명합니다.
이 문서에서 다루는 핵심 추상화 요소는 상호 연동되는 정책 결정 지점(PDP)과 정책 시행 지점(PEP)입니다. 정책 결정 지점은 정책 엔진(PE)과 정책 관리자(PA)로 구성됩니다. 정책 엔진은 신뢰 알고리즘을 사용하여 주체에게 리소스 접근 권한을 부여할지 여부를 결정합니다. 이 결정은 정책 관리자가 실행하며, 정책 관리자는 정책 시행 지점과 통신하여 새 세션을 허용하거나 차단하고 기존 세션을 수정하거나 종료합니다. 또한 이 문서에서는 신뢰 알고리즘의 변형, 제로 트러스트 환경을 위한 네트워크 구성 요소, 다양한 사용 사례 또는 배포 시나리오를 설명합니다. 마지막으로 구현자가 위협을 인지하고 제로 트러스트 아키텍처 구성 요소를 보호하기 위한 적절한 조치를 취할 수 있도록, 공격자가 제로 트러스트 아키텍처를 무력화할 수 있는 방법도 살펴봅니다.
사이버보안 및 인프라 보안국(CISA): 제로 트러스트 성숙도 모델
미국 사이버보안 및 인프라 보안국(CISA)의 전문가들은 기관의 제로 트러스트 계획 수립을 지원하기 위해 제로 트러스트 성숙도 모델(https://www.cisa.gov/zero-trust-maturity-model)을 발표했습니다.3 이 모델은 NIST SP 800-207 문서에 설명된 추상적인 제로 트러스트 아키텍처를 기반으로 합니다. 저자들은 5개 영역을 제시하고, 조직이 각 영역에서 제로 트러스트 원칙을 준수하기 위해 지속적으로 발전할 것을 권고합니다. 해당 영역은 (i) ID, (ii) 디바이스, (iii) 네트워크, (iv) 애플리케이션 워크로드, (v) 데이터입니다. 또한 5개 영역 각각에서 가시성 및 분석과 자동화 및 오케스트레이션을 활용할 것을 권고합니다.
이 문서는 앞서 식별한 제로 트러스트의 5가지 핵심 요소 전반에 대한 상위 수준의 성숙도 모델을 제시한 다음, 각 영역을 더욱 심층적으로 다룹니다. 조직은 이 성숙도 모델을 활용하여 현재 상태를 파악하고 최적의 상태를 향해 단계적으로 나아갈 방향을 설정할 수 있습니다.
미 국방부(DOD): 제로 트러스트 참조 아키텍처
SolarWinds 공격이 발견된 후, 미국 국가안보국(NSA)은 「제로 트러스트 보안 모델 수용」이라는 문서에서 사이버 보안 팀에 제로 트러스트 보안 모델을 도입할 것을 권고하는 지침을 발표했습니다.4 미국 국방정보시스템국(DISA)과 국가안보국의 합동 제로 트러스트 엔지니어링 팀 소속 전문가들은 미국 국방부(DOD)의 제로 트러스트 참조 아키텍처를 작성했습니다.5 저자들은 다음과 같이 제로 트러스트 도입의 필요성을 강조합니다. “DOD 내부와 외부에서 발생한 데이터 침해로 드러난 취약점은 충분한 정보를 바탕으로 위험 기반 의사 결정을 내릴 수 있도록 지원하는 새롭고 더욱 강력한 사이버 보안 모델이 필요함을 보여줍니다.”6
이 참조 아키텍처의 권고 사항은 NIST SP 800-207 제로 트러스트 아키텍처 문서에 정의된 추상화 개념을 기반으로 합니다. 이 문서는 상위 수준의 운영 모델을 제시하고 그 구성 요소를 자세히 설명합니다. 또한 상위 수준의 성숙도 모델과 다양한 관심 영역에 제로 트러스트 원칙을 적용하기 위한 역량 매핑도 포함합니다. 이러한 문서들은 종합적으로 조직이 현재 상태를 평가하고 계획을 수립하는 데 도움을 줍니다.
제로 트러스트 원칙을 통한 위험 및 거버넌스 관리
“침해를 전제로 하는” 태도를 갖고 제로 트러스트 원칙을 따르면 조직의 위험 관리 및 거버넌스 관행을 개선하는 데 도움이 될 수 있습니다. 트랜잭션에 관여하는 주체를 “지속적으로 모니터링”하고 “명시적으로 검증”하는 제로 트러스트 원칙을 통해 조직은 모든 주체와 그 활동에 대한 동적 위험 점수를 산정할 수 있습니다. 이는 기존 보안 프로그램을 강화하기 위해 “지속적이고 적응형인 위험 및 신뢰 평가”(CARTA) 방법론을 사용하라는 Gartner의 권고와도 일치합니다. 리소스에 대한 최소 권한 액세스만 허용하는 원칙을 채택하면 침해가 발생하더라도 손실 위험을 줄일 수 있습니다. 지속적인 모니터링과 명시적 검증을 통해 생성된 정보는 규정 준수 보고서를 작성하는 데에도 유용합니다.
사고방식 자세히 알아보기
이 섹션에서는 기업이 제로 트러스트 보안을 위해 도입해야 할 도구와 설계에 관한 전략 및 의사결정의 동기가 되는 사고방식, 즉 신념 체계와 ‘왜(Why)’에 초점을 맞춥니다. 실제로 오늘날의 제로 트러스트 솔루션에 사용되는 모든 방법론과 구성 기술의 근간은 네 가지 핵심 원칙으로 간단히 요약할 수 있습니다. 먼저 이러한 원칙을 열거한 다음, 더 넓은 애플리케이션 개발 수명 주기의 맥락에서 이를 적용하는 방법을 살펴봅니다. 즉, 설계 단계에서 이러한 원칙을 사전에 고려하는 방법뿐만 아니라 애플리케이션의 배포 및 런타임 단계에서 운영 측면으로 고려하는 방법도 논의합니다.
제로 트러스트 운영 원칙
제로 트러스트 솔루션을 근본적으로 시스템 상호작용에서 신뢰를 구축하는 것으로 이해한다면, 즉 “누가 무엇을 누구에게 하고 있는가?”라는 관점에서 보면, 상호작용에 적합한 수준의 신뢰를 구축하는 과정은 네 가지 구성 요소로 나눌 수 있습니다.
명시적으로 검증
이름에서 알 수 있듯이, 제로 트러스트의 기본 원칙은 “무조건 신뢰하지 말고, 항상 검증하라”입니다. 따라서 시스템의 모든 주체, 즉 시스템 상호작용에서의 주체와 대상은 다음을 수행할 수 있어야 합니다:
- 시스템이 익명 ID에서 시작되거나 익명 ID를 대상으로 하는 상호작용(예: 항공사 예약 시스템의 익명 브라우저)을 허용하는 경우, 특수한 사례인 ‘익명’ ID를 포함하여 자신의 ID를 증명해야 합니다. 그 밖의 모든 ID의 경우, 행위자는 시스템이 허용하는 네임스페이스에서 자신이 누구인지 명시할 수 있어야 합니다.
- 행위자가 주장한 신원(익명이 아닌 모든 주장 신원)에 대한 보조적인 ‘증거’를 수신하고 검증합니다. ‘증거’의 유형(비밀번호, 인증서, 행동 등)과 그 증거의 강도는 다양할 수 있지만, 시스템은 해당 신원 주장에 대해 일정 수준의 신뢰도를 판단할 수 있어야 합니다. 단순한 시스템은 증거의 신뢰도를 예/아니요의 이분법으로 판단할 수 있는 반면, 고급 시스템은 위험과 보상을 기반으로 한 정책의 일부로 명시적으로 참조할 수 있는 수치형 신뢰도 점수를 사용할 수 있습니다. 또한 시스템은 능동적 챌린지에 대한 응답이나 행위자의 행동에 대한 수동적 관찰 등 다른 수단을 통해 신뢰도를 높이거나 낮출 수도 있습니다.
- 과거 행동과 비교하여 현재 행동에 대한 추가적인 맥락 정보를 바탕으로, 증명된 신원에 대한 신뢰도를 평가하고 조정합니다. 예를 들어 시스템은 신원 ‘증명’에 대한 신뢰도를 높이거나 낮추기 위해 행위자의 이전 및 현재 지리적 위치, 하드웨어 플랫폼, IP 주소, 평판 등의 과거 메타데이터를 유지할 수 있습니다.
또한 명시적 검증 원칙은 ID뿐만 아니라 트랜잭션의 '무엇(What)'에 해당하는 작업에도 적용할 수 있습니다. 일반적인 사용 사례로는 데이터베이스 쿼리를 수행하는 API와 같이 작업이 API 호출로 표현되는 경우가 있습니다. 이 예에서 명시적 검증 원칙은 API를 호출하는 행위자의 ID를 신뢰할 수 있는지 확인하는 데 그치지 않고, API에 전달된 매개변수가 적절한 제약 조건을 준수하는지 확인하는 등 API 작업이 올바르게 사용되었는지도 검증하는 데 활용할 수 있습니다.
성숙한 제로 트러스트 관점에서 ‘증명’은 거의 언제나 절대적이지 않습니다. ID 자격 증명은 도난당할 수 있고 디바이스는 침해될 수 있으며, API 매개변수 제약 조건은 불완전한 경우가 많습니다. 따라서 제로 트러스트 맥락에서 ‘신뢰도’라는 용어는 검증된 ID 또는 트랜잭션 매개변수가 적법할 가능성이 얼마나 높은지를 나타내는 지표에 가깝게 해석해야 합니다. 그러므로 트랜잭션을 허용하거나 차단하거나 추가로 검사할지 결정할 때 ‘신뢰도’ 수준은 유일한 요소가 아니라 여러 핵심 요소 중 하나로 간주해야 합니다.
최소 권한
트랜잭션에 참여하는 주체에 대해 허용 가능한 수준의 ‘신뢰’가 확립되면, 제로 트러스트 접근 방식에서는 해당 주체(일반적으로 요청자, 즉 ‘누가(Who)’)에게 시스템에서 의도된 작업을 수행하는 데 필요한 최소한의 권한만 부여해야 합니다. 이 원칙은 ‘포지티브 보안 모델’이라고도 하는 개념을 구현한 것으로, 기본적으로 모든 작업을 허용하지 않고 시스템 운영에 필요한 경우에만 특정 권한을 부여하는 접근 방식입니다. 예를 들어 예약 시스템에서는 익명 사용자가 항공편 일정을 조회할 수 있도록 허용하더라도, 애플리케이션 설계 요구 사항에 따라 익명 사용자의 항공편 예약은 허용하지 않을 수 있습니다.
이러한 권한은 개별 행위자 또는 행위자 그룹에 적용될 수 있습니다. 일반적으로 애플리케이션 사용자는 사람이거나 사람을 대신하는 프록시이며, “익명 사용자”, “고객”, “파트너”, “직원” 등의 그룹으로 분류됩니다. 신뢰도가 낮은 행위자 그룹은 일반적으로 인증을 통과하는 데 필요한 신뢰도 임계값도 낮지만, 접근할 수 있는 API의 수가 더 적거나 민감도가 낮은 API로 제한됩니다. 애플리케이션 내의 특정 서비스나 컨테이너처럼 애플리케이션 또는 해당 인프라 내부의 행위자에게는 “<X> 및 <Y> 컨테이너만 데이터베이스에 접근할 수 있고, <X>만 객체 저장소에 쓸 수 있지만 <Y>와 <Z>는 객체 저장소에서 읽을 수 있다”와 같이 보다 세분화된 권한이 부여되는 경우가 많습니다.
최소 권한 원칙을 구현할 때 중요하게 고려해야 할 점은 사전에 충분히 검토하여 각 상황에 맞게 보다 세밀하게 적용하도록 노력하는 것입니다.7 구체적으로, 모든 행위자 또는 특정 행위자 집단에 일률적인 권한 집합을 적용하기보다는, 성숙한 제로 트러스트 구현에서는 시도되는 어떤 작업인지 더 세분화하여 파악해야 합니다. 예를 들어, 매우 포괄적인 수준에서는 “파일 시스템 액세스” 권한을 부여할 수 있지만, “파일 시스템 읽기”는 실제로 필요한 권한을 더 엄밀하게 명시하므로 포지티브 보안 모델을 고품질로 구현할 수 있습니다.
마지막으로, 최소 권한 원칙을 더욱 정교하게 구현할 경우 행위자에게 부여된 권한을 절대적인 것으로 보지 않고 인증을 통해 확보된 신뢰도를 전제로 하는 것으로 간주함으로써, 성숙한 ‘명시적 검증’ 구현과 연계할 수 있습니다. 따라서 증명된 신원(누구)에 대한 신뢰도가 최소 임계값을 충족하는 경우에만 권한이 부여되며, 이 임계값은 시도되는 작업에 따라 달라집니다. 예를 들어 시스템 종료와 같이 특히 영향이 큰 작업을 수행하려면 해당 행위자가 관리자라는 신뢰도가 90% 이상이어야 할 수 있습니다. 이 예에서 시스템 종료를 시도할 때 신원에 대한 시스템의 신뢰도가 80%에 불과하다면, 시스템은 작업을 허용하기 전에 추가 검증을 요구하여 증명된 신원에 대한 신뢰도 점수를 높입니다.
지속적으로 평가
명시적 검증과 최소 권한은 핵심 개념입니다. 그러나 지속적인 평가 원칙은 이러한 원칙을 다음과 같은 관점에서 지속적으로 평가해야 한다는 점을 담고 있습니다.
- 모든 트랜잭션에는 검증 및 권한 부여가 적용되어야 합니다. 즉, “사용자 세션의 첫 번째 트랜잭션”이나 “Docker 컨테이너 워크로드를 통해 시작된 트랜잭션”처럼 일부 트랜잭션만 검사해서는 안 됩니다. 이는 당연하게 들릴 수 있지만, 잘못된 설계나 가시성 부족으로 인해 모든 트랜잭션을 검증하지 않는 제로 트러스트 구현이 많습니다. 이 영역에서 흔히 발생하는 문제는 제로 트러스트를 내부 주체가 아닌 외부 주체에만 적용하거나, 제로 트러스트 판정이 장기간 유효하다고 가정하는 데서 비롯됩니다.
- 평가의 핵심 요소인 행위자의 신원에 대한 신뢰도와 해당 행위자에게 허용되는 권한은 동적이며 변경될 수 있는 것으로 간주해야 합니다. 예를 들어, 관찰된 행동과 부가 메타데이터에 따라 신원에 대한 신뢰도는 시간이 지나면서 높아지거나 낮아질 수 있으므로, 신뢰도 기반 정책 역시 변화하는 신뢰도에 맞춰 동적으로 조정되어야 합니다. 또한 정책에 따라 이전에 부여된 권한 임계값이 잠시 후 철회되거나, 특정 작업에 필요한 최소 신뢰도가 변경될 수도 있습니다. 정책 변경 주기는 다양하여 느리게(사람이 수행하는 운영 프로세스의 시간 단위로) 또는 빠르게(자동화된 거버넌스 에이전트를 통해) 변경될 수 있지만, 시스템은 이러한 변경 사항에 동적으로 대응하고 이를 준수할 수 있어야 합니다.
침해를 전제로 하기
마지막 원칙은 건전한 경계심을 바탕으로, 공격자가 매우 강한 동기를 지니고 있다고 전제하는 데서 출발합니다. 구체적으로는 “이미 침해당했다고 가정하라”는 것으로, 여기서 “침해”란 “완벽한 정보와 실행 능력이 있었다면 거부했어야 하지만 실제로는 허용된 트랜잭션”을 의미합니다. 이러한 허용이 발생하는 근본 원인은 불완전한 정보(예: 탐지되지 않은 위조 자격 증명으로 인해 인증 과정에서 잘못 산출된 높은 신뢰도 점수), 구현상의 한계(예: “네트워크 연결 열기” 권한은 있지만 네트워크 대상의 지리적 위치에 따라 구분할 수 없는 등, 부여된 권한을 충분히 세분화하지 못하는 경우), 또는 제로 트러스트의 불완전한 구현(예: 내부에서 사용하는 취약한 오픈 소스 구성 요소에 제로 트러스트를 적용하지 않는 경우)일 수 있습니다.
따라서 제로 트러스트 사고방식은 이러한 침해의 영향을 가장 효과적으로 관리하고 최소화하는 방법도 고려해야 합니다.
이 원칙의 구현 방식은 다른 원칙보다 더 다양하지만, 일반적으로 다음과 같은 형태로 나타납니다:
- 먼저, 정책상 기술적으로 허용되지만 의심스러운 트랜잭션을 식별합니다. ‘의심스럽다’는 판단은 맥락에 따라 크게 달라지는 경우가 많지만, 일반적으로는 다음과 같이 해석할 수 있습니다. (a) 과거에 관찰된 동작과 크게 다른 비정상적인 트랜잭션, (b) 개별적으로는 정상이지만 전체적으로는 이례적인 트랜잭션 그룹(예: 파일을 읽고 쓰는 것은 일반적일 수 있지만 초당 1,000개의 파일을 읽고 쓰는 것은 이례적일 수 있음), 또는 (c) 원치 않으며 이전에는 관찰되지 않았던 시스템 영향과 연관된 작업(예: 특정 트랜잭션이 TOR 노드에 대한 네트워크 연결을 열거나 시스템 CPU 부하를 크게 증가시키는 패턴).
- 그런 다음 완전 자동화된 워크플로 또는 사람이 제어하고 머신러닝이 지원하는 하이브리드 워크플로를 통해 심층 분석을 수행하여 해당 트랜잭션이 유효하지 않은지 판단합니다. 해당 트랜잭션이 유효하지 않은 것으로 판단되면 완화 조치를 적용합니다. 이는 일반적인 정책 업데이트의 형태로 적용하거나, 추가적인 완화 계층으로서 다른 정책 기반 완화 조치를 보완하는 ‘최후의 안전장치’ 형태로 적용할 수 있습니다.
정책 기반 조정을 사용하기로 한 경우, 사용 가능한 정적 정책 도구를 활용하여 조정을 적용할 수 있습니다. 정책 기반 조정의 예로는 트랜잭션 단위의 액세스 제어 권한을 제한하는 것(즉, 더 이상 누가 무엇을 누구에게 하도록 허용할지를 허용하지 않음)이나, 특정 행위자(또는 행위자 집단)가 특정 작업을 수행할 때 더 엄격한 ‘입증 기준’(즉, MFA 또는 더 높은 신뢰도 점수 요구)을 적용하는 것이 있습니다.
그 대신 추가적인 ‘최후 방어선’ 계층을 사용하는 접근 방식을 선택한다면, 이 전략 역시 세분화된 방식이나 포괄적인 방식으로 구현할 수 있습니다. 가장 세분화된 전략은 특정 위험 대비 보상 비율을 초과하는 트랜잭션만 정확히 차단하는 것입니다. 다만 구현 과정에서 추가 분석이 필요할 경우, 허용되는 일부 트랜잭션에 허용하기 어려운 수준의 지연이 발생할 가능성도 있습니다. 그 대신 해당 행위자의 향후 트랜잭션을 샌드박스에서 실행하거나, 해당 행위자의 시스템 이용을 전면 금지하는 등 보다 포괄적인 전략을 사용할 수도 있습니다. 극단적인 경우에는 파일 I/O를 중단하는 것과 같이 훨씬 더 포괄적인 완화 조치가 적절할 수 있습니다.
물론 다른 모든 조건이 동일하다면, 일반적으로는 더 세분화된 백스톱 완화 조치가 바람직합니다. 그러나 사용 가능한 솔루션 기술의 제약에 따라 절충이 필요한 경우가 많으며, 대체로 거친 단위의 백스톱이라도 전혀 없는 것보다는 낫습니다. 예를 들어 의심되는 랜섬웨어를 방지하기 위한 거친 단위의 대응으로 파일 I/O를 비활성화할 경우, 아무런 조치를 취하지 않아 파일 시스템이 랜섬웨어에 의해 암호화되는 결과를 초래한다면, 그러한 대응의 부작용도 해당 행위자가 아무런 제약 없이 시스템에서 계속 활동하도록 내버려 두는 것보다는 나을 수 있습니다.
제로 트러스트: 실제로는 운영 이전부터 시작됩니다
제로 트러스트를 활용해 안전한 애플리케이션을 개발하기 위한 최적의 출발점은 당연하게도 개발 초기 단계입니다. 제로 트러스트 원칙을 실제 운영에 적용할 수 있게 하는 기본 원칙은 애플리케이션 개발 프로세스의 설계 단계부터 반영되어야 합니다. 따라서 CI/CD 파이프라인에 통합되는 운영 환경의 제로 트러스트 솔루션을 논의하려면, 설계 시 최우선으로 고려해야 할 이러한 기본 요소를 이해하는 것부터 시작해야 합니다.
이러한 기본 요소의 핵심에는 시스템 동작 간 상호작용에서 바람직하거나 의도된 동작을 명시하고, 편차를 감지하여 조치할 수 있는 충분한 가시성과 제어 기능을 갖추는 것이 포함되어야 합니다. 의도된 상호작용은 각 행위자(무엇을)가 각 대상(누가)에 대해 수행할 바람직한 일련의 작업(누구에게)을 정의하는 데 사용됩니다. 다만 일부 시나리오와 환경에서는 의도된 상호작용 패턴을 알 수 없을 수도 있습니다. 이러한 경우 조직은 더 높은 수준의 가시성을 활용하여 적절한 상호작용 집합을 ‘발견’하고,8 이를 정책으로 체계화할 수 있습니다.
예를 들어, 애플리케이션의 외부 API에 대한 ID 기반 액세스 제어에 중점을 두는 오늘날의 ZTNA 솔루션에서는 인증 API에 대한 가시성과 제어 기능이 필요합니다. 또한 클라우드 워크로드 보호 플랫폼(CWPP)의 맥락에서 침해된 컨테이너 워크로드를 탐지하려면 각 컨테이너가 수행하는 작업에 대한 가시성이 필요하며, 실시간 대응이 필요한 경우에는 이러한 가시성도 실시간으로 확보되어야 합니다.
다음은 설계 프로세스에 포함해야 할 기본 고려 사항과 관련된 상위 수준의 ‘범주’ 목록이며, 각 핵심 사항에 대해 생각해 볼 구체적인 질문을 제시하는 세부 항목도 함께 제공합니다:
- 시스템의 블랙박스 인터페이스, 즉 입력과 출력은 무엇인가?
- 애플리케이션과 상호 작용하는 사용자 유형(관리자, 인증된 사용자, 인증되지 않은 사용자, 파트너)은 누구이며, 이들은 무엇을 해야 하나요?
- 모든 통신이 정의된 API를 통해 이루어지나요? 아니면 ‘원시’ 네트워크 통신이나 데이터베이스 또는 객체 저장소와 같은 데이터 저장소를 통한 통신도 있나요?
- API 통신의 경우, API와 상호 작용할 수 있는 사용자와 해당 상호 작용에 적용되는 제약 조건(예: 매개변수 제약, 요청 속도 제한 등)이 얼마나 명확하게 정의되어 있습니까?
- 모든 네트워크 통신에서 전송되는 모든 데이터가 암호화됩니까?
- “원시” 데이터 인터페이스(예: 객체 저장소 또는 데이터베이스를 통해 클라이언트와 애플리케이션 간에 정보가 공유되는 경우)가 있다면, 누가 언제 어떤 정보에 액세스했는지 추적할 수 있는 감사 로그가 있습니까?
- 마찬가지로 내부적인 ‘화이트박스’ 수준에서, 외부에서 제공되는 서비스를 포함해 전체 애플리케이션을 구성하는 구성 요소 서비스는 무엇이며, 이들은 어떻게 통신합니까?
- 이러한 서비스는 어떻게 통신합니까? 사용되는 API는 무엇이며, 이러한 상호작용에는 어떤 제약 조건(역할, 액세스 제어, 호출 빈도 제한, 매개변수 등)이 적용됩니까?
- 위에서 언급한 것과 마찬가지로, API의 공식성 및 제약 조건과 통신 암호화에 대해서도 유사한 질문이 제기됩니다.
- “내부” 통신(예: 워크로드/컨테이너 간 통신)은 공유 메모리 및 파일 시스템 기반 인터페이스를 사용할 가능성이 더 높으므로, 이러한 인터페이스를 모두 식별해야 합니다.
- 이러한 서비스는 어떻게 통신합니까? 사용되는 API는 무엇이며, 이러한 상호작용에는 어떤 제약 조건(역할, 액세스 제어, 호출 빈도 제한, 매개변수 등)이 적용됩니까?
- 시스템은 블랙박스 인터페이스와 내부 통신 경로에 대한 접근을 제한하기 위해 어떤 제어 메커니즘을 제공합니까?
- 특정 API를 호출할 수 있는 주체와 역할, 그리고 정책 위반 시의 조치를 명시한 정책이 있습니까? 마찬가지로 잘못된 매개변수를 사용하거나 지나치게 높은 빈도로 호출하는 등 API의 모든 오용을 탐지하고 완화할 수 있는 수단이 있습니까? 이러한 정책을 다른 시스템에서 제공하는 상황별 입력을 기반으로 동적으로 업데이트할 수 있습니까?
- 마찬가지로, 워크로드 간 통신의 다른 형태(파일 시스템, 객체 저장소, 데이터베이스 테이블)에 대해서도 누가 어떤 파일/저장소/테이블에 액세스할 수 있는지를 제한하고 해당 리소스의 오용(예: “SELECT * from <table>”)을 방지하는 정책이 있습니까?
- 블랙박스 인터페이스와 내부 통신 경로 모두에 대한 액세스를 제한할 수 있도록 시스템에서는 어떤 가시성 정보(대시보드, 로그, 통계)를 제공합니까?
- 시스템에서 누가 언제 어떤 API를 호출하는지 식별할 수 있습니까? 이 데이터는 보관됩니까? 그렇다면 보관 기간은 얼마나 됩니까? 이러한 데이터는 얼마나 신속하게(실시간, 매시간 등) 제공됩니까? 데이터는 얼마나 쉽게 활용할 수 있습니까? 비정형 파일 로그입니까, 보안 이벤트 및 인시던트 관리(SEIM) 서비스로 전송할 수 있는 구조화된 JavaScript Object Notation(JSON)입니까, 아니면 빅데이터 데이터베이스 테이블에 기록된 데이터입니까?
- 메모리, 파일, 객체, 데이터베이스 등 다른 통신 경로에 대해서도 동일한 질문에 대한 답은 무엇입니까? 누가 무엇을 하고 있습니까? 해당 데이터는 어떻게 노출됩니까?
- 통신 경로 외에, 리소스의 과도한 할당이나 소비를 방지하기 위해 시스템에서 제공하는 다른 제어 기능과 가시성에는 어떤 것이 있습니까?
- 시스템에서 CPU, 메모리, 대역폭, Pod 스케일링 등의 리소스 사용량 메트릭을 확인할 수 있습니까? 그렇다면 어느 정도의 세분성으로 확인할 수 있으며, 해당 데이터는 얼마나 쉽게 활용할 수 있습니까?
- 시스템에 리소스 사용량을 제어하거나 제한하는 보호 장치가 있습니까? 예를 들어 워크로드별 메모리/CPU/파일 I/O 제한, 프로세스 생성 시스템 호출 추적, Pod의 스케일업/스케일아웃 제한, 다른 서비스를 호출하는 API의 요청 속도 제한 등이 있습니까?
이러한 질문을 명시적으로 제기하면 제로 트러스트를 구현하기 위한 기반에 어떤 공백이 있는지 파악하는 데 도움이 됩니다. 설계 초기에 질문을 던지는 것만으로도 최소한의 추가 설계 작업을 통해 해당 공백이 해소되는 경우가 많습니다. 또한 공백이 계속 남아 있을 수 있는 경우에도 이를 인지하는 것만으로 보안을 더욱 강화해야 할 부분을 파악하거나 취약한 공격 표면을 식별하는 데 도움이 됩니다.
이러한 사전 보안 개발 분석은 제로 트러스트 사고방식의 핵심 요소입니다. 하지만 오늘날 제로 트러스트에 대한 관심은 대부분 초기 설계 이후에 발생하는 일에 집중되어 있으며, 대다수 기업 역시 제로 트러스트의 설계 이후 측면에 중점을 두고 있습니다. 그러나 설계 단계에서 제로 트러스트를 효과적으로 구현하기 위한 요구 사항을 신중하게 고려하면 애플리케이션 배포 후 ‘허점을 메우기’ 위해 훨씬 더 많은 추가 작업을 들이는 일을 방지할 수 있습니다.
완화 조치 고려 사항: 적시성, 오탐/미탐 및 위험
이러한 사고방식의 전제인 ‘침해 가정’이 의미하듯, 보안 실무자는 충분한 동기를 가진 공격자가 결국 악의적인 트랜잭션을 실행하는 데 성공할 것이라고 가정해야 합니다. 이는 정책 규칙에는 부합했지만 이상적인 환경이라면 허용되지 않았어야 할 ‘누가 누구에게 무엇을 하는가’의 사례입니다. 이러한 경우에는 앞서 ‘침해 가정’ 섹션에서 설명한 것처럼, 일반적으로 트랜잭션 패턴과 시스템 부작용을 관찰하여 해당 사례를 찾아낼 수 있는 효과적인 ‘최후 방어선’ 메커니즘을 마련하는 데 초점을 맞추게 됩니다.
그러나 ID라는 개념과 마찬가지로, 특정 트랜잭션이 악의적인지 여부를 완벽하게 판단하는 것은 불가능합니다. 따라서 이상적인 제로 트러스트 솔루션은 ID의 경우와 마찬가지로 트랜잭션의 적법성에 대한 ‘신뢰도’ 점수를 제시해야 합니다. 예를 들어 데몬이 10초 동안 정상적인 파일 처리 속도의 10배로 파일을 읽고 쓰는 것이 관찰되면 악의성에 대한 신뢰도 점수가 70%로 산정될 수 있지만, 그 속도가 100배로 증가해 1분 동안 지속되면 신뢰도가 95%까지 높아질 수 있습니다. 이 예에서 향후 파일 쓰기를 차단하는 교정 조치를 취하더라도 잘못된 대응, 즉 ‘오탐’일 가능성(30% 또는 5%)은 여전히 존재합니다. 따라서 교정 조치 여부를 결정할 때는 오탐의 위험과 잠재적으로 악의적인 동작을 허용할 경우 발생할 수 있는 영향을 함께 고려해야 합니다.
이 예시의 요점은 사용자에게 드러나는 교정 조치를 취할지에 관한 모든 결정이 실제로는 의심스러운 활동과 관련된 모든 위험, 비용 및 이점을 고려하는 비즈니스 결정이라는 점을 강조하는 데 있습니다. 트랜잭션에 추가적인 마찰을 도입하면 가치를 얻지 못할 가능성이 커지지만, 개입하지 않거나 마찰을 추가하지 않으면 침해 위험이 발생합니다. 따라서 이러한 경우 조치를 취할지 여부는 다음 세 가지 입력 요소에 따라 결정됩니다:
- 악의적일 가능성이 있는 트랜잭션이 계속되도록 허용할 경우 어떤 위험이 있습니까?
이러한 위험은 은행 자금 이체와 같은 직접적인 금전적 손실일 수도 있고, 핵심 기록이 암호화되어 몸값을 요구받는 경우와 같은 운영상의 간접 비용이나 웹사이트 변조와 같은 브랜드 이미지 훼손 비용일 수도 있습니다. 또한 고객의 개인정보 유출로 인해 법적 비용이나 규정 준수 비용이 발생할 수도 있습니다. 본질적으로 위험을 평가하는 것은 거버넌스의 문제이며, 올바른 거버넌스는 애플리케이션의 위험을 파악하고 정량화합니다. - 교정 조치를 취할 경우 어떤 부작용이 발생합니까?
부작용은 (a) 추가되는 마찰과 (b) 영향 범위라는 두 가지 측면으로 설명할 수 있습니다. 마찰은 정상적인 트랜잭션을 진행하기가 얼마나 더 어려워지는지를 의미하며, 약간 더 불편해지는 수준(예: 추가 인증 단계)부터 아예 불가능해지는 수준(트랜잭션 자체가 허용되지 않음)까지 다양할 수 있습니다. 영향 범위는 서로 독립적인 다른 트랜잭션도 영향을 받는지, 영향을 받는다면 얼마나 많은 트랜잭션이 해당되는지를 의미합니다. 예를 들어 특정 사용자를 차단하면 해당 사용자에게만 영향을 미치지만, 로깅 서비스를 중단하면 모든 사용자와 트랜잭션에 대한 감사 가능성에 영향을 미칩니다. - 해당 트랜잭션이 악의적이라는 판단을 얼마나 확신할 수 있는가?
일반적으로 확신을 높이려면 더 많은 데이터 포인트를 수집하고 더 다양한 데이터 소스를 서로 연계해 분석해야 하며, 두 작업 모두 시간이 걸립니다. 따라서 실제로는 이러한 절충점을 두고 “조치를 취하기로 결정하기 전에 얼마나 오래 지켜봐야 하는가?”를 고민하게 되는 경우가 많습니다.
따라서 제로 트러스트 전략은 침해 사고가 발생할 수밖에 없다는 사실을 전제로 해야 하지만, 신중한 접근 방식이라면 허용되었으나 의심스러워 보이는 트랜잭션의 조치 여부를 결정할 때 위험과 보상을 비교해야 합니다. 이때 다양한 애플리케이션 트랜잭션의 위험 수준과 조치 적용에 따른 결과를 고려하고, 위험 수준이 예상되는 비즈니스 이익보다 큰 경우에만 조치를 적용해야 합니다.
1 https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
2 https://csrc.nist.gov/publications/detail/sp/800-207/final
3 https://www.cisa.gov/zero-trust-maturity-model
4 https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF
5 https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf
6 https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf
7 이러한 사전 고려는 뒤에서 설명하듯이 설계 단계에서 시작됩니다.
8 또는 적어도 시스템에 필요해 보이는, ‘적절하다고 여겨지는’ 상호작용의 집합을 의미합니다. 관찰을 통해 도출한 상호작용의 집합은 불완전하거나 기존의 위험을 내포할 가능성이 항상 있습니다. 따라서 설계 단계에서 미리 고려하는 것이 언제나 바람직합니다.
2022년 5월 4일 게시