Unit 42 클라우드 ID 연구, 권한 기반 보안의 한계를 드러내다

Unit 42는 4만 개 이상의 클라우드 ID를 분석해, 권한 검토만으로는 해결할 수 없는 충돌을 드러냈다. Unit 42의 클라우드 ID 연구는 보안팀이 ID가 할 수 있는 일뿐 아니라 실제로 수행하는 일을 이해해야 한다고 주장한다.

2026년 9월 14일 공개된 이 연구는 2개월의 관찰 기간 동안 125개 클라우드 환경에서 수집한 활동을 매핑했다. 이 모델은 AWS CloudTrail에 기록된 작업을 기준으로 ID를 그룹화한다. 각 그룹은 관리자, 백업 에이전트, 보안 도구, DevOps 사용자, 지속적 배포 시스템 등 식별 가능한 역할에 해당한다.

핵심 경쟁 구도는 행동 기반 역할 추론과 정적 ID 라벨 간의 대립이다. 공격자가 ID의 용도를 바꾼 뒤에도 신뢰받는 이름, 익숙한 정책 또는 정상 자격 증명은 그대로 남을 수 있다. Unit 42는 관찰된 행동을 역할 맥락으로 전환하고, 그 맥락에서 벗어나는 활동을 활용해 자동화된 탐지를 개선할 것을 제안한다.

Unit 42는 이름이 아닌 행동으로 ID를 매핑했다

이 연구는 API 활동을 ID의 실제 업무 역할을 보여주는 증거로 취급해 ID 분석 방식을 바꾼다.

행동 기반 ID 연구는 실무적인 문제에서 출발한다. 오늘날 클라우드 환경에는 직원, 애플리케이션, 배포 파이프라인, 보안 제품, 자율 에이전트가 존재한다. 이들의 이름과 할당된 권한만으로는 현재 기능을 파악하기 어려운 경우가 많다.

“backup”이라는 이름의 ID는 매일 밤 하나의 스토리지 버킷을 읽는 것이 정상일 수 있다. 하지만 이후 사용자 목록을 열거하거나 정책을 검사하거나 컴퓨팅 리소스를 생성할 수도 있다. 이름과 권한이 바뀌지 않았더라도 이러한 행동은 중요하게 다뤄져야 한다.

Unit 42는 연구 기간 중 각 ID가 호출한 AWS 작업을 통해 해당 ID를 표현했다. 이후 연구진은 참여 환경 전반에서 이러한 행동 프로필을 비교했다. 유사한 작업 조합을 수행한 ID는 서로 다른 그룹으로 묶였다.

그 결과 지도에는 약 2만 개의 ID를 대표하는 30개의 대형 클러스터가 포함됐다. 연구진은 이 클러스터들을 관리, 인프라 자동화, 네트워킹, 보안, 백업, FinOps, 데이터 서비스 등 반복적으로 나타나는 기능과 연결했다.

관리자 클러스터는 가장 분명한 사례를 제공했다. 이 클러스터에는 100개가 넘는 클라우드 프로젝트 전반의 약 5,000개 ID가 포함됐다. 이 가운데 약 94%는 ConsoleLogin 이벤트를 생성했으며, 다른 클러스터에서는 이 비율이 1% 미만이었다.

약 60%는 GetCostAndUsage 및 GetCostForecast를 포함해 일반적인 콘솔 활동과 연관된 작업도 호출했다. 이러한 작업은 더 제한된 API 집합을 사용하는 머신 ID와 대화형 관리자를 구분하는 데 도움이 됐다.

이 증거가 중요한 이유는 단일 이벤트만으로 의도를 확정할 수 없기 때문이다. ConsoleLogin은 대화형 로그인을 나타내지만, 사용자가 관리자라는 점을 증명하지는 않는다. 비용 관리 요청은 콘솔이 로드될 때 자동으로 발생할 수도 있다.

Unit 42는 하나의 편리한 신호에 의존하지 않기 위해 네 가지 분석 형태를 결합했다. 클러스터별 작업 빈도, 구별되는 작업, ID 속성, 반복되는 명명 패턴을 검토했다.

특히 하나의 명명 패턴이 많은 사실을 드러냈다. AWS IAM Identity Center는 표준 권한 세트를 통해 AdministratorAccess가 할당될 때 식별 가능한 접두사를 생성한다. 이 접두사는 관리자 클러스터 내부에서 자주 나타났으며, 행동 기반 해석을 뒷받침했다.

