본문 바로가기
Data Engineering/Cloud_Azure

AZ-104 (준비중)

YD_data 2025. 5. 2. 18:59

학습계획 : 2025/06/15 이전 취득

교재 : Microsoft Doc + Dump

 

[학습순서]

05/02 - 15:00~17:00 = AZ-104 Guide Vedio 시청 및 학습 계획 수립

           - 17:00~19:00 = Docs 정리 (2. Identity & Governance - 2.1 Entra ID)

           - 22:00~24:00 = Docs 정리 (2. Identity & Governance - 2.2 ID생성/구성/관리)

05/06 - 22:20~00:10 = Docs 정리 (2. Identity & Governance - 2.4 Azure Policy 이니셔티브)

05/10 - 17:40~18:00 = Docs 정리 (2. Identity & Governance - 2.5 Azure RBAC 리소스 보안)

             18:10~18:30 = Docs 정리 (2. Identity & Governance - 2.6 셀프 서비스 암호 재설정)
05/11 - 13:30~14:00, 17:30~18:00 = Docs 정리 (+ Azure Key Vault에서 비밀 구성 및 관리)

             19:30~20:00 = Docs 정리 (1. Azure Administrator 필수 조건 - 1.1 Portal 사용하여 서비스 관리)

             22:40~24:30 = Docs 정리 (1. Azure Administrator 필수 조건 - 1.2~1.5)

05/18 - 21:20~22:00 = Docs 정리 (3. Storage - 3.1 Storage Account 구성)

05/19 - 08:00~08:30 = Docs 정리 (3. Storage - 3.1 Storage Account 구성)

              22:10~23:00 = Docs 정리 (3. Storage - 3.1 Storage Account 구성)

              23:10~24:00 = Docs 정리 (3. Storage - 3.2 Azure Blob Storage 구성)

06/03 - 19:40~20:30 = Docs 정리 (3. Storage - 3.3 Azure Storage 보안 구성)

            - 21:20~22:00 = Docs 정리 (3. Storage - 3.4 Azure Files 구성 : 공유 폴더 구성하기)

            - 22:00~23:00 = Docs 정리 (4. Compute - 4.1 Azure Virtual Machine 소개)

06/04 - 20:00~21:00 = Docs 정리 (4. Compute - 4.2 가상 머신 가용성 구성)

            - 21:00~21:30 = Docs 정리 (4. Compute - 4.3 Azure App Service 계획 구성)

            - 21:30~22:30 = Docs 정리 (4. Compute - 4.4 Azure App Service 구성)

            - 22:30~23:20 = Docs 정리 (4. Compute - 4.5 Azure Container Instances 구성)

06/06 - 14:00~15:00 = Docs 정리 (5. Network - 5.1 가상 네트워크 구성)

            - 15:00~15:25 = Docs 정리 (5. Network - 5.2 네트워크 보안 그룹 구현)

06/09 - 23:20~00:00 = Docs 정리 (5. Network - 5.3 Azure DNS에서 도메인 호스트)

 

 

MS Certification Tip

1. Microsoft 자격증 정리 링크 : https://arch-center.azureedge.net/Credentials/Certification-Poster-en-us.pdf

2. 900 - 104 - 305를 취득하는 것이 가장 빠른 Expert 취득 루트 (아래는 참고 이미지 : 펌)

[Certi Relation] from : https://www.freecodecamp.org/news/azure-administrator-certification-az-104-pass-the-exam-with-this-free-11-hour-course/

[AZ-104 시험 준비 방법 링크]

 1) Azure
administrator
(3h)		 [학습자료] Portal/Shell/ARM
사용법
2) Manage
identities &
governance
(5h) (20~25%)		 [영상링크]
[학습자료]
 Entra ID/Policy
/RBAC의 관리법
3) Storage
(3h) (15~20%)		 [영상링크]
[학습자료]
  
4) Compute
Resource
(4h) (20~25%)		 [영상링크]
[학습자료]
  
5) Virtual Net
& Security
(5h)(15~20%)		 [영상링크]
[학습자료]
  
6) monitor &
back up
(4h)(10~15%)		 [영상링크]
[학습자료]
  
7) summary
pre-test (6h)		    

 

1) Azure administrator 필수 조건

 

[Keywords]

Portal/Shell/ARM

 

[Reference]

[상세 내용]

1-1) Azure Portal을 사용하여 서비스 관리 (05/11 19:30~20:00)

  • Azure 관리 옵션 (3분 예상 -> skip) : portal, shell, cli 소개
    포털 탐색 (8분 예상 -> 5분 소요 )
    : portal의 설정에서 할 수 있는 작업 : 디렉토리 및 구독 관리, 비활성 로그아웃 시간 설정, 포털 메뉴 옵션, 색상, 언어, 지역 선택
    : 프로필에서 할 수 있는 작업 : 권한 확인, 아이디어 제출, 청구서 보기, 연락처 업데이트, 암호 변경
    : Azure advisory 항목 : 고가용성, 보안, 운영, 비용 권장사항 및 체점
  • Azure Portal 대시보드 (8분 예상 -> 10분 소요)
    : 리소스 상태에 대한 대시보드를 구성하여 배포하고, 팀원들과 공유할 수 있다.
    : JSON으로 구성 가능하며 기본적인 Azure 전반의 숫자들을 모아서 관리할 수 있다. 
      대표적으로는 Resource Graph, Cosmos DB, Application Insight, SQL DB, VM, App Service, IoT Hub 상태를 제공한다

1-2) Azure Cloud Shell 소개

  • Azure Cloud Shell이란? (10분 예상 -> 5분 소요)
    : 웹브라우저 기반의 명령줄 환경, SSH키, 스크립트 등과 같은 파일을 유지하는 스토리지 제공
  • Azure Cloud Shell 작동 방식 (6분 예상 -> 10분 소요)
    : shell.azure.com에 접속하거나, Azure Portal의 GUI 버튼으로 접속 가능
    : PowerShell 혹은 Bash 둘 중 하나를 선택해서 사용 가능
    : 인증이 필요하며, 기본은 20분 활동 없을 시 자동 종료된다.
    : 별도 공간에 파일을 업로드하여 사용할 수 있고, 타 저장소를 연결할 수도 있다.
    code temp.txt처럼 입력하면 해당 파일을 편집하는 화면이 등장한다.

  • Azure Cloud Shell을 사용해야 하는 경우 (3분예상 -> 3분 소요)
    : sudo 권한이 필요하거나, 리전/지역이 다른 콘텐츠를 필요로 하는 경우, 동시에 여러 세션을 열어야 하는 경우는
      Cloud Shell로 처리하기 어려움

Cloud Shell에서 사용 가능한 명령어/기능은 아래와 같다.

Linux 도구 bash / zsh / sh / tmux / dig
Azure 도구 Azure CLI 및 Azure 클래식 CLI / AzCopy /Azure Functions CLI
Service Fabric CLI / Batch Shipyard / blobxfer
텍스트 편집기 코드(Cloud Shell 편집기) / vim / nano / emacs
원본 제어 git
빌드 도구 make / maven / npm / pip
컨테이너 Docker 컴퓨터 / Kubectl / Helm / DC,OS CLI
데이터베이스 MySQL / PostgreSql 클라이언트 / sqlcmd 유틸리티 / mssql-scripter
기타 iPython 클라이언트 / Cloud Foundry CLI / Terraform / Ansible / Chef InSpec
Puppet Bolt / HashiCorp Packer / Office 365 CLI

 

1-3) Bash 소개

  • Bash란? (5분 예상 -> 2분 소요)
    : Linux용 표준 셸 스크립팅 언어 (Bourne Again Shell), Shell = os에 작업을 명령하는 프로그램
  • Bash 기본 사항 (8분 예상 -> skip) : bash 명령어 설명 (ls, man, 정규식, *)
  • Bash 명령 및 연산자 (10분 예상 -> 5분 소요)
    : cat, sudo, cd, mkdir, rmdir, rm, cp, ps -ef, grep, more, head
    : < 입력 리디렉션, > 출력 리디렉션, >> 동일 작업 수행하되 덮어쓰지 않고 추가, | 한 명령어 수행 후 다른 명령 입력
  • : VM 중 DS SKU를 사용하는 것들을 찾으려면
    az vm list-skus --location westus --output table | grep DS 입력 -> "DS" 텍스트가 있는 행만 필터링

1-4) PowerShell 소개

  • PowerShell이란? (4분 예상 -> 5분 소요)
    : window 관리 작업을 자동화하는 셸이자 스크립팅 언어 프레임워크, 작업 래핑을 위해 cmdlet을 사용하는 작업 엔진으로 설계됨.
  • 명령 찾기 (3분 예상 -> 5분 소요)
    : Get-Verv (동사 명령어 리스트 반환), Get-Command, Get-Help, Get-Member
    : [예시] Get-Command -Verv Get -Noun alias* = 동사가 Get이고, 명사가 Alias* 인것을 찾아라.

1-5) JSON ARM 템플릿을 사용하여 Azure 인프라 배포

  • ARM은 IaC(Infrastructure as Code)를 위해 Bicep 또는 JSON으로 작성됨.
  •  
  • : IaC : App 필요한 인프라를 코드로 중앙 집중형 관리하는 개념. 구성의 일관성, 빠른 배포 및 확장, 추적 강화 장점을 가짐.
    : ARM 템플릿 : JSON 파일로 리소스에 대한 명세가 기록됨.
      템플릿이 Resource Manager에 전달되면, 리소스 생성 계획을 검토한 후, 최선의 계획을 통해 병렬로 생성 진행됨.
      배포가 복잡해지면, ARM템플릿들을 작은 단위로 분리해서 관리할 수 있고, 배포의 결과 값을 바탕으로 분기할 수도 있음.
      Azure Pipeline 같은 CI/CD 툴에 통합하여 사용 가능하고, 주 템플릿에서 서브 템플릿을 호출하여 실행할 수도 있음.
    : [배포 코드 예시 (CLI)]
      templateFile="{provide-the-path-to-the-template-file}"
      az deployment group create \
            --name blanktemplate \
            --resource-group myResourceGroup \
            --template-file $templateFile
    : 템플릿에 리소스 추가 = [리소스 공급자 목록] , [속성 리스트] 
    : 변화가 없는 ARM 템플릿을 다시 배포하면 변경이 일어나지 않는다.
  • : 배포할 리소스 그룹을 잘 지정하고 실행한다.
    : ARM 템플릿 파일은 VS CODE에서 자동완성을 이용하여 작성이 가능하다. tab키를 사용하여 가능한 옵션들을 보며 작성한다.
  • : Parameters, outputs를 활용하여 이름의 하드코딩 같은 반복성 제약을 해결
      템플릿 당 파라미터는 256개로 제한되며, string, secureString, integers,boolean,object,secureObject,array 사용 가능

[ARM 요소설명]

