S2S 인증

S2S 인증은 어떤 서비스/워크 플로우가 요청을하는지 입증하고 제한된 시간 동안 필요한 최소 권한을 부여합니다. 사용자 스트림과 달리 여기에는 사람이 없습니다. 따라서 자격 증명의 짧은 수명, 운동/채널에 대한 암호화 바인딩 및 명확한 관찰 성이 중요합니다.

1) 목표와 원칙

기본적으로 제로 트러스트: 네트워크를 신뢰하지 말고 운동 및 암호화 만 인증하십시오.
단기 크레딧: 일/개월이 아닌 분.
상황 구속력: 세입자/지역/라이센스/청중/스코프.
중앙 집중식 발행, 분산 검증: STS/IdP + 로컬 검증.
최소한의 특권 및 명시 적 위임: 필요한 범위 및 감사 만.
"무통" 회전: 듀얼 키/듀얼 인증 창 및 자동화.

2) 위협 모델 (최소)

오래 지속되는 비밀 도난 (API-keys, 오래 지속되는 RT).
VPC/클러스터 내에서 서비스 스푸핑.
부서진 세분화에 대한 지역 간 공격.
재생/프록시 트래픽 대체.
공급망/컨테이너 이미지 대체.
구성 오류 (넓은 방화벽/메쉬 규칙, 모두에 대한 일반적인 JWKS).

3) 기본 패턴 S2S

3. 1 mTLS (상호 인증서)

당신은 누구입니까: 채널로 증명합니다.
내부 PKI에서 수명이 짧은 (1 시간) 인증서; 릴리스/회전은 메쉬/사이드카 또는 SPIRE 에이전트에 의해 관리됩니다.
동일한 트러스트 도메인의 "이웃" 및 바인딩 토큰에 좋습니다.

3. 서비스 JWT (STS) 2 개

당신은 누구입니까: 메시지로 증명하십시오.
'aud', 'scp', 'tentin', 'region' 을 사용한 짧은 액세스 JWT (2-5 분).
KMS/HSM, 공개 키-' 키드 '및 로테이션이있는 JWKS를 통해 표시됩니다.
로컬 체크 (IdP 네트워크 호출 없음).

3. 3 SPIFFE/SPIRE (SVID)

근로자의 보편적 정체성: 'spiffe ://trust-domain/ns/< ns >/sa/< sa>'.

Istio/Linkerd와의 통합 자동 발급/회전

3. 4 OAuth 2. 1 클라이언트 자격 증명/토큰 교환 (RFC 8693)

기계 클라이언트는 STS로부터 토큰을받습니다 사용자 "대신" 조치 - OBO (토큰 교환).

결합: 채널의 경우 mTLS, 메시지의 경우 JWT, 안정적인 ID의 경우 SPIFFE.

4) 참조 아키텍처

[KMS/HSM]       [Policy Store / PDP]

[STS/IdP (issuer)] ── JWKS ──[Gateway/PEP] ─────[Services/PEP]
│
SVID/JWT │         │    │      │
(SPIRE/Istio)│      mTLS/DPoP  │    mTLS/DPoP
│         │    │      │
[Workload/Sidecar]─────────┴───────┴────────────┘

발행인 (STS/IdP): 짧은 서비스 JWT/CVID를 출시하고 JWKS를 게시합니다.
게이트웨이 (PEP): 네트워크 용어, mSL/JWT 검증, 컨텍스트 풍부 화, PDP 요청.
서비스 (PEP) -심층 방어, PDP 솔루션 캐시.
SPIRE/mesh: mTLS에 대한 자동 인증서 및 SVID.

5) JWT 서비스 형식 (예)

json
{
"iss": "https://sts. core",
"sub": "svc. catalog, "//service identity
"aud": ["svc. search"] ,//target service/domain
"exp": 1730390100, "iat": 1730389800,
"tenant": "brand_eu",
"region": "EE",
"scp": ["catalog:read:public","catalog:read:tenant"],
"mtls": { "bound": true, "spiffe": "spiffe://core/ns/prod/sa/catalog" }
}

서명 된 ES256/EdDSA의 'kid' 는 활성 키를 나타냅니다.
채널에 대한 선택적 바인딩: 플래그, 해시 인증, SVID.

