마이크로 서비스는 사용자 여야합니까?


13

우리는 마이크로 서비스 아키텍처에서 사용자에게 권한을 부여하는 가장 좋은 방법을 결정하려고 노력하고 있으며 마이크로 서비스는 제한된 권한을 갖습니다. 우리 아키텍처는 중앙 인증 서비스를 사용하여 JWT 토큰 발행을 처리합니다.

우리는 다음과 같은 요구 사항이 있습니다.

  1. 사용자는 특정 역할을 수행하도록 제한되어야합니다. 예를 들어, 사용자는 자신이 소유 한 컨텐츠 만 작성 / 수정 / 읽을 수 있어야합니다.

  2. 마이크로 서비스는 필요한 권한으로 만 제한해야합니다. 예를 들어 다른 서비스에서 데이터를 읽기만하면되는 마이크로 서비스는 해당 서비스에 데이터를 쓰는 것이 명시 적으로 금지되어야합니다.

예를 들어, 사용자가 이미지 저장소 서비스에 사진을 업로드 할 수있는 시스템이 있다고 가정합니다. 위치에 자동으로 태그를 지정하는 태그 지정 서비스가 있습니다. 사용자는 자신의 사진 만 CRUD 할 수 있습니다. 태깅 서비스는 이미지 저장소 서비스에서 이미지를 읽을 수 있지만 수정 / 삭제할 수 없습니다.

JWT 토큰을 사용하여 위를 달성하는 좋은 방법은 무엇입니까? 우리가 논의한 몇 가지 솔루션은 다음과 같습니다.

  1. 이미지 저장소 서비스는 2 개의 API를 제공합니다. 하나는 외부에서 사용 가능하고 (사용자에게 CRUD 액세스 권한을 제공) 하나는 내부적으로 사용 가능합니다 (내부 읽기 전용 액세스 제공). 융통성이없는 것 같습니다-다른 내부 서비스가 모든 이미지 (예 : 명시 적 이미지를 자동으로 삭제하는)에 대한 읽기 / 쓰기 액세스가 필요한 경우 어떻게해야합니까?

  2. 사용자의 JWT에서 두 가지 권한을 설정했습니다. 하나는 CRUD_OwnImages이고 다른 하나는 READ_ForAnalysis입니다. 태깅 서비스는 사용자에게 READ_ForAnalysis 권한이 있는지 확인하고, 그렇다면 적절한 요청을합니다. 사용자 자신의 이미지에서 CRUD 작업을 위해 CRUD_OwnImages가 있는지 확인하는 또 다른 마이크로 서비스가 있습니다. 이로 인해 각 마이크로 서비스에 대한 책임이 사용자에게 필요한 조치로 제한됩니다. 이미지 저장소는이 접근 방식으로 각 마이크로 서비스를 제한 할 방법이 없으므로 잠재적으로 결함이 있고 오류가 발생하기 쉽습니다.

  3. READ_ForAnalysis를 권한으로 사용하여 태그 지정 마이크로 서비스에 자체 사용자를 제공합니다. 그런 다음 태깅 서비스가 이미지 저장소에서 이미지를 요청하면 해당 이미지에 액세스 할 수는 있지만 이미지를 수정할 수는 없습니다. 사용자의 사용자에게는 CRUD_OwnImages 권한 만 있으므로 프런트 엔드에서 자신의 이미지 만 검색하고 액세스 할 수 있습니다. 다른 서비스가 모든 데이터에 CRUD를 필요로하는 경우 CRUD_AllData 또는 이와 유사한 것을 제공 할 수 있습니다. 우리는 각 서비스가 현재 여러 데이터에 복제되는 논리가 아닌 자체 데이터에 대한 책임이 있기 때문에이 접근 방식을 좋아하지만, 서비스에 사용자 권한과 마이크로 서비스 권한이 모두 필요한 경우 어떻게해야합니까? 두 개의 JWT 토큰 (사용자 및 마이크로 서비스 모두)을 안전하게 보낼 수 있습니까? 권한을 안전하게 결합하여 전송할 수있는 방법이 있습니까? 예 :

