정체성과 그 너머로- 한 건축가의 관점

  • 아티클

이 문서에서는 Microsoft의 수석 기술 설계자인 Alex Shteynberg가 Microsoft 365 및 기타 Microsoft 클라우드 서비스를 채택하는 엔터프라이즈 조직을 위한 최고의 디자인 전략에 대해 설명합니다.

만든 이 정보

알렉스 슈테인버그 사진.

저는 뉴욕 Microsoft 기술 센터의 수석 기술 설계자입니다. 저는 주로 대규모 고객 및 복잡한 요구 사항과 함께 일합니다. 내 관점과 의견은 이러한 상호 작용을 기반으로하며 모든 상황에 적용되지 않을 수 있습니다. 그러나 제 경험상 가장 복잡한 과제를 가진 고객을 도울 수 있다면 모든 고객을 도울 수 있습니다.

저는 일반적으로 매년 100명 이상의 고객과 함께 일합니다. 모든 organization 고유한 특성을 가지고 있지만 추세와 공통점을 보는 것은 흥미롭습니다. 예를 들어 한 가지 추세는 많은 고객에게 업계 간 관심입니다. 결국 은행 지점은 커피숍과 커뮤니티 센터가 될 수도 있습니다.

저는 고객이 고유한 비즈니스 목표를 해결하기 위해 최상의 기술 솔루션에 도달할 수 있도록 돕는 데 주력합니다. 공식적으로는 ID, 보안, 개인 정보 보호 및 규정 준수에 중점을 두고 있습니다. 저는 이 모든 것이 우리가 하는 모든 것을 만지고 있다는 사실을 좋아합니다. 그것은 나에게 대부분의 프로젝트에 참여할 수있는 기회를 제공합니다. 이 활동은 나를 바쁘게 하고이 역할을 즐기고 있습니다.

나는 뉴욕시 (최고!)에 살고 있으며 문화, 음식 및 사람들 (교통이 아닌)의 다양성을 정말로 즐깁니다. 저는 제가 할 수 있을 때 여행하는 것을 좋아하며, 제 일생에 세상의 대부분을 볼 수 있기를 바랍니다. 저는 현재 야생 동물에 대해 배우기 위해 아프리카 여행을 연구하고 있습니다.

원칙

  • 단순이 더 나은 경우가 많습니다. 기술을 사용하여 (거의) 무엇이든 할 수 있지만, 그렇다고 해서 그렇게 해야 한다는 의미는 아닙니다. 특히 보안 공간에서 많은 고객이 솔루션을 과도하게 사용합니다. 나는이 점을 강조하기 위해 구글의 스트라이프 컨퍼런스에서 이 비디오를 좋아한다.
  • 사람, 프로세스, 기술: 기술이 아닌 프로세스를 향상시키기 위한 디자인입니다. "완벽한" 솔루션은 없습니다. 우리는 각 비즈니스에 대해 다를 수 있는 다양한 위험 요소와 결정의 균형을 유지해야 합니다. 너무 많은 고객이 나중에 사용자가 피할 수 있는 접근 방식을 설계합니다.
  • 먼저 '왜'와 '방법'에 초점을 맞추고 나중에 : 백만 질문과 성가신 7 세 아이가 될 수 있습니다. 우리가 물어 올바른 질문을 모르는 경우 우리는 올바른 대답에 도착 할 수 없습니다. 많은 고객이 비즈니스 문제를 정의하는 대신 작업 방식을 가정합니다. 항상 여러 경로를 사용할 수 있습니다.
  • 과거 모범 사례의 긴 꼬리: 모범 사례가 빠른 속도로 변화하고 있음을 인식합니다. 3개월 전에 Microsoft Entra 살펴보았습니다. 여기에 있는 모든 항목은 게시 후 변경될 수 있습니다. 오늘 "최고"옵션은 지금부터 6 개월 동일하지 않을 수 있습니다.

기준 개념

이 섹션을 건너뛰지 마세요. 수년 동안 클라우드 서비스를 사용해 온 고객도 이러한 문서로 한 걸음 물러서야 하는 경우가 많습니다. 아아, 언어는 정확한 도구가 아닙니다. 우리는 종종 같은 개념을 의미하기 위해 다른 개념이나 다른 단어를 의미하는 동일한 단어를 사용합니다. 다음 다이어그램을 사용하여 일부 기준 용어 및 "계층 모델"을 설정하는 경우가 많습니다.

테넌트, 구독, 서비스 및 데이터의 일러스트레이션.

수영하는 법을 배우면 바다 한가운데가 아닌 수영장에서 시작하는 것이 좋습니다. 이 다이어그램에서는 기술적으로 정확하지 않습니다. 몇 가지 기본 개념을 설명하는 모델입니다.

다음은 이 다이어그램에 대한 설명입니다.

  • 테넌트 = Microsoft Entra ID instance. 계층 구조의 "맨 위" 또는 다이어그램의 수준 1에 있습니다. 이 수준을 다른 모든 항목이 발생하는 "경계"로 간주할 수 있습니다(Microsoft Entra B2B 제외). 모든 Microsoft 엔터프라이즈 클라우드 서비스는 이러한 테넌트 중 하나입니다. 소비자 서비스는 별개입니다. "테넌트"는 설명서에 Microsoft 365 테넌트, Azure 테넌트, WVD 테넌트 등으로 표시됩니다. 이러한 변화가 고객에게 혼란을 야기하는 경우가 많습니다.
  • 다이어그램의 수준 2인 서비스/구독은 하나의 테넌트와 하나의 테넌트만 속합니다. 대부분의 SaaS 서비스는 1:1이며 마이그레이션 없이 이동할 수 없습니다. Azure는 서로 다르며 청구 및/또는 구독을 다른 테넌트로 이동할 수 있습니다. Azure 구독을 이동해야 하는 고객이 많습니다. 이 시나리오에는 다양한 의미가 있습니다. 구독 외부에 있는 개체는 이동하지 않습니다. 예를 들어 Azure RBAC(역할 기반 액세스 제어), Microsoft Entra 개체(그룹, 앱, 정책 등) 및 일부 서비스(Azure Key Vault, Data Bricks 등)가 있습니다. 좋은 비즈니스 필요 없이 서비스를 마이그레이션하지 마세요. 마이그레이션에 도움이 될 수 있는 일부 스크립트는 GitHub에서 공유됩니다.
  • 지정된 서비스에는 일반적으로 일종의 "하위 수준" 경계 또는 수준 3(L3)이 있습니다. 이 경계는 보안, 정책, 거버넌스 등을 분리하는 데 유용합니다. 불행히도, 내가 아는 균일 한 이름은 없습니다. L3의 몇 가지 예는 Azure 구독 = 리소스입니다. Dynamics 365 CE = instance; Power BI = 작업 영역; Power Apps = 환경; 등등.
  • 수준 4는 실제 데이터가 있는 위치입니다. 이 '데이터 평면'은 복잡한 문서입니다. 일부 서비스는 RBAC에 Microsoft Entra ID 사용하고, 다른 서비스는 사용하지 않습니다. 위임 문서에 도착하면 조금 설명하겠습니다.

