리소스 구성 및 액세스 지정에 대한 우수 사례

IBM Cloud® 계정을 설정한 후에는 계정에서 리소스를 프로비저닝 또는 예약이 가능한 물리적 또는 논리적 인스턴스입니다.리소스의 예로는 스토리지, 프로세서, 메모리, 데이터베이스, 클러스터, 가상 머신 등이 있습니다. 구성하고 ID에 액세스 권한을 할당하는 방법을 계획할 준비가 된 것입니다. 이러한 우수 사례는 IBM Cloud에서 성공적이고 안전하게 앱을 개발할 수 있도록 하는 기본 구성 요소를 제공합니다.

다음 우수 사례는 IBM Cloud Identity and Access Management(IAM)에 대해 사용으로 설정되고 리소스 그룹에 지정된 리소스에 중점을 둡니다. 기존 인프라 서비스는 IAM이 지원되지 않으므로 리소스 그룹에 할당할 수 없습니다.

어떻게 좋은 리소스 그룹 전략을 만들 수 있습니까?

리소스 그룹을 사용하여 계정 리소스를 액세스 제어 및 청구 용도로 구성할 수 있습니다.

프로젝트 환경당 하나의 리소스 그룹이 사용되는 경우에는 관리자가 프로젝트 환경 레벨에서 리소스 사용량을 보다 잘 제어할 수 있습니다. 예를 들어 일반적인 프로젝트에는 개발, 테스트 및 프로덕션 환경이 있습니다. CustApp이라는 프로젝트에는 다음 리소스 그룹이 있습니다.

CustApp-Dev
CustApp-Test
CustApp-Prod

이 시나리오에서는 개발자에게 개발 리소스 그룹에는 광범위한 액세스 권한을 부여하고 프로덕션 리소스 그룹에는 훨씬 더 제한적으로 또는 전혀 액세스 권한을 부여하지 않을 수 있습니다.

리소스 그룹의 리소스 구성

IAM 액세스 제어를 사용하여 관리되는 모든 리소스는 리소스 그룹에 속합니다. 사용자는 카탈로그로부터 리소스를 작성할 때 이를 해당 리소스 그룹에 지정합니다. 리소스 지정을 설정한 후에는 변경할 수 없으므로 먼저 리소스 그룹을 작성하는 것이 중요합니다. 실수로 잘못된 리소스 그룹에 리소스를 지정한 경우에는 해당 리소스를 삭제하고 새로 작성하십시오.

계정에 대한 기본 리소스 그룹이 작성됩니다. Lite 계정이 있는 경우에는 하나의 리소스 그룹을 사용하도록 제한됩니다. 여러 리소스 그룹을 작성하려면 종료과금제 또는 구독 계정으로 업그레이드하십시오.

리소스 검색

사용자 태그를 사용하여 계정의 리소스에 대해 손쉽게 구성 및 검색할 수 있습니다. 또한 사용자 태그를 사용하여 CSV 파일로 사용 내역 내보내기를 볼 때 특정 팀 사용량이나 비용 할당을 식별하는 데 도움을 줄 수 있습니다.

자세한 정보는 태그에 대한 작업을 참조하십시오.

IAM 액세스 작동 방법

계정에서 리소스 그룹을 설정하고 구성한 후에는 액세스 관리 프로세스를 간소화하기 위해 몇 가지 전략을 활용할 수 있습니다.

액세스 그룹: 개별 사용자, 서비스 ID 또는 신뢰할 수 있는 프로파일마다 동일한 액세스 권한을 여러 번 지정하지 않고, 액세스 그룹의 모든 ID에 대해 동일한 액세스 권한을 부여하여 지정된 정책의 수를 최소한으로 관리할 수 있습니다. 사용자를 액세스 그룹에 추가하려면 먼저 사용자를 계정에 초대해야 합니다. 사용자가 액세스 그룹의 구성원인 신뢰할 수 있는 프로파일에 대한 자격이 있으면 사용자의 계정에 초대할 필요가 없습니다.
신뢰할 수 있는 프로파일: 조직에 엔터프라이즈 디렉토리가 있는 경우 신뢰 프로파일을 사용하면 액세스를 관리하는 데 드는 시간과 노력을 줄일 수 있습니다. 또한 엔터프라이즈에 있는 연합 사용자의 IBM Cloud 계정에 대한 로그인 프로세스를 단순화합니다. 신뢰 프로파일을 작성하여 연합 사용자 또는 컴퓨팅 리소스에 계정에 대한 액세스 권한을 자동으로 부여할 수 있습니다. 연합 사용자의 경우 SAML 속성을 기반으로 조건을 추가하여 어떤 연합 사용자가 프로파일을 적용할 수 있는지 정의하십시오. 컴퓨팅 리소스의 경우 특정 리소스를 지정하거나 리소스 속성을 기반으로 조건을 추가하여 프로파일을 적용할 수 있는 컴퓨팅 리소스를 정의하십시오. 두 엔티티 유형 모두, 부여되는 액세스 레벨은 신뢰할 수 있는 각 프로파일 내에 지정된 액세스 정책 또는 신뢰할 수 있는 프로파일이 멤버인 액세스 그룹에 따라 결정됩니다. 그러나 신뢰 프로파일은 연합 사용자를 계정에 초대할 필요가 없으며, 외부 ID 제공자(IdP)에 의해 연합 사용자만 신뢰 프로파일을 적용할 수 있습니다.

