많은 보안 사고의 출발점은 평범한 계정입니다. 공격자는 평범한 계정으로 들어온 뒤 내부 시스템으로 옮겨 다니며 권한을 높여 갑니다. 목표로 삼은 시스템이나 데이터에 접근할 수 있는 관리자 권한을 손에 넣기 위해서입니다. 이런 이유로 많은 기업이 온프레미스 환경에서 관리자 계정처럼 높은 권한을 가진 계정을 관리하고 감독하기 위해 특권 접근 관리(PAM, Privileged Access Management) 솔루션을 도입해 운영해 왔습니다. 이것만으로 충분할까요?
조직의 컴퓨팅 환경이 클라우드까지 넓어진 만큼 그에 맞는 관리자 권한 관리 방안이 필요합니다. 특히 클라우드 환경에서는 높은 권한과 관련한 위험이 더 빠르게 커질 수 있습니다. 프로젝트와 리소스가 빠르게 늘고, 권한을 주는 일은 클릭 몇 번이면 끝나지만, 권한을 회수하는 일은 누군가 기억해야만 일어나기 때문입니다. 관련해 이번 포스팅에서는 구글 클라우드 PAM의 핵심 기능을 알아보고, 가상의 기업 사례로 PAM이 보안을 어떻게 강화하는지 살펴보겠습니다.
DX 시대에 맞춰 진화 중인 PAM
클라우드 네이티브 기술을 중심으로 한 DX가 본격화되면서 PAM도 진화의 길을 걷고 있습니다. 주로 온프레미스 환경에서 PAM 기반 통제를 하던 예전에는 특권 계정의 비밀번호를 금고에 넣고 꺼내 쓰는 데 초점을 맞췄습니다. 반면에 클라우드 환경에서는 권한 자체가 IAM 역할로 존재합니다. 그 결과 관심사도 “관리자 비밀번호를 어떻게 보호할까”에서 “상시 특권(Standing Privilege)을 어떻게 없앨까”로 옮겨 갔습니다.
늘 켜져 있는 권한 대신 필요한 순간에만 주고 시간이 지나면 자동으로 회수하는 적시 접근(JIT, Just-in-Time)이 새로운 PAM의 기준이 된 것입니다. 구글 클라우드의 PAM은 이런 흐름을 잘 보여 줍니다. 서버 운영체제 계정의 비밀번호를 관리하던 기존 PAM 솔루션을 대신하기보다, 클라우드 IAM 권한이라는 새로운 영역을 맡아 서로를 보완한다고 보는 편이 정확합니다.
구글 클라우드 PAM은 무엇을 해 줄까?
구글 클라우드의 특권 접근 관리자(Privileged Access Manager, 이하 PAM)는 높은 권한이 필요한 접근을 보호하고 관리하고 감사하는 클라우드 네이티브 관리형 서비스입니다. 구글은 2024년 6월 프리뷰로 공개한 뒤 정식 출시(GA)했습니다. 별도의 인프라나 소프트웨어를 설치할 필요가 없고 IAM과 기본으로 연동하므로 PAM으로 준 권한을 IAM에서도 확인할 수 있습니다. 더불어 구글 클라우드 콘솔, gcloud CLI, API, 테라폼(Terraform) 중 익숙한 방식으로 관리할 수 있어 편의성도 높습니다.
구글 클라우드 PAM의 핵심은 자격(Entitlement)입니다. 자격은 접근을 요청할 수 있는 자격증과 같습니다. 관리자는 자격마다 다음 항목을 정합니다.
- 부여할 역할: 사전 정의 역할이나 커스텀 역할을 지정하고, IAM 조건으로 특정 리소스에만 권한이 닿게 좁힐 수 있습니다.
- 최대 사용 시간: 권한을 쓸 수 있는 최대 시간을 정합니다.
- 요청자: 이 자격으로 접근을 요청할 수 있는 사용자나 그룹을 정합니다.
- 사유 입력: 요청할 때 업무 사유를 반드시 적게 할 수 있습니다.
- 승인자: 승인이 필요한 경우 승인자를 지정합니다. 프리뷰 기능으로 최대 2단계, 단계별 최대 5명까지 다단계·다자 승인도 설정할 수 있습니다.
- 알림 대상: 중요한 이벤트를 알릴 관계자를 추가합니다.
자격은 조직, 폴더, 프로젝트 등 원하는 범위에 만들 수 있습니다. 접근의 민감도와 상황의 긴급도에 따라 사용자가 스스로 권한을 올리게 할 수도 있고, 승인을 거친 뒤에만 주게 할 수도 있습니다.
권한의 생애 주기는 자동으로 돌아갑니다. 사용자가 요청하고 승인자가 승인하면 PAM이 권한을 활성화합니다. 승인자를 지정하지 않은 자격이라면 요청과 동시에 권한이 활성화됩니다. 정한 시간이 끝나면 PAM이 권한을 자동으로 회수하고 정책도 정리합니다. 관리자가 중간에 권한을 회수할 수도 있습니다. 승인자가 24시간 안에 결정하지 않으면 요청은 만료됩니다.
감사 기능도 제공합니다. 누가 요청했는지, 사유가 무엇인지, 누가 승인했는지, 언제 권한을 받았는지가 모두 클라우드 감사 로그(Cloud Audit Logs)에 남습니다. 요청자, 승인자, 관리자에게는 승인 요청, 활성화, 만료 같은 주요 이벤트를 메일로 알립니다. 권한 변경 이벤트를 Pub/Sub으로 받아 다른 보안 워크플로와 연결할 수도 있습니다.
가상의 사례로 본 PAM 기반 보안 강화
구글 클라우드 PAM이 실제로 어떤 변화를 일으키는지 가상의 사례로 살펴보겠습니다. IT 헬프데스크 서비스를 제공하는 A사가 PAM을 도입하게 된 배경과 도입 후 달라진 점을 정리한 시나리오입니다.
A사는 여러 기업 고객의 IT 헬프데스크를 대행하는 회사입니다. 고객 문의 티켓과 첨부 파일, 장애 로그를 구글 클라우드 스토리지(Cloud Storage)에 보관합니다. 첨부 파일에는 고객사 임직원의 개인정보가 섞여 있는 경우가 많습니다. 처리 파이프라인이 분석하지 못한 파일은 별도의 “처리 실패” 버킷으로 옮깁니다. 2선 기술지원 엔지니어는 이 파일을 직접 열어 원인을 확인하고 파이프라인을 고쳐야 합니다.
PAM 도입 전 A사의 절차는 길었습니다. 엔지니어가 팀장에게 접근을 요청합니다. 팀장은 IAM 관리자에게 티켓을 남깁니다. IAM 관리자는 권한을 주고, 나중에 작업이 끝났는지 확인한 뒤 권한을 회수합니다. 이 과정은 오래 걸리고 번거롭습니다. 바쁜 날에는 회수를 잊기 쉽습니다. 결과적으로 처리가 늦어지거나, 반대로 권한이 필요 이상으로 남기도 합니다.
PAM 자격 만들기
A사는 보안 강화를 위해 PAM으로 이 절차를 바꾸기로 합니다. IAM 관리자는 구글 클라우드 콘솔의 PAM 자격 페이지에서 새 자격을 만듭니다. 이름은 용도가 드러나게 “처리 실패 티켓 첨부 파일 읽기”로 정합니다. 부여할 역할은 스토리지 객체 뷰어(Storage Object Viewer)입니다. 프로젝트에는 버킷이 여러 개 있으므로 IAM 조건에 버킷 이름을 넣어 처리 실패 버킷에만 권한이 닿게 합니다.
경험상 엔지니어는 한 번에 한 시간 정도면 원인을 확인합니다. IAM 관리자는 최대 사용 시간을 이에 맞춰 정합니다. 요청자는 2선 기술지원팀 구글 그룹으로 지정합니다. 데이터가 민감하므로 요청 시 업무 사유를 필수로 받고, 팀장을 승인자로 지정합니다. 알림은 기본 설정을 그대로 쓰고 자격을 생성합니다.

