[기고] 제로 스탠딩 권한, 벤더 허구와 현실

특권 액세스 관리(PAM) 시장에 진출한 일부 신규 공급업체들은 자신들이 제로 스탠딩 권한(ZSP)으로 액세스를 제공할 수 있다거나 곧 제공할 수 있을 것이라고 자신하게 주장하고 있다.

그런데 이같은 공급업체의 주장은 자체 기술의 제한된 사용 사례를 무시할 가능성이 높다. 이는 사이버 보안에서 가장 어려운 문제인 PAM에 대한 근본적인 오해를 드러낸다.

ZSP는 진화하는 IT 환경 내 아이덴티티 보안의 미래에 있어 절대적으로 중요한 구성 요소다. 그럼에도 불구하고 조직은 하이브리드 및 멀티 클라우드 환경의 복잡성을 보호하기 위해 항상 포괄적인 범위의 제어가 필요하다.

혼잡한 시장에서 현대 PAM 프로그램을 구축할 때 고려해야 할 제로 스탠딩 권한에 대한 몇 가지 신화 같은 허구가 있다. 이 같은 신화와 실제 현실을 이해하는 것은 정보에 입각한 결정을 내리고 효과적인 보안 조치를 구현하는 데 매우 중요하다. 가장 일반적인 오해와 그 이면에 숨겨진 진실을 살펴보자.

"ZSP의 자격 증명 보관 로테이션 대체"는 허구'...특권계정·자격증명은 '필수'

지난 7월 크라우드스트라이크 사태 당시 포천 500대 기업은 '팰컨 센서 에이전트'에 대한 잘못된 소프트웨어 업데이트로 인해 전 세계 수 백만 대의 윈도 기기가 작동을 멈추면서 50억 달러 이상의 직접적 손실을 입은 것으로 알려졌다. 많은 조직이 시스템을 재부팅하고, IT 운영을 복구할 수 있는 특권 액세스가 있는 '브레이크 글래스(Break-glass) 계정으로 전환했다.

대부분 PAM 솔루션으로 안전하게 관리되는 이러한 특권 계정과 자격 증명은 조직이 내부 및 고객 대면 서비스를 복원하는 데 필수적이었다. 이러한 비상 계정이 없었다면 크라우드스트라이크로 인한 서비스 중단과 관련 비용은 더욱 악화됐을 수 있다. 이는 안전한 자격 증명 관리가 항상 필요하다는 점을 방증한다.

클라우드 환경에서 일부 특권 계정과 자격 증명은 결코 대체될 수 없다. 모든 조직이 아마존 웹 서비스(AWS)에서 작업할 때 필요로 하는 슈퍼 사용자 계정인 AWS 루트 계정을 예로 들 수 있다. AWS 루트 계정은 삭제할 수 없으며 보안 지침은 매우 명확하다. 조직은 강력한 비밀번호 정책, 다중 요소 인증(MFA), 이중 제어 프로세스 및 기타 신원 보안 모범 사례를 통해 루트 사용자 자격 증명을 보호해야 한다. 유사한 루트 및 등록 계정과 비슷한 모범 사례는 다른 선도적인 클라우드 제공업체들도 보유하고 있다.

또 다른 과제는 서비스 계정, 로봇 프로세스 자동화(RPA) 봇 및 애플리케이션 계정 같은 머신 아이덴티티에서 사용하는 자격 증명 및 비밀과 관련이 있다. 사이버아크를 포함한 일부 혁신적인 공급업체는 최적(Just-In-Time, JIT) 및 동적 애플리케이션 비밀 프로비저닝을 제공하지만 오늘날 대부분의 머신 간 통신은 여전히 인증을 위해 비밀번호 및 보안 셸(SSH) 키 같은 자격 증명에 의존하고 있다.

조직은 이러한 비밀을 안전하게 보관하고 순환시키지 못하면 코드코브(CodeCov), 솔라윈즈(SolarWinds) 및 우버(Uber)에서 발생한 것과 같은 주요 침해로 이어진 자격 증명 도용 공격에 노출된다.

모든 조직은 권한 있는 액세스를 보유한 공유 계정 및 자격 증명의 사용을 줄이기 위해 아이덴티티 보안 모범 사례를 따라야 한다. ZSP 접근 방식을 추구하는 것은 위험을 줄이기 위한 효과적인 단계다. 그럼에도 클라우드 및 소프트웨어 개발 환경의 적절한 구성과 크라우드스트라이크 중단 복구 같은 비상 시나리오를 위해 이러한 아이덴티티를 일부 사용하는 것은 항상 필요하다.

동적 권한 생성 사용·제거 가능한 공급업체 사실상 '부재'

ZSP로 액세스하기 위한 벤더 대부분의 마케팅 기능은 사용자를 특권 액세스가 있는 기존 계정이나 역할로만 승격시킨다. 이는 사용자가 특권 자격 증명으로 로그인하지 않고 대신 계정이나 역할을 사용할 수 있는 임시 액세스 권한을 받는 JIT 특권 액세스 접근 방식이다.

이 JIT 접근 방식으로 위험을 줄이는 것은 중요하지만 역할과 계정에 부여된 권한도 함께 제공된다. 이러한 역할과 계정은 여전히 조직의 디렉토리 또는 클라우드 아이덴티티 및 액세스 관리(IAM) 저장소에 존재하기 때문에 공격자는 여전히 무단 액세스할 수 있고 JIT 승격 워크플로를 우회할 수 있다.

일례로 공격자가 클라우드에서 아이덴티티 및 접근관리(IAM) 권한을 수정할 수 있는 아이덴티티 제공업체, 도메인 컨트롤러 또는 역할에 액세스하기 위해 측면으로 이동한다고 가정해 보자. 이 경우 공격자는 이러한 기존 계정과 역할을 자유롭게 사용할 수 있다.

진정한 ZSP 접근 방식은 정확히 다음과 같은 요구사항을 충족해야 한다. 제로 스탠딩 권한, 즉 공격자가 손상시킬 수 있는 특권 역할이나 계정이 존재하지 않아야 한다. 또 이러한 계정이나 역할은 시스템에 남아 있지 않아야 한다. 대신 조직은 최종 사용자가 액세스해야 할 때 완전히 새로운 권한과 역할을 생성하며 시간 제한 세션이 끝난 후 해당 권한을 삭제한다.

오늘날 이 같은 진정한 ZSP 접근 방식을 제공할 수 있는 공급업체는 극히 일부만 존재한다. 제공할 수 있는 공급업체를 평가하려면 조직의 특권 액세스를 제어하는 시간, 자격 및 승인(TEA) 설정을 고려해야 한다.

세 가지 모두에 대한 세부적인 제어가 필요하다. 최종 사용자가 필요 이상으로 특권 액세스 권한을 갖지 않도록 시간 제한 액세스를 부여할 때는 유연성을 갖는 것이 무엇보다 중요하다. 마찬가지로 권한은 최소 권한 규칙에 따라 부여해야 하므로 최종 사용자는 필요한 작업을 수행할 수 있는 권한만 갖는다.

승인은 중요한 마지막 단계다. 특히 개발자 팀의 경우 개발자가 이미 사용 중인 채팅 기반 운영(ChatOps) 및 IT 서비스 관리(ITSM) 도구에 액세스 요청과 자동화된 승인을 통합해 혁신에 대한 마찰과 방해를 최소화하는 것이 중요하다.