많은 고객(및 Microsoft 직원)이 혼동하거나 관련 질문이 있는 다른 개념에는 다음 문제가 포함됩니다.

  • 누구나 비용 없이 많은 테넌트 만들기를 할 수 있습니다. 서비스 내에 프로비전된 서비스가 필요하지 않습니다. 나는 수십 있다. 각 테넌트 이름은 Microsoft의 전 세계 클라우드 서비스에서 고유합니다(즉, 두 테넌트가 같은 이름을 가질 수 없음). 모두 TenantName.onmicrosoft.com 형식입니다. 테넌트(관리되지 않는 테넌트)를 자동으로 만드는 프로세스도 있습니다. 예를 들어 이 결과는 사용자가 다른 테넌트에서 존재하지 않는 전자 메일 도메인을 사용하여 엔터프라이즈 서비스에 등록할 때 발생할 수 있습니다.
  • 관리되는 테넌트에서 많은 DNS 도메인을 등록할 수 있습니다. 이 결과는 원래 테넌트 이름을 변경하지 않습니다. 현재 테넌트의 이름을 쉽게 바꿀 수 있는 방법은 없습니다(마이그레이션 이외의 경우). 요즘에는 테넌트 이름이 기술적으로 중요하지 않지만 어떤 사람들은 이러한 현실에 의해 제한을 느낄 수 있습니다.
  • 아직 서비스를 배포할 계획이 없더라도 organization 대한 테넌트 이름을 예약해야 합니다. 그렇지 않으면 누군가가 당신에게서 그것을 취할 수 있으며 그것을 되돌릴 수있는 간단한 프로세스가 없습니다 (DNS 이름과 동일한 문제). 나는 고객으로부터 너무 자주 이런 식으로 듣는다. 테넌트 이름이 되어야 하는 것은 토론 문서입니다.
  • DNS 네임스페이스를 소유하는 경우 테넌트에서 이러한 네임스페이스를 모두 추가해야 합니다. 그렇지 않으면 이 이름으로 관리되지 않는 테넌트를 만들 수 있으며, 이로 인해 관리 중단이 발생할 수 있습니다.
  • DNS 네임스페이스(예: contoso.com)는 테넌트 하나에만 속할 수 있습니다. 이 요구 사항은 다양한 시나리오(예: 합병 또는 인수 중에 전자 메일 도메인 공유 등)에 영향을 줍니다. 다른 테넌트에서 DNS 하위(예: div.contoso.com)를 등록하는 방법이 있지만 피해야 합니다. 최상위 도메인 이름을 등록하면 모든 하위 도메인이 동일한 테넌트 에 속하는 것으로 간주됩니다. 다중 테넌트 시나리오(다음에 설명된 대로)에서는 일반적으로 다른 최상위 도메인 이름(예: contoso.ch 또는 ch-contoso.com)을 사용하는 것이 좋습니다.
  • 누가 테넌트 "소유"해야 하나요? 현재 테넌트가 누구인지 모르는 고객을 자주 봅니다. 이러한 지식의 부족은 중요한 붉은 깃발입니다. Microsoft 지원을 최대한 빨리 호출합니다. 문제가 되는 것처럼 서비스 소유자(종종 Exchange 관리자)가 테넌트를 관리하도록 지정된 경우입니다. 테넌트는 나중에 원하는 모든 서비스를 포함합니다. 테넌트 소유자는 organization 모든 클라우드 서비스 사용을 결정할 수 있는 그룹이어야 합니다. 또 다른 문제는 테넌트 소유자 그룹에 모든 서비스를 관리하라는 메시지가 표시되는 경우입니다. 이 메서드는 대규모 조직에 대해 확장되지 않습니다.
  • 하위/슈퍼 테넌트의 개념은 없습니다. 어떤 이유로, 이 신화는 계속 반복. 이 개념은 Azure Active Directory B2C 테넌트에도 적용됩니다. "내 B2C 환경이 내 XYZ 테넌트 안에 있습니다." 또는 "내 Azure 테넌트가 내 Microsoft 365 테넌트로 이동해야 어떻게 할까요??"가 너무 많이 들립니다.
  • 이 문서는 대부분 전 세계 상용 클라우드에 중점을 두고 있습니다. 대부분의 고객이 사용하고 있기 때문입니다. 소 버린 클라우드에 대해 아는 것이 유용한 경우도 있습니다. 소버린 클라우드는 이 토론의 scope 벗어난 것을 논의하기 위한 다른 의미를 갖습니다.

기준 ID 문서

