API Connectivity Manager로 세분화된 액세스 제어 및 라우팅 적용

Veena Raja Rathna

API의 전체 수명 주기를 관리할 때 중요한 부분 중 하나는 API 액세스와 트래픽 라우팅을 세밀하게 제어하는 것입니다. 액세스 토큰은 API 액세스를 관리하기 위한 사실상의 표준으로 자리 잡았습니다. JSON 웹 토큰(JWT) 기반 인증 체계의 장점 중 하나는 JWT의 클레임을 활용하여 이처럼 세밀한 액세스 제어를 구현할 수 있다는 것입니다. 권한을 사용자 지정 클레임으로 인코딩하면 API 소유자가 이를 사용해 자신의 API에 대한 액세스를 제어할 수 있습니다. API 프록시가 JWT를 검증하면 토큰의 모든 필드를 변수로 사용할 수 있으며, 이를 바탕으로 액세스 허용 여부를 결정할 수 있습니다.

In a 이전 게시물에서는 API Connectivity Manager가 운영자와 개발자의 협업을 어떻게 개선할 수 있는지 살펴보았습니다. API를 소유하고 운영하는 각 사업 부문의 팀은 API와 서비스의 사용자 경험을 개발하고 개선하는 과정에서 모든 권한을 행사할 수 있어야 합니다.

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

사전 요구 사항

평가판 또는 유료 구독이 필요합니다: F5 NGINX Management Suite. 이 제품에는 Instance Manager와 API Connectivity Manager뿐만 아니라 API 게이트웨이로 사용되는 NGINX Plus와 API 보안을 위한 NGINX App Protect가 포함되어 있습니다. 시작하려면 NGINX Management Suite 30일 무료 평가판을 신청하세요.

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

특정 서비스에 대한 액세스 권한 부여 및 트래픽 라우팅

다음과 같은 여러 엔드포인트가 있는 창고 API 프록시를 게시했다고 가정해 보겠습니다. 예를 들면 inventory, orders 등이 있습니다. 이제 pricing이라는 새 서비스를 도입하되, 베타 평가판을 신청한 일부 클라이언트만 이 서비스에 액세스할 수 있도록 하려고 합니다. 이러한 클라이언트는 betatester라는 클레임으로 식별됩니다. 이 샘플 액세스 토큰에서 sub 클레임으로 식별되는 사용자 user1@abc.com의 해당 클레임 값은 true입니다.

Header
{
  "kid": "123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx",
  "alg": "RS256"
}
Payload

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

베타 프로그램에 선정되지 않은 user2@abc.com 사용자의 경우 betatester 클레임은
false로 설정됩니다:

"sub": "user2@abc.com","betatester": false,

이제 JWT에 값이 pricing 서비스에 대한 액세스 권한을 부여하도록 액세스 제어 라우팅 정책(access-control-routing)을 구성합니다. JWT에는 값이 betatester인 true 클레임이 포함되어 있어야 합니다.

간결하게 설명하기 위해 정책 페이로드만 표시합니다. 이 정책은 API Connectivity Manager의 JWT Assertion 및 OAuth2 Introspection과 같은 토큰 기반 정책에서만 작동합니다.

"policies": {  "access-control-routing": [
    {
      "action": {
        "conditions": [
          {
            "allowAccess": {
              "uri": "/pricing"
            },
            "when": [
              {
                "key": "token.betatester",
                  "matchOneOf": {
                    "values": [
                      "true"
                    ]
                  }
              }
            ]
          }
        ],
        "returnCode": 403
      }
    }
  ]
}

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

특정 메서드 사용 제어

특정 HTTP 메서드를 사용할 수 있는 사용자를 제어하도록 access-control-routing 정책을 더욱 세밀하게 조정할 수 있습니다. 이 예시에서 API 프록시는 관리자(토큰에 Admin 값이 포함된 사용자)만 DELETE 메서드를 사용할 수 있도록 허용합니다.

"policies":{  "access-control-routing":[
    "action":{
      "conditions":[
        {
          "when":[
            {
              "key":"token.{claims}",
              "matchOneOf":{
                "values":[
                  "Admin"
                ]
              }
            }
          ],
          "allowAccess":{
            "uri":"/v1/customer",
            "httpMethods":[
              "DELETE"
            ]
          },
          "routeTo" : {
            "targetBackendLabel" : ""
          }
        }
      ]
    }
  ]
}

헤더 기반 라우팅

access-control-routing 정책의 또 다른 용도는 수신 요청의 헤더 값을 기반으로 라우팅을 결정하는 것입니다. API 소유자는 요청이 라우팅되기 위해 일치해야 하는 헤더 값을 지정하는 규칙이나 조건을 구성할 수 있습니다. 해당 헤더가 포함된 요청은 전달되고, 포함되지 않은 요청은 삭제됩니다.

이 예시에서는 /seasons 엔드포인트로 요청이 라우팅되려면 version 요청 헤더의 값이 v1이어야 합니다. returnCode 값은 version이 v1이 아닐 때 반환할 오류 코드를 지정합니다. 이 경우에는 403 (Forbidden)입니다.

"access-control-routing": [  {
    "action": {
      "conditions": [
        {
          "allowAccess": {
            "uri": "/seasons"
          },
          "when": [
            {
              "key": "header.version",
              "matchOneOf": {
                "values": [
                  "v1"
                ]
              }
            }
          ]
        }
      ],
      "returnCode": 403
    }
  }
]

이 예시 curl 요청에서는 seasons 서비스에 요청을 보내면서 version 헤더를 v2로 설정합니다:

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

정책에서 요구하는 대로 version 헤더의 값이 v1이 아니므로 서비스는 상태 코드 403을 반환합니다.

정책에 여러 규칙 포함

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

요약

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

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

작성자 소개

Veena Raja Rathna

Veena Raja Rathna의 다른 블로그 게시물