Auth 도메인 요구사항

1. 기능 요구사항

1.1 앱 인증

백엔드 요구사항

• AUT-FR-BE-001: 시스템은 디바이스를 등록하고 식별할 수 있어야 한다.
• AUT-FR-BE-002: 시스템은 앱 토큰을 발급하고 관리할 수 있어야 한다.
• AUT-FR-BE-003: 시스템은 앱의 무결성을 검증할 수 있어야 한다.
• AUT-FR-BE-004: 시스템은 시간 기반 OTP 챌린지-응답 인증 메커니즘을 구현해야 한다.
  • 서버는 랜덤 챌린지 및 논스를 생성하고 응답을 검증할 수 있어야 한다.
  • 타임윈도우(10분 단위)를 기반으로 한 암호화 키 생성 메커니즘을 사용해야 한다.
  • 서버와 클라이언트는 서로 다른 방식으로 호환 가능한 암호화 키를 생성해야 한다.
  • 매 요청마다 고유한 논스를 사용하여 재사용 공격을 방지해야 한다.
• AUT-FR-BE-005: 시스템은 앱의 권한을 관리할 수 있어야 한다.
• AUT-FR-BE-006: (옵션) 시스템은 앱 시크릿을 이용한 디바이스 ID 솔트 추가 기능을 구현해야 한다.

프론트엔드 요구사항

• AUT-FR-FE-001: TBD

1.2 사용자 인증

백엔드 요구사항