Microsoft Entra ID Microsoft의 ID 플랫폼에 대한 많은 설명서가 있습니다. 막 시작하는 사람들에게는 종종 압도적 인 느낌이 듭니다. 그것에 대해 배운 후에도 지속적인 혁신과 변화를 따라잡는 것은 어려울 수 있습니다. 고객 상호 작용에서 저는 종종 비즈니스 목표와 이러한 문제를 해결하기 위한 "좋은, 더 나은, 최고" 접근 방식(그리고 이 문서에 대한 인간의 "절벽 노트") 사이에서 "번역자"로 활동하는 경우가 많습니다. 완벽한 대답은 거의 없으며 "올바른"결정은 다양한 위험 요소의 균형입니다. 다음은 고객과 논의하는 경향이 있는 몇 가지 일반적인 질문과 혼란 영역입니다.

프로비전

Microsoft Entra ID ID 세계에서 거버넌스가 부족하기 때문에 해결되지 않습니다! ID 거버넌스 는 클라우드 결정과 관계없이 중요한 요소여야 합니다. 거버넌스 요구 사항은 시간이 지남에 따라 변경되므로 도구가 아닌 프로그램입니다.

Microsoft Entra Connect 및 MIM(Microsoft Identity Manager) 및 다른 항목(타사 또는 사용자 지정)? 지금과 미래에 자신에게 문제를 저장하고 Microsoft Entra 연결로 이동합니다. 이 도구에는 독특한 고객 구성과 지속적인 혁신을 해결하기 위한 모든 종류의 스마트가 있습니다.

좀 더 복잡한 아키텍처로 전환될 수 있는 몇 가지 에지 사례:

  • 네트워크 연결 없이 여러 AD 포리스트가 있습니다. Cloud Provisioning이라는 새로운 옵션이 있습니다.
  • Active Directory가 없으며 설치하고 싶지도 않습니다. Microsoft Entra Connect는 LDAP에서 동기화하도록 구성할 수 있습니다(파트너가 필요할 수 있음).
  • 여러 테넌트에서 동일한 개체를 프로비전해야 합니다. 이 시나리오는 기술적으로 지원되지 않지만 "동일"의 정의에 따라 달라집니다.

기본 동기화 규칙(필터 개체, 특성 변경, 대체 로그인 ID 등)을 사용자 지정해야 하나요? 그것을 피하십시오! ID 플랫폼은 이를 사용하는 서비스만큼만 중요합니다. 모든 종류의 견과류 구성을 수행할 수 있지만 이 질문에 대답하려면 애플리케이션에 미치는 영향을 살펴봐야 합니다. 메일 사용 개체를 필터링하는 경우 온라인 서비스 GAL은 불완전합니다. 애플리케이션이 특정 특성을 사용하는 경우 이러한 특성을 필터링하면 예측할 수 없는 효과가 있습니다. ID 팀의 결정이 아닙니다.

XYZ SaaS는 JIT(Just-In-Time) 프로비저닝을 지원합니다. 동기화해야 하는 이유는 무엇인가요? 이전 단락을 참조하세요. 많은 애플리케이션은 기능을 위해 "프로필" 정보가 필요합니다. 모든 메일 사용 개체를 사용할 수 없는 경우 GAL을 사용할 수 없습니다. Microsoft Entra ID 통합된 애플리케이션의 사용자 프로비저닝도 마찬가지입니다.

인증

PHS(암호 해시 동기화) 및 PTA(통과 인증) 및 페더레이션.

일반적으로 페더레이션에 대한 열정적인 논쟁이 있습니다. 더 간단한 일반적으로 더 나은 따라서 하지 않는 좋은 이유가 없는 한 PHS를 사용 합니다. 동일한 테넌트의 다른 DNS 도메인에 대해 서로 다른 인증 방법을 구성할 수도 있습니다.

일부 고객은 주로 다음을 위해 페더레이션 + PHS를 사용하도록 설정합니다.

일부 오해를 명확히 하기 위해 클라이언트 인증 흐름을 통해 고객을 안내하는 경우가 많습니다. 결과는 다음 그림과 같으며, 이는 대화형 프로세스만큼 좋지 않습니다.

화이트보드 대화 예제입니다.

이 유형의 화이트보드 드로잉은 인증 요청 흐름 내에서 보안 정책이 적용되는 위치를 보여 줍니다. 이 예제에서는 AD FS(Active Directory Federation Service)를 통해 적용되는 정책이 첫 번째 서비스 요청에 적용되지만 후속 서비스 요청은 적용되지 않습니다. 이 동작은 보안 컨트롤을 클라우드로 최대한 이동해야 하는 하나 이상의 이유입니다.

우리는 내가 기억할 수있는 한 SSO ( Single Sign-On )의 꿈을 쫓아 왔습니다. 일부 고객은 STS("올바른" 페더레이션) 공급자를 선택하여 Single Sign-On을 달성할 수 있다고 생각합니다. Microsoft Entra ID SSO 기능을 사용하도록 설정하는 데 크게 도움이 될 수 있지만 STS는 마법같지 않습니다. 중요한 애플리케이션에 여전히 사용되는 "레거시" 인증 방법이 너무 많습니다. 파트너 솔루션을 사용하여 Microsoft Entra ID 확장하면 이러한 많은 시나리오를 해결할 수 있습니다. SSO는 전략과 여정입니다. 애플리케이션에 대한 표준으로 이동하지 않고는 이 곳에 도착할 수 없습니다. 이 문서와 관련된 것은 암호 없는 인증에 대한 여정이며, 마법같은 대답도 없습니다.

MFA(다단계 인증)는 현재 필수입니다(자세한 내용은 여기). 사용자 동작 분석을 추가하면 가장 일반적인 사이버 공격을 방지하는 솔루션이 있습니다. 소비자 서비스조차도 MFA를 요구하기 위해 이동하고 있습니다. 그러나 최신 인증 접근 방법으로 전환하고 싶지 않은 많은 고객을 여전히 만나고 있습니다. 가장 큰 논쟁은 사용자 및 레거시 애플리케이션에 영향을 미친다는 것입니다. 때로는 좋은 킥이 고객이 따라 이동하는 데 도움이 될 수 있습니다 - Exchange Online 발표 된 변경 내용. 이제 고객이 이러한 전환을 수행할 수 있도록 많은 Microsoft Entra 보고서를 사용할 수 있습니다.

권한 부여