schema JSON 데이터의 구조를 설명하는 JSON 스키마 파일의 위치를 정의하는 필수 섹션입니다. 사용할 버전 번호는 배포 범위 및 JSON 편집기에 따라 다릅니다.
콘텐츠 버전 템플릿 버전을 정의하는 필수 섹션입니다(예: 1.0.0.0). 이 값을 사용하여 템플릿의 중요한 변경 내용을 문서화하고 올바른 템플릿을 배포하는지 확인할 수 있습니다.
api Profile 리소스 종류의 API 버전 컬렉션을 정의하는 선택적 섹션입니다. 이 값을 사용하면 템플릿에 있는 각 리소스의 API 버전을 지정하지 않을 수 있습니다.
parameters 배포 중에 제공되는 값을 정의하는 선택적 섹션입니다. 매개 변수 파일, 명령줄 매개 변수 또는 Azure Portal에서 해당 값을 제공할 수 있습니다.
variables 템플릿 언어 식을 간소화하는 데 사용되는 값을 정의할 선택적 섹션입니다.
functions 템플릿 내에서 사용할 수 있는 사용자 정의 함수를 정의할 수 있는 선택적 섹션입니다. 템플릿에서 반복적으로 사용되는 복잡한 식이 있는 경우 사용자 정의 함수를 사용하여 템플릿을 간소화할 수 있습니다.
resources 리소스 그룹 또는 구독에서 업데이트하거나 배포하려는 실제 항목을 정의하는 필수 섹션입니다.
Outputs 배포 종료 시 반환되는 값을 지정할 선택적 섹션입니다.
resource 템플릿 예시 parameters 예시
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageName": {
      "type": "string",
      "minLength": 3,
      "maxLength": 24,
      "metadata": {
        "description": "The name of the Azure storage resource"
      }
    },
    "storageSKU": {
      "type": "string",
      "defaultValue": "Standard_LRS",
      "allowedValues": [
        "Standard_LRS",
        "Standard_GRS",
        "Standard_RAGRS",
        "Standard_ZRS",
        "Premium_LRS",
        "Premium_ZRS",
        "Standard_GZRS",
        "Standard_RAGZRS"
      ]
    }
  },
  "functions": [],
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2023-05-01",
      "name": "[parameters('storageName')]",
      "tags": {
        "displayName": "[parameters('storageName')]"
      },
      "location": "[resourceGroup().location]",
      "kind": "StorageV2",
      "sku": {
        "name": "[parameters('storageSKU')]"
      }
    }
  ],
  "outputs": { "storageEndpoint": { "type": "object", "value": "[reference(parameters('storageName')).primaryEndpoints]" }
}		 "parameters": {
  "storageAccountType": {
    "type": "string",
    "defaultValue": "Standard_LRS",
    "allowedValues": [
      "Standard_LRS",
      "Standard_GRS",
      "Standard_ZRS",
      "Premium_LRS"
    ],
    "metadata": {
      "description": "Storage Account type"
    }
  }
}
Outputs 예시
"outputs": {
  "storageEndpoint": {
    "type": "object",
    "value": "[reference('learntemplatestorage123').primaryEndpoints]"
  }
}
templateFile="azuredeploy.json"
today=$(date +"%d-%b-%Y")
DeploymentName="addSkuParameter-"$today
az deployment group create \
      --name $DeploymentName \
      --template-file $templateFile \
      --parameters storageSKU=Basic storageName={your-unique-name} <- 배포 시 파라미터 지정

 

2) Manage Identity & Governance (20~25%)

 

[Keywords]

EntraID / Resource Control / Subscription & Governance / Policy / ARM

 

[Reference]

Entra ID 문서

DS = Directory Service = 컴퓨터 네트워크에 있는 사용자 및 자원에 대한 정보를 저장하고 관리하는 소프트웨어 및 응용 프로그램

DAP = Directory Access Protocol = X.500, LDAP가 대표적 [설명 링크]

 

[상세 내용]

 

2-1) Entra ID 이해 (05/02 17:00~19:00)

  •  
    - Entra ID
       : Azure의 ID, Group 및 Access 관리 서비스, Web 기반 (PaaS, Online 비즈니스 서비스 구독 시 자동 제공)
       : 제공 기능은 MFA(다단계 인증), ID보호, 셀프 암호 재설정, App 접근, SaaS에 대한 SSO, 조직 간 페더레이션, 사용자 프로비젼,
                            비정상 접근 탐지, On-prem AD 통합, 프록시 구성, 조건부 엑세스 등이 있다.
                            (On-prem 위주의 AD-DS에서 제공하지 않는 기능들)
       : 기존 AD-DS (On-prem DS서비스)와 비교하여 제공하지 않는 기능은
         '컴퓨터 클래스 단위 스키마 클래스 - GPO와 같은 기존 관리 그룹 사용 불가', OU 클래스 활용 불가 등이 있다.
       : 테넌트는 기본적으로 하나의 '기업'을 의미하지만 하나의 기업에서 여러 테넌트를 보유할 수 있고,
         하위에 복수의 구독(Subscription : 청구/계약단위)연결이 가능하여, 여러 MSP와의 계약이 하나의 테넌트에 매칭될 수 있다.
       (MS 전사적 측면에서 보면 다중 테넌트 디렉토리 구조, 100만개의 디렉터리, 매주 10억 건의 인증 스케일)
     
  • Microsoft Entra ID 검사 (7분 예상 -> 실제 40분 소요)
  • - AD-DS
       : 물리 서버에 구성, 클라우드 이전 On-prem에 구성되던 Window Server의 Directory Service
       : Windows Active Directory 제품군의 하나 (AD CS(인증서), FS(Federation), LDS, RMS 등 AD DS외 제품군 존재)
       : 계층적 X.500 기반 구조를 사용하는 전통적인 DS, LDAP도 사용 가능. 인증에는 Kerberos 프로토콜을 주로 사용
  •    : OU, GPO 개념을 사용하며, 컴퓨터 개체 관리 가능 (Entra ID에서는 제공하지 않음)
  •    : DS간 위임된 관리를 위해 도메인 간 트러스트 사용

  • ★ Entra ID는 HTTP(80), HTTPS(443) 인터넷 기반 Rest API로 통신하며, AD-DS는 X.500, LDAP 등 사용
  •      Entra ID의 사용자 및 그룹은 플랫 구조여서, AD-DS의 트리 구조 OU, GPO와 차이가 있음.
  •      Entra ID는 SAML, WS-Federation, OpenID Connect같은 HTTP,HTTPS 프로토콜로 인증하고, 권한 부여에 OAuth를 사용
  •      AD-DS는 Kerberos 사용
  •      Entra ID로 Facebook과 같은 타사 서비스와 신뢰 가능한 페더레이션 설정 가능.
  •  
  • - Cloud App's Directory [추가 설명 문서]
    : Azure 외부의 Application에서 Entra ID 인증을 사용하려면 복잡한 과정이 필요하지만,
      Azure 리소스 (Azure WebApp 등의 앱 호스팅 서비스)에 Entra ID를 통한 인증을 연결하는 것은 수월하다.
  • Microsoft Entra ID P1 및 P2 계획 비교 (4분 예상 -> 10분 소요)
    프리미엄 라이선스를 사용하면 추가 기능들을 사용할 수 있지만, 사용자 프로비저닝당 추가 비용이 발생한다. [가격]
    Microsoft Enterprise Mobility 및 Security의 일부로 조달 가능하며 여기엔 Information Protection, Intune 라이선스가 포함
    - P1 License 추가 기능
    : ML 기반 고급 보안 보고서, MFA, MIM(타 On-prem DS와의 연동), SLA 99.9%, 조건부 엑세스(Device, Location 엑세스 제약)
      Cloud App Discovery(자주 사용되는 App탐지), Connect Health(경고, 성능 카운터, 패턴 등 모니터)
    - P2 License 추가 기능
    : Entra ID 보호 (사용자 별 위험/로그인 정책/플래그 지정), Privileged Identity Management(운영 권한 사용자 지정 기능)
     
  • - Domain Service
    : AD-DS를 Entra ID와 연동하여 application들에 자격증명을 제공하고 싶을 때,
      On-prem <-> Cloud의 VPN을 구성하거나, VM에 AD-DS 복제본 도메인 컨트롤러를 배포할 수 있으나 비용이 수반된다.
      하여 매개 서비스인 Domain Service를 P1,P2 기능으로 제공한다. (그룹정책 관리, 도메인 가입, Kerberos 인증 제공)
      비용은 디렉토리 크기에 따라 시간 단위 종량제로 청구된다. 
      -> 관리자의 도메인 컨트롤러 관리/업데이트/모니터 필요, Active Directory 복제본 관리 필요 제거
      -> 중첩된 OU는 사용할 수 없으며, 스키마 확장이 불가합니다. 기본 컴퓨터 AD개체만 지원되며 GPO의 OU를 대상으로 사용 불가
 

2-2) ID생성, 구성, 관리 (05/02 22:00~24:00)

        클라우드 이전 시, 페르소나 정의를 통해 필요한 만큼만 권한을 제어하는 정책을 구성해야 한다.

        사용자 생성, 구성, 관리 (2분 예상 -> 5분 소요)

        : 로그온으로 인증이 완료되면 EntraID에서 엑세스 토큰을 작성하고, 이는 권한을 부여하고 수행 가능한 작업을 결정

        : 클라우드 ID (EntraID에서 생성된 ID), 디렉토리 동기화된 ID (On-prem AD 계정이 Entra Connect로 동기화된 경우), 게스트

        : 관리자 권한이 있을 경우, 삭제 30일 이전에는 사용자를 복구할 수 있음. ('삭제된 사용자 항목' 탭에서 복구하기 클릭)

  •  
  • 그룹 생성, 구성, 관리 (3분 예상 -> 3분 소요)
  • : 그룹의 종류는 2가지로 '보안그룹'(권한 부여 목적)과 'M365그룹'(공유 사서함, 일정, 파일, Sharepoint 등의 협업 목적)이 있음
  • : 동적 그룹(Dynamic Membership rules)를 통해 특정 조건에 해당되는 경우, 자동으로 그룹에 추가/제거할 수 있다.
  • 디바이스 등록 구성 및 관리 (9분 예상 -> 20분 소요)
    : 전 직원의 디바이스를 ID 단위로 관리해야 보안/생산성 확보가 가능. 디바이스와 EntraID 조합으로 SSO 설정도 가능
    : Entra 등록 디바이스 = 개인 기기에서 Entra ID 로그인을 통해 등록 및 리소스 제어
  •   (Win10/11, iOS, Android, Mac 지원 가능)
  • : Entra 조인 디바이스 = 조직의 기기에서 Entra ID만을 이용하여 클라우드 및 On-prem 앱/리소스 제어
  •   (Win10/11, Home 제외), 조인은 OutOfBoxExperience,대량등록,Autopilot과 같은 self서비스 옵션을 사용해 수행 가능
  • : Hybric Entra 조인 디바이스 = 기존 On-prem AD와 EntraID를 함께 사용하는 조직 
  • 라이선스 관리 (5분 예상 -> 30분 소요)
    : 그룹 기반 라이선스 컨트롤을 하려면 P1 구독 이상 또는 365 E3/A3/GCC G3 이상 버전이 필요함
    : Entra Connector로 On-prem 그룹에 대해서도 부여가 가능하며, 라이선스 전체 기능 중 일부만 할당할 수도 있습니다.
    : 몇 분 내 변경 이력 동기화됩니다. 여러 그룹에 할당된 인원은 1개 라이선스만 사용됩니다.
    : 라이선스를 대량 부여하는 경우는 powershell을 사용할 수 있고, CountViolation등의 수량 부족 오류도 발생 가능하다.
    : 더 상위의 라이선스가 부여되어 있는 경우, 하위 라이선스 부여에서 오류가 발생한다. (E1이 들어가 있는데 E3를 주려는 경우)
      (CMD 오류 : MutuallyExclusiveViolation)
    : 라이선스 간의 종속성 탓에 오류가 발생할 수도 있다. (CMD 오류 : DependencyViolation)
    : 라이선스를 사용하려는 위치가 제한될 수 있다. 사용자의 위치를 지정한다 (CMD 오류 : ProhibitedInUsageLocationViolation)
    : 그룹에 할당된 라이선스가 개인에 할당된 라이선스에 종속성이 있는 상태에서 그룹을 지우면, 개인 라이선스로 자동 전환된다.
  • 사용자 지정 보안 특성 만들기 (4분 예상 -> 30분 소요)
    : 사용자에 따라 접근할 수 있는 범위를 제한하는 기능 - 규칙을 스크립트로 작성하여 사용자 단위로 지정
    : Azure에서 기본적으로 만들어 제공하는 보안 규칙/권한 규칙 외 사용자가 작성하여 관리 (테넌트 당 숫자가 제한됨)
    : Human Resource를 관리하는 시스템이 존재하는 경우, SCIM 프로토콜을 활용하여 사용자 Provisioning을 자동화할 수 있음.
    : SCIM (System for Cross-domain Identity Management

2-3) Azure 핵심 아키텍처 구성 요소 (900을 취득할 때 수강한 영역)

  • Microsoft Azure란 무엇인가요? (4분 -> skip)
  • Azure 계정 시작 (4분 -> skip)
  • Azure 물리적 인프라 설명 (6분)
    : 리전 (짧은 네트워크 연결로 구성된 복수의 데이터 센터, 지리적 영역) 및 가용성 영역 (리전 내의 물리적 분리 영역, 각 센터)
  • : 가용성 영역을 통한 고가용성 확보는 주로 VM, 관리 디스크, 부하 분산 장치, SQL DB에 주로 활용
    : 가용성 영역으로 커버가 불가한 경우, 지역 쌍(300마일 이상 떨어진 리전) 간 복제를 활용
    : 소버린 지역 = 미국 정부가 사용하는 리전, 중국 동북부 리전은 Microsoft와 계약을 맺은 별도 운영자가 관리함.