이름은 보조 증거일 뿐 모델의 기반은 아니었다. 이 구분은 방법론이 ID에 이미 붙어 있는 라벨을 단순히 다시 발견하는 일을 막는다. 또한 이름이 모호하거나 오래됐거나 의도적으로 속이도록 만들어진 경우에도 접근법의 유용성을 높인다.

이 연구는 새롭게 관찰된 침해 사고나 취약점을 발표하는 것이 아니다. 실제 운영 텔레메트리를 기반으로 구축된 탐지 설계를 제시한다. 클라우드 ID 분류를 더 확장 가능하고 설명 가능하게 만든다는 점에서 뉴스 가치가 있다.

대부분의 ID 인벤토리는 누가 자격 증명을 소유하는지, 그리고 해당 정책이 어떤 작업을 허용하는지를 답한다. Unit 42는 세 번째 질문을 더한다. ID의 활동은 어떤 기능적 역할을 보여주는가? 이 추가 계층이 연구 전체를 이끄는 긴장을 만든다.

정적 권한은 가장 중요한 질문을 열어 둔다

권한은 가능한 일을 알려주지만, 행동은 ID가 현재 어떤 기능을 실제로 사용하고 있는지 드러낸다.

ID 및 액세스 관리 정책은 여전히 필수적이다. 이 정책은 주체가 시크릿을 읽고, 인스턴스를 시작하고, 로깅을 수정하거나, 다른 역할을 수임할 수 있는지를 결정한다. 최소 권한 원칙은 탈취된 자격 증명이 초래할 수 있는 피해를 줄인다.

하지만 정책 분석만으로 운영 현실을 완전히 설명할 수는 없다. 조직은 배포나 긴급 작업이 차단되는 것을 피하기 위해 광범위한 액세스 권한을 자주 부여한다. 오래된 역할에는 프로젝트, 팀, 책임이 바뀌면서 권한도 축적된다.

일부 과도한 권한을 가진 ID는 수년간 문제없이 운영된다. 반면 다른 ID는 자격 증명이 탈취된 후 가치 있는 진입점이 된다. 두 경우 모두 권한 문서는 위험해 보이지만, 어느 ID가 기존 기능을 벗어나 행동하기 시작했는지는 보여주지 못한다.

행동 맥락은 이 빠진 구분을 제공한다. 하나의 보호된 대상에 반복적으로 액세스하는 백업 프로세스는 좁은 기준선을 형성한다. 리소스 열거, ID 탐색, 관리 변경은 그 기준선에서 의미 있는 이탈이 된다.

동일한 API 호출도 다른 맥락에서는 다른 위험도를 가질 수 있다. ListBuckets는 보안 인벤토리 제품에서는 예상되는 활동일 수 있다. 하지만 과거에 하나의 버킷에 애플리케이션 로그만 기록해 온 워크로드에서 발생한다면 더 면밀한 검토가 필요하다.

이 때문에 Unit 42의 클라우드 ID 연구는 보안 태세에만 초점을 둔 보안 프로그램에 압박을 가한다. 클라우드 보안 태세 관리 도구는 과도한 권한과 구성 문제를 식별한다. 그러나 관찰된 행동이 ID의 실제 업무와 일치하는지를 자동으로 설명하지는 않는다.

공격자는 이 간극에서 이득을 얻는다. 기존 자격 증명, 상속된 정책, 무해해 보이는 리소스 이름을 활용할 수 있다. 그러면 그 활동은 보안팀이 이미 알고 있는 ID 아래에서 나타난다.

위장은 계정 이름을 바꾸지 않아도 가능하다. 공격자는 방어자가 신뢰하는 ID를 통해 악의적인 작업을 수행하기만 하면 된다. 행동이 바뀐 후에도 정적 인벤토리는 그 신뢰를 유지할 수 있다.

AWS는 이미 관리형 위협 탐지 서비스에 행동 분석을 적용하고 있다. 이상 탐지 문서에 따르면 GuardDuty는 CloudTrail 이벤트의 필드를 프로파일링해 비정상적이거나 승인되지 않은 활동을 식별한다.

GuardDuty는 요청 ID, API, 위치 등의 요소도 고려한다. 탐지 결과는 자격 증명 액세스, 탐색, 지속성 확보, 권한 상승, 유출, 영향과 연관된 활동을 식별할 수 있다.

