728x90
반응형
Azure의 핵심 아키텍처 구성 요소 설명
Azure 계정
- 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 블록으로 구성
- if블록 연산자
- not : 조건의 결과 반전
- allOf : 모든 조건이 참이어야 함
- anyOf : 하나 이상의 조건이 참이어야 함
Azure Policy를 통한 리소스 평가
- 할당된 정책과 이니셔티브에 대한 평가는 다양한 이벤트의 결과로 발생
- 정책이나 이니셔티브가 범위에 새로 할당
- 범위에 이미 할당된 정책이나 이니셔티브가 업데이트
- 리소스는 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 리스너와 같은 여러 서비스를 구성하여 이벤트를 처리 가능
반응형
'개발 > Azure' 카테고리의 다른 글
| [Azure] Azure내 스토리지 구현 및 관리 - Azure Blob Storage (0) | 2025.05.10 |
|---|---|
| [Azure] Azure내 스토리지 구현 및 관리 - 스토리지 계정 구성 (0) | 2025.04.28 |
| [Azure] Azure내 ID 및 거버넌스 관리 - Azure RBAC (0) | 2025.04.13 |
| [Azure] Azure내 ID 및 거버넌스 관리 - Microsoft Entra ID (0) | 2025.04.06 |
| [Azure] Azure 관리자 필수 조건 (0) | 2025.03.30 |