위키백과에서 "권한 부여"는 액세스 정책을 정의하는 것입니다. 많은 사람들이 개체(파일, 서비스 등)에 대한 액세스 제어를 정의하는 기능으로 보고 있습니다. 현재 사이버 위협 세계에서 이 개념은 다양한 위협 벡터에 대응하고 이에 대응하여 액세스 제어를 신속하게 조정할 수 있는 동적 정책으로 빠르게 진화하고 있습니다. 예를 들어 비정상적인 위치에서 은행 계좌에 액세스하는 경우 추가 확인 단계를 받습니다. 이러한 현실에 접근하려면 정책 자체뿐만 아니라 위협 탐지 및 신호 상관 관계 방법론의 에코시스템을 고려해야 합니다.

Microsoft Entra ID 정책 엔진은 조건부 액세스 정책을 사용하여 구현됩니다. 이 시스템은 동적 결정을 내리기 위해 다른 위협 탐지 시스템의 정보에 따라 달라집니다. 간단한 보기는 다음 그림과 같습니다.

Microsoft Entra ID 정책 엔진.

이러한 모든 신호를 함께 결합하면 다음과 같은 동적 정책을 사용할 수 있습니다.

  • 디바이스에서 위협이 감지되면 다운로드 기능 없이만 데이터에 대한 액세스가 웹으로 줄어듭니다.
  • 비정상적으로 많은 양의 데이터를 다운로드하는 경우 다운로드하는 모든 항목이 암호화되고 제한됩니다.
  • 관리되지 않는 디바이스에서 서비스에 액세스하는 경우 매우 중요한 데이터에서 차단되지만 다른 위치에 복사할 수 없는 무제한 데이터에 액세스할 수 있습니다.

이 확장된 권한 부여 정의에 동의하는 경우 추가 솔루션을 구현해야 합니다. 구현하는 솔루션은 정책의 동적 방식과 우선 순위를 지정하려는 위협에 따라 달라집니다. 이러한 시스템의 몇 가지 예는 다음과 같습니다.

Microsoft Entra ID 외에도 다양한 서비스 및 애플리케이션에는 고유한 특정 권한 부여 모델이 있습니다. 이러한 모델 중 일부는 위임 섹션의 뒷부분에서 설명합니다.

감사

Microsoft Entra ID 자세한 감사 및 보고 기능이 있습니다. 그러나 이러한 보고서는 일반적으로 보안 결정을 내리는 데 필요한 유일한 정보 원본이 아닙니다. 위임 섹션에서 이 주제에 대한 자세한 내용을 참조하세요.

Exchange가 없습니다.

당황하지 마! Exchange는 더 이상 사용되지 않습니다(또는 SharePoint 등). 여전히 핵심 서비스입니다. 제가 의미하는 것은 기술 공급자가 여러 서비스의 구성 요소를 포괄하도록 UX(사용자 환경)를 전환해 왔다는 것입니다. Microsoft 365의 간단한 예는 전자 메일 첨부 파일이 SharePoint Online 또는 OneDrive에 저장되는 "최신 첨부 파일"입니다.

전자 메일에 파일 첨부

Outlook 클라이언트를 보면 Exchange뿐만 아니라 이 환경의 일부로 "연결"된 많은 서비스를 볼 수 있습니다. 예를 들어 Microsoft Entra ID, Microsoft Search, 앱, 프로필, 규정 준수 및 Microsoft 365 그룹이 있습니다.

설명선이 있는 Outlook 인터페이스입니다.

예정된 기능의 미리 보기에 대한 Microsoft Fluid Framework 대해 읽어보세요. 지금 미리 보기에서는 Outlook에서 Teams 대화를 직접 읽고 회신할 수 있습니다. 실제로 Teams 클라이언트 는 이 전략의 가장 눈에 띄는 예 중 하나입니다.

전반적으로 Microsoft 365와 Microsoft 클라우드의 다른 서비스 간에 명확한 선을 그리는 것이 점점 더 어려워지고 있습니다. 고객이 하나의 구성 요소를 사용하더라도 우리가 하는 모든 일에서 총 혁신의 혜택을 누릴 수 있기 때문에 고객에게 큰 이점이라고 생각합니다. 꽤 멋지고 많은 고객에게 큰 영향을 미칩니다.

오늘날 많은 고객 IT 그룹이 "제품"을 중심으로 구성되어 있습니다. 각 특정 제품에 대한 전문가가 필요하기 때문에 온-프레미스 세계에 논리적입니다. 그러나 이러한 서비스가 클라우드로 이동했기 때문에 Active Directory 또는 Exchange 데이터베이스를 다시 디버그할 필요가 없어서 기쁩니다. 자동화(기본적으로 클라우드)는 특정 반복적인 수동 작업을 제거합니다(팩터리에서 발생한 작업 보기). 그러나 이러한 작업은 서비스 간 상호 작용, 효과, 비즈니스 요구 사항 등을 이해하기 위한 보다 복잡한 요구 사항으로 대체됩니다. 배우고자 하는 경우 클라우드 변환을 통해 사용할 수 있는 좋은 기회가 있습니다. 기술에 뛰어들기 전에 IT 기술 및 팀 구조의 변화를 관리하는 방법에 대해 고객에게 이야기하는 경우가 많습니다.

모든 SharePoint 팬과 개발자에게 "SharePoint Online에서 XYZ를 어떻게 할 수 있나요?"라는 질문을 중지하세요. 워크플로에 Power Automate (또는 Flow)를 사용하면 훨씬 더 강력한 플랫폼입니다. Azure Bot Framework를 사용하여 500K 항목 목록에 대한 더 나은 UX를 만듭니다. CSOM 대신 Microsoft Graph 사용을 시작합니다. Microsoft Teams 에는 SharePoint뿐만 아니라 더 많은 세계가 포함되어 있습니다. 나열할 수 있는 다른 많은 예제가 있습니다. 광대하고 멋진 우주가 있습니다. 문을 열고 탐색을 시작합니다.