이 기존 기능은 더 넓은 방향성을 뒷받침하지만, Unit 42의 기여를 없애지는 않는다. 관리형 탐지는 일반적으로 공급자의 모델과 규칙이 의심스러운 활동을 식별한 후 결과를 제시한다. 고객은 정확한 기준선이나 분류 과정에 대한 가시성이 제한적이다.

Unit 42는 방어자가 이해하고 재사용할 수 있는 기능적 역할을 부여하는 데 초점을 맞춘다. 이 모델은 ID가 관리자, 배포 시스템, 스캐너 또는 백업 서비스처럼 행동하는지를 묻는다. 이 역할은 후속 탐지를 강화할 수 있다.

이 구분은 트리아지 방식도 바꾼다. 익숙하지 않은 API 호출이 자동으로 악성인 것은 아니며, 일반적인 API 호출이 자동으로 무해한 것도 아니다. 분석가는 행동을 ID에 기대되는 기능과 비교해야 한다.

이는 클라우드 보안 공급업체, 내부 탐지팀, ID 거버넌스 플랫폼에 압박을 만든다. 각 주체는 권한 데이터를 런타임 활동과 연결해야 한다. 한쪽만 보여주는 제품은 분석가가 다른 쪽을 수동으로 재구성하도록 남겨 둔다.

비인간 ID가 늘어날수록 이러한 압박은 커진다. 워크로드, CI/CD 시스템, 서비스 계정, 자동화 도구, AI 에이전트는 지속적으로 활동할 수 있다. 이들의 행동량은 수동 분류를 비현실적으로 만든다.

Unit 42의 답은 권한을 버리는 것이 아니다. 허용된 기능과 관찰된 작업을 결합하는 것이다. 두 관점은 서로 다른 질문에 답하며, 함께 평가될 때 더 유용해진다.

Unit 42 클라우드 ID 클러스터링의 작동 방식

Unit 42는 비지도 클러스터링으로 행동 역할을 발견한 뒤, 그 발견을 더 단순한 분류기로 정제한다.

첫 단계는 클라우드 감사 로그에서 시작된다. AWS CloudTrail은 ID와 관련 API를 포함해 사용자, 역할, 서비스가 생성한 이벤트를 기록한다. AWS는 CloudTrail 이벤트 참조에서 이러한 필드를 설명한다.

Unit 42는 각 ID를 불리언 벡터로 변환한다. 각 위치는 사용 가능한 작업 하나를 나타내며, true 또는 false는 관찰 기간 동안 해당 ID가 그 작업을 호출했는지를 기록한다.

이 과정은 다루기 어려운 데이터세트를 만든다. 연구에 따르면 AWS는 약 240개 서비스에 걸쳐 15,000개 이상의 가능한 작업을 제공한다. 대부분의 ID는 그중 일부만 호출하므로 벡터는 크고 대부분 비어 있게 된다.

파이프라인은 이러한 벡터를 축소하기 위해 UMAP(Uniform Manifold Approximation and Projection)을 사용한다. UMAP은 의미 있는 이웃 구조를 보존하려 시도하면서 고차원 관측값을 더 작은 표현으로 변환한다.

연구진은 거리 측정값으로 코사인 유사도를 사용했다. 이 측정값은 두 벡터의 절대 크기보다 방향을 비교한다. 어느 ID가 더 많은 활동을 생성했는지보다 ID들이 어떤 작업을 공유하는지를 강조한다.

한 번의 UMAP 실행은 32개의 연속값을 포함한 밀집 표현을 생성했다. 별도의 실행은 시각화를 위해 ID를 2차원으로 투영했다. 이 두 출력은 서로 다른 목적을 가지며 상호 교환 가능한 것으로 취급해서는 안 된다.

이후 밀집 표현은 높은 점 밀도 영역을 식별하는 클러스터링 방식인 HDBSCAN으로 입력된다. 고정된 그룹 수를 요구하는 알고리즘과 달리, HDBSCAN은 클러스터를 발견하고 이례적인 점을 노이즈로 표시할 수 있다.

두 방법 모두 확립된 연구 기반을 갖고 있다. 원본 UMAP 논문은 차원 축소 기법을 설명하며, HDBSCAN 논문은 계층적 밀도 기반 클러스터링을 다룬다.

