가용성 계획에 포함되어야 하는 전략

1. 계획되지 않은 하드웨어 유지 관리 : 물리적 컴퓨터에 연결된 하드웨어 또는 플랫폼 구성 요소가 실패할 것으로 예측하는 경우에 발생 -> 실시간 마이그레이션 기술을 사용하여 오류가 발생한 하드웨어에서 정상적인 물리적 컴퓨터로 가상 머신을 마이그레이션 -> 성능저하 우려 있음
2. 예기치 않은 가동 중지 시간 : 로컬 네트워크 오류, 로컬 디스크 오류 또는 기타 랙 수준의 오류가 포함 -> 가상 머신을 동일한 데이터 센터의 정상적인 물리적 컴퓨터로 자동으로 마이그레이션(복구) -> 임시 드라이브가 손실 우려 있음
3. 계획된 유지 관리 : 플랫폼 인프라의 전반적인 안정성, 성능 및 보안을 개선하기 위해 Microsoft에서 기본 Azure 플랫폼으로 정기적으로 업데이트

• 가상 머신 운영 체제 또는 기타 소프트웨어를 자동으로 업데이트하지 않습니다. 이러한 업데이트는 전적으로 사용자의 제어와 책임 하에 실시됩니다. 그러나 기본 소프트웨어 호스트 및 하드웨어는 안정성과 고성능을 보장하기 위해 정기적으로 패치
  
  
  

가용성 집합

• 특징

1. 동일 가용성 집합의 가상 머신은 모두 동일한 기능을 수행
2. 동일 가용성 집합의 가상 머신은 모두 동일 소프트웨어 설치
3. 동일 가용성 집합의 가상 머신은 여러 물리적 서버, 컴퓨팅 랙, 스토리지 단위 및 네트워크 스위치에 나눠 실행
4. 가용성 집합을 변경하려면 가상 머신을 삭제한 다음, 다시 만들어야 함
5. 단일 실패 지점이 모든 컴퓨터에 영향을 주지 않도록 하는 데 도움 -> 호스트 운영 체제를 업그레이드하는 동안 모든 컴퓨터가 동시에 업그레이드되지 않도록 함
   
   
   

• 고려 사항

1. 중복 고려
2. 애플리케이션 계층의 분리를 고려 : 각 애플리케이션 계층은 별도의 가용성 집합 필요 -> 실패지점 확산 방지
3. 부하 분산을 고려 : Azure Load Balancer를 사용
4. 관리 디스크를 고려 : 블록 수준 스토리지
   
   
   

업데이트 도메인 및 장애 도메인

• 업데이트 도메인 : 서비스 업그레이드(또는 롤아웃) 프로세스 중에 함께 업그레이드되는 노드 그룹 -> Azure가 배포 전체에서 증분 또는 롤링 업그레이드를 수행

• 장애 도메인 : 실패의 물리적 단위를 나타내는 노드 그룹 -> 동일한 물리적 랙에 속하는 노드로 간주 -> 장애 도메인은 단일 실패 지점을 공유하는 공통된 하드웨어(또는 스위치) 집합
  
  
  

• 가용성 집합내 VM은 각각 업데이트 도메인과 장애 도메인에 배치됨

• 업데이트 도메인은 기본 5개, 최대 20개까지 구성 가능

• 한 번에 한 개의 업데이트 도메인만 다시 부팅

• 두 개의 장애 도메인이 함께 동작되어 하드웨어 오류, 네트워크 중단, 전원 중단 또는 소프트웨어 업데이트에 따른 상황을 완화
  
  
  

• 장애 도메인과 가용성 집합 구성

가용성 영역

• 가용성 영역 : 데이터 센터 오류에서 애플리케이션 및 데이터를 보호하는 고가용성 기능 (장애 도메인과 업데이트 도메인의 조합)
  
  
  

• 특징

