[50편] 해킹 이후, 공격자는 어디까지 갈 수 있을까 — ACP 첫 연재를 마치며

첫 글을 쓸 때 가장 마음에 걸렸던 것은 계정 하나가 노출된 다음의 일이었다. 그 계정으로 다른 서버에 들어갈 수 있다면, 필요한 것보다 많은 데이터를 읽을 수 있다면, 한 번의 사고가 어디까지 커질까.

그래서 QueryPie ACP 커뮤니티 버전을 직접 설치했다. Mac에서 테스트 DB를 연결하는 것부터 시작해 서버와 쿠버네티스까지 써봤다. 권한을 요청하고 승인받는 사람도 돼보고, 작업을 허용하거나 회수하는 관리자도 돼봤다.

50편에 와서 기억에 남는 장면들을 돌아보니 공통점이 있었다. 주문 상태는 확인할 수 있었지만 허용하지 않은 변경은 막혔다. 서버에서 파일을 읽는 일은 가능했고, 제한해둔 삭제 명령은 실행되지 않았다. 쿠버네티스에서도 설정 조회는 되면서 변경 요청은 거부됐다.

맡긴 일은 할 수 있게 두고, 그 일을 넘어서는 권한은 주지 않는 것. 처음 글에서 필요하다고 생각했던 통제를 직접 설정하고 결과까지 확인해본 셈이다.

조회는 맡기고, 변경은 승인받게 할 수 있었다

데이터베이스 접근 제어인 DAC에서 특히 좋았던 점은 업무를 꽤 구체적으로 나눌 수 있다는 것이었다.

예를 들어 주문이 제대로 처리됐는지 확인하는 담당자에게는 주문번호와 배송 상태가 필요하다. 고객의 전화번호와 이메일 전체까지 항상 필요한 것은 아니다. 실습에서는 DBeaver로 평소처럼 조회하면서도 연락처에 마스킹을 적용할 수 있었다. 주문 확인은 계속하고, 원문이 필요한 담당자에게만 예외를 주는 식이었다.

“조회만 해주세요”라는 말도 실제 실행 권한으로 옮겨볼 수 있었다. 읽기 전용 사용자가 UPDATE를 실행하자 차단됐고, 같은 연결에서 SELECT는 정상적으로 실행됐다.

필요한 변경은 승인 절차로 처리했다. 49편에서는 평소 접속 권한을 Read-Only로 유지한 채, 주문 한 건을 바꾸는 SQL을 별도로 승인받아 실행했다. 변경 사유와 승인자가 남았고, DML Snapshot에서 상태가 PENDING에서 DELIVERED로 바뀐 것도 확인했다.

도입을 맡았다면 이 장면부터 동료들에게 보여주고 싶다. 조회 업무와 변경 업무를 나누면서도 필요한 정정 작업은 진행할 수 있고, 나중에 왜 바꿨는지와 어떤 값이 달라졌는지까지 설명할 수 있기 때문이다.

서버 비밀번호를 건네주지 않아도 작업을 맡길 수 있었다

서버 접근 제어인 SAC를 쓰면서는 사용자에게 접속 정보를 전달하는 방식부터 다시 생각하게 됐다.

관리자가 서버 계정을 등록하고 역할을 부여하자, 사용자는 자신의 QueryPie 계정으로 로그인해 허용된 서버에 접속했다. 서버 비밀번호를 따로 받아 입력하는 단계는 없었다. 감사 기록에서는 실제 작업한 QueryPie 사용자와 서버에서 사용한 계정을 함께 확인할 수 있었다.

서버 비밀번호를 바꾸는 실습도 인상적이었다. QueryPie에서 테스트 계정의 비밀번호를 변경한 뒤 다시 접속했는데, 사용자가 새 비밀번호를 찾아 입력할 필요가 없었다. 담당자마다 새 비밀번호를 전달하고 보관하게 하는 수고를 줄일 수 있겠다는 생각이 들었다.

