참가자 등록 시스템 관리자 권한 분리 설계 및 보안 가이드

운영 현장의 문제와 관리자 권한 세분화 기준 (RBAC 스키마 설계)

행사 당일 오전 8시, 접수대가 열린다. 현장 접수자는 QR 하나 스캔해 참가자를 체크인해야 하는데, 화면에 보이는 건 전체 결제 내역이다. 같은 시각, 등록 창구 운영자는 정회원·준회원·학생회원별 요금이 제대로 자동 계산되고 있는지 확인해야 하고, 마스터 관리자는 운영 대시보드에서 실시간 현황을 볼 수 있어야 한다. 한 시스템에 세 가지 역할이 동시에 움직이는 게 학회 행사의 현실이다.

왜 단일 관리자 계정으로는 안 되는가

학회 통합 솔루션이 회원관리·논문 투고·심사·사전등록·결제를 단일 플랫폼에서 처리한다는 건, 그만큼 한 화면 안에 섞여 있는 데이터의 종류가 많다는 뜻이다. 여기에 협찬사 파트너 포털까지 더해진다 — 참가자 QR 스캔으로 개인정보 동의 기반 연락처를 수집하는 리드 수집 기능이 별도로 존재한다. 권한 경계가 없으면 즉시 문제가 된다.

• 현장 접수자가 전체 참가자 결제 내역을 조회 → 불필요한 개인정보 노출
• 등록 창구 운영자가 CRM 데이터를 수정 → 데이터 무결성 훼손
• 협찬사가 자신의 QR 스캔 리드 이외의 데이터에 접근 → 정보 유출 위험

이걸 막으려면 역할별로 "어디까지 보고, 어디까지 바꿀 수 있는가"를 DB 단에서 정의해야 한다.

최소 권한 원칙: 현장 명찰 발급자를 위한 개인정보 마스킹 구현

현장 접수 데스크에서 가장 빈번하게 발생하는 보안 사고는 사내 관리자의 '우연한 데이터 과노출(Over-exposure)'입니다. 명찰을 발급하려는 접수 담당자에게는 참가자 식별이 최우선이지만, 시스템이 관리자 전용 화면을 그대로 내려주면 생년월일과 휴대폰 번호가 그대로 노출됩니다. 단순히 화면에서 가려주는(Front-end masking) 것만으로는 API 응답 데이터를 중간에 가로채거나 로그로 남길 때 유출 위험이 여전히 존재합니다.

화면 단위가 아닌 'API 응답 단위'의 마스킹

명찰 발급자(현장 접수 권한)가 호출하는 API는 아예 민감 정보 원본을 반환하지 않아야 합니다. 백엔드(Spring Security) 단에서 권한에 따라 데이터를 필터링하여 내려주는 것이 안전합니다.

• 휴대폰 번호:010-12-56 (앞뒤 일부만 노출하여 직접 확인용으로만 사용)
• 생년월일: 월/일 마스킹 처리 또는 연령대/회원 등급(정회원·준회원·학생회원) 식별 코드로 치환

시스템은 이미 등록 모듈을 통해 회원증번호 검증과 등급별 요금 자동 계산을 수행합니다. 따라서 현장에서 굳이 생년월일 원본을 열람할 필요 없이, 유효한 회원인지와 등급이 일치하는지 확인된 '상태값'만 명찰 발급 화면으로 전달하면 됩니다.

Spring Security 및 Next.js 환경에서 권한 인가 및 체크 로직

백엔드와 프론트엔드의 역할 분담

행사 당일, 협찬사가 참가자의 QR 코드를 스캔하며 리드(Lead)를 수집하는 동시에, 학회 관리자는 운영 대시보드에서 사전등록 현황을 점검합니다. 이처럼 단일 플랫폼 안에서 여러 역할이 동시에 움직일 때 권한 인가 로직이 없다면 데이터가 뒤섞이고 노출될 위험이 있습니다.

Spring Security는 백엔드에서 자물쇠 역할을 합니다. 들어오는 API 요청마다 토큰(JWT)을 검증해 해당 사용자가 데이터를 볼 권한이 있는지 판단합니다. Next.js는 프론트엔드에서 로그인한 역할에 맞춰 메뉴를 조건부로 렌더링합니다.

역할별 접근 통제 구조 설계하기

행/열 단위 데이터 접근 제어와 행사 종료 후 체크리스트

행사 종료 직후, 사무국의 관리 포인트는 참가자 안내에서 정산 및 데이터 마감으로 넘어갑니다. 이때 회계 담당자가 결제 및 환불 내역을 확인하려는데 관리자 화면에 참가자의 상세 연락처나 논문 투고 현황까지 전부 노출된다면 심각한 보안 위험입니다.

이를 방지하려면 행(Row)과 열(Column) 단위의 세밀한 데이터 접근 제어가 필수입니다. 단순히 '운영자'라는 통합 권한 하나로 모든 데이터를 열람하게 두어서는 안 됩니다.

행과 열 단위 접근 제어의 실무 기준

화면 설계 시 담당자의 역할에 따라 데이터를 어떻게 가릴 것인지 명확한 기준이 필요합니다.

| 열(Column) 단위 | 데이터 필드(항목)별 노출 제어 | 회계 담당자는 소속이나 연락처 열을 숨기고 '결제 수단