• AUT-FR-BE-007: 시스템은 이메일과 비밀번호를 사용한 사용자 인증을 지원해야 한다.
• AUT-FR-BE-008: 시스템은 2단계 인증(2FA)을 제공해야 한다.
• AUT-FR-BE-009: 시스템은 사용자의 비밀번호 재설정 기능을 제공해야 한다.
• AUT-FR-BE-010: 시스템은 사용자가 입력한 이메일에 대해 5회 이상 패스워드를 잘못 입력했을 때, 1분 간 로그인을 시도할 수 없도록 해야 한다.
• AUT-FR-BE-011: 시스템은 사용자가 GesundheitsID를 이용해 대체 로그인을 설정할 수 있어야 한다.
• AUT-FR-BE-012: 시스템은 비밀번호에 공백 문자(스페이스)와 HTML/SQL 인젝션 관련 문자(<, >, ", ', \\)를 사용할 수 없도록 해야 한다.
• AUT-FR-BE-013: 시스템은 PIN 코드를 서버에 저장하지 않는 모바일 로컬 인증 방식을 지원해야 한다.
• AUT-FR-BE-014: 시스템은 클라이언트에서 전송된 해시 처리된 비밀번호를 안전하게 처리하고, 추가적인 서버 측 암호화를 적용하여 저장해야 한다.
• AUT-FR-BE-015: 시스템은 해시 처리된 비밀번호를 전송받고 처리할 수 있는 API를 제공해야 한다.
• AUT-FR-BE-016: 시스템은 회원가입과 비밀번호 재설정을 위한 별도의 이메일 인증 코드 발송 API를 제공해야 한다.
  • 회원가입 이메일 인증 코드 발송 시 이미 가입된 이메일일 경우 적절한 오류를 반환해야 한다.
  • 비밀번호 재설정 이메일 인증 코드 발송 시 가입되지 않은 이메일일 경우 적절한 오류를 반환해야 한다.
  • 회원가입과 비밀번호 재설정 모두 동일한 재발송 제한 규칙을 적용해야 한다.
• AUT-FR-BE-017: 시스템은 사용자 유형에 따라 데이터를 다른 스키마에 저장해야 한다:
  • 고객(환자) 사용자 데이터는 'private' 스키마에 저장해야 한다.
  • 내부 운영자, 의료진 등 고객이 아닌 사용자 데이터는 'operation' 스키마에 저장해야 한다.
  • 사용자 유형에 관계없이 인증 서비스는 통합적으로 제공해야 한다.
• AUT-FR-BE-073: 시스템은 이메일/소셜 로그인 없이 약관 동의만으로 게스트 사용자 계정을 생성할 수 있어야 한다.
  • 게스트 온보딩은 App Token 검증과 디바이스 무결성 검사를 기존 회원 가입과 동일하게 수행해야 한다.
  • 게스트 계정은 내부에서 발급하는 가명 식별자(예: guestAccountId)와 동의 이력만을 영구 데이터로 저장해야 한다.
  • 게스트 온보딩 시 수집하지 않는 개인정보(이메일, OAuth subject 등)는 추후 신원 연동 전까지 저장하거나 요구해서는 안 된다.
• AUT-FR-BE-074: 시스템은 게스트 계정을 정규 사용자로 전환하기 위한 Step-up 인증 플로우를 제공해야 한다.
  • 게스트가 이메일 또는 카카오 로그인을 연동할 때, 기존 게스트 식별자와 새로운 자격증명을 안전하게 연결해야 한다.
  • 연동 성공 시 기존 게스트 토큰은 모두 무효화하고, 신규 신원 수준에 맞는 토큰을 재발급해야 한다.
  • 신원 연동 과정에서 동의 항목을 재수집하고, User 도메인에 전환 이벤트를 발행해야 한다.

App Token 필수화: 이메일·OAuth 여부와 상관없이 신규 사용자 등록 및 온보딩 엔드포인트는 AppTokenGuard를 통해 검증된 appToken을 요구해야 하며, 클라이언트는 Kakao 등 소셜 로그인 전 앱 인증 챌린지를 반드시 수행해야 합니다.

프론트엔드 요구사항

• AUT-FR-FE-002: TBD

1.3 토큰 관리

백엔드 요구사항

• AUT-FR-BE-018: 시스템은 JWT 토큰 기반 인증을 구현해야 한다.
• AUT-FR-BE-019: 시스템은 만료된 토큰의 갱신 메커니즘을 제공해야 한다.
• AUT-FR-BE-020: 시스템은 토큰 발급 정책을 통해 사용자의 디바이스별 접근을 제어할 수 있어야 한다.
• AUT-FR-BE-021: 시스템은 사용자별 마지막 로그인 디바이스 정보를 기록하고, 토큰 발급 이력을 관리해야 한다.
• AUT-FR-BE-022: 시스템은 단일 사용자에 대해 멀티 디바이스 동시 접속을 허용하지 않아야 한다(한 계정은 한 번에 하나의 디바이스에서만 로그인 가능).
• AUT-FR-BE-023: 시스템은 새로운 디바이스에서 로그인 시 이전 디바이스의 토큰을 무효화해야 한다.
• AUT-FR-BE-024: 시스템은 액세스 토큰 유효 기간을 30분(단, DEV 환경에서는 5분)으로 설정해야 한다.
• AUT-FR-BE-025: 시스템은 사용자의 동의(Consent) 정보를 Access Token 내에 포함시켜야 한다.
• AUT-FR-BE-026: 시스템은 Access Token의 Consent 정보를 기반으로 권한 검증을 수행해야 한다.
• AUT-FR-BE-075: 시스템은 Access Token에 신원 수준(identityLevel)을 포함시켜 게스트와 정규 사용자를 구분해야 한다.
  • 최소 수준은 guest이며, 이메일/소셜 연동 후 registered로 승격되어야 한다.
  • 신원 수준은 IAM 도메인에서 권한 평가 시 필수 입력값으로 사용되어야 한다.
• AUT-FR-BE-076: 시스템은 게스트 토큰에 대해 강화된 제약을 적용해야 한다.
  • 게스트 토큰의 유효 기간은 최대 15분으로 제한하고, 리프레시 토큰 수명도 12시간을 초과할 수 없다.
  • 게스트 토큰은 최초 등록된 디바이스에서만 사용할 수 있도록 디바이스 바인딩을 적용해야 한다.
  • 게스트 토큰으로 호출 가능한 리소스는 IAM/Plan 도메인에서 정의한 제한된 권한 범위에 한정되어야 한다.
• AUT-FR-BE-027: 시스템은 디바이스별 토큰 발급 이력을 추적해야 한다.
• AUT-FR-BE-028: 시스템은 사용자당 하나의 활성 토큰만 유효하도록 보장해야 한다.
• AUT-FR-BE-029: 시스템은 Access Token 갱신, 로그인, 로그아웃 요청 시, 기존 Access Token을 :staging 상태로 전환하여 관리해야 한다.
  • :staging 상태의 Access Token은 Redis 등의 캐시 저장소에 set 형태로 저장하며, TTL(Time-to-Live)을 5분으로 설정해야 한다.
  • 이 메커니즘은 연달은 토큰 갱신 요청 시 발생할 수 있는 race condition 문제를 해결하고, 이전 토큰을 사용하는 요청도 일정 시간 동안 처리할 수 있도록 한다.
• AUT-FR-BE-030: 시스템은 Access Token의 유효 기간이 1분 이내로 남은 요청에 대해 401 Unauthorized 응답을 반환하여 클라이언트가 토큰 갱신을 유도하도록 해야 한다.
• AUT-FR-BE-031: 시스템은 Access Token 검증 시, 현재 Access Token이 :staging 키에 포함되어 있는 경우에도 유효한 요청으로 처리해야 한다.

프론트엔드 요구사항

• AUT-FR-FE-003: TBD

1.4 보안

백엔드 요구사항

• AUT-FR-BE-027: 시스템은 사용자 비밀번호를 암호화하여 저장해야 한다.
• AUT-FR-BE-028: 시스템은 토큰에 민감한 개인정보를 포함해서는 안 되며, 토큰의 무결성을 보장하기 위해 적절한 서명 알고리즘을 사용해야 한다.
• AUT-FR-BE-029: 시스템은 API에 대한 접근을 제어해야 한다.
• AUT-FR-BE-030: 시스템은 이메일 인증 코드를 발송하고 검증할 수 있어야 한다.
• AUT-FR-BE-031: 시스템은 이메일 인증 코드의 유효 시간을 5분으로 관리해야 한다.
• AUT-FR-BE-032: 시스템은 이메일 인증 코드 발송 API에 대해 Rate Limiting을 적용하여 서비스 거부 공격(DoS)을 방지하고 시스템 가용성을 보장해야 한다.
  • 동일 이메일 주소에 대해 10분 내 요청 횟수를 5회로 제한해야 한다.
  • 동일 IP 주소에 대해 1분 내 요청 횟수를 60회로 제한하여 자동화된 공격을 방지해야 한다.
  • 제한 초과 시 429 Too Many Requests 응답과 함께 일정 시간 동안 요청을 차단해야 한다.
• AUT-FR-BE-033: 시스템은 이메일 인증 코드 검증 시도에 대한 제한을 적용해야 한다.
  • 동일 이메일 및 requestId에 대해 최대 10회까지만 인증 시도를 허용해야 한다.
  • 10회 실패 시 해당 인증 코드는 무효화되고, 이메일 주소는 1시간 동안 잠금 상태가 되어야 한다.
  • 검증 시도 제한 초과 시에도 HTTP 200 응답과 함께 실패 상태와 잠금 시간을 전달해야 한다.
  • 오류 응답은 상황에 따라 다음 중 하나의 메타데이터만 포함해야 한다:
    • 잘못된 코드 입력 시: 남은 시도 횟수(remainingAttempts)
    • 시도 횟수 초과 시: 잠금 해제까지 남은 시간(remainingLockoutSeconds)
    • 만료된 코드: 빈 메타데이터
• AUT-FR-BE-034: 시스템은 이메일 인증 코드 발송 시 사용자의 언어 선호도에 따라 적절한 언어로 이메일을 발송해야 한다.
  • API 요청 시 Accept-Language 헤더를 분석하여 사용자 언어 선호도를 결정해야 한다.
  • 기본 언어는 독일어(de)로 설정하고, 영어(en)와 한국어(ko) 등 다국어를 지원해야 한다.
  • 지원하지 않는 언어 코드가 요청된 경우 기본 언어인 독일어로 발송해야 한다.
• AUT-FR-BE-035: 시스템은 회원가입과 비밀번호 재설정에 대해 각각 다른 이메일 인증 코드 발송 API를 제공해야 한다.

프론트엔드 요구사항

• AUT-FR-FE-004: TBD

1.5 회원 가입 프로세스

백엔드 요구사항

• AUT-FR-BE-036: 시스템은 회원 가입 시 사용자의 Access Code 유효성을 검증해야 하며, 이 인증이 정상적으로 완료되어야만 가입을 진행할 수 있다.
• AUT-FR-BE-037: 시스템은 동일한 디바이스 ID에 대해 Access Code 검증 시도를 시간당 최대 10회까지만 허용해야 한다. 10회 실패 시 해당 디바이스 ID는 1시간 동안 Access Code 검증 시도가 제한되어야 한다.
• AUT-FR-BE-038: 시스템은 사용자가 회원가입을 시도할 때 반드시 이메일 인증 과정을 거치도록 해야 한다.
• AUT-FR-BE-039: 시스템은 사용자가 입력한 이메일 주소로 인증 코드를 발송해야 한다.
• AUT-FR-BE-040: 시스템은 이메일 인증 코드 재발송 기능을 제공해야 한다.
• AUT-FR-BE-041: 시스템은 이메일 인증 코드 재발송에 대한 지수 백오프(Exponential Backoff) 제한을 적용해야 한다.
  • 동일 이메일 주소에 대한 재발송 대기시간은 점진적으로 증가해야 한다:
    • 1차 재발송: 10초 후
    • 2차 재발송: 30초 후
    • 3차 재발송: 90초 후
    • 4차 재발송: 300초(5분) 후
    • 5차 재발송: 900초(15분) 후
    • 6차 재발송: 1800초(30분) 후
    • 이후 재발송: 최대 86400초(24시간) 간격까지 점진적 증가
  • 재발송 횟수는 전체 발송 제한 횟수(10분 내 5회)에 포함되어야 한다.
  • 24시간 후에는 재발송 대기시간이 초기값(10초)으로 리셋되어야 한다.
• AUT-FR-BE-042: 시스템은 이메일 인증이 완료된 후에만 회원가입 절차를 계속 진행할 수 있도록 해야 한다.
• AUT-FR-BE-043: 시스템은 회원 가입 완료 단계에서 사용자로부터 다음 두 가지 동의 항목을 수신하고 처리해야 한다:
  • termsOfServiceDiGAV (boolean, 필수)
  • dataProcessingForImprovement (boolean, 선택)
• AUT-FR-BE-044: 시스템은 필수 동의(termsOfServiceDiGAV)가 true가 아닌 경우 회원 가입을 거부해야 한다.
• AUT-FR-BE-045: 시스템은 수집된 동의 상태를 Consent 도메인에 기록해야 한다.

프론트엔드 요구사항

• AUT-FR-FE-005: TBD

1.6 OAuth 인증

백엔드 요구사항

• AUT-FR-BE-046: 시스템은 GesundheitsID를 유일한 OAuth 제공자로 지원해야 한다.
• AUT-FR-BE-047: 시스템은 GesundheitsID 계정 연동 및 해제 기능을 제공해야 한다.
• AUT-FR-BE-048: 시스템은 GesundheitsID 토큰을 안전하게 저장하고 관리해야 한다.
• AUT-FR-BE-049: 시스템은 GesundheitsID 인증 상태를 확인하고 검증할 수 있어야 한다.
• AUT-FR-BE-050: 시스템은 GesundheitsID 설정을 유연하게 관리할 수 있어야 한다.

프론트엔드 요구사항

• AUT-FR-FE-006: TBD

2. 비기능 요구사항

2.1 성능

• AUT-NFR-001: 시스템은 로그인 요청에 대해 1초 이내의 응답 시간을 제공해야 한다.
• AUT-NFR-002: 시스템은 토큰 검증에 대해 100ms 이내의 응답 시간을 제공해야 한다.
• AUT-NFR-003: 시스템은 앱 토큰 발급에 대해 300ms 이내의 응답 시간을 제공해야 한다.
• AUT-NFR-004: 시스템은 앱 무결성 검증에 대해 500ms 이내의 응답 시간을 제공해야 한다.
• AUT-NFR-005: 시스템은 챌린지 생성 및 검증에 대해 200ms 이내의 응답 시간을 제공해야 한다.
• AUT-NFR-006: 시스템은 10,000명 이상의 동시 접속자를 처리할 수 있어야 한다.
• AUT-NFR-007: 시스템은 이메일 인증 코드 발송을 5초 이내에 완료해야 한다.

2.2 보안

• AUT-NFR-008: 시스템은 OWASP Top 10 보안 취약점에 대응해야 한다.
• AUT-NFR-009: (공통 정책 참조) 전송 중 암호화는 Platform 표준을 따른다 - PLT-SEC-002
• AUT-NFR-010: (공통 정책 참조) 민감 정보 암호화는 Platform 표준을 따른다 - PLT-SEC-001, PLT-SEC-003
• AUT-NFR-011: 시스템은 모든 접근에 대한 로그를 기록해야 한다.
• AUT-NFR-012: 시스템은 앱 무결성 검증 정책을 적용해야 한다.
• AUT-NFR-013: 시스템은 디바이스 블랙리스트를 관리해야 한다.
• AUT-NFR-014: 시스템은 시간 기반 챌린지-응답 보안 메커니즘을 구현해야 한다.
• AUT-NFR-015: 시스템은 Rate Limiting을 구현해야 한다.
• AUT-NFR-016: 시스템은 IP 기반 접근 제어를 구현해야 한다.
• AUT-NFR-017: 시스템은 디바이스 ID에 SHA-256 해싱을 적용해야 한다.
• AUT-NFR-018: 시스템은 앱 시크릿을 통한 솔트를 적용해야 한다.
• AUT-NFR-019: 시스템은 보안 위반 감지 시 자동으로 계정을 잠가야 한다.

2.3 확장성

• (공통 정책 참조) 수평 확장/로드 밸런싱/마이크로서비스 아키텍처는 Platform 도메인 기준을 따른다: PLT-NFR-001, PLT-NFR-002, PLT-NFR-003
• AUT-NFR-021: 시스템은 다중 인증 제공자를 지원해야 한다.
• AUT-NFR-022: 시스템은 커스텀 인증 로직을 추가할 수 있는 구조를 가져야 한다.

2.4 가용성

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

2.5 사용자 유형별 권한 관리

• AUT-NFR-029: System Admin 권한

  • System Admin은 인증 시스템 전체 설정을 관리할 수 있어야 한다.
  • System Admin은 모든 사용자의 인증 상태를 관리할 수 있어야 한다.
  • System Admin은 2단계 인증 정책을 관리할 수 있어야 한다.
  • System Admin은 API 호출 제한 없이 사용할 수 있어야 한다.

• AUT-NFR-030: IAM Admin 권한

  • IAM Admin은 할당된 범위 내 사용자의 인증 상태를 관리할 수 있어야 한다.
  • IAM Admin은 2단계 인증 상태를 조회할 수 있어야 한다.
  • IAM Admin은 시간당 최대 10,000 요청으로 제한되어야 한다.

• AUT-NFR-031: Service Account 권한

  • Service Account는 토큰 검증을 수행할 수 있어야 한다.
  • Service Account는 세션 검증을 수행할 수 있어야 한다.
  • Service Account는 사용자 인증 상태를 조회할 수 있어야 한다.
  • Service Account는 시간당 최대 100,000 요청으로 제한되어야 한다.

• AUT-NFR-032: Regular User 권한

  • Regular User는 자신의 인증 관련 작업만 수행할 수 있어야 한다.
  • Regular User는 자신의 2단계 인증을 관리할 수 있어야 한다.
  • Regular User는 시간당 최대 100 요청으로 제한되어야 한다.

3. 제약사항

3.1 기술적 제약

• AUT-CR-001: 시스템은 NestJS 프레임워크를 사용하여 구현되어야 한다.
• AUT-CR-002: 시스템은 TypeScript 기반으로 개발되어야 한다.
• AUT-CR-003: 시스템은 PostgreSQL 데이터베이스를 사용해야 한다.

3.2 보안 제약

• AUT-CR-004: 시스템은 GDPR을 준수해야 한다.
• AUT-CR-005: 시스템은 HIPAA를 준수해야 한다 (해당하는 경우).
• AUT-CR-006: 시스템은 PCI DSS를 준수해야 한다 (해당하는 경우).
• AUT-CR-007: 시스템은 모바일 앱 OWASP MASVS(Mobile Application Security Verification Standard)를 준수해야 한다.
• AUT-CR-008: 디바이스 ID 정보는 해싱 후 저장 및 관리되어야 한다.
• AUT-CR-009: 챌린지-응답은 5분 이내 일회성으로 사용되어야 한다.
• AUT-CR-010: 이메일 인증 코드는 30분 이내 유효해야 한다.

3.3 운영 제약

• AUT-CR-011: 시스템은 무중단 배포를 지원해야 한다.
• AUT-CR-012: 시스템은 로그를 1년간 보관해야 한다.
• AUT-CR-013: 시스템은 감사 로그를 5년간 보관해야 한다.

3.4 시간 처리 제약

• AUT-CR-014: 시스템은 TimeMachine 서비스를 사용해야 한다.
• AUT-CR-015: 시스템은 시스템 시간을 직접 사용해서는 안 된다.
• AUT-CR-016: 시스템은 타임존 처리를 해야 한다.

3.5 데이터 저장 제약

• AUT-CR-017: 시스템은 변경 이력을 추적해야 한다.
• AUT-CR-018: 시스템은 WORM(Write Once Read Many) 저장 방식을 사용해야 한다.
• AUT-CR-019: 환자(고객) 사용자의 모든 데이터는 'private' 스키마에 저장되어야 한다.
• AUT-CR-020: 내부 운영자, 의료진 등 고객이 아닌 사용자의 데이터는 'operation' 스키마에 저장되어야 한다.
• AUT-CR-021: 사용자 유형에 상관없이 인증 도메인에서 관리하는 공통 데이터(JWK 등)는 'auth' 스키마에 저장되어야 한다.
• AUT-CR-022: 민감 정보는 항상 암호화되어 저장되어야 한다.

4. 가정사항

4.1 시스템 환경

• AUT-AR-001: 시스템은 클라우드 기반으로 운영될 것이다.
• AUT-AR-002: 시스템은 컨테이너화된 배포 방식을 사용할 것이다.
• AUT-AR-003: 시스템은 마이크로서비스 아키텍처를 따를 것이다.

4.2 사용자 환경

• AUT-AR-004: 사용자는 모던 웹 브라우저를 사용할 것이다.
• 사용자는 모바일 디바이스를 지원할 것이다.
• 사용자는 국제화/지역화가 필요할 것이다.
• 모바일 앱은 네이티브 보안 기능에 접근할 수 있을 것이다.
• 앱은 디바이스 식별 정보를 수집할 수 있을 것이다.
• 앱은 안전한 저장소에 민감 정보를 보관할 수 있을 것이다.

5. 의존성

5.1 내부 의존성

• AUT-DR-001: 시스템은 User 도메인에 의존할 것이다.
• AUT-DR-002: 시스템은 IAM 도메인에 의존할 것이다.
• AUT-DR-003: 시스템은 Audit 도메인에 의존할 것이다.
• AUT-DR-004: 시스템은 Access Code 도메인에 의존할 것이다.
• AUT-DR-005: 시스템은 Terms 도메인에 의존할 것이다.
• AUT-DR-006: 시스템은 Consent 도메인에 의존할 것이다.

5.2 외부 의존성

• AUT-DR-007: 시스템은 GesundheitsID OAuth 제공자에 의존할 것이다.
• AUT-DR-008: 시스템은 SMS/이메일 서비스에 의존할 것이다.
• AUT-DR-009: 시스템은 보안 인증 서비스에 의존할 것이다.
• AUT-DR-010: 시스템은 암호화 라이브러리(SHA-256, AES-256-CBC)에 의존할 것이다.
• AUT-DR-011: 시스템은 타임 서비스(챌린지-응답 메커니즘용)에 의존할 것이다.

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

6.1 인증 데이터 처리

백엔드 요구사항

• AUT-FR-BE-056: 시스템은 인증 로그의 보관 기간을 정의하고 관리해야 한다.
  • 인증 로그: 1년 보관 후 자동 삭제
  • 감사 로그: 5년 보관 (법적 요구사항)
  • 실패 시도 로그: 90일 후 익명화
• AUT-FR-BE-057: 시스템은 개인정보 최소화 원칙을 적용해야 한다.
  • 인증에 필요한 최소한의 정보만 처리
  • 불필요한 개인정보 수집 금지
  • 디바이스 정보는 해시 처리 후 저장
• AUT-FR-BE-058: 시스템은 동의 기반 처리를 구현해야 한다.
  • 선택적 2FA 활성화 시 명시적 동의
  • 디바이스 정보 수집 동의 확인
  • 마케팅 목적 로그 활용 시 별도 동의

6.2 데이터 주체 권리 보장

백엔드 요구사항

• AUT-FR-BE-059: 시스템은 인증 관련 개인정보 열람권을 보장해야 한다.
  • 로그인 이력 조회 API
  • 등록된 디바이스 목록 조회 API
  • 2FA 설정 정보 조회 API
• AUT-FR-BE-060: 시스템은 인증 데이터 삭제권을 보장해야 한다.
  • 로그인 이력 삭제 요청 처리
  • 특정 디바이스 등록 해제
  • 계정 완전 삭제 시 모든 인증 데이터 제거
• AUT-FR-BE-061: 시스템은 인증 데이터 이동권을 보장해야 한다.
  • 인증 이력 내보내기 (JSON/CSV 형식)
  • 디바이스 등록 정보 내보내기
  • 보안 설정 내역 내보내기

7. ISO27001 정보보호 관리

7.1 접근 통제 강화

백엔드 요구사항

• AUT-FR-BE-062: 시스템은 강화된 인증 메커니즘을 구현해야 한다.
  • 다단계 인증(MFA) 필수 적용 (관리자 계정)
  • 위험 기반 인증 (비정상 접근 패턴 탐지)
  • 적응형 인증 (컨텍스트 기반 보안 수준 조정)
• AUT-FR-BE-063: 시스템은 세션 보안을 강화해야 한다.
  • 동시 세션 수 제한 (사용자당 최대 5개)
  • 유휴 세션 자동 종료 (30분)
  • 세션 하이재킹 방지 메커니즘
• AUT-FR-BE-064: 시스템은 비밀번호 정책을 강화해야 한다.
  • 복잡도 요구사항 (대소문자, 숫자, 특수문자 조합)
  • 이전 비밀번호 재사용 금지 (최근 5개)
  • 정기적 비밀번호 변경 권고 (90일)

7.2 로깅 및 모니터링

백엔드 요구사항

• AUT-FR-BE-065: 시스템은 상세한 인증 감사 로그를 생성해야 한다.
  • 모든 인증 시도 기록 (성공/실패)
  • IP 주소, 디바이스 정보, 시간 기록
  • 권한 상승 활동 추적
• AUT-FR-BE-066: 시스템은 보안 이벤트 모니터링을 구현해야 한다.
  • 무차별 대입 공격 탐지
  • 비정상 로그인 패턴 탐지
  • 계정 탈취 시도 탐지
• AUT-FR-BE-067: 시스템은 실시간 알림을 제공해야 한다.
  • 의심스러운 활동 즉시 알림
  • 새로운 디바이스 로그인 알림
  • 비밀번호 변경 알림

7.3 암호화 및 키 관리

백엔드 요구사항

• AUT-FR-BE-068: 시스템은 토큰 보안을 강화해야 한다.
  • JWT 서명 알고리즘: RS256 또는 ES256
  • 토큰 암호화: JWE (JSON Web Encryption) 적용
  • 토큰 수명 최소화 (액세스: 15분, 리프레시: 7일)
• AUT-FR-BE-069: (공통 정책 참조) 키 관리는 Platform 도메인 표준을 따른다:
  • PLT-SEC-004 참조
  • Google Cloud KMS 활용
  • JWK 로테이션 정책 (월 1회)
• AUT-FR-BE-070: (공통 정책 참조) 전송 구간 보안은 Platform 도메인 표준을 따른다:
  • PLT-SEC-002 참조
  • TLS 1.2 이상 필수
  • 인증서 피닝 (모바일 앱)

7.4 보안 사고 대응

백엔드 요구사항

• AUT-FR-BE-071: 시스템은 계정 침해 대응 체계를 구축해야 한다.
  • 자동 계정 잠금 (5회 실패 시)
  • 임시 비밀번호 강제 재설정
  • 모든 세션 강제 종료 기능
• AUT-FR-BE-072: 시스템은 보안 사고 추적을 지원해야 한다.
  • 사고 타임라인 재구성 기능
  • 영향받은 계정 식별
  • 포렌식 분석용 데이터 보존

7.5 티어/동의/라우팅 연계

백엔드 요구사항

• AUT-FR-BE-118: 시스템은 tier(anonymous/guest/member), consent_version, allowed_domains, data_persistence 클레임을 포함해 토큰을 발급·검증해야 한다. 누락 시 tier=anonymous, allowed_domains=[], data_persistence=none으로 강등 평가한다.
• AUT-FR-BE-119: anonymous/guest 토큰 발급 시 개인화 컨텍스트를 비활성화하고 비저장·FAQ 전용 스코프로 제한한다(allowed_domains 기본값: anonymous=["faq","docs-public","agent-help-public"], guest=["faq","docs-public","agent-help-public","sleep-education"]).
• AUT-FR-BE-120: guest→member 승격 시 기존 토큰을 폐기(블랙리스트)하고 동의 버전/허용 도메인/데이터 보존 정책을 재평가한 신규 토큰을 발급한다.
• AUT-FR-BE-121: consent_version 불일치 시 401 또는 재동의 요구 에러를 반환하며 관용 기간을 두지 않는다.
• AUT-FR-BE-122: 서비스 호출 시 tier 미제공은 anonymous로 처리하고, 컨텍스트 제공자는 NOT_READY로 폴백한다.
• AUT-FR-BE-123: TTL/보존 정책을 준수해야 한다: Access token(anonymous/guest 15분, member 30분), Refresh token(member 7일, anonymous/guest 없음), 컨텍스트/대화 저장(anonymous 없음, guest 3일 권장, member 규제 준수 예: 90일), 그룹 멤버십(anonymous 1일, guest 7일, member 영속).
• AUT-FR-BE-124: 익명(anonymous) 액세스 토큰 발급은 유효한 appToken 인증이 있는 경우에만 허용하며, 토큰 클레임은 최소한 tier=anonymous, allowed_domains=["faq","docs-public","agent-help-public"], data_persistence=none를 포함한다. 토큰이 없을 때는 익명 토큰 발급 엔드포인트를 선행 호출해 받은 토큰을 이후 요청의 Authorization: Bearer <token>으로 사용해야 한다.

변경 이력

버전	날짜	작성자	변경 내용
0.1.0	2025-03-25	bok@weltcorp.com	최초 작성
0.2.0	2025-04-15	bok@weltcorp.com	TokenPayload에 consents 필드 추가, ConsentToken 제거 및 Access Token으로 통합 반영
0.3.0	2025-04-17	bok@weltcorp.com	회원 가입 시 수집하는 구체적인 동의 항목(DiGAV, 데이터 처리 개선) 요구사항 반영 (1.5, 1.6, 1.8절 수정)
0.4.0	2025-04-29	bok@weltcorp.com	약관(1.5) 및 동의(1.8) 관리 요구사항, 관련 권한(2.5) 및 제약(3.5)을 별도 도메인 문서로 분리하고 내부 의존성(5.1) 추가
0.5.0	2025-05-03	bok@weltcorp.com	회원가입과 비밀번호 재설정을 위한 별도의 이메일 인증 코드 발송 API 요구사항 추가 (1.2, 1.4절 수정)
0.6.0	2025-05-07	bok@weltcorp.com	사용자 유형 분리에 따른 스키마 저장 요구사항 추가: 환자는 'private' 스키마, 내부 운영자 등은 'operation' 스키마 (1.2, 3.5절 수정)
0.7.0	2025-08-06	bok@weltcorp.com	이메일 인증 코드 재발송 제한 요구사항 추가: Exponential Backoff 패턴, 전체 발송 제한 연동 (1.2, 1.5절 수정)
0.8.0	2025-08-07	bok@weltcorp.com	요구사항 ID 체계 적용 - AUT 도메인 코드 적용 (AUT-FR-BE/FE-xxx, AUT-NFR-xxx, AUT-CR-xxx, AUT-AR-xxx, AUT-DR-xxx)
0.9.0	2025-08-11	bok@weltcorp.com	JWT stateless 인증 방식에 맞게 요구사항 수정: 세션 관리 → 토큰 관리, 멀티 디바이스 제어 방식 변경, JWT 토큰 블랙리스트 관리 요구사항을 1.3 토큰 관리 섹션에 추가 (AUT-FR-BE-051~055)
0.10.0	2025-01-21	bok@weltcorp.com	GDPR 및 ISO27001 컴플라이언스 요구사항 추가 (섹션 6, 7) - 인증 데이터 처리, 데이터 주체 권리, 접근 통제 강화, 보안 사고 대응
0.11.0	2025-10-27	bok@weltcorp.com	게스트 온보딩/Step-up 인증 및 identityLevel 토큰 정책 요구사항 추가 (1.2, 1.3절)
0.12.0	2025-11-26	bok@weltcorp.com	MAO 라우팅을 위한 tier/consent/allowed_domains/data_persistence 토큰 요구사항 및 anonymous/guest 제약, 재동의 처리 규칙 추가
0.13.0	2025-11-26	bok@weltcorp.com	allowed_domains 기본값, TTL/보존 수치, consent 불일치 즉시 거부, anonymous 강등 기본값을 확정 반영
0.14.0	2025-11-26	bok@weltcorp.com	익명 토큰 발급을 appToken 기반으로 제한하고 클레임 기본값을 명시(AUT-FR-BE-124)
0.15.0	2025-12-18	bok@weltcorp.com	게스트 로그인 응답에서 agreementsStatus 필드 제거 (AUT-FR-BE-077 요구사항 삭제)