여러 액세스 그룹의 구성원이면 계정에 액세스할 때 모든 정책이 한 번에 적용됩니다. 연합 사용자인 경우 다른 신뢰 프로파일을 적용하는 옵션이 있을 수 있지만 로그인할 때 적용할 프로파일을 하나만 선택합니다. 예를 들어 개발자 관련 작업을 완료하려면 로그인할 때 Developer 프로필을 선택합니다. 관리자 관련 태스크를 완료하려면 권한이 있는 Admin 프로파일을 선택합니다. 이렇게 하면 실수로 특권 조치를 취하는 위험을 줄일 수 있습니다.

정책은 제목, 대상 및 역할로 구성됩니다. 이 경우의 주제는 액세스 그룹 또는 신뢰 프로파일입니다. 대상은 리소스 그룹 내의 리소스 세트, 서비스 인스턴스, 계정의 모든 서비스 또는 서비스의 모든 인스턴스와 같은 액세스할 주체입니다. 역할은 부여된 액세스 레벨을 정의합니다.

다음 다이어그램은 액세스 정책이 작동하는 방법을 보여줍니다.

액세스 정책이란 무엇인가요?

가장 일반적으로 사용되는 역할은 뷰어, 편집자, 운영자 및 관리자 플랫폼 역할입니다.

뷰어 역할에서는 계정의 리소스 그룹과 인스턴스를 보는 데 필요한 최소한의 액세스 권한을 제공합니다.
운영자 역할에는 인스턴스 보기 및 자격 증명 관리 기능과 같은 작업이 포함됩니다.
편집자 역할에는 운영자 역할의 조치와 동일한 조치가 포함되지만 서비스 인스턴스를 작성, 편집, 삭제 및 바인딩하기 위한 조치도 포함됩니다.
관리자 역할에는 서비스 인스턴스에 대해 작업하고 다른 사용자에게 정책이 적용되는 해당 서비스 또는 인스턴스에 대한 액세스 권한을 지정하기 위한 모든 기능이 포함됩니다.

이러한 역할은 플랫폼에서 액세스 권한을 지정하는 데 가장 많이 사용되는 역할이지만 서비스 역할이라는 고려해야 할 두 번째 역할 세트가 있습니다. 이러한 역할에 맵핑된 조치는 각 서비스에서 정의됩니다. 일반적으로 이러한 역할에 맵핑된 조치는 특히 서비스의 API 및 UI에 대해 작업할 수 있는 기능과 관련되어 있습니다.

지정할 수 있는 역할에 관한 자세한 정보는 IAM 역할을 참조하십시오.

액세스 관리 시간과 노력 감소

계정에서 허용되는 총 정책 수에는 한계가 있습니다. 몇 가지 전략을 사용하여 한계에 도달하지 않도록 하고 계정의 ID(사용자, 서비스 ID 또는 신뢰 프로파일)에 대한 액세스를 관리하는 데 소요되는 시간을 줄일 수 있습니다.

최소 권한의 원칙을 사용하고 필요한 액세스만 지정하십시오. 그러면 계정의 ID가 허용을 원하는 조치로만 제한되도록 보장하는 데 도움이 될 수 있습니다. 예를 들어, 액세스 정책에 대한 시간 기반 조건은 사용자가 지정하는 시간 프레임 동안에만 액세스를 부여하여 보안 위반 시 공격 기회를 줄입니다. 자세한 정보는 시간 기반 조건으로 액세스 제한 을 참조하십시오.
자원 그룹에 자원을 추가하여 필요한 정책의 수를 더 최소화하십시오. 예를 들어, 계정의 특정 리소스를 사용하는 프로젝트에 대해 작업 중인 팀이 있을 수 있습니다. 특정 리소스 그룹에 있는 리소스에만 액세스를 지정하는 정책으로 액세스 그룹 또는 신뢰 프로파일에 팀 멤버를 추가하십시오. 이 방법을 사용하면 각 팀 멤버의 각 리소스에 정책을 지정할 필요가 없습니다.
액세스 그룹을 사용하여 동일한 레벨의 액세스가 필요한 ID의 액세스 관리를 효율화합니다. 정의된 특정 정책으로 액세스 그룹을 설정한 후 해당 ID를 그룹에 추가할 수 있습니다. 그룹 구성원이 나중에 더 많은 액세스 권한이 필요한 경우, 액세스 그룹에 대한 새 정책을 정의하기만 하면 됩니다.
액세스 관리 태그를 사용하여 계정의 리소스 및 서비스 ID에 대한 액세스를 대규모로 제어할 수 있습니다. 특정 태그가 첨부된 리소스 및 서비스 ID에만 액세스 권한을 할당하면 정의한 정책에 대한 여러 번의 업데이트를 피할 수 있습니다. 자세한 정보는 태그를 사용하여 리소스에 대한 액세스 제어를 참조하십시오.
신뢰 프로파일을 사용하여 연합 사용자에게 자동으로 권한을 부여하고 계정에 대한 리소스 액세스를 계산하십시오. 이러한 방식으로, 연합 사용자들은 그들이 적용할 수 있는 프로파일을 결정하기 위해 SAML 기반 속성을 평가함으로써 로그인 시간동안 하나 이상의 신뢰 프로파일에 매핑될 수 있습니다. 컴퓨팅 리소스에 대해 신뢰 프로파일을 사용하면 애플리케이션을 실행하기 위한 신임 정보 저장과 신임 정보의 관리 및 회전을 방지할 수 있습니다. 또한 신뢰할 수 있는 프로파일을 액세스 그룹에 추가하여 이미 작성한 정책 세트를 활용할 수 있습니다.

