보안 기준: 권한 설계와 데이터 격리

보안·개인정보·권리2026년 9월 18일 4분 읽기보안구축기준docspublic-doc

누가 무엇을 볼 수 있고 무엇을 바꿀 수 있는지 정하는 방식과, 실수로 다른 데이터가 보이지 않게 막는 장치를 정리한 문서입니다. 전체 구성은 업무 시스템 보안 기준에 있습니다.

권한은 화면을 숨기는 것이 아닙니다

관리자에게만 「삭제」 버튼을 보여 주는 것은 화면 구성이지 권한이 아닙니다. 버튼이 보이지 않아도 요청은 다른 방법으로 보낼 수 있기 때문입니다.

듀오랩스는 권한을 서버에서 확인합니다. 화면에서 감추는 것은 사용자 편의를 위한 것이고, 실제로 막는 일은 서버가 합니다. 확인하는 것은 세 가지입니다.

세 번째가 자주 빠지는 확인입니다. 로그인한 직원이 다른 부서나 다른 거래처의 자료를 요청했을 때 막는 것이 이 확인입니다.

역할은 회사의 업무 규칙이라 듀오랩스가 대신 정할 수 없습니다. 구축 초기에 함께 정합니다.

정하는 방식은 「직급」이 아니라 **「무엇을 할 수 있는가」**입니다. 과장과 대리가 같은 일을 한다면 역할은 하나입니다.

시작은 단순하게 하는 편이 좋습니다. 역할을 처음부터 열 개로 나누면 운영에서 누가 어느 역할인지 관리하기 어려워집니다. 서너 개로 시작하고 필요할 때 늘립니다.

권한 확인은 코드가 합니다. 코드에는 실수가 있을 수 있습니다. 조회 조건 한 줄을 빠뜨리면 보이지 않아야 할 자료가 나올 수 있습니다.

그래서 듀오랩스는 데이터베이스에도 같은 규칙을 겁니다. **행 수준 보안(RLS)**이라고 하며, 데이터베이스가 요청한 사용자를 기준으로 접근할 수 있는 행만 돌려줍니다. 코드의 실수가 곧바로 자료 노출로 이어지지 않도록 하는 층입니다.

Supabase 문서 역시 프로덕션 점검 항목으로 노출되는 모든 테이블에 행 수준 보안을 켤 것을 권합니다. 정책 없이 열려 있는 테이블은 클라이언트가 데이터를 읽고 고칠 수 있다고 설명합니다.

여러 회사나 사업장이 한 시스템을 함께 쓰는 경우에는 이 층이 더 중요합니다. 다른 회사의 자료가 섞이는 것을 코드 하나에 맡기지 않게 됩니다.

구축 후 다음을 함께 확인합니다.

역할을 새로 만들거나 권한을 바꾼 뒤에도 같은 확인을 반복합니다.

상황	원인	대응
역할이 너무 많아 관리가 어렵습니다	직급 단위로 역할을 만들었습니다	「무엇을 할 수 있는가」로 묶어 줄입니다
담당자가 바뀔 때마다 권한 요청이 옵니다	사람마다 권한을 따로 주고 있습니다	역할을 바꾸는 방식으로 정리합니다
조회 전용 계정이 필요합니다	초기 역할 설계에 없었습니다	역할을 추가합니다. 대체로 간단합니다
특정 직원만 단가를 못 보게 하고 싶습니다	역할 구분과 예외가 섞였습니다	예외를 만들기보다 역할을 하나 더 두는 편이 관리하기 쉽습니다