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

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

이전 포스트에서는 API Connectivity Manager 가 운영자와 개발자가 더 잘 협업할 수 있도록 도와주는 방법에 대해 논의했습니다. API를 소유하고 운영하는 다른 사업 부문의 팀은 API 및 서비스의 경험을 개발하고 향상시키는 과정에서 완전한 제어권이 필요합니다.

API의 라이프사이클 동안 API 접근과 트래픽 라우팅에 대한 세밀한 제어는 중요한 부분입니다. 접근 토큰은 API 접근을 관리하기 위한 사실상의 표준으로 등장했습니다.
JSON Web Tokens (JWTs)를 기반으로 한 인증 체계의 장점 중 하나는 JWT의 클레임을 활용하여 세밀한 수준의 접근 제어를 구현할 수 있다는 것입니다.
권한은 사용자 정의 클레임으로 인코딩될 수 있으며, API 소유자는 이를 사용하여 자신의 API에 대한 접근을 제어할 수 있습니다. API 프록시가 JWT를 검증한 후에는 토큰의 모든 필드에 변수로 접근할 수 있으며, 이를 기반으로 접근 결정을 내릴 수 있습니다.

목차

1. 전제 조건
2. 특정 서비스에 액세스 권한 부여 및 트래픽 라우팅
3. 특정 메소드 사용 통제
4. API Connectivity Manager 의 Header 기반 라우팅
5. API Connectivity Manager 로 정책에 여러 규칙 포함
6. 요약

1. 전제 조건

NGINX Management Suite, Instance Manager 및 API Connectivity Manager 를 포함한 구독 또는 유료 구독이 필요합니다. 이는 API Gateway로 NGINX Plus와 API를 보호하기 위한 NGINX App Protect를 포함합니다.
NGINX Management Suite의 무료 30일 체험판을 NGINX STORE에 요청하여 시작하세요. NGINX Management Suite 및 API Connectivity Manager 를 설치하는 방법에 대한 지침은 설치 가이드를 참조하십시오.

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

inventory, order 등과 같은 여러 엔드포인트를 가진 warehouse API 프록시를 게시했다고 가정해 봅시다. 이제 NGINX는 pricing이라는 새로운 서비스를 소개하려고 합니다. 그러나 이 서비스는 베타 Trial에 가입한 몇 명의 클라이언트만 접근할 수 있도록 만들고 싶습니다.
이러한 클라이언트는 betatester라는 클레임으로 식별됩니다. 이 샘플 액세스 토큰에서는 betatester 클레임이 true로 설정되어 있으며, 해당 클레임은 sub 클레임에서 식별된 사용자인 user1@abc.com에게 적용됩니다.

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,

이제 NGINX는 액세스 제어 라우팅 정책(access-control-routing)을 구성하여 betatester 클레임 값이 true인 JWT를 포함하는 사용자에게 가격 서비스에 대한 액세스를 허용합니다.

간결함을 위해 정책 페이로드만 표시합니다. 이 정책은 JWT Assertion 및 OAuth2 Introspection과 같은 API Connectivity Manager 의 토큰 기반 정책과 함께만 작동합니다.

"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의 요청을 거부하여 세밀한 액세스 제어를 수행합니다.

3. 특정 메소드 사용 통제

액세스 제어 라우팅 정책을 더욱 세밀하게 조정하여 특정 HTTP 메소드를 사용할 수 있는 사용자를 제어할 수 있습니다.
이 예시에서는 API 프록시가 DELETE 메소드를 사용할 수 있는 권한을 가진 관리자들 (토큰에 Admin 값을 포함하는 사용자)에게만 허용합니다.

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

4. API Connectivity Manager 의 Header 기반 라우팅

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

이 예시에서는 버전 요청 헤더가 v1인 경우에만 요청이 /seasons 엔드포인트로 라우팅됩니다. returnCode 값은 버전이 v1이 아닌 경우 반환할 오류 코드를 지정합니다. 이 경우에는 403 (Forbidden)입니다.

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

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

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

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

5. API Connectivity Manager 로 정책에 여러 규칙 포함

액세스 제어 라우팅 정책에는 이 게시물에서 설명한 세 가지 기준 중 하나, 둘 또는 모두를 기반으로 라우팅을 제어하기 위해 여러 규칙을 포함할 수 있습니다.

  • JWT 클레임
  • 유효한 메서드
  • 유효한 요청 헤더 값

요청은 모든 규칙의 조건과 일치해야 라우팅됩니다. 그렇지 않으면 차단됩니다.

6. 요약

API Connectivity Manager 는 API 소유자가 API 및 서비스의 경험을 제어하고 향상시킬 수 있도록 API 수준의 정책을 적용하여 세밀한 접근 제어를 수행하고 동적 라우팅 결정을 내릴 수 있게 합니다.

API Connectivity Manager 를 시작하려면 NGINX Management Suite의 무료 30일 체험을 NGINX STORE에 요청하세요.

아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.