ID가 클러스터 할당을 받은 뒤에도 분석가는 각 그룹을 해석해야 한다. 클러스터 식별자에는 “관리자”나 “백업 서비스” 같은 라벨이 자동으로 붙지 않는다. 따라서 연구는 역할을 추론하기 위해 여러 테스트를 적용한다.

작업 빈도는 어떤 API가 클러스터 전반에 나타나는지를 보여준다. 클래스 기반 점수화 방식은 하나의 그룹 안에서는 자주 발생하지만 다른 곳에서는 드문 작업을 식별한다. 이를 통해 단순히 널리 사용되는 API와 실제로 구별되는 신호를 분리할 수 있다.

속성 매핑은 또 다른 관점을 제공한다. 연구진은 특정 서비스를 사용하거나, 특정 작업을 호출하거나, 반복되는 문자열을 포함하는 ID를 강조 표시할 수 있다. 집중된 속성은 제안된 기능적 라벨을 뒷받침하는 증거를 제공한다.

마지막으로, 부분 문자열 마이닝은 ID 이름 전반에서 반복되는 조각을 식별합니다. 이를 통해 배포 시스템이나 ID 관리 제품이 만들어낸 규칙을 발견할 수 있습니다. 단일 ID의 이름만으로 역할을 단정하는 것보다 안전합니다.

이러한 방법을 함께 활용하면 시각적 패턴을 해석 가능한 행동 범주로 전환할 수 있습니다. 이 해석은 여전히 분석적 판단이지만, 여러 형태의 증거에 기반합니다.

따라서 Unit 42의 클라우드 ID 클러스터링 접근법은 마법 같은 ID 해독기가 아닙니다. 반복되는 운영 패턴을 찾기 위한 구조화된 파이프라인입니다. 이러한 패턴을 실제 조직 기능과 연결하는 일은 여전히 인간 분석가의 몫입니다.

이 한계는 강점이기도 합니다. 보안팀은 클러스터가 특정 레이블을 받은 이유를 검토할 수 있습니다. 또한 분류를 프로덕션에 적용하기 전에 고유한 작업이 자체 환경과 일치하는지 검증할 수 있습니다.

이 과정은 탐색적 지도 제작과 닮아 있습니다. 비지도 학습은 미리 정의된 역할 목록을 받지 않고 지도를 그립니다. 이후 분석가가 어떤 영역이 알려진 운영 행동에 해당하는지 식별합니다.

하지만 전체 매핑 파이프라인을 반복 실행하면 컴퓨팅 및 운영 비용이 발생합니다. 데이터 세트와 매개변수가 바뀌면서 클러스터 식별자가 계속 달라질 수도 있습니다. Unit 42는 다음 단계에서 이 문제를 다룹니다.

진정한 진전은 모델에서 SQL로 이어지는 경로에 있다

운영상 가장 중요한 단계는 발견된 클러스터를 기존 데이터 시스템이 실행할 수 있는 작고 해석 가능한 규칙으로 정제하는 것입니다.

유용한 클러스터를 식별한 뒤 Unit 42는 원래의 불리언 작업 벡터를 대상으로 로지스틱 회귀 분류기를 학습합니다. 로지스틱 회귀는 개별 특성이 관측값이 선택된 클래스에 속할 가능성을 어떻게 바꾸는지 계산합니다.

팀은 관리자 행동을 위한 분류기 하나와 보안 도구를 위한 또 다른 분류기를 학습할 수 있습니다. 그러면 새 ID를 완전한 행동 맵을 다시 구축하지 않고도 관련 모델에 따라 평가할 수 있습니다.

Unit 42는 L1 정규화도 적용합니다. 이 페널티는 도움이 되지 않는 특성의 계수를 0에 가깝게 만듭니다. 남은 작업은 훨씬 더 작은 규모의 긍정적 및 부정적 지표 집합을 구성합니다.

이 희소성은 보안 운영에 중요합니다. 수천 개의 상호작용 특성으로 이루어진 모델은 검사, 설명, 재현이 어렵습니다. 수십 개의 가중 작업을 기반으로 한 분류기는 운영 환경에 적용하기가 훨씬 쉽습니다.

분석가는 어떤 API 호출이 ID를 관리자 분류 쪽으로 이동시키는지 확인할 수 있습니다. 반대로 어떤 작업이 그 분류에서 멀어지게 하는지도 볼 수 있습니다. 이러한 가시성은 로직이 경보에 영향을 미치기 전 검토를 지원합니다.

