IAM 도메인 요구사항 명세서

1. 기능 요구사항

1.1 사용자 유형별 권한 관리

백엔드 요구사항

• IAM-FR-BE-001: 모든 IAM 리소스에 대한 완전한 접근 권한을 가져야 한다. (System Admin)
• IAM-FR-BE-002: 권한 생성, 수정, 삭제가 가능해야 한다. (System Admin)
• IAM-FR-BE-003: 역할 생성, 수정, 삭제가 가능해야 한다. (System Admin)
• IAM-FR-BE-004: 정책 생성, 수정, 삭제가 가능해야 한다. (System Admin)
• IAM-FR-BE-005: 모든 사용자의 권한 할당/해제가 가능해야 한다. (System Admin)
• IAM-FR-BE-006: 시스템 수준의 정책 관리가 가능해야 한다. (System Admin)
• IAM-FR-BE-007: IAM 리소스에 대한 관리 권한을 가져야 한다. (IAM Admin)
• IAM-FR-BE-008: 권한 생성, 수정 (삭제 제외)이 가능해야 한다. (IAM Admin)
• IAM-FR-BE-009: 역할 생성, 수정 (삭제 제외)이 가능해야 한다. (IAM Admin)
• IAM-FR-BE-010: 정책 생성, 수정 (삭제 제외)이 가능해야 한다. (IAM Admin)
• IAM-FR-BE-011: 할당된 범위 내 사용자 권한 관리가 가능해야 한다. (IAM Admin)
• IAM-FR-BE-012: 감사 로그 조회가 가능해야 한다. (IAM Admin)
• IAM-FR-BE-013: API를 통한 권한 검증이 가능해야 한다. (Service Account)
• IAM-FR-BE-014: 할당된 범위 내 권한 조회가 가능해야 한다. (Service Account)
• IAM-FR-BE-015: 권한 캐시 관리가 가능해야 한다. (Service Account)
• IAM-FR-BE-016: 제한된 범위의 정책 평가가 가능해야 한다. (Service Account)
• IAM-FR-BE-017: 실시간 권한 검증이 가능해야 한다. (Service Account)
• IAM-FR-BE-018: 자신의 권한 조회가 가능해야 한다. (Regular User)
• IAM-FR-BE-019: 할당된 역할 확인이 가능해야 한다. (Regular User)
• IAM-FR-BE-020: 권한 검증 요청이 가능해야 한다. (Regular User)
• IAM-FR-BE-021: 제한된 범위의 권한 위임이 가능해야 한다. (Regular User)
• IAM-FR-BE-022: 시스템은 사용자 유형을 구분하여 권한을 관리해야 한다:
  • 고객(환자) 사용자에 대한 권한 관리
  • 내부 운영자, 의료진 등 고객이 아닌 사용자에 대한 권한 관리
• IAM-FR-BE-111: 시스템은 게스트 사용자 유형에 대한 전용 역할과 권한 세트를 정의해야 한다.
  • 게스트 사용자는 읽기 전용·체험 기능 등 제한된 권한만 부여받아야 한다.
  • 게스트 권한 세트는 Plan/Group 연동 결과에 따라 교집합으로 계산되어 추가 제한을 적용해야 한다.
  • 게스트에서 정규 사용자로 전환 시 기존 게스트 권한은 즉시 해제되고, 신규 역할이 재평가되어야 한다.

1.2 권한(Permission) 관리

백엔드 요구사항

• IAM-FR-BE-023: 권한을 생성, 조회, 수정, 삭제할 수 있어야 한다. (CRUD)
• IAM-FR-BE-024: 권한 메타데이터(설명 등)를 관리할 수 있어야 한다. (CRUD)
• IAM-FR-BE-025: 권한 간의 계층 구조 또는 그룹핑을 지원할 수 있어야 한다. (CRUD, 선택 사항)
• IAM-FR-BE-026: 권한 간의 관계(예: 의존성)를 관리할 수 있어야 한다. (CRUD, 선택 사항)
• IAM-FR-BE-027: 실시간으로 사용자의 특정 권한 보유 여부를 검증할 수 있어야 한다. (검증)
• IAM-FR-BE-028: 성능 향상을 위해 권한 검증 결과를 캐싱할 수 있어야 한다. (검증)
• IAM-FR-BE-029: 요청 컨텍스트(예: 특정 리소스 ID)를 기반으로 권한을 평가할 수 있어야 한다. (검증)
• IAM-FR-BE-030: 모든 권한 검증 시도 및 결과를 감사 로그로 기록해야 한다. ([Audit 도메인] 의존, 검증)

1.3 역할(Role) 관리

백엔드 요구사항

• IAM-FR-BE-031: 역할을 생성, 조회, 수정, 삭제할 수 있어야 한다. (CRUD)
• IAM-FR-BE-032: 역할은 특정 기능 또는 책임 단위를 나타내며, 여러 권한(Permission)의 집합으로 구성된다. (CRUD)
• IAM-FR-BE-033: 역할에 여러 권한(Permission)을 할당하거나 해제할 수 있어야 한다. (CRUD)
• IAM-FR-BE-034: 역할 메타데이터(설명 등)를 관리할 수 있어야 한다. (CRUD)
• IAM-FR-BE-035: 역할의 활성/비활성 상태를 관리할 수 있어야 한다. (상태 관리)
• IAM-FR-BE-036: 역할 변경 이력을 관리할 수 있어야 한다. (상태 관리)
• IAM-FR-BE-037: 역할 할당 및 해제에 대한 감사 로그를 기록해야 한다. ([Audit 도메인] 의존, 상태 관리)