2-4) Azure Policy 이니셔티브 (05/06 22:20~00:10)

 

         Policy는 json으로 작성되는 전사 거버넌스 표준 준수 서비스, 이니셔티브는 Policy들의 모음

         (1) 미래에 생성될 리소스의 조건 적용, (2) 리소스 규정 준수 추적, (3) 미준수/거부 리소스 해결, (4) 조직 정책 일괄 제어에 사용

    • Cloud Adoption Framework for Azure (10분 예상 -> 40분 소요)
      : 거버넌스 팀 구축 - 위험 평가 - 정책 문서화 - 정책 시행 - 모니터링 과정을 반복하여 아래 이미지 진행
        정책 정의에는 '비즈니스 위험과 허용범위 확인 -> 정책 및 규정화 -> 정책 정착률 모니터 프로세스'가 필요하다.
        5가지 핵심원칙 : 비용관리, 보안 기준선(보안 요구사항 준수), 리소스 일관성(온보딩, 복구 및 검색 가능성)
                                  , ID기준선(역할 및 권한 일관성), 배포 가속화(표준화, 중앙제어)
    • Azure Policy design principles (10분 -> 40분 소요)
      : 리소스 디자인에서 보안/운영/비용 3가지는 꼭 고려해야 한다.
      : 거버넌스 계층 (어느 계층 단위로든 정책 적용 가능, 상위 수준 계층의 정책은 자동 상속됨)
        테넌트 - 관리그룹(어느 타입의 구독도 포함 가능하며, 중첩도 가능) - 구독(리소스 수 제한, 비용 청구에 활용)
        - 리소스그룹(접근 권한 제어 및 리소스 일괄 작업에 활용) - 리소스(모든 Azure 서비스)
      : Azure Resource Manager = 리소스의 배포 및 운영을 위한 서비스 (control plane, data plane 2가지로 구성) [링크]
        Azure 상 SDK, API 등을 통해 리소스를 생성할 때는 무조건 ARM을 거친다 (리소스를 컨트롤하는 영역)
        ARM을 거치지 않는 리소스 활용 영역을 Data Plane이라고 정의하며 대표적으로 kubernetes,keyvault,network 등이 있다.
      : 정책을 적용하는 방법은 2가지로,
         greenfield (정책에 위반되는 경우 실행 취소), brownfeild (실행은 하되, 24시간 기준으로 미준수 플래그 표시) 가능
    • Azure Policy resources (10분 -> 25분 소요)
      : 정책에는 크게 6가지가 있음
        (1) Definition = 규정 준수 조건과 적용 효과를 설명이며,scope(관리그룹,구독,리소스그룹 등) 단위로 설정됨.
        (2) Initiative (Policy Set) = [링크] Microsoft에서 기본 제공하는 필수 정책 그룹이나 여러 정책을 혼합하여 적용할 때 사용
        (3) Assignment = 정책과 이니셔티브를 할당하는 행위/기능을 의미, 여러 포함/제외 옵션이 제공됨
        (4) Examption = 정책과 이니셔티브에서 면저하는 행위/기능을 의미, 완화/면제의 옵션이 있음.
        (5) Attestation = 정책의 준수에 대한 인증으로, 관리 설계에 있어 고려대상이 되어야함.
        (6) Remediation = 개선/대응책으로 policy를 준수하지 않는 경우의 대응 방식입니다. 
    • Azure Policy definitions (20분 -> 30분 소요)
      : 정책 Json의 구성 =
        (1) 정책명(128자), (2) 설명(512자), (3) 정책타입(BuiltIn-MS관리, Custom-직접관리, Static-MS권장),
        (4) 모드(정책 적용 대상이 무엇인지, ARM인지 Resource Provider 컨트롤 영역인지)
        (5) 정책의 버전, (6) metadata(for Built-in 정책) : version, category, preview(Y/N), deprecated(Y/N),portalReview
        (7) parameters (정책의 변수들) : 이름, 타입, 메타데이터, defaultValue, allowedValues,schema
        (8) policyRule : if, then 블럭으로 구성된 정책의 행위 설정부
      : policyRule의 if 조건에는 feild, count, value 등에 대하여 equals, like, match, contains, in, less/greater, exists 등을 사용
        then 절에는 deny(생성/수정 거부), audit(로그에 기록한 후 동작), modify(자동 수정), append(속성 강제 추가) 등의 설정 가능
      : 그 외 addDays, Field, requestContext().apiversion, policy(), ipRangeContains, current 등의 함수로 advanced 설정
    • : 정책을 이용하면 리소스를 중앙집중형으로 관리할 수 있으며, 감사 및 모니터가 가능합니다.
      : 정책 평가 트리거 = (1) 신규 정책이 생성/업데이트된 경우, (2) 평가 주기 도래, (3) 주문형, (4) 구독이나 리소스의 위치/상태 변경
      : 평가 시기 = 24시간 간격 자동 준수 검사, 새 정책 적용에는 30분 가량 소요될 수 있음. (중요도가 낮아 다른 엑션에 밀릴 수 있음)
      : 평가 결과 = 비준수/준수/오류(평가 오류)/충돌(모순되는 정책의 결합 발생)/보호됨(보호 리소스)/면제인지 알 수 없음 (수동 옵션)
      : enforcement mode를 통해 정책의 영향도를 Test할 수 있음. (Disabled로 배포한 후, 이상이 없으면 Enabled로 변경)
       
      <정책 배포 Test의 Best 시나리오 이미지>

<정책 예시 : it can be "United States," "Europe," "Asia Pacific," or "Australia">

{
  "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"
      }
    }
  }

 

2-5) Azure RBAC (Azure 역할 기반 엑세스 제어)를 통한 Azure 리소스 보안 (05/10 17:40 ~18:00)

  • Azure RBAC란? (8분 -> 20분 소요)
    : Roll Base Access Control : ARM을 기반하며, 각 리소스에 대한 세부 권한을 중앙집중형으로 관리할 수 있는 서비스
    : 관리그룹, 구독, 리소스그룹, 단일 리소스에 각각 IAM을 지정할 수 있으며, 상위 계층에 부여된 권한은 하위 계층으로 상속
    : 웹 사이트, 가상 머신 및 서브넷을 포함하여, 모든 리소스에 대한 권한 설정 가능
    : 아래 3가지를 조합하여 "역할 할당"이라는 개체를 만들고, 그 목록을 통해 권한을 관리하게 됨.
      (1) 누구 = 사용자/그룹/어플리케이션,
      (2) 역할 = 권한 컬렉션 (기본 제공되는 소유자/기여자/읽기 권한자 등과 사용자 지정 컬렉션 구성을 Json 형태로 구성)
      (3) 범위 = 엑세스 권한 부여 대상
    : 부여되면 부여된 권한들의 합집합으로 적용되며, Action보다 NotAction이 우선된다.

 

2-6) 셀프 서비스 암호 재설정 (05/10 18:10~18:30)

  • Microsoft Entra ID의 셀프 서비스 암호 재설정이란? (7분 -> 10분 소요)
    : Self Service Password Reset (SSPR)이라 불리며, 암호를 사용자 스스로 변경하도록 허용하는 기능
      유료 서비스에 해당하여 P1, P2 또는 M365 라이선스가 있어야 한다. On-prem의 AD와도 연동된다.
    : 암호 재설정을 위해서는 (1) Authenticator App 인증 / (2) 메일 인증 / (3) 휴대폰 SMS or 사무실전화 인증 / (4) 본인 질문 인증
      위 4가지를 사용하여 본인 인증을 진행해야 하고, 조직에서는 위 4가지 중 몇가지를 인증해야 진행될지 지정이 가능하다.
    : 권장사항은 2개 이상의 방법을 사용하는 것이며, 보통 Authenticator App을 기본 방식으로 하고, 메일을 추가한다.
      관리자 계정에는 기본으로 2개 이상이 적용된다.
  • : 설정에는 3가지 옵션이 있습니다. (없음 : SSPR 사용 안 함, 선택됨 : 특정 조직에만 적용, 전체 : 전체 조직에 적용)
    : [설정 방법] (1) Microsoft Entra ID>관리>암호 재설정 접속
                        (2) [속성]에서 SSPR을 사용하도록 설정
                        (3) [인증방법]에서 사용할 방법 선택
                        (4) [등록]에서 다음 로그인 시 SSPR에 필요한 등록을 해야할지 및 재인증 기한 설정
                        (5) [알림] 및 [사용자 지정] 설정 (도움을 받기 위해 연락할 이메일 혹은 URL 등)
    연습 - 디렉터리 브랜딩 사용자 지정 (5분)
    : 디렉터리 단위로 로그인 화면 등을 디자인 적용할 수 있음. (회사 브랜딩)