연구진은 이 가중 로직을 표준 SQL 쿼리로 표현할 수 있다고 말합니다. 대부분의 보안 조직은 이미 클라우드 로그를 데이터 웨어하우스, 보안 데이터 레이크 또는 분석 플랫폼에 중앙화하고 있습니다. SQL은 배포 장벽을 낮춥니다.

그렇다고 전체 머신러닝 워크플로가 사라지는 것은 아닙니다. 원래의 클러스터링 단계는 여전히 의미 있는 그룹을 발견하고 학습 레이블을 제공합니다. 경량 분류기는 이전 분석을 국지적으로 근사한 것입니다.

이 구분은 기사가 오해를 부를 수 있는 결론에 이르지 않도록 합니다. Unit 42는 모든 클라우드 보안 문제를 SQL 문 하나로 축소한 것이 아닙니다. 학습된 하나의 분류 경계가 어떻게 투명한 쿼리 로직이 될 수 있는지를 보여줬습니다.

이 설계는 맞춤형 머신러닝과 경직된 수기 규칙 사이에서 실용적인 절충안을 제시합니다. 완전히 수동적인 탐지는 분석가가 관련 조합을 사전에 예측해야 합니다. 복잡한 모델은 비용이 많이 들고 설명하기 어려울 수 있습니다.

행동 클러스터링은 관측 데이터에서 후보 패턴을 발견합니다. 이후 희소 분류기는 선택된 패턴을 검사 가능한 형식으로 보존합니다. 탐지팀은 탐색 파이프라인을 지속적으로 유지하지 않고도 재사용 가능한 맥락을 얻습니다.

백업 서비스 사례를 생각해 봅시다. 분류기는 정기적인 백업 활동과 연관된 작업을 인식하고 기능적 역할을 할당할 수 있습니다. 그러면 탐지 로직은 관리형 검색이나 정책 변경을 그 역할과 충돌하는 행동으로 처리할 수 있습니다.

경보는 단순한 희귀 이벤트가 아니라 불일치를 설명하기 때문에 더 강력합니다. “백업 ID가 관리자 행동을 수행했다”는 “비정상 API가 관찰됐다”보다 분석가에게 더 많은 맥락을 제공합니다. 이는 행위자의 기준선과 의심스러운 행동을 연결합니다.

같은 접근법은 CI/CD 시스템에도 적용할 수 있습니다. 배포 ID는 예측 가능한 서비스 전반에서 반복적인 인프라 작업을 수행하는 경우가 많습니다. 자격 증명 악용은 콘솔 활동, 광범위한 검색 또는 무관한 데이터 접근을 초래할 수 있습니다.

보안 제품 역시 유용한 또 다른 범주입니다. 이들은 정기적으로 리소스를 열거하고 구성을 검사합니다. 역할 맥락이 없으면 이러한 행동은 공격자의 정찰처럼 보일 수 있으며, 피할 수 있는 노이즈를 발생시킬 수 있습니다.

따라서 기능적 분류는 서로 다른 두 가지 오류를 줄일 수 있습니다. 광범위한 접근이 알려진 스캐너와 일치할 때 오탐을 낮출 수 있습니다. 제한된 목적의 자동화가 관리자처럼 행동하기 시작할 때는 의심도를 높일 수 있습니다.

이 지점에서 행동 기반 역할 추론은 정적 레이블과 가장 직접적으로 경쟁합니다. “security-scanner”와 같은 이름은 분석가에게 구성을 신뢰하라고 요구합니다. 반면 관측된 패턴은 해당 ID가 계속 그 기능을 수행하고 있다는 증거를 제공합니다.

이 방법은 권한 분석도 보완합니다. 보안 스캐너는 과도한 권한을 유지한 채 정상적으로 행동할 수 있습니다. 런타임 탐지에서 의심스러운 점을 찾지 못하더라도 포스처 도구는 이러한 노출을 계속 보고해야 합니다.

반대로, 권한이 엄격히 제한된 ID도 허용된 범위 안에서 예기치 않게 행동할 수 있습니다. 정책 검토에서 위반 사항이 발견되지 않더라도 행동 모니터링은 이러한 변화를 표시해야 합니다.

따라서 이 모델은 대체 통제가 아니라 추가 데이터 계층을 만듭니다. 권한은 경계를 정의합니다. 클러스터링은 역할을 추론합니다. 탐지 로직은 조사가 필요한 이탈을 식별합니다.

