백엔드 API 서비스 보호하기 2탄 – 특정 요청 메소드 적용 & 세분화된 액세스 제어 적용

애플리케이션 운영을 보다 빠르고, 스마트하며, 안전하게 운영할 수 있도록 지원하는 글로벌 No.1 브랜드 <F5 네트웍스 코리아> 공식 블로그를 방문해주신 여러분, 반갑습니다! 최근 F5네트웍스 코리아 블로그에서는 중요한 API 게이트웨이 기능을 NGINX로 구현하는 방법들을 설명해 드리고 있는데요. 그 중 백엔드 API 서비스 보호하기의 ‘속도제한’편에 보여주신 많은 관심에 힘입어 ‘특정 요청 메소드 적용 & 세분화된 액세스 제어 적용’편을 준비했습니다.

​​

특정 요청 메소드 적용하기

RESTful API에서 verb로도 불리는 HTTP 메소드는 각 API 호출의 중요한 부분이며, API 정의에 있어서도 매우 중요합니다. 웨어하우스 API의 가격 책정 서비스를 예로 들어 자세히 설명해 드리겠습니다.

• GET /api/warehouse/pricing/item001 item001의 가격 반환

• PATCH /api/warehouse/pricing/item001 item001의 가격 변경

가격 책정 서비스에 대한 요청에서 이들 2개의 HTTP 메소드만 수용하도록 Warehouse API의 정의를 업데이트할 수 있습니다. 인벤토리 서비스에 대한 요청에서는 GET 메소드만 수용되지요.

​이 구성을 적용해 보면 라인 4에 나열된 것 이외의 가격 책정 서비스에 대한 요청이나, 라인 13에 나열된 것 이외의 재고 서비스에 대한 요청은 거부됩니다. 백엔드 서비스로도 전달되지 않죠. 반면 아래 콘솔 트레이스(console trace)에서 볼 수 있는 것처럼 NGINX Plus는 405 (Method Not Allowed) 응답을 전송해 API 클라이언트에게 오류의 정확한 특성을 알립니다. 최소 공개 보안 정책이 필요한 경우에는 error_page 지시문(directive)을 사용합니다. 이러한 응답은 400 (Bad Request)과 같은 less informative 에러처럼 유익하지 않은 오류로 변환할 수 있습니다.

​​

세분화된 엑세스 제어 적용하기

두 가지 예제를 통해 세분화된 액세스 제어 적용하는 법을 설명해 드리겠습니다. 첫 번째는 <NGINX Plus 및 API 게이트웨이로 시작하기> 시리즈에서 소개한 구성을 확장하고, API 클라이언트 화이트리스트를 이용해 API key 인증을 기준으로 특정 API 리소스에 대한 액세스를 제어하는 것입니다. 두 번째 예제는 NGINX Plus가 클라이언트에서 허용하는 HTTP 메소드를 제어하기 위해 커스텀 클레임(custom claim)을 사용해 JWT 인증 메소드를 구현하는 것입니다. 물론, 모든 NGINX Plus 인증 메소드를 이들 예제에 적용할 수 있습니다.

오직 “인프라 클라이언트”만 Warehouse API 인벤토리 서비스의 감사 리소스에 액세스하는 것을 허용하려고 한다고 가정해 보겠습니다. API key 인증이 활성화된 경우, map 블록을 사용해 인프라 클라이언트 이름의 화이트리스트를 작성하고, 이로써 해당 API key가 사용될 때 변수 $is_infrastructure의 값이 1이 되도록 합니다.

​​

Warehouse API의 정의에서, 라인 13부터 19까지에 인벤토리 감사 리소스를 위한 location 블록을 추가합니다. 여기서 if 블록은 인프라 클라이언트만 해당 리소스에 액세스할 수 있다는 것을 보장합니다.

​​

라인 13의 location 지시문(directive)은 = (등호) 수정자를 사용해 감사 리소스에서 완전 일치 매칭(exact match)을 실행합니다. 완전 일치 매칭은 다른 리소스에 사용되는 기본 path‑prefix 정의보다 우선합니다. 이 구성을 적용한 방법~ ‘화이트리스트에 포함되어 있지 않은 클라이언트는 인벤토리 감사 리소스에 액세스할 수 없도록 하는 방법’이 궁금하다면 아래 트레이스(trace)를 참고하세요. 제시된 API key는 client_two에 속합니다.

​​

특정 메소드에 대한 엑세스 제어하기

지금까지 소개해 드린 바와 같이 ‘가격 책정 서비스’는 각각 클라이언트가 특정 품목의 가격을 입수하고 수정할 수 있도록 하는 GET 및 PATCH 메소드를 수용합니다. 이번에는 활용 사례를 확장해 특정 사용자가 발행할 수 있는 메소드를 제어하는 것을 소개해 드리려고 합니다. Warehouse API에 JWT 인증을 활성화하면, 각 클라이언트에 대한 권한은 커스텀 클레임으로서 인코딩됩니다. 가격 책정 데이터를 변경할 수 있는 권한을 가진 관리자들에게 발행된 JWT는 클레임 “admin”:true를 포함하고 있습니다.

​​

api_gateway.conf의 하단에 추가된 이 map 블록은 모든 가능한 HTTP 메소드를 READ 또는 WRITE로 평가하는 새로운 변수인 $request_type으로 결합시킵니다. 아래 스니펫에서는 $request_type 변수를 사용해 요청을 적절한 Warehouse API 정책, /_warehouse_READ 또는 /_warehouse_WRITE로 보냅니다.

라인 9와 14의 rewrite 지시문(directive)은 $request_type 변수를 Warehouse API 정책 이름에 추가합니다. 그 결과, 정책 섹션은 2개로 나뉘게 되며, read 및 write 작업에 서로 다른 정책이 적용됩니다.

/_warehouse_READ 및 /_warehouse_WRITE 정책 모두 클라이언트가 유효한 JWT를 제시하도록 요구합니다. 하지만, WRITE 메소드(POST, PATCH 또는 DELETE)를 사용하는 요청의 경우, JWT에 클레임 “admin”:true (라인 35)이 포함되어야 합니다. 이렇게 각 요청 메소드마다 개별 정책을 갖는 접근 방식은 ‘인증’에만 국한되지 않습니다. 속도 제한, 로깅 및 다른 백엔드로의 라우팅 등 메소드별로 다른 컨트롤을 적용할 수 있습니다. 단, JWT 인증은 NGINX Plus에서만 제공됩니다.

지금까지 백엔드 API 서비스 보호하기 방법으로 ‘특정 요청 메소드 적용 & 세분화된 액세스 제어 적용’에 대해 소개해드렸습니다. 다음 편에서는 ‘요청 사이즈 제어 & 요청 본문 유효성 검증’에 대해 다룰 예정이니, 많은 관심 부탁드려요! 이외 궁금하신 점은 댓글 또는 Contact F5를 통해 문의해 주세요! “Code Connects Us All!” F5 네트웍스 코리아는 귀사의 애플리케이션이 보다 빠르고 스마트하며 안전하게 운영될 수 있도록 항상 최선을 다하겠습니다.

출처: https://blog.naver.com/f5networks_korea/221870501458

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>