API Connectivity Manager를 사용하여 세분화된 액세스 제어 및 라우팅 적용

API를 수명 주기 전반에 걸쳐 관리하는 데 있어 중요한 부분 중 하나는 API 액세스와 트래픽 라우팅을 세부적으로 제어하는 것입니다. 액세스 토큰은 API 액세스를 관리하기 위한 사실상의 표준으로 등장했습니다. JSON 웹 토큰(JWT) 기반 인증 체계의 장점 중 하나는 JWT의 클레임을 활용하여 섬세한 수준의 액세스 제어를 구현할 수 있다는 것입니다. 권한은 사용자 정의 클레임으로 인코딩될 수 있으며, API 소유자는 이를 사용하여 API에 대한 액세스를 제어할 수 있습니다. API 프록시가 JWT의 유효성을 검사하면 토큰의 모든 필드에 변수로 접근할 수 있으며 이를 기반으로 액세스 결정을 내릴 수 있습니다.

이전 게시물 에서는 API Connectivity Manager가 운영자와 개발자의 보다 효과적인 협업에 어떻게 도움이 될 수 있는지 설명했습니다. API를 소유하고 운영하는 다양한 사업 부문의 팀은 API와 서비스 경험을 개발하고 향상시키면서 전체적인 통제권을 가져야 합니다.

API Connectivity Manager는 API 소유자가 API 인증, 권한 부여, 추가 보안 요구 사항과 같은 서비스 수준 설정을 구성할 수 있는 정책을 제공합니다. 이 게시물에서는 API 소유자가 액세스 제어 라우팅 정책을 사용하여 특정 경로에 대한 세분화된 제어를 시행하고 토큰의 특정 클레임을 기반으로 HTTP 메서드 및 경로별로 적용되도록 더욱 세부적으로 조정할 수 있는 방법을 보여줍니다.

필수 조건

Instance Manager와 API Connectivity Manager, API 게이트웨이인 NGINX Plus, API를 보호하기 위한 NGINX App Protect가 포함된 F5 NGINX Management Suite 의 평가판이나 유료 구독이 필요합니다. 시작하려면 NGINX Management Suite의 무료 30일 체험판을 요청하세요.

NGINX Management Suite와 API Connectivity Manager를 설치하는 방법에 대한 지침은 설치 가이드를 참조하세요.

특정 서비스에 대한 액세스 허용 및 트래픽 라우팅

재고 , 주문 등 여러 엔드포인트가 있는 창고 API 프록시를 게시했다고 가정해 보겠습니다. 이제 가격 책정 이라는 새로운 서비스를 소개하고 베타 평가판에 등록한 일부 고객에게만 접근 가능하도록 하려고 합니다. 이러한 클라이언트는 betatester 라는 클레임을 통해 식별됩니다. 이 샘플 액세스 토큰에서 해당 클레임은 하위 클레임에서 식별된 사용자 user1@abc.com 에 대해 참입니다 .

헤더
{
"아이": "123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx",
"alg": "RS256"
}
탑재량

{
"ver": 1,
"jti": "AT.xxxxxxxxxxxx",
"iss": "https://oauthserver/oauth2/",
"aud": "inventoryAPI",
"iat": 1670290877,
"exp": 1670294477,
"cid": "AcvfDzzzzzzzzzz",
"uid": "yyyyyyyWPXulqE4x6",
"scp": [
"apigw"
],
"auth_time": 1670286138,
"sub": "user1@abc.com",
"betatester": true,
"domain": "abc"
}

베타 프로그램에 선택되지 않은 user2@abc.com 의 경우 베타테스터 클레임은 다음과 같이 설정됩니다.
거짓:

"sub": "user2@abc.com","betatester": 거짓,

이제 JWT에 true 값을 가진 betatester 클레임이 포함된 사용자에게 가격 서비스 액세스 권한을 부여하기 위해 액세스 제어 라우팅 정책( access-control-routing )을 구성합니다.