Unit 42는 이 방법론이 AWS CloudTrail을 넘어 다른 클라우드 제공업체, Kubernetes 및 소프트웨어 서비스로 확장될 수 있다고 말합니다. 이러한 시스템도 ID와 연결된 감사 이벤트를 생성하므로 이 확장은 타당합니다.

하지만 이식성에는 새로운 검증이 필요합니다. Azure, Google Cloud, Kubernetes 및 SaaS 플랫폼은 서로 다른 이벤트 어휘와 ID 구조를 노출합니다. AWS 작업을 기반으로 학습한 분류기를 수정 없이 그대로 이전할 수는 없습니다.

이 연구가 아직 입증하지 못한 것

이 데이터 세트는 일관된 행동 클러스터를 보여주지만, 조직·제공업체·변화하는 워크로드 전반에서 보편적인 탐지 정확도를 확립하지는 못합니다.

Unit 42는 4만 개가 넘는 ID와 125개 환경을 포함한 상당한 규모를 보고합니다. 이 범위는 반복되는 행동 역할이 여러 클라우드 환경에 걸쳐 나타난다는 주장을 뒷받침합니다. 하지만 모든 프로덕션 질문에 답하지는 못합니다.

이 보고서는 정밀도, 재현율, 오탐률 및 식별된 모든 역할에 대한 성능을 포함하는 완전한 벤치마크를 제공하지 않습니다. 로지스틱 회귀가 선택된 클러스터를 정확히 식별할 수 있다고 말하지만, 공개 독자가 모든 결과를 독립적으로 재현할 수는 없습니다.

이 연구는 두 달간의 관찰 기간에도 초점을 맞춥니다. 이 기간은 반복 작업을 포착하지만, 일부 정상 ID는 분기별 복구 테스트, 마이그레이션 또는 인시던트 대응 때만 활동합니다. 짧은 기준선은 드물지만 승인된 작업을 잘못 분류할 수 있습니다.

불리언 벡터는 또 다른 절충을 도입합니다. 작업이 발생했는지는 보존하지만, 발생 빈도는 제외합니다. API를 한 번 호출한 ID와 수천 번 호출한 ID는 해당 특성에서 동일하게 보입니다.

이 단순화는 차원 수를 제어하고 해석 가능성을 지원합니다. 그러나 일상 업무와 악용을 구분하는 볼륨 신호를 지울 수도 있습니다. 조사 중에는 빈도, 시점, 지리적 위치, 요청 매개변수 및 리소스 대상이 모두 중요할 수 있습니다.

개념 드리프트는 또 다른 문제를 제기합니다. 팀이 새 서비스를 도입하거나 파이프라인을 수정하거나 아키텍처를 마이그레이션하면 기능적 행동도 바뀝니다. 어제의 작업을 기반으로 학습한 분류기는 정당한 배포 변경을 의심스러운 것으로 처리할 수 있습니다.

공격자도 적응할 수 있습니다. 예상되는 행동 역할을 이해한다면 정상 활동과 유사한 작업을 선택할 수 있습니다. 행동 분류는 위장의 비용을 높이지만, 회피를 제거하지는 못합니다.

이 접근법은 신뢰할 수 있는 텔레메트리에 의존합니다. 누락된 CloudTrail 범위, 비활성화된 로깅, 일관되지 않은 보존 정책 또는 불완전한 교차 계정 수집은 ID 벡터를 왜곡합니다. 깔끔한 모델도 처음부터 기록되지 않은 이벤트를 복구할 수는 없습니다.

ID 경계 역시 모호해질 수 있습니다. Assume된 역할, 연합 세션, 워크로드 자격 증명 및 공유 자동화 경로는 여러 행위자를 하나의 명백한 주체로 합칠 수 있습니다. 역할 추론의 정밀도는 소스 로그의 식별자만큼만 정확합니다.

조직 간 데이터는 또 다른 불확실성을 더합니다. 공유된 행동은 안정적인 산업 패턴을 드러낼 수 있지만, 모든 기업은 계정을 다르게 구성합니다. 한 환경에서 관리자와 강하게 연관된 작업이 다른 환경에서는 자동으로 발생할 수 있습니다.

관리자 클러스터는 이러한 위험을 보여줍니다. ConsoleLogin은 보고된 데이터 세트에서 매우 뚜렷한 특성입니다. 하지만 자동 콘솔 요청, 연합 접근 설계 및 제공업체 인터페이스 변경은 대화형 세션에 수반되는 작업을 바꿀 수 있습니다.