1.4 정책(Policy) 관리

백엔드 요구사항

• IAM-FR-BE-038: 접근 제어 정책을 생성, 조회, 수정, 삭제할 수 있어야 한다. (CRUD)
• IAM-FR-BE-039: 정책에 적용될 조건(예: 시간, IP 주소, 리소스 속성, 사용자 서비스 상태[Active/Suspended])을 관리할 수 있어야 한다. (CRUD)
• IAM-FR-BE-040: 여러 정책이 충돌할 경우 적용될 우선순위를 관리할 수 있어야 한다. (CRUD)
• IAM-FR-BE-041: 정책 변경 이력을 추적하기 위한 버전 관리를 지원해야 한다. (CRUD)
• IAM-FR-BE-042: 정의된 조건에 따라 정책을 평가할 수 있어야 한다. (평가)
• IAM-FR-BE-043: 여러 정책(예: 사용자 직접 할당 정책, 그룹 상속 정책)을 조합하여 최종 접근 허용 여부를 평가할 수 있어야 한다. (평가)
• IAM-FR-BE-044: 정책 충돌 시 정의된 우선순위 또는 규칙(예: Deny-overrides)에 따라 해결해야 한다. (평가)
• IAM-FR-BE-112: 시스템은 정책 평가 시 신원 수준(identityLevel)과 게스트 전용 조건을 고려해야 한다.
  • identityLevel=guest인 토큰은 게스트 허용 목록에 포함된 리소스에서만 허용되어야 한다.
  • Step-up 인증이 필요한 리소스는 정책에서 requiresIdentityLevel>=registered 조건으로 명시해야 한다.
  • 게스트에서 승격된 사용자는 정책 캐시 무효화 후 재평가되어야 한다.
• IAM-FR-BE-045: 성능 향상을 위해 정책 평가 결과를 캐싱할 수 있어야 한다. (평가)

1.5 플랜(Plan) 연동 관리

백엔드 요구사항

• IAM-FR-BE-046: Plan 도메인에서 관리되는 플랜 정보를 참조할 수 있어야 한다. ([Plan 도메인] 의존)
• IAM-FR-BE-047: 플랜과 역할(Role) 간의 관계를 관리할 수 있어야 한다. (플랜-역할 관계)
• IAM-FR-BE-048: 플랜에 역할을 추가하거나 제거하는 기능을 제공해야 한다. (플랜-역할 관계)
• IAM-FR-BE-049: 특정 플랜에 포함된 역할 목록을 조회할 수 있어야 한다. (플랜-역할 관계)
• IAM-FR-BE-050: 플랜-역할 관계 변경에 대한 감사 로그를 기록해야 한다. ([Audit 도메인] 의존, 관계 관리)
• IAM-FR-BE-051: (Plan 도메인 연동): 플랜의 생명주기 관리, 플랜 유형 정의, 플랜별 기능 범위 등은 Plan 도메인에서 관리되며, IAM 도메인은 플랜 기반 권한 부여를 담당한다.

1.5.1 그룹과 플랜의 역할 구분

책임 정의

IAM 도메인 내에서 그룹과 플랜은 다음과 같이 명확히 구분된 책임과 역할을 가진다:

• 그룹 (Group): 사용자의 조직적/기능적 분류 ([Group 도메인] 관리)

  • 목적: 사용자를 조직 구조, 기능적 역할, 지리적 위치 등에 따라 분류한다. "이 사용자는 어떤 조직/팀에 속하는가?"에 대한 답을 제공한다.
  • IAM 도메인에서의 역할:
    • 그룹 기반 역할 할당: 그룹에 역할을 할당하여 해당 그룹 멤버에게 조직/기능적 권한 부여
    • 정책 적용 단위: 그룹 단위로 특정 정책을 적용하거나 리소스 접근 제어
    • 권한 계산: 그룹을 통해 부여된 권한 집합 계산
  • 독립성: 그룹은 플랜과 독립적으로 관리되며, 그룹 변경이 플랜에 영향을 주지 않음

• 플랜 (Plan): 서비스 수준 및 기능 범위 정의 ([Plan 도메인] 관리)

  • 목적: 사용자가 이용할 수 있는 서비스의 범위와 기능 수준을 정의한다. "이 사용자는 어느 수준의 서비스를 이용할 수 있는가?"에 대한 답을 제공한다.
  • IAM 도메인에서의 역할:
    • 플랜 기반 역할 할당: 플랜에 역할을 할당하여 서비스 수준별 권한 부여
    • 기능 제한 관리: 플랜별로 이용 가능한 기능과 제한사항 정의
    • 권한 계산: 플랜을 통해 부여된 권한 집합 계산
  • 독립성: 플랜은 그룹과 독립적으로 관리되며, 플랜 변경이 그룹에 영향을 주지 않음

다차원 권한 계산

• 그룹 권한: User → Group → Role → Permission (조직/기능적 권한)
• 플랜 권한: User → Plan → Role → Permission (서비스 수준 권한)
• 최종 권한: 그룹 권한 ∩ 플랜 권한 (교집합)

1.6 그룹(Group) 연동 관리

백엔드 요구사항

