"김 대리, 그 파일 권한 좀 열어줘"의 위험성

실무에서 마주하는 권한 부여의 딜레마

현업에서 가장 빈번하게 발생하는 보안 사고는 외부 해킹이 아닙니다. 오히려 "업무가 급하다"는 이유로 알음알음 열어준 파일 권한에서 시작되는 경우가 많습니다.

• 상황 1: 부서 간 협업을 위해 문서를 공유해야 하는데, 특정 팀원에게만 권한을 주는 것이 번거로워 '링크가 있는 모든 사용자'로 설정을 풉니다.

• 상황 2: 마케팅팀 인턴이 신규 프로젝트 TF팀에 합류했습니다. 업무를 위해 '보안 2등급' 문서를 봐야 하지만, 인턴에게 보안 문서를 취급할 권한을 줄 수 없어 규정 위반을 고민합니다.

• 상황 3: '팀장 이상 열람 가능' 문서이지만, 팀장이 긴 휴가를 떠났습니다. 급한 결재를 위해 대리에게 자신의 ID와 비밀번호를 알려줍니다.

왜 기존 그룹웨어/ERP 설정만으로는 부족한가?

대부분의 회사 그룹웨어나 ERP는 "인사팀은 인사 문서만", "재무팀은 재무 문서만" 보는 식으로 단순하게 설계되어 있습니다. ‘부서’와 ‘직급’이라는 딱딱한 틀에 맞춰져 있기 때문입니다. 하지만 실제 업무는 부서의 경계를 넘나들며 수시로 변합니다. 기존 시스템은 이런 예외 상황을 유연하게 처리하지 못해 보안 공백을 만듭니다.

1. RBAC (역할 기반): 가장 기초적인 조직도 관리

왜 등장했나? : "김철수에게 권한 주기"의 한계

초기에는 시스템 관리자가 직원 한 명 한 명에게 권한을 줬습니다. 하지만 직원이 100명, 1,000명이 되자 관리가 불가능해졌습니다. 그래서 나온 아이디어가 "사람이 아니라 '직책'에 권한을 주자"는 것입니다. 이것이 우리가 흔히 쓰는 그룹웨어의 시초인 RBAC(Role-Based Access Control)입니다.

법무·컴플라이언스 팀의 활용법

RBAC는 입·퇴사자 관리(Onboarding/Offboarding)의 핵심입니다.

• 활용 예시: 신규 입사자가 오면 '영업 1팀'이라는 역할만 부여합니다. 그러면 영업 1팀이 봐야 할 모든 계약서 권한이 자동으로 생깁니다. 반대로 퇴사 시에는 역할만 회수하면 모든 접근권이 사라집니다.

• 컴플라이언스 관점: "권한 부여의 근거가 무엇인가?"라는 감사의 질문에 "인사 발령(조직도)에 따랐다"고 명확히 답할 수 있는 가장 안전한 방법입니다.

한계점: "TF팀은 어떻게 하죠?"

하지만 현대 조직은 부서 단위로만 움직이지 않습니다. 여러 팀이 협업하는 TF가 생길 때마다 RBAC는 제대로 동작하지 않습니다. 'TF팀용 역할'을 따로 만들다 보면, 나중에는 직원 수보다 역할의 종류가 더 많아지는 역할 폭발(Role Explosion)이 일어나 사실상 관리가 무너집니다.

2. ABAC (속성 기반): 보안 규정을 시스템에 이식하다

왜 등장했나? : ID만으로는 부족한 시대

클라우드와 재택근무가 확산되면서, 단순히 "영업팀 김 과장"이라는 ID만으로는 보안을 장담할 수 없게 되었습니다. 만약 김 과장이 해외 여행 중인 카페 와이파이로 접속한다면? ID는 맞지만 상황이 위험합니다. 그래서 누가(Who)뿐만 아니라 언제(When), 어디서(Where) 등의 속성으로 역할을 제어하는 ABAC(Attribute-Based Access Control)가 등장했습니다.

법무·컴플라이언스 팀의 활용법

ABAC는 보안 서약서나 내부 규정을 시스템적으로 여러 속성을 활용해 강제할 때 쓰입니다.