1. Azure 지역 내의 고유한 물리적 위치
2. 각 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터
3. 모든 지역에서 최소한 세 개의 별도 영역이 필요
4. 가용성 영역을 물리적으로 구분하면 애플리케이션 및 데이터를 데이터 센터 오류로부터 보호 가능
5. 영역 중복 서비스는 단일 실패 지점으로부터 보호하기 위해 가용성 영역 전체에서 애플리케이션과 데이터를 복제
   
   
   

Scaling

• 스케일링 기능 : VM 처리량에 하드웨어 리소스를 맞추는 기능
  
  
  

• 수직 스케일링(Scale up/down) : VM의 크기를 늘리거나 줄임

1. 활용률이 낮을 때 비용 절감을 위해 VM크기 줄임
2. 더 많은 처리를 위해 VM크기 늘림
   
   
   

• 수평 스케일링(Scale out/in) : VM 수 조정
  
  
  

• 고려사항

1. 일반적으로 수평 스케일링은 수직 스케일링보다 제한 사항이 적음 : 수직은 지역별로 달라질 수 있음, 수평은 데이터에 대한 액세스가 일시적으로 제한될 수 있음
2. 유연성 고려 : 수평 스케일링이 더 유연
3. 재설정 고려 : 다시 프로비저닝이 필요할 수 있는 경우와 서비스 중단 계획을 고려
   
   
   

Scale Sets

• Azure Virtual Machine Scale Sets : 동일한 VM 세트를 배포 및 관리하는 데 사용할 수 있는 Azure 컴퓨팅 리소스 -> auto scaling 가능
  
  
  

• 특징

1. 모든 가상 머신 인스턴스는 동일한 기본 운영 체제 이미지 및 구성
2. 기본 레이어 4 트래픽 배포를 위해 Azure Load Balancer 사용을 지원하고 고급 L7 트래픽 배포 및 TLS/SSL 종료를 위해 Azure Application Gateway 사용을 지원
3. 중단을 최소화하면서 다른 가상 머신 인스턴스를 통해 애플리케이션에 계속 액세스
4. 고객의 요구를 충족하기 위해 Virtual Machine Scale Sets는 자동 스케일링을 구현
5. 최대 1,000개의 가상 머신 인스턴스를 지원 (사용자 지정 가상 머신 이미지인 경우 최대 600개)
   
   
   

• Scale Sets을 만들기 위한 설정

1. 오케스트레이션 모드 : 가상 머신을 관리하는 방법을 선택 -> 가상 머신 모델을 수동 정의 -> Azure는 해당 모델을 기반으로 동일한 인스턴스를 생성
2. 이미지 : VM의 기본 운영 체제 또는 애플리케이션
3. VM 아키텍처 : x64 또는 Arm64 기반 가상 머신을 선택 가능
4. VM 크기 : 처리 성능, 메모리 및 스토리지 용량 등의 요소를 결정
5. 크기조정 모드
   • 자동 크기 조정 설정
     • 기본 인스턴스 수 : 초기 가상 머신 수(0~1000)
     • 인스턴스 제한 : 스케일 다운하려는 최소 인스턴스 수, 스케일 업하려는 최대 인스턴스 수
     • 스케일 아웃 : 스케일 아웃 자동 크기 조정 규칙을 트리거하기 위한 CPU 사용량 백분율 임계값. 스케일 아웃할 인스턴스 수
     • 스케일 인 : 스케일 인 자동 크기 조정 규칙을 트리거하기 위한 CPU 사용량 백분율 임계값. 스케일 인할 인스턴스 수
     • 쿼리 기간 : 이 기간은 자동 크기 조정 엔진이 메트릭 사용량 평균을 다시 조회하는 시간.
     • 일정: 시작 및 종료 날짜를 지정. 특정 요일에 일정을 반복할 수도 있음
       
       
       

Auto Scaling

• 고려사항

