주 콘텐츠로 건너뛰기

조직을 위한 IBM Quantum Platform 설정 시 고려 사항

여러 프로젝트를 함께 진행하는 구성원이 있는 조직에서는 IBM Quantum Platform 거버넌스가 복잡하게 느껴질 수 있습니다. 그러나 액세스 관리를 활용하면 사용자 협업을 쉽게 활성화하고, 필요한 경우 사용자 및 프로젝트의 가시성을 제한할 수 있습니다. 액세스 관리는 무료가 아닌 IBM Quantum Platform 리소스, 즉 유료 플랜을 사용하는 서비스 인스턴스(조직에 요금이 부과됨)와 관련하여 더욱 중요해집니다.

개요

참고

IBM Cloud®는 이 가이드에서 설명하는 메커니즘을 구현하는 다양한 방법을 제공합니다. 이러한 목표를 달성하는 방법은 여러 가지가 있습니다. 또한, 이 가이드의 대부분의 단계는 IBM Quantum Platform에 특화된 것이 아니라 IBM Cloud에 일반적으로 적용되는 내용이며, 커스텀 역할 세부 사항만 예외입니다.

관련 페르소나

이 가이드에서 언급되는 주요 페르소나는 다음과 같습니다:

  • 사용자: IBM Quantum Platform 리소스(서비스 인스턴스)에 대한 액세스 권한을 부여받고, 해당 리소스에서 다른 사용자와 협업할 수 있는 사람입니다. 사용자의 액세스는 관리자가 제어하며, 서비스 인스턴스를 생성하거나 삭제할 수 없습니다.
  • 클라우드 관리자: IBM Quantum Platform 리소스를 소유하고 어떤 사용자가 해당 리소스에 액세스할 수 있는지를 관리하는 IBM Cloud 계정 소유자입니다. 리소스 소유자로서 관리자는 유료 리소스 사용에 대한 요금을 부담합니다.
  • IDP 관리자: ID 공급자(IDP)에서 ID와 해당 속성을 정의하는 관리자입니다.

용어

이 가이드에서는 다음 용어를 사용합니다:

  • 리소스: 클라우드 사용자 인터페이스, CLI 또는 API를 통해 관리할 수 있는 객체를 의미하는 일반적인 IBM Cloud 용어입니다. 이 가이드에서 _리소스_는 IBM Quantum Platform 서비스 인스턴스를 의미합니다.

  • 서비스 인스턴스: 클라우드 서비스, 구체적으로는 양자 컴퓨터에 액세스하는 데 사용됩니다. 카탈로그를 통해 정의되며, 다양한 양자 컴퓨팅 Backend에 대한 액세스를 제공하는 동일하거나 다른 플랜을 기반으로 여러 서비스 인스턴스를 정의할 수 있습니다. 자세한 내용은 사용 가능한 IBM Cloud 플랜을 참조하세요.

  • 프로젝트: 사용자가 동일한 리소스에서 작업할 수 있도록 하는 그룹화 단위입니다. 이 가이드에서는 mlfinance라는 두 가지 프로젝트를 사용합니다. 자세한 내용은 계층적 프로젝트 구조를 참조하세요.

    참고

    이 프로젝트는 기존 IBM Quantum® Platform의 "프로젝트" 개념과 관련이 없습니다.

설정 계획

조직을 위한 IBM Quantum Platform을 설정하기 전에 다음 사항을 결정해야 합니다:

  • 사용자 ID는 어떻게 정의됩니까? IBM Cloud 사용자, 다른 IDP의 사용자, 또는 둘 다를 설정할 수 있습니다.

    • 다른 IDP를 사용하는 경우, 클라우드 관리자와 IDP 관리자 중 누가 프로젝트 리소스에 사용자를 할당합니까?
    • IDP 관리자가 사용자를 프로젝트에 할당하는 경우, 프로젝트 비교를 위한 키로 사용할 문자열(이 가이드에서는 project를 사용)이 필요합니다.
  • 프로젝트는 무엇이며, 각 프로젝트에 속할 서비스 인스턴스는 무엇입니까? 프로젝트 이름을 신중하게 계획해야 합니다.

    • 프로젝트 이름이 다른 이름의 부분 문자열이 되지 않도록 하세요. 예를 들어, mlchemlab을 프로젝트 이름으로 사용하면 나중에 ml에 대한 프로젝트 매칭을 설정할 때 두 값 모두에서 트리거되어, 의도한 것보다 더 많은 액세스 권한이 부여될 수 있습니다. 대신 mlchem-lab과 같은 고유한 이름을 사용하세요. 또는 의도하지 않은 부분 문자열 매칭을 피하기 위해 접두사 또는 접미사 값을 사용하세요.
    • 명명 규칙과 접두사 또는 접미사 값을 함께 사용하면 여러 프로젝트에 대한 액세스를 쉽게 허용할 수 있습니다.
    • 양자 실험(작업)은 서비스 인스턴스에 속하며, 인스턴스에 액세스할 수 있는 사용자는 해당 인스턴스의 작업을 볼 수 있습니다.
    • 서비스 인스턴스는 다양한 플랜을 기반으로 할 수 있으며, 서로 다른 Backend에 대한 액세스를 허용합니다.
  • 어떤 사용자가 어떤 프로젝트에 액세스해야 합니까?

  • 사용자가 작업을 삭제할 수 있어야 합니까? 서비스 인스턴스에 작업을 유지하면 청구 비용에 대한 추적성이 높아집니다.

  • IBM Quantum Platform 서비스 인스턴스를 직접 참조하는 액세스 그룹을 사용할 것입니까, 아니면 서비스를 리소스 그룹으로 구성할 것입니까?

    • 액세스 그룹은 IBM Cloud 리소스에 대한 사용자 액세스를 제어하는 편리하고 일반적인 방법입니다. 사용자 액세스를 일관되게 할당하는 간단하지만 강력한 수단입니다. 각 프로젝트에 대한 액세스 그룹을 만들고 사용자를 액세스 그룹에 매핑합니다. 각 액세스 그룹은 사용자가 특정 서비스 인스턴스 또는 리소스 그룹에 액세스할 수 있도록 하는 커스텀 역할을 사용합니다.
    • 리소스 그룹은 서비스 인스턴스의 명확한 분리가 필요한 경우에만 사용됩니다. 리소스 그룹에 더 많은 서비스 인스턴스가 생성되면, 해당 리소스 그룹에 액세스할 수 있는 모든 사용자는 액세스 그룹을 업데이트하지 않아도 자동으로 해당 인스턴스를 볼 수 있습니다. 리소스 그룹을 사용하도록 선택한 경우, 액세스 그룹을 생성한 다음 리소스 그룹에 할당합니다.
    참고

    서비스 인스턴스는 하나의 리소스 그룹에만 속할 수 있으며, 인스턴스가 리소스 그룹에 할당된 후에는 변경할 수 없습니다. 즉, 리소스 그룹 할당은 서비스 인스턴스 생성 시에만 가능합니다. 따라서 서비스 인스턴스와 리소스 그룹 간의 할당을 변경해야 할 경우 리소스 그룹은 충분한 유연성을 제공하지 못할 수 있습니다.