다른 일반적인 효과는 규정 준수 영역에 있습니다. 이 서비스 간 접근 방식은 많은 규정 준수 정책을 완전히 혼동하는 것처럼 보입니다. "eDiscovery 시스템에 대한 모든 전자 메일 통신을 저널링해야 합니다."라는 조직이 계속 표시됩니다. 전자 메일이 더 이상 전자 메일이 아니라 다른 서비스에 대한 창일 때 이 설명은 실제로 무엇을 의미하나요? Microsoft 365는 규정 준수를 위한 포괄적인 접근 방식을 가지고 있지만, 사람과 프로세스를 변경하는 것은 기술보다 훨씬 더 어려운 경우가 많습니다.

다른 많은 사람들과 프로세스에 영향을 미칩니다. 내 의견으로는,이 요소는 중요하고 논의되지 않은 영역입니다. 아마도 다른 문서에서 더 많은.

테넌트 구조 옵션

단일 테넌트 및 다중 테넌트 비교

일반적으로 대부분의 고객은 프로덕션 테넌트가 하나만 있어야 합니다. 여러 테넌트가 어려운 이유( Bing 검색 제공) 또는 이 백서를 읽는 데는 여러 가지 이유가 있습니다. 동시에 함께 작업하는 많은 엔터프라이즈 고객은 IT 학습, 테스트 및 실험을 위한 다른(소규모) 테넌트가 있습니다. 테넌트 간 Azure 액세스는 Azure Lighthouse를 사용하여 더 쉽게 이루어집니다. Microsoft 365 및 기타 많은 SaaS 서비스에는 테넌트 간 시나리오에 대한 제한이 있습니다. Microsoft Entra B2B 시나리오에서는 고려해야 할 사항이 많습니다.

많은 고객이 인수 합병(M&A) 후 여러 프로덕션 테넌트로 끝나고 통합을 원합니다. 이는 간단하지 않으며 MCS(Microsoft Consulting Services) 또는 파트너 및 타사 소프트웨어가 필요합니다. 향후 다중 테넌트 고객과 함께 다양한 시나리오를 해결하기 위한 엔지니어링 작업이 진행 중입니다.

일부 고객은 둘 이상의 테넌트로 이동하도록 선택합니다. 이것은 신중한 결정이어야하며 거의 항상 비즈니스 이유가 주도되어야합니다! 몇 가지 예로는 다음과 같은 이유가 있습니다.

  • 서로 다른 엔터티 간의 간편한 협업이 필요하지 않고 강력한 관리 및 기타 격리 요구 사항이 있는 지주 유형 회사 구조입니다.
  • 인수 후 두 엔터티를 별도로 유지하기로 비즈니스 결정이 내려집니다.
  • 고객의 프로덕션 환경을 변경하지 않는 고객 환경의 시뮬레이션입니다.
  • 고객을 위한 소프트웨어 개발.

이러한 다중 테넌트 시나리오에서 고객은 테넌트 간에 일부 구성을 동일하게 유지하거나 구성 변경 및 드리프트에 대해 보고하려고 하는 경우가 많습니다. 이는 종종 수동 변경에서 코드로 구성으로 이동하는 것을 의미합니다. Microsoft 프리미어 지원은 공용 IP https://Microsoft365dsc.com를 기반으로 하는 이러한 유형의 요구 사항에 대한 워크샵을 제공합니다.

Multi-Geo

Multi-Geo 또는 Multi-Geo가 아닌 경우 그게 문제입니다. Microsoft 365 Multi-Geo를 사용하면 데이터 상주 요구 사항을 충족하기 위해 선택한 지리적 위치에 미사용 데이터를 프로비전하고 저장할 수 있습니다. 이 기능에 대한 많은 오해가 있습니다. 다음 사항에 유의하세요.

  • 성능 이점을 제공하지는 않습니다. 네트워크 디자인이 올바르지 않으면 성능이 저하할 수 있습니다. 디바이스를 Microsoft 네트워크에 "닫기"(반드시 데이터에 연결할 필요는 없음)를 가져옵니다.
  • GDPR 규정 준수를 위한 솔루션이 아닙니다. GDPR은 데이터 주권 또는 스토리지 위치에 초점을 맞추지 않습니다. 데이터 주권 또는 스토리지 위치에 대한 다른 규정 준수 프레임워크가 있습니다.
  • 관리 위임(아래 참조) 또는 정보 장벽은 해결되지 않습니다.
  • 다중 테넌트와 동일하지 않으며 더 많은 사용자 프로비저닝 워크플로가 필요합니다.
  • 테넌트(Microsoft Entra ID)를 다른 지리로 이동하지 않습니다.

관리 위임

대부분의 대규모 조직에서는 업무 분리와 RBAC(역할 기반 액세스 제어)가 필요한 현실입니다. 나는 미리 사과 할 거야. 이 활동은 일부 고객이 원하는 만큼 간단하지 않습니다. 고객, 법률, 규정 준수 및 기타 요구 사항은 서로 다르며 때로는 전 세계에서 충돌합니다. 단순성과 유연성은 종종 서로 반대쪽에 있습니다. 오해하지 마세요, 우리는이 목표에서 더 나은 일을 할 수 있습니다. 시간이 지남에 따라 상당한 개선이 있었습니다 (그리고 있을 것입니다). 379,230개의 문서를 읽지 않고도 비즈니스 요구 사항에 맞는 모델을 해결하려면 로컬 Microsoft 기술 센터를 방문하세요! 여기서는 여러분이 어떻게 생각해야 하는지, 왜 이런 식으로 생각해야 하는지에 초점을 맞추고 있습니다. 계획해야 할 다섯 가지 영역과 제가 마주치는 몇 가지 일반적인 질문이 있습니다.

Microsoft Entra ID 및 Microsoft 365 관리 센터