다중 서비스에 대한 액세스를 지정하기 위해 단일 정책만 필요하도록 서비스 그룹을 사용하여 액세스를 지정하십시오. 이 방법을 사용하면 계정의 정책 수를 줄이고 액세스를 관리하는 시간과 노력을 줄일 수 있습니다.

 * **All Identity and Access enabled services**: All catalog services that use IAM for access management.
 * **All Account Management services**: Platform services, such as billing and usage, license and entitlements, enterprises, and more. For more information, see [Assigning access to account management services](/docs/iam?topic=iam-account-services).
 * **All IAM Account Management services**: A subset of account management services that includes the IAM platform services IAM Identity, IAM Access Management, IAM Users, IAM Groups, and future IAM services.

비활성 ID 및 비활성 정책에 대한 액세스를 제거하면 IBM Cloud 리소스에 대한 무단 액세스의 위험을 줄이고 액세스를 보다 효율적으로 관리할 수 있습니다. 자세한 정보는 비활성 ID 식별 및 액세스 정책 감사 를 참조하십시오.

어떻게 좋은 액세스 그룹 전략을 만들 수 있습니까?

액세스 그룹은 동일한 IAM 액세스 권한을 부여할 수 있는 그룹화의 사용자, 서비스 ID 및 신뢰할 수 있는 프로파일 조직입니다. 단일 액세스 그룹의 모든 ID는 동일한 액세스 권한을 상속합니다.

리소스 그룹 및 포함된 리소스에 대한 액세스 권한을 지정하는 논리적인 방법은 필요한 액세스 레벨마다 하나의 액세스 그룹을 작성하는 것입니다. 그런 다음 각 액세스 그룹을 이전에 작성한 리소스 그룹에 맵핑할 수 있습니다. 예를 들어 CustApp 프로젝트에 대한 액세스를 제어하려면 다음과 같은 액세스 그룹을 작성할 수 있습니다.

감사자-그룹
개발자-그룹
관리자-그룹

감사자-그룹의 경우 CustApp-Test와 CustApp-Prod 리소스 및 리소스 그룹에 대한 뷰어 액세스 권한을 부여하는 두 개의 액세스 정책을 지정하십시오. 개발자-그룹의 경우 CustApp-Dev 및 CustApp-Test 리소스 및 리소스 그룹에 대한 편집자 액세스 권한을 부여하는 두 개의 액세스 정책을 지정하십시오. 관리자-그룹의 경우 세 개의 모든 CustApp 리소스 그룹 및 해당 리소스에 대한 관리자 액세스 권한을 부여하는 세 개의 액세스 정책을 지정하십시오.

액세스 그룹을 작성하고 여기에 두 개의 정책을 지정하여 계정의 모든 항목에 대한 관리자 액세스 권한을 지정할 수 있습니다. 첫 번째 정책을 만들려면 관리자 플랫폼 역할 및 관리자 서비스 역할이 있는 모든 ID 및 액세스 사용 서비스를 선택합니다. 두 번째 정책을 만들려면 관리자 역할이 할당된 모든 계정 관리 서비스를 선택합니다. 관리자 역할이 있는 사용자는 액세스를 변경하고 액세스 그룹을 제거할 수 있으며 관리자 역할이 있는 다른 사용자를 포함하여 액세스 그룹에서 사용자를 추가 및 제거할 수 있습니다.

액세스 그룹에 대한 관리자 역할이 있는 사용자는 액세스 그룹에서 사용자를 추가하거나 제거하여 액세스 권한을 부여하거나 취소할 수 있습니다. 관리자 액세스 권한이 있는 액세스 그룹을 생성하면 계정의 관리자 액세스 권한 부여 및 취소를 액세스 그룹에 추가된 관리자에게 위임하게 됩니다. 계정의 모든 항목에 대한 관리자 액세스에는 관리자 역할을 가진 다른 사용자의 액세스 권한을 취소하는 기능이 포함됩니다.

다음 다이어그램은 자원 그룹에 액세스를 지정하는 방법을 보여줍니다.

IBM Garage for Cloud의 더 많은 모범 사례는 IBM Cloud 에서 리소스 액세스 관리하기를 참조하세요.

샘플 액세스 정책

다음 샘플 액세스 정책을 검토하여 리소스 그룹으로 구성된 리소스에 대한 액세스 그룹에 대한 액세스 권한을 지정하는 방법을 결정하는 데 도움이 됩니다.