1. 자동 조정된 용량 : 정의된 임계값이 충족되면 자동 크기 조정 규칙이 작동
2. 스케일 아웃 : 구현된 가상 머신 인스턴스의 수를 늘리도록 자동 크기 조정 규칙을 구성
3. 스케일 인 : 감소된 로드가 일정 기간 동안 일관성 있게 유지될 경우 구현된 가상 머신 인스턴스 수를 줄이도록 자동 크기 조정 규칙을 구성
4. 예약 이벤트 : 정해진 시간에 구현의 용량을 자동으로 늘리거나 줄이도록 이벤트를 예약
5. 오버헤드 : 자동 크기 조정과 함께 Azure Virtual Machine Scale Sets를 사용하면 애플리케이션의 성능을 모니터링하고 최적화하는 데 드는 관리 오버헤드 감소 가능

Azure 컴퓨팅 리소스

1. VM (Virtual Machine)
2. 스토리지용 디스크
3. 가상 네트워크
4. 네트워크 인터페이스
5. 네트워크 보안 그룹 (네트워크 트래픽 보호)
6. IP주소
   
   
   

VM (Virtual Machine)

• VM 생성 시, 고려해야할 사항

1. 네트워크
2. VM 이름
3. 생성 위치
4. VM 크기
5. 디스크
6. 운영 체제
   
   
   

네트워크

• 동일 VNet(가상 네트워크)에서 Azure 서비스간 연결 가능 (프라이빗 연결) -> VNet 외부와 연결하도록 구성 가능
• 가상 네트워크 설정 내용

1. 사용 가능한 주소
2. 서브넷 : 서로 다른 VNet간에 서브넷이 겹치면 안됨
3. 보안 : 서브넷 및 VM간에 NSG(네트워크 보안 그룹)를 설정하여 트래픽 제어 가능 (방화벽 역할)
   
   
   

VM 이름

• VM에서 수행하는 작업을 쉽게 식별할 수 있도록 의미 있고 일관성 있는 이름을 선택
• 이름에 포함시키길 권장하는 정보 (ex. deveus-webvm01 : 미국 동부 지역에서 호스트되는 첫 번째 개발 웹 서버)

VM 생성위치

• 고려사항

1. 위치에 따른 사용가능 옵션 제한
2. 위치 간의 가격 차이
   
   
   

VM 크기

• 원하는 작업에 적합한 컴퓨팅, 메모리 및 스토리지의 적절한 조합 선택 가능
• VM 크기는 변경 가능 -> 크기 조정 시에 VM이 자동으로 부팅되어 일시적으로 서비스가 중단될 수 있음
• 작업 옵션에 따른 설명

VM 스토리지

• VM당 둘 이상의 VHD(가상 하드 디스크)가 있음

1. 운영체제 저장
2. 임시 스토리지
3. 추가 스토리지 : 애플리케이션 데이터 저장 용도
   
   
   

• 최대 디스크 수는 VM크기에 따라 결정
  
  
  

• 특정 시나리오에 따른 5가지 디스크 유형

운영체제

• Azure에서 VM 구성을 위한 다양한 OS 이미지 제공 -> 원하는 이미지가 없을 경우, 커스텀 가능
• Azure Marketplace에서 다양한 이미지 선택 가능
• OS 라이선스 비용이 컴퓨팅 가격에 영향을 미침
  
  
  

VM 가격책정 방식

1. 종량제
   • 컴퓨팅 비용 : 분당 요금으로 청구 (VM크기와 OS에 따라 다름)
   • 스토리지 비용 : VM 중지 및 할당 취소에 관계없이 디스크를 사용중이라면 별도 요금 지속 청구
2. 예약 인스턴스 : 1년 or 3년 동안 VM을 사전 구매하는 방식 (약정) -> 종량제에 비해 최대 72% 가격 절감 효과
   
   
   

Azure VM을 만드는 방법

1. Azure 리소스 관리자 템플릿
   • 배포 리소스를 정의한 JSON 파일
   • 기존 VM에서 템플릿 내보내기 활용
2. Azure PowerShell
3. Azure CLI
   • az vm create
