Share via


방어 클라우드 채택 계획

플랜 방법론은 클라우드 채택의 명령 도메인에 속합니다.

do기본 추적기를 보여 주는 그림입니다. 명령, 플랫폼 및 임무를 보여줍니다. 명령은 클라우드 채택의 기본 명령에 있음을 표시하기 위해 강조 표시됩니다.그림 1: 추적기 기본 - 명령 수행기본

플랜 방법론은 임무 소유자가 클라우드 채택을 준비하는 곳입니다. 요구 사항을 정의하고, 임무 목표를 충족하는 데 도움이 되는 결정을 내리고, 올바른 이해 관계자를 참여시켜야 합니다. 이러한 계획은 담당자 및 플랫폼 관리 요구 사항을 결정합니다. 적절한 계획은 프로젝트가 관련자의 동의를 얻도록 하는 데 도움이 됩니다.

클라우드 브로커를 사용하는 것이 좋으며, 계획은 임무 소유자가 클라우드 브로커 서비스 사용에 대한 접근 방식을 선택하는 곳입니다. 임무 소유자가 목표를 충족하기 위해 기술 요구 사항을 정의했다고 가정합니다. 정의하지 않은 경우 이것은 클라우드 브로커 전략을 결정하기 전에 적용해야 하는 필수 조건입니다. 관계가 제공하는 많은 이점 때문에 방어 조직에서는 클라우드 브로커를 사용하는 것이 좋습니다. 일부 방어 조직은 명령 체인에서 특정 클라우드 브로커를 사용하도록 요구합니다. 클라우드 브로커의 중요성과 이점을 고려하면 클라우드 브로커의 이점과 접근 방식을 살펴볼 가치가 있습니다.

클라우드 브로커의 이점

클라우드 브로커는 클라우드 플랫폼을 빌드하고 관리하는 중앙 집중식 그룹입니다. 클라우드 브로커는 클라우드 환경을 관리하고 임무 소유자를 위해 클라우드 채택을 더 간단하게 만드는 데 필요한 많은 작업을 수행합니다. 방어 조직에는 때때로 클라우드 브로커 요구 사항이 있으며, 임무 소유자는 이러한 요구 사항을 플랜에 고려해야 합니다. 임무 소유자가 여러 클라우드 브로커 중에서 선택할 수 있는 경우 이 프로젝트에 가장 적합한 서비스와 가격을 제공하는 클라우드 브로커를 결정해야 합니다.

클라우드 브로커는 다음 이점을 제공했습니다.

관리되는 플랫폼 랜딩 존 - 방어 환경에서 호스트되는 서비스, 솔루션 및 애플리케이션에는 관리되는 환경이 필요합니다. 클라우드 브로커는 규정 준수 요구 사항을 충족하는 관리되는 플랫폼 환경(플랫폼 랜딩 존)을 빌드하고 기본.

Azure 랜딩 존은 안전하고 안정적이며 비용 효율적인 클라우드 작업에 필요한 모든 구성 요소 방어 애플리케이션을 포함하는 대상 아키텍처를 제공합니다(그림 2 참조). Azure 랜딩 존은 8개의 디자인 영역에서 주요 원칙을 따릅니다. Azure 랜딩 존 환경은 플랫폼 랜딩 존 및 애플리케이션 랜딩 존으로 구성됩니다.

  • 플랫폼 랜딩 존: 플랫폼 랜딩 존은 여러 애플리케이션에서 사용하는 핵심 서비스를 제공하는 구독입니다. 샘플 아키텍처(그림 2 참조)에서 빨간색으로 설명된 구성 요소 및 구독은 플랫폼 랜딩 존입니다. ID, 관리 및 연결과 같은 공유 서비스를 이 환경의 애플리케이션에 제공합니다.

  • 애플리케이션 랜딩 존: 애플리케이션 랜딩 존은 애플리케이션 호스팅을 위한 구독입니다. 샘플 아키텍처(그림 2 참조)에서 파란색 상자는 애플리케이션 랜딩 존을 간략하게 설명합니다. 아키텍처에는 "애플리케이션 랜딩 존 A1 구독" 및 "애플리케이션 랜딩 존 A2 구독"의 두 애플리케이션 랜딩 존이 있습니다. 아키텍처는 "애플리케이션 랜딩 존 A2 구독"만 자세히 표시합니다.