• 활용 예시: "개인정보가 포함된 계약서는(속성:민감정보), 반드시 사내망 IP에서만(속성:위치), 업무 시간 내에(속성:시간) 열람 가능하다."

• 컴플라이언스 관점: ISMS-P 등 정보보호 인증 심사에서 요구하는 '접근 통제' 항목을 기술적으로 완벽하게 구현할 수 있습니다. 사람의 실수가 개입할 여지를 차단합니다.

  

한계점: "너무 복잡해서 못 쓰겠다"

규칙이 정교한 만큼 설정이 어렵습니다. 법무팀이 "재택근무 규정이 바뀌었으니 권한 설정 바꿔주세요"라고 할 때마다 관리자가 정책을 매번 수정해야 하는 비효율이 발생합니다.

3. ReBAC (관계 기반): 현대적인 협업의 방식

왜 등장했나? : "이거 김 변호사님도 참조해주세요"

과거에는 내부 결재 시스템을 통해 결재 라인을 거쳐야만 문서가 공유되었습니다. 하지만 지금은 슬랙, 노션, 구글 드라이브처럼 작성자가 직접 공유하는 시대입니다. "내가 이 문서의 주인이니까, 내가 초대한 사람도 볼 수 있다"는 관계 중심의 사고가 ReBAC(Relationship-Based Access Control)입니다.

법무·컴플라이언스 팀의 활용법

ReBAC은 외부 파트너 및 로펌과의 협업에 유용합니다.

• 활용 예시: 'M&A 프로젝트' 폴더에 외부 자문 변호사를 초대합니다. 그러면 그 폴더 안에 있는 모든 하위 문서에 대해 변호사도 자동으로 접근 권한(관계)을 갖게 됩니다. 일일이 파일마다 권한을 줄 필요가 없습니다.

한계점: “도대체 누가 누구한테 권한을 준거야?”

• 컴플라이언스 관점: 업무 속도는 빨라지지만, 너무 자유롭습니다. 시간이 지나면 거미줄처럼 얽힌 공유 관계 때문에 "도대체 이 대외비 문서를 누가 보고 있는 거야?"라며 통제 불능 상태에 빠질 수 있습니다. "도대체 이 파일은 누가 누구한테 공유한 거야?"를 추적하기 어려워지기에 보안 감사가 어려워집니다.

4. PBAC (정책 기반): 법무팀이 꿈꾸는 자동화된 통제

왜 등장했나? : "회사의 규칙은 절대적이다"

개별 담당자의 재량에 따라 판단될 경우 휴먼에러가 일어나고, 통합적인 관리가 불가능하게 됩니다. 그래서 개개인의 판단보다 상위에 있는 "전사적 정책(Policy)"이 필요해졌습니다. 이것이 PBAC(Policy-Based Access Control)입니다.

법무·컴플라이언스 팀의 활용법

PBAC는 법무팀이 원하는 거버넌스의 완성형입니다.

• 활용 예시: "D-1등급 기밀 문서는 대표이사 승인 없이는 절대 외부 메일로 발송할 수 없다." 라는 정책을 걸어두면, 그 어떤 직원이 실수로 공유 버튼을 눌러도 시스템이 막습니다.

• 컴플라이언스 관점: 사람의 실수(Human Error)로 인한 보안 사고를 원천 봉쇄할 수 있습니다. 감사 시 "우리는 시스템적으로 정책이 강제되고 있다"고 증명하기 가장 좋습니다.

한계점: "정책은 좋은데, 적용이 너무 오래 걸려요"

문제는 법무팀의 정책을 시스템 언어(코드)로 변환하는 실행의 병목입니다. 우선 법무팀이 시스템에 대한 이해도가 있어야 새로운 정책을 세울 수 있어 정책을 세울 때 까지의 시간이 오래 걸릴 수 있고, 법무팀이 새로운 보안 가이드라인을 만들더라도, 이를 IT팀이 코드로 구현해서 시스템에 반영하기까지는 2주, 길게는 한 달이 넘게 걸릴 수 있습니다. 급변하는 비즈니스 환경에서 정책 반영이 늦어지면 그 기간 동안 리스크에 노출될 수밖에 없습니다. 그렇기에 개발 지식 없이도 정책을 즉시 반영할 수 있는 환경이 중요합니다.