기본 제공 역할의 길고 증가하는 목록이 있습니다. 각 역할은 특정 작업을 수행할 수 있도록 함께 그룹화된 역할 권한 목록으로 구성됩니다. 각 역할 내의 "설명" 탭에서 이러한 권한을 볼 수 있습니다. 또는 Microsoft 365 관리 센터에서 이러한 권한의 더 사람이 읽을 수 있는 버전을 볼 수 있습니다. 기본 제공 역할에 대한 정의는 수정할 수 없습니다. 일반적으로 이러한 역할을 세 가지 범주로 그룹화합니다.

  • 전역 관리자: 이 "모든 강력한" 역할은 다른 시스템에서와 마찬가지로 매우 보호되어야 합니다. 일반적인 권장 사항은 영구 할당 없음 및 PIM(Microsoft Entra Privileged Identity Management 사용), 강력한 인증 등이 있습니다. 흥미롭게도 이 역할은 기본적으로 모든 항목에 대한 액세스 권한을 부여하지 않습니다. 일반적으로 규정 준수 액세스 및 Azure 액세스에 대한 혼란이 나중에 설명되어 있습니다. 그러나 이 역할은 항상 테넌트에서 다른 서비스에 대한 액세스를 할당할 수 있습니다.
  • 특정 서비스 관리자: 일부 서비스(Exchange, SharePoint, Power BI 등)는 Microsoft Entra ID 높은 수준의 관리 역할을 사용합니다. 이 동작은 모든 서비스에서 일관되지 않으며 나중에 더 많은 서비스별 역할이 설명되어 있습니다.
  • 기능: 특정 작업(게스트 초대자 등)에 중점을 두는 역할의 긴(및 증가) 목록이 있습니다. 주기적으로 이러한 역할 중 더 많은 것이 고객의 요구에 따라 추가됩니다.

간격이 감소하지만 모든 것을 위임할 수는 없습니다. 즉, 전역 관리자 역할을 가끔 사용해야 합니다. 코드로 구성 및 자동화는 이 역할의 사용자 멤버 자격 대신 고려해야 합니다.

참고: Microsoft 365 관리 센터 더 사용자에게 친숙한 인터페이스를 가지고 있지만 Microsoft Entra 관리자 환경에 비해 기능의 하위 집합이 있습니다. 두 포털 모두 동일한 Microsoft Entra 역할을 사용하므로 동일한 위치에서 변경이 발생합니다. 팁: 모든 Azure 혼란 없이 ID 관리 중심 관리자 UI를 원하는 경우 를 사용합니다 https://aad.portal.azure.com.

이름에 무엇이 있나요? 역할 이름에서 가정하지 마세요. 언어는 정확한 도구가 아닙니다. 목표는 필요한 역할을 살펴보기 전에 위임해야 하는 작업을 정의하는 것입니다. "보안 읽기 권한자" 역할에 누군가를 추가해도 모든 항목에서 보안 설정이 표시되지는 않습니다.

사용자 지정 역할을 만드는 기능은 일반적인 질문입니다. 이 기능은 현재 Microsoft Entra 제한되지만(나중에 설명한 대로) 시간이 지남에 따라 기능이 증가합니다. 이러한 사용자 지정 역할은 Microsoft Entra ID 함수에 적용할 수 있다고 생각하며, 앞서 설명한 대로 계층 모델 "다운"에 걸쳐 있지 않을 수 있습니다. "사용자 지정"을 다룰 때마다 "단순이 더 낫다"는 교장으로 돌아가는 경향이 있습니다.

또 다른 일반적인 질문은 역할을 디렉터리의 하위 집합에 scope 기능입니다. 한 가지 예는 "EU 사용자만을 위한 기술 지원팀 관리자"입니다. 관리 단위 는 이 시나리오를 해결하기 위한 것입니다. 앞에서 설명한 것처럼 이러한 범위는 Microsoft Entra ID 함수에 적용할 수 있으며 "다운"으로 확장되지 않을 수 있습니다. 특정 역할은 scope 의미가 없습니다(전역 관리자, 서비스 관리자 등).

현재 이러한 모든 역할에는 직접 멤버 자격(또는 Microsoft Entra PIM을 사용하는 경우 동적 할당)이 필요합니다. 즉, 고객은 Microsoft Entra ID 이러한 역할을 직접 관리해야 하며 이러한 역할은 보안 그룹 멤버 자격을 기반으로 할 수 없습니다. 나는 높은 권한으로 실행해야하기 때문에 이러한 역할을 관리하는 스크립트를 만드는 팬이 아닙니다. 일반적으로 ServiceNow와 같은 프로세스 시스템과 API를 통합하거나 Saviynt와 같은 파트너 거버넌스 도구를 사용하는 것이 좋습니다. 시간이 지남에 따라 이 문제를 해결하기 위한 엔지니어링 작업이 진행되고 있습니다.

나는 PIM에 Microsoft Entra 몇 번 언급했다. 온-프레미스 컨트롤에 해당하는 MIM(Microsoft Identity Manager) PAM(Privileged Access Management) 솔루션이 있습니다. PAW(Privileged Access Workstations) 및 Microsoft Entra ID Governance 살펴볼 수도 있습니다. 또한 Just-In-Time, Just-Enough 및 동적 역할 상승을 사용하도록 설정할 수 있는 다양한 타사 도구도 있습니다. 이 기능은 일반적으로 환경 보안을 위한 더 큰 논의의 일부입니다.

경우에 따라 역할에 외부 사용자를 추가해야 하는 경우가 있습니다(이전 다중 테넌트 섹션 참조). 이 결과는 잘 작동합니다. Microsoft Entra B2B는 아마도 다른 문서에서 고객을 안내하는 또 다른 크고 재미있는 기사입니다.

Microsoft Defender XDR 및 Microsoft 365 Purview 규정 준수 포털