+) Azure Key Vault에서 비밀 구성 및 관리 [Azure Key Vault Doc 링크]

        비밀/암호화 키 및 인증서를 직접 관리하는 것이 위험한 상황에서
        암호화 키, 인증서 및 서버 쪽 토큰과 같은 App 비밀을 저장하고, 보안 엑세스/권한제어/엑세스 로깅 제공하는 중앙 집중 서비스 
        데이터의 송수신 중 암호화, 앱 비밀 관리를 위한 보안 스토리지 영역을 제공
  • Azure Key Vault 사용 지침 (5분 예상 -> 20분 소요) 
    : 서비스는 크게 3가지로 구성된다. (1) 자격 증명 모음, (2) 키, (3) 비밀
    : 자격 증명 모음 = 보안 컨테이너로 한 조직에서 여러개를 생성할 수 있으며, 암호화 키 및 암호화된 보호 데이터를 모아둔 객체다.
      키 = 특정 용도를 따르며, MS Azure RMS의 비대칭 마스터 키, SQL Server TDE, CLE, 암호화된 백업 비대칭 키가 있음.
              어플리케이션은 키에 직접 엑세스하지 않고, 자격 증명 모음 서비스를 거치며 특정 경계 내에서 요청된 작업만 수행하도록 설정
              단일 인스턴스화되거나 버전 관리될 수 있고, 버전은 롤오버될 때 만들어진 보조키들을 포함하는 개체
              RSA 2048을 지원하며 App 암호화, 디지털 서명에 사용 가능
              (1) 하드웨어 보호 키 : FIPS 140-2 수준 2에 부합하는 전용 HSM을 소유, 복호화 및 서명은 HSM 내부에서 수행
                                                자체 HSM에서 키를 가져와 HSM 내부에서 Key Vault로 전송도 가능(Bring Your Own Key)
              (2) 소프트웨어 보호 키 :  RSA, ECC 알고리즘 사용하여 키 생성 및 보호, FIPS 140-2 수준 2 보증, Azure Compute 활용   
                    -> 주로 Test, 검증계에서 소프트웨어 키를 쓰고, 운영계에서 HSM 구성
       비밀 = 스토리지 계정 키, PFX 파일, SQL 연결 문자열, 데이터 암호화 키 등을 암호화한 (10K미만의) 데이터 BLOB
    : 서버와 연결해야 하며, 클라이언트 연결은 금지됨. 
    : [사용 예시]
      RBAC과 연동하여 Key Vault에 기여자 역할을 할당하면 앱 엑세스를 제어할 수 있음.  
  • 비밀, 인증서 및 키에 대한 액세스 관리 (4분 예상 -> 10분 소요)
    : 익명의 증명 만들기, 사용은 불가하며, Entra ID와 연동하여 수행됨.
    : 기본적으로 ARM에서 부여하는 Azure Key Vault 기여자는 '자격증명모음'을 만들고 관리하는 역할만 주어지며,
      '자격증명모음'의 데이터를 사용하여 암복호화/인증을 진행하려면 별도의 '액세스 정책'을 구성하여 할당해야 한다.
    : [액세스 정책 권한 종류]
       (1) 키 관리 작업 : 가져오기(Get)/나열(List)/업데이트/만들기/삭제/복구/백업/복원
       (2) 암호화 작업 : 복호화/암호화/키 래핑/키 래핑 해제/확인/로그인
       (3) 권한 있는 키 작업 : 제거
    : 특정 네트워크에서 오는 요청만을 허용하도록 [방화벽 및 가상 네트워크] 탭에서 설정이 가능하다.
      주로 Azure SQL, App service 등 Key Vault와 연결되는 서비스들을 지정하여 오픈한다.
  • : Key Vault는 여러 소스에서 가져올 수 있는 X.509 기반 인증서를 관리하며, 자체 서명된 인증서를 생성할 수도 있다.
      CA와 연계하여 App 인증을 관리하는 방식은 아래 2가지 아키텍처로 구성이 가능하다.
    : Azure Web App에서 [설정] - [TLS/SSL] 설정을 통해 키 연동을 쉽게 구성할 수 있음.
      동일한 구독 내의 자격증명 모음과 인증서를 선택할 수 있고, 인증서 콘텐츠 형식이 application/x-pkcs12인 인증서여야 한다.
      할당된 도메인과의 연동도 필요하다.
Application이 중개하는 경우 CA와 key Vault를 직접 연계하는 경우

 

3) Storage

 

[Keywords]

Redundancy / LifeCycle & tiers = cost optimization / permission = SAS, AccessKey, IAM / Encryption / Policy / Firewall 

 

[Reference]

SMB (Server Message block) / NFS (Network File System) : [링크]

 

[상세 내용]

 

3-1) 스토리지 계정 구성

  • Azure Storage 구현 (11분 예상 -> 20분 소요)
    : 저장소를 크게 3가지로 구분할 수 있음.
      (1) VM 데이터 : 디스크 및 파일이 포함됨. 정적 콘텐츠 및 어플리케이션 코드 등, 각 디스크의 최대 용량은 32TB.
      (2) 비정형 데이터 : REST API를 활용하는 Blob이나 HDFS 시스템인 Data Lake Storage를 활용, 비관계형 데이터 저장
      (3) 정형 데이터 : 공유 스키마가 있는 관계형 데이터. Table Storage나 Cosmos DB, SQL DB 등을 의미
    : 스토리지 계정 유형
      (1) 표준 스토리지 : 마그네틱 HDD(하드 디스크 드라이브)로 지원, 대량 저장 및 엑세스율이 낮은 데이터에 적합
      (2) 프리미엄 스토리지 : SSD(반도체 드라이브) 백업, 대기시간이 짧고 고성능 제공함. I/O 집약적인 앱에서 디스크로 사용 가능
  •    스토리지 유형은 한 번 정해지면 서로 변경될 수 없고, 새로 만들어야 함.
  • : Cloud Storage 장점 : (1) 내구성 및 가용성 확인, (2) 보안 엑세스 옵션, (3) 스케일링, (4) 관리 효율성, (5) 데이터 접근성
  • Azure Storage 서비스 살펴보기 (4분 예상 -> 20분 소요)
    : (1) 컨테이너(Blob Storage) : 텍스트/이진 데이터 대규모 저장 : 이미지/비디오/오디오/문서 직접 제공, 분산 엑세스, 백업, 분석용
      (2) Files : 배포에 대한 관리 파일 공유 : SMB, NFS 사용 : 진단 로그, 메트릭, 크래시 덤프 등 사용 가능
      (3) Queue Storage : 앱 구성 요소 간 안정적인 메시징을 위한 저장소
      (4) Table Storage : 비관계형 구조적 데이터를 저장하는 서비스
  • 스토리지 계정 유형 결정 (6분 예상 -> 6분 소요)
    : (1) 표준 범용 : 대부분 스토리지를 사용 가능하나 HDD로 운영
      (2) 프리미엄 블록 blob : 어플리케이션에서 스케일링, 높은 속도의 트랜젝션 지원
      (3) 프리미엄 파일 공유 : 파일공유 목적
      (4) 프리미엄 페이지 blob : DB 및 가상 머신에 대한 OS, 데이터 디스크와 같은 인덱스 기반 데이터와 스파스 데이터 구조 저장
  • 복제 전략 결정 (7분 예상 -> 15분 소요)
    : SLA 서비스 수준 계약
      (1) LRS(로컬 중복 : 동일 데이터 센터에 저장 : 동일 국가/지역에만 데이터를 저장하는 경우, 스토리지 계정은 1개),
      (2) ZRS(영역 중복 : 가용성 영역을 복수로 사용하는 경우, 각 영역 별 스토리지 계정이 생성됨. 설정 변경 시)
      (3) GRS(지역 중복 : 보조 리젼에 복제, RA-GRS는 복제 리젼에서도 읽기가 가능하도록 설정하는 것)
      (4) GZRS(지역 영영 중복 : LRS + ZRS : 메인 리젼에 ZRS를 구성한 후, 타 리전에 LRS를 구성)
  • 스토리지 액세스(3분 예상 -> 20분 소요)
    : *.blob/table/queue/file.core.windows.net 으로 접근 URL 생성됨.
    : CDN 사용도 가능. asverify 접두어를 사용하면, DNS 레코드를 수정하지 않고도 인식 가능
  • 스토리지 엔드포인트 보호 (2분 예상 -> 10분 소요)
    : 방화벽 및 가상 네트워크 설정 사용. 
    : 하나 이상의 공용 IP 범위에 대한 엑세스를 허용하도록 서비스 구성이 가능하며, 서브넷 및 Vnet은 동일한 리젼 또는 지역쌍에 위치
     

3-2) Azure Blob Storage 구성

  • Azure Blob Storage 구현 (2분 예상 -> 5분 소요)
    : Binary large object (Blob), 개체/컨테이너 Storage로 불림.
    : 3가지 구성 리소스 : Azure Storage 계정(드라이브), 계정의 컨테이너(폴더), 컨테이너의 Blob(파일) 개념으로 구성됨.
      필요 설정 : (1) 컨테이너 옵션, (2) 형식 및 업로드 옵션, (3) 엑세스 계층, (4) 수명 주기 규칙, (5) 개체 복제 옵션
    : 브라우저 업로드 후 문서/이미지를 직접 제공하는 경우, 분산 저장, 스트리밍, 보관 및 백업, 앱 엑세스를 위해 사용함. 
  • Blob 컨테이너 만들기 (5분 예상 -> 5분 소요)
    : 모든 Blob은 컨테이너에 존재하며, 컨테이너와 Blob의 저장 수는 제한이 없음
    : 컨테이너 이름은 소문자, 숫자, 하이픈만 사용 가능, 문자 또는 숫자로 시작해야 하며, 3~63자로 구성
    : New-AzStorageContainer 명령으로 컨테이너 생성 가능
  • Blob 액세스 계층 할당 (3분 예상 -> 6분 소요)
    : 핫(자주, 즉시), 쿨(30일 쿨에 남아 있을 시 적용됨, 즉시 사용 가능), 콜드(90일 콜드에 남아있을 시 적용, 로딩 지연),
      보관 엑세스(180일 보관 시 적용, 남아 있지 않으면 삭제 요금 부과됨. 검색 및 로딩시간 김) 4개 계층으로 구분. 아래 표 참조
    Blob 수명 주기 관리 규칙 추가 (5분 예상 -> 6분 소요)
    : GPv2 또는 Blob Storage 계정에 대해 규칙 기반 제공, Lifecycle management에서 rule 설정 가능
    : 계정 수준에서 하루에 한 번 실행하도록 규칙 기반 조건 정의, 컨테이너 또는 Blob 하위 집합에 규칙 기반 조건 적용
    : if - then 절에 따라, 쿨/콜드/보관 영역 이동, 혹은 삭제 설정이 가능
  • Blob 개체 복제 확인 (3분 예상 -> 4분 소요)
    : 개체 복제 사용을 위해서는 양 계정 모두에서 Blob 버전 지정을 사용하도록 설정해야함.
      Blob 스냅샷을 지원하지 않으며, 원본 계정 스냅샷은 대상 계정에 복제되지 않음. 핫/쿨/콜드 계층만 제공
      복제 정책을 만들어 관리
    : [사용처]
      (1) 클라이언트가 다른 지역에 있는 경우, 엑세스 시간 단축을 위해 리전간 복제를 사용
      (2) 워크로드 효율성 및 데이터 배포, 비용 혜택을 고려함
  • Blob 업로드 (5분 예상 -> 10분 소요)
    : 블록 Blob (기본 설정, 파일/이미지/비디오 등 블록들을 조합하여 저장), 추가 Blob (데이터가 계속 추가되는 경우 유용)
      페이지 Blob (최대 8TB, 읽기/쓰기가 빈번한 경우 효율적, VM의 OS디스크 및 데이터 디스크에 페이지 블랍 사용)
    : 한 번 생성되면 Blob의 형식은 변경될 수 없음.
    : [업로드 방법 3가지]
      (1) AZCopy : Window 및 Linux의 명령줄 도구, Blob/컨테이너/계정 단위로 복사 가능
      (2) Azure Data Box Disk : 오프라인 물리적 복제 서비스,     (3) Azure Import/Export : 드라이브 배송받아 저장 후 회신 서비스
    : 스토리지 계정 단위에서 Data Protection 탭을 통해 버져닝 기능을 활성화할 수 있다.
  • Blob Storage 가격 책정 (2분 예상 -> 5분 소요)
    : 저장된 볼륨, I/O 등의 작업 종류 및 횟수, 데이터 전송비용, 데이터 복제 옵션 등에 따라 가격 책정
    : 특히 엑세스 계층에 따라 다른 엑세스, 트랜젝션 비용, 지역 복제 전송 비용, 아웃바운드 전송 비용 등을 유의해야 함.
  핫 쿨 콜드 보관 엑세스