사용자 정보가 더 다운 스트림 (2 개 또는 3 개의 마이크로 서비스) 떨어져 필요할 경우 문제가 악화됩니다. 우리는 필요한 조치로 자신을 제한하고 명시 적으로 표현하지 않는 것이 개별 마이크로 서비스에 달려 있다고 가정합니까?


1
이러한 마이크로 서비스의 유일한 개발자입니까, 아니면 다른 회사 / 조직 / 부서 (예 : 보안 경계가있는 것)도 시스템을 대상으로하는 마이크로 서비스를 작성합니까?
Robert Harvey

1
시스템을 대상으로하는 다른 서비스가있을 가능성이 매우 높으며 그러한 경우를 위해 설계하려고합니다.
awr

답변:


6

일반적으로 가능한 많은 작업을 실제 사람과 연결해야합니다. 사람들이 올바르게 인증하도록하고 일관된 단일 인증 전략을 추진하며 응집력있는 감사 추적을 제공하는 데 중요한 부분입니다.

그리고 일반적으로 마이크로 서비스에 대한 세 가지 종류의 시나리오가 있습니다.

1. 사용자가 들어 와서 사진을 업로드하고 태그를 지정해야합니다. 큰. 사진 서비스는 JWT를 따라 태깅 서비스로 전달할 수 있으며 (또는 의존 방향에 따라 그 반대도 가능) 하위 작업을 수행 할 권한이없는 사용자는 적절한 조치를 취합니다 (태그없이 사진을 업로드 할 수 있음) , 아마도 오류를 반환하거나 다른 것).

2. 사용자가 들어 와서 사진을 업로드하며 태그가 필요하지만 지금은 아닙니다. 멋있는. 이제 정상적으로 사진을 처리합니다. 나중에 태깅이 발생하면 (이벤트 / 메시지 처리, CQRS 스타일 명령 처리, 일부 주기적 작업 처리 등) 태깅 서비스는 사용자를 가장 한 다음 (공인 비밀을 사용하여 인증에서 사용자 정의 JWT를 요청함으로써) 원래 요청자를 대신하여 하위 작업 (모든 권한 및 제한) 이 방법에는 문제가 발생하지 않으면 사용자에게 오류를 제공하기 어려운 비동기 작업의 일반적인 문제가 있지만 교차 서비스 작업에이 패턴을 사용하는 경우 이미 해결 한 것입니다.

3. 일부 하위 시스템은 사용자의 상황을 벗어난 작업을 수행해야합니다. 오래된 이미지를 보관하는 야간 작업이있을 수 있습니다. 태그를 통합해야 할 수도 있습니다 ...이 경우, 각 액터마다 권한이 제한되고 감사 내역에 대한 고유 한 ID를 가진 자체 의사 사용자가 필요합니다.

사용할 시나리오는 시나리오, 요구 사항 및 위험 허용 범위에 따라 다릅니다. 물론 이것들은 불완전한 광범위한 스트로크 일반화입니다.

그러나 일반적으로 마이크로 서비스 자체는 가능한 경우 사용자가 아니어야합니다.


1
첫 단락과 마지막 단락이 모순되지 않습니까?
Robert Harvey

1
아니? 작업은 사용자에게 연결되어야합니다. 마이크로 서비스 자체는 사용자가 아닙니다. 명확히하겠습니다.
Telastyn

1
나는 제안 한 문제에 대한 해결책을 발견했다. 액세스 토큰에서 어떤 엔드 포인트에 액세스 할 수 있는지 지정하는 각 마이크로 서비스의 범위를 정의하십시오. 또한 사용자의 JWT ID 토큰을 다른 헤더로 전달하십시오. 이런 식으로 마이크로 서비스와 사용자를 모두 제한 할 수 있습니다 (심층 방어). manning.com/books/microservices-in-net-core의
awr

시나리오 3은 흥미로운 것으로 사용자가 마이크로 서비스가되어야한다고 결정했습니다. 그러나 규칙보다는 예외가 될 수 있습니다.
awr
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.