달라진 권한 관리 흐름
PAM 적용 후 A사의 권한 관리 흐름은 눈에 띄게 달라집니다. IAM 관리자가 설정을 마치고 며칠 뒤, 엔지니어에게 처리 실패 알림이 옵니다. 스토리지 페이지에 들어가 보니 파일을 볼 권한이 없습니다. 엔지니어는 PAM 페이지로 가서 자신이 요청할 수 있는 자격을 확인합니다. 권한 요청 버튼을 누르고, 사용 시간은 1시간으로, 사유에는 처리 실패 티켓 번호와 확인할 내용을 적어 요청합니다. 요청은 승인 대기 상태로 바뀝니다.
팀장은 PAM에서 보낸 승인 요청 메일을 받습니다. 메일의 링크로 들어가 요청한 역할, 사유, 사용 시간을 확인하고, 승인 사유를 적어 승인합니다. PAM이 권한을 활성화하고 엔지니어에게 알림을 보냅니다. 엔지니어가 보는 화면에는 남은 시간이 나타납니다. 엔지니어는 이제 처리 실패 파일을 열어 원인을 찾고 파이프라인을 고칠 수 있습니다. 한 시간이 지나면 PAM이 권한을 자동으로 회수합니다. IAM 관리자가 따로 챙길 필요가 없습니다.
IAM 관리자는 민감 버킷에 대한 접근을 정기적으로 점검합니다. PAM 감사 로그에는 자격 생성부터 엔지니어의 요청, 팀장의 승인, 권한 활성화와 종료까지 모든 이벤트가 시간 순서대로 남아 있습니다. 자격 생성 로그에는 설정 값이, 요청 로그에는 엔지니어가 적은 사유와 사용 시간이 담겨 있습니다. 이 로그는 해당 리소스의 감사 로그에서 조회할 수 있으므로 다른 감사 담당자나 후속 분석 워크플로에서도 활용할 수 있습니다.