4. Azure REST API
   • 프로그래밍 방식 REST API 호출
5. Azure 클라이언트 SDK
   • 프로그래밍 방식 SDK 활용
6. Azure VM 확장
7. Azure Automation 서비스
   • 시간 소모적이고 오류가 발생하기 쉬운 관리 작업을 자동화하는 서비스들을 통합
   • 프로세스 자동화 (ex. 발생 이벤트에 대해 응답해주는 감시자 작업 등)
   • 구성 관리 (ex. OS에서 사용할 수 있는 소프트웨어 업데이트 추적 등)
   • 업데이트 관리 (ex. VM에 대한 업데이트 및 패치 관리, 사용 가능한 업데이트 상태 확인->설치 예약->배포 결과 검토 등)
8. Terraform
   • 클라우드 인프라의 정의, 미리보기 및 배포 사용
   • HCL구문의 구성 파일로 실행계획 작성 및 적용 후 인프라 배포
     
     
     

Azure VM 가용성 관리

• 지속 가능한 서비스, 데이터 안전 유지를 위한 가용성 관리 -> 비즈니스 연속성 및 재해 복구 전략 고민
• 가용성 영역 (AWS의 AZ?) : 동일 Azure 지역 내에서 물리적으로 별도의 영역
• VM 크기 집합 (Scale Group?) : 부하 분산 VM 그룹, VM 인스턴스의 수를 자동으로 확장or축소
• Azure Load Balancer : 트래픽을 여러 VM에 분산 -> 가용성 영역 or 가용성 집합(크기집합?)과 결합하여 복원력 극대화
• Azure Storage 복사본 : 데이터 보호를 위해 여러 복사본 저장 (기본 지역 데이터 복제, 보조 지역 복제, 보조 지역으로의 액세스 권한 여부 등 옵션 선택)
• 장애 조치 (failover) : Azure Site Recovery 활용, 워크로드를 기본 위치에서 보조 위치로 복제(장애조치)
  
  
  

VM 백업

• Azure Backup 활용
• Azure Backup : 온-프레미스 or 클라우드 등으로 가상 머신을 보호하는 서비스 기반 백업 제품

• Azure Backup 장점

1. 자동 스토리지 관리
2. 무제한 크기 조정
3. 여러 스토리지 옵션 (ex. 로컬 중복 스토리지, 지역 중복 스토리지 등)
4. 무제한 데이터 전송
5. 데이터 암호화
6. 보존 시간 제한 없음
   
   
   

• Recovery Services 자격 증명 모음을 사용하여 백업 데이터 저장 (백업 머신 선택 및 백업 정책 정의 가능) -> Azure Storage Blob으로 백업

Azure Files

• Azure Files : 완전 관리형 파일 공유를 제공
  
  
  

• 접근 방법

1. SMB(서버 메시지 블록)
2. NFS(네트워크 파일 시스템)
3. HTTP 프로토콜
   
   
   

• 특성

1. 인프라를 필요로 하지 않는 완전 관리형 파일 공유의 PaaS 제품 (VM, 운영체제 등 자동 업데이트)
2. 최대 100TiB(테비바이트)의 파일을 저장
3. 온-프레미스 파일 서버와 동일한 방식으로 계층 구조의 폴더 구조
4. 데이터 미사용 시 암호화, 전송중 암호화 지원
5. 인터넷에 연결된 경우 어디서나 Azure 파일 공유에 액세스
6. 사용자가 온-프레미스 파일 서버에 액세스할 때와 동일한 방식으로 Azure 파일 공유에 액세스 (동기화되는 Microsoft Entra ID 또는 AD DS ID 등 활용)
7. 이전 버전 기능과 통합되는 Azure 파일 공유 스냅샷 생성 가능
8. Azure Backup을 통한 파일 백업 가능
9. 여러 Azure 데이터 센터의 여러 위치에 복제 (Azure 스토리지 계정의 복제 설정)
   
   
   

• 사용 시나리오