Azure 랜딩 존 아키텍처의 다이어그램. 플랫폼 랜딩 존 및 애플리케이션 랜딩 존을 보여 주는 샘플 아키텍처입니다. 아래에 관리 그룹이 있는 Microsoft Entra 테넌트가 표시됩니다. 관리 그룹은 플랫폼, 랜딩 존, 서비스 해제 및 샌드박스로 나눕니다. 이러한 관리 그룹 및 아래에 구독이 있는 자식 관리 그룹. 아키텍처는 이러한 구독의 콘텐츠를 보여 줍니다. 플랫폼 랜딩 존 관리 그룹에는 ID, 관리 및 연결 구독이 포함됩니다. 플랫폼 랜딩 존 구독 주변에는 블랙박스가 있습니다. 애플리케이션 랜딩 존 관리 그룹에는 두 개의 애플리케이션 랜딩 존 구독이 포함되어 있습니다. 한 구독의 내용이 자세히 표시됩니다. 애플리케이션 랜딩 존 구독 주위에 빨간색 상자가 있습니다.그림 2: 개념적 Azure 랜딩 존 아키텍처

클라우드 브로커가 없으면 미션 소유자는 애플리케이션 랜딩 존 및 플랫폼 랜딩 존을 담당합니다. 그러나 클라우드 브로커를 사용하면 임무 소유자는 애플리케이션 랜딩 존만 관리하면 되며, 임무 목표를 충족하도록 애플리케이션을 현대화하는 데 집중할 수 있습니다. 클라우드 브로커는 플랫폼 랜딩 존의 핵심 서비스에 대한 기술적 책임을 져야 합니다.

플랫폼 랜딩 존은 다음 분야를 포함하는 디자인 결정을 제공합니다.

  • Cost Management
  • 보안 기준 관리
  • ID 기준 관리
  • 리소스 일관성
  • 배포 가속화

자세한 내용은 플랫폼 및 애플리케이션 랜딩 존을 참조하세요.

핵심 서비스 - 클라우드 브로커는 ID, 네트워킹, 관리 등의 핵심 서비스를 구현하고 관리합니다. 대부분의 경우, 클라우드 브로커는 새 클라우드 환경을 온-프레미스 네트워크에 안전하게 연결하고, 운영 환경을 빌드하고, 임무 요구 사항에 따른 정책 적용을 통해 IAM(ID 및 액세스 관리) 솔루션을 설정합니다.

플랫폼 ATO(Authorization To Operate) - 숙련된 클라우드 브로커는 임무 소유자보다 플랫폼 수준 ATO를 더 빠르게 달성하는 데 도움이 될 수 있습니다. 플랫폼 수준 ATO는 임무 소유자가 중요한 애플리케이션을 배포할 수 있는 속도에 직접적인 영향을 줍니다. 자세한 내용은 ATO 가속화를 참조하세요.

효율성 향상 - 클라우드 브로커는 정보 흐름을 자동화하므로 데이터를 수동으로 생성하고 플랫폼 규정 준수 요구 사항을 관리할 필요가 없습니다. 이 자동화를 사용하면 애플리케이션 배포를 위해 승인 기관으로 시기 적절하게 정확하게 라우팅할 수 있으므로 추적 가능성과 책임을 제공합니다. 클라우드 브로커가 없으면 임무 소유자는 다음 장애물을 살펴 보아야 합니다.

  • 자금 확보 및 할당
  • 감독 및 규정 준수 요구 사항 관리
  • 보안 팀의 승인 획득
  • 애플리케이션 빌드를 위해 기술 팀에 프로젝트 전달

이러한 활동은 몇 주 또는 몇 달, 경우에 따라 몇 년 동안 지속될 수 있습니다. 클라우드 브로커는 임무 소유자를 위한 프로세스를 간소화하고 신속하게 처리합니다.