• IAM-FR-BE-052: Group 도메인에서 관리되는 그룹 정보를 참조할 수 있어야 한다. ([Group 도메인] 의존)
• IAM-FR-BE-053: 그룹과 역할 간의 관계를 관리할 수 있어야 한다. (그룹-역할 관계)
• IAM-FR-BE-054: 그룹에 역할을 추가하거나 제거하는 기능을 제공해야 한다. (그룹-역할 관계)
• IAM-FR-BE-055: 특정 그룹에 할당된 역할 목록을 조회할 수 있어야 한다. (그룹-역할 관계)
• IAM-FR-BE-056: 사용자-그룹 관계를 조회할 수 있어야 한다. ([User 도메인], [Group 도메인] 의존)
• IAM-FR-BE-057: 특정 사용자가 속한 그룹 목록을 조회할 수 있어야 한다. (사용자-그룹 관계)
• IAM-FR-BE-058: 그룹을 통해 부여된 권한 집합을 계산할 수 있어야 한다. (그룹 권한 계산)
• IAM-FR-BE-059: 그룹 기반 권한 부여 로직을 구현할 수 있어야 한다. (그룹-역할 연계)
• IAM-FR-BE-060: 그룹-역할 관계 변경에 대한 감사 로그를 기록해야 한다. ([Audit 도메인] 의존, 관계 관리)
• IAM-FR-BE-061: (Group 도메인 연동): 그룹의 생명주기 관리, 그룹 유형 정의, 그룹 계층 구조 등은 Group 도메인에서 관리되며, IAM 도메인은 그룹 기반 권한 부여를 담당한다.

1.7 접근 제어 결정

백엔드 요구사항

• IAM-FR-BE-062: 사용자의 최종 권한은 그룹 기반 권한과 플랜 기반 권한의 교집합으로 결정되어야 한다. ([User 도메인], [Group 도메인], [Plan 도메인] 의존)
  • 그룹 권한 경로: User → Group → Role → Permission (조직/기능적 권한)
  • 플랜 권한 경로: User → Plan → Role → Permission (서비스 수준 권한)
  • 최종 권한 계산: GroupPermissions ∩ PlanPermissions
• IAM-FR-BE-063: 시스템은 두 권한 경로를 독립적으로 계산한 후 교집합을 구해야 한다. (다차원 권한 계산)
• IAM-FR-BE-064: 그룹 변경과 플랜 변경이 서로 독립적으로 처리되어야 한다. (독립적 권한 관리)
• IAM-FR-BE-065: 시스템은 특정 사용자의 특정 권한 보유 여부를 두 경로 모두에서 확인해야 한다. (권한 검증)
• IAM-FR-BE-066: 특정 사용자에 대해 최종적으로 부여된 모든 유효 권한 목록을 조회하는 API를 제공해야 한다. (유효 권한 조회)
• IAM-FR-BE-067: 시스템은 사용자 유형(고객 또는 내부 운영자)에 따라 적절한 권한 계산 로직을 적용해야 한다.
• IAM-FR-BE-068: 플랜 또는 그룹 변경 시 해당 사용자들의 권한이 자동으로 재계산되어야 한다. (동적 권한 업데이트)
• IAM-FR-BE-069: 권한 캐시는 그룹 또는 플랜 변경 시 즉시 무효화되어야 한다. (캐시 일관성)

1.8 사용자 유형 분리

백엔드 요구사항

• IAM-FR-BE-070: 시스템은 사용자 유형을 명확히 구분하여 관리해야 한다:
  • 고객(환자) 사용자: 서비스의 주요 소비자로, 'private' 스키마에 데이터가 저장됨
  • 내부 운영자 사용자: 관리자, 의료진, 기술 담당자 등으로, 'operation' 스키마에 데이터가 저장됨
• IAM-FR-BE-071: 사용자 유형에 따라 다른 권한 부여 모델을 적용할 수 있어야 한다:
  • 고객(환자) 사용자: 주로 그룹-플랜 기반 권한 부여 ([Plan 도메인] 연동)
  • 내부 운영자 사용자: 주로 역할 직접 할당 기반 권한 부여
• IAM-FR-BE-072: 사용자 유형 간 명확한 접근 제어 경계를 설정해야 한다:
  • 고객 사용자는 다른 고객 데이터에 접근할 수 없다.
  • 내부 운영자는 할당된 권한에 따라 고객 데이터에 접근할 수 있다.
  • 시스템 관리자는 모든 데이터에 접근할 수 있다.
• IAM-FR-BE-073: 사용자 유형에 따른 적절한 감사 로깅을 구현해야 한다.

1.9 Service Account 관리

1.9.1 Service Account 개요

Service Account는 시스템 간 통신 또는 자동화된 작업을 위한 특별한 유형의 계정입니다. Google Cloud Platform의 Service Account 모델을 참조하여 설계되었으며, 다음과 같은 특징을 가집니다:

• 비인간 사용자: 실제 사람이 아닌 애플리케이션, 서비스, 워크로드를 위한 계정
• API 기반 인증: 비밀번호 대신 API Key와 JWT 토큰을 사용한 인증
• 프로그래밍 방식 접근: 자동화된 시스템 간 통신에 최적화
• 최소 권한 원칙: 필요한 최소한의 권한만 부여

1.9.2 Service Account 생명주기 관리

백엔드 요구사항

• IAM-FR-BE-074: 생성: 새로운 Service Account와 초기 API Key를 생성할 수 있어야 합니다.
• IAM-FR-BE-075: 조회: Service Account 정보(ID, 이름, 설명, 상태, 생성일시 등)를 조회할 수 있어야 합니다.
• IAM-FR-BE-076: 수정: Service Account의 메타데이터(이름, 설명 등)를 수정할 수 있어야 합니다.
• IAM-FR-BE-077: 상태 관리: Service Account의 활성화/비활성화 상태를 관리할 수 있어야 합니다.
  • ACTIVE: 활성 상태, 정상적인 API 호출 가능
  • INACTIVE: 비활성 상태, 모든 API 호출 차단
  • SUSPENDED: 일시 정지 상태, 보안 이슈 등으로 임시 차단