“기능적 역할”이라는 표현조차 증거가 뒷받침하는 것보다 더 큰 확실성을 암시할 수 있습니다. 클러스터는 관찰 기간 동안의 행동 유사성을 설명합니다. 조직 소유권, 권한 또는 비즈니스 목적을 입증하지는 않습니다.

따라서 보안팀은 할당된 역할을 맥락적 메타데이터로 취급해야 합니다. 권한 데이터, 리소스 범위, 네트워크 지표, 인증 신호 및 위협 인텔리전스와 결합해야 합니다. 단일 차원만으로는 악의적 의도를 확정할 수 없습니다.

상업적 맥락도 면밀히 살펴볼 필요가 있습니다. Unit 42는 Palo Alto Networks의 위협 연구 조직이며, 이 보고서는 방법론을 Cortex Cloud 및 관련 제품과 연결합니다. 기술적 발견은 여전히 가치가 있지만, 제품 주장은 고객 측 검증이 필요합니다.

조직은 계정과 시간에 따라 분류가 안정적으로 유지되는지 확인해야 합니다. 역할 불일치가 자동 격리를 촉발하도록 허용하기 전에 경보 품질을 측정해야 합니다. 잘못된 대응은 백업, 배포 또는 보안 모니터링을 중단시킬 수 있습니다.

드라이런 평가는 더 안전한 도입 경로를 제공합니다. 팀은 추론된 역할을 계산하고, 알려진 자산 소유권과 비교하며, 프로덕션 접근을 변경하지 않은 채 이탈을 관찰할 수 있습니다. 이후 분석가는 임계값과 예외를 조정할 수 있습니다.

최선의 시험 기준은 시각화가 설득력 있어 보이는지 여부가 아닙니다. 역할 맥락이 의미 있는 탐지를 유지하면서 조사 시간을 단축하는지 여부입니다. 그러한 결과를 위해서는 연구 보고서 이상의 운영 증거가 필요합니다.

행동 기반 ID 탐지가 효과를 입증할 세 가지 신호

다음 시험은 행동 기반 역할 추론이 연구 환경을 벗어난 뒤에도 정확성, 이식성 및 유용성을 유지하는지 여부입니다.

첫 번째 신호는 측정 가능한 탐지 성능입니다. Unit 42 또는 고객은 여러 역할에 대한 정밀도, 재현율 및 오탐 결과를 공개해야 합니다. 관리자 분류만으로는 백업 에이전트, 배포 시스템 또는 자율 에이전트에 대한 성능을 확립할 수 없습니다.

결과에는 동일한 조직 집단에서 샘플링한 ID가 아니라, 보지 못한 환경이 포함되어야 합니다. 외부 환경에서 강력한 성능을 보인다면 기능적 패턴이 일반화된다는 주장을 뒷받침할 수 있습니다. 성능이 급격히 떨어진다면 환경별 가정이 드러날 것입니다.

두 번째 신호는 크로스 플랫폼 검증입니다. 연구진은 방법론이 Kubernetes, SaaS 애플리케이션 및 다른 클라우드 제공업체로 확장될 수 있다고 말합니다. AWS 밖에서 문서화된 구현은 이 주장을 검증할 수 있습니다.

이식성은 단순히 다른 로그 형식을 처리하는 것 이상을 의미해야 합니다. 이 방법은 식별 가능한 역할을 찾아내고, 안정적인 분류기를 생성하며, 실제 탐지 결정을 개선해야 합니다. 그렇지 않다면 AWS API 관례가 일반 프레임워크보다 더 많은 역할을 하고 있을 수 있습니다.

세 번째 신호는 투명한 탐지 워크플로를 통한 운영 도입입니다. 보안 팀은 경보 안에서 추론된 역할, 기여한 작업, 신뢰도, 상충하는 행동을 보여주는 통합 기능을 주시해야 합니다.

단순한 위험 점수는 이 연구의 핵심 장점을 가리게 됩니다. 그 가치는 알려진 백업 ID가 관리자처럼 행동하기 시작했다는 점을 설명하는 데 있습니다. 분석가는 긴급성을 판단하고 대응 방식을 선택하기 위해 그 관계를 알아야 합니다.

