Lionel Blog

일부 외부 타사 시스템은 시스템 내부의 마이크로서비스에 접근해야 할 수 있습니다. 예를 들어 온라인 상점의 경우, 외부 추천 서비스가 상점의 상품 카탈로그 정보를 얻기 위해 시스템에 연결해야 할 수 있습니다. 내부 서비스 간의 접근과 비교하여 외부 시스템의 접근은 엄격한 보안 제어가 필요합니다.

사용자로부터의 접근 요청 외에도, 마이크로서비스 애플리케이션 내의 각 마이크로서비스는 서로 많은 접근을 합니다. 애플리케이션 시스템 데이터의 민감도에 따라 시스템 내 마이크로서비스 접근에 대해서도 적절한 보안 제어가 필요합니다.

최근 마이크로서비스 보안 관련 기존 아이디어를 추가로 요약하고 정리하여, 이전 글에서 명확하지 않았던 부분, 예를 들어 서비스 간 인증 및 권한 부여, 서비스 호출 체인에서 사용자 신원 전달 등을 명확히 했습니다. 이 시리즈 블로그에서는 마이크로서비스 보안을 세 부분으로 나누어 체계적으로 설명할 것입니다: 사용자 접근 인증 및 권한 부여, 서비스 간 인증 및 권한 부여, 외부 시스템 접근 제어.

API 게이트웨이와 서비스 메시의 관계는 제가 최근에 계속 고민해왔던 문제이며, 동료 및 커뮤니티 친구들과도 몇 차례 논의했습니다. 이 짧은 글은 둘 사이의 유사점과 마이크로서비스 아키텍처에서 이 둘의 다른 용도를 명확하게 요약합니다.

아키텍처 패턴으로서 마이크로서비스는 복잡한 시스템을 수십에서 수백 개의 작은 서비스로 분할하며, 각 서비스는 독립적인 비즈니스 로직을 구현합니다. 이러한 작은 서비스는 소규모 소프트웨어 엔지니어링 팀이 이해하고 수정하기 쉽고, 언어 및 프레임워크 선택의 유연성을 제공하며, 애플리케이션 개발 및 출시 시간을 단축하고, 다양한 워크로드 및 리소스 요구 사항에 따라 서비스를 독립적으로 확장/축소할 수 있는 이점을 제공합니다. 반면에 애플리케이션이 여러 마이크로서비스 프로세스로 분할되면 프로세스 내 메서드 호출이 프로세스 간 원격 호출로 변경됩니다. 이는 수많은 서비스의 연결, 관리 및 모니터링의 복잡성을 야기합니다. 이 문서에서는 서비스 메시 패턴이 마이크로서비스 아키텍처의 이러한 과제를 어떻게 해결하는지, 그리고 서비스 메시의 대표적인 오픈 소스 프로젝트인 Istio를 소개합니다.

마이크로서비스 아키텍처의 도입은 소규모 개발팀, 개발 주기 단축, 언어 선택의 유연성, 서비스 확장성 향상 등 소프트웨어 애플리케이션에 많은 이점을 가져다주었습니다. 동시에 분산 시스템의 복잡한 문제들도 함께 도입되었습니다. 그중 하나의 과제는 마이크로서비스 아키텍처에서 유연하고 안전하며 효율적인 인증 및 권한 부여 방안을 구현하는 것입니다. 이 글에서는 이 문제에 대해 비교적 완전한 논의를 시도할 것입니다.