Azure의 SaaS 워크로드에 대한 ID 및 액세스 관리
애플리케이션 ID는 데이터를 보호하기 위한 첫 번째 방어선 역할을 하므로 SaaS 워크로드에 중요한 영역입니다. 프로젝트 후반부까지 간과되는 경우가 많지만 애플리케이션의 다른 요소에 대한 많은 결정은 견고한 ID 전략에 따라 달라집니다. 고객의 데이터를 보호하는 데 도움이 되는 ID의 중요성을 과소평가하지 마세요.
SaaS 워크로드의 컨텍스트에는 두 가지 유형의 ID가 있습니다.
CIAM(고객 ID 및 액세스 관리)라고도 하는 애플리케이션 ID를 사용하면 최종 사용자가 SaaS 애플리케이션을 인증하고 사용할 수 있습니다. 애플리케이션 ID 공급자에 사용자를 로그인하는 두 가지 주요 방법이 있습니다.
페더레이션 ID. 사용자는 다른 ID 공급자가 유지 관리하는 기존 자격 증명으로 로그인합니다. 해당 공급자는 Google, Facebook 또는 LinkedIn과 같은 소셜 ID 공급자이거나 Microsoft Entra 또는 Okta와 같이 고객이 사용하는 엔터프라이즈 ID 공급자일 수 있습니다. 사용자 계정의 유지 관리는 페더레이션 ID 공급자의 책임입니다.
로컬 ID입니다. 사용자는 애플리케이션에 대한 계정만 만듭니다. 계정은 사용자 이름 및 암호, 암호 또는 기타 인증 방법으로 보호됩니다. 사용자의 계정 유지 관리는 사용자의 책임입니다.
엔터프라이즈 ID 는 내부 사용자 및 워크로드를 비즈니스 생산성 도구, 내부 도구 또는 서비스 및 Azure 서비스에 인증하는 데 사용되는 ID 솔루션입니다. 내부 사용자 및 워크로드에 대한 엔터프라이즈 ID 솔루션을 사용하여 비즈니스 생산성 도구, 내부 도구 또는 서비스 및 Azure 서비스에 인증합니다.
SE:05 ID 및 액세스 관리를 참조하세요.
애플리케이션 및 엔터프라이즈 ID는 다양한 용도로 사용되며 다른 ID 공급자를 사용할 수 있습니다. 이 문서에서는 두 형식이 모두 SaaS 워크로드 환경에 있을 가능성이 높지만 애플리케이션 ID에 대한 디자인 고려 사항에 중점을 둡니다.
ID 관리에는 인증(사용자 ID 확인) 및 권한 부여(ID에 따라 사용 권한 부여)의 두 가지 관련 문제가 포함됩니다. 이 문서의 처음 세 섹션은 SaaS 인증에 중점을 줍니다. 마지막 섹션에서는 SaaS 공급자에 대한 권한 부여 고려 사항을 다룹니다.
다중 테넌트 애플리케이션의 ID
다중 테넌트 애플리케이션에서 테넌트 데이터를 별도로 유지하는 것이 중요합니다. 이러한 구분은 효과적인 사용자 인증 및 권한 부여 선택에 의해 좌우됩니다. 또한 테넌시 모델 선택은 ID 공급자에 대한 의사 결정에 크게 영향을 줍니다. ID의 우선 순위를 기본 경계로 지정합니다.
디자인 고려 사항
애플리케이션의 테넌트 및 배포 모델을 이해합니다. ID 전략에 영향을 주는 미묘한 차이가 있을 수 있습니다. 예를 들어 배포 스탬프 패턴에는 각 스탬프에 ID 공급자가 필요하다는 오해가 있습니다. 대부분의 ID 공급자의 경우 대체 격리 모델을 사용할 수 있습니다.
다중 테넌트에 대한 ID 공급자를 선택하는 경우 실패의 영향을 평가합니다. 잘못된 구성으로 모든 테넌트에 대한 전체 애플리케이션이 중단될 수 있습니다. 잠재적인 영향 반경의 위험에 대비하여 오버헤드 비용을 측정합니다.
고객의 Azure 환경에 솔루션을 배포하고 대신 관리하는 경우 해당 엔터프라이즈 ID 공급자와 통합해야 할 수 있습니다. 이러한 측면을 명확하게 이해하세요.
- 애플리케이션 테넌트와 상호 작용할 때 사용자 유형 및 액세스에 필요합니다. 예를 들어 사용자 A는 테넌트 1에 로그인하기 위해 액세스만 필요할 수 있지만 사용자 B는 테넌트 1과 테넌트 2에 모두 로그인하기 위해 액세스 권한이 필요할 수 있습니다.
- ID 공급자에 적용되는 경우 데이터 보존 규정 준수 경우에 따라 ID 공급자가 저장한 데이터에는 규정이 적용될 수 있습니다. 많은 ID 공급자는 이 시나리오에 대한 특정 지침과 기능을 제공합니다. 이 시나리오가 사용자와 관련이 있는지 평가하고 규정 준수를 보장하기 위해 필요한 단계를 수행합니다.
디자인 권장 사항
| 추천 | 장점 |
|---|---|
| 여러 테넌트에 대한 솔루션을 분할하기 위한 ID 공급자의 모범 사례 및 지침을 따릅니다. | 테넌트 격리는 보안 및 규정 준수 목표를 달성하는 데 도움이 됩니다. |
| 동일한 사용자에 대해 여러 계정이 없으면 안 됩니다. 사용자는 여러 테넌트에 액세스해야 하는 경우에도 하나의 자격 증명 집합이 있는 단일 계정이 있어야 합니다. 동일한 사용자에 대해 여러 계정을 만드는 대신 필요에 따라 각 테넌트에 대한 액세스 권한을 부여합니다. | 동일한 사용자에 대해 여러 계정을 만들면 보안 위험이 증가하고 동일한 소프트웨어에 대해 여러 사용자 이름 및 암호를 기억해야 하는 사용자를 혼동할 수 있습니다. |
| 데이터 상주를 고려할 때 사용자 데이터를 별도의 위치에 저장하는 방법을 계획합니다. 다른 지역에서 사용자를 위해 별도의 배포 스탬프를 배포하는 경우 별도의 ID 공급자가 필요할 수도 있습니다. 필요한 경우 로그인을 위해 올바른 지역으로 보낼 수 있도록 사용자의 데이터가 저장되는 위치를 식별하는 방법이 있는지 확인합니다. |
사용자를 해당 위치에 적합한 로그인 환경으로 라우팅하여 규정 준수 요구 사항을 지원하고 사용자 환경을 향상시킬 수 있습니다. |
ID 공급자 선택
각 ID 공급자는 고유한 기능, 제한 사항, 가격 책정 모델 및 구현 패턴을 제공합니다. Microsoft Entra 및 Okta는 IDaaS(ID as a Service) 옵션으로 널리 사용됩니다. Keycloak 및 Authentik와 같은 다른 오픈 소스 공급자도 있습니다.
디자인 고려 사항
ID 요구 사항을 문서화합니다. 먼저 애플리케이션에 지금 필요하고 나중에 필요한 기능을 나열합니다. 고려해야 할 일반적인 기능은 다음과 같습니다.
-
- 페더레이션 ID 공급자는 고객의 ID 솔루션과 통합할 수 있도록 지원합니다. 이 기능을 사용하면 새 ID를 만들지 않도록 할 수 있습니다.
- 브랜딩을 유지하기 위해 모양과 느낌을 수정하는 사용자 지정 가능한 로그인/등록 흐름입니다. 이 기능은 로그인/등록 프로세스에 사용자 지정 비즈니스 논리를 삽입하는 기능도 제공합니다.
- 테넌트 데이터를 고유 사일로로 분리하여 테넌트 격리를 유지합니다.
- 보안 관리를 위해 로그인 로그를 유지하거나 내보내도록 지원을 감사합니다.
Important
ID 솔루션의 비용을 평가할 때 계획된 사용자 증가를 고려합니다. 솔루션은 장기적으로 비용 효과적이거나 확장성이 유지되지 않을 수 있지만 지금은 유용할 수 있습니다. 필요한 경우 사용할 수 있는 마이그레이션 계획을 갖습니다.
예를 들어 솔루션은 500명의 사용자에게는 저렴하지만 500만 명에게는 지속 가능하지 않을 수 있습니다. 최소한의 설정이 필요하고 사용자에게 친숙하고 마이그레이션하기 쉬운 경우 비용 크기 조정이 다른 솔루션으로의 전환을 정당화할 때까지 올바른 선택이 될 수 있습니다.
ID 공급자 기능을 철저히 조사합니다. ID 솔루션이 필요한 기능 목록과 일치하는지 확인합니다. 현재 페더레이션 ID와 같은 복잡한 시나리오가 필요하지 않더라도 향후 요구 사항을 고려합니다. B2B(Business-to-Business) SaaS 솔루션의 경우 페더레이션 ID가 결국 필요할 수 있습니다.
관리 오버헤드를 고려합니다. ID 공급자마다 다양한 수준의 관리 오버헤드가 필요합니다. 잘 알려진 IDaaS 솔루션은 일반적으로 호스팅, 유지 관리 및 보안을 처리하기 때문에 오버헤드가 적습니다. 그러나 솔루션이 특수 요구 사항에 더 적합한 경우 오픈 소스 솔루션의 추가 오버헤드는 가치가 있을 수 있습니다.
디자인 권장 사항
| 추천 | 장점 |
|---|---|
| 고유한 ID 솔루션을 만들지 마세요. ID는 매우 특수한 영역이며 ID 솔루션을 만드는 것은 복잡하고 비용이 많이 듭니다. 안전하고 신뢰할 수 있는 ID 솔루션을 만드는 것은 어렵습니다. | 자체 공급자를 만드는 문제를 방지하고 솔루션의 보안, 안정성 및 운영 효율성을 향상시킵니다. |
| ID 공급자가 제공하는 기능의 기능 매트릭스를 만들고 ID 요구 사항에 맞게 매핑합니다. | 제한된 ID 기능 집합에 의해 제한되지 않고 진화하는 기능을 보장합니다. |
| 오픈 소스 솔루션보다 IDaaS 옵션을 선호합니다. 오픈 소스 솔루션을 직접 호스팅하면 상당한 운영 오버헤드 및 보안 위험이 발생합니다. 그러나 공급자가 충족할 수 없는 규정 준수, 데이터 보존 또는 안정성에 대한 특정 요구 사항을 충족하도록 해당 옵션을 선택할 수 있습니다. 자세한 내용은 IDaaS ID 공급자를 참조 하세요. |
IDaaS ID 공급자를 사용하면 불필요한 복잡성을 방지하고 핵심 비즈니스에 노력을 집중할 수 있습니다. |
페더레이션 ID
SSO(Single Sign-On)라고도 하는 페더레이션 ID를 사용하면 사용자가 이미 다른 곳에서 사용하는 자격 증명으로 로그인할 수 있습니다. 애플리케이션 ID 공급자와 고객의 기존 ID 공급자 간에 트러스트 관계를 설정하여 페더레이션 ID를 사용하도록 설정합니다. 페더레이션 ID는 특히 B2B에서 SaaS 솔루션에 대한 일반적인 요구 사항입니다. 고객이 회사 자격 증명을 사용하는 직원을 선호하기 때문입니다. 중앙 집중식 ID 관리 및 자동 수명 주기 관리와 같은 B2B 솔루션에 대한 몇 가지 이점을 제공합니다. B2C SaaS 제품에서 소셜 ID 공급자와 통합하면 사용자가 기존 자격 증명으로 로그인할 수 있습니다.
절충: 복잡성 및 운영 효율성. 페더레이션 ID 공급자를 사용하여 사용자의 ID를 관리하는 복잡성을 오프로드합니다. 그러나 다른 ID 공급자와 통합하는 데 드는 비용을 부담합니다. 운영 활동에 집중할 위치를 결정합니다.
페더레이션 ID 구현은 처음에는 간단하지만 지원되는 ID 공급자 수가 증가함에 따라 더 복잡해집니다. 특히 각 고객이 고유한 ID 공급자를 사용하는 경우 신중한 계획이 필수적입니다. 동일한 ID 공급자를 사용하는 경우에도 특정 구성 세부 정보 때문에 각 고객에게 고유한 신뢰 관계가 필요한 경우가 많습니다.
이 이미지는 애플리케이션, 애플리케이션 ID 공급자 및 ID 페더레이션을 사용하여 구현하도록 선택할 수 있는 다운스트림 ID 공급자 간의 관계를 보여 줍니다.
디자인 고려 사항
지원해야 하는 ID 공급자의 유형 및 수를 예측합니다. 정적 수의 소셜 ID 공급자가 필요하거나 각 고객에 대해 고유한 페더레이션 ID 공급자가 필요할 수 있습니다. 고객이 OIDC(OpenID Connect), SAML(Security Assertion Markup Language) 또는 둘 다 통합에 사용할지 여부를 알아야 합니다.
로그인 환경을 매핑합니다. 등록 및 로그인 프로세스의 사용자 흐름을 시각화합니다. 사용자 흐름 디자인을 변경할 수 있는 특별한 요구 사항을 기록해 둡니다. 예시:
사용자 지정 브랜딩. 고객당 흰색 레이블 지정 또는 사용자 지정 로그인 도메인입니다.
사용자 지정 정보입니다. 등록 또는 로그인 중에 여러 테넌트에 액세스할 수 있는 사용자의 테넌트 선택과 같은 추가 사용자 정보 수집
ID 공급자 선택. 많은 페더레이션 ID 공급자가 신뢰하는 단일 애플리케이션 ID 공급자를 사용하는 경우 공급자를 선택하는 방법을 결정합니다. 이 선택은 단추를 통해 수동으로 또는 알려진 사용자 정보에 따라 자동으로 수행될 수 있습니다. 공급자 수가 늘어나면 자동 선택이 더 실용화됩니다. 이 기능을 홈 영역 검색이라고 합니다.
디자인 권장 사항
| 추천 | 장점 |
|---|---|
| 필요한 페더레이션 ID 공급자 수를 수용하도록 확장할 수 있는 ID 공급자를 선택합니다. 초과할 수 없는 공급자의 하드 한도에 유의하세요. |
성장함에 따라 ID 솔루션의 크기를 조정할 수 있는지 확인합니다. |
| 각 페더레이션 ID 공급자의 온보딩을 계획하고 가능한 한 프로세스를 자동화합니다. 조직과 고객 간의 이러한 공동 작업에서는 일반적으로 OIDC 또는 SAML 프로토콜을 통해 트러스트 관계를 설정하기 위해 정보를 교환하는 작업이 포함됩니다. |
ID 통합은 사용자와 고객 모두에게 시간과 노력이 걸릴 수 있습니다. 프로세스를 계획하면 운영 효율성을 향상시킬 수 있습니다. |
| 가격 책정 및 비즈니스 모델에서 페더레이션 ID의 복잡성과 비용을 반영합니다. 고객이 자신의 ID 공급자를 사용할 수 있도록 허용하면 여러 페더레이션 ID 트러스트 관계를 유지하는 오버헤드로 인해 운영 복잡성과 비용이 증가합니다. 기업이 페더레이션 로그인을 가능하게 하는 더 높은 계층에 대한 비용을 지불하는 것이 SaaS 솔루션에서 일반적입니다. |
고객의 ID 공급자와 페더레이션하는 것은 SaaS 솔루션에서 숨겨진 비용이 될 수 있습니다. 계획하여 구현하는 동안 예기치 않은 비용을 방지할 수 있습니다. |
| 로그인 흐름 중에 사용자의 ID 공급자를 선택하는 방법을 계획합니다. 홈 영역 검색을 사용하는 것이 좋습니다. Microsoft Entra ID는 기본 제공 홈 영역 검색을 제공합니다. |
고객 환경을 간소화하고 사용자가 올바른 로그인 프로세스로 이동되도록 합니다. |
Authorization
사용자 권한 부여는 여러 테넌트에 대한 데이터를 저장하는 SaaS 애플리케이션에 매우 중요합니다. 사용자가 실수로 다른 테넌트의 데이터에 액세스하지 않고 데이터에만 액세스할 수 있는 권한을 부여하는 방법을 명확하게 정의합니다. 또한 테넌트 내에서 세분화된 권한 부여를 제공하여 사용자가 다른 데이터에 대한 업데이트 또는 액세스를 제한하면서 특정 정보를 읽거나 액세스할 수 있도록 합니다.
디자인 고려 사항
사용 사례에 적합한 권한 부여 모델을 선택합니다. 다음과 같은 두 가지 기본 형식이 있습니다.
- 역할 기반 권한 부여. 사용자에게는 역할 또는 그룹이 할당되고 특정 기능은 특정 역할로 제한됩니다. 예를 들어 관리자는 모든 작업을 수행할 수 있지만 다른 역할의 사용자는 권한이 제한됩니다.
- 리소스 기반 권한 부여. 각 리소스에는 고유한 사용 권한 집합이 있습니다. 사용자는 한 리소스에 대한 관리자일 수 있지만 다른 리소스에 대한 액세스 권한은 없습니다.
권한 부여 데이터를 저장할 위치를 결정합니다. 애플리케이션에 대한 권한 부여 데이터는 다음 위치에 저장할 수 있습니다.
- ID 공급자입니다. 기본 제공 그룹 또는 역할을 활용하여 권한을 애플리케이션에 발급된 토큰의 클레임으로 표시합니다. 그러면 애플리케이션에서 이러한 토큰 클레임을 사용하여 권한 부여 규칙을 적용할 수 있습니다.
- 애플리케이션 고유한 권한 부여 논리를 개발하고 사용자 권한을 데이터베이스 또는 유사한 시스템에 저장하여 세분화된 역할 기반 또는 리소스 수준 권한 부여 제어를 허용합니다.
절충: 복잡성, 유연성 및 보안. ID 공급자에 권한 부여 데이터를 저장하고 토큰 클레임을 통해 표시하는 것은 일반적으로 사용자 고유의 권한 부여 시스템을 관리하는 것보다 더 간단합니다. 그러나 클레임 기반 권한 부여는 유연성을 제한하며, 토큰이 재발행될 때만 클레임이 새로 고쳐지도록 허용해야 하므로 변경된 권한 적용이 지연될 수 있습니다.위임된 관리의 영향을 평가합니다. 대부분의 SaaS 애플리케이션, 특히 B2B 애플리케이션에서는 역할 및 권한 관리가 고객에게 위임됩니다. 이 기능이 없으면 고객이 사용자의 권한을 자주 변경하는 경우 관리 오버헤드가 증가할 수 있습니다.
다중 테넌트 액세스를 평가합니다. 일부 시스템에서는 단일 사용자가 여러 테넌트에서 데이터에 액세스해야 할 수 있습니다. 예를 들어 컨설턴트는 여러 테넌트에서 데이터에 액세스해야 할 수 있습니다. 고객이 이러한 사용자에게 액세스 권한을 부여하는 방법과 로그인 흐름이 테넌트 간 선택 및 전환을 지원하는 방법을 계획합니다.
디자인 권장 사항
| 추천 | 장점 |
|---|---|
| 해당 액세스가 명시적으로 허용되지 않는 한 사용자가 테넌트 경계를 넘어 데이터에 액세스하지 못하도록 합니다. | 다른 테넌트의 데이터에 대한 무단 액세스(우발적 액세스)는 주요 보안 인시던트로 간주되어 플랫폼에서 고객의 신뢰를 약화시킬 수 있습니다. 불필요한 액세스를 차단하면 이러한 상황을 방지하는 데 도움이 됩니다. |
| 데이터가 정적이고 자주 변경되지 않는 경우 ID 공급자에 저장합니다. 사용자가 소프트웨어를 사용하는 동안 자주 변경해야 하는 경우 애플리케이션에 권한 부여 데이터를 저장합니다. | 권한 부여 데이터에 가장 적합한 데이터 저장소를 선택하면 운영 효율성이 향상되고 확장성 요구 사항을 충족하는 데 도움이 됩니다. |
| 고객에게 권한 관리를 위임하는 경우 사용 권한을 관리하는 명확한 방법을 제공합니다. 예를 들어 사용자 권한을 변경하기 위해 테넌트 관리자만 액세스할 수 있는 웹 포털을 만듭니다. | 고객에게 더 많은 제어를 제공하고 지원 팀에서 불필요한 운영 부담을 방지합니다. |
추가 리소스
다중 테넌시는 SaaS 워크로드를 디자인하기 위한 핵심 비즈니스 방법론입니다. 다음 문서에서는 ID 및 액세스 관리에 대한 자세한 정보를 제공합니다.
다음 단계
컴퓨팅 호스팅 모델 선택, 운영 측면 및 서비스 수준 계약 및 목표를 충족하는 데 도움이 되도록 기술 옵션을 최적화하는 방법에 대해 알아봅니다.