1. 기존 온-프레미스 파일 서버 또는 NAS 디바이스를 대체하거나 보완
2. 전 세계 어디서나 접근
3. 애플리케이션을 쉽게 리프트 앤 시프트할 수 있음 (옮기는 것)
4. Azure 파일 동기화를 사용하여 Azure 파일 공유를 Windows Server에 복제
5. 로그, 메트릭 및 크래시 덤프와 같은 진단 데이터를 공유 위치에 저장
6. 개발하거나 관리하는 데 필요한 도구 및 유틸리티를 저장하는 데 좋은 옵션
   
   
   

• Azure Files vs Azure Blob Storage

Azure Files 공유

• SMB(서버 메시지 블록) 프로토콜과 NFS(네트워크 파일 시스템) 프로토콜을 모두 제공하지만, 동일 파일 공유에서 동시에는 제공하지 않음
• Azure Files 공유 유형
  
  
  

1. 프리미엄 스토리지 계층
   • SSD에 데이터 저장
   • FileStorage 계정 유형
   • 일관된 고성능, 짧은 대기시간
2. 스탠다드 스토리지 계층
   • HDD에 데이터 저장
   • GPv2(범용 버전 2) 스토리지 계정 유형
     
     
     

• 인증 형식

1. SMB를 통한 ID 기반 인증 : 온-프레미스 파일 공유에 액세스할 때와 동일한 SSO(Single Sign-On) 환경 제공
2. 액세스 키
   • Azure Files를 포함하여 스토리지 계정에 대한 요청을 할 때 사용할 수 있는 두 개의 액세스 키에 해당
   • 모든 액세스 제어 제한을 우회하므로 사용자와 공유하지 않고 액세스 키를 보호해야 함
   • ID기반 인증 권장
3. SAS(공유 액세스 서명 토큰)
   • 액세스 키 기반으로 동적으로 생성하는 URI로 인증
   • 제한된 권한과 시간
   • Azure Files를 사용하면 SAS 토큰은 코드에서 REST API 액세스를 제공하는 데만 사용
     
     
     

• SMB Azure File 공유 만들기

1. 포트 445를 엽니다 : SMB는 445 TCP 포트를 통해 통신함
2. 보안 전송을 사용하도록 설정합니다 : 보안 연결로만 스토리지 계정에 대한 요청을 제한하여 스토리지 계정의 보안을 향상 (REST API 활용 고려, HTTPS)
   
   
   

• 파일 공유 스냅샷 만들기 (데이터의 읽기 전용 시점 복사본 캡처)

1. 스냅샷 기능은 파일 공유 수준에서 제공
2. 최근 공유 스냅샷 이후 변경된 데이터만 저장
3. 시간을 최소화하고 스토리지 비용을 절감 가능
4. 공유를 복원하려면 가장 최근의 공유 스냅샷만 유지해야 함
5. 파일 공유 또는 스토리지 계정에서 키보드 입력 실수로 인한 삭제를 방지하지 않음
   
   
   

• Azure Files 일시 삭제

1. 파일공유 수준에서 활성화
2. 영구적이 아닌 일시 삭제 상태로 전환
3. 보존 기간 설정 가능 (보존 기간 : 다시 복구하여 사용할 수 있는 기간, 1~365일)
   
   
   

Azure Storage Explorer

• Azure Storage Explorer : Windows, macOS 및 Linux에서 Azure Storage 데이터를 쉽게 사용할 수 있는 독립 실행형 애플리케이션, 여러 계정 및 구독에 액세스하고 모든 스토리지 콘텐츠를 관리 가능

• 특징

1. 모든 권한을 허용을 위해 Azure Storage Explorer에 관리 권한(Azure Resource Manager)과 데이터 계층 권한이 모두 필요
2. 스토리지 계정, 계정의 컨테이너, 컨테이너의 데이터에 액세스하려면 Microsoft Entra ID 권한이 필요
3. 다른 스토리지 계정에 연결 가능
   • Azure 구독과 연결된 스토리지 계정에 연결
   • 다른 Azure 구독에서 공유되는 스토리지 계정 및 서비스에 연결
   • Azure Storage 에뮬레이터를 사용하여 로컬 스토리지에 연결하고 관리