• IAM-FR-BE-078: 삭제: 더 이상 사용하지 않는 Service Account를 안전하게 삭제할 수 있어야 합니다.
• IAM-FR-BE-079: 이력 관리: Service Account의 생성, 수정, 삭제 이력을 추적할 수 있어야 합니다.

1.9.3 인증 방식 및 자격증명 관리

인증 방식 개요

Service Account 기반 인증은 Google Service Account와 유사한 API Key + JWT 하이브리드 방식을 사용합니다:

1. 장기 자격증명 (Long-term Credential): API Key

   • Service Account 생성 시 발급되는 장기 보관용 인증 키
   • Google Service Account의 Private Key와 동일한 역할
   • 안전한 저장소에 보관하며 주기적 로테이션 필요

2. 단기 접근 토큰 (Short-term Access Token): JWT Token

   • API Key를 사용하여 발급받는 단기 유효 토큰 (기본 1시간)
   • 실제 API 호출 시 사용하는 Bearer Token
   • 만료 시 API Key로 재발급

인증 플로우

1. Service Account 생성 → API Key 발급 (장기 자격증명)
2. API Key → IAM 서버 → JWT Token 발급 (단기 토큰)
3. JWT Token → 실제 API 호출 (Bearer Authorization)
4. Token 만료 → API Key로 재발급 (refresh token 미지원)

JWT 토큰 관리 요구사항

• IAM-FR-BE-080: 토큰 발급: Service Account가 API Key를 사용하여 JWT 토큰을 발급받을 수 있어야 합니다.
• IAM-FR-BE-081: 토큰 검증: 다른 서비스가 JWT 토큰의 유효성을 검증할 수 있어야 합니다.
• IAM-FR-BE-082: 토큰 재발급: Service Account는 refresh token을 지원하지 않습니다. 토큰 만료 시 API Key를 사용하여 새로운 JWT 토큰을 발급받아야 합니다.
• IAM-FR-BE-083: 토큰 무효화: 보안상 필요 시 특정 토큰 또는 Service Account의 모든 토큰을 무효화할 수 있어야 합니다.

API Key 관리 요구사항 (장기 자격증명)

• IAM-FR-BE-084: API Key 생성: Service Account 생성 시 고유한 API Key가 자동 생성되어야 합니다.
• IAM-FR-BE-085: API Key 재생성: 보안 로테이션을 위해 기존 API Key를 무효화하고 새로운 키를 생성할 수 있어야 합니다.
• IAM-FR-BE-086: API Key 검증: JWT 토큰 발급 시 API Key의 유효성을 검증해야 합니다.
• IAM-FR-BE-087: API Key 상태 관리: API Key의 활성/비활성 상태를 개별적으로 관리할 수 있어야 합니다.

1.9.4 Service Account 권한 및 접근 제어

권한 관리 요구사항

• IAM-FR-BE-088: 최소 권한 원칙: Service Account는 필요한 최소한의 권한만을 가져야 합니다.
• IAM-FR-BE-089: 역할 기반 권한: Service Account는 특정 역할(Role)에 할당되어 권한을 상속받습니다.
• IAM-FR-BE-090: 네임스페이스 격리: 서비스별로 Service Account를 격리하여 관리합니다.
• IAM-FR-BE-091: 권한 검증: 실시간으로 Service Account의 권한을 검증할 수 있어야 합니다.
• IAM-FR-BE-092: 권한 위임: Service Account가 다른 Service Account에게 제한된 권한을 위임할 수 있어야 합니다.

접근 제어 요구사항

• IAM-FR-BE-093: 리소스 기반 접근 제어: 특정 리소스에 대한 Service Account의 접근을 세밀하게 제어할 수 있어야 합니다.
• IAM-FR-BE-094: 시간 기반 접근 제어: 특정 시간대에만 접근을 허용하는 정책을 적용할 수 있어야 합니다.
• IAM-FR-BE-095: IP 기반 접근 제어: 특정 IP 주소 또는 네트워크에서만 접근을 허용할 수 있어야 합니다.

1.9.5 보안 및 규정 준수

암호화 및 보안 요구사항

• IAM-FR-BE-096: 암호화 알고리즘:
  • API Key 저장: SHA-256 해시 알고리즘 사용
  • JWT 서명: RS256 또는 ES256 알고리즘 사용
• IAM-FR-BE-097: API Key 보안:
  • 해시하여 데이터베이스 저장 (평문 저장 금지)
  • 정기적인 키 로테이션 지원 (최소 90일마다)
  • 키 유출 시 즉시 무효화 가능
• IAM-FR-BE-098: 이상 패턴 감지: 비정상적인 접근 패턴 감지 및 자동 차단
• IAM-FR-BE-099: Rate Limiting: Service Account별 요청 제한 (분당 1000 요청)

토큰 전파 및 체이닝

• IAM-FR-BE-100: 호출 체인 추적: 서비스 간 호출 체인에서 원본 요청자 정보 추적
• IAM-FR-BE-101: 토큰 체이닝: 다중 서비스 호출 시 전체 호출 경로 추적
• IAM-FR-BE-102: 컨텍스트 전파: 원본 사용자 정보(있는 경우) 포함

1.9.6 감사 및 모니터링

감사 로깅 요구사항