액세스 그룹에 전체 계정의 IBM Cloud Kubernetes Service에 대한 플랫폼 관리자 역할을 부여하는 정책입니다. 액세스 그룹의 사용자는 이 서비스의 모든 인스턴스에 액세스하고 최소 뷰어 역할이 지정된 모든 리소스 그룹에서 서비스 인스턴스를 작성할 수 있습니다. 리소스에 지정된 관리자 역할이 있는 액세스 그룹 멤버는 해당 리소스에 대한 액세스 권한을 부여할 수도 있습니다.
액세스 그룹에 리소스 그룹(멤버 리소스 제외)에 대한 플랫폼 뷰어 역할을 부여하는 정책입니다. 액세스 그룹의 사용자는 이 리소스 그룹에 서비스의 인스턴스를 작성하는 데 필요한 리소스 그룹에 대한 가시성을 가집니다.
액세스 그룹에 리소스 그룹의 모든 리소스에 대한 플랫폼 편집자 역할을 부여하는 정책입니다. 액세스 그룹의 사용자는 해당 리소스를 편집하거나 삭제할 수 있습니다.
액세스 그룹에 전체 계정(모든 IAM 사용 서비스)에 대한 플랫폼 관리자 역할을 부여하는 정책입니다. 액세스 그룹의 사용자는 전체 계정의 리소스에 대한 플랫폼 조치 및 관리 조치(예: 계정의 리소스 그룹 관리)를 수행할 수 있습니다.

신뢰 프로파일 전략은 무엇입니까?

신뢰 프로파일은 동일한 IAM 액세스 권한이 부여될 수 있는 연합 사용자 또는 컴퓨팅 리소스의 그룹입니다. 단일 프로파일을 적용하도록 허용된 모든 ID가 동일한 액세스 권한을 상속합니다. 계정의 정책 수를 줄이기 위해, 액세스 요구사항이 동일한 경우 컴퓨팅 리소스 및 연합 사용자를 동일한 신뢰 프로파일에 추가할 수 있습니다.

리소스 그룹과 포함된 리소스에 대한 액세스 권한을 논리적으로 할당하는 방법은 신뢰할 수 있는 프로필을 만드는 것입니다. 자세한 내용은 필요한 액세스 수준별 페더레이션 사용자 및 워크로드를 위한 신뢰할 수 있는 프로필 을 참조하세요. 그런 다음, 각 신뢰 프로파일을 이전에 작성된 리소스 그룹에 맵핑할 수 있습니다. 예를 들어, CustApp 프로젝트에 대한 액세스를 제어하기 위해 다음과 같은 신뢰 프로파일을 작성할 수 있습니다.

감사-프로파일
개발자-프로파일
관리-프로파일

Auditor-Profile의 경우 이 프로파일을 적용할 수 있도록 하려는 연합 사용자의 SAML 속성을 기반으로 하는 조건을 지정하십시오. 이러한 SAML 속성은 회사 사용자 디렉토리에 정의되어 있습니다. 이러한 방식으로 연합 사용자 관리, 액세스 권한 부여 및 액세스 권한 취소는 주로 회사 사용자 디렉토리에서 수행됩니다. 다음으로, CustApp-Test 및 CustApp-Prod 리소스 및 리소스 그룹에 뷰어 액세스 권한을 부여하는 두 액세스 정책을 지정하십시오.

Developer-Profile의 경우 이 프로파일을 적용할 수 있도록 하려는 연합 사용자의 SAML 속성을 기반으로 하는 조건을 지정하십시오. CustApp-Dev 및 CustApp-Test 자원 및 자원 그룹에 편집자 권한을 부여하는 두 개의 액세스 정책을 지정하십시오. Admin-Profile의 경우 이 프로파일을 적용할 수 있도록 하려는 연합 사용자의 SAML 속성을 기반으로 하는 조건을 지정하십시오. 그런 다음 세 개의 모든 CustApp 자원 그룹 및 해당 자원에 대한 관리자 액세스 권한을 부여하는 세 개의 액세스 정책을 지정하십시오.

신뢰할 수 있는 프로파일은 다른 IAM ID와 마찬가지로 정책을 사용하거나, 이를 액세스 그룹에 추가함으로써 액세스 권한을 부여할 수 있습니다. 신뢰할 수 있는 프로파일이 필요로 하는 것과 액세스 권한 레벨이 동일한 액세스 그룹이 있는 경우에는 이 신뢰할 수 있는 프로파일을 해당 액세스 그룹에 추가할 수 있습니다.

다음 다이어그램은 신뢰할 수 있는 프로파일에 액세스를 지정하는 방법을 보여줍니다.

신뢰 프로파일을 처음 작성할 때 신뢰 엔티티 유형을 하나만 선택할 수 있습니다. 먼저 언제든지 콘솔을 사용하여 신뢰할 수 있는 프로필을 업데이트하여 컴퓨팅 리소스와 신뢰 관계를 추가할 수 있습니다.

신뢰 프로파일을 작성하고 두 개의 정책을 지정하여 계정의 모든 항목에 관리자 액세스 권한을 지정할 수 있습니다. 첫 번째 정책을 만들려면 관리자 플랫폼 역할 및 관리자 서비스 역할이 있는 모든 ID 및 액세스 사용 서비스를 선택합니다. 두 번째 정책의 경우 관리자 역할이 할당된 모든 계정 관리 서비스를 선택합니다. 관리자 역할이 있는 사용자는 신뢰할 수 있는 프로필의 액세스 권한을 업데이트 및 제거하고 관리자 역할이 있는 다른 사용자를 포함하여 신뢰할 수 있는 프로필에서 사용자를 추가 및 제거할 수 있습니다.

신뢰할 수 있는 프로필에 대한 관리자 역할이 있는 사용자는 신뢰할 수 있는 프로필에서 규칙을 추가하거나 제거하여 액세스 권한을 부여하거나 취소할 수 있습니다. 관리자 액세스 권한이 있는 신뢰할 수 있는 프로필을 생성하면 해당 계정의 관리자 액세스 권한 부여 및 취소를 신뢰할 수 있는 프로필에 추가된 관리자에게 위임하게 됩니다. 계정의 모든 항목에 대한 관리자 액세스에는 관리자 역할을 가진 다른 사용자의 액세스 권한을 취소하는 기능이 포함됩니다.