• 사용 시나리오

Azure Files 동기화

• Azure Files 동기화

1. 온-프레미스 Windows Server 또는 클라우드 가상 머신에 여러 Azure 파일 공유를 캐시할 수 있음
2. Azure Files에서 조직의 파일 공유를 중앙 집중화
   
   
   

• 클라우드 계층화

1. 클라우드 계층화는 Azure 파일 동기화의 선택적 기능
2. 자주 액세스하는 파일은 서버에서 로컬로 캐시되고 다른 모든 파일은 정책 설정에 따라 Azure Files로 계층화
   • 파일이 계층화되면 Azure 파일 동기화는 로컬에서 파일을 포인터로 바꿈
   • 포인터를 일반적으로 재분석 지점이라고 함
   • 구문 분석 지점은 Azure Files의 파일에 대한 URL
     
     
     

• 동기화 사용 시나리오

1. 애플리케이션 리프트 앤 시프트를 고려 (애플리케이션 이동시키기, Windows Server와 Azure Files 간에 동일한 데이터에 대해 쓰기 액세스를 제공)
2. 서비스를 사용하여 Azure Storage에 연결하는 새 서버를 설정
3. Azure 파일 동기화를 구현하면 Azure Backup이 온-프레미스 데이터를 백업
4. Azure 파일 동기화는 최근에 액세스한 데이터만 로컬 서버에 저장합니다. 이전 데이터가 Azure Files로 이동하도록 클라우드 계층을 구현 (클라우드 계층화)

Azure Storage 보안 전략

1. 휴지 상태의 암호화 : 256비트 AES(Advanced Encryption Standard) 암호를 사용하는 SSE(스토리지 서비스 암호화)는 Azure Storage에 기록된 모든 데이터를 암호화합니다. -> Azure Storage가 암호를 해독한 후에 데이터 반환 (비활성화 불가)
2. 인증 : Microsoft Entra ID 및 RBAC(역할 기반 액세스 제어)는 리소스 관리 작업 및 데이터 작업 모두에 대한 Azure Storage에 지원됩니다.
3. 전송 중 암호화 : Azure와 클라이언트 간에 전송 수준 보안을 사용하도록 설정하여 데이터를 안전하게 유지 -> 항상 HTTPS 사용
4. 디스크 암호화(DB외 케이스인 듯) : VM(가상 머신)의 경우 Azure를 사용하면 Azure Disk Encryption을 사용하여 VHD(가상 하드 디스크)를 암호화할 수 있습니다.
5. 공유 액세스 서명(?) : SAS(공유 액세스 서명)를 사용하여 Azure Storage의 데이터 개체에 대해 액세스 권한(?)을 부여
6. 권한 부여 : Blob Storage, Azure Files, Queue Storage 또는 Azure Cosmos DB(Azure Table Storage)의 보안 리소스에 대해 수행한 모든 요청에는 권한이 부여되어야 합니다.
   
   
   

• 권한부여 전략

1. Microsoft Entra ID : 역할 기반 액세스 제어
2. 공유 키 : Azure Storage 계정 액세스 키와 기타 매개 변수를 사용 (요청 시 헤더에 실음)
3. 공유 액세스 서명(SAS)(?) : SAS는 지정된 사용 권한을 사용하고 지정된 시간 간격으로 Azure Storage 계정의 특정 리소스에 대한 액세스 권한을 위임
4. 컨테이너 및 Blob에 대한 익명 액세스 : 필요에 따라 컨테이너 또는 Blob 수준에서 Blob 리소스를 public으로 설정
   
   
   

공유 액세스 서명 (SAS)