• IAM-FR-BE-103: 인증 이벤트 로깅: 모든 Service Account 인증 시도 및 결과 기록
• IAM-FR-BE-104: API 호출 로깅: Service Account를 통한 모든 API 호출 기록
• IAM-FR-BE-105: 변경 이력 추적: Service Account 생성, 수정, 삭제 이력 추적
• IAM-FR-BE-106: 권한 변경 로깅: Service Account 권한 할당/해제 이력 기록

모니터링 요구사항

• IAM-FR-BE-107: 실시간 모니터링: 토큰 사용 패턴 및 보안 이벤트 실시간 모니터링
• IAM-FR-BE-108: 사용량 통계: Service Account별 API 사용량 및 패턴 분석
• IAM-FR-BE-109: 성능 모니터링: 인증 및 권한 검증 성능 모니터링
• IAM-FR-BE-110: 알림 시스템: 비정상적인 활동 감지 시 자동 알림

1.9.7 관리 인터페이스

프론트엔드 요구사항

• IAM-FR-FE-001: TBD

2. 비기능 요구사항

2.1 보안

접근 제어

• IAM-NFR-001: 모든 API 요청은 인증 및 인가를 거쳐야 한다.
• IAM-NFR-002: 역할 기반 접근 제어(RBAC)를 지원해야 한다.
• IAM-NFR-003: 정책 기반 접근 제어(PBAC/ABAC)를 지원해야 한다.
• IAM-NFR-004: 최소 권한 원칙을 적용하여 리소스 접근을 제어해야 한다.

데이터 보안

• IAM-NFR-005: 민감한 권한 또는 정책 정보는 암호화하여 저장해야 한다.
• IAM-NFR-006: 권한 데이터의 무결성을 보장해야 한다. (예: 체크섬, 버전 관리)
• IAM-NFR-007: 암호화 키는 안전하게 관리되어야 한다.
• IAM-NFR-008: 권한, 역할, 정책 데이터에 대한 모든 접근 및 변경은 감사 로그로 기록되어야 한다.

API 보안

• IAM-NFR-009: 입력값 검증을 통해 Injection 공격 등을 방지해야 한다.
• IAM-NFR-010: 비정상적인 요청 패턴을 방지하기 위해 Rate Limiting을 적용해야 한다.
• IAM-NFR-011: 특정 IP 주소에서의 접근을 제한하거나 허용할 수 있어야 한다.
• IAM-NFR-012: API 호출에 대한 상세 감사 로그를 기록해야 한다.

Service Account 보안

• IAM-NFR-013: Service Account API 키는 강력한 암호화 알고리즘(예: SHA-256)으로 해싱하여 저장해야 한다.
• IAM-NFR-014: Service Account JWT 토큰은 RS256 또는 ES256 알고리즘으로 서명되어야 한다.
• IAM-NFR-015: Service Account 토큰에는 민감한 정보(API 키, 비밀번호 등)가 포함되어서는 안 된다.
• IAM-NFR-016: Service Account별 Rate Limiting을 적용하여 과도한 API 호출을 방지해야 한다.
• IAM-NFR-017: Service Account의 비정상적인 접근 패턴(예: 짧은 시간 내 대량 요청, 비정상적인 IP)을 감지하고 차단해야 한다.
• IAM-NFR-018: Service Account 토큰 유출 시 즉시 무효화할 수 있는 메커니즘을 제공해야 한다.

2.2 성능

응답 시간

• IAM-NFR-019: 권한 검증 API 평균 응답 시간: < 50ms
• IAM-NFR-020: 역할 조회 API 평균 응답 시간: < 100ms
• IAM-NFR-021: 정책 평가 API 평균 응답 시간: < 200ms
• IAM-NFR-022: 권한/역할 할당 API 평균 응답 시간: < 500ms
• IAM-NFR-023: 정책 생성/수정 API 평균 응답 시간: < 1초
• IAM-NFR-024: Service Account JWT 토큰 발급 API 평균 응답 시간: < 100ms
• IAM-NFR-025: Service Account 토큰 검증 API 평균 응답 시간: < 30ms

처리량

• IAM-NFR-026: 초당 최소 1000건의 권한 검증 요청을 처리할 수 있어야 한다.
• IAM-NFR-027: 초당 최소 100건의 역할 할당/해제 요청을 처리할 수 있어야 한다.
• IAM-NFR-028: 초당 최소 50건의 정책 평가 요청을 처리할 수 있어야 한다.
• IAM-NFR-029: 초당 최소 20건의 정책 생성/수정 요청을 처리할 수 있어야 한다.
• IAM-NFR-030: 초당 최소 2000건의 Service Account 토큰 검증 요청을 처리할 수 있어야 한다.
• IAM-NFR-031: 초당 최소 100건의 Service Account 토큰 발급 요청을 처리할 수 있어야 한다.

캐싱 전략

• IAM-NFR-032: 권한 평가 결과를 캐싱하여 반복적인 검증 속도를 향상시켜야 한다.
• IAM-NFR-033: 역할-권한 매핑 정보를 캐싱해야 한다.
• IAM-NFR-034: 자주 사용되는 정책 정보를 캐싱해야 한다.
• IAM-NFR-035: 사용자-역할 매핑 정보를 캐싱해야 한다.
• IAM-NFR-036: Service Account 토큰 검증 결과를 캐싱하여 반복 검증 성능을 향상시켜야 한다.
• IAM-NFR-037: Service Account 권한 정보를 캐싱하여 빠른 권한 확인을 지원해야 한다.
• IAM-NFR-038: 캐시 데이터의 일관성을 유지하기 위한 적절한 무효화 전략을 사용해야 한다.

