계정 및 하위 사용자 계층
(섹션: 운영 및 관리)
1) 과제 및 원칙
계정 계층은 조직과 사람들이 플랫폼 리소스에 액세스하는 방법과 권리, 할당량, 예산 및 책임이 분배되는 방법을 정의합니다.
원칙:- 우려의 분리: 우리는 엔티티 트리의 비즈니스 구조와 정책의 권리를 반영합니다.
- 최소 특권: 기본-최소 역할, JIT를 통한 임시 프로모션.
- 합성성: 역할/할당량/제한이 상속되고 무시됩니다.
- 코드 정책: 액세스 정책, 할당량, 청구-다양한 아티팩트.
- 감사-각 작업은 주제, 컨텍스트 및 서명과 관련이 있습니다.
2) 계층 참조 모델
Tenant
├─ Account - legally/operationally significant unit
│ ├─ Sub-account - Product/Region/Team/Project
│ │ ├─ Spaces/Projects/Environments: prod/stage/dev
│ │ └─ Roles and Groups (RBAC/ABAC) for People and Services
│ └─ Shares (limits, budgets, keys, integrations)
└─ Marketplace/Integrations/Affiliates (Outer Loops)- 임차인: 계약 소유자, 고급 청구, 글로벌 정책 및 SSO.
- 계정: 격리 된 책임 영역 (브랜드/국가/회사 코드); 자체 예산/제한.
- 하위 계정: 작업 단위 (제품/스트림/명령); 열쇠, 할당량, 역할 및 감사.
3) 승인 모델
RBAC: ро독점 소유자/관리자/운영자/뷰어/청구/준수.
ABAC: атри자세 '지역', '테넌트', '계정', '환경', '위험 _ 점수', '장치 _ 자세'.
ReBAC: 프로젝트 및 비밀에 대한 "소유/참여/검토" 관계.
실습: 하이브리드-읽을 수있는 기준으로 RBAC, 컨텍스트 제약 조건 (지역/시간/장치) 을위한 ABAC, 리소스 소유를위한 ReBAC.
4) 대표단 및 상속
대표단 다운: 임차인 관리자는 계정 관리자 역할 (하위 계정 관리자) 을 제공합니다.
오버 라이드: 쿼타/제한/정책을 트리 아래로 강화할 수 있습니다.
신탁 경계: PII/금융-계정 수준 "신탁 영역" 에서만; 하위 계정은 토큰/집계를 봅니다.
브레이크 글래스: 짧은 TTL, 자동 경보 및 사후 부검으로 긴급 액세스.
5) 쿼타, 예산, 청구
쿼터: 요청/초, 이벤트/일, 탈출, 저장, 키/웹 후크.
예산: 월간 상한 및 경고 (80/90/100%), 자동 조절/서스펜션.
청구: 세입자/계정 수준의 송장; 하위 계정 및 비용 센터 섹션.
이전 가격: BU/지역 간 내부 요금.
공정 사용: 공공 제한, 요율 제한, "버스트" 에 대한 보호.
6) 신원 및 SSO/SCIM
SSO (SAML/OIDC): 세입자 수준의 중앙 집중식 항목.
SCIM: 사용자/그룹의 자동 생성/비활성화 및 역할 바인딩.
JML (Joiner/Mover/Leaver): 시작 역할의 자동 발행, 번역 중 수정, 해고시 즉시 리콜.
MFA/FIDO2: 관리자, 재무 및 PII 액세스에 필수적입니다.
장치 자세: 장치 상태 허용 오차 (암호화, EDR).
7) 서비스 계정 및 키
하위 계정 + 환경 당 서비스 계정, 공유 비밀이 없습니다.
워크로드 아이덴티티: 수명이 짧은 토큰, 하단/기능에 바인딩됩니다.
KMS/Vault: 비밀 교체, 역할 액세스, DSSE 서명.
웹 후크: HMAC/EdUSA 서명, 'nonce + timestamp', TTL 창.
8) 데이터 모델 (단순화)
'테넌트' '{id, 이름, sso, 빌링 _ 프로필, 정책 []}'
'계정' '{id, 테넌트 _ id, 지역, 법률 _ 엔터티, 할당량 {}, 예산 {}, risk _ tier}'
'sub _ 플레이어' '{id, 계정 _ id, 제품, 환경, 키 [], webhooks [], 제한 {}}'
'role' '{id, scope: 세입자 계정' sub _ 계정, 권한 []} '
'멤버십' '{주제 _ id, role _ id, scope _ ref, ttl, 정당화}'
'정책' '{유형: rbac' abac 'od' quoter, 버전, 규칙, 서명} '
'감사 _ 이벤트' '언제, 언제, 어디서, 추적, 서명}'
'quarte _ usage' '{scope _ ref, metric, woods, cap}'
9) API 계약
관리:- 'POST/세입자/{ id }/계정' - 계정 작성 (정책/할당량/청구).
- 'POST/계정/{ id }/하위 계정' -하위 계정 (키, 웹 후크) 을 만듭니다.
- 'PUT/역할/{ id}' - 역할 정책; ' POST/회원-역할을 할당하십시오.
- 'POST/Access/elevate' -TTL 및 정당화로 JIT 향상.
- 'GET/할당량/사용량' -사용량/캡; ' POST/할당량/재정의 '.
- 'GET/감사/이벤트? scope =... '- 서명 된 로그.
- 'GET/상태/액세스' -역할/TTL/키.
- 함수: 'QuotaCapReached', 'RoleExpiring', 'KeyRotationDue', 'PolicyChanged'.
10) RACI (핵심 영역)
11) 측정 및 SLO
TTG (Time-to-Grant): 중간 표준 액세스 문제
JIT 적용 범위: 임시 역할을 통한 특권 거래의 80% 이상.
SoD 위반: 0 달력 prod; 제거 TTR 체크 24 시간.
고아원 액세스: "잊혀진" 권리의 공유 1%.
쿼터 정확도: 일치하는 발생/사용 99%.
감사 완료: 100% 중요한 서명/영수 활동.
12) 대시 보드
액세스 건강: 레벨 별 활성 역할, TTL 만료, SoD 위반.
FinOps: 할당량 사용량, 예산 예측, 탈출/계산 이상.
보안: 키 회전, MFA/SSO 고장, 코호트의 위험률.
준수: 재 인증 상태, 감사 기록, 정책 위반.
작업: MTTR 액세스 요청, 새 명령에 대한 TTFI.
13) 데이터 구분 및 개인 정보
데이터 도메인: PII/재무-계정 수준 만; 하위 계정-집계/토큰.
지역: 지역당 데이터 및 키 (신탁 지역) 의 현지화.
PII 요청: 승인 된 bs을 통해서만; 토큰 화 및 마스킹.
14) 위험 및 반 패턴
플랫 모델: 모두- "admins →" 사고 및 누출.
공유 비밀: 추적 불가능 및 리뷰 불가능.
SoD 없음: 한 사람이 지불/제한을 작성하고 승인합니다.
게시되지 않은 환경: prod의 개발 키; 테스트와 실제 데이터를 혼합합니다.
"무한" 역할: TTL/재 인증 → 위험 축적 없음.
약한 할당량: 하나의 하위 계정이 모든 사람의 용량을 "먹습니다".
15) 사건 플레이 북
하위 계정 키의 타협: 즉각적인 해지, 의존성 회전, 할당량 재 계산, 지난 7-30 일의 감사.
초과 할당량: 자동 조절/일시 정지, 소유자의 알림, 임시 예산 한도.
SoD의 위반: 작업 차단, 역할 제거, 정책 조사 및 수정.
웹 후크 대체: 서명/외부 TTL, 리 키, 상태 종료 지점 조정없이 수신 금지.
16) 온 보딩 및 라이프 사이클
1. 임차인 초기화: SSO/SCIM, 청구 프로필, 글로벌 정책.
2. 계정 생성-지역, 쿼타, 예산, 데이터 영역, 기본 역할
3. 하위 계정: 키/웹 후크, 팀 역할, 통합.
4. JML/재 인증: 분기 별 권리 검토, "침목" 자동 제거.
5. EOL: 아카이브, 주요 리콜, 소유권 이전, 청구 마감.
17) 구현 점검표
- 화해 임차인 → 계정 → 하위 계정 트리 및 상속 규칙.
- 역할 (RBAC) 및 컨텍스트 정책 (ABAC), SoD 행렬을 설명하십시오.
- SSO/SCIM, JML 프로세스 및 JIT 부스트를 시작하십시오.
- 할당량/예산/캡 규칙 및 경고를 입력하십시오.
- KMS/Vault 배포, 회전 및 공유 비밀.
- 코드 정책, 서명 된 릴리스 및 WORM 로그를 포함하십시오.
- 관리 API/웹 후크, 상태 끝점 및 감사 설정.
- 액세스/FinOps/보안/규정 준수 대시 보드 구축.
- GameDay 수행: 주요 누출, 쿼터 폭풍, IdP 실패, SoD 위반.
- 역할을 정기적으로 재 인증하고 한계를 검토하십시오.
18) FAQ
계정과 하위 계정의 경계를 유지할 수있는 곳은 어디입니까?
팀/제품/환경에 대한 재정/규정 준수/규제 (계정) 및 하위 계정이 변경되는 경우.
여러 하위 계정의 할당량을 "접착" 할 수 있습니까?
예, 수영장과 우선 순위를 통해 용량이 "연소" 됩니다.
임시 액세스를 신속하게 발행하는 방법?
MFA 및 TTL을 사용한 JIT 응용 프로그램, 권한 부여 세션을위한 자동화 및 사후 부검.
수요일에 다른 키가 필요합니까?
필수: 네트워크 및 권한을 격리 한 개발/단계/prod에 대한 별도의 서비스 계정/키.
요약: 계정 및 하위 사용자의 계층 구조는 관리 가능성의 프레임 워크입니다. 엔터티의 읽을 수있는 구조, 상속 된 정책, 엄격한 할당량 및 청구, 안전한 신원 확인 및 입증 가능한 감사. RBAC/ABAC/ReBAC, JIT/SoD 및 코드 정책 하이브리드를 구현함으로써 제품, 팀 및 지역별로 확장 할 때 빠른 온 보딩, 예측 가능한 비용 및 지속 가능한 보안을 얻을 수 있습니다.