작업할 때는 익숙한 Mac 터미널도 계속 쓸 수 있었다. Multi Agent를 거쳐 SSH로 접속해 파일을 확인했고, 정책에 넣어둔 rm 명령을 실행하자 터미널에서 바로 제한됐다. 다시 파일을 읽어보니 내용은 그대로였다. 명령 감사에는 그 삭제 시도가 Restricted로 남았다.

SAC의 매력은 서버에 들어가는 사람과 그 안에서 하는 일을 함께 살펴볼 수 있다는 데 있었다. 점검에 필요한 접속을 제공하면서 제한할 명령을 정하고, 작업 후에는 기록과 세션 재생으로 당시 상황을 확인할 수 있었다. 외부 유지보수나 운영 점검을 맡기는 상황이 자연스럽게 떠올랐다.

kubectl을 그대로 쓸 수 있어서 KAC가 더 와닿았다

쿠버네티스 접근 제어인 KAC에서는 설정을 확인하는 일과 설정을 바꾸는 일을 구분해봤다. 테스트 네임스페이스의 ConfigMap은 조회할 수 있게 두고, 같은 설정의 변경은 제한했다.

Multi Agent 인증을 사용하는 접속 설정을 준비한 뒤에는 익숙한 kubectl 명령으로 작업했다. get으로 현재 값을 읽는 것은 됐지만, patch로 값을 바꾸려 하자 QueryPie 정책에 따라 거부됐다. 다시 조회한 설정값과 리소스 버전도 그대로였다.

관리자 화면에서는 누가 어느 클러스터의 어떤 리소스에 변경을 요청했는지, 요청에 어떤 값을 넣었는지까지 볼 수 있었다. 쿠버네티스의 네임스페이스와 리소스, 작업 종류에 맞춰 권한을 나누고 그 결과를 사용자 기준으로 찾아볼 수 있다는 점이 좋았다.

컨테이너 안에서 한 작업을 재생해본 경험도 기억에 남는다. 테스트 Pod에 들어가 상태 파일을 읽고 나온 뒤 녹화를 열었더니, 입력한 명령과 그때 화면에 나온 값이 다시 보였다. 접속 요청을 찾은 다음 같은 작업의 녹화까지 이어서 확인할 수 있었다.

쿠버네티스를 도입하면 운영 대상과 작업 방식이 달라진다. 이번에는 DB와 서버에서 중요하게 봤던 “누가 어떤 권한으로 작업했고, 무엇을 했는가”를 쿠버네티스에서도 같은 제품 안에서 확인할 수 있었다. 운영자가 kubectl을 계속 쓸 수 있다는 점까지 더해지니, 실제 업무에 적용하는 모습이 한결 쉽게 그려졌다.

DB와 서버, 쿠버네티스를 한곳에서 관리해보니

DB부터 서버, 쿠버네티스까지 써보고 나니 한 제품에서 함께 관리한다는 점이 생각보다 크게 다가왔다. 회사의 중요한 데이터는 DB에 있고, 서비스를 돌리는 서버와 쿠버네티스에도 접근 권한이 필요하다. QueryPie에서는 이 자산들을 한곳에 등록하고, 업무에 맞게 접근 범위를 정한 뒤 실제 작업 기록까지 확인할 수 있었다.

DB에서는 어떤 SQL을 실행했는지, 서버에서는 어떤 명령을 입력했는지, 쿠버네티스에서는 어떤 리소스에 작업을 요청했는지 살펴봤다. 실습을 이어갈수록 “누가 어떤 권한으로 들어와 무엇을 했는가”라는 질문에 같은 제품 안에서 답을 찾을 수 있다는 점이 마음에 들었다.

도입 담당자라면 이 부분도 눈여겨볼 만하다. DB 접근 제어부터 시작해 서버와 쿠버네티스로 관리 범위를 넓혀가는 모습을 그려볼 수 있기 때문이다. 작업자는 DBeaver와 터미널, kubectl을 계속 사용하고, 관리자는 주요 자산의 접근 권한과 작업 이력을 한곳에서 살펴본다. 직접 써보고 나서 느낀 QueryPie ACP의 큰 매력 중 하나다.