• SAS(공유 액세스 서명) : Azure Storage 리소스에 대한 제한된 액세스 권한을 부여하는 URI(Uniform Resource Identifier)
• 스토리지 계정 키에 대한 액세스 권한이 없는 클라이언트에 SAS를 제공 -> 클라이언트에 SAS URI를 배포하여 지정된 기간 동안 리소스에 액세스하도록 할 수 있음

• 클라이언트 인증 -> SAS 생성 -> 클라이언트에 부여 -> 스토리지 계정 리소스에 접근 (SAS는 클라이언트 권한과 액세스 간격을 정의)
  
  
  

• SAS 특성

1. 클라이언트에 부여한 액세스 유형을 세부적으로 제어 가능
2. SAS는 Blob, 파일, 큐 및 테이블과 같은 여러 Azure Storage 서비스에 대한 액세스를 위임 가능
3. SAS가 유효한 시간 간격을 지정 가능
4. SAS에 의해 부여되는 권한을 지정
5. SAS는 계정 수준 및 서비스 수준 컨트롤을 제공
   • 계정 수준 : 서비스 수준보다 큰 범위, 서비스 수준 + 기타 리소스 및 능력에 대한 액세스 허용
   • 서비스 수준 : 스토리지 계정의 특정 리소스에 대한 액세스를 허용
6. SAS를 수락하는 선택적 IP 주소 또는 IP 주소 범위를 식별 가능
7. SAS를 수락하는 프로토콜을 지정 가능
   
   
   

• URI(Uniform Resource Identifier) : SAS(공유 액세스 서명)를 만들 때 매개 변수 및 토큰을 사용하여 URI를 만듭니다. (Azure Storage 리소스 URI + SAS 토큰)
  
  
  

• URI 구성

Azure Storage 암호화

• 암호화 및 암호 해독 프로세스는 자동 수행 -> 데이터는 기본적으로 보호되므로 코드 또는 애플리케이션을 수정할 필요가 없음.

• 256비트 AES(고급 암호화 표준) 암호화를 통해 암호화

• 직접 키를 관리하거나 Microsoft에서 관리하는 키를 사용 가능
  
  
  

• 암호 key 활용
  : Storage 계정 생성 -> 생성 계정에 대해 2개의 512비트 스토리지 계정 액세스 키 생성 -> 공유 키 권한 부여 or 공유 키로 서명된 SAS 토큰을 통해 데이터에 접근
  
  
  

• 암호화 유형

1. 인프라 암호화 : 데이터는 두 가지 암호화 알고리즘과 두 가지 키를 사용하여 서비스 수준에서 한 번, 인프라 수준에서 한 번씩 두 번 암호화
2. 플랫폼 관리형 키 : Azure에서 완전히 생성, 저장 및 관리되는 암호화 키
3. 고객 관리형 키 : 한 명 이상의 고객이 읽고, 만들고, 삭제하고, 업데이트하고, 관리하는 키
   
   
   

• Azure Key Vault

1. 애플리케이션을 중단하지 않고 쉽게 키를 회전(갱신?)시켜 다시 생성 -> 키 관리 자동화
2. Azure Key Vault API를 사용하여 암호화 키를 생성 (고객 관리형 키) -> 다시 생성하거나 기존 키 자격증명에서 선택하여 활용 가능
   
   
   

Best Practice

1. encrypt data at rest and in-flight
   • Always encrypt data at rest
   • Always encrypt in-flight data
2. Restrict access to database
   • Enable database firewalls
   • Use Azure Private Link
3. Restrict access to VMS
   • Disable VM RDP/SSH ports
   • Connect to VMs with Azure Bastion
4. Protect application secrets
   • Store secrets in Azure Key Vault
   • Use managed service identities
5. Use a separate Azure Subscription for production
   • Implement RBAC
   • Use a separate subscription
6. Implement a Web Application Firewall
   • Implement Application Gateway or Front Door
   • Enable Web Application Firewall
7. Use Azure Security Center
   
   
   

• 보안 권장사항