클라우드 브로커 접근 방식

클라우드 브로커를 사용할 때 임무 소유자가 고려해야 할 다양한 접근 방식이 있습니다. 임무 소유자는 단일 클라우드 브로커 또는 여러 클라우드 브로커를 사용할 수 있으며 올바른 접근 방식은 임무 요구 사항에 따라 달라집니다.

단일 클라우드 브로커 접근 방식 - 단일 클라우드 브로커 접근 방식에서 임무 소유자는 단일 엔터티와 클라우드 서비스를 계약합니다. 다양한 지원 모델이 있을 수 있지만 클라우드 브로커는 단일 연락 지점입니다. 단일 클라우드 브로커는 테넌트라고 하는 단일 클라우드 ID 솔루션을 제공합니다. 단일 테넌트에는 몇 가지 뚜렷한 이점이 있습니다. 단일 테넌트는 다음과 같은 이점을 제공합니다.

  • 모든 클라우드 환경에서 가시성과 투명성을 개선하여 ID 및 액세스 관리 복잡성을 줄입니다.
  • 규정 준수 정보 공유를 용이하게 하면서 보안을 개선합니다.
  • 제로 트러스트 아키텍처 빌드를 간소화합니다.
  • 엄격한 조건에서 관련자 간의 데이터 전송 효율성을 높입니다.

이러한 혜택이 임무 소유자의 요구를 충족하는 경우 단일 브로커가 더 나은 접근 방식일 수 있습니다.

여러 클라우드 브로커 접근 방식 - 다중 클라우드 브로커 접근 방식은 둘 이상의 클라우드 브로커를 사용하여 관리형 클라우드 서비스를 제공합니다. 여러 클라우드 브로커는 복잡한 조직에 더 적합하고, 방어 환경에는 종종 여러 클라우드 브로커 전략이 필요할 만큼 충분한 복잡성이 있습니다. 하지만 주의해야 할 점이 있습니다. 여러 클라우드 브로커는 클라우드 채택 플랜에 더 많은 위험을 추가하고 조직이 관리해야 하는 더 많은 통신 라인을 추가할 수 있습니다.

다음 요소는 여러 클라우드 브로커 접근 방식이 올바른지 확인하는 데 도움이 될 수 있습니다.

  • 소유권: 임무 소유자는 자체 클라우드 브로커가 필요할 수 있습니다. 의사 결정 그룹은 종종 임무 목표를 충족하고 종속성으로 인한 지연을 피하기 위해 자체 테넌트가 필요합니다.

  • 격리: 임무 소유자는 규정 준수, 거버넌스 또는 ID 등의 이유로 격리된 환경이 필요할 수 있습니다. 각 테넌트(Microsoft Entra ID 인스턴스)는 격리된 ID 환경을 나타내며 필요한 경우 확고한 격리 장벽을 만들 수 있습니다.

  • 관리: 복잡한 환경을 분리하는 것은 클라우드 애플리케이션을 관리하고 현대화하는 데 적합할 수 있습니다. 그러나 이 관리 분리로 인해 명령 체인에서 복잡성이 증가합니다. 모든 클라우드 자산을 한 눈에 보기가 더 어려워집니다.

  • 보안: 다양한 영향 수준에 대한 데이터 규정 준수를 사용하려면 권한이 부여되고 해당 영향 수준을 관리하는 경험이 있는 여러 테넌트와 여러 클라우드 브로커가 필요할 수 있습니다.

다중 클라우드 브로커 전략은 방어 조직의 다양한 수준에서 사용할 수 있습니다. 브로커는 개별 군대(해군, 공군, 육군) 또는 애플리케이션 그룹에 할당될 수 있습니다. 선택은 소유권, 격리, 관리 및 보안에 대한 방어 조직의 요구 사항에 따라 달라집니다.

자세한 내용은 계획 개요마이그레이션 평가 검사 목록을 참조하세요.

다음 단계

계획은 방어 조직의 실행을 준비합니다. 구성 방법론은 이 계획을 사용하고 비기술적 필수 구성 요소를 완료하기 시작합니다.