2.3 가용성

서비스 가용성

• (공통 정책 참조) 서비스 가용성/복구/무중단 배포는 Platform 도메인 기준을 따른다: PLT-NFR-004, PLT-NFR-005, PLT-NFR-007

데이터 가용성

• (공통 정책 참조) 백업/복구/다중 AZ는 Platform 도메인 기준을 따른다: PLT-NFR-006

2.4 확장성

수평적 확장

• (공통 정책 참조) 수평 확장/로드 밸런싱은 Platform 도메인 기준을 따른다: PLT-NFR-001, PLT-NFR-003

기능 확장성

• IAM-NFR-047: 새로운 권한 유형이나 리소스 타입을 쉽게 추가할 수 있어야 한다.
• IAM-NFR-048: 외부 시스템(예: LDAP, SSO)과의 연동이 용이해야 한다.
• IAM-NFR-049: 정책 조건에 사용자 정의 속성을 사용할 수 있도록 확장 가능해야 한다.

2.5 사용자 유형별 권한 관리

• IAM-NFR-050: 인증 시스템 전체 설정을 관리할 수 있어야 한다. (System Admin, 예시 - IAM에 맞게 수정 필요)
• IAM-NFR-051: 모든 사용자의 권한 상태를 관리할 수 있어야 한다. (System Admin)
• IAM-NFR-052: 역할 및 정책 관리 정책을 관리할 수 있어야 한다. (System Admin, 예시)
• IAM-NFR-053: API 호출 제한 없이 사용할 수 있어야 한다. (System Admin)
• IAM-NFR-054: 할당된 범위 내 사용자의 권한 상태를 관리할 수 있어야 한다. (IAM Admin)
• IAM-NFR-055: 역할 및 정책 상태를 조회할 수 있어야 한다. (IAM Admin, 예시)
• IAM-NFR-056: 시간당 최대 10,000 요청으로 제한되어야 한다. (IAM Admin, 예시 - 조정 필요)
• IAM-NFR-057: 권한 검증을 수행할 수 있어야 한다. (Service Account)
• IAM-NFR-058: 정책 평가를 수행할 수 있어야 한다. (Service Account)
• IAM-NFR-059: 사용자 권한 상태를 조회할 수 있어야 한다. (Service Account)
• IAM-NFR-060: 시간당 최대 100,000 요청으로 제한되어야 한다. (Service Account, 예시 - 조정 필요)
• IAM-NFR-061: 자신의 권한 관련 작업만 수행할 수 있어야 한다. (Regular User)
• IAM-NFR-062: 자신의 권한 및 역할 정보를 조회할 수 있어야 한다. (Regular User)
• IAM-NFR-063: 시간당 최대 100 요청으로 제한되어야 한다. (Regular User, 예시 - 조정 필요)

3. 제약사항

3.1 데이터 제약사항

권한 데이터

• IAM-CR-001: 권한 이름은 시스템 내에서 고유해야 한다.
• IAM-CR-002: 권한 식별자는 생성 후 변경할 수 없다.
• IAM-CR-003: 권한 계층 구조는 최대 3단계까지만 지원한다. (선택 사항)

역할 데이터

• IAM-CR-004: 역할 이름은 시스템 내에서 고유해야 한다.
• IAM-CR-005: 역할 계층 구조 내에서 순환 참조는 허용되지 않는다.
• IAM-CR-006: 한 사용자 또는 그룹에 할당될 수 있는 역할의 최대 개수는 100개로 제한한다.

정책 데이터

• IAM-CR-007: 정책 조건식의 최대 길이는 4KB로 제한한다.
• IAM-CR-008: 정책 우선순위는 1부터 1000까지의 정수 값을 사용한다 (숫자가 낮을수록 우선순위 높음).
• IAM-CR-009: 하나의 정책에서 대상으로 지정할 수 있는 리소스의 최대 개수는 100개로 제한한다.

3.2 API 호출 제한

Service Account 제한사항

• IAM-CR-010: Rate Limit: 분당 1000 요청으로 제한한다.
• IAM-CR-011: 권한 검증 결과 캐시의 TTL은 5분으로 설정한다.
• IAM-CR-012: 최대 동시 요청 수는 100개로 제한한다.
• IAM-CR-013: 배치(Batch) 요청 시 한 번에 처리할 수 있는 최대 항목 수는 1000개로 제한한다.

Regular User 제한사항

• IAM-CR-014: Rate Limit: 분당 100 요청으로 제한한다.
• IAM-CR-015: 권한 검증 결과 캐시의 TTL은 15분으로 설정한다.
• IAM-CR-016: 최대 동시 요청 수는 10개로 제한한다.
• IAM-CR-017: 배치(Batch) 요청 시 한 번에 처리할 수 있는 최대 항목 수는 100개로 제한한다.

3.3 데이터 저장 제약

• IAM-CR-018: 권한(Permission), 역할(Role), 플랜(Plan) 등 IAM 리소스는 'iam' 스키마에 저장해야 한다.
• IAM-CR-019: 그룹(Group) 정보는 'group' 스키마에 저장해야 한다.
• IAM-CR-020: 고객(환자) 사용자 데이터는 'private' 스키마에 저장해야 한다.
• IAM-CR-021: 내부 운영자, 의료진 등 고객이 아닌 사용자 데이터는 'operation' 스키마에 저장해야 한다.
• IAM-CR-022: 사용자-그룹 관계는 스키마를 교차하여 관리되어야 한다:
  • 고객(환자) 사용자와 그룹의 관계는 'private' 스키마에서 관리한다.
  • 내부 운영자 사용자와 그룹의 관계는 'operation' 스키마에서 관리한다.
