Azure 서비스 활용을 위해 Azure 구독이 필요함 (ex. 회사에서 단일 계정을 만든 후 부서별 구독을 생성할 수도 있음)
Azure infra
물리적 인프라
물리적 인프라 : 데이터센터와 같이 전용 전원, 냉각 및 네트워킹 인프라를 갖춘 랙에 배치된 리소스가 있는 시설
Region (지역) : 데이터 센터를 하나 이상 포함하고 있는(여러 개 포함 가능) 지리적 영역
Availability Zone (가용성 영역) : Azure 지역 내에서 물리적으로 분리된 데이터 센터
가용성 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터로 구성
한 가용성 영역 내에 컴퓨팅, 스토리지, 네트워킹 및 데이터 리소스를 공동 배치하고 다른 가용성 영역에 복제하여 애플리케이션 아키텍처에 고가용성을 구현
Region Pair (지역 쌍) : 대부분의 Azure 지역은 300마일 이상 떨어져 있는 동일한 지리적 위치(예: 미국, 유럽 또는 아시아) 내의 다른 Azure 지역과 쌍을 이룸 -> 단일 지역의 여러 가용성 영역에 영향을 주는 경우 대비
Sovereign Region (소버린 지역) : Azure의 주 인스턴스에서 격리된 Azure의 인스턴스
규정 준수 또는 법적 목적을 위해 소버린 지역을 사용
US DoD 중부, US Gov 버지니아, US Gov 아이오와 등 : 선별된 미국인이 운영하며 추가 규정 준수 인증서를 포함
중국 동부, 중국 북부 등 : Microsoft와 21Vianet 간의 고유한 파트너십을 통해 사용할 수 있으며, Microsoft에서 데이터 센터를 직접 관리하지 않음
관리 인프라
관리 인프라 : Azure 리소스 및 리소스 그룹, 구독 및 계정이 포함
Resource Group (리소스 그룹) : 말그대로 리소스의 그룹
리소스를 만드려면 리소스 그룹 하위에 둬야 함
리소스는 한 개의 리소스 그룹만 연결 가능
자신에게 가장 유용한 방향으로 리소스 그룹을 설정하는 방식을 고려
Subscription (구독) : 관리, 청구 및 크기 조정의 단위 -> 구독은 리소스 그룹을 논리적으로 구성하고 청구를 용이하게 할 수 있음
Azure 구독은 Microsoft Entra ID 또는 Microsoft Entra ID가 신뢰하는 디렉터리에 있는 ID인 Azure 계정과 연결
Management Group (관리 그룹) : Azure 관리 그룹은 구독 상위 수준의 범위를 제공 -> 구독을 관리 그룹이라고 하는 컨테이너에 구성하고 거버넌스 조건을 관리 그룹에 적용
단일 디렉터리에서 지원할 수 있는 관리 그룹 수는 10,000개
관리 그룹 트리에서 지원할 수 있는 최대 깊이 수준은 6
Azure Policy 이니셔티브
Azure Policy : Azure 리소스에 대한 규칙과 효과를 적용하여 IT 거버넌스 표준을 준수하도록 하는 거버넌스 정책을 만들고, 할당하고, 관리할 수 있는 서비스
Azure Policy 이니셔티브 : 특정 목표나 목적을 향해 그룹화된 Azure Policy 정의의 컬렉션
Azure용 Microsoft Cloud Adoption Framework
Azure용 Microsoft Cloud Adoption Framework : Microsoft Azure에 대한 포괄적인 기술 지침을 제공
프레임워크 내에서 Microsoft Azure Policy는 거버넌스 프레임워크에서 중요한 역할을 하여 클라우드 환경과 워크로드를 거버넌스하는 데 도움이 됨
포괄적인 클라우드 거버넌스는 클라우드 사용의 모든 측면을 감독하고, 다양한 위험(예: 규정 준수, 보안, 리소스 관리 및 데이터 관련 우려)을 최소화하며, 조직 전체에서 클라우드 운영을 최적화
Cloud 거버넌스 프로세스 -> 진화하는 기술, 위험 및 규정 준수 요구 사항에 적응하기 위해 지속적인 모니터링, 평가 및 조정이 필요
거버넌스 팀 구성 - 클라우드 거버넌스 정책의 진행 상황을 정의하고, 유지하고, 보고하는 전담 클라우드 거버넌스 팀을 구성합니다.
클라우드 위험 평가 - 규정 준수, 보안, 운영, 비용, 데이터 관리, 리소스 관리, AI 관련 위험을 포함한 모든 위험 범주를 다루며 조직에 맞는 철저한 위험 평가를 수행합니다.
클라우드 거버넌스 정책 문서화 - 허용 가능한 클라우드 사용을 규정하고 식별된 위험을 완화하는 규칙과 지침을 설명하는 클라우드 거버넌스 정책을 명확하게 문서화합니다.
클라우드 거버넌스 정책 시행 - 클라우드 거버넌스 정책 준수를 보장하기 위한 체계적인 접근 방식을 구현합니다. 수동 감독과 함께 자동화된 도구를 사용하여 준수를 시행합니다. 이러한 도구는 가드레일을 설정하고, 구성을 모니터링하고, 정책을 준수하는 데 도움이 됩니다.
클라우드 거버넌스 모니터링 - 클라우드 사용과 거버넌스 팀을 정기적으로 모니터링하여 기존 클라우드 거버넌스 정책을 지속적으로 준수하는지 확인합니다.
클라우드 거버넌스 정책 정의 고려사항
비즈니스 위험 – 데이터 분류와 애플리케이션 중요도에 따라 변화하는 비즈니스 위험과 기업의 위험 허용 범위를 문서화해야 합니다.
정책 및 규정 준수 – 클라우드 도입 경계를 효율적으로 설정하려면 위험 결정을 정책 진술로 전환해야 합니다.
프로세스 – 회사 정책 위반 및 준수 사항을 모니터링하기 위한 프로세스를 수립해야 합니다.
클라우드 거버넌스 핵심 원칙
비용 관리 – IT 지출을 통제하여 잘 정의된 비용 관리를 수립하는 것을 포함하여 비용을 평가하고 모니터링합니다. 또한 수요에 따라 리소스를 조정하는 것도 포함됩니다. 투자에서 더 큰 가치를 얻으려면 클라우드 지출을 통제하는 것이 중요합니다.
보안 기준선 – 모든 도입 노력에 보안 기준을 적용하여 IT 보안 요구 사항 준수를 보장합니다.
리소스 일관성 – 리소스 구성의 일관성을 보장하고 온보딩, 복구 및 검색 가능성에 대한 관행을 시행합니다.
ID 기준선 – 역할 정의와 할당을 일관되게 적용하여 ID 및 액세스에 대한 기준이 시행되도록 보장합니다.
배포 가속화 – 배포 템플릿 전반의 중앙 집중화, 일관성 및 표준화를 통해 정책 배포를 가속화합니다.
=> Azure의 주요 거버넌스 도구는 Azure Policy
Azure Policy
특징
중앙 집중식 관리를 허용 -> 규정 준수 데이터를 한 곳에서, 환경 전반적인 상태를 집계한 뷰 제공
규정 준수 표준을 일관되게 준수하고 잘못된 구성을 방지
기존 리소스에 대한 대량 수정 및 새 리소스에 대한 자동 수정을 통해 리소스를 규정 준수 상태로 만드는 데 도움 -> 비준수 리소스와 구성을 자동으로 수정하여 리소스 상태의 무결성을 보장 -> 해당 리소스를 예외로 표시하면 정책이 자동으로 업데이트되지 않음
Azure Policy를 Azure 플랫폼에 직접 임베드하면 외부 승인 프로세스의 필요성을 크게 줄여 개발자 생산성을 높임
기능
정책을 준수하지 않는 리소스를 강조 표시
비준수 리소스가 생성되는 것을 방지
Storage, Networking, Compute, Security Center 및 Monitoring에 대한 기본 제공 정책 및 이니셔티브 정의가 함께 제공
정책이 생성되기 전에 만들어진 VM을 포함하여 환경의 모든 현재 VM을 평가하고 모니터링
Azure DevOps와도 통합
Azure Policy를 활용한 유용한 작업 예시
팀이 허용된 지역에만 Azure 리소스를 배포하는지 확인하세요.
데이터 상주 요구 사항을 준수하기 위해 지리적 복제 규칙을 적용합니다.
클라우드 환경에는 특정 가상 머신 크기만 허용합니다.
리소스 전체에 걸쳐 분류 태그의 일관된 적용을 시행합니다.
서버에 시스템 업데이트를 권장합니다.
모든 구독 계정에 대해 다중 인증을 허용합니다.
Azure Monitor Logs 작업 영역으로 진단 로그를 전송하려면 리소스가 필요합니다.
Azure Policy를 설계할 때의 목표 : 한 영역에서는 제어와 안정성을, 다른 영역에서는 속도와 결과 간의 균형을 맞추는 것 -> 운영 효율성이나 생산성을 방해하지 않으면서 거버넌스를 보장하는 데 필요한 수준의 제어를 구현할 수 있도록 환경을 매우 관리하기 쉬운 상태로 유지
Azure Policy 계층 구조
위 4개 계층중 하나에 Azure Policy 적용 가능
상위 계층 Azure Policy를 하위에서 상속받음
Azure Resource Manager
Azure Resource Manager : Azure의 배포 및 관리 서비스, Azure 리소스를 만들고, 업데이트하고, 삭제할 수 있는 관리 계층 제공
Azure Resource Manager는 Control Plane과 Data Plane으로 나뉨
Control Plane
Azure Resource Manager는 Control Plane에서 수행되는 모든 작업들을 관리함 (Azure Policy는 수행되는 작업중 하나)
Azure Resource Manager는 아래와 같은 Control Plane의 작업들을 관리하여 배포 후 Azure 리소스에 대한 통합관리 환경 제공
Deploy from ARM Template
Azure Policy
Azure RBAC
Auditing, Logs & Monitoring
Consistent SDKs
Tags Support
Scoping
Graph
Data Plane
Data Plane : 실제 작업이 발생하는 곳, Azure Policy는 Data Plane에서 상호작용하는 리소스가 정책을 준수하는지 확인
데이터 작업이 리소스 정책을 준수하는지 등의 Data Plane 작업은 실제 서비스 엔드포인트에서 진행됨 (ex. Microsoft Azure Storage, SQL 데이터베이스 쿼리 등)
RBAC or ACL과 같은 서비스별 액세스 제어는 Data Plane의 권한도 관리하여 요청자가 올바른 권한을 가지고 있는지 확인함
Azure Policy 확장을 구현하는 것을 통해 Data Plane 작업을 지원할 수도 있음
Microsoft.Kubernetes.Data : Kubernetes 클러스터 및 Pod, 컨테이너, 인그레스와 같은 구성 요소를 관리하는 데 사용
Microsoft.KeyVault.Data : Azure Key Vault의 자격 증명 모음과 인증서를 관리하는 데 사용
Microsoft.Network.Data : Azure Policy를 사용하여 Microsoft Azure Virtual Network Manager 사용자 지정 멤버십 정책을 관리하는 데 사용
Microsoft.ManagedHSM.Data : Azure Policy를 사용하여 Azure Key Vault 관리형 HSM 키를 관리하는 데 사용
Microsoft.DataFactory.Data : Azure Policy를 사용하여 Microsoft Azure Data Factory 아웃바운드 트래픽 도메인 이름을 거부하는 데 사용
Microsoft.MachineLearningServices.v2.Data : Microsoft Azure Machine Learning 모델 배포를 관리하는 데 사용
Azure Resource Manager의 작업 흐름
Azure Resource에 대한 Azure 요청을 처리할 때 두 가지 시나리오가 있음 (Greenfield, Brownfield)
Greenfield (기존재하는 Azure Plicy 기반으로 Azure 리소스를 만들거나 업데이트할 때의 시나리오) : Azure Resource Manager를 호출하여 새 리소스를 만들 때, RBAC 및 Azure Policy 계층을 거쳐 리소스 공급자로 요청 전달 (RBAC 권한이 있어야 Azure Policy 호출되어 모든 정책에 대해 리소스가 검사됨) -> 리소스 생성 및 업데이트
Brownfield (Azure 리소스에 새로운 Azure Policy를 만들어 할당할 때의 시나리오) : 이런 경우 Azure 리소스에 대해 24시간마다 자동으로 Azure Policy 준수 검사 or 수동 검사를 통해 규정 준수 상태 업데이트
규정준수 상태 업데이트 시점 : Greenfield는 ARM을 통해 리소스를 생성 및 업데이트하는 시점, Brownfield는 24시간마다 자동 검사 및 수동 검사 시점
Azure Policy 리소스
Azure에는 6개의 Policy 리소스가 있음
Definitions
Definitions : 리소스 규정 준수 조건과 조건 충족 시 적용되는 효과를 설명
Initiatives
Initiatives : 정책 집합, 단일 항목으로 여러 정책을 그룹화하여 할당 및 관리를 간소화할 수 있음
JSON 형태로 이니셔티브 정의 가능
기본 제공 이니셔티브 : Azure 리소스에 기본적으로 제공되는 정책 그룹 -> Azure 리소스 전반에 중앙 집중식 제어 가능 (다양한 규제 프레임워크, 업계 표준 및 모범 사례 준수 지원)
사용자 지정 이니셔티브 : 기본 제공 이니셔티브로 요구사항이 충족되지 않을 때 작성하는 정책 정의 유형 -> 조직의 고유한 요구 사항에 맞게 정책 집합을 맞춤 설정하여 환경에 가장 적합한 표준과 규칙을 적용할 수 있음
Assignments
Assignments : policy 혹은 initiatives에 의해 평가되는 리소스를 정의
정책 적용에 대해 리소스별 차이를 둘 수 있음
enforcementMode를 비활성화하면 정의를 변경하지 않고도 "가정" 시나리오를 지원 -> 효과는 없지만 정책에 대한 평가 결과는 계속 확인 가능
"deployIfNotExists " 효과 유형 의 정책이 있는 경우, Azure Policy에서 평가할 리소스와 규정 준수에 포함되는 리소스가 결정
Exemptions
Exemptions : 리소스 계층 구조 또는 개별 리소스를 이니셔티브 또는 정의 평가에서 면제
정책 면제는 할당 시점이 아닌 할당 시점 이후에 생성
면제의 두 가지 범주
완화됨 : 정책 의도가 다른 방법을 통해 충족되었기 때문에 면제가 허용
면제 : 리소스의 비준수 상태가 일시적으로 수용되었기 때문에 면제가 허가
Attestations
Attestations : Attestations을 사용하여 수동정책의 대상이 되는 리소스 또는 범위의 규정 준수 상태를 설정할 수 있음. 수동 정책 할당당 하나의 증명이 필요
Remediations
Remediations : 정의 및 할당을 기반으로 리소스를 규정 준수 상태로 만드는 데 사용
Azure Policy 정의
Azure Policy 정의 : 리소스 규정 준수 조건과 해당 조건이 충족될 경우 발생하는 작업 또는 효과를 작성
예시
{
"displayName": "Allowed locations",
"description": "This policy enables you to restrict the locations your organization can specify when deploying resources. Use to enforce your geo-compliance requirements. Excludes resource groups, Microsoft.AzureActiveDirectory/b2cDirectories, and resources that use the 'global' region.",
"policyType": "BuiltIn",
"mode": "Indexed",
"metadata": {
"version": "1.0.0",
"category": "General"
},
"parameters": {
"listOfAllowedLocations": {
"type": "Array",
"metadata": {
"description": "The list of locations that can be specified when deploying resources.",
"strongType": "location",
"displayName": "Allowed locations"
}
}
},
"policyRule": {
"if": {
"allOf": [
{
"field": "location",
"notIn": "[parameters('listOfAllowedLocations')]"
},
{
"field": "location",
"notEquals": "global"
},
{
"field": "type",
"notEquals": "Microsoft.AzureActiveDirectory/b2cDirectories"
}
]
},
"then": {
"effect": "deny"
}
}
}
displayName : 정책 정의 식별 이름
description : 정책에 대한 설명 제공
policyType : 정책의 유형 (기본제공, 사용자지정, 정적)
mode
리소스 관리자 all : 리소스 그룹, 구독 및 모든 리소스 유형을 평가
리소스 관리자 Indexed : 리소스 그룹, 구독 및 모든 리소스 유형을 평가
리소스 공급자 limited to Built in policies and fully supported
리소스 공급자 limited to Built in policies and in preview mode
metadata : 정책 정의에 대한 정보를 저장 (version, category, preview 여부 등)
parameters : 정책 정의에 매개변수를 포함시켜 다양한 시나리오에서 서로 다른 값을 사용하여 해당 정책을 재사용할 수 있도록 함
policyRule : 정책의 효과는 policyRule 에 정의, 정책 규칙은 if 및 then 블록으로 구성
리소스는 Azure Resource Manager, REST API 또는 지원되는 SDK로 할당을 통해 범위에 배포되거나 업데이트
구독(리소스 유형 Microsoft.Resources/subscriptions)은 구독 리소스 유형을 대상으로 하는 할당된 정책 정의를 사용하여 관리 그룹 계층에서 생성되거나 이동
정책 면제가 생성, 업데이트 또는 삭제
표준 준수 평가 주기
머신 구성 리소스 공급자는 관리되는 리소스에 의해 규정 준수 세부 정보로 업데이트
주문형 스캔
리소스 규정 준수 상태
비준수
규정 준수
오류 (템플릿 또는 평가 오류)
충돌 (동일한 범위 내에서 서로 모순되는 규칙을 가진 두 개 이상의 정책 할당, 예: 서로 다른 값을 가진 동일한 태그를 추가하는 두 정책)
보호됨 ( denyAction 효과 가 있는 할당에 따라 보호되는 리소스 )
면제됨 알 수 없음 ( 수동 효과가 있는 정의에 대한 기본 상태 )
준수율 : (준수 + 면제 + 알 수 없음 리소스) / 총 리소스
enforcementMode : 특정 정책 효과의 적용을 비활성화할 수 있는 정책 할당 속성 -> 이 모드를 사용하면 정책 효과를 시작하거나 Azure 활동 로그 에 항목을 트리거하지 않고도 기존 리소스에서 정책 결과를 테스트할 수 있음 -> 일반적으로 What If( 가상 상황) 라고 하며 안전한 배포 관행에 부합
정책 시행 및 안전한 배포 모범사례 : 정책을 코드처럼 처리하면(정책 정의를 소스 제어에 유지하고 변경 사항이 발생할 때마다 해당 변경 사항을 테스트하고 검증) 테스트를 자동화하고 수동 오류 요인이 발생하지 않도록 할 수 있음
새로운 정책 할당부터 시작 : enforcementMode가 비활성화된 상태로 시작하면 작업을 트리거하거나 작업을 거부하지 않고도 규정 준수 상태를 확인하고 정책 결과를 평가할 수 있음 -> What If( 가상 상황)
정책을 작은 하위 집합에서 점진적으로 배포한 후 더 큰 집합으로 배포
정의 생성 : 범위를 루트(테넌트)로 하여 정책 정의를 정의
할당 생성 : 리소스 선택기를 사용하여 배포 링(1~5)을 정의. 링 5에서 특정 범위(예: 리소스 그룹, 구독 또는 관리 그룹)에 정책을 할당. 변경 사항을 적용하지 않고 규정 준수 여부를 평가하려면 EnforcementMode 를 비활성화하여 할당.
규정 준수 검사 - 정책이 올바르게 적용되는지 확인하고 Ring 5의 리소스에 대해 원하는 규정 준수 상태가 달성되었는지 확인합니다.
애플리케이션 상태 점검 - 링 5의 리소스에 대한 정책의 영향을 평가합니다. 예상치 못한 부작용이 없는지 확인합니다.
각 링(비생산 환경)에 대해 반복합니다 . 모든 비생산 환경 링에 대해 3단계를 반복합니다.
할당 업데이트(선택 사항) : 필요한 경우 비생산 환경의 리소스 평가에 따라 정책 정의 또는 할당을 조정한 다음, enforcementMode 가 활성화된 링 5의 리소스에 다시 할당.
규정 준수 확인 : 변경 사항을 적용한 후 규정 준수 여부를 재평가(3a단계와 동일).
애플리케이션 상태 점검 : 다시 한번, 정책이 문제를 일으키지 않는지 확인(3b단계와 동일).
각 링(비생산 환경)에 대해 반복. 모든 비생산 환경 링에 대해 6단계를 반복.
프로덕션 링에 대해서도 반복. 정책이 비프로덕션 환경에서 검증된 후 점진적으로 프로덕션 환경에 배포. 먼저 작은 하위 집합(링)부터 시작하여 시간이 지남에 따라 범위를 확장.
Azure Policy 이벤트
이벤트를 통해 애플리케이션이 정책 상태 변경에 대응
Microsoft Azure Event Grid를 통해 이벤트 처리기로 푸시됨
Microsoft Azure Functions, Microsoft Azure Logic Apps 또는 사용자 지정 HTTP 리스너와 같은 여러 서비스를 구성하여 이벤트를 처리 가능
네트워크 사용자, 관리자, 기타 디바이스 및 application에서 데이터를 사용할 수 있도록 기능 제공
Microsoft Entra ID
구현에 대한 통제력이 줄어들지만, 배포 또는 유지관리에 신경쓰지 않아도 됨
다단계 인증, ID 보호, 셀프서비스 암호 재설정 지원 등 AD DS에서 기본적으로 제공하지 않는 기능도 사용 가능
안전한 액세스 기능 제공
애플리케이션에 대한 액세스를 구성합니다.
클라우드 기반 SaaS 애플리케이션에 SSO(Single Sign-On) 구성
사용자 및 그룹 관리
사용자 프로비전
조직 간 페더레이션 사용
ID 관리 솔루션 제공
비정상적인 로그인 활동 식별
다단계 인증 구성
기존 온-프레미스 Active Directory 구현을 Microsoft Entra ID로 확장합니다.
클라우드 및 로컬 애플리케이션의 애플리케이션 프록시 구성
사용자 및 디바이스의 조건부 액세스 구성
Microsoft Entra ID를 구현하는 것은 Azure에서 가상 머신을 배포하고 AD DS를 추가한 다음, 새 포리스트 및 도메인에 대한 일부 도메인 컨트롤러를 배포하는 것과는 다름 -> AD DS는 온프레미스에 더 중점, Microsoft Entra ID는 클라우드 웹 application에 ID 관리 서비스 제공에 더 중점
Microsoft Entra 테넌트
테넌트란?
테넌트는 하나의 ID (개인, 기업, 조직 단위)
테넌트는 한 개 혹은 여러 개의 구독을 가질 수 있음
구독에서 Azure 컴퓨팅 리소스 사용 가능 (ex. VM, storage, network 등)
구독당 여러 개의 Microsoft Entra 테넌트 생성 가능
구독->테넌트 연결은 한 개만 연결 가능
테넌트->구독 연결은 여러개 가능 -> RBAC를 통해 Azure 구독의 리소스에 대한 권한을 특정 Microsoft Entra 테넌트에 있는 사용자, 그룹, 애플리케이션에 부여
AD DS vs Microsoft Entra ID
AD DS : AD DS는 물리적 서버 또는 가상 서버에 Windows Server 기반 Active Directory를 배포한 것
AD DS 특징
AD DS는 계층적 X.500 기반 구조를 사용하는 진정한 디렉터리 서비스입니다.
AD DS는 DNS(Domain Name System)를 사용하여 도메인 컨트롤러와 같은 리소스를 찾습니다.
LDAP(Lightweight Directory Access Protocol) 호출을 사용하여 AD DS를 쿼리하고 관리할 수 있습니다.
AD DS는 인증하기 위해 Kerberos 프로토콜을 주로 사용합니다.
AD DS는 관리를 위해 OU 및 GPO를 사용합니다.
AD DS에는 Active Directory 도메인에 가입하는 컴퓨터를 나타내는 컴퓨터 개체가 포함됩니다.
AD DS는 위임된 관리를 위해 도메인 간의 트러스트를 사용합니다.
Microsoft Entra ID 특징
Microsoft Entra ID는 주로 ID 솔루션으로, HTTP(포트 80) 및 HTTPS(포트 443) 통신을 사용하여 인터넷 기반 애플리케이션용으로 설계되었습니다.
Microsoft Entra ID는 다중 테넌트 디렉터리 서비스입니다.
Microsoft Entra 사용자 및 그룹은 플랫 구조로 생성되며 OU나 GPO는 없습니다.
LDAP를 사용하여 Microsoft Entra ID를 쿼리할 수 없습니다. 대신 Microsoft Entra ID는 HTTP 및 HTTPS를 통해 REST API를 사용합니다.
Microsoft Entra ID는 Kerberos 인증을 사용하지 않는 대신, SAML, WS-Federation 및 OpenID Connect와 같은 HTTP 및 HTTPS 프로토콜을 사용하여 인증하고 권한 부여에 OAuth를 사용합니다.
Microsoft Entra ID에는 페더레이션된 서비스가 포함되어 있고 Facebook과 같은 많은 타사 서비스가 Microsoft Entra ID와 페더레이션되며 Microsoft Entra ID를 신뢰합니다.
요약 => Mircosoft Entra ID 서비스는 클라우드 application용 SSO 서비스로 보임. => 그리고 테넌트(개인, 회사, 조직) 단위로 관리됨. => 테넌트는 하나의 구독에 의해 만들어지고, 여러 구독에서 접근할 수 있음 => AD DS는 온프레미스 서비스에 집중, Microsoft Entra ID 서비스는 클라우드 application 서비스에 집중 => 다양한 액세스 및 보안 기능 제공 (위 내용 참고) => Microsoft 365, Azure, Microsoft Dynamics 365, Intune과 같은 모든 Microsoft 클라우드 기반 서비스를 포함할 수 있는 ID를 가질 수 있음
Microsoft Entra Plan
P1, P2 : 일반적인 plan
프리미엄 : 가장 높은 등급, 사용자가 추가될 때마다 추가요금 부과
P1, P2 plan 공통 기능
셀프 서비스 그룹 관리 : 사용자에게 그룹을 만들고 관리할 수 있는 권한이 부여되는 그룹 관리를 간소화합니다. 최종 사용자는 다른 그룹에 가입 요청을 생성할 수 있으며 그룹 소유자는 요청을 승인하고 그룹의 멤버 자격을 유지할 수 있습니다.
고급 보안 보고서 및 경고 : 비정상과 일관성 없는 액세스 패턴에 대한 고급 보고서를 보여 주는 상세 로그를 확인하여 클라우드 애플리케이션에 대한 액세스를 모니터링하고 보호할 수 있습니다. 고급 보고서는 기계 학습 기반이며 액세스 보안을 개선하고 잠재적 위협에 대응하는 새로운 인사이트를 얻는 데 도움이 될 수 있습니다.
다단계 인증 : 전체 MFA(다단계 인증)는 온-프레미스 애플리케이션(VPN[가상 사설망], RADIUS 등을 사용), Azure, Microsoft 365, Dynamics 365, 타사 Microsoft Entra 갤러리 애플리케이션에서 작동합니다. Microsoft Outlook과 같이 브라우저에 기반하지 않은 상용 앱에서는 작동하지 않습니다. 전체 다단계 인증은 이 단원의 다음 단계에서 자세히 설명합니다.
Microsoft Identity Manager(MIM) 라이선싱 : MIM은 Microsoft Entra ID P1 또는 P2와 통합하여 하이브리드 ID 솔루션을 제공합니다. MIM은 AD DS, LDAP, Oracle, 기타 애플리케이션과 같은 여러 온-프레미스 인증 저장소를 Microsoft Entra ID와 연결할 수 있습니다. 이는 온-프레미스 LOB(기간 업무) 애플리케이션과 Saas 솔루션에 일관성 있는 경험을 제공합니다.
99.9%의 엔터프라이즈 SLA : Microsoft Entra ID P1 또는 P2 서비스의 가용성이 99.9% 이상 보장됩니다. 동일한 SLA가 Microsoft Entra Basic에 적용됩니다.
쓰기 저장을 사용하여 암호 재설정 : 셀프 서비스 암호 재설정은 Active Directory 온-프레미스 암호 정책을 따릅니다.
Microsoft Entra ID의 Cloud App Discovery 기능입니다. 이 기능은 가장 자주 사용되는 클라우드 기반 애플리케이션을 검색합니다.
디바이스나 그룹, 위치를 기반으로 하는 조건부 액세스 : 이렇게 하면 여러 기준에 따라 중요한 리소스에 대한 조건부 액세스를 구성할 수 있습니다.
Microsoft Entra Connect Health : 이 도구를 사용하여 Microsoft Entra ID에 대한 운영 인사이트를 얻을 수 있습니다. 경고, 성능 카운터, 사용 패턴, 구성 설정과 함께 작동하며 Microsoft Entra Connect Health 포털에서 수집된 정보를 제공합니다.
P2 plan 추가 기능
Microsoft Entra ID 보호 : 이 기능은 사용자 계정을 모니터링하고 보호하기 위한 향상된 기능을 제공합니다. 사용자 위험 정책 및 로그인 정책을 정의할 수 있습니다. 또한 사용자의 동작을 검토하고 사용자에게 위험에 대한 플래그를 지정할 수 있습니다.
Microsoft Entra Privileged Identity Management : 이 기능을 사용하면 관리자와 같은 권한 있는 사용자에 대한 추가 보안 수준을 구성할 수 있습니다. Privileged Identity Management를 사용하면 영구 및 임시 관리자를 정의합니다. 또한 누군가가 관리 권한을 사용하여 일부 작업을 수행하려고 할 때마다 활성화되는 정책 워크플로를 정의합니다.
Microsoft Entra Domain Services
As-Is : 온프레미스로 application을 구동할 때 인증기능은 AD DS 기반 자격증명 활용 -> Application이 Azure 인프라를 활용하는 경우, 로컬 인프라와 Azure IaaS 간에 사이트 간 VPN(가상 사설망)을 구현하거나 Azure에서 로컬 AD DS의 복제본 도메인 컨트롤러를 VM(가상 머신)으로 배포하여 인증기능 구현
To-Be : Microsoft Entra Domain Services
Microsoft Entra Domain Services : 위에서 언급된 로컬 배포된 AD DS 인증기능의 대안으로서 그룹 정책 관리, 도메인 가입, Kerberos 인증과 같은 도메인 서비스를 Microsoft Entra 테넌트에 제공하는 서비스 -> 로컬로 배포된 AD DS와 완전히 호환되므로 클라우드에서 추가 도메인 컨트롤러를 배포하고 관리할 필요 없이 사용 가능
특징
Microsoft Entra Connect를 구현하면 사용자는 온-프레미스 AD DS와 Microsoft Entra Domain Services 모두에서 조직 자격 증명을 활용 가능
AD DS를 로컬에 배포하지 않은 경우에도 Microsoft Entra Domain Services를 클라우드 전용 서비스로 사용하도록 선택 가능
방법 : 조직은 Microsoft Entra 테넌트를 만들고 Microsoft Entra Domain Services를 사용하도록 설정한 다음 온-프레미스 리소스와 Microsoft Entra 테넌트 간에 가상 네트워크를 배포하도록 선택 -> 모든 온-프레미스 사용자 및 서비스가 Microsoft Entra ID의 도메인 서비스를 사용할 수 있도록 이 가상 네트워크에 대해 Microsoft Entra Domain Services를 사용하도록 설정
이점
관리자가 도메인 컨트롤러를 관리, 업데이트, 모니터링할 필요가 없음
관리자가 Active Directory 복제본을 배포하고 관리할 필요가 없음
Microsoft Entra ID가 관리하는 도메인에 대해서는 도메인 관리자 또는 엔터프라이즈 관리자 그룹이 필요하지 않음
LDAP, NTLM 또는 Kerberos 프로토콜을 사용하는 애플리케이션을 온-프레미스 인프라에서 클라우드로 자유롭게 마이그레이션
한계
기본 컴퓨터 Active Directory 개체만 지원
Microsoft Entra Domain Services 도메인에 대한 스키마를 확장하는 것은 불가능
OU(조직 구성 단위) 구조는 수평적이며 중첩된 OU는 현재 지원되지 않음
기본으로 제공되는 GPO(그룹 정책 개체)가 있으며 컴퓨터와 사용자 계정에 대해 존재
기본 제공 GPO를 사용하는 OU를 대상으로 할 수 없습니다. 또한 WMI(Windows Management Instrumentation) 필터 또는 보안 그룹 필터링을 사용할 수 없음
ID 생성, 구성, 관리
Azure 리소스 사용을 위해서 Azure 사용자 계정이 필요 -> 제어가 필요한 리소스에 대한 Microsoft Entra에 사용자 계정 등록
리소스 사용 시, 사용자 정보 기반으로 로그인 프로세스 진행 -> Microsoft Entra ID로부터 액세스 토큰 발급 -> 토큰의 권한에 따라 리소스 액세스 가능
Microsoft Entra ID에서 정의한 사용자 유형
클라우드 ID : Microsoft Entra ID에만 존재, 리소스 제어가 필요하여 다른 Microsoft Entra 인스턴스의 계정이 등록된 경우도 있음 (해당 경우에 다른 Microsoft Entra에서 계정이 삭제될 경우, 다른 모든 Microsoft Entra에서 계정 삭제됨) -> Micosoft Entra ID 하위로 Microsoft Entra 인스턴스가 있는듯...? 추측
디렉터리 동기화된 ID : 온프레미스 Active Directory에 존재하는 ID, Microsoft Entra Connect를 통한 동기화 작업으로 계정을 Azure로 가져옴 (출처는 Windows Server AD)
게스트 사용자 : Azure 외부에 존재하는 사용자 계정 (ex. 다른 클라우드 공급자 계정, Xbox와 같은 Microsoft 계정 등), 외부 사용자가 해당 리소스에 사용해야하는 경우
Microsoft Entra Device
Microsoft Entra Join Device
요약
Microsoft Entra ID 에 사용자 (ID)를 추가할 수 있음 (추가 형태는 위 유형 참고)
사용자 추가는 Microsoft Entra ID 관리자 권한
일반 사용자는 게스트 사용자 유형으로만 추가할 수 있음
추가된 사용자는 동일 Microsoft Entra의 그룹에 할당될 수 있음 (Microsoft Entra ID - 그룹 - 사용자, 계층 형성)
그룹 유형
보안 그룹 : 공유 리소스에 대한 구성원 및 컴퓨터 액세스를 관리하는 데 사용
Microsoft 365 그룹 : 공유 사서함, 일정, 파일, SharePoint 사이트 등에 대한 액세스 권한을 구성원에게 부여
그룹 사용자 추가 유형
할당됨 : 그룹 구성원이 수동으로 추가
동적 할당 : 임의로 설정한 규칙에 따라 조건에 부합하는 Microsoft Entra ID내 사용자를 자동으로 그룹에 추가
그룹에 라이선스 할당을 할 수 있음
Microsoft Entra ID 관리자 권한
Microsoft Entra ID에서 삭제된 사용자는 30일 이내에 다시 복원 가능
Microsoft Entra ID 관리자 권한
Microsoft Entra Device : 조직에서의 Device에 대한 정책 적용 가능
조직 리소스에 액세스하기 위해 추가로 연결된 Microsoft Entra 계정이 있음 -> 조직의 Microsoft Entra 계정인듯
디바이스가 준수해야하는 규칙이 있을 경우 추가 제한 여지 있음
MDM(모바일 디바이스 관리) 도구를 사용하여 이러한 Microsoft Entra 등록 디바이스를 보호하고 추가로 제어
MDM : 스토리지 암호화, 암호 복잡성 유지, 보안 소프트웨어 업데이트 등 기능 제공
Microsoft Entra 조인을 사용하여 클라우드와 온-프레미스 앱 및 리소스에 모두 액세스 가능
클라우드 및 온-프레미스 리소스 모두에 대한 SSO, 조건부 액세스, 셀프 서비스 암호 재설정 및 Windows Hello PIN 재설정 가능
조직의 Microsoft Entra 계정을 사용하여 로그인
라이선스 관리 - 유료 클라우드 서비스 활용을 위해 라이선스 할당 필요
대규모 관리를 위해 Microsoft Entra ID 그룹 기반 라이선스 할당 활용
라이선스 갯수는 최소 사용자 수에 맞게 준비되어야 함 -> 모든 사용자가 유료 서비스를 활용할 수 있도록
최종 사용자 라이선스는 여러 그룹 및 그룹 외부로부터 할당된 제품 및 서비스 라이선스의 조합 -> 라이선스가 중복될 경우 1개만 사용됨
사용자 지정 보안 특성 : 사용자별로 집합 관리를 위한 메타정보 세팅 가능 (key-value 형태)
SCIM(System for Cross-domain Identity Management) : ID 도메인과 IT 시스템 간의 사용자 ID 정보 교환을 자동화하기 위한 개방형 표준 프로토콜 -> SCIM을 사용하면 HCM(Human Capital Management) 시스템에 추가된 직원이 Microsoft Entra ID 또는 Windows Server Active Directory에서 만든 계정을 자동으로 갖게 됨 (시스템간 동기화)