샘플 액세스 정책

다음 샘플 액세스 정책을 검토하여 리소스 그룹으로 구성된 리소스에 신뢰 프로파일 액세스를 할당하는 방법을 결정하는 데 참고하십시오.

연합 사용자에게 전체 계정의 IBM Cloud Kubernetes Service에 플랫폼 관리자 역할을 부여하는 정책입니다. 연합 사용자는 연합 사용자의 외부 IdP 속성이 신뢰 관계의 조건을 충족할 때 이 프로파일을 적용할 수 있습니다. 예를 들어, 회사 사용자 디렉토리에 jobrole 값으로 관리자를 식별하는 admin 속성이 있는 경우 해당 속성을 가진 연합 사용자를 다른 조건과 함께 신뢰 프로파일에 동적으로 추가하는 조건을 작성할 수 있습니다. 신뢰 프로파일을 적용할 수 있는 연합 사용자는 이 서비스의 모든 인스턴스에 액세스하고 최소 뷰어 역할이 지정된 모든 리소스 그룹에서 서비스 인스턴스를 작성할 수 있습니다. 리소스에 대한 관리자 역할이 있는 신뢰 프로파일도 해당 리소스에 대한 액세스 권한을 부여할 수 있습니다. 가장 높은 권한이 필요한 연합 사용자만 이 신뢰 프로파일을 적용할 수 있도록 조건을 지정할 수 있습니다. 다른 모든 연합 사용자는 해당 SAML 속성을 기반으로 필터링할 수 있습니다.
리소스 그룹에서 컴퓨팅 리소스 Reader 및 Writer 역할을 부여하는 정책입니다. 컴퓨팅 리소스가 인증되고 신뢰 프로파일에 지정된 조건(예: location 또는 resource type)을 충족시키면 신뢰 프로파일이 자동으로 적용됩니다. 이 방법은 이러한 조건을 충족하는 모든 기존 또는 향후 리소스가 인증 시 자동으로 적용되는 프로파일을 보유할 수 있도록 합니다.
단일 Kubernetes 클러스터와 같이 특정 컴퓨팅 리소스와의 신뢰를 구축할 수도 있습니다. 예를 들어, 애플리케이션이 Kubernetes Service에서 읽고 쓰고 IBM Cloudant 버킷에 읽고 써야 하는 Cloud Object Storage Dedicated IBM Managed에서 실행 중인 애플리케이션이 있을 수 있습니다. IBM Cloudant 및 Cloud Object Storage Dedicated IBM Managed 인스턴스는 동일한 리소스 그룹에 있으며 신뢰 프로파일에는 Reader 또는 Writer 역할이 지정됩니다.

신뢰 프로파일을 사용하는 것은 IAM 사용 리소스에 대한 액세스를 얻기 위해 IBM Cloud 리소스를 계산하는 애플리케이션에 대한 우수 사례입니다.

액세스 그룹 및 신뢰 프로파일 비교

액세스 그룹은 사용자의 일상적인 업무에 대한 액세스 권한을 부여하는 데 가장 적합하며, 신뢰할 수 있는 프로필은 연합된 사용자에게 제한된 시간 내에 전문적이고 특정한 작업을 완료하는 데 필요한 수준의 액세스 권한을 부여하는 데 적합합니다. 이는 일반적으로 일일 작업에서 의도하지 않게 수행하지 않으려는 중요한 태스크입니다. 신뢰 프로파일을 사용하면, 연합 사용자는 IBM Cloud에 온보드할 필요가 없으며 신뢰 관계를 통해 계정의 IBM Cloud 자원에 대한 액세스 권한이 부여됩니다. 연합 사용자가 회사를 떠나면 디렉토리에서 회사 ID를 삭제하면 됩니다. 그러면 IBM Cloud에 대한 액세스도 제거됩니다. 신뢰 프로파일을 사용한 시간 기반 액세스를 사용하면 보안 위험을 줄이기 위해 빈번한 인증 확인이 가능합니다.

다음 표를 사용하여 액세스 그룹과 신뢰 프로파일을 사용하여 유스 케이스에 가장 적합한 결정을 내리는 것의 차이점을 이해하십시오.

액세스 그룹 및 신뢰 프로파일 비교
기능	액세스 그룹	신뢰 프로파일
IAM 액세스 제어	예	예
필요한 IBM Cloud 계정에 사용자 초대	예	아니오
사용자가 계정에 추가되기 전에 액세스를 정의할 수 있습니다.	예, 동적 규칙 사용	예
연합 사용자	예	예
비연합 사용자	예	예
서비스 ID	예	예
컴퓨팅 리소스 ID	아니오	예
사용자 관리가 주로 수행됩니다.	IBM Cloud 계정	회사 사용자 디렉토리

액세스 그룹 및 신뢰 프로파일은 조직의 요구 사항에 따라 사용자 및 액세스 관리를 위해 별도로 또는 함께 사용할 수 있습니다.

예를 들어, CustApp 프로젝트의 경우 다음 정책으로 IAM Admin 신뢰 프로파일을 작성하도록 선택할 수 있습니다.