첫 글의 질문에 이제는 구체적인 장면으로 답할 수 있다

주요 자산을 함께 관리해보면서 첫 글에서 던졌던 질문도 다시 떠올랐다. “공격자가 이미 내부에 들어왔다면, 우리는 무엇을 막을 수 있을까?”

이번 연재의 마지막 실습에서는 로그인된 테스트 계정으로 주문 조회, 정산 조회, 주문 변경을 차례로 시도했다. 주문 조회는 가능했고, 허용 범위 밖의 정산 조회와 변경은 차단됐다. 그 시도는 감사 기록에 남았으며, 관리자가 해당 DB 권한을 회수하자 열어둔 연결에서도 더 이상 조회할 수 없었다.

이 결과를 보며 계정에 부여해둔 권한의 크기가 얼마나 중요한지 다시 느꼈다. 로그인한 계정이 사용할 수 있는 범위를 평소에 좁혀두고, 필요할 때 접근을 중단하며, 그동안의 작업을 확인할 수 있었다. 1편에서 말한 ‘침투 이후 통제’가 어떤 설정과 운영으로 이어져야 하는지 훨씬 분명해졌다.

도입 담당자에게는 필요한 업무를 이어가면서 통제 결과까지 보여줄 수 있다는 점이 큰 설득력이 있다고 생각한다. 개발·운영팀에는 익숙한 도구로 작업하는 모습을, 보안 담당자에게는 어떤 작업을 허용하고 제한했는지 남은 기록을 보여줄 수 있다. 회사의 주요 자산에 이런 기준을 함께 적용할 수 있다는 점까지 확인하니, QueryPie ACP를 검토할 이유가 내게는 훨씬 구체적이 됐다.

첫 실습은 테스트 DB 하나부터

이 글을 읽고 직접 써볼까 싶어졌다면, 처음부터 DB와 서버, 쿠버네티스를 모두 준비할 필요는 없다. 나도 테스트 DB 하나와 관리자·작업자 계정을 나누는 것부터 시작했다.

작업자에게 조회 권한을 주고 데이터를 읽어본 뒤, 같은 계정으로 변경을 시도해보면 된다. 이어서 관리자 화면에서 두 작업의 기록을 찾아보자. 허용한 일은 되고, 제한한 일은 막히며, 그 결과가 남는 모습을 보면 접근 제어가 자신의 업무에서 어떤 역할을 할지 감이 온다.

그다음에는 회사에서 자주 고민하는 상황 하나를 가져오면 좋겠다. 외부 담당자에게 점검을 맡기는 일일 수도 있고, 서버 비밀번호를 전달하지 않고 접속을 제공하는 일일 수도 있다. 쿠버네티스 설정은 읽되 바꾸지는 못하게 하고 싶은 팀이라면 KAC부터 살펴봐도 되겠다.

커뮤니티 버전으로 직접 해볼 수 있었던 덕분에, 나는 제품 설명을 읽으면서 생긴 질문을 테스트 환경에서 하나씩 확인할 수 있었다. 그렇게 DB 접속부터 시작한 실습이 서버와 쿠버네티스까지 이어졌다.

여기서 첫 연재를 마친다. 1편에서는 계정 하나가 노출됐을 때 그다음에 벌어질 일이 걱정됐다. 지금은 우리 팀에 필요한 권한을 어디까지 줄지, 그 기준을 DB와 서버, 쿠버네티스에 어떻게 일관되게 적용할지 생각하게 된다. 주요 자산의 접근 권한과 작업 이력을 한곳에서 관리해보니, 우리 회사에도 적용해보고 싶은 모습이 훨씬 구체적으로 그려졌다. QueryPie ACP를 직접 써보며 얻은 가장 큰 변화다.

설치부터 따라가려면 이 블로그의 2편과 QueryPie ACP 커뮤니티 버전 공식 설치 안내를 참고하면 된다.

이 글은 QueryPie ACP Community 11.6.7과 별도의 테스트 DB·서버·쿠버네티스 환경에서 진행한 실습을 돌아본 후기다.