Medium - API security in a microservices architecture
in Trend
Trend 파악을 위한 Medium 기고문 포스팅 - 마이크로서비스 구조에서의 API 보안
Monolithic VS Microservices Architecture
오랜기간 동안 소프트웨어를 개발한다는 말은 모든 기능을 다 가지고 있는 거대한 하나의 응용프로그램을 만드는 것이었습니다. 큰 문제점은 이렇게 완전히 통일된 접근(monolithic approach)는 새로운 기능을 배포할 때마다 응용프로그램 전체의 안전성에 영향을 줄 수 있다는 것입니다. 또한 응용프로그램과 자체 사용자 기반이 커질 수록 확장하는 방법이 전체 응용프로그램과 인프라 전체를 확장하는 방법 뿐이라는 것입니다. 반면에 마이크로 서비스는 작은 응용프로그램들의 집합으로 각 응용프로그램들 각각의 환경에서 동작하며 서로 API를 통해 통신합니다. 마이크로서비스의 가장 큰 장접은 각 응용프로그램이 자체의 개발 사이클을 가질 수 있어서 확장이 필요할 경우 해당 구조만 확장하면 되기 때문에 매우 편한 구조라고 할 수 있습니다.
Users and Permissions
모노리틱 응용프로그램에서 사용자와 권한 관리는 시스템의 다른 모든 기능을 가지고 있습니다. 그래서 사용자가 특정 역할이나 권한을 가지고 있는지 확인하는 것이 쉽습니다. 반면에 마이크로 서비스는 각 개별 서비스가 현재 사용자가 어떤 역할인지 알지 못합니다. 모든 마이크로서비스는 중앙 인증 웹 서비스를 이용해 사용자의 유효성을 검사해야 하고 이를 통해 현재 사용자가 정확한 권한을 가지고 있는지 검사할 수 있습니다.
JSON Web Tokens
JSON 웹토큰은 접근 토큰을 만드는 JSON을 기반으로한 표준입니다. JWT(JSON Web Token)는 payload와 헤더, 서명을 가지고 있습니다. 퍼블릭 시그니쳐에 기반해서 여러분은 JSON payload 부분을 읽을 수 있습니다. 그러나 데이터를 변경하려고 할 때 JWT는 더 이상 유효한 데이터를 가질 수 없습니다. 서버에서 JWT의 유효성을 검사하려고 하는 것도 실패할 것입니다. 모든 마이크로서비스들은 주어진 액션을 수행하는데 필요한 권한을 알아야합니다. 그래야 다른 웹서비스에 대한 유효성 검사를 할 필요없이 전달받은 JWT로 데이터를 읽을 수 있습니다.
API Gateway
모든 API 요청을 일치하는 보안된 웹서비스로 라우팅 시켜주기 위해 public accessible API 게이트웨이를 사용합니다. 만약 JWT payload가 외부 네트워크에 노출되는 것을 막고싶다면 API 게이트웨이가 유니크 API 키를 생성하도록 할 수 있습니다. 사용자가 특정 API 키로 리퀘스트를 요청하고 API 게이트웨이는 알맞는 JWT를 찾아보고 해당 리퀘스트를 마이크로서비스로 전달합니다. 이 방식에서는 사용자의 토큰 속에는 절대로 접속 정보가 남지 않습니다.
Summary
- JWT를 이용한 웹 API 보안 방법
- 마이크로서비스와 모니리틱 서비스의 대략적인 비교
- 마이크로서비스는 유연하며 확장성이 좋다.