6) 문제 정책 (STS) 및 검증

• 과목은 SVID/클라이언트 인증서/클라이언트 레지스터에서 가져옵니다.
• 수명 2-5 분, 새로 고침이 없음-대신 STS를 다시 요청하십시오.
• 스코프/청중은 고객 요청이 아닌 정책 저장소 (GitOps) 에서 가져옵니다.

1. (PHP 3 = 3.0.6, PHP 4)

2. JWKS ('kid') 의 JWT 서명을 확인하십시오.

3. 'exp/nbf/iss/aud', 테넌트/지역/라이센스.

4. 컨텍스트를 확장하고 PDP (RBAC/ABAC/ReBAC) 에 문의하십시오.

5. 캐시 PDP 솔루션 (TTL 30-120 s), 이벤트 장애.

7) 멀티 테넌트 및 지역 (트러스트 도메인)

별도의 신뢰 도메인: 'spiffe ://eu. 핵심 ',' spiffe ://latam. 핵심 '.

지역별로 별도의 JWKS/PKI; 지역 간 - 신뢰할 수있는 게이트웨이를 통해서만

스탬프에 '테넌트/지역/라이센스' 를 포함시키고 리소스 준수를 확인하십시오.
세그먼트 로그/세입자 및 지역별 감사.

8) 메시/사이드카 및 노 메쉬 모드

Istio/Linkerd: 상자에서 mTLS, L4/L7 수준에서 정책 시행, SPIRE와의 통합.

메쉬없이: 응용 프로그램의 클라이언트 라이브러리 + 상호 TLS; 회전을 관리하기가 더 어렵습니다. 에이전트를 통해 자동

9) 키, JWKS 및 회전

KMS/HSM에서만 개인 키; 서명 - 원격 통화/설정으로.
N 일마다 회전; 듀얼 키: 오래된 + 새로운 것이 허용되고, 발행자는 캐시를 예열 한 후 새로운 신호를 보냅니다.
모니터링: 'kid' 에 의한 소비 점유율, 기존 키에 고객을 매달았습니다.

yaml issuer:
jwks:
alg: ES256 rotation_days: 30 publish_cache_ttl: 60s sts:
access_ttl: 5m audience_policies:
- subject: "svc. catalog"
allow: ["svc. search","svc. wallet"]
scopes: ["catalog:read:"]
tenancy:
claims: ["tenant","region","licence"]
jwks_per_region: true

10) 링크 바인딩 (DPoP/mTLS 바운드)

mSL 바운드 토큰: JWT에 클라이언트 인증서 해시 추가; 리셉션에서 확인하십시오.
DPoP: mTLS가없는 SHT 클라이언트의 경우-각 요청에 DPoP 키로 서명하고 AT에 DPoP 지문을 표시하십시오.

11) 오류 및 반환 정책

• '401 INVALID _ TOKEN '/' EXPIRED _ TOKEN '/' AUD _ MISMATCH'.
• (PHP 3 = 3.0.6, PHP 4)
• '403 INSUFFICIENT _ SCOPE '/' POLICY _ DENY'.
• '429 RATE _ LIMITED'.

응답에는 기계에서 읽을 수있는 '오류 _ 코드' 및 'as _ of' (키/정책 버전) 가 포함되어 있습니다.

12) 관찰 및 감사

• (PHP 3 = 3.0.13, PHP 4)
• (PHP 3 = 3.0.6, PHP 4)
• mSL 바운드 요청의 비율 인 'kid' 에 의한 소비.

• '주제', 'aud', '세입자', '지역', 'scp', 'kid', 'sid/svid', '결정', 'policy _ version', 'trace _ id'.

• 토큰 발행, 키 회전, 정책 변경, 거부 된 요청.

13) 성능

JWT 확인-로컬로 배경 업데이트가있는 캐시 JWKS (TTL 30-60 초).
할 수 없습니다.
고가의 검증 I/O를 게이트웨이/사이드카로 가져 오십시오.
프리페치 토큰/인증서 사용 (만료 10-20 초 전).

14) 테스트

계약/상호 작용: 다른 NP/라이브러리, 시계 기울기

