lander.log

AWS OpenSearch Security Model (SigV4 & FGAC)

7 min read

AWS OpenSearch Security Model (SigV4 & FGAC)

Referenced by

정의 (Definition)

AWS OpenSearch의 보안은 “누가 클러스터에 도달할 수 있는가(Gateway)” 를 검증하는 SigV4 (IAM) 계층과, “도달한 주체가 어떤 데이터에 접근할 수 있는가(Internal)” 를 제어하는 FGAC (Fine-Grained Access Control) 계층이 직렬로 연결된 이중 인가(Dual-Layer Authorization) 모델입니다. 이는 단일 진입점으로 모든 권한을 처리하는 일반적인 데이터베이스 인증 모델과 다릅니다.

문제가 되는 배경 (Problem Context)

OpenSearch 도입 시 가장 빈번한 장애는 “IAM Role에 es:* 권한을 부여했는데 인덱스 쓰기가 거부됨” 또는 “Basic Auth(ID/PW)를 사용하는데 User: anonymous is not authorized 오류가 발생함”과 같은 상황입니다. 이는 두 보안 계층이 독립적으로, 순차적으로 동작한다는 사실을 간과했을 때 발생합니다. 하나만 통과해서는 데이터에 접근할 수 없습니다.

핵심 메커니즘 (How it Works)

1. Layer 1: Domain Access Policy (SigV4)

  • 역할: AWS 인프라 레벨의 방화벽. HTTP 요청 자체가 OpenSearch 엔드포인트에 도달할 자격이 있는지 검사합니다.
  • 검증 방식: Authorization 헤더의 SigV4 서명을 AWS IAM 서비스와 대조하여 Principal (User/Role)을 식별합니다.
  • 판정: Access Policy에 명시된 Principal과 Source IP 조건이 맞지 않으면 즉시 차단됩니다.

2. Layer 2: Fine-Grained Access Control (FGAC)

  • 역할: OpenSearch 어플리케이션 레벨의 권한 제어. (구 Opendistro Security Plugin)
  • 검증 방식:
    1. 식별: SigV4로 넘어온 IAM Role ARN 또는 Basic Auth의 Username을 확인합니다.
    2. 매핑: 해당 식별자를 OpenSearch 내부의 Backend Role에 매핑합니다.
    3. 인가: 매핑된 Role이 요청한 인덱스/Action(예: indices:data/write/index)을 허용하는지 확인합니다.

요청 처리 흐름 (Flow)

graph LR
    Client[Client Request] -->|"(1) Network"| SG["Security Group"]
    SG -->|Pass| Layer1["(2) Domain Access Policy (SigV4)"]
    Layer1 -->|Allow Principal| Layer2["(3) FGAC (Security Plugin)"]
    Layer2 -->|Allow Action| Data[Data/Index]
    
    Layer1 --"No SigV4 / Policy Deny"--> Drop1["403 Forbidden (AWS)"]
    Layer2 --"No Internal Role Mapping"--> Drop2["403 Unauthorized (OpenSearch)"]

불변 조건과 보장 범위 (Invariants & Guarantees)

  1. 순차적 차단 (Sequential Denial): Access Policy(Layer 1)가 허용하지 않은 요청은 FGAC(Layer 2)에 도달조차 하지 못합니다. 로그 또한 남지 않을 수 있습니다.
  2. SigV4 우선 원칙: Access Policy가 Principal: AWS: "*" (전체 허용)으로 설정되지 않은 한, SigV4 서명이 없는 요청(Basic Auth 포함)은 Anonymous로 간주되어 Layer 1에서 거부됩니다.
  3. 최소 권한의 교집합: 최종적으로 수행 가능한 작업은 Layer 1(IAM Policy)과 Layer 2(FGAC Role)가 모두 허용하는 범위로 제한됩니다.

비유 (Analogy)

  • OpenSearch 도메인: “국가 기밀 문서 보관소 (건물)”
  • SigV4 (IAM Policy): “건물 정문 출입증”. (사원증). 이것이 없거나 유효하지 않으면 건물 로비조차 밟을 수 없습니다.
  • FGAC: “자료실 열람 등급”. (2급 비밀 취급 인가). 정문을 통과해 로비에 있더라도, 내 등급에 맞지 않는 문서를 열려고 하면 사서(Security Plugin)가 제지합니다.
  • Basic Auth: “방문증”. 사원증(SigV4) 대신 신분증(ID/PW)을 맡기고 들어오는 방식입니다. 단, 정문 경비원(Access Policy)에게 “방문증 소지자도 출입 가능(Anonymous 허용)” 지침이 있어야만 들어올 수 있습니다.

비유의 한계

현실의 방문증은 사원증과 별개로 취급되지만, OpenSearch의 Basic Auth는 Access Policy 관점에서는 “신원 미상(Anonymous)“으로 처리될 수 있다는 점에서 기술적 차이가 있습니다.

실무적 함의 (Operational Implications)

  • 장애 식별 (Troubleshooting):
    • User: anonymous is not authorized: Layer 1 문제. SigV4 서명이 누락되었거나, Access Policy가 이 요청을 거부했습니다.
    • security_exception: no permissions for [indices:data/read/search]: Layer 2 문제. 정문은 통과했으나, 해당 IAM Role이나 User가 OpenSearch 내부 Role에 매핑되지 않았습니다.
  • 보안 구성 전략:
    • Prod: Access Policy를 타이트하게(특정 IAM Role만 허용) + FGAC로 세부 권한 제어.
    • Access Pattern: 어플리케이션은 SigV4(IAM)를 사용하고, 사람(운영자)은 Basic Auth(ID/PW)를 사용하는 경우가 많습니다. 이 경우 Access Policy는 “특정 IAM Role” OR “특정 IP(VPN)에서의 Anonymous 접근”을 허용해야 합니다.

주의사항 / 오해 (Pitfalls & Misconceptions)

  1. “Master User는 무적이다?”: 생성 시 설정한 Master User(Basic Auth)라도, Access Policy에서 해당 IP나 요청을 차단하면 접속할 수 없습니다. Access Policy가 상위 계층입니다.
  2. “IAM Policy에 Admin 권한이 있으면 끝?”: AWS IAM Policy에서 opensearch:*를 줘도, FGAC 내부 매핑(all_access role)이 없으면 데이터 조회는 불가능합니다.
  3. Security Group vs Access Policy: Security Group은 네트워크(Port/IP) 레벨의 차단이고, Access Policy는 HTTP 요청의 인증 정보(SigV4) 레벨의 차단입니다. 둘 다 통과해야 합니다.

References

Recent Posts