무엇이 달라졌을까?
PAM 적용 후 A사의 권한 관리 흐름은 눈에 띄게 달라집니다. IAM 관리자가 설정을 마치고 며칠 뒤, 엔지니어에게 처리 실패 알림이 옵니다. 스토리지 페이지에 들어가 보니 파일을 볼 권한이 없습니다. 엔지니어는 PAM 페이지로 가서 자신이 요청할 수 있는 자격을 확인합니다. 권한 요청 버튼을 누르고, 사용 시간은 1시간으로, 사유에는 처리 실패 티켓 번호와 확인할 내용을 적어 요청합니다. 요청은 승인 대기 상태로 바뀝니다.
팀장은 PAM에서 보낸 승인 요청 메일을 받습니다. 메일의 링크로 들어가 요청한 역할, 사유, 사용 시간을 확인하고, 승인 사유를 적어 승인합니다. PAM이 권한을 활성화하고 엔지니어에게 알림을 보냅니다. 엔지니어가 보는 화면에는 남은 시간이 나타납니다. 엔지니어는 이제 처리 실패 파일을 열어 원인을 찾고 파이프라인을 고칠 수 있습니다. 한 시간이 지나면 PAM이 권한을 자동으로 회수합니다. IAM 관리자가 따로 챙길 필요가 없습니다.
IAM 관리자는 민감 버킷에 대한 접근을 정기적으로 점검합니다. PAM 감사 로그에는 자격 생성부터 엔지니어의 요청, 팀장의 승인, 권한 활성화와 종료까지 모든 이벤트가 시간 순서대로 남아 있습니다. 자격 생성 로그에는 설정 값이, 요청 로그에는 엔지니어가 적은 사유와 사용 시간이 담겨 있습니다. 이 로그는 해당 리소스의 감사 로그에서 조회할 수 있으므로 다른 감사 담당자나 후속 분석 워크플로에서도 활용할 수 있습니다.
PAM 적용의 좋은 출발점
높은 권한 자체는 없앨 수 없습니다. 클라우드 환경을 운영하려면 누군가는 높은 권한을 써야 합니다. 핵심은 그 권한이 늘 켜져 있지 않게 하는 것입니다. PAM 적용의 시작은 지금 상시로 주고 있는 높은 권한을 찾아보는 것입니다. 운영 환경 관리자 역할, 민감 데이터가 담긴 버킷의 접근 권한, 외주 인력에게 열어 둔 권한이 좋은 출발점입니다.
그중 사용 빈도가 낮은 권한부터 PAM 자격으로 옮기고, 승인 흐름과 감사 로그 점검 주기를 정해 보시기 바랍니다. 구글 클라우드 환경에서 최소 권한 원칙에 맞춘 관리자 권한 접근 관리 체계를 구축하고 싶다면 메가존소프트 문의 포털을 통해 상담을 남겨 주세요.


