문제 :
- Adatum이라는 Azure AD 테넌트와 Subscription1이라는 Azure 구독이 있습니다.
- Adatum에는 Developers라는 그룹이 있습니다.
- Subscription1에는 Dev라는 리소스 그룹이 있습니다.
- 목표: Developers 그룹이 Dev 리소스 그룹에서 Azure Logic Apps를 만들 수 있는 권한을 제공해야 합니다.
- 해결 방법: Dev 리소스 그룹에서 Developers 그룹에 Logic App Contributor 역할을 할당합니다.
- 질문: 이것이 목표를 달성합니까?
해설
- Logic App Contributor 역할은 리소스 그룹 내에서 Logic Apps를 포함한 Logic App 리소스의 생성, 편집, 삭제 등 대부분의 관리 작업을 수행할 수 있는 권한을 제공합니다5.
- 따라서, Dev 리소스 그룹에서 Developers 그룹에 Logic App Contributor 역할을 할당하면 해당 그룹의 사용자는 Logic Apps를 새로 만들 수 있습니다5.
- 참고로, Logic App Operator(운영자) 역할은 Logic App을 활성화/비활성화하거나 실행 상태를 볼 수 있지만, 새 Logic App을 만들 수 있는 권한은 없습니다6. Contributor(기여자) 역할 역시 Logic Apps 생성이 가능합니다.
결론
Dev 리소스 그룹에서 Developers 그룹에 Logic App Contributor 역할을 할당하면, 해당 그룹은 Logic Apps를 생성할 수 있으므로 목표를 달성합니다.
문제
- Storage1이라는 Azure 스토리지 계정이 온-프레미스 Active Directory(AD)와 동기화된 contoso.com 도메인에 연결되어 있습니다.
- 도메인에는 User1(사용자)과 Computer1(컴퓨터) 계정이 있습니다.
- Azure AD에서 User2라는 사용자를 새로 만듭니다.
- Storage1 계정에는 share1이라는 파일 공유가 있습니다.
- share1은 Azure Files Identity Based Authentication(Azure AD DS 통합)으로 구성되어 있습니다.
진술별로 권한 할당 가능 여부를 판단해야 합니다.
Azure Files RBAC 역할 및 할당 조건
- Storage File Data SMB Share Contributor/Reader/Elevated Contributor 역할은 사용자, 그룹, 서비스 프린시플 등 Microsoft Entra ID(구 Azure AD)에 등록된 엔터티에 할당할 수 있습니다456.
- **컴퓨터 계정(Computer1)**은 Microsoft Entra ID에 엔터티로 존재하지 않으므로, Azure RBAC 역할을 직접 할당할 수 없습니다. 컴퓨터 계정은 기본 공유 수준 권한으로만 접근 가능합니다5.
- User1은 온-프레미스 AD와 동기화된 사용자이므로, Microsoft Entra ID에 하이브리드 아이덴티티로 존재하고, 역할 할당이 가능합니다5.
- User2는 Azure AD에서 새로 만든 사용자로, 클라우드 전용 계정입니다. Azure Files RBAC의 경우, 하이브리드 아이덴티티(온프레미스 AD와 동기화된 사용자)만 지원하므로, User2에는 역할 할당이 불가합니다5.
진술별 정답 및 해설
| Statements | Yes | No |
| You can assign the Storage File Data SMB Share Contributor role to User1 for share1. | ● | |
| You can assign the Storage File Data SMB Share Reader role to Computer1 for share1. | ● | |
| You can assign the Storage File Data SMB Share Elevated Contributor role to User2 for share1. | ● |
1. User1에게 Contributor 역할 할당 가능 여부
- User1은 온프레미스 AD와 동기화된 사용자이므로 Microsoft Entra ID에 하이브리드 아이덴티티로 존재합니다.
- 따라서 Contributor 역할을 할당할 수 있습니다5.
2. Computer1에게 Reader 역할 할당 가능 여부
- Computer1은 컴퓨터 계정으로, Microsoft Entra ID에 엔터티로 존재하지 않습니다.
- 따라서 Reader 역할을 직접 할당할 수 없습니다5.
3. User2에게 Elevated Contributor 역할 할당 가능 여부
- User2는 Azure AD에서 새로 만든 클라우드 전용 사용자입니다.
- Azure Files의 공유 수준 RBAC 권한은 하이브리드(동기화된) 사용자만 지원하므로, User2에게는 할당할 수 없습니다5.
결론
- 1번 진술: Yes
- 2번 진술: No
- 3번 진술: No
따라서, 이미지의 표에서 1번만 Yes, 2번과 3번은 No로 체크한 것이 정답입니다.
앞 풀이에서 3번(User2에게 Elevated Contributor 역할 할당 가능 여부)을 Yes로 했던 이유와, 지금은 No로 바뀐 이유는 Azure Files의 공유 수준 권한(RBAC) 할당 조건에 대한 정확한 이해 차이 때문입니다.
핵심 근거
- Azure Files의 공유 수준 권한(RBAC)은 Microsoft Entra ID(구 Azure AD)에 존재하는 사용자, 그룹, 서비스 프린시플에만 할당할 수 있습니다.
- 하지만, 공유 수준 권한을 개별 사용자에게 할당하려면 해당 계정이 반드시 "하이브리드 아이덴티티"여야 합니다. 즉, 온프레미스 AD에 존재하고, Microsoft Entra ID로 동기화된 사용자만 해당합니다2.
"If you intend to use a specific Microsoft Entra user or group to access Azure file share resources, that identity must be a hybrid identity that exists in both on-premises AD DS and Microsoft Entra ID... The selected Microsoft Entra identity must be a hybrid identity and cannot be a cloud only identity. This means that the same identity is also represented in AD DS."2
- User2는 Azure AD에서 새로 만든 클라우드 전용 사용자이므로, 온프레미스 AD에는 존재하지 않고 하이브리드 아이덴티티가 아닙니다.
- 따라서 User2에게는 Storage File Data SMB Share Elevated Contributor(혹은 다른 공유 수준 역할)를 할당할 수 없습니다2.
결론
- 앞 풀이에서 3번을 Yes로 했던 이유:
단순히 "Azure AD 사용자면 역할 할당 가능하다"고 오해했기 때문입니다. - 지금은 No로 바뀐 이유:
Azure Files 공유 수준 권한은 반드시 온프레미스 AD와 동기화된 하이브리드 사용자만 개별적으로 할당할 수 있고, 클라우드 전용 사용자(User2)에게는 할당할 수 없기 때문입니다2.
참고 요약
| 사용자 유형공유 수준 권한 할당 가능 | 여부 |
| 온프레미스 AD 동기화 사용자 (User1) | O |
| 컴퓨터 계정 (Computer1) | X |
| Azure AD 클라우드 전용 사용자 (User2) | X |
따라서, 3번 진술(You can assign the Storage File Data SMB Share Elevated Contributor role to User2 for share1)은 No가 정답입니다.
📌 보완 설명
- **Azure Files Identity-Based Authentication (AD DS 통합)**는 Microsoft Entra ID 사용자에게 권한을 부여하지만, "동기화된 온프레미스 사용자(hybrid identity)"만 지원합니다.
- **클라우드 전용 사용자(Azure AD native)**나 서비스 계정, 컴퓨터 계정 등은 직접 공유 수준 RBAC를 통해 접근 권한을 받을 수 없습니다.
- 컴퓨터 계정은 AD의 NTFS ACL 또는 기본 공유 권한 수준에서만 접근 가능하며, RBAC 대상이 아닙니다.
✅ 문제
Contoso.com이라는 Azure Active Directory 테넌트에는 다음과 같은 사용자와 디바이스가 있습니다.
사용자 정보
| Name | Role |
| User1 | Cloud device administrator |
| User2 | User administrator |
디바이스 정보
| Name | Join type |
| Device1 | Azure AD registered |
| Device2 | Azure AD joined |
그룹 정보
| Name | Membership Type | Owner |
| Group1 | Assigned | User2 |
| Group2 | Dynamic Device | User2 |
다음 각 문장에 대해 True이면 Yes, 그렇지 않으면 No를 선택하십시오.
✅ Statements
- User1 can add Device2 to Group1.
- User2 can add Device1 to Group1.
- User2 can add Device2 to Group2.
✅ 정답 및 해설
| Statements | 정답 | 해설 |
| User1 can add Device2 to Group1 | ✅ Yes | User1는 Cloud Device Administrator 역할을 가지고 있고, 이 역할은 디바이스를 등록하고 그룹에 추가할 수 있는 권한을 포함합니다. Group1은 "Assigned" 타입이므로 수동 추가가 가능합니다. |
| User2 can add Device1 to Group1 | ✅ Yes | User2는 Group1의 Owner이고, Group1은 Assigned 타입이므로 소유자는 그룹에 멤버(디바이스 포함)를 추가할 수 있습니다. |
| User2 can add Device2 to Group2 | ❌ No | Group2는 "Dynamic Device" 그룹으로, 조건에 따라 자동으로 멤버가 결정되며 수동 추가가 불가능합니다. Owner라고 하더라도 직접 멤버 추가는 할 수 없습니다. |
📌 핵심 개념 요약
| 조건 | 가능한 작업 |
| Assigned Group | 소유자나 관리자 권한이 있으면 수동 추가 가능 |
| Dynamic Device Group | 필터 조건에 따라 자동으로 디바이스가 추가되며, 수동 추가는 불가 |
| Cloud Device Administrator | 디바이스 등록 및 그룹에 할당 가능 (Assigned Group에 한함) |
좋습니다. **1번 문장: "User1 can add Device2 to Group1"**이 정답이 "Yes"인지 No인지 정확히 판단하기 위해 역할 권한, 그룹 유형, 디바이스 유형을 조합해 분석해보겠습니다.
🔎 조건 정리
- User1의 역할: Cloud Device Administrator
- Device2: Azure AD Joined
- Group1: Assigned 타입, Owner는 User2
✅ Cloud Device Administrator 권한
Microsoft 공식 문서 기준, Cloud Device Administrator는 다음 권한을 가집니다:
- 디바이스를 Azure AD에 등록 및 관리할 수 있음
- Azure AD에 조인된(Azure AD joined) 디바이스를 관리할 수 있음
- 하지만 그룹 관리 권한은 없음 (그룹에 멤버 추가 불가)
🔗 공식 문서: Cloud Device Administrator 역할 정의 (MSDN)
"Users with this role can read directory information for devices and register new devices. They cannot manage groups or assign group memberships."
즉, Cloud Device Administrator는 디바이스는 관리할 수 있지만, 그룹에 디바이스를 추가하는 권한은 없다는 것이 핵심입니다.
❌ 결론: 1번은 No
- User1은 Group1의 Owner도 아니고, 그룹 관리 권한도 없음
- Assigned 그룹이므로 수동 추가는 필요하지만, User1은 권한이 부족
정답 다시 정리
| Statements | 정답 | 해설 |
| User1 can add Device2 to Group1 | ❌ No | User1은 Cloud Device Administrator로서 디바이스 관리는 가능하나, 그룹 소속 관리 권한은 없음. |
| User2 can add Device1 to Group1 | ✅ Yes | User2는 Owner이고 Group1은 Assigned 타입이므로 수동 추가 가능. |
| User2 can add Device2 to Group2 | ❌ No | Dynamic Device 그룹에는 수동 추가 불가능. |
Q1: Cloud Device Administrator와 User Administrator의 권한 범위는 어떻게 다르고, 각각 어떤 시나리오에서 쓰일까?
아주 좋은 질문입니다. Cloud Device Administrator와 User Administrator는 Azure AD에서 각각 디바이스와 사용자에 대한 관리 책임을 지닌 역할이지만, 권한 범위와 사용 시나리오는 크게 다릅니다.
🔍 Cloud Device Administrator vs. User Administrator 비교표
| 항목 | Cloud Device Administrator | User Administrator |
| 주요 관리 대상 | 디바이스(Devices) | 사용자(Users), 그룹(Groups) |
| 디바이스 등록 및 삭제 | ✅ 가능 | ❌ 불가능 |
| Azure AD 등록된 디바이스 보기 | ✅ 가능 | ❌ 기본적으로 불가 |
| 디바이스 그룹 멤버 관리 | ❌ 불가능 (그룹에 디바이스 추가는 못함) | ✅ 가능 (그룹 Owner일 경우) |
| 사용자 생성 및 수정 | ❌ 불가능 | ✅ 사용자 계정 생성, 수정, 삭제 가능 |
| 비밀번호 재설정 | ❌ 불가능 | ✅ 일반 사용자 비밀번호 재설정 가능 |
| 그룹 생성 및 멤버 관리 | ❌ 불가능 | ✅ 가능 (보안 그룹, M365 그룹 등 생성 및 구성 가능) |
| 시나리오 예시 | 회사 PC를 Azure AD에 등록하거나 삭제할 수 있는 현장 IT 직원 | 사내 인사팀에서 신규 직원 계정 생성, 비밀번호 초기화 등을 담당 |
| 실제 업무 예 | - 신규 PC Azure AD 등록- 불량 디바이스 삭제- 등록 상태 확인 | - 신규 사용자 계정 발급- 팀별 보안 그룹 생성- 비밀번호 초기화 |
🔧 주요 차이 요약
- Cloud Device Administrator: 디바이스 등록/삭제/조회에 초점
👉 “기기 중심 역할”, 보통 IT 부서에서 현장 장치 설정을 담당할 때 사용 - User Administrator: 사용자/그룹 관리, 사용자 비밀번호 초기화 등 인사 관리에 초점
👉 “사용자 중심 역할”, 인사(HR), 헬프데스크 등에서 자주 사용
✅ 함께 기억할 점
- Cloud Device Administrator는 그룹과 사용자에는 접근 불가
- User Administrator는 디바이스 직접 등록은 불가, 다만 사용자 디바이스 관련 설정은 가능
질문 :
Azure 가상 머신(VM)에 구성된 Microsoft SQL Server Always On 가용성 그룹의 리스너를 Azure 내부 부하 분산 장치(ILB)로 구성해야 합니다.
솔루션으로 "세션 지속성을 클라이언트 IP로 설정"하는 것이 제시되었습니다.
이 솔루션이 목표(가용성 그룹 리스너의 정상 동작)를 충족하는지 묻고 있습니다.
해설
정답: 솔루션은 목표를 충족하지 않습니다.
이유 및 상세 설명
- Always On 가용성 그룹 리스너는 클라이언트가 가용성 그룹의 활성 복제본에 투명하게 연결할 수 있도록 해주는 엔드포인트입니다. Azure VM 환경에서는 내부 부하 분산 장치(ILB)를 통해 리스너를 구성해야 하며, 이때 부하 분산 장치의 설정이 매우 중요합니다.
- **세션 지속성(Session Persistence, Affinity)**을 "클라이언트 IP(Client IP)"로 설정하면, 동일한 클라이언트 IP에서 들어오는 모든 요청이 항상 동일한 백엔드 서버로 전달됩니다.
- 이 방식은 웹 서버 등에서는 유용할 수 있으나, SQL Server Always On 가용성 그룹에서는 부적합합니다.
- 가용성 그룹에서는 장애 조치(failover) 발생 시 리스너 IP가 활성 복제본으로 이동해야 하며, ILB가 이를 올바르게 라우팅해야 합니다.
- 클라이언트 IP 기반 세션 지속성은 장애 조치 후에도 이전(비활성) 복제본으로 트래픽을 보내는 문제가 발생할 수 있습니다.
- 권장 설정
"Session Persistance 설정을 Client IP로 설정하게 되면 클라이언트의 IP 주소에 따라 요청이 특정 백엔드 서버로 지속적으로 전달됨. 이는 데이터 베이스 연결에 적합하지 않음... SQL Server Always On 리스너를 구성할 땐 'None' or 'Client Affinity'와 같은 다른 세션 지속성 설정이 더 적합."
(출처:5)
결론
- 세션 지속성을 클라이언트 IP로 설정하는 것은 Azure VM 기반 SQL Server Always On 가용성 그룹 리스너의 정상 동작을 보장하지 못합니다.
- Floating IP(Direct Server Return) 옵션을 활성화해야 장애 조치 시에도 리스너가 올바르게 동작합니다.
따라서, 제시된 솔루션(세션 지속성을 클라이언트 IP로 설정)은 목표를 충족하지 않습니다.
'Azure에서 SQL Server Always On 가용성 그룹(Availability Group, AG) 리스너를
내부 부하 분산 장치(Internal Load Balancer, ILB)로 구성한다.'
는 것은 고가용성을 보장하기 위해 애플리케이션이 가용성 그룹의 데이터베이스에 연결할 때 특정 IP 주소와 네트워크 이름을 통해 연결하도록 설정하는 것을 의미합니다. 이를 통해 애플리케이션은 기본 복제본(Primary Replica)이 위치한 SQL Server 인스턴스에 자동으로 연결되며, 장애 조치(Failover)가 발생하더라도 중단 없이 연결이 유지됩니다. 아래에서 이 개념을 상세히 설명하고, 도식화된 구조를 통해 이해를 돕겠습니다.
SQL Server Always On 가용성 그룹 리스너와 Azure ILB의 역할
SQL Server Always On 가용성 그룹은 고가용성과 재해 복구를 위해 여러 SQL Server 인스턴스 간에 데이터베이스를 동기화하는 기능입니다. 가용성 그룹 리스너(Listener)는 애플리케이션이 데이터베이스에 연결할 때 사용하는 가상 네트워크 이름(VNN)과 IP 주소로, 기본 복제본이 있는 SQL Server 인스턴스로 연결을 라우팅합니다. Azure 환경에서는 Windows Failover Cluster(WSFC)와 함께 작동하며, Azure의 네트워크 제약으로 인해 ILB가 리스너의 IP 주소를 관리하고 트래픽을 적절한 노드로 전달하는 데 필요합니다.
Azure ILB는 가상 네트워크(VNET) 내에서 트래픽을 분산하는 역할을 하며, 가용성 그룹 리스너의 경우 ILB는 애플리케이션 연결을 위한 프론트엔드 IP 주소를 제공하고, 백엔드 풀(Backend Pool)에 포함된 SQL Server VM으로 트래픽을 전달합니다. 특히, ILB는 건강 프로브(Health Probe)를 통해 기본 복제본이 위치한 SQL Server 인스턴스를 식별하고, 해당 인스턴스로 트래픽을 라우팅합니다.
Azure ILB로 가용성 그룹 리스너를 구성하는 이유
Azure 환경에서는 가용성 그룹 리스너의 IP 주소가 Windows Failover Cluster에서 직접 관리되지 않습니다. 온프레미스 환경에서는 리스너 IP가 클러스터 노드에 직접 바인딩되지만, Azure에서는 네트워크 계층의 제한으로 인해 ILB가 리스너 IP를 프론트엔드 IP로 설정하고, 트래픽을 백엔드 풀의 적절한 VM으로 전달하는 중간 역할을 합니다. 이는 Azure의 가상 네트워크에서 ICMP 프로토콜(예: ping)이 차단되어 있어 직접적인 연결 테스트가 어렵기 때문이기도 합니다. 또한, ILB는 "Floating IP" 또는 "Direct Server Return" 기능을 통해 리스너 IP를 특정 SQL Server 인스턴스에 매핑하여 효율적인 트래픽 처리를 가능하게 합니다.
구성 요소와 작동 방식
- 프론트엔드 IP 구성: ILB의 프론트엔드 IP 주소는 가용성 그룹 리스너의 IP 주소로 설정됩니다. 애플리케이션은 이 IP 주소를 통해 리스너에 연결을 시도합니다.
- 백엔드 풀: ILB는 가용성 그룹에 포함된 SQL Server VM들을 백엔드 풀로 구성합니다. 이 VM들은 리스너를 통해 들어오는 트래픽을 수신할 수 있는 대상입니다.
- 건강 프로브(Health Probe): ILB는 특정 포트(예: 59999)를 통해 각 SQL Server 인스턴스의 상태를 확인합니다. 이 프로브는 기본 복제본이 위치한 인스턴스를 식별하여 트래픽을 해당 인스턴스로 라우팅합니다.
- 부하 분산 규칙(Load Balancing Rules): ILB는 TCP 프로토콜(기본적으로 포트 1433)을 사용하여 리스너 트래픽을 처리하며, "Floating IP" 설정을 통해 직접 서버 반환(Direct Server Return)을 활성화합니다. 이는 한 번에 하나의 SQL Server 인스턴스만 리스너 리소스를 소유하기 때문에 필요합니다.
- 클러스터 리소스 구성: Windows Failover Cluster Manager에서 리스너의 클라이언트 액세스 포인트(Client Access Point)를 설정하고, 리스너 IP를 ILB의 프론트엔드 IP와 동일하게 정적 IP로 구성합니다.
구성 절차 개요
- Azure 포털에서 ILB를 생성하고 프론트엔드 IP 주소를 리스너 IP로 설정합니다.
- 백엔드 풀에 SQL Server VM을 추가합니다.
- 건강 프로브를 설정하여 기본 복제본을 식별할 포트(예: 59999)를 지정합니다.
- 부하 분산 규칙을 설정하여 TCP 포트(예: 1433)와 Floating IP를 활성화합니다.
- Failover Cluster Manager에서 리스너를 생성하고, 리스너 IP를 ILB의 프론트엔드 IP와 동일하게 설정합니다14.
도식화된 구조
아래는 가용성 그룹 리스너와 Azure ILB의 관계를 간단히 도식화한 것입니다. Markdown 형식으로 텍스트 기반 다이어그램을 제공합니다.
|
v
[Azure ILB]
- 프론트엔드 IP (리스너 IP: 예: 10.0.0.100)
- 건강 프로브 (포트 59999로 기본 복제본 확인)
|
|----> [SQL Server VM 1 (기본 복제본)] (백엔드 풀)
|----> [SQL Server VM 2 (보조 복제본)] (백엔드 풀)
위 다이어그램에서 애플리케이션은 ILB의 프론트엔드 IP를 통해 리스너에 연결하고, ILB는 건강 프로브를 통해 기본 복제본이 위치한 VM 1으로 트래픽을 라우팅합니다. 장애 조치 시 VM 2가 기본 복제본이 되면 ILB는 자동으로 트래픽을 VM 2로 전환합니다.
제한 사항 및 주의점
- 단일 ILB 제한: 하나의 클라우드 서비스 또는 VNET 내에서는 하나의 ILB만 지원되므로, 동일한 클라우드 서비스에서 내부 리스너와 외부 리스너를 동시에 구성할 수 없습니다.
- ICMP 차단: Azure ILB는 ICMP 프로토콜(ping)을 지원하지 않으므로 연결 테스트 시 PSPing, Nmap, telnet과 같은 TCP 포트 테스트 도구를 사용해야 합니다.
- Floating IP 설정 변경 불가: 부하 분산 규칙에서 Floating IP(Direct Server Return)는 생성 시 설정해야 하며, 이후 변경이 불가능합니다.
이와 같이 Azure ILB를 통해 가용성 그룹 리스너를 구성하면 애플리케이션은 고가용성을 유지하며 SQL Server 데이터베이스에 안정적으로 연결할 수 있습니다. ILB는 Azure의 네트워크 환경에서 리스너의 IP 관리와 트래픽 라우팅을 효율적으로 처리하는 핵심 구성 요소입니다.
'인공지능,프로그래밍 > MS Azure' 카테고리의 다른 글
| Azure DP (0) | 2025.05.07 |
|---|---|
| Azure 역할의 이해 각 권한 별 일반적 특징 및 관계 (0) | 2025.05.06 |
| Azure ID 라이선스 블레이드 (0) | 2025.05.06 |
| 새로운 직원을 추가하고 다단계 인증하기 문제 (0) | 2025.05.02 |
| 대량 게스트 사용자 계정 생성 방법 (0) | 2025.05.02 |