Microsoft Defender 포털의 Email & 공동 작업 역할 및 Microsoft 365 Purview 규정 준수 포털의 Microsoft Purview 솔루션에 대한 역할 그룹은 Microsoft Entra 역할과 별개인 "역할 그룹"의 컬렉션입니다. 이러한 역할 그룹 중 일부는 Microsoft Entra 역할(예: 보안 읽기 권한자)과 이름이 같지만 멤버 자격이 다를 수 있으므로 혼동될 수 있습니다. 나는 Microsoft Entra 역할을 사용하는 것을 선호합니다. 각 역할 그룹은 하나 이상의 "역할"(동일한 단어를 다시 사용하는 것에 대한 의미 참조)으로 구성되며 전자 메일 사용 개체인 Microsoft Entra ID 멤버가 있습니다. 또한 역할과 이름이 같은 역할 그룹을 만들 수 있습니다. 이 그룹은 해당 역할을 포함하거나 포함하지 않을 수 있습니다(이 혼동을 방지).

어떤 의미에서 이러한 권한은 Exchange 역할 그룹 모델의 진화입니다. 그러나 Exchange Online 고유한 역할 그룹 관리 인터페이스가 있습니다. Exchange Online 일부 역할 그룹은 Microsoft Entra ID 또는 Microsoft Defender XDR 및 Microsoft 365 Purview 규정 준수 포털에서 잠기고 관리되지만 다른 역할 그룹은 이름이 동일하거나 유사한 것일 수 있으며 Exchange Online 관리됩니다(혼동 추가). Exchange 관리에 대한 범위가 필요하지 않은 경우 Exchange Online 사용자 인터페이스를 사용하지 않는 것이 좋습니다.

사용자 지정 역할을 만들 수 없습니다. 역할은 Microsoft에서 만든 서비스에 의해 정의되며 새 서비스가 도입됨에 따라 계속 증가합니다. 이 동작은 개념에서 Microsoft Entra ID 애플리케이션에서 정의한 역할과 유사합니다. 새 서비스를 사용하도록 설정하면 이러한 서비스(예: 내부 위험 관리)에 대한 액세스 권한을 부여하거나 위임하기 위해 새 역할 그룹을 만들어야 하는 경우가 많습니다.

또한 이러한 역할 그룹에는 직접 멤버 자격이 필요하며 Microsoft Entra 그룹을 포함할 수 없습니다. 아쉽게도 오늘날 이러한 역할 그룹은 Microsoft Entra PIM에서 지원되지 않습니다. Microsoft Entra 역할과 마찬가지로 API 또는 Saviynt와 같은 파트너 거버넌스 제품을 통해 이러한 역할 그룹의 관리를 권장하는 경향이 있습니다.

Microsoft Defender 포털 및 Microsoft 365 Purview 규정 준수 포털 역할은 Microsoft 365에 걸쳐 있으며 이러한 역할 그룹을 환경의 하위 집합에 scope 수 없습니다(예: Microsoft Entra ID 관리 단위를 사용할 수 있음). 많은 고객이 어떻게 위임할 수 있는지 묻습니다. 예를 들어 "EU 사용자에 대해서만 DLP 정책을 만듭니다." 현재 Microsoft Defender XDR 및 Microsoft 365 Purview 규정 준수 포털의 특정 함수에 대한 권한이 있는 경우 테넌트에서 이 함수가 다루는 모든 항목에 대한 권한이 있습니다. 그러나 많은 정책에는 환경의 하위 집합을 대상으로 하는 기능이 있습니다(예: "이러한 레이블을 이러한 사용자만 사용할 수 있도록 설정"). 적절한 거버넌스 및 통신은 충돌을 방지하기 위한 핵심 구성 요소입니다. 일부 고객은 Microsoft Defender XDR 및 Microsoft 365 Purview 규정 준수 포털에서 하위 설정을 해결하기 위해 "코드로 구성" 접근 방식을 구현하도록 선택합니다. 일부 특정 서비스는 하위 구분을 지원합니다(다음 섹션 참조).

서비스별