가용도 99.9% 99% 99% 99%
가용성(RA-GRS 읽기) 99.99% 99.9% 99.9% 99.9%
대기 시간(첫 번째 바이트까지 시간) 밀리초 밀리초 밀리초 시간
최소 스토리지 기간 해당 없음 30일 90일 180일

 

3-3) Azure Storage 보안 구성

  • Azure Storage 보안 전략 검토 (3분 예상 -> 10분 소요)
    : 자격증명, 파일 권한, 프라이빗 서명을 사용한 암호화, 인증, 권한 부여, 엑세스 제어가 해당됨.
    : 1) 저장된 데이터의 암호화 : 256비트 AES 암호를 사용한 SSE 제공 (속도 저하나 비용 추가 없음),
          가상 하드 디스크 암호화는 window용 bitlocker 이미지와 linux용 dm-crypt 사용
      2) 전송중인 데이터의 암호화 : server-client간 전송은 항상 https를 사용하고, rest api에도 보안 전송을 요구할 수 있음.
                                                    모든 파일 공유 탑재에 SMB 3.0을 요구하여 SMB를 통한 전송 보안 적용
      3) 암호화 모델 : (1) 서비스 관리 키를 사용해 서버 암호화, (2) Key Vault의 고객 관리 키, (3) 하드웨어 고객 관리 키
                                키의 경우 on-prem을 비롯한 다양한 위치에서 저장/관리 가능
      4) 요청에 대한 권한 : 관리ID, EntraID를 사용하여 각 데이터 저장소에 대한 요청 권한을 관리, 공유 키 권한 부여를 통해 제공
      5) RBAC : 리소스에 지정한 사용자나 어플리케이션만 엑세스할 수 있도록 관리
      6) 스토리지 로깅 : Azure Storage Analytics로 로그 수집 및 추세 분석, 계정 문제를 진단 가능
    : 권한 부여 보안 사용 시, EntraID / 공유키 / 공유 엑세스 서명 등을 고려, 퍼블릭 엑세스가 가능한 컨테이너나 blob도 있음.
  • 공유 액세스 서명 만들기 (3분 예상 -> 10분 소요)
    : SAS(Shared Access Sign)은 리소스에 대한 제한된 엑세스 권한을 부여하는 URI (Uniform Resource Identifier).
      SAS URI를 통해 특정 기간 Blob과 DataLake Storage에 접근할 수 있으며, 서비스/특정 리소스/계정 단위로 설정이 가능.
    : HTTPS를 통해 SAS가 전달되어야 하며, 만료 날짜가 긴 저장된 엑세스 정책을 사용하여 적용하는 것을 추천하며, 
  • URI 및 SAS 매개 변수 식별 (3분 예상 -> 5분 소요) : 아래 표 참조
  • Azure Storage 암호화 확인 (4분 예상 -> 10분 소요)
    : Storage 계정을 생성하면 Azure는 2개의 512비트 엑세스 키를 생성하고, 공유키 권한이나 SAS토큰을 통해 엑세스 제어에 활용함.
      (키를 2개 만드는 이유는 하나가 갱신되고 있는 경우, 다른 하나를 사용하여 중단을 막기 위함)
    : KeyVault를 통해 키를 관리하고, 정기적으로 회전/생성해야 하며, 이러면 어플리케이션의 중단 없이 키의 갱신이 가능함.
    : Azure의 스토리지들은 사용자가 인지하지 못하는 사이에 데이터를 256비트 AES로 암호화하고, 검색 시 해독함. 필수 사용임.
    : 스토리지 계정 생성 시 암호화 설정 가능. 인프라 수준에서 추가 암호화 구성도 가능하며, PMK(플랫폼 관리형 키)는 기본 제공되며,
      CMK(고객 관리형 키)를 별도 구성할 수 있음, 자격 증명모음이나 HSM(하드웨어 보안 모듈)에 저장된 키를 의미, BYOK 시나리오
  • 고객 관리형 키 만들기 (2분 예상 -> 5분 소요)
    : CMK는 유연성과 제어를 향상시킴. 키 엑세스 제어를 생성하고 감사/회전/정의가 가능. 동일한 리전에 위치/구독은 다를 수 있음.
  • Azure Storage 보안 모범 사례 적용 (8분 예상 -> 3분 소요)
    : Azure Storage 인사이트 모니터를 활용하여 성능/용량 및 가용성 추적 가능. 메트릭으로 보안/규정 감사 기능을 제공
    : 실시간 제공되며, 상태 분석 및 최적화를 지원
  •  

URI 매개 변수 설명
https://myaccount.blob.core.windows.net/?restype=service&comp=properties&sv=2015-04-05&ss=bf&st=2015-04-29T22%3A18%3A26Z&se=2015-04-30T02%3A23%3A26Z&sr=b&sp=rw&sip=168.1.5.60-168.1.5.70&spr=https&sig=F%6GRVAZ5Cdj2Pw4tgU7IlSTkWgn7bUkkAg8P6HESXwmf%4B

리소스 URI https://myaccount. blob .core.windows.net/ ?restype= service &amp;comp=properties Azure Storage 엔드포인트 및 기타 매개 변수를 정의합니다. 이 예제에서는 Blob Storage에 대한 엔드포인트를 정의하고 SAS가 서비스 수준 작업에 적용된다는 것을 나타냅니다. GETURI를 사용하면 Storage 속성이 검색됩니다. SETURI를 사용하면 스토리지 속성이 구성됩니다.
스토리지 버전 sv=2015-04-05 Azure Storage 버전 2012-02-12 이상의 경우 이 매개 변수는 사용할 버전을 나타냅니다. 이 예제는 버전 2015-04-05(2015년 4월 5일)를 사용해야 임을 나타냅니다.
스토리지 서비스 ss=bf SAS가 적용되는 Azure Storage를 지정합니다. 이 예제는 SAS가 Blob Storage 및 Azure Files에 적용된다는 것을 나타냅니다.
시작 시간 st=2015-04-29T22%3A18%3A26Z (선택 사항) SAS의 시작 시간을 UTC 시간으로 지정합니다. 다음은 시작 시간을 2015년 4월 29일 22:18:26 UTC로 설정하는 예제입니다. SAS를 즉시 유효하게 하려면 시작 시간을 생략합니다.
만료 시간 se=2015-04-30T02%3A23%3A26Z SAS의 만료 시간을 UTC 시간으로 지정합니다. 다음은 만료 시간을 2015년 4월 30일 02:23:26 UTC로 설정하는 예제입니다.
자원 sr=b SAS를 통해 액세스할 수 있는 리소스를 지정합니다. 이 예제에서는 액세스 가능한 리소스가 Blob Storage에 있음을 지정합니다.
권한 sp=rw 부여할 권한을 나열합니다. 이 예제에서는 읽기 및 쓰기 작업에 대한 액세스 권한을 부여합니다.
IP 범위 sip=168.1.5.60-168.1.5.70 요청이 수락되는 IP 주소 범위를 지정합니다. 이 예제에서는 IP 주소 범위 168.1.5.60~ 168.1.5.70을 정의합니다.
프로토콜 spr=https Azure Storage에서 SAS를 수락하는 프로토콜을 지정합니다. 이 예제에서는 HTTPS를 사용한 요청만 수락됨을 나타냅니다.
서명 sig =F%6GRVAZ5Cdj2Pw4tgU7Il STkWgn7bUkkAg8P6HESXwmf%4B Hash-Based HMAC(메시지 인증 코드) 서명을 사용하여 리소스에 대한 액세스를 인증하도록 지정합니다. 서명은 SHA256 알고리즘을 사용하여 키로 계산되고 Base64 인코딩을 사용하여 인코딩됩니다.

 

3-4) Azure Files 구성 : 공유 폴더 구성하기

  • : SMB(서버 메시지 블록), NFS(네트워크 파일 시스템), HTTP를 통해 파일 공유에 엑세스 가능, os는 window,linux,mac 지원
    : 서버리스 배포의 PaaS 제품으로 VM, OS 업데이트 필요 없음. 미사용 시와 네트워크 전송 시 암호화됨. Backup 스냅샷 기능 지원.
      무제한급 저장 용량을 제공하며, on-prem과 동일한 폴더 계층 구조로 구성됨. EntraID나 AD를 통해 제어 가능. 가용성 보장
    : 용도 = 기존 파일 서버 또는 NAS 디바이스의 교체하거나, 공유 어플 구성파일/진단 데이터 공유/도구 및 유틸리티 저장에 활용
  • Azure 파일 공유 관리 (5분 예상 -> 10분 소요)
    : 동일한 파일 공유 공간에서 SMB와 NFS를 동시에 지원하지는 않음. 택1
    : 유형 = 1) 프리미엄 : SSD, ZRS(일부지역) LRS지원
                 2) 스텐다드 : HDD, GPv2(범용버전2), 모든 지역에서 LRS/ZRS/GRS/GZRS 보장
    : 인증 = 1) SMB를 통한 ID 기반 인증 : SSO : 포트는 445 TCP(445를 열 수 없을 때는 VPN이나 전용선이 필요), HTTPS 사용
                 2) 엑세스 키 : 모범 사례는 아님. 키의 보호가 필요함.
                 3) SAS URI : 제한된 REST API URI 사용
    : window에는 powershell 명령어를, linux에는 /etc/fstab에 mount 명령을 사용하여 주문형으로 파일 탑재 수행
  • 파일 공유 스냅샷 만들기 (3분 예상 -> 3분 소요)
    : 전체를 대상으로 읽기 전용 시점 복사본 생성, 증분하며, 개별파일별 복사본으로 접근 가능, 스냅샷 삭제 시 복원 불가
  • Azure Files에 대한 일시 삭제 구현 (2분 예상 -> 2분 소요)
    : 일시 삭제 시, 삭제된 파일의 설정된 보존 기간(1~365일) 내 복구 가능, 랜섬웨어 삭제 방지
  • Azure Storage Explorer 사용 (4분 예상 -> 5분 소요)
    : Storage Explorer는 Azure 상의 모든 엑세스 권한이 동일하게 적용되는 에뮬레이터 역할
    : 외부 Storage 계정 연결을 위해서는 Storage 계정이름과 키가 필요하며 엔드포인트를 입력하여 연결 가능
  • Azure 파일 동기화 고려 (4분 예상 -> 5분 소요)
    : 파일의 사용 빈도에 따라 계층화도 가능. 로컬에 직접 개시하거나 사용 빈도가 낮은 경우, 포인터를 만들어 Files의 스토리지로 이동.
      계층화되어 Azure에만 존재하는 파일에는 오프라인 0 이라는 회색 아이콘을 표시함
 

 

4) Azure Compute Resource

 

[Keywords]

ARM(Bicep File) / VM Types & Requirments /  Region Redundancy / ACA&ACI&ACR / App Service&Plan&License

 

Automate deployment of resources by using Azure Resource Manager (ARM) templates or Bicep files

Create and configure VMs

Provision and manage containers in the Azure portal

Create and configure an Azure App Service

 