프릭스의 해법: "팀 기반의 정밀한 기능 통제"

이론보다 강력한 실무 중심의 기능

이론은 쉽지만 현실은 늘 복잡합니다. RBAC(부서별 권한)만 고집하자니 유연한 협업이 막히고, ReBAC(자유로운 공유)을 도입하자니 보안 사고가 두렵습니다. 그렇다고 ABAC(정밀 통제)을 구축하기엔 비용과 인력이 부족합니다.

해답은 하이브리드에 있습니다. 대부분의 조직에는 강력한 기본 규칙(RBAC, PBAC) 위에 유연한 예외 처리(ReBAC)를 덧붙이는 현실적인 대안이 필요합니다.

1. 팀 기반의 기본 설정 (RBAC의 장점)과 PBAC 요소의 보완

프릭스는 많은 회사에서 조직 단위로 권한 부여가 되어 있기에 팀을 설정해 두고 시작합니다.(RBAC) 그 이후 우리 팀의 기본적인 룰을 정합니다. 예를 들어 영업팀의 설정에서 '법무검토 없이 전자서명 요청' 권한을 끄면, 영업팀원 누구나 계약서를 보낼 때 자동으로 법무팀 검토 절차를 거치게 됩니다(PBAC적 통제). 신규 입사자가 와도 팀에 초대만 하면 이 강력한 규칙이 자동 적용되므로 관리가 편합니다.

2. 프로젝트/계약 단위의 유연한 제어 (RBAC의 한계 극복)

하지만 RBAC는 "영업팀은 이 유형의 계약서는 다 볼 수 있다"처럼 너무 포괄적인 것이 단점이었죠. 프릭스에서는 팀 권한과 별개로, 개별 프로젝트나 계약서 단위로 정밀한 권한 조정이 가능합니다. 프릭스에서는 개별 프로젝트, 계약서별로 권한을 제공하여 계약서의 유형 등으로 엄격한 관리가 아닌 유연한 관리가 가능합니다.

추가 팁: 외부 협업을 위한 "외부 공유 링크"

권한 체계에 없는 외부 자문 변호사나 잠깐 협업하는 파트너에게 계약서를 보여줘야 할 때, 계정을 만들고 초대하는 과정이 번거로울 수 있습니다.

이럴 땐 '외부 공유 링크'를 활용해보세요. 로그인 없이도 링크만으로 계약 내용을 안전하게 공유할 수 있습니다. 물론, 보안이 걱정된다면 관리자 설정에서 이 기능을 비활성화하여 원천 차단할 수도 있습니다. 유연함이 필요할 땐 켜고, 통제가 필요할 땐 끄면 됩니다.

이처럼 큰 틀은 팀으로 잡아주되, 디테일한 상황은 파일 단위로 유연하게 풀어주어 보안과 협업 효율을 동시에 잡을 수 있습니다.

결론: 보안과 업무 효율, 두 마리 토끼를 잡으려면

핵심 요약

• RBAC (조직 관리): 인사 발령에 따른 입·퇴사자 권한 자동화에 필수적입니다.

• ABAC (보안 규정): "사내망 접속" 같은 구체적인 컴플라이언스 요건을 준수하는 데 쓰입니다.

• ReBAC (협업): 파일을 직접 공유해 외부 로펌이나 TF팀과의 유연한 자료 공유를 지원합니다.

• PBAC (거버넌스): 회사의 핵심 정책을 시스템으로 강제하여 사고를 예방합니다.

프릭스로 스마트한 권한 관리 시작하기

완벽한 하나의 정답은 없습니다. 조직의 규모와 업무 성격에 맞춰 여러 방식을 적절히 섞어 써야 합니다. 프릭스는 팀 기반의 권한 관리와 정밀한 행동 제어 기능으로, 복잡한 설정 없이도 안전하고 유연한 계약 관리 환경을 제공합니다. 통제는 시스템에 맡기고, 더 중요한 컴플라이언스 준수에 집중하세요.