고려 사항

환경을 설정할 때 다음 사항을 이해해야 합니다.

보다 세분화된 역할 정의

커스텀 역할의 작업은 보다 세분화된 액세스 제어에 사용할 수 있습니다. 예를 들어, 일부 사용자는 서비스 인스턴스에 대한 전체 액세스가 필요한 반면, 다른 사용자는 서비스 인스턴스, 프로그램 및 작업에 대한 읽기 액세스만 필요할 수 있습니다.

이를 위해 MLreaderMLwriter와 같은 두 가지 커스텀 역할을 정의하세요. MLreader 커스텀 역할에서는 취소, 삭제 및 업데이트 역할을 모두 제거하고, MLwriter 커스텀 역할에는 모든 작업을 포함합니다. 그런 다음 각각 두 개의 서로 다른 액세스 그룹에 역할을 추가합니다.

참고

동적 규칙, 즉 ID 공급자(IDP) 관리자가 커스텀 IDP 사용자 속성을 통해 액세스를 관리하는 경우, 서로 부분 문자열 관계인 IDP 커스텀 사용자 속성을 사용하지 마세요. 예를 들어, ml의 문자열 비교가 mlReader도 허용하므로 mlmlReader를 함께 사용하지 마세요. 이 충돌을 피하려면 MLreaderMLwriter를 사용할 수 있습니다.

커스텀 역할 설정 예시는 프로젝트를 위한 액세스 그룹 생성을 참조하세요.

공유 워크로드 액세스

액세스는 서비스 인스턴스에 적용된다는 점을 유의하는 것이 중요합니다. 따라서 인스턴스에 대한 '쓰기' 액세스 권한을 가진 사용자는 자신의 워크로드를 취소할 수 있지만, 다른 사용자의 워크로드도 보고 취소할 수 있습니다. 이는 IAM의 작동 방식에 따른 것으로 변경할 수 없습니다.

기타 클라우드 리소스

이 가이드의 단계는 다른 클라우드 리소스에 대한 액세스 관리에도 사용할 수 있습니다. 관련 프로젝트의 액세스 그룹에 적절한 권한을 포함하세요.

계층적 프로젝트 구조

이 가이드에서는 사용자와 프로젝트 및 서비스 인스턴스 간의 매핑을 단순하게 유지했습니다. 그러나 여러 사용자를 액세스 그룹에 연결하고 여러 액세스 그룹에서 서비스 인스턴스를 참조함으로써 보다 복잡한 매핑을 구현할 수 있습니다.

이 방법은 계층적 구조를 수용할 수 있습니다. 즉, 기존 IBM Quantum® Platform의 Hub/Group/Project 액세스 구조에 사용자를 할당하는 방식과 일치시킬 수 있습니다. 예를 들어, _그룹_은 그룹의 프로젝트에 속한 모든 서비스 인스턴스에 할당된 액세스 그룹이 될 수 있습니다. 그룹의 모든 프로젝트에 액세스해야 하는 사용자는 그룹의 액세스 그룹에만 추가하면 됩니다.

일관되고 반복 가능한 구성 배포

이 가이드의 단계는 사용자, 프로젝트 및 이들 간의 매핑을 일관되고 반복 가능하게 관리하기 위해 자동화할 수 있습니다. 템플릿은 Terraform IBM Cloud® Provider 문서를 참조하세요.

다음 단계