[Reference]

[상세 내용]

 

4-1) Azure Virtual Machines 소개

  • : 구성요소 = VM(이름/위치/크기/OS), 스토리지 디스크, 가상 네트워크, 네트워크 인터페이스, NSG, IP주소
      * 네트워크 구성 시, IP 대역이 겹치지 않아야 하고, 하부 서브넷을 구성함. 서브넷은 처음 네 개와 마지막 주소를 사용하도록 설정
      * VM 이름은 Linux는 64자, Window는 15자 지정 가능. 변경이 어려움으로 명명규칙에 환경/위치/인스턴스/서비스/역할 등 반영
      * 가용한 리소스 종류, 비용, 세금/정책 등을 고려하여 리전 지정.
      * 실행중인 VM의 옵션을 변경하면 자동 재부팅됨으로 주의가 필요함.
      * 비용은 구성요소 별로 각각 정책이 정해져 있으며, 기본 종량제에서 RI 설정이 가능하다.
      * 디스크는 기본 2개 존재, 운영 체제 저장용과 임시 스토리지. app 데이터 저장을 위해서는 추가 (vCPU단 2개 추가 가능)
         디스크는 Ultra Disk (IO 집약적 최상위 시스템 DB, 워크로드용, 4000MB/s, 160000IOPS)
                       프리미엄SSD v2 (짧은 대기 시간 및 높은 IOPS가 지속 요구되는 프로덕션 및 워크로드, 1200MB/s, 80000IOPS)
                       프리미엄SSD (성능이 중요한 워크로드, 900MB/s, 2000IOPS, OS 디스크 활용 가능)
                       표준SSD (웹 서버, 일반 엔터프라이즈 App, 개발/테스트 환경, 750MB/s, 6000IOPS, OS 디스크 활용 가능)
                       표준HDD (백업, 중요하지 않고 엑세스 낮은 것, 500MB/s, 2000IOPS, OS 디스크 활용 가능)
       * OS는 marketplace에서 탐색하여 커스텀도 가능, Azure Compute Gallary에서 직접 구성도 가능
    : 리소스 관리자 템플릿, PowerShell, CLI, Rest API, SDK, VM확장, Automation 서비스로 관리 가능
      1) 리소스 관리자 템플릿 : 현재 구성된 VM의 템플릿을 Json으로 빼낼 수 있는 기능
      2) PowerShell : New-AzVm -ResourceGroupName "값" -Name "값" -Location "East US" 처럼 코드로 관리 가능
      3) CLI : az vm create --resource-group 값 --name 값 --image Ubuntu2204 처럼 코드로 관리 가능
      4) ... Terafform, SDK 등 제공
      5) Azure Automation : 프로세스 자동화(이벤트 대응), 구성관리(SW 업데이트, 디바이스 추적), 업데이트(VM 업데이트) 제공
  • Azure VM의 가용성 관리 (10분 예상 -> 10분 소요)
    : 가용성 = 서비스를 사용할 수 있는 시간의 백분율
    : Azure는 기본 리전별 가용성 영역 3개로 구성되며, VM 확장 집합을 사용하여 그룹을 구성할 수 있음.
    : Load Balancer를 구성하여 트래픽을 분산시키면 각 VM의 부하를 방지할 수 있음.
    : Storage의 중복성을 구성하여 타 트랜젝션의 점유 시에도 활용 가능하도록 구성.
    : Failover 시나리오를 구성하여 사이트 간 인프라 복제 조치도 가능. Site Recovery를 통해 보조 위치로 복제. (Test 용이)
      이 시나리오에는 PowerShell, Azure Automation Runbook 또는 수동 개입 단계가 포함될 수 있음.
  • 가상 머신 백업 (7분 예상 -> )
    : Azure Backup을 통해 VM을 백업할 수 있음.
    : Window OS 머신의 파일 및 폴더, App인식 스냅샷, 서버 워크로드, Client 머신 등을 백업할 수 있음.
      이를 백업하기 위한 스토리지의 자동 관리(크기, 저장 옵션, 저장을 위한 송수신 무료 제공 및 암호화), 일치 백업, 장기 보존 제공

4-2) 가상 머신 가용성 구성

  • : 실패가 예측되는 경우 - 임시 마이그레이션 후 회복 방식을 취함,
      예상치 못한 중지 - 동일한 데이터 센터의 물리적 컴퓨터로 마이그레이션, 이 때는 재부팅이 발생하며 임시 드라이버는 손실됨.
      계획된 유지 관리 - 정기적인 업데이트 (OS나 기타 소프트웨어는 자동 업데이트하지 않으나, SW 호스트 및 HW는 정기적 패치)
  • 가용성 집합 만들기 (2분 예상 -> 10분 소요)
    : 가용성 집합의 VM은 동일한 기능 집합을 수행하고, 동일한 SW가 설치되어 있어야 하며,
      가용성 집합은 ARM 및 스크립트를 통해 VM과 함께 생성 가능, 변경하려면 삭제 후 다시 생성이 필요
    : Load Balancer를 통해 가용성 집합 내 부하를 분산하고, 어플리케이션 계층의 분리를 고려해야 함. 
  • : VM이나 가용성 집합이 생성되면, 업데이트 도메인과 장애 도메인을 각각 구현함.
    : 업데이트 도메인 : 서비스 업그레이트(롤아웃) 중에 함께 업그레이드 되는 도메인, 증분 또는 롤링 업그레이드를 위함
      업데이트 실행과 동시에 재부팅 가상 머신 및 연결된 물리적 하드웨어 세트가 구성됨, 계획된 유지관리 동안에는 1개 도메인만 활용.
      기본 5개~최대 20개가 구성됨.
    : 장애 도메인 : 실패지점을 공유하는 물리적 구성이 동일한 집합을 의미. 동일 운영
  • 가용성 영역 검토 (2분 예상 -> 6분 소요)
    : 가용성 집합을 영역으로 구분하는 경우, 3개 이상의 VM을 이용하며, 업데이트/장애 도메인도 각각 3개씩 활용함.
    : 고유한 물리적 위치의 조합이며, 독립 전원/냉각 및 네트워크를 갖춘 하나 이상의 데이터 센터로 구성됨.
    : Azure Storage나 SQL DB에 사용되는 영역 중복 서비스는 가용성 영역 전체에서 어플과 데이터를 복제.
    : VM이나 Managed Disk, IP주소 등에 사용되는 영영 서비스는 특정 영역에 고정됨.
  • 수직 및 수평 스케일링 비교 (2분 예상 -> 2분 소요) 
    : 수직 = 단일 리소스를 줄이거나 늘리는 것 (스케일 업/다운)
    : 수평 = 갯수를 줄이거나 늘리는 것 (스케일 아웃/인)
  • Azure Virtual Machine Scale Sets 구현 (9분 예상 -> 5분 소요 )
    : 동일한 이미지와 OS를 활용한 VM 세트를 배포/관리하는 서비스, 수동/자동 제어 모두 가능, 네트웍/구성작업이 없음.
    : 레이어 4 트래픽 제어를 위해 Load Balancer를 사용하며, L7 트래픽 배포 및 TLS/SSL 종료 위해 Application Gateway 사용
    : 최대 1000개의 인스턴스를 지원, 사용자 지정 VM은 600개 지원
  • Virtual Machine Scale Sets 만들기 (2분 예상 -> 2분 소요)
    : 장애 도메인을 분산하는 알고리즘도 선택 가능
  • 자동 스케일링 구현 (3분 예상 -> 3분 소요)
    : 자동 크기 조정은 규칙을 통해 특정 임계값이 충족되면 조정함. 아웃/인을 모두 고려해야 하며, 이벤트 예약을 걸 수도 있음.
  • 자동 크기 조정 구성 (3분 예상 -> 3분 소요)
    : 크기, 이벤트, 조정 량 등을 설정하여 규칙 정의가 가능, 자동 스케일링 설정도 가능

4-3) Azure App Service Plan 구성

4-4) Azure App Service 구성

  • Azure App Service 구현 (3분 예상 -> 25분 소요)
    : window, linux 환경에서 디바이스용 웹, 모바일 백엔드, 웹 API를 운영할 수 있는 서비스
    : 장점 : 1) 다양한 개발 언어 지원(ASP.NET,Java,Ruby,Node.js,PHP,Python)
       2) DevOps 최적화 (Azure DevOps,Github, BitBucket, Docker Hub, Azure Container Registry 배포 지원, CLI 관리
       3) 스케일 업/아웃 지원
       4) 엔터프라이즈 시스템 (SAP, Salesforce, 인터넷 서비스 등 50개 커넥터 보유, 하이브리드 연결 및 Vnet을 통해 On-prem 접근
       5) 보안 (ISO, SOC 및 PCI 호환, EntraID 또는 소셜 로그인으로 인증 가능, IP 주소 제한을 만들고 서비스 ID 관리
       6) WordPress, Joomla,Drupal 등 Azure Marketplace의 어플리케이션 템플릿 목록 사용 가능
       7) Visual Studio 연동하여 만들기, 배포, 디버깅 작업 간소화
       8) Rest API 시나리오에 대한 턴키 CORS 지원, 인증/오프라인 데이터 동기화/푸시 알림 등 사용 설정 간소화
       9) 서비리스 코드로 명시적 프로비저닝 및 관리 가능
  • App Service를 사용하여 앱 만들기 (8분 예상 -> 8분 소요)
    : 이름/게시 방법(코드 또는 Docker Container)/런타임/OS/지역/가격 책정 계획 설정
    : 생성 후에는 Always On 여부, 세션 선호도, HTTPS만 허용 옵션 설정 가능
  • : Azure DevOps, Github, BitBucket, FTP 또는 로컬 Git Repository에 대한 연속 통합/배포 지원
    : 코드를 서밋하면 컴파일/테스트/빌드/배포를 자동으로 진행
    : Azure Portal의 개별 App 화면에서 Deployment Center 접속하여 Setting : 연결 시 자동 프로덕션 분기 변경이 배포됨.
    : 수동 배포는 원격 Git의 URL에 푸시하면 배포되거나, OneDrive, DropBox 등을 사용하여 파일을 저장/호스팅할 수도 있음.
  • 배포 슬롯 만들기 (3분 예상 -> 10분 소요)
    : 기본 프로덕션 슬롯 외 배포 슬롯을 사용할 수 있음.
    : 자체 호스트 이름을 갖춘 라이브 앱, 표준/프리미엄 및 격리 등의 가격 계층 사용 가능하며, 프로덕션 슬롯을 포함해 콘텐츠 교환 가능
    : 장점 1) 앱 변경 내용을 프로덕션 슬롯의 콘텐츠로 변경하기 전에 스테이징 배포 슬롯에서 유효성 검사 가능
              2) 가동 중지 시간을 줄이기 위해 프로덕션 전환 준비 단계로 활용, 무중단 배포 가능, 교환으로 삭제되는 요청 없으며,
              3) 슬롯 단위로 버전 관리를 통해 롤백 작업 수행 가능
              4) 자동 교환을 설정하면 배포 슬롯에 푸시된 내용이 자동으로 준비완료된 프로덕션 슬롯으로 교환됨. 
  • 배포 슬롯 추가 (5분 예상 -> 10분 소요) 
    : 슬롯은 새로 만들거나 복사할 수도 있음. 복사하는 경우 설정들을 편집할 수 있음.
      설정은 앱 설정 및 연결 문자열, 지속 배포 설정, App Service 인증 설정 3가지로 나뉨
    : 교환되는 설정 = 언어 스택, 버전, 32/64비트, 앱 설정, 연결 문자열, 스토리지 계정, 공용 인증서,경로 맵핑
      슬롯별 설정 = 도메인 이름, 비공개 인증서 및 TLS/SSL 설정, 크기 조정 설정, AlwaysOn설정, IP제한, WebJobs스케줄러,
                            CORS, 가상 네트워크 통합, 관리ID
  • App Service 앱 보호 (3분 예상 ->  8분 소요)
    : 기본 제공 인증 및 권한 부여를 통해 웹앱, API, 모바일 백엔드, Azure Function 등에 접근 가능
      (인증 및 권한 부여에는 페더레이션, 암호화, JSON 웹 토큰 관리, 부여 유형 등 보안 지식 필요 - App Service는 이를 자동제공)
    : 보안 모듈은 동일한 환경에서 실행되지만 별도 실행됨. 앱 설정으로 구현되며, 설정에 제약이 없음.
      보안 모듈을 사용하도록 설정하면, HTTP 요청이 모듈을 통과함,
      지정된 공급자로 사용자 인증, 토큰 유효성 검사, 저장 및 새로고침, 세션 관리, 요청 헤더에 ID 정보 삽입 제공
    : 익명 접근, 인증 사용자만 접근(/.auth/login/<provider>로 리디렉션), 로깅 및 추적 제공
  • 사용자 지정 도메인 이름 만들기 (3분 예상 -> 5분 소요)
    : 도메인 이름은 사용자가 직접 설정 가능하며, TLS/SSL 인증서와 type(SNI SSL, IP Based SSL)을 설정할 수 있다
    : A record로 직접 등록 가능하며, CNAME을 만들어 도메인을 도메인에 연결할 수도 있음.
  • App Service 앱 백업 및 복원 (4분 예상 -> 10분 소요)
    : 백업 사용을 위해서는 앱 또는 사이트에 대한 표준/프리미엄 계층 요금제 필요
    : Storage를 지정하여 백업하며, 앱구성설정/파일콘텐츠/연결된DB정보 등이 함께 Zip,XML 파일로 백업됨. 컨테이너에서 확인 가능
    : 수동/자동으로 설정 가능하며, 전체 백업이 기본이나 부분백업도 지원됨 (제외할 파일 및 폴더 지정), 10GB의 앱과 DB콘텐츠 가능
    : 스토리지 계정이 방화벽 내에서 사용하도록 설정된 경우 지정 불가
  • Azure Application Insights 사용 (3분 예상 -> 5분 소요) 
    : .NET, Node.js, Java 등 다양한 플랫폼에서 작동, Azure 파이프라인 프로세스와 통합되고, 개발도구들과 연결 가능
    : Visual Studio App Center와 통합하여 모바일 앱에서 데이터 모니터링 가능
    : 모니터 대상 = 요청속도, 응답 시간 및 실패율 / 종속성 비율, 응답시간, 실패율 / 예외 / 페이지 보기 및 로드 성능 / 사용자 및 세션 수 /
                            성능 카운터 / 호스트 진단 / 진단 추적 로그 제공 / 이벤트 및 메트릭

