RBAC: 역할 및 권한 관리
1) RBAC 목표 및 원칙
목적: 돈/PII 및 규정 준수 (GDPR/AML/PCI/ISO) 를 보호하기 위해 액세스를 관리 가능하고 검증 가능하며 최소화하십시오.
원칙: 최소 특권· 알아야 할 필요· 의무 분리 (SoD)· 제로 트러스트· 복귀 가능성 (빠른 리콜)· 감사 가능성 (가능성).
2) 권리와 역할의 분류
권한의 종류:- 데이터: 'READ', 'WRITE', 'EXPORT', 'DELETE', 'MASKED _ READ' (PII의 기본값).
- 'APPROVE _ WITHD DRAWAL', 'CHANGE _ FRM _ RULE', 'KYC _ DECISION', 'SANCTIONS _ OVERRIDE'.
- 'ROLE _ Updates', 'USER _ PROVISION', 'SECRET _ ROTATE', 'BREAK _ GLASS'.
- 통합: 'API _ CALL:', 'WEBHOOK _ SING', 'SERVICE _ CONFIG _ Update'.
- 핵심 (скво방법): '직원 _ 기본', '뷰어 _ 내부', '감사 _ 개인 정보 보호'.
- 지원 _ agent ',' vip _ managent ',' payment _ ops ',' aml _ offer ',' kyc _ operator ',' sraw _ analystor ',' rg _ expert ',' bi _ analystor '
- 시스템/해당 시스템: 'devops _ administration', 'dba _ administration', 'service _ play _', 'readed _ Only _ prod'.
- 특권 (PAM/JIT를 통해): 'break _ glass _ administration', 'prod _ db _ jit _ editor'.
3) 역할 공학
1. 리소스 목록: 시스템/테이블/엔드 포인트, 데이터 클래스 (공개/내부/기밀/제한/하이 제한).
2. 기능별 사용자 스토리: 누가 무엇을하고 왜 (목적).
3. 작업 매핑 → 권한-함수 당 최소 세트.
4. 역할 그룹: 하나의 역할 = 하나의 책임 영역; "슈퍼 역할" 을 피하십시오.
5. SoD 테스트: 비 호환성 검사 (예: 'payment _ ops' 및 'fray _ rule _ administration').
6. 파일럿 및 측정: 일시적으로 제한된 그룹을 발행하고 감사 추적을 수집합니다.
7. 버전: 각 역할 변경은 변경 로그가있는 CAB를 통해 이루어집니다.
4) RBAC 엄선 된 ABAC SoD 상호 작용
RBAC는 "원칙적으로 가능한 사람" ABAC- "어떤 조건에서" (환경, 지리, 장치/MDM, 시간, KYC 수준, '목적') 답변합니다.
SoD는 위험한 역할 조합을 금지하며 중요한 행동을 위해 4 눈이 필요합니다.
연습: 기본적으로 역할은 MASKED _ READ를 PII에 제공합니다. 마스크를 벗기지 않은 액세스에는 '목적' + JIT 속성과 긍정적 인 ABAC 정책 결정이 필요합니다.
5) 다중 임대 및 지리적 맥락
세입자 범위: 역할은 임대/브랜드/관할권 ('역할: payment _ ops @ EEA') 과 관련이 있습니다.
지리 키: 지역당 개별 암호화 키 및 액세스 세그먼트 (EC/UK/...).
세분성: 'region _ code' 열 (RLS) 및 플레이어 관할권에 의한 필터링.
6) 행/열 수준 보안 및 마스킹
전략:- RLS (문자열): 국가/브랜드/팀 레코드에만 액세스하십시오.
- CLS (열): 민감한 필드를 사용할 수 있습니다. 마스크를 벗기지 않음-특권 'pii _ unmask' + 'performation' 만 있습니다.
sql
CREATE POLICY rls_tx
ON dwh. transactions
USING (region_code = current_setting('app. region'));
SELECT
CASE WHEN has_priv('pii_unmask') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;7) JIT, 브레이크 글래스 @ info: whatsthis
JIT: 티켓에 따른 임시 특권 역할 (15-120 분); 자동 피드백; 전체 감사.
브레이크 글래스: MFA + 두 번째 확인 및 세션 기록을 통한 비상 액세스; Security + DPO로 검토 후.
PAM: 비밀 저장소, 세션 프록시, 비밀번호/키 회전.
8) 역할 수명주기 (SOP)
SOP-1: 역할 만들기/수정
1. 도메인 → 작업 목록의 소유자에 대한 문의 → 권한 매핑 → SoD 확인 → 파일럿 → CAB → 릴리스 + 문서화.
SOP-2: 요청 및 보조금 접근
1. '목적' 및 마감일 → SoD/관할권 자동 검증 → 데이터 소유자 승인 + 보안 (제한 +) → 발행 (종종 JIT) → 레지스트리 항목이있는 응용 프로그램 (IDM/ITSM).
SOP-3: 피드백/오프 보드
방아쇠: 종료, 역할 변경, 비 활동> 30/60 일, JIT가 만료되었습니다.
자동 리콜 및 로그.
SOP-4: 재 인증
분기별로 소유자는 사용자 역할이 여전히 필요하다는 것을 확인합니 시스템은 "매달린" 권리를 제거합니
9) 역할 행렬 예 (조각)
10) 도구 및 구현 (패턴)
코드로서의 역할 카탈로그: 저장소 + CI 유효성 검사기, 변경 로그의 YAML/JSON.
중앙 IdP/SSO: SCIM 프로비저닝, 그룹 매핑 '그룹 → 역할'.
정책 결정 포인트: 컨텍스트 속성이있는 정책 엔진 (ABAC).
비밀/KMS: 환경/지역/테넌트 당 주요 격리.
데이터 게이트웨이: DWH/BI/내보내기를위한 단일 마스킹/감사 계층.
SIEM/SOAR: 상관 관계 'ROLE _ Updates '/' READ _ PII '/' EXPORT _ DATA', 자동 티켓.
11) 감사 및 벌목
'ROLE _ ASSIN', 'ROLE _ REVOKE', 'ROLE _ Updates', 'BREAK _ GLASS', 'JIT _ GRANT', 'READ _ PII', 'EXPORT _ DATA', 'PAYMENT _ PPAROVE', YC 결정 '.
요구 사항: 각 이벤트에서 WORM 복사, 해시 체인, 패킷 서명, '목적 '/' 티켓 _ id', 시간 동기화.
12) 지표 및 KPI/KRI
적용 범위: RBAC 하의 시스템%
SoD 위반: = 0; 호환되지 않는 역할 (자동 차단) 을 할당하려고 시도합니다.
JIT 비율: 증가율의 80% 이상이 JIT입니다.
오프 보드 TTR: 권리 철회
가면 판독 비율: PII 통화의 95% 이상이 가려져 있습니다.
재 인증: 분기별로 100% 역할이 확인되었습니다.
수출 서명: 서명/로그 수출의 100%.
13) RACI (확대)
14) 점검표
역할을 만들기 전에
- 설명 된 사용자 이야기 및 '목적'
- 리소스 및 데이터 클래스 목록
- 최소 권한 매핑
- SoD 확인/충돌
- 마스킹 및 RLS/CLS 정책
- 재 인증 계획 및 소유자
액세스 권한을 부여하기 전에
- 고정 된 '목적' 및 날짜
- SoD/관할 구역/MDM/MFA 완료
- 기본 마스킹, 프로모션 JIT
- 저널 및 개정 날짜 포함
15) 빈번한 오류 및 패턴 방지
작은 도메인 대신 광범위한 권한을 가진 "슈퍼 역할".
마스킹 및 '목적' 없이 PII에 직접 액세스하십시오.
'PAYMENT _ APPROVE '/' KYC _ APPROVE' 에 대한 SoD/4th 눈이 없습니다.
임시 권리의 확장 "영원히".
prod 데이터를 개발자/단계로 복사합니다.
서명과 로그없이 Opaque 수출.
16) 구현 로드맵
1-2 주: 자산 재고/데이터 분류; 역할의 초안 행렬; SoD 테이블.
3-4 주: 코드 (저장소), IdP 그룹/SCIM, ABAC 엔진 (기본 속성: 환경/geo/MDM/time), JIT/PAM, DWH/BI의 마스킹 계층.
2 월: 재 인증, 오프 보드 자동화, RBAC/SoD/ABAC 위반에 대한 SOAR 경고, 수출 로그/WORM.
3 개월 이상: 속성 확장 (장치 위험, KYC 수준), 액세스 바이어스 감사, 비용 최적화 및 정기적 인 탁상용 연습.
TL; DR
강력한 RBAC = 작은 도메인 역할 + 속성 조건 (ABAC) + SoD 및 JIT/PAM + 마스킹 및 RLS/CLS + 하드 감사 및 재 인증. 이는 누출/남용의 위험을 줄이고 감사 속도를 높이며 플랫폼을 개인 정보 보호 및 규정 준수 요구 사항의 경계 내에 유지합니다.