• IAM-CR-023: 민감 정보는 항상 암호화되어 저장되어야 한다.

4. 가정사항

4.1 시스템 환경

• IAM-AR-001: 시스템은 마이크로서비스 아키텍처 기반으로 구축된다.
• IAM-AR-002: 시스템은 클라우드 환경(예: GCP)에서 운영된다.

4.2 사용자 환경

• IAM-AR-003: 관리자는 별도의 관리 콘솔 또는 API를 통해 IAM 설정을 관리한다.
• IAM-AR-004: 일반 사용자는 자신의 권한 정보를 조회하거나 필요한 경우 권한 검증을 요청한다.
• IAM-AR-005: 서비스 계정은 다른 시스템과의 연동을 위해 API를 호출한다.

5. 의존성

5.1 내부 의존성

• IAM-DR-001: Auth 도메인: 사용자 인증 정보 확인, 토큰 검증 등.
• IAM-DR-002: User 도메인: 사용자 정보(ID, 서비스 이용 상태[Active/Suspended 포함], 그룹 등) 참조.
• IAM-DR-003: Plan 도메인: 플랜 정보 참조, 플랜-역할 매핑 관리, 플랜 기반 권한 제어.
• IAM-DR-004: Group 도메인: 그룹 정보 참조, 그룹-플랜 연결 정보 조회.
• IAM-DR-005: Audit 도메인: 권한 변경, 역할 할당, 정책 평가 등 주요 작업에 대한 감사 로그 기록.
• IAM-DR-006: Billing 도메인: 플랜 결제 상태 연동을 통한 권한 제어 (예: 결제 미납 시 서비스 제한).
• IAM-DR-007: Operation 도메인: 내부 운영자 사용자 관리 및 정보 참조.

5.2 외부 의존성

• IAM-DR-008: (필요시 명시: 예: 외부 IDP, LDAP 등)

6. GDPR 컴플라이언스 (개인정보 보호)

6.1 권한 관리와 개인정보 연계

백엔드 요구사항

• IAM-FR-BE-056: 시스템은 권한 관리와 개인정보 처리를 연계해야 한다.
  • 데이터 접근 권한과 처리 목적 매핑
  • 역할별 개인정보 접근 범위 제한
  • 권한 변경 시 데이터 주체 통지
  • 최소 권한 원칙 구현
• IAM-FR-BE-057: 시스템은 접근 로그를 개인정보로 관리해야 한다.
  • 접근 로그 보관 기간 정의 (1년)
  • 로그 데이터 익명화 정책
  • 감사 목적 외 사용 금지
  • 로그 암호화 저장

6.2 Service Account 개인정보 처리

백엔드 요구사항

• IAM-FR-BE-058: 시스템은 Service Account의 데이터 접근을 제한해야 한다.
  • 서비스별 필요 최소 데이터만 접근
  • API Key 암호화 저장
  • 접근 범위 명시적 정의
  • 정기적 권한 검토
• IAM-FR-BE-059: 시스템은 권한 변경 이력을 관리해야 한다.
  • 모든 권한 변경 감사 로그
  • 변경 사유 기록
  • 이력 보관 기간: 5년
  • 변경 영향 분석

6.3 데이터 주체 권리 지원

백엔드 요구사항

• IAM-FR-BE-070: 시스템은 권한 관련 데이터 주체 권리를 지원해야 한다.
  • 개인의 권한 정보 열람 API 제공
  • 권한 데이터 정정/수정 요청 처리
  • 권한 데이터 삭제 요청 처리 (단, 법적 의무 제외)
  • 권한 이력 데이터 이동권 지원
• IAM-FR-BE-071: 시스템은 권한 기반 개인정보 처리 제한을 구현해야 한다.
  • 동의 철회 시 관련 권한 자동 제한
  • 처리 제한 요청 시 권한 일시 정지
  • 반대권 행사 시 선택적 권한 비활성화
  • 제한 상태 모니터링 및 추적

6.4 특권 계정 관리

백엔드 요구사항

• IAM-FR-BE-072: 시스템은 특권 계정의 개인정보 접근을 강화 관리해야 한다.
  • 시스템 관리자 계정별 접근 데이터 추적
  • 특권 계정 사용 사유 기록 의무화
  • 임시 특권 부여 시간 제한 (최대 8시간)
  • 특권 사용 모든 활동 실시간 모니터링
• IAM-FR-BE-073: 시스템은 특권 계정 데이터 접근을 제한해야 한다.
  • 업무 필요 최소 범위로 접근 제한
  • 개인정보 대량 조회 시 별도 승인 필요
  • 특권 계정별 접근 가능 데이터 유형 명시
  • 정기적 특권 계정 권한 재검토 (월 1회)

6.5 개인정보 처리 기록

백엔드 요구사항

• IAM-FR-BE-074: 시스템은 권한 기반 개인정보 처리를 추적해야 한다.
  • 권한별 처리 가능 개인정보 범위 정의
  • 실제 데이터 접근 시 권한 검증 로그
  • 처리 목적과 권한의 정합성 검증
  • 권한 오남용 패턴 자동 탐지
• IAM-FR-BE-075: 시스템은 GDPR 준수를 위한 처리 기록을 생성해야 한다.
  • 처리 활동 기록(ROPA) 자동 생성
  • 법적 근거별 권한 분류 및 기록
  • 개인정보 처리 현황 대시보드
  • 감독기관 요청 시 즉시 제출 가능 형태