4-5) Azure Container Instances 구성

  • 컨테이너와 가상 머신 비교 (3분 예상 -> 10분 소요)
    : 빠른 시작 시간, 간편한 관리, 격리된 컨테이너에서 어플 실행이 필요한 경우, Container Instances 등을 활용 가능
    : 격리를 유지하면서 운영 체제의 동일한 인스턴스 내에서 다수의 어플리케이션 실행 가능
    : VM과의 차이점
      1) VM처럼 강력한 보안 격리를 제공하지는 않음.
      2) VM은 커널 등의 전체 OS를 실행, 더 많은 시스템 리소스(CPU, 메모리, 스토리지)를 활용, 컨테이너는 OS의 사용자 모드 실행
      3) 명령줄을 통해 Docker를 사용하여 개별 컨테이너 배포 가능(AKS 사용하여 멀티 컨테이너 배포 가능)
           VM은 Window Admin Center 또는 Hyper-V 관리자를 통해 머신 배포, PowerShell, System Central VM Manager 사용
      4) 컨테이너는 단일 노드에 로컬 스토리지용 Azure 디스크를 사용, 여러 노드나 서버에는 Azure Files(SMB 공유)로 공유
           VM은 VHD(가상 하드 디스크) 사용, 여러 서버 공유에는 마찬가지로 SMB 파일 공유
      5) 내결함성 : 클러스터 노드에 장애 발생 시, 오케스트레이터가 모든 컨테이너를 다시 만듦.
                           VM의 경우 장애 조치(Failover) 설정 가능. 이 때 재부팅이 발생
    : 컨테이너를 사용하면 유연성/속도/테스트 원할/배포 간소화/워크로드 밀도에 대한 리소스 사용률 개선이 가능
  • Azure Container Instances 검토 (3분 예상 -> 5분 소요) 
    : 원시 컨테이너 컨샙 (ACI)
    : 컨테이너는 이미지에서 만들어짐 : 어플리케이션을 실행하는데 필요한 모든 것을 캡슐화한 소프트웨어 패키지
                       (코드, 런타임, 시스템 도구, 시스템 라이브러리, 설정이 포함됨)
    : 컨테이너는 공용 IP 및 DNS(FQDN)으로 인터넷에 직접 노출 가능
      동적 크기 조정이 가능하며, 영구 스토리지 컨테이너는 Azure Files 공유 직접 탑재를 지원
  • 컨테이너 그룹 구현 (4분 예상 -> 15분 소요) 
    : Kubernetes의 Pod 개념과 유사. 일반적으로 Pod는 컨테이너와 1:1 매핑되지만, 여러 컨테이너가 포함될 수 있음. (리소스 공유)
      하나의 호스트 컴퓨터에서 예약되며, DNS가 할당됨. 컨테이너 그룹은 수명 주기, 리소스, 로컬 네트워크, 스토리지 볼륨을 공유
    : 모든 컨테이너의 리소스 요청을 함께 취합하여 리소스를 다중 컨테이너 그룹에 할당함. (GPU, 메모리, CPU)
    : ARM 템플릿이나 YAML로 배포 관리 가능
    : 그룹은 외부 연결 IP주소, 해당 IP 주소에 있는 하나 이상의 포트, FQDN이 포함된 DNS 레이블을 공유함.
      노출을 통해 외부 클라이언트 엑세스가 가능하며, 포트 매핑은 지원되지 않음, 그룹이 삭제되면 관련 IP, FQDN이 해제됨.
    : 다중 그룹을 구현하여 업데이트와 실행을 동시 진행 가능
  • Azure Container Apps 검토 (4분 예상 -> 10분 소요)
    : API 앤드포인트 배포, 후순위 처리 작업 호스팅, 이벤트 기반 처리 수행, 마이크로서비스 실행에 사용
    : HTTP 트래픽, 이벤트 기반 처리, CPU 또는 메모리 로드로 확장 설정 가능
    : Kubernates, Dapr, KEDA, envoy와 같은 오픈 소스 기술을 통해 제공됨.
기능 ACA(Azure Container Apps) AKS(Azure Kubernetes Service)
개요 ACA는 기본 인프라를 추상화하여 마이크로 서비스 기반 애플리케이션의 배포 및 관리를 간소화하는 서버리스 컨테이너 플랫폼입니다. AKS는 운영 오버헤드를 Azure로 오프로드하여 Azure에 관리형 Kubernetes 클러스터 배포를 간소화합니다. 오케스트레이션이 필요한 복잡한 애플리케이션에 적합합니다.
배포 ACA는 빠른 배포 및 관리 기능을 갖춘 PaaS 환경을 제공합니다. AKS는 Kubernetes 환경에 대한 더 많은 제어 및 사용자 지정 옵션을 제공하므로 복잡한 애플리케이션 및 마이크로 서비스에 적합합니다.
관리 ACA는 AKS를 기반으로 하며 컨테이너를 실행하기 위한 간소화된 PaaS 환경을 제공합니다. AKS는 Kubernetes 전문 지식을 갖춘 팀에 적합한 Kubernetes 환경에 대한 보다 세부적인 제어를 제공합니다.
확장성 ACA는 HTTP 기반 자동 크기 조정 및 이벤트 기반 크기 조정을 모두 지원하므로 수요 변화에 신속하게 대응해야 하는 애플리케이션에 적합합니다. AKS는 수평 Pod 자동 크기 조정 및 클러스터 자동 크기 조정을 제공하여 컨테이너화된 애플리케이션에 대한 강력한 확장성 옵션을 제공합니다.
사용 사례 ACA는 빠른 크기 조정 및 간소화된 관리를 활용하는 마이크로 서비스 및 서버리스 애플리케이션을 위해 설계되었습니다. AKS는 복잡하고 장기적으로 실행되는 애플리케이션에 가장 적합합니다. 이러한 애플리케이션에는 전체 Kubernetes 기능과 다른 Azure 서비스와의 긴밀한 통합이 필요합니다.
통합 ACA는 이벤트 기반 아키텍처를 위해 Azure Logic Apps, Functions 및 Event Grid와 통합됩니다. AKS는 포괄적인 보안 및 거버넌스를 위해 Kubernetes용 Azure Policy, 컨테이너용 Azure Monitor 및 Kubernetes용 Azure Defender와 같은 기능을 제공합니다.

5) Virture Network

 

[Keywords]

VNet & subnet & IP types / peering / Resolution / NSG / ASG / Bastion / Private endpoint / DNS / load balancer

 

Configure and manage virtual networks in Azure

Configure secure access to virtual networks

Configure name resolution and load balancing

 

[Reference]

[상세 내용]

 