액세스 그룹 CustApp-Dev/Test/Prod의 Administrator 이러한 방식으로 관리자는 사용자를 액세스 그룹에 추가하거나 액세스 그룹에서 제거하여 액세스 권한을 부여하거나 취소할 수 있습니다.
IAM ID 계정 관리 서비스의 Administrator. 이러한 방식으로 관리자는 서비스 ID, 신뢰 프로파일, 규칙 등을 관리할 수 있습니다.
사용자 관리 계정 관리 서비스의 Editor . 이 방법으로 관리자는 계정에 사용자를 초대하고 사용자를 계정으로 보는 등의 작업을 수행할 수 있습니다.

이 신뢰 프로파일을 사용하면 관리자는 개발 및 테스트 환경에서 일일 조치 및 태스크를 완료하기 위해 광범위한 액세스 정책이 있는 액세스 그룹에 개발자를 추가할 수 있습니다. 프로덕션 환경의 오퍼레이션에 대한 액세스는 Operator-Profile이라는 신뢰 프로파일에서 설정할 수 있습니다. 이러한 방식으로 개발자는 프로덕션에서 Operator-Profile에 대한 오퍼레이션 조치를 수행해야 하는 경우 CustApp에 로그인하고 적용하여 작업 역할을 변경할 수 있습니다.

리소스 구성 및 액세스 권한 지정 우수 사례

다음 유스 케이스를 검토하여 조직에 적합한 플랜을 준비하는 데 도움을 받으십시오. 각 유스 케이스에 대해 액세스 그룹 또는 신뢰 프로파일을 사용하여 최소 수의 액세스 정책을 유지하면서 사용자 그룹에 대한 액세스를 제공하는 것이 좋습니다. 액세스 그룹을 사용하여 액세스 그룹의 계정에 있는 사용자를 단순히 추가하거나 제거하여 필요에 따라 액세스를 지정하거나 취소할 수 있습니다. 신뢰 프로파일을 사용하면 회사 사용자 디렉토리의 연합 사용자가 계정에 초대하거나 각 사용자에게 개별 액세스를 지정하지 않고도 신뢰 프로파일을 적용할 수 있는 조건을 쉽게 업데이트할 수 있습니다.

액세스 그룹을 사용하여 단일 프로젝트에서 함께 작업하는 여러 사용자

계정의 일부 사용자는 계정을 관리하고 다른 사용자에게 액세스 권한을 지정해야 합니다. 일부 사용자는 비용을 초래하는 서비스 인스턴스를 작성해야 합니다. 기타 사용자는 애플리케이션 컴포넌트의 서비스 인스턴스만 사용해야 하는 애플리케이션 개발자입니다.

모든 사용자에게 계정 및 기본 리소스 그룹의 다양한 역할을 부여하려고 합니다. 리소스를 분리하거나 일부 사용자가 일부 리소스에 액세스하지 못하도록 제한하기 위해 추가 리소스 그룹을 작성할 필요는 없습니다. 각 사용자 그룹에 대한 액세스 그룹을 작성하여 사용자에게 요구사항에 적합한 역할을 부여할 수 있습니다.

액세스 그룹을 작성하고 이 그룹에 계정을 관리하고 다른 사용자에게 액세스 권한을 부여해야 하는 사용자를 지정하십시오. 그런 다음 모든 IAM 사용 서비스 및 모든 계정 관리 서비스에 대한 관리자 역할이 있는 정책을 지정하십시오.
액세스 그룹을 작성하고 이 그룹에 서비스 인스턴스를 작성해야 하는 사용자를 지정하십시오. 그런 다음 기본 리소스 그룹에 대한 편집자 역할이 있는 정책과 사용자가 작성해야 하는 서비스에 대한 편집자 역할이 있는 정책을 지정하십시오.
액세스 그룹을 작성하고 이 그룹에 리소스 그룹의 서비스 인스턴스를 사용해야 하는 사용자를 지정하십시오. 그런 다음 리소스 그룹에 있는 서비스 인스턴스에 대한 작성자 또는 독자 역할이 있는 정책을 지정하십시오.

신뢰 프로파일을 사용하여 단일 프로젝트에서 함께 작업하는 여러 사용자

조직에서 대규모로 액세스를 관리하려는 경우 조직의 일부 구성원이 IBM Cloud 계정을 관리하고 다른 사용자에게 액세스 권한을 할당해야 합니다. 일부 구성원은 비용을 초래하는 서비스 인스턴스를 작성해야 합니다. 기타 멤버는 애플리케이션 컴포넌트에서 서비스 인스턴스만 사용해야 하는 애플리케이션 개발자입니다.

모든 사용자에게 계정 및 기본 리소스 그룹의 다양한 역할을 부여하려고 합니다. 리소스를 분리하거나 일부 사용자가 일부 리소스에 액세스하지 못하도록 제한하기 위해 추가 리소스 그룹을 작성할 필요는 없습니다. 각 사용자 유형에 대해 신뢰 프로파일을 작성하고 외부 IdP 속성을 기반으로 올바른 프로파일에 맵핑하여 필요에 적합한 역할을 사용자에게 부여할 수 있습니다.

