필요성

프로젝트 설계를 하면서, 백엔드 서버 간 통신에서만 사용되는 API가 일부 생겼습니다.
이는 프론트엔드에서 접근할 수 없으며, 이 api를 우리 시스템의 백엔드 서버에서 호출한건지 인증하지 않으면 보안상 취약점이 될 가능성 존재하다고 판단했습니다.
이에 가능한 인증 방식을 조사했습니다.

---

인증 방식

Shared Secret

• 방법: 서버 간 공유하는 비밀 키를 요청에 포함해 검증.
  • 예: Authorization: Bearer <shared_secret>
• 장점: 간단한 구현.
• 단점: 키 유출 시 보안 취약.

mTLS (Mutual TLS)

• 방법: 양쪽 서버가 TLS 인증서를 사용해 상호 인증.
• 장점: 높은 보안성, 데이터 위조 방지.
• 단점: 인증서 발급 및 관리 복잡.

IP 화이트리스트

• 방법: 허용된 서버의 IP 주소만 요청을 수락.
• 장점: 설정 간단.
• 단점: 동적 IP 환경에서는 관리가 어려움.

API Gateway

• 방법: API Gateway를 통해 내부 서버 전용 API로 설정.
  • 프론트엔드 IP를 차단하고 내부 요청만 허용.
• 장점: API 접근 권한 및 인증 관리 통합.
• 단점: 설정이 복잡하고 외부 호출 차단을 명확히 해야 함.

---

IP 화이트 리스트 방식의 수평 확장 방법

Private Network (VPC)

• 방법: 백엔드 서버를 사설 네트워크(VPC) 내에서 실행하고, CIDR 범위(예: 10.0.0.0/16)를 화이트리스트에 등록.
• 장점: IP 변화에 무관.
• 단점: VPC 구성 필요.

로드 밸런서 활용

• 방법: 로드 밸런서(LB)를 통해 모든 요청을 중계하고, LB의 IP만 화이트리스트에 등록.
• 장점: 서버 IP 관리 필요 없음.
• 단점: 로드 밸런서 설정 필요.

서비스 디스커버리

• 방법: 서버 IP를 직접 관리하지 않고 DNS 이름(예: backend-service.internal.local)으로 요청 처리.
• 도구: AWS Route 53, Consul, Eureka.
• 장점: IP 관리 부담 감소.
• 단점: 서비스 디스커버리 설정 필요.

Kubernetes NetworkPolicy

• 방법: Kubernetes Pod 간 통신을 NetworkPolicy로 제어.
• 예시:

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: allow-backend
  spec:
    podSelector:
      matchLabels:
        app: backend
    ingress:
    - from:
      - podSelector:
          matchLabels:
            app: frontend