부정적: 만료/가짜 토큰, 잘못된 'aud', 잘못된 지역/테넌트, 깨진 인증서 체인.
혼돈: 갑작스런 회전 '어린이', JWKS의 사용 불가, 대량 만료, mSL 중단.
로드: STS의 최대 문제, 게이트웨이의 스파이크 확인.
E2E: mSL 전용, JWT 전용, 결합 된 모드, 토큰 교환 (OBO).

15) 플레이 북 (런북)

1. 서명 키 타협

즉시 철회, 새롭고 단축 된 TTL 토큰 출시, 감사, "중단 된" 클라이언트 검색, 오래된 '어린이' 에 대한 강제 거부.

2. 대량 'INVALID _ TOKEN'

JWKS 캐시, 클럭 정렬 오류, 토큰 원점 (TTL 너무 짧음) 을 확인하고 일시적으로 기울기 공차를 확장하고 JWKS를 예열하십시오.

3. mTLS 거부

CA 체인, SVID 날짜, 호스트 시간을 확인하십시오. SPIRE/Istio를 통한 비상 재발행은 해당 지역 내에서만 대체 경로를 가능하게합니다.

4. 'AUD _ MISMATCH' 성장

청중 정책 드리프트: STS 정책을 실제 통화와 비교하고 원하는 'aud' 를 일시적으로 추가하여 통화 아키텍처 조정을 예약하십시오.

5. STS 사용할 수 없음/느림

이미 발행 된 토큰 (그레이스) 의 TTL을 늘리고 미리 가져오기/새로 고침, 스케일 아웃 STS를 활성화하십시오.

16) 전형적인 오류

env/코드의 수명이 긴 API 키/비밀.
일반 JWKS/PKI "모든 지역과 항상".
바인딩 부족 (mSL/DPoP) → 토큰을 쉽게 제거 할 수 있습니다.
Broad 'aud =' 및 "관리자" 는 기본적으로 범위를 정합니다.
이중 키 기간이없는 회전 → 질량 401.
게이트웨이에서만 토큰을 확인합니다 (심층 방어 없음).
"Dumb" 오류 ('오류 _ 코드' 및 '이유' 없음) -팀을 디버깅하고 훈련하기가 어렵습니다.

17) 미니 설정 템플릿

yaml auth:
require_mtls: true jwks:
url: https://sts. core/.well-known/jwks. json cache_ttl: 60s claims:
required: ["iss","sub","aud","exp","tenant","region"]
tenant_in_header: "x-tenant"
pdp:
endpoint: "opa:8181/v1/data/policy/allow"
decision_cache_ttl: 60s

yaml subjects:
- id: "svc. catalog"
spiffe: "spiffe://core/ns/prod/sa/catalog"
audiences: ["svc. search","svc. wallet"]
scopes: ["catalog:read:"]
ttl: "5m"

18) 사전 판매 점검표

• 짧은 서비스 JWT (λ5 분), 로컬 확인, JWKS 캐시.
• mSL (또는 DPoP) 활성화; 우선 순위-mSL 바운드 토큰.
• SPIFFE/SPIRE 또는 인증서의 자동 발급/회전에 해당합니다.
• 청중/범위 정책이있는 STS; 신뢰할 수있는 신원만으로 발행.
• 지역별 트러스트 도메인 및 JWKS 분리; 세입자/지역/라이센스 스탬프가 확인됩니다.
• 이벤트 별 PDP/PEP 통합 솔루션 캐시 + 장애.
• 소비 'kid' 를 모니터링하는 듀얼 키 윈도우는 유효하지 않음/aud 불일치를 경고합니다.
• 전체 로그/감사 S2S, 성능/오류 메트릭 활성화
• 주요 타협 플레이 북, STS 드롭, mSL 실패.
• 계약/음성/혼돈/로드/E2E 테스트 제품군이 통과되었습니다.

결론

S2S 인증은 중앙 집중식 STS가 관리하고 로컬에서 확인한 채널 트러스트 (mSL), 메시지 트러스트 (짧은 JWT) 및 지속적인 작업자 신원 (SPIFFE) 의 조합입니다. 트러스트 도메인 분리, 엄격한 청중/스코프, 자동 회전 및 관찰 성을 추가하면 플랫폼 및 지리와 함께 신뢰할 수 있고 설명 가능하며 확장 가능한 개요가 있습니다.