API 게이트웨이 뒤의 마이크로 서비스가 액세스 토큰을 확인해야합니까?

API Gateway를 통해서만 외부에서 액세스 할 수있는 많은 마이크로 서비스가 있습니다.

내 API 게이트웨이는 OAuth 리소스로 설정되고 요청을 하나 이상의 마이크로 서비스에 다운 스트림으로 전달하기 전에 토큰을 확인합니다 (서명 확인 등).

범위와 클레임을 확인하기 위해 마이크로 서비스에 토큰이 필요하지만이 서비스에서도 토큰의 유효성을 검사해야합니까?

약간 과잉이지만이 시나리오에 대한 온라인 조언을 찾을 수 없습니다.

API 게이트웨이에서 토큰을 검증하면 충분합니까? 아니면 나중에 다시 확인하는 것이 가장 좋은 방법입니까?

microservices

— fml
소스

내부적으로 게이트웨이를 우회 할 때 이와 동일한 서비스에 액세스 할 수 있습니까?

— Greg Burghardt

I cannot find any advice online about this scenario.프로젝트마다 다른 여러 요소에 의존하기 때문입니다. 아마도 MS 아키텍처라고 주장하는 대부분의 개발에서 필요하지 않을 것입니다. 또한 이러한 아키텍처에는 서비스 대신 (물론 게이트웨이 대신)이를 수행하는 인증 서버가 있어야합니다. 요청 통과를 허용하는 인증 서버입니다.

— Laiv

내부 통화가 게이트웨이를 우회 할 수있는 경우 모든 마이크로 서비스에서 토큰의 유효성을 검사하거나 내부 및 외부의 모든 통화가 게이트웨이를 통과하도록합니다.

개인적으로 나는 내부 전화도 믿지 않을 것입니다. 방화벽 규칙을 통해 트래픽을 제한 할 때까지 게이트웨이를 통과하게하십시오. 누가 누구와 왜 대화하는지 알고 있습니다. 이렇게하면 누군가 네트워크에 침입 한 경우 공격 범위를 제한하는 데 도움이됩니다.

이로 인해 단일 장애 지점이 발생하지만 치명적인 문제가 발생할 경우 서버 부하 분산 서버와 장애 조치 서버를 보유함으로써 이러한 위험을 완화 할 수 있습니다.

반면에 모든 서비스가 토큰의 유효성을 검사하고 유효성 검사 프로세스에 대한 내용이 변경되면 N + 1 서비스가 업데이트됩니다.

— 그렉 버거 트
소스

"내부 트래픽도 신뢰할 수 없습니다"라는 주장을 들었습니다. 그러나 인트라넷의 소수의 사용자에게 응용 프로그램을 노출시키는 것은 동일한 응용 프로그램을 공용 인터넷에 노출시키는 것과는 거리가 멀습니다. 스피커 자석과 사이클로트론의 차이와 본질적으로 동일합니다.

— Robert Harvey

@RobertHarvey : "내부 트래픽을 신뢰하지 않는다"는 말의 정당성은 침입이 발생할 경우 네트워크를 차단하는 합법적 인 트래픽이 아니라고 생각합니다. 특히 시스템이 PII, 건강, 재무 또는 민감한 정보를 처리하는 경우. 누군가가 침입하면 다른 사람들과 대화 할 수있는 능력이 제한됩니다.

— Greg Burghardt

누군가 시스템에 들어간 경우 토큰 유효성 검사는 문제의 적은 부분이됩니다. 신뢰할 수있는 네트워크 내에서 토큰의 유효성을 검사해야하는지 (외국인이 액세스 할 수없는) 여부는 우리가 수행하는 유효성 검사의 종류와 유효성 검사를 다시 수행하지 않는 경우에 따라 달라질 수 있습니다. 예를 들어 성능. 당신의 추론으로 돌아갑니다. 개인 네트워크에서 TLS를 구현 하시겠습니까? 서로 옆에서 실행되는 두 구성 요소 간의 통신을 암호화 하시겠습니까? 가능한 대답은에 달려 있습니다.

— Laiv