가장 강력한 구현은 시간에 따른 역할 변화도 추적합니다. 배포 계정이 새로운 서비스로 합법적으로 확장될 수 있습니다. 시스템에는 재학습 일정, 드리프트 모니터링, 버전 관리되는 분류기, 변화한 행동을 검토하는 프로세스가 필요합니다.

팀은 모든 불일치를 사고로 취급하지 않아야 합니다. 일부 편차는 유지보수, 마이그레이션 또는 신제품 출시를 반영할 수 있습니다. 역할 신호는 조사의 우선순위를 정해야 하며, 격리가 정당한지는 다른 증거가 판단해야 합니다.

사람과 머신 ID도 별도로 평가해야 합니다. 대화형 관리자, 예약된 서비스, 자율 에이전트는 서로 다른 속도로 활동을 생성합니다. 이들은 서로 다른 관찰 기간과 임계값을 필요로 할 수 있습니다.

자율 에이전트는 이 문제를 특히 시급하게 만듭니다. 에이전트는 승인된 하나의 목표를 추구하면서 여러 서비스 전반에서 가변적인 작업 순서를 수행할 수 있습니다. 정적인 작업 레이블로는 이러한 행동을 제대로 설명하기 어렵습니다.

그러나 가변적인 행동은 클러스터링도 더 어렵게 만듭니다. 에이전트의 합법적인 작업 공간은 정찰, 구성 변경, 데이터 접근과 겹칠 수 있습니다. 방어자는 목표, 승인, 리소스, 실행 이력에 관한 맥락을 필요로 합니다.

Unit 42 cloud identities 제안은 그러한 맥락의 한 부분을 제공합니다. 이는 한 ID가 동료 집단 내에서 어떻게 행동하는지에 대한 실증적 설명을 만듭니다. 하지만 근본적인 목표가 승인되었는지는 판단하지 않습니다.

개발자에게 당면한 질문은 배포 및 서비스 ID에 명확하고 관찰 가능한 패턴이 있는지입니다. 팀은 감사 이벤트가 역할 위임과 자동화 세션 전반에서 일관되게 연결될 수 있는지 검토해야 합니다.

엔터프라이즈 구매자는 공급업체에 기능적 역할을 어떻게 추론하는지 물어야 합니다. 또한 각 분류를 이끄는 이벤트가 무엇인지 설명하는 증거를 요청해야 합니다. “AI 기반 이상 탐지”만으로는 영향이 큰 보안 결정을 내리기에 충분한 정보가 아닙니다.

보안 리더는 행동 분석 결과를 접근 권한 검토와 비교해야 합니다. 운영 범위가 좁아 보이지만 광범위한 권한을 유지하는 ID는 예방 가능한 노출을 의미합니다. 갑자기 역할이 바뀌는 ID는 잠재적인 활성 위협을 의미합니다.

지식 근로자와 AI 제품 사용자도 관련된 이해관계를 가집니다. 비즈니스 애플리케이션은 점점 더 어시스턴트와 에이전트를 회사 데이터에 연결하고 있습니다. 각각의 연결은 단순한 사용자 레이블을 넘어서는 실질적 행동을 보일 수 있는 ID를 만듭니다.

향후 1~3개월은 Palo Alto Networks가 추가 검증 자료를 공개하는지, 역할 범위를 확대하는지, 또는 고객 워크플로에서 로직을 더 직접적으로 드러내는지를 보여줄 것입니다. 독립적인 테스트는 이 사례를 한층 더 강화할 것입니다.

독자는 세 가지 구체적인 질문을 따라가야 합니다. 분류기가 보지 못한 환경에서도 작동하는가, AWS를 넘어 이전 가능한가, 그리고 분석가의 결정을 개선하는가? 이 답이 행동 기반 ID 맵이 일상적인 보안 맥락이 될지를 결정할 것입니다.

이 연구의 핵심 판단은 이미 유효합니다. 권한 문서는 필요하지만, ID 위험을 완전히 설명하지는 못합니다. 방어자에게는 자격 증명, 워크로드, 에이전트가 실제로 무엇을 하는지에 대한 증거도 필요합니다.

그 관점에서 자체 클라우드 인벤토리를 검토해 보십시오. 이름과 권한은 있지만 검증된 행동 역할이 없는 ID는 무엇입니까? 그 답에서 드러나는 공백은 Unit 42 cloud identities 연구가 가장 중요한 영역을 보여줍니다.