클라우드 아키텍처란?

클라우드 아키텍처는 구성 요소와 하위 구성 요소를 효율적이며 효과적인 구조로 구성하여 목표를 향한 강점을 최대화하고 약점을 최소화 할 수 있도록 합니다.

클라우드 아키텍처

클라우드 아키텍처는 클라우드에 있는 구성 요소와 하위 구성 요소로 구성됩니다. 이는 매우 일반적인 설명이지만, 클라우드 아키텍처에는 단순한 기술이 아닙니다. National Institute of Standards and Technology Special Publication 500-929(NIST SP 500-292)는 관련 엔티티(클라우드 소비자, 공급자, 감사자 등)에 중점을 둡니다. 그들 없이는 기술을 얻을 수 없습니다.

클라우드 아키텍처는 역할, 활동, 구성 요소 및 하위 구성 요소의 4단계 분류로 나눌 수 있습니다. 클라우드 아키텍처에 대해 논의할 때는 누가 무엇을, 어떻게, 어떤 툴을 사용하는지 명시해야 합니다.

잘 설계된 프레임워크

잘 설계된 프레임워크

잘 설계된 프레임워크에는 많은 작업이 필요합니다. 이 프로세스를 진행할 때 고려해야 할 사항이 많습니다. 처음에는 다음과 같은 많은 질문에 답해야 합니다.

  • 귀사의 내부 및 외부 고객의 비즈니스 우선 순위는 무엇입니까? 
  • 클라우드 및 핵심 비즈니스 구조에 영향을 미칠 위협 환경을 어떻게 결정합니까?
  • 데이터, 특히 민감한 데이터는 어디에 있으며 어디로 이동합니까?
  • 클라우드에 시스템을 올바르게 배포하려면 어떻게 해야 합니까?
  • 소프트웨어 개발자, IT 직원 및 직원이 클라우드로 이전하는 데 필요한 추가 교육은 무엇입니까?
  • 모든 시스템이 올바르게 구성되었는지 확인하기 위해 어떤 메커니즘을 사용하시겠습니까?
  • 보안 수준을 유지하기 위해 모든 클라우드 시스템에 대한 업데이트 및 패치를 관리하는 툴은 무엇입니까?
     

목록은 계속 작성되므로, 아키텍처를 기술과 함께 올바르게 수행하는 것이 중요합니다. 따라서 클라우드를 구현해도 비즈니스에 제공할 수 있는 이점보다 더 많은 피해를 입히지 않도록 해야 합니다.

역할

액티비티

클라우드 아키텍처 내의 활동은 SaaS, PaaS 및 IaaS의 액세스 및 소비를 정의합니다. 여기에는 오케스트레이션, 감사 및 보안이 포함됩니다.

  • 오케스트레이션 – 클라우드 환경을 사용하여 비즈니스 목표를 달성하기 위한 조정된 관리입니다.
  • 감사 – 클라우드 공급자의 보안, 성능 및 규정 준수에 대한 분석입니다. 이것은 외부 제3자가 수행합니다.
  • 보안은 기밀성에서 무결성 및 가용성에 이르기까지 해결되어야 합니다.
    • 기밀성 – 민감한 데이터를 비밀로 유지합니다. 권한이 있는 사용자만 액세스할 수 있도록 합니다.
    • 무결성 – 데이터 또는 시스템이 변경되지 않았으며 데이터 또는 시스템을 신뢰할 수 있다는 확신을 제공합니다.
    • 가용성 – 필요할 때 데이터 및 시스템에 액세스하고 사용할 수 있도록 합니다.

구성 요소

클라우드 아키텍처의 구성 요소를 선택하여 목표를 충족합니다. 이 목적을 달성하기 위해 수행해야 하는 구체적인 조치, 단계, 작업 및 프로세스는 무엇입니까? 클라우드에서는 퍼블릭 클라우드인지 프라이빗 클라우드인지 또는 이들의 조합인지 결정이 되어야 합니다. 하이브리드 클라우드는 예를 들자면 프라이빗 클라우드와 퍼블릭 클라우드를 연결합니다. 새로운 용어인 멀티클라우드는 연결 없이 공용 및 개인용으로 정의됩니다.