계정을 관리하고 다른 사용자에게 액세스 권한을 부여해야 하는 사용자에 대해 신뢰 프로파일을 작성하십시오. 외부 IdP와 신뢰 관계를 설정하고 조직의 적절한 구성원이 프로파일을 적용할 수 있도록 하는 속성을 정의하십시오. 그런 다음 모든 IAM 사용 서비스 및 모든 계정 관리 서비스에 대한 관리자 역할이 있는 정책을 지정하십시오.
서비스 인스턴스를 작성해야 하는 사용자에 대해 신뢰 프로파일을 작성하십시오. 외부 IdP와 신뢰 관계를 설정하고 조직의 적절한 구성원이 프로파일을 적용할 수 있도록 하는 속성을 정의하십시오. 그런 다음 기본 리소스 그룹에 대한 편집자 역할이 있는 정책과 사용자가 작성해야 하는 서비스에 대한 편집자 역할이 있는 정책을 지정하십시오.
리소스 그룹에서 서비스 인스턴스를 사용해야 하는 사용자에 대해 신뢰 프로파일을 작성하십시오. 외부 IdP와 신뢰 관계를 설정하고 조직의 적절한 구성원이 프로파일을 적용할 수 있도록 하는 속성을 정의하십시오. 그런 다음 리소스 그룹에 있는 서비스 인스턴스에 대한 작성자 또는 독자 역할이 있는 정책을 지정하십시오.

두 개의 관련 프로젝트에서 작업하는 두 팀

계정에 두 개의 기능 프로젝트가 있습니다. 프로젝트에서 작업 중인 개발자는 모든 리소스에 액세스할 수 있어야 합니다. 계정 관리자는 각 프로젝트에 대한 액세스 그룹을 작성하고 액세스 관리 태그를 각 그룹의 액세스 정책에 통합하여 액세스 권한을 부여할 수 있습니다.

유연성이 중요하며 IAM을 사용하면 다양한 그룹 간에 리소스를 공유할 수 있습니다. 리소스가 두 프로젝트 모두에서 잘 작동할 수 있음을 확인했다고 가정해 보겠습니다. 리소스에 태그를 지정하고 기존 권한에 의존하여 개발자에게 액세스 권한을 부여하여 두 프로젝트 간에 리소스를 공유할 수 있습니다. 프로젝트에 더 이상 리소스가 필요하지 않은 경우 서비스 인스턴스에서 적절한 태그를 분리하여 개발자의 액세스 권한을 간단히 취소할 수 있습니다. 액세스 관리 태그를 사용하여 계정의 리소스에 대한 액세스를 관리하는 방법을 더 잘 이해하려면 다음 동영상을 확인하십시오.

동영상 대본

계정 관리자는 태그를 사용하여 규모에 맞게 계정의 리소스에 대한 액세스를 중앙에서 관리할 수 있습니다.

예를 들어, 두 개의 기능적 프로젝트가 있습니다. 하나는 Watson 언어 서비스 및 스토리지에 사용되는 Soulmate이고 다른 하나는 프로젝트 Soulmate를 지원하는 Soul-FAQ입니다. Watson Assistant 및 Cloud Object Storage를 사용합니다.

계정 관리자로서 액세스 관리 태그를 작성하려면 IBM Cloud 콘솔에서 관리를 클릭한 다음 계정을 클릭하십시오. 태그 페이지에서 액세스 관리 태그를 클릭하십시오. 새 태그를 작성하려면 쉼표로 구분된 태그 이름을 입력하십시오. 지금 두 개의 태그를 작성하고 있습니다. 하나는 프로젝트 soulmate용이고 다른 하나는 프로젝트 soul-faq용입니다.

리소스 목록으로 이동하면 계정의 모든 리소스를 볼 수 있습니다. 여기에서 프로젝트 관련 리소스에 태그를 지정하고 태그별로 필터링하여 계정 전체에서 이를 볼 수 있습니다.

이때 개발자는 아직 올바른 권한이 지정되지 않았기 때문에 리소스를 볼 수 없습니다.

계정 관리자는 액세스 그룹과 태그의 조합을 사용하여 개발자에게 프로젝트의 리소스에 액세스할 수 있는 권한을 부여할 수 있습니다.

계정 관리자는 관리, 액세스를 차례로 클릭하고 액세스 그룹을 선택하십시오. 두 개의 액세스 그룹이 설정되어 있습니다. 하나는 soulmate 프로젝트용이고 다른 하나는 FAQ용입니다.

soulmate 개발자 그룹에는 한 명의 개발자가 있습니다. 설정된 정책이 없으므로 계정 관리자가 액세스 권한을 지정해야 합니다. 이를 수행하려면 특정 속성을 기준으로 계정의 모든 서비스를 선택하십시오. 계정에서 사용 가능한 모든 태그를 보려면 액세스 관리 태그를 선택하십시오. soulmate 프로젝트에 대한 정책을 작성하고 있으므로 해당 태그를 선택하십시오. 콘솔은 프로젝트 soulmate 태그가 세 개의 개별 리소스에 맵핑되었음을 보여줍니다.

다음으로 일부 역할을 선택하십시오. 모든 사용자가 목록의 리소스와 이러한 서비스에 대한 모든 기능 액세스를 볼 수 있도록 전체 그룹에 뷰어 역할을 부여하십시오. 지정을 클릭하여 정책을 작성하십시오.

이제 개발자가 사용할 수 있는 세 가지 서비스가 있습니다. 세 개의 리소스 및 존재할 수 있는 모든 하위 리소스에 액세스할 수 있습니다.