간결하게 설명하기 위해 정책 페이로드만 보여드리겠습니다. 이 정책은 JWT 어설션 및 OAuth2 인트로스펙션과 같은 API Connectivity Manager의 토큰 기반 정책에서만 작동합니다.

"정책": { "액세스 제어 라우팅": [
{
"작업": {
"조건": [
{
"허용접근": {
"uri": "/가격"
},
"언제": [
{
"키": "토큰.베타테스터",
"matchOneOf": {
"값": [
"참"
]
}
}
]
}
],
"반환 코드": 403
}
}
]
}

정책을 적용하면 API 프록시는 인증된 사용자에 대한 JWT의 클레임을 검증하여 user1@abc.com 의 요청을 라우팅하고 user2@abc.com 의 요청을 거부하는 세부적인 액세스 제어를 수행합니다.

특정 방법의 사용 제어

우리는 사용자가 특정 HTTP 메서드를 사용할 수 있는지 제어하기 위해 액세스 제어 라우팅 정책을 더욱 세부적으로 조정할 수 있습니다. 이 예에서 API 프록시는 관리자(토큰에 Admin 값이 포함된 사용자)만 DELETE 메서드를 사용하도록 허용합니다.

"정책":{ "액세스 제어 라우팅":[
"작업":{
"조건":[
{
"언제":[
{
"키":"토큰.{클레임}",
"matchOneOf":{
"값":[
"관리자"
]
}
}
],
"허용접근":{
"uri":"/v1/고객",
"http방법":[
"삭제"
]
},
"routeTo": {
"대상백엔드레이블": ""
}
}
]
}
]
}

헤더 기반 라우팅

액세스 제어 라우팅 정책의 또 다른 용도는 들어오는 요청의 헤더 값을 기반으로 라우팅 결정을 내리는 것입니다. API 소유자는 요청을 라우팅하기 위해 헤더에 일치해야 하는 값을 지정하는 규칙이나 조건을 구성할 수 있습니다. 헤더가 포함되어 있으면 요청이 전달되고, 포함되어 있지 않으면 요청이 삭제됩니다.

이 예에서 요청은 버전 요청 헤더의 값이 v1 인 경우에만 /seasons 엔드포인트로 라우팅됩니다. returnCode 값은 버전이 v1이 아닐 때 반환할 오류 코드를 지정합니다. 이 경우에는 다음과 같습니다.403 (금지됨) .

"접근 제어 라우팅": [ {
"동작": {
"조건": [
{
"허용접근": {
"uri": "/시즌"
},
"언제": [
{
"키": "헤더.버전",
"matchOneOf": {
"값": [
"v1"
]
}
}
]
}
],
"반환 코드": 403
}
}
]

이 샘플 curl 요청에서는 버전 헤더를 v2 로 설정하여 seasons 서비스에 요청을 보냅니다.

curl -H "버전: v2" http://example.com/seasons

정책에서 요구하는 대로 버전 헤더의 값이 v1이 아니기 때문에 서비스는 상태 코드를 반환합니다.403 .

정책에 여러 규칙 포함

이 게시물에서 논의된 기준 중 하나, 둘 또는 세 가지 모두를 기반으로 라우팅을 제어하기 위해 액세스 제어 라우팅 정책에 여러 규칙을 포함할 수 있습니다. JWT 클레임, 유효한 메서드 및 요청 헤더 값. 요청은 라우팅되려면 모든 규칙의 조건을 충족해야 합니다. 그렇지 않으면 차단됩니다.

요약

API Connectivity Manager를 사용하면 API 소유자가 세분화된 액세스 제어를 적용하고 동적 라우팅 결정을 내리는 API 수준 정책을 통해 API 및 서비스 경험을 제어하고 개선할 수 있습니다.

API Connectivity Manager를 시작하려면 NGINX Management Suite의 무료 30일 평가판을 요청하세요.