구성 요소를 선택할 때 다뤄야 할 또 다른 주제는 상호 운용성 및 이식성 문제입니다.

  • 상호 운용성은 서로 다른 두 시스템이 특정 조건에서 통신하고 데이터를 주고 받을 수 있는 기능입니다.
  • 이식성은 데이터를 수동으로 다시 생성하거나 다시 입력하지 않고도 한 클라우드에서 다른 클라우드로 데이터를 이동할 수 있는 기능입니다.
     

클라우드 설계 및 설계 시작부터 비즈니스 목표 측면에서 이 두 가지 문제를 신중하게 고려하는 것이 중요합니다. 초기에 이러한 것들을 바로잡지 않는다면 기업이 부적절한 아키텍처에 갇혀 있다는 것을 추후에 알게 될 수도 있습니다.

하위 구성 요소

하위 구성 요소를 통해 기업은 SLA(서비스수준협약서) 관리, 신속한 프로비저닝 및 리소스 변경과 같은 문제를 해결할 수 있습니다. 

  • SLA 관리 – 기업이 자체적으로 메트릭을 모니터링하고 약속된 서비스 수준을 충족하는지 확인합니까? 서비스 브로커 모니터링과 같은 제 3자가 필요합니까? 서비스 브로커는 원래 계약 협상을 돕고 서비스의 지속적인 관리를 제공하고 메트릭 및 다른 서비스를 모니터링합니다.
  • 신속한 프로비저닝 – 클라우드는 기존의 변경 관리 방법에 적합하지 않은 다른 환경입니다. 클라우드 인프라 변경 관리를 지원하는 자동화 툴을 구현하는 것이 타당할까요?
  • 리소스 변경 – 구성을 업데이트하고 수리를 위해 일부 장치를 따로 설정해야 합니다.

클라우드 보안 아키텍처

클라우드의 보안은 기본 아키텍처에 보안 요소를 추가하는 것에서 시작됩니다. 클라우드 보안에는 항상 클라우드 공급자와 클라우드 사용자 간의 공동 책임이 수반됩니다. 책임 분담은 사용 중인 클라우드 구조의 유형에 따라 다릅니다. IaaS, PaaS, 또는 SaaS. ISO(International Organization for Standardization), NIST 및 CSA(Cloud Security Alliance)가 생각하는 책임 분담이 있습니다. 그러나 결국 클라우드 제공자와 고객이 이를 결정하고 계약서에 서명하게 됩니다.

클라우드 고객은 위험 평가를 수행하여 어떤 형태의 클라우드든 사용할 경우 어떤 결과가 발생하는지 사전에 파악해 두는 것이 중요합니다. 자체 데이터 센터에서 클라우드를 구축하지 않는 이상, 계약서에는 클라우드 제공자가 할 수 있는 일에 대해 누가 책임을 져야 하는지 또는 최소한 무엇을 해야 하는지 명시되어 있어야 합니다.

보안 모범 사례

다음은 클라우드 솔루션을 설계하거나 사용할 때 고려해야 할 몇 가지 보안 제어입니다.

  • 멀티팩터 인증(MFA) – 모든 계정에서 MFA를 사용하는 것이 좋습니다.
  • 데이터 분류 – 오늘날 클라우드에 있는 데이터와 그 데이터가 얼마나 민감한지를 이해하는 것이 중요합니다. 데이터 저장소 내에서 개인정보와 같은 것을 찾는데 도움이 되는 툴이 있습니다. 도구 또는 복잡한 수동 프로세스를 사용, 어느 쪽이든 반드시 수행해야 합니다.
  • 식별 및 인증 – 클라우드를 사용하거나 클라우드 내에서 모든 행위자의 액세스를 제어하는 것이 중요합니다. 이것은 사용자와 관리자뿐만 아니라 소프트웨어, API, 다른 소프트웨어 또는 데이터에 액세스하는 기능입니다.
  • 관리자를 위한 별도의 통제된 계정 생성 – 비즈니스의 기본 계정은 관리자가 사용하는 계정이 아니어야 합니다. 해당 계정이 도용되면 모든 것이 손실될 수 있습니다.
  • 로그 – 가능한 모든 것을 기록하고 메트릭을 설정하여 의심스럽거나 위험한 상황을 관리자에게 알립니다.

관련 기사

관련 연구