앞에서 설명한 것처럼 많은 고객이 보다 세분화된 위임 모델을 달성하고자 합니다. 일반적인 예: "나누기 X 사용자 및 위치에 대해서만 XYZ 서비스 관리" (또는 다른 차원). 이 작업을 수행하는 기능은 각 서비스에 따라 달라지며 서비스 및 기능 간에 일관되지 않습니다. 또한 각 서비스에는 별도의 고유한 RBAC 모델이 있을 수 있습니다. 이러한 모든 모델에 대해 논의하는 대신(영원히 걸릴 수 있음) 각 서비스에 대한 관련 링크를 추가하고 있습니다. 이 목록은 완료되지 않았지만 시작할 수 있습니다.

  • Exchange Online - (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online - (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams - (/microsoftteams/itadmin-readiness)
  • eDiscovery - (.. /compliance/index.yml)
    • 권한 필터링 - (.. /compliance/index.yml)
    • 규정 준수 경계 - (.. /compliance/set-up-compliance-boundaries.md)
    • eDiscovery(프리미엄) - (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • 다중 지역 - (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 – (/dynamics365/)

참고

이 링크는 설명서의 루트에 대한 링크입니다. 관리/위임 모델에 변형이 있는 여러 유형의 서비스가 있습니다.

  • Power Platform - (/power-platform/admin/admin-documentation)

    • Power Apps - (/power-platform/admin/wp-security)

      참고

      관리자/위임 모델에 변형이 있는 여러 형식이 있습니다.

    • Power Automate - (/power-automate/environments-overview-admin)

    • Power BI - (/power-bi/service-admin-governance)

      참고: 데이터 플랫폼 보안 및 위임(Power BI가 구성 요소임)은 복잡한 영역입니다.

  • Intune - (/mem/intune/fundamentals/role-based-access-control)

  • 엔드포인트용 Microsoft Defender - (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (.. /security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps - (/cloud-app-security/manage-admins)

  • Stream - (/stream/assign-administrator-user-role)

  • 정보 장벽 - (.. /compliance/information-barriers.md)

활동 로그

Microsoft 365에는 통합 감사 로그가 있습니다. 매우 자세한 로그이지만 이름에 너무 많이 읽지 마세요. 보안 및 규정 준수 요구 사항에 필요한 모든 항목이 포함되지 않을 수 있습니다. 또한 일부 고객은 감사(프리미엄)에 매우 관심이 있습니다.

다른 API를 통해 액세스되는 Microsoft 365 로그의 예는 다음과 같습니다.

먼저 보안 및 규정 준수 프로그램에 필요한 모든 로그 원본을 식별하는 것이 중요합니다. 또한 로그에 따라 온라인 보존 제한이 다릅니다.

관리자 위임 관점에서 대부분의 Microsoft 365 활동 로그에는 기본 제공 RBAC 모델이 없습니다. 로그를 볼 수 있는 권한이 있는 경우 로그에 있는 모든 항목을 볼 수 있습니다. 고객 요구 사항의 일반적인 예는 "EU 사용자에 대해서만 활동을 쿼리할 수 있기를 원합니다"(또는 다른 차원)입니다. 이 요구 사항을 달성하려면 로그를 다른 서비스로 전송해야 합니다. Microsoft 클라우드에서는 Microsoft Sentinel 또는 Log Analytics로 전송하는 것이 좋습니다.

상위 수준 다이어그램:

보안 및 규정 준수 프로그램에 대한 로그 원본 다이어그램

다이어그램은 Event Hubs 및/또는 Azure Storage 및/또는 Azure Log Analytics에 로그를 보내는 기본 제공 기능을 나타냅니다. 모든 시스템에 이 기본 제공이 아직 포함되어 있지는 않습니다. 그러나 이러한 로그를 동일한 리포지토리로 보내는 다른 방법이 있습니다. 예를 들어 Microsoft Sentinel을 사용하여 Teams 보호를 참조하세요.

모든 로그를 하나의 스토리지 위치에 결합하면 상호 상관 관계, 사용자 지정 보존 시간, RBAC 모델을 지원하는 데 필요한 데이터 보강 등의 추가 혜택이 포함됩니다. 데이터가 이 스토리지 시스템에 있으면 적절한 RBAC 모델을 사용하여 Power BI dashboard(또는 다른 유형의 시각화)를 만들 수 있습니다.

로그는 한 곳으로만 전달될 필요가 없습니다. Power BI에서 Microsoft 365 로그를 Microsoft Defender for Cloud Apps 또는 사용자 지정 RBAC 모델과 통합하는 것도 유용할 수 있습니다. 리포지토리의 이점과 대상 그룹이 다릅니다.

Microsoft Defender XDR 이라는 서비스에는 보안, 위협, 취약성 등에 대한 풍부한 기본 제공 분석 시스템이 있다는 점을 언급할 가치가 있습니다.

많은 대규모 고객이 이 로그 데이터를 타사 시스템(예: SIEM)으로 전송하려고 합니다. 이 결과에는 여러 가지 방법이 있지만 일반적으로 Azure Event Hubs그래프는 좋은 시작점입니다.

Azure

Microsoft Entra ID, Azure 및 SaaS(예: Azure가 아닌 Microsoft 365용 전역 관리자) 간에 높은 권한의 역할을 구분하는 방법이 있는지 자주 묻습니다. 설마. 완전한 관리 분리가 필요한 경우 다중 테넌트 아키텍처가 필요하지만 앞에서 설명한 대로 상당히 복잡해집니다 . 이러한 모든 서비스는 계층 모델에 표시된 것처럼 동일한 보안/ID 경계의 일부입니다.

동일한 테넌트의 다양한 서비스 간의 관계를 이해하는 것이 중요합니다. Azure, Microsoft 365 및 Power Platform(그리고 종종 온-프레미스 및 타사 클라우드 서비스)에 걸쳐 있는 비즈니스 솔루션을 빌드하는 많은 고객과 협력하고 있습니다. 한 가지 일반적인 예는 다음과 같습니다.

  1. 문서/이미지/등 집합에서 공동 작업하려고 합니다(Microsoft 365)
  2. 승인 프로세스를 통해 각각 보내기(Power Platform)
  3. 모든 구성 요소가 승인되면 이러한 항목을 통합 결과물(Azure) Microsoft Graph API 조합하는 것이 가장 좋습니다. 불가능하지는 않지만 여러 테넌트에서 솔루션을 설계하는 것이 훨씬 더 복잡합니다.

AZURE RBAC(Azure Role-Based Access Control)를 사용하면 Azure에 대한 세분화된 액세스 관리를 사용할 수 있습니다. RBAC를 사용하면 사용자에게 작업을 수행하는 데 필요한 가장 적은 권한을 부여하여 리소스에 대한 액세스를 관리할 수 있습니다. 이 문서에 대한 자세한 내용은 scope 없지만 RBAC에 대한 자세한 내용은 Azure의 RBAC(역할 기반 액세스 제어)란?을 참조하세요. RBAC는 중요하지만 Azure에 대한 거버넌스 고려 사항의 일부일 뿐입니다. 클라우드 채택 프레임워크 자세한 내용을 알아볼 수 있는 좋은 출발점입니다. 제 친구 안드레스 라비넷(Andres Ravinet)이 다양한 구성 요소를 단계별로 안내하여 접근 방식을 결정하는 방법을 좋아합니다. 다양한 요소에 대한 개략적인 보기(실제 고객 모델에 도달하기 위한 프로세스만큼 좋지 않음)는 다음과 같습니다.

위임된 관리를 위한 Azure 구성 요소의 개략적인 보기

위의 그림에서 볼 수 있듯이 다른 많은 서비스는 디자인의 일부로 간주되어야 합니다(예: Azure Policy, Azure Blueprints, 관리 그룹 등).

결론

이 문서는 짧은 요약으로 시작하여 예상보다 오래 끝났습니다. 이제 organization 대한 위임 모델을 만드는 방법에 대해 자세히 알아보시기 바랍니다. 이 대화는 고객과 매우 일반적입니다. 모든 사용자에게 적합한 모델은 없습니다. 고객 전체에서 볼 수 있는 일반적인 패턴을 문서화하기 전에 Microsoft 엔지니어링에서 계획된 몇 가지 개선 사항을 기다리고 있습니다. 그 동안 Microsoft 계정 팀과 협력하여 가장 가까운 Microsoft 기술 센터를 방문할 수 있습니다. 거기 당신을 참조하십시오!