ASP.NET Core의 목적 계층 및 다중 테넌트

IDataProtector는 또한 암묵적으로 IDataProtectionProvider 역할을 하기 때문에 서로 연결하여 사용할 수 있습니다. 이러한 의미에서는 provider.CreateProtector([ "purpose1", "purpose2" ])가 provider.CreateProtector("purpose1").CreateProtector("purpose2")와 동일합니다.

이렇게 하면 데이터 보호 시스템을 통해 몇 가지 흥미로운 계층적 관계를 사용할 수 있습니다. Contoso.Messaging.SecureMessage의 이전 예제에서 SecureMessage 구성 요소는 한 번 선행 호출 provider.CreateProtector("Contoso.Messaging.SecureMessage") 하고 결과를 프라이빗 _myProvider 필드에 캐시할 수 있습니다. 이후 보호기는 호출을 _myProvider.CreateProtector("User: username")통해 만들 수 있으며 이러한 보호기는 개별 메시지를 보호하는 데 사용됩니다.

이것은 뒤집을 수도 있습니다. 여러 테넌트를 호스트하는 단일 논리 애플리케이션(CMS는 적절해 보임)을 고려하고 각 테넌트는 자체 인증 및 상태 관리 시스템으로 구성할 수 있습니다. Umbrella 애플리케이션에는 단일 주 공급자가 있으며, provider.CreateProtector("Tenant 1") 및 provider.CreateProtector("Tenant 2")를 호출하여 각 테넌트에 데이터 보호 시스템의 자체 격리된 조각을 제공합니다. 그런 다음 테넌트는 자신의 요구에 따라 고유한 개별 보호기를 파생시킬 수 있지만 아무리 열심히 노력하더라도 시스템의 다른 테넌트와 충돌하는 보호기를 만들 수는 없습니다. 그래픽으로 아래와 같이 표시됩니다.

경고

이 경우 우산 애플리케이션은 개별 테넌트에서 사용할 수 있는 API를 제어하고 테넌트는 서버에서 임의 코드를 실행할 수 없다고 가정합니다. 테넌트가 임의의 코드를 실행할 수 있는 경우 프라이빗 리플렉션을 수행하여 격리 보장을 중단하거나 마스터 키 지정 자료를 직접 읽고 원하는 하위 키를 파생시킬 수 있습니다.

데이터 보호 시스템은 실제로 기본 기본 구성에서 일종의 다중 테넌트를 사용합니다. 기본적으로 마스터 키 지정 자료는 작업자 프로세스 계정의 사용자 프로필 폴더(또는 IIS 애플리케이션 풀 ID의 경우 레지스트리)에 저장됩니다. 그러나 실제로는 단일 계정을 사용하여 여러 애플리케이션을 실행하는 것이 매우 일반적이므로 이러한 모든 애플리케이션은 마스터 키 지정 자료를 공유하게 됩니다. 이 문제를 해결하기 위해 데이터 보호 시스템은 애플리케이션별 고유 식별자를 전체 용도 체인의 첫 번째 요소로 자동으로 삽입합니다. 이 암시적 용도는 각 애플리케이션을 시스템 내의 고유한 테넌트로 효과적으로 처리하여 개별 애플리케이션을 서로 격리 하는 역할을 하며 보호기 생성 프로세스는 위의 이미지와 동일하게 보입니다.