7. ISO27001 정보보호 관리

7.1 접근 통제 강화

백엔드 요구사항

• IAM-FR-BE-060: 시스템은 다단계 권한 검증을 구현해야 한다.
  • Group 기반 권한 검증
  • Plan 기반 권한 검증
  • 교집합 방식 최종 권한 결정
  • 권한 충돌 해결 메커니즘
• IAM-FR-BE-061: 시스템은 권한 에스컬레이션을 방지해야 한다.
  • 권한 상승 모니터링
  • 임시 권한 부여 추적
  • 비정상 권한 요청 탐지
  • 자동 권한 회수

7.2 정책 관리 보안

백엔드 요구사항

• IAM-FR-BE-062: 시스템은 정책 변경을 안전하게 관리해야 한다.
  • 정책 버전 관리
  • 변경 승인 워크플로우
  • 롤백 메커니즘
  • 정책 테스트 환경
• IAM-FR-BE-063: 시스템은 권한 관리 체계를 모니터링해야 한다.
  • 비사용 권한 탐지
  • 과도한 권한 부여 경고
  • 권한 사용 패턴 분석
  • 정기적 권한 검토 리포트

7.3 Service Account 보안 강화

백엔드 요구사항

• IAM-FR-BE-064: 시스템은 Service Account 라이프사이클을 관리해야 한다.
  • 자동 만료 정책
  • 주기적 키 로테이션
  • 비활성 계정 자동 비활성화
  • 계정 활동 모니터링
• IAM-FR-BE-065: 시스템은 Service Account 이상 행동을 탐지해야 한다.
  • 비정상 API 호출 패턴
  • 권한 남용 시도
  • 지리적 이상 접근
  • 자동 차단 메커니즘

7.4 MAO 티어/동의/라우팅 요구사항

백엔드 요구사항

• IAM-FR-BE-201: 정책 평가 입력에 tier(anonymous/guest/member), consent_version, allowed_domains, data_persistence를 필수로 포함하며, 누락 시 tier=anonymous, allowed_domains=[], data_persistence=none으로 평가한다.
• IAM-FR-BE-202: anonymous/guest는 FAQ/비저장 에이전트만 허용하고 민감 리소스는 Deny-overrides 규칙으로 차단한다(allowed_domains 기본값: anonymous=["faq","docs-public","agent-help-public"], guest=["faq","docs-public","agent-help-public","sleep-education"]).
• IAM-FR-BE-203: 에이전트/툴 메타데이터에 requiredTier/requiresConsent를 명시하고, 미충족 시 접근을 거부한다.
• IAM-FR-BE-204: guest→member 승격, consent_version 업데이트 시 정책 캐시를 무효화하고 재평가해야 한다.
• IAM-FR-BE-205: TTL/보존(guest 캐시 5분, member 15분)을 준수하며, anonymous/guest 토큰의 컨텍스트/저장은 금지 또는 단기(guest 3일)로 제한해야 한다.

변경 이력

버전	날짜	작성자	변경 내용
0.1.0	2025-04-17	bok@weltcorp.com	최초 문서 생성
0.2.0	2025-05-07	bok@weltcorp.com	사용자 유형 분리에 따른 스키마 저장 요구사항 추가
0.3.0	2025-06-13	bok@weltcorp.com	서비스 간 인증 요구사항 추가 (1.9절)
0.4.0	2025-06-13	bok@weltcorp.com	서비스 간 인증 방식 명확화: API Key + JWT 하이브리드 방식, Google Service Account 패턴과의 유사성 강조
0.5.0	2025-06-27	bok@weltcorp.com	Service Account 관리 요구사항 대폭 확장 및 체계화 (1.9절 전면 개편)
0.6.0	2025-06-27	bok@weltcorp.com	Plan 관련 요구사항을 별도 Plan 도메인으로 분리, Plan 도메인 의존성 추가 (1.5절 수정, 의존성 추가)
0.7.0	2025-06-27	bok@weltcorp.com	Group 관련 요구사항을 별도 Group 도메인으로 분리, Group 도메인 의존성 추가 (1.6절 수정, 1.5.1절 그룹 설명 수정)
0.8.0	2025-07-16	bok@weltcorp.com	다차원 권한 계산 모델로 변경 (1.5.1, 1.6, 1.7절 수정) - Group과 Plan 독립성 확보, 권한 교집합 계산
0.9.0	2025-08-07	bok@weltcorp.com	요구사항 ID 체계 적용 - IAM 도메인 코드 적용 (IAM-FR-BE-xxx, IAM-FR-FE-xxx, IAM-NFR-xxx, IAM-CR-xxx, IAM-AR-xxx, IAM-DR-xxx)
1.0.0	2025-08-12	bok@weltcorp.com	GDPR 및 ISO27001 컴플라이언스 요구사항 추가 (섹션 6, 7) - 권한 관리와 개인정보 연계, Service Account 보안 강화
1.1.0	2025-10-27	bok@weltcorp.com	게스트 전용 역할/정책 평가 요구사항 추가 (1.1, 1.4절)
1.2.0	2025-11-26	bok@weltcorp.com	MAO 라우팅을 위한 tier/consent/allowed_domains/data_persistence 기반 정책 평가 및 에이전트/툴 requiredTier 규칙 추가
1.3.0	2025-11-26	bok@weltcorp.com	allowed_domains 기본값, TTL/보존 수치, anonymous 강등 및 Deny-overrides 적용을 확정