5-1) 가상 네트워크 구성

  • 가상 네트워크 계획 (3분 예상 -> 10분)
    : Azure 리소스를 논리적으로 격리한 것. 가상 네트워크를 사용하여 VPN을 프로비저닝하고 관리할 수 있음.
    : 각 Vnet은 고유한 CIDR(Classless interdomain Routing) 블록을 가지고 있으며, 다른 Vnet 혹은 On-prem과 연동 단위가 됨
    : 연결 네트워크의 CIDR 블록이 겹치지 않으면 Vnet을 On-prem IT인프라와 연결하여 하이브리드, 프레미스 간 솔루션 구성 가능
    : Vnet에 대한 DNS 서버 설정을 제어하고 Vnet을 서브넷으로 구분함.
    : 용도 = 프라이빗 망 만들기, 데이터 센터와 Azure의 결합 (IPSEC을 통한 VPN Gateway를 통해 보안 연결), 하이브리드 연동 채널
  • 서브넷 만들기 (3분 예상 -> 20분 소요)
    : 각 서브넷은 Vnet 주소 공간에 속하는 IP 주소의 범위를 포함되며, IP주소 범위는 고유하고 겹치지 않아야 함.
    : IP 주소는 CIDR 표기법을 사용하여 지정
    : 예약된 주소 = 각 서브넷에 Azure가 기본적으로 5개의 IP를 예약함. (처음 4개와 마지막 1개)
                            192.168.1.0/24를 사용한다고 할 때,
                            192.168.1.0은 Vnet의 주소를 식별함.
                            192.168.1.1은 기본 게이트웨이 구성에 사용함.
                            192.168.1.2~3은 DNS IP를 Vnet 공간에 맵핑
                            192.168.1.255는 Vnet의 브로드캐스트 주소 제공
    : Vnet을 VPN Gateway에 연결하려면 게이트웨이 전용 서브넷이 필요하고, 각 서비스의 요건(주소 할당 범위 필요양)의 고려 필요
    : 네트워크 가상 어플라이언스를 고려하여 Azure 기본 라우팅(모든 서브넷간 라우팅)을 제어할 수도 있다. 
    : 네트워크 보안 그룹을 서브넷에 연결할 수 있으며, Private Link를 통해 PaaS 서비스와의 Public 통신을 제어할 수 있다.
  • 가상 네트워크 만들기 (2분 예상 -> skip)
  • IP 주소 지정 계획 (2분 예상 -> )
    : 퍼블릭/프라이빗의 개념 이해 필요.
    : 정적/동적 할당이 가능하며, 각각의 IP를 서로 다른 서브넷으로 분리할 수 있음. 동적일 때, VM이나 리소스가 중지되면 변경됨
    : 고정 IP는 변경되지 않으며, DNS이름을 가지는 리소스, 앱 또는 서비스의 보안에 필요한 경우, TLS/SSL 인증서 IP주소 기반할 때,
      IP 주소 범위로 트래픽을 허용하거나 거부하는 방화벽 규칙을 적용할 때, 도메인 컨트롤러/DNS서버 같은 역할 기반 가상머신 운용 시
      IP 고정이 필요함
  • 공용 IP 주소 지정 만들기 (2분 예상 -> skip)
  • 공용 IP 주소 연결 (2분 예상 -> 15분 소요 )
    : 가상 머신에 NIC로 public 네트워크 연결, loadbalancer에 프론트엔드구성, VPN게이트웨이의 IP구성, 프론트엔드 구성 등에 
      Public IP를 연결할 떄, 동적/고정 IP 모두 활용이 가능함.
    : 기준SKU와 표준SKU가 있는데
      기준은 고정 및 동적IP를 할당 받으며, 열려있고 NIC, VPN/App Gateway, LoadBalancer에 사용된다. 영역에 중복이 없음.
      표준은 정적IP를 할당 받으며, 닫혀있고, 인바운드 트래픽을 수신하지 않는다. NIC 또는 공용 로드밸런서에서 중복 영영으로 구성됨.
  • Private IP 주소 할당 (1분 예상 -> 5분 소요)
    : 가상머신 NIC, 내부 로드밸런서, 프론트 앤드 구성에 동적/고정으로 사용 가능함.
    : 초기 설정은 할당되지 않은 주소 중 임의 값이 할당되어 사용 가능함.
  • 대화형 랩 시뮬레이션 (15분 예상 -> skip)

5-2) 네트워크 보안 그룹 구성

  • 네트워크 보안 그룹 구현 (3분 예상 -> 3분 소요)
    : 서브넷 또는 Network I/F에 보안 그룹을 할당하고, 트래픽을 제어하는 개념
    : 인바운드/아웃바운드를 구분하여 거부 또는 허용 규칙 목록을 작성함.
    : 여러번 연결할 수 있으며, 보안 규칙으로 정의 가능. 각 VM은 할당된 서브넷, NI, NSG를 볼 수 있음.
    : DMZ를 만드는 방안이 될 수 있고, 보안 그룹을 만들어 NIC에 직접 할당도 가능하다. 
    : 서브넷의 각 Network Interface에는 0개 또는 1개의 보안 그룹을 할당 할 수 있다.
  • 네트워크 보안 그룹 규칙 결정 (4분 예상 -> 10분 소요)
    : 각 NSG에는 기본적으로 구성되는 몇가지 규칙이 있음 (DenyAllInbound, AllowInternetOutbound, 우선권 65000대로 구성)
    : 규칙은 출처(IP주소, 서비스 또는 app 보안 그룹), 원본 포트 범위, 목적지, 프로토콜 (TCP, UDP, ICMP), 허용/거부, 우선권
      TCP:Transmission Control Protocol, UDP:User Datagram Protocol, ICMP:Internet Control Message Protocol 
    : 우선권은 숫자가 낮으면 더 우선함. 기본 보안 규칙은 제거할 수 없고, 기본보다 더 높은 우선순위를 만들어 재정의하는 개념
    : 인바운드 기본 규칙 : 65000 AllowVnetInBound, 65001 AllowAzureLoadBalancerInBound, 65002 DenyAllInbound
    : 아웃바운드 기본 규칙 : 65000 AllowVnetOutBound, 65001 AllowInternetOutBound, 65002 DenyAllOutbound
  • : VM을 예로들어, 서브넷과 Network Interface에 각각 NSG가 지정되면 각각을 개별로 평가함으로 평가 순서를 고려하여
      필요한 내용을 양쪽에 모두 작성해줘야 한다.
    : '유효한 보안 규칙' 기능을 사용하여 해당 보안 규칙이 어디에 사용되고 있는지 확인할 수 있다.
  • 네트워크 보안 그룹 규칙 만들기 (3분 예상 -> 2분 소요)
    : 원본, 대상, 서비스(Http(s), SSH, RDP, SQL, FTP, SMTP 등 지정), 우선순위와 이름으로 구성한다.
  • 애플리케이션 보안 그룹 구현 (5분 예상 -> 3분 소요)
    :IP의 고정 유무를 파악, 어플리케이션 보안 그룹을 통해 설정하는 것을 고려할 것. 간소화를 지향할 것.

5-3) Azure DNS에서 도메인 호스트

  • Azure DNS란? (7분 예상 -> 25분 소요)
    : Azure 상의 DNS(Domain Name System), IP주소를 사람이 읽을 수 있는 도메인 이름으로 변경하는 역할
    : 최근 사용된 도메인 이름과 IP에 대한 로컬 케시 유지, 검색이 어려운 경우 시간이 다할 때까지 다른 DNS로 요청을 전달
    : IP주소/DNS 서버 권한이 있는 모든 호스트 또는 하위 도메인의 키-값 쌍 DB를 유지함. 메일/웹 및 기타 인터넷 도메인과 주로 연결됨
    : 외부 디바이스들이 웹 기반 리소스 접속 시 DNS 서버를 참조해야함. On-prem은 자체 서버에서, 외부는 ISP에서 공급됨.
    : DNS 조회 요청은 적절한 수의 DNS를 검사하거나 시간이 초과될 때까지 계속 된다.
    : IPv4 는 0~255 4개의 '.'으로 구분된 숫자집합, IPv6는 8개의 16진수 그룹으로 ':'으로 구분됨. DNS는 둘 모두를 지원함.
    : [DNS 레코드 형식]
       A Record : 가장 일반적이며, 도메인 또는 호스트 이름을 IP주소에 매핑하는 파일
       CNAME : 한 도메인에서 다른 도메인으로 별칭을 만들 때 사용되는 정식 이름 레코드, 서로 다른 도메인이 같은 웹에 접속할 때 사용
       MX : 메일 교환 레코드, 메일 서버에서 메일 요청을 매핑
       TXT : 텍스트 레코드, 텍스트 문자열을 도메인 이름과 연결. Azure 및 M365로 도메인 소유권 확인
       기타 : 와일드카드, CA(Certificate Authority), NS(이름 서버), SOA(권한 개시 정보), SPF(발시자 정책 프레임워크),SRV(장소)
       NS와 SOA는 Azure DNS 생성 시 자동으로 만들어지는 레코드
    : 레코드 집합 - 단일 레코드에 여러 리소스를 정의하는 경우 사용 (SOA, CNAME에는 레코드 세트가 포함되지 않음
    : Azure DNS는 도메인의 SOA를 확보하고 호스팅하는 개념이고, 타사 DNS를 통해 해당 주소를 레코드에 등록해야 한다.
    : AzureDNS 사용 이유 : 보안 기능, 사용 편의성, 프라이빗 도메인, 별칭 레코드 집합
  • : 1단계 = 원하는 도메인을 외부 기관에 등록하고, Azure DNS 영역을 생성함.
      2단계 = 생성된 영역에는 NS(이름 서버)가 등록되어 있음. 해당 NS의 상세를 취득
      3단계 = 1단계에서 등록했던 외부 기관의 도메인 관리 어플에 로그인해서 NS 레코드를 편집함
      4단계 = 잘 등록되었는지 확인 (nslookup -type=SOA 도메인)을 입력하면 지점 확인 가능
      5단계 = A레코드 또는 CNAME을 등록하여 사용자 지정 도메인으로 연동 가능
    : [A record 형태]
      이름 : 사용자 지정 도메인 이름
      형식 : A
      TTL : time-to-live로 DNS 검색 지속 시간을 의미
      IP주소 : 이 A 레코드가 연결되어야 하는 서버의 IP
    : [CNAME Record 형태]
      www.~.com  과 ~.com 을 동일한 페이지로 연결하고 싶을 때 사용한다.
      등록 자체를 DNS영역에다가 한다.
      이름 : www / TTL : 600초 / 레코드 유형 : CNAME 처럼 구성
    : 프라이빗 DNS영역은 가상 네트웤 내에서만 통하는 DNS를 의미한다. 
      프라이빗 DNS 영역은 VNet을 링크할 수 있도록 탭이 구성되어 있다.
      
  • : 로드 벨런서 같은 서비스를 위해 레코드 등록하기. 
    : @는 정점 도메인을 나타내고, Apex도메인이라고 함. Apex 도메인을 영역 Apex, 루트 Apex라고도 함.
    : NS, SOA는 자동으로 생겨, @로 기재되어 있음.
    : [별칭 레코드]
       Apex 도메인이 DNS 영역에서 다른 Azure 리소스를 참조 가능.
       Traffic Manager 통해 모든 트래픽 라우팅,  Azure Content Delivery Network 엔드포인트, 공용 IP 리소스,Front Door프로필
       별칭 레코드는 대상 리소스를 주기적으로 추적해 변경 사항을 반영하고, 부하 분산 앱을 지원함.
       A(IPv4 매핑), AAAA(IPv6매핑),CNAME(별칭, A 레코드에 대한 링크) 지원
     
    -> 무슨 이야기인지 잘 모르겠음....
  • : 두개의 VM과 하나의 분산 장치를 사용하여 가상 네트워크 설정, 영역 Apex에서 Azure 별칭을 구성하여 부하 분산 장치로 이동
      도메인 이름이 가상 네트워크의 VM 중 하나로 확인되는지 확인
    Vnet과 VM/NIC - 부하 분산 장치를 구성하고 영역에서 A record로 공용 IP 주소를 연동

5-4) Azure 가상 네트워크 피어링 구성

5-5) 경로를 사용하여 Azure 배포에서 트래픽 흐름 관리 및 제어

5-6) Azure Load Balancer 소개

5-7) Azure Application Gateway 소개

5-8) Azure Network Watcher 소개

6) Monitor & back-up 

 

[Keywords]

Alerts & Log Analytics & metric / action group / Recovery Vault = Backup + ASR / Site Recovery / Failover

 

Monitor resources in Azure

Implement backup and recovery

 

[Reference]

[상세 내용]

 

6-1) Azure Backup 소개

6-2) Azure Backup을 사용하여 가상 머신 보호

6-3) Azure Monitor 소개

6-4) Azure Monitor 경고를 사용하여 인시던트 대응 개선

6-5) Azure Monitor 로그를 사용하여 Azure 인프라 분석

 

 

저작자표시 비영리 변경금지 (새창열림)

'Data Engineering > Cloud_Azure' 카테고리의 다른 글

AZ-900 (취득완료)  (0) 2025.03.13

'Data Engineering/Cloud_Azure' Related Articles

티스토리툴바