클라우드 자산 보호
이 문서에서는 Azure 클라우드 자산의 안정성과 보안을 유지하기 위한 모범 사례를 제공합니다. 안정성을 사용하면 가동 중지 시간을 최소화하면서 클라우드 서비스가 계속 작동합니다. 보안은 리소스의 기밀성, 무결성 및 가용성을 보호합니다. 안정성과 보안은 성공적인 클라우드 운영에 매우 중요합니다.
안정성 관리
안정성 관리에는 중복성, 복제 및 정의된 복구 전략을 사용하여 가동 중지 시간을 최소화하고 비즈니스를 보호하는 작업이 포함됩니다. 표 1 세 가지 워크로드 우선 순위, 안정성 요구 사항(가동 시간 SLO, 최대 가동 중지 시간, 중복성, 부하 분산, 복제) 및 SLO(서비스 수준 목표)에 부합하는 예제 시나리오의 예를 제공합니다.
표 1. 워크로드 우선 순위 및 안정성 요구 사항의 예입니다.
| 우선권 | 비즈니스 영향 | 최소 가동 시간 SLO | 매월 최대 가동 중지 시간 | 아키텍처 중복성 | 부하 분산 | 데이터 복제 및 백업 | 예제 시나리오 |
|---|---|---|---|---|---|---|---|
| 높음(임무 중요) | 회사 평판 또는 수익에 즉각적이고 심각한 영향을 미칩니다. | 99.99% | 4.32분 | 다중 지역 & 각 지역의 여러 가용성 영역 | 액티브-액티브 | 복구를 위한 동기 지역 간 데이터 복제 & 백업 | 임무에 필수적인 기준 |
| 미디엄 | 회사 평판 또는 수익에 대한 측정 가능한 영향. | 99.9% | 43.20분 | 여러 지역 & 각 지역의 여러 가용성 영역 | 활성-수동 | 복구를 위한 비동기 지역 간 데이터 복제 & 백업 | 신뢰할 수 있는 웹앱 패턴 |
| 낮음 | 회사 평판, 프로세스 또는 수익에는 영향을 주지 않습니다. | 99% | 7.20시간 | 단일 지역 & 다중 가용성 영역 | 가용성 영역 중복성 | 가용성 영역 간 동기 데이터 복제 및 & 복구를 위한 백업 |
App Service 기준 가상 머신 기준선 |
안정성 책임 식별
안정성 책임은 배포 모델에 따라 다릅니다. 다음 표를 사용하여 인프라(IaaS), 플랫폼(PaaS), 소프트웨어(SaaS) 및 온-프레미스 배포에 대한 관리 책임을 식별합니다.
| 책임 | 자체 설치형 | IaaS(Azure) | PaaS(Azure) | SaaS |
|---|---|---|---|---|
| 데이터 | ✔️ | ✔️ | ✔️ | ✔️ |
| 코드 및 런타임 | ✔️ | ✔️ | ✔️ | |
| 클라우드 리소스 | ✔️ | ✔️ | ✔️ | |
| 물리적 하드웨어 | ✔️ |
자세한 내용은 안정성 대한공유 책임을 참조하세요.
안정성 요구 사항 정의
명확하게 정의된 안정성 요구 사항은 가동 시간 목표, 복구 및 데이터 손실 허용 오차에 매우 중요합니다. 안정성 요구 사항을 정의하려면 다음 단계를 수행합니다.
워크로드 우선 순위를 지정합니다. 중요 비즈니스 위험성 및 재무 투자 수준에 따라 워크로드에 높음, 중간(기본값) 또는 낮은 우선 순위를 할당합니다. 비즈니스 목표와 일치를 유지하기 위해 우선 순위를 정기적으로 검토합니다.
모든 워크로드에 SLO(가동 시간 서비스 수준 목표)를 할당합니다. 워크로드 우선 순위에 따라 가동 시간 목표를 설정합니다. 우선 순위가 높은 워크로드에는 더 엄격한 가동 시간 목표가 필요합니다. SLO는 아키텍처, 데이터 관리 전략, 복구 프로세스 및 비용에 영향을 줍니다.
SLI(서비스 수준 지표)를 식별합니다. SLI를 사용하여 SLO에 대한 가동 시간 성능을 측정합니다. 예를 들어 서비스 상태 모니터링 및 오류율.
모든 워크로드에 RTO(복구 시간 목표)를 할당합니다. RTO는 워크로드에 허용되는 최대 가동 중지 시간을 정의합니다. RTO는 연간 허용되는 최대 가동 중지 시간보다 짧아야 합니다. 예를 들어 가동 시간 SLO 99.99% 연간 가동 중지 시간은 52분 미만(매월 4.32분)이 필요합니다. 다음 단계를 수행하세요.
오류 수를 예측합니다. 각 워크로드가 연간 실패할 수 있다고 생각하는 빈도를 예측합니다. 운영 기록이 있는 워크로드의 경우 SLI를 사용합니다. 새 워크로드의 경우 오류 모드 분석 수행하여 정확한 예상을 얻습니다.
RTO를 예측합니다. 연간 허용 가동 중지 시간을 예상 오류 수로 나눕니다. 연간 4개의 오류를 예상하는 경우 RTO는 13분 이하(52분/4 오류 = 13분 RTO)여야 합니다.
복구 시간을 테스트합니다. 장애 조치(failover) 테스트 및 라이브 오류 중에 복구하는 데 걸리는 평균 시간을 추적합니다. 오류에서 복구하는 데 걸리는 시간은 RTO보다 낮아야 합니다. 비즈니스 연속성 솔루션에 몇 시간이 걸리는 경우
모든 워크로드에 대한 RPO(복구 지점 목표)를 정의합니다. 비즈니스에서 허용할 수 있는 데이터 손실의 양을 결정합니다. 이 목표는 데이터를 복제하고 백업하는 빈도에 영향을 줍니다.
워크로드 안정성 목표를 정의합니다. 워크로드 안정성 대상의 경우 안정성 대상을 정의하기 위한 Well-Architected Framework의 권장 사항을 참조하세요.
데이터 안정성 관리
데이터 안정성에는 가용성과 일관성을 유지하기 위한 데이터 복제(복제본) 및 백업(지정 시간 복사본)이 포함됩니다. 데이터 안정성 대상과 일치하는 워크로드 우선 순위의 예는 표 2 참조하세요.
표 2. 예제 데이터 안정성 구성을 사용하는 워크로드 우선 순위입니다.
| 워크로드 우선 순위 | 가동 시간 SLO | 데이터 복제 | 데이터 백업 | 예제 시나리오 |
|---|---|---|---|---|
| 높음 | 99.99% | 지역 간 동기 데이터 복제 가용성 영역 간 동기 데이터 복제 |
높은 빈도의 지역 간 백업. Frequency는 RTO 및 RPO를 지원해야 합니다. | 중요 업무용 데이터 플랫폼 |
| 미디엄 | 99.9% | 지역 간 동기 데이터 복제 가용성 영역 간 동기 데이터 복제 |
지역 간 백업. Frequency는 RTO 및 RPO를 지원해야 합니다. | 신뢰할 수 있는 웹앱 패턴의 데이터베이스 및 스토리지 솔루션 |
| 낮음 | 99% | 가용성 영역 간 동기 데이터 복제 | 지역 간 백업. Frequency는 RTO 및 RPO를 지원해야 합니다. | 기준 웹앱의 데이터 복원력, 영역 중복성을 사용하여 |
이 접근 방식은 데이터 안정성 구성을 워크로드의 RTO 및 RPO 요구 사항에 맞게 조정해야 합니다. 다음 단계를 수행하세요.
데이터 복제를 관리합니다. 워크로드의 RTO 및 RPO 요구 사항에 따라 데이터를 동기적으로 또는 비동기적으로 복제합니다.
데이터 배포 데이터 복제 부하 분산 구성 가용성 영역 간 동기(거의 실시간) 대부분의 PaaS 서비스는 기본적으로 영역 간 부하 분산을 처리합니다. 지역 간(활성-활성) 동기화 활성-활성 부하 분산 지역 간(활성-수동) 비동기(주기적) 활성-수동 구성 자세한 내용은 복제:데이터 중복성을 참조하세요.
데이터 백업을 관리합니다. 백업은 재해 복구(서비스 오류), 데이터 복구(삭제 또는 손상) 및 인시던트 대응(보안)을 위한 것입니다. 백업은 각 워크로드에 대한 RTO 및 RPO 요구 사항을 지원해야 합니다. RTO 및 RPO 목표에 맞는 백업 솔루션을 선택합니다. Azure Cosmos DB 및 Azure SQL Database 네이티브 백업과 같은 Azure의 기본 제공 솔루션을 선호합니다. 온-프레미스 데이터를 비롯한 다른 경우는 azure Backup 사용합니다. 자세한 내용은 Backup참조하세요.
워크로드 데이터 안정성을 디자인합니다. 워크로드 데이터 안정성 디자인의 경우 Well-Architected Framework 데이터 분할 가이드 및 Azure 서비스 가이드 참조하세요(안정성 섹션시작).
코드 및 런타임 안정성 관리
코드 및 런타임은 워크로드 책임입니다. Well-Architected Framework의 자동 복구 및 자기 보존 가이드따릅니다.
클라우드 리소스 안정성 관리
클라우드 리소스의 안정성을 관리하려면 아키텍처 중복성(중복 서비스 인스턴스) 및 효과적인 부하 분산 전략이 필요한 경우가 많습니다. 워크로드 우선 순위에 맞는 아키텍처 중복성의 예는 표 3 참조하세요.
표 3. 워크로드 우선 순위 및 아키텍처 중복 예제입니다.
| 워크로드 우선 순위 | 아키텍처 중복성 | 부하 분산 방법 | Azure 부하 분산 솔루션 | 예제 시나리오 |
|---|---|---|---|---|
| 높음 | 두 개의 가용성 영역 & 지역 | 액티브-액티브 | Azure Front Door(HTTP) Azure Traffic Manager(비 HTTP) |
중요 업무용 기준 애플리케이션 플랫폼 |
| 미디엄 | 두 지역의 & 가용성 영역 | 활성-수동 | Azure Front Door(HTTP) Azure Traffic Manager(비 HTTP) |
신뢰할 수 있는 웹앱 패턴 아키텍처 지침 |
| 낮음 | 단일 지역 & 가용성 영역 | 가용성 영역 간 | Azure Application Gateway 가상 머신용 Azure Load Balancer 추가 |
App Service 기준 가상 머신 기준 |
워크로드의 안정성 요구 사항을 충족하려면 접근 방식이 아키텍처 중복성을 구현해야 합니다. 다음 단계를 수행하세요.
아키텍처의 작동 시간을 예측합니다. 각 워크로드에 대해 복합 SLA를 계산합니다. 워크로드가 실패할 수 있는 서비스(중요 경로)만 포함합니다. 다음 단계를 수행하세요.
워크로드의 중요한 경로를 따라 있는 모든 서비스에서 Microsoft 가동 시간 서비스 수준 계약(SLA)을 수집하십시오.
독립적인 중요 경로가 없는 경우 각 관련 서비스의 작동 시간 비율을 곱하여 단일 지역 복합 SLA를 계산합니다. 독립적인 중요 경로가 있는 경우 계산하기 전에 3단계로 이동합니다.
두 Azure 서비스가 독립적인 중요 경로를 제공하는 경우 해당 서비스에 독립적인 중요 경로 수식을 적용합니다.
다중 지역 애플리케이션의 경우 단일 지역 복합 SLA(N)를 다중 지역 가동 시간 수식에 입력합니다.
계산된 가동 시간을 가동 시간 SLO와 비교합니다. 필요한 경우 서비스 계층 또는 아키텍처 중복성을 조정합니다.
사용 사례 수식 변수 예시 설명 단일 지역 가동 시간 예상 N = S1 × S2 × S3 × ... × Un N: 단일 지역 중요 경로에 있는 Azure 서비스의 복합 SLA입니다.
S: 각 Azure 서비스의 SLA 작동 시간 비율입니다.
n: 중요 경로의 총 Azure 서비스 수입니다.N = 99.99%(앱) × 99.95%(데이터베이스) × 99.9%(캐시) 단일 중요 경로에서 앱(99.99%), 데이터베이스(99.95%) 및 캐시(99.9%)를 사용하는 간단한 워크로드입니다. 독립적인 중요 경로 예측 S1 x 1 - [(1 - S2) ×(1 - S3)] S: 독립적인 중요 경로를 제공하는 Azure 서비스의 SLA 작동 시간 비율입니다. 99.99%(앱) × (1 - [(1 - 99.95% 데이터베이스) ×(1 - 99.9% 캐시)]) 두 개의 독립적인 중요 경로입니다. 데이터베이스(99.95%) 또는 캐시(99.9%)는 가동 중지 시간 없이 실패할 수 있습니다. 다중 지역 가동 시간 예상 M = 1 - (1 - N)^R M: 다중 지역 가동 시간 예상.
N: 단일 지역 복합 SLA입니다.
R: 사용된 지역 수입니다.N = 99.95% 및 R = 2이면 M = 1 - (1 - 99.95%)^2 두 지역에 배포된 워크로드입니다. 서비스 계층을 조정합니다. 아키텍처를 수정하기 전에 다양한 Azure SKU(서비스 계층)가 안정성 요구 사항을 충족할 수 있는지 여부를 평가합니다. 일부 Azure 서비스 계층에는 Azure Managed Disks와 같은 다른 작동 시간 SLA가 있을 수 있습니다.
아키텍처 중복성을 추가합니다. 현재 가동 시간 추정치가 SLO에 미치지 못하는 경우 중복성을 높입니다.
여러 가용성 영역을 사용합니다. 여러 가용성 영역을 사용하도록 워크로드를 구성합니다. 가용성 영역이 가동 시간을 개선하는 방법은 예측하기 어려울 수 있습니다. 선택한 수의 서비스에만 가용성 영역을 고려하는 가동 시간 SLA가 있습니다. SLA가 가용성 영역을 고려하는 경우, 가동 시간 예측에 사용하십시오. 예시에 대한 다음 테이블을 참조하십시오.
Azure 서비스 유형 가용성 영역 SLA를 사용하는 Azure 서비스 컴퓨트 플랫폼 App Service,
Azure Kubernetes Service,
가상 머신데이터 저장소 Azure Service Bus,
Azure Storage 계정,
Azure Cache for Redis,
Azure Files 프리미엄 계층데이터베이스 Azure Cosmos DB,
Azure SQL Database,
Azure Database for MySQL(마이SQL용 Azure 데이터베이스)
Azure PostgreSQL 데이터베이스
Apache Cassandra를 위한 Azure 관리형 인스턴스부하 분산기 애플리케이션 게이트웨이 안전 Azure Firewall 여러 지역을 사용합니다. 가동 시간 SLO를 충족하기 위해 여러 지역이 필요한 경우가 많습니다. 트래픽 분산에 전역 부하 분산 장치(Azure Front Door 또는 Traffic Manager)를 사용합니다. 다중 지역 아키텍처에는 신중한 데이터 일관성 관리가 필요합니다.
아키텍처 중복성을 관리합니다. 중복성 사용 방법 결정: 아키텍처 중복성을 일별 작업(활성)의 일부로 사용할 수 있습니다. 또는 재해 복구 시나리오(수동)에서 아키텍처 중복성을 사용할 수 있습니다. 예제는 표 3을 참조하세요.
가용성 영역 간 부하 분산을 . 모든 가용성을 적극적으로 사용합니다. 많은 Azure PaaS 서비스는 가용성 영역 간에 부하 분산을 자동으로 관리합니다. IaaS 워크로드는 내부 부하 분산 장치 사용하여 가용성 영역 간에 부하를 분산해야 합니다.
지역 간 부하 분산을 . 다중 지역 워크로드가 안정성 요구 사항에 따라 활성-활성 또는 활성-수동을 실행해야 하는지 여부를 결정합니다.
서비스 구성을 관리합니다. Azure 리소스의 중복 인스턴스에 구성을 일관되게 적용하므로 리소스가 동일한 방식으로 작동합니다. 인프라를 코드 사용하여 일관성을 유지합니다. 자세한 내용은 중복 리소스 구성 참조하세요.
디자인 워크로드 안정성. 워크로드 안정성 디자인은 Well-Architected Framework를 참조하세요.
워크로드 안정성 안내 안정성 핵심 요소 고가용성 다중 지역 디자인
중복성을 고려한 설계
가용성 영역 및 지역 사용서비스 가이드 Azure 서비스 가이드(안정성 섹션시작)
자세한 내용은 중복성참조하세요.
비즈니스 연속성 관리
오류로부터 복구하려면 서비스를 신속하게 복원하고 사용자 만족도를 유지하기 위한 중단을 최소화하기 위한 명확한 전략이 필요합니다. 다음 단계를 수행하세요.
오류에 대비합니다. 높음, 중간 및 낮은 우선 순위에 따라 워크로드에 대해 별도의 복구 절차를 만듭니다. 데이터 안정성, 코드 및 런타임 안정성및 클라우드 리소스 안정성 오류 준비의 기초입니다. 비즈니스 연속성 준비에 도움이 되도록 다른 복구 도구를 선택합니다. 예를 들어 온-프레미스 및 가상 머신 기반 서버 워크로드에 Azure Site Recovery 사용합니다.
테스트 및 문서 복구 계획입니다. 정기적으로 장애 조치(failover) 및 장애 복구 프로세스를 테스트하여 워크로드가 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)를 충족하는지 확인합니다. 인시던트 중에 쉽게 참조할 수 있는 복구 계획의 각 단계를 명확하게 문서화합니다. Azure Site Recovery와 같은 복구 도구가 지정된 RTO를 일관되게 충족하는지 확인합니다.
오류를 감지합니다. 잘못된 경고가 증가하더라도, 중단을 신속하게 식별하기 위해 사전 예방적인 접근 방식을 채택합니다. 가동 중지 시간을 최소화하고 사용자 신뢰를 유지하여 고객 환경의 우선 순위를 지정합니다.
오류를 모니터링합니다. 워크로드를 모니터링하여 1분 이내에 중단을 감지합니다. Azure Service Health 과 Azure Resources Health 을 사용하고, Azure Monitor 경고 를 활용하여 관련 팀에 알리도록 합니다. 이러한 경고를 Azure DevOps 또는 ITSM(IT 서비스 관리) 도구와 통합합니다.
SLA(서비스 수준 표시기)를 수집합니다. SLA 역할을 하는 메트릭을 정의하고 수집하여 성능을 추적합니다. 팀이 이러한 메트릭을 사용하여 SLO(서비스 수준 목표)에 대해 워크로드 성능을 측정하도록 합니다.
오류에 응답합니다. 워크로드 우선 순위에 복구 응답을 정렬합니다. 중복 인프라 및 데이터 복제본에 대한 요청을 즉시 다시 라우팅하는 장애 조치 절차를 구현합니다. 시스템이 안정화되면 근본 원인을 해결하고 데이터를 동기화하고 장애 복구 절차를 실행합니다. 자세한 내용은 장애 조치(failover) 및 장애 복구(failback)를 참조하세요.
오류를 분석합니다. 문제의 근본 원인을 식별한 다음 문제를 해결합니다. 교훈을 문서화하고 필요한 변경 사항을 합니다.
워크로드 오류를 관리합니다. 워크로드 재해 복구의 경우 Well-Architected Framework의 재해 복구 가이드 및 Azure 서비스 가이드 참조하세요(안정성 섹션시작).
Azure 안정성 도구
| 사용 사례 | 해결 방법 |
|---|---|
| 데이터 복제, 백업 및 비즈니스 연속성 |
Azure 서비스 가이드(안정성 섹션시작) 빠른 참조: Azure Cosmos DB Azure SQL 데이터베이스 Azure Blob Storage Azure 파일 |
| 데이터 백업 | Azure Backup |
| 비즈니스 연속성(IaaS) | Azure Site Recovery |
| 다중 지역 부하 분산 장치 |
Azure Front Door (HTTP) Azure Traffic Manager (비 HTTP) |
| 다중 가용성 영역 부하 분산 장치 |
Azure Application Gateway (HTTP) Azure 로드 밸런서 (비 HTTP) |
보안 관리
반복적인 보안 프로세스를 사용하여 클라우드 환경에서 위협을 식별하고 완화합니다. 다음 단계를 수행하세요.
보안 작업 관리
보안 컨트롤을 관리하여 클라우드 자산에 대한 위협을 감지합니다. 다음 단계를 수행하세요.
보안 도구 표준화 표준화된 도구를 사용하여 위협을 감지하고, 취약성을 수정하고, 문제를 조사하고, 데이터를 보호하고, 리소스를 강화하고, 대규모 규정 준수를 적용합니다. Azure 보안 도구 참조하세요.
환경 기준 . 클라우드 자산의 정상 상태를 문서화합니다. 보안 모니터링하고 네트워크 트래픽 패턴 및 사용자 동작을 문서화합니다. Azure 보안 기준 및 Azure 서비스 가이드 사용하여 서비스에 대한 기준 구성을 개발합니다. 이 기준을 사용하면 변칙 및 잠재적인 보안 약점을 보다 쉽게 검색할 수 있습니다.
보안 컨트롤 적용 액세스 제어, 암호화 및 다단계 인증과 같은 보안 조치를 구현하여 환경을 강화하고 손상 가능성을 줄입니다. 보안관리에 대해 더 알고 싶으시면 참조하세요.
보안 책임을 할당합니다. 클라우드 환경에서 보안 모니터링에 대한 책임을 지정합니다. 기준선에 대한 정기적인 모니터링 및 비교를 통해 무단 액세스 또는 비정상적인 데이터 전송과 같은 인시던트 빠른 식별이 가능합니다. 정기적인 업데이트 및 감사는 진화하는 위협에 대해 보안 기준을 효과적으로 유지합니다.
자세한 내용은 CAF Secure참조하세요.
보안 인시던트 관리
랜섬웨어, 서비스 거부 또는 위협 행위자 침입과 같은 보안 인시던트를 복구하는 프로세스 및 도구를 채택합니다. 다음 단계를 수행하세요.
인시던트에 대비합니다. 조사, 완화 및 통신을 위한 역할을 명확하게 정의하는 인시던트 대응 계획을 개발합니다. 계획의 효과를 정기적으로 테스트합니다. 취약성 관리 도구, 위협 탐지 시스템 및 인프라 모니터링 솔루션을 평가하고 구현합니다. 인프라 강화를 통해 공격 노출 영역을 줄이고 워크로드별 복구 전략을 만듭니다. 인시던트 응답 개요 및 인시던트 대응 플레이북참조하세요.
인시던트 검색 microsoft Sentinel 같은 SIEM(보안 정보 및 이벤트 관리) 도구를 사용하여 보안 데이터를 중앙 집중화합니다. MICROSOFT Sentinel의 SOAR(보안 오케스트레이션, 자동화 및 응답 기능) 사용하여 일상적인 보안 작업을 자동화합니다. 위협 인텔리전스 피드 SIEM에 통합하여 클라우드 환경과 관련된 악의적인 전술에 대한 인사이트를 얻습니다. Microsoft Defender for Cloud 사용하여 Azure에서 취약성을 정기적으로 검사합니다. Microsoft Defender Microsoft Sentinel과 통합하여 보안 이벤트에 대한 통합 보기를 제공합니다.
인시던트에 대응합니다. 인시던트를 감지하면 즉시 인시던트 대응 계획을 활성화합니다. 조사 및 완화 절차를 신속하게 시작합니다. 재해 복구 계획을 활성화하여 영향을 받는 시스템을 복원하고 인시던트 세부 정보를 팀에 명확하게 전달합니다.
보안 인시던트 분석 각 인시던트 후에는 위협 인텔리전스를 검토하고 학습된 교훈과 MITRE ATT&CK 기술 자료와 같은 공공 리소스의 인사이트를 기반으로 인시던트 대응 계획을 업데이트합니다. 취약성 관리 및 검색 도구의 효율성을 평가하고 인시던트 후 분석을 기반으로 전략을 구체화합니다.
자세한 내용은 인시던트 대응 관리(CAF 보안)을 참조하세요.
Azure 보안 도구
| 보안 기능 | Microsoft 솔루션 |
|---|---|
| ID 및 액세스 관리 | Microsoft Entra ID |
| 역할 기반 액세스 제어 | Azure 역할 기반 접근 제어 |
| 위협 탐지 | Microsoft Defender for Cloud |
| 보안 정보 관리 | Microsoft Sentinel |
| 데이터 보안 및 거버넌스 | Microsoft Purview |
| 클라우드 리소스 보안 | Azure 보안 기준 |
| 클라우드 거버넌스 | Azure Policy |
| 엔드포인트 보안 | 엔드포인트용 Microsoft Defender |
| 네트워크 보안 | Azure Network Watcher |
| 산업 보안 | Microsoft Defender for IoT |