유연성이 중요하므로 다양한 그룹 간에 리소스를 쉽게 공유할 수 있습니다. 계정 관리자가 IBM Cloud Object Storage가 백업 용도에 적합하고 FAQ 프로젝트와 잘 작동한다는 것을 알고 있다고 가정해 보겠습니다. 계정 관리자는 Soulmate 프로젝트에서 IBM Cloud Object Storage를 사용하려고 합니다.

액세스 관리 태그를 편집하기만 하면 됩니다. 프로젝트 soulmate 태그를 추가하고 저장을 클릭하십시오.

리소스 목록에서 Cloud Object Storage 인스턴스에 연결된 두 개의 액세스 관리 태그가 있는지 확인할 수 있습니다.

원래 리소스 외에도 개발자는 이제 Cloud Object Storage 리소스를 볼 수 있습니다. 인스턴스는 프로젝트 soulmate 또는 프로젝트 FAQ에 액세스할 수 있는 모든 사용자가 사용할 수 있습니다.

더 이상 soulmate 프로젝트에 Tone Analyzer 서비스를 원하지 않는다고 가정해 보겠습니다. Tone Analyzer 서비스에서 프로젝트 soulmate 태그를 분리하면 해당 서비스 인스턴스에 대한 개발자의 액세스 권한이 취소됩니다. 계정 관리자는 태그 편집을 클릭하고 목록에서 태그를 삭제하여 태그를 분리할 수 있습니다.

Tone Analyzer 서비스 인스턴스는 더 이상 개발자의 리소스 목록에 포함되지 않습니다.

액세스 관리 태그를 사용하여 액세스를 제어하는 경우 IAM 정책에 대한 업데이트 없이도 팀 프로젝트의 확장이 가능합니다.

세 개의 팀이 세 개의 프로젝트에 대해 작업하는 경우

내 계정 내의 몇몇 사용자는 관리자입니다. 이러한 사용자는 새 리소스 그룹을 작성하고 사용자에게 해당 리소스 그룹에 대한 액세스 권한을 지정할 수 있습니다. 모든 IAM 지원 서비스에 지정된 관리자 역할이 있는 정책을 사용하여 이러한 사용자를 액세스 그룹에 할당합니다.

나머지 사용자는 프로젝트와 연관된 리소스 그룹에만 액세스해야 합니다. 액세스 그룹을 사용하고 해당 프로젝트와 연관된 리소스 그룹 및 멤버에 대한 다양한 역할을 지정합니다. 인스턴스를 작성해야 하는 사용자에는 리소스 그룹에 대한 편집자 역할을 지정하고 해당 인스턴스를 사용해야 하는 사용자에는 리소스 그룹 멤버에 대한 독자 또는 작성자 역할을 지정합니다.

내 계정 내의 여러 리소스 그룹

내 계정의 일부 사용자는 내 전체 계정에 걸쳐 Service A 서비스에 대한 관리자이며 해당 서비스의 모든 인스턴스에 대한 액세스 권한과 인스턴스를 작성하기 위한 액세스 권한이 필요합니다. 이러한 사용자에는 계정의 다른 리소스에 대한 액세스 권한이 필요하지 않습니다. 액세스 그룹을 작성하고 계정 레벨에서 서비스 A에 대한 관리자 역할과 인스턴스를 작성할 수 있어야 하는 계정의 리소스 그룹에 대한 뷰어 역할이 있는 정책을 지정합니다. 리소스 그룹만 선택한 다음 리소스 그룹과 해당 리소스 그룹에 대한 최소 뷰어 역할을 선택하면 됩니다. 그런 다음 액세스가 필요한 리소스 그룹마다 반복하십시오.

특정 리소스에 액세스해야 하는 사용자

내 계정에는 한 서비스 내의 특정 리소스에 대한 액세스 권한만 필요한 사용자가 있습니다. 예를 들어, IBM Cloud Object Storage 내의 Bucket A 버킷에 쓸 수 있는 기능이 필요합니다. 이 사용자는 내 계정 내의 리소스 그룹을 보거나 Object Storage의 이 인스턴스 내의 기타 서비스 또는 버킷에 액세스할 필요가 없습니다.

이 사용자에게 Object Storage의 특정 인스턴스 내의 버킷 A에 대한 작성자 역할을 지정합니다. IAM UI 또는 Object Storage UI를 사용하여 역할을 지정하도록 선택할 수 있습니다. 리소스 목록에서 지정할 수 있으므로 서비스별 UI를 사용합니다. IAM UI는 서비스 인스턴스 레벨 아래에 리소스를 표시하지 않으므로 수동으로 CRN을 입력하여 해당 리소스에 대한 정책을 지정해야 합니다.

다음 단계

리소스 그룹을 설정하고 리소스를 구성하며 계정에 액세스 그룹을 작성하는 방법을 알게 되었으므로 계정에 사용자를 초대하고 액세스 그룹에 대한 액세스 권한을 지정할 수 있습니다. 이미 사용자를 계정에 초대했다면 사용자 페이지로 이동하여 콘솔에서 액세스 권한 할당을 시작할 수 있습니다.

조직에서 회사 사용자 디렉터리를 기반으로 사용자 액세스를 관리하기로 결정한 경우 신뢰할 수 있는 프로필을 만드는 것으로 시작할 수 있습니다. 자세한 내용은 페더레이션 사용자 및 워크로드에 대한 신뢰할 수 있는 프로필을 참조하세요.