[OpenSearch] FGAC(Fine-Grained Access Control)와 JWT 활용

JWT와 FGAC를 사용하는 이유

대규모 데이터를 다루는 애플리케이션에서, 사용자의 데이터 접근 권한을 세밀하게 제어하는 것은 매우 중요합니다. 특히, 민감한 정보가 포함된 데이터베이스나 검색 엔진(OpenSearch)을 사용할 때는 사용자의 역할(Role), 요청 범위, 그리고 데이터 단위(예: 특정 필드)에 따라 접근 권한을 설정해야 보안 사고를 예방할 수 있습니다.

JWT(JSON Web Token)와 FGAC(Fine-Grained Access Control)는 이러한 요구 사항을 충족하는 데 적합한 도구입니다. JWT는 사용자 인증과 권한 정보를 효율적으로 전달하며, FGAC는 이를 기반으로 데이터 접근을 세밀하게 제어합니다.

---

JWT와 FGAC: 무엇이고 어떻게 조합할까?

FGAC(Fine-Grained Access Control)

FGAC는 클러스터, 인덱스, 문서, 필드 등 데이터 단위별로 세부적인 접근 정책을 설정하는 기능입니다. FGAC의 주요 요소는 다음과 같습니다:

• Role: 사용자 역할에 따라 클러스터, 인덱스, 문서, 필드 수준의 접근 권한 설정
• User: JWT를 통해 인증된 사용자를 특정 역할에 매핑
• Mapping: 사용자를 특정 역할에 연결하여, 해당 사용자의 접근 범위 설정

예를 들어, viewer 역할의 사용자에게는 읽기 권한만 부여하고, 특정 필드(password, ssn)에 대한 접근은 제한할 수 있습니다.

JWT와 FGAC 조합 시나리오

1. 인증 서버(AWS Cognito, Auth0 등)에서 사용자 정보를 기반으로 JWT 발급
   • 클레임에 사용자 정보와 권한 정보 포함
2. 클라이언트가 OpenSearch로 JWT와 함께 요청 전송
3. OpenSearch가 JWT의 서명을 검증하고 FGAC 정책에 따라 역할(Role) 확인
4. FGAC가 역할(Role)과 테넌트 정보에 따라 접근 가능한 데이터와 필드를 필터링

---

사용 사례

1. 금융 애플리케이션
   • 예시: 금융 기관에서 고객의 거래 내역을 관리하는 시스템이 있다고 가정합니다.
     • 사용자가 로그인하면 JWT가 발급되며, 여기에는 사용자 정보(예: 고객 ID)와 권한(예: 계좌 조회 가능 여부)이 포함됩니다.
     • 관리자는 고객 서비스 담당자가 특정 고객의 민감한 정보(예: 계좌 비밀번호, 카드 번호)를 조회하지 못하도록 필드 수준의 접근 제어를 설정할 수 있습니다.
2. 의료 데이터 관리
   • 예시: 병원이 환자의 의료 기록을 저장하고 조회할 수 있는 시스템을 운영합니다.
     • 환자가 시스템에 로그인하거나 의사가 인증을 받으면 JWT가 발급됩니다. JWT에는 사용자 역할(환자, 의사, 관리자)과 권한 정보가 포함됩니다.
     • 의사는 자신의 환자 데이터에만 접근할 수 있고, 특정 필드(예: 환자 주소, 주민등록번호)는 접근이 제한됩니다.
3. 멀티테넌트 SaaS 애플리케이션
   • 예시: 여러 조직(테넌트)이 하나의 OpenSearch 클러스터를 공유하는 SaaS 플랫폼.
     • 각 조직의 사용자가 로그인하면, 해당 조직의 테넌트 ID와 사용자 역할을 포함한 JWT가 발급됩니다.
     • 특정 테넌트의 데이터에만 접근 가능하도록 설정하고, 필드 수준에서 민감한 정보는 숨깁니다.

---

JWT와 FGAC의 필요성

이러한 환경에서 JWT와 FGAC는 다음과 같은 이유로 필수적입니다:

1. 사용자 권한 관리: 각 사용자가 자신의 권한 범위 내에서만 데이터에 접근하도록 보장.
2. 데이터 보호: 민감한 데이터를 필드 수준에서 필터링하여 정보 유출 방지.
3. 확장성과 유연성: 역할(Role)과 테넌트 정책을 쉽게 커스터마이징하여 다양한 요구 사항에 대응.
4. 효율적인 인증: JWT를 통해 중앙 인증 시스템과의 통합이 쉬워짐.

---

람다를 통한 JWT 검증 방식(사용자 커스텀)과 OpenSearch 내부 JWT 검증 방식

1. 람다를 통한 JWT 검증

클라이언트 요청은 OpenSearch에 도달하기 전에 람다에서 JWT 검증을 거칩니다. 이후, 람다가 OpenSearch로 요청을 전달합니다.

• 구조: 클라이언트 → 람다 → OpenSearch
• 장점:
  • OpenSearch 부하 분산: JWT 검증 및 요청 처리를 람다에서 독립적으로 수행
  • 인증 로직 분리: 보안 로직과 데이터 처리가 분리되어 유지보수가 용이
  • 추가 기능 구현 가능: 람다에서 추가 로직(예: 요청 필터링, 로깅) 적용 가능
• 단점:
  • 네트워크 레이턴시 증가: 람다를 경유하면서 추가 레이턴시 발생
  • 비용 증가: 람다 실행 시간과 호출 수에 따라 비용 발생

2. OpenSearch 내부 JWT 검증

클라이언트 요청이 OpenSearch로 직접 전달되어 OpenSearch 내부에서 JWT를 검증합니다.

• 구조: 클라이언트 → OpenSearch
• 장점:
  • 단순한 구조: 클라이언트 요청이 바로 OpenSearch로 전달
  • 요청 처리 속도 향상: 별도의 경유 없이 요청 처리
• 단점:
  • OpenSearch 리소스 소모: JWT 검증으로 인해 검색 성능 저하 가능
  • 부하 집중: 요청량 증가 시 OpenSearch에 과도한 부하 발생

---

보안 관련 비교 요약

	람다 JWT	OpenSearch 내부 JWT
보안 로직 분리	✅ (보안 로직과 데이터 처리 분리 가능)	❌ (OpenSearch 내에서 처리)
유연한 검증	✅ (커스터마이징 가능)	❌ (고정된 검증 방식)
KMS 키 관리	✅ (AWS KMS로 비밀키 관리)	❌ (OpenSearch 내에서 키 관리)
네트워크 보안	❌ (네트워크 홉 추가로 보안 관리 필요)	✅ (단순한 네트워크 구조)
부하 관리	✅ (OpenSearch 부하 분산)	❌ (OpenSearch 부하 집중 가능성)
필터링 및 전처리	✅ (Lambda에서 악성 요청 차단 가능)	❌ (사전 필터링 기능 없음)

---

어떤 방식을 선택해야 할까?

람다를 통한 JWT 검증이 적합한 경우:

• OpenSearch에 부하를 줄이고 싶을 때
• 보안 로직을 독립적으로 관리하고 싶을 때
• 추가적인 요청 전처리나 검증 로직이 필요한 경우

OpenSearch 내부 JWT 검증이 적합한 경우:

• 요청 처리 속도가 중요한 경우
• 네트워크 레이턴시와 비용을 최소화해야 하는 경우
• OpenSearch의 성능이 충분히 여유로운 경우