주:

태그 기반 Oracle Cloud Infrastructure Identity and Access Management 정책 심층 분석

소개

Oracle Cloud Infrastructure Identity and Access Management(OCI IAM) 정책은 강력하고 안전한 클라우드 환경의 초석입니다. OCI 리소스에 대한 액세스를 제어하는 강력하고 유연한 메커니즘을 제공하여 권한이 부여된 사용자 및 서비스만 지정된 리소스에 대해 특정 작업을 수행할 수 있도록 보장합니다.

OCI IAM 정책은 사람이 읽을 수 있는 구문으로 작성된 선언문 집합으로, 누가가 무엇에 액세스할 수 있는지 그리고 어떤 조건에 따라 액세스할 수 있는지 지정합니다. 이러한 정책을 통해 조직은 최소 권한 원칙을 적용할 수 있으며, 사용자 및 서비스에 자신의 작업을 수행하는 데 필요한 권한만 부여할 수 있습니다. 이는 운영 효율성을 유지하면서 보안 위험을 최소화합니다.

OCI IAM 정책은 구획, 테넌시 및 특정 리소스를 포함한 OCI 계층의 다양한 레벨에서 적용되므로 복잡한 조직 구조에 매우 적응할 수 있습니다. OCI의 정책 상속 및 구획화를 통해 관리자는 특정 보안 및 운영 요구사항에 맞게 세분화된 제어를 설정할 수 있습니다. OCI 정책에 대한 자세한 내용은 정책 시작하기를 참조하십시오.

이 자습서에서는 정책 최적화의 중요성에 대해 알아보고, 최적의 결과를 얻기 위해 정책을 미세 조정하기 위한 모범 사례를 탐색하고, 정책 최적화를 최대한 활용할 수 있는 시나리오를 강조합니다.

목표

필요 조건

정책 구성 요소 및 구문 이해

OCI IAM 정책을 효과적으로 튜닝하려면 해당 정책의 구조와 주요 구성 요소를 이해해야 합니다. OCI의 정책은 누가(주체), 무엇(리소스)에 대한 작업, 어디에(범위)를 지정하여 권한을 정의합니다. 우리는 이것을 분해하자 :

OCI IAM 정책의 주요 구성 요소

보너스 팁: OCI IAM 정책의 Sets-Intersect Concept 이해

OCI IAM 정책의 sets-intersect는 두 값 집합 간에 겹치는 경우에만 액세스 권한을 부여하는 데 사용됩니다. 이렇게 하면 특정 사용자 또는 그룹의 정책을 하드코딩하는 대신 그룹 멤버쉽, 리소스 태그 또는 기타 속성에 따라 권한이 동적으로 부여됩니다.

대규모 OCI IAM 정책 모델

OCI IAM 정책은 OCI에서 워크로드를 보호하는 기본 요소 중 하나입니다. 고객을 위해 대규모 워크로드를 확장하고 지원할 수 있어야 합니다. 따라서 모든 규모의 워크로드에 대해 작동하는 OCI의 정책 한도 내에서 적은 수의 정책이 필요한 정책 모델을 생성했습니다. 다음은 확장 가능한 정책 모델을 채택하는 몇 가지 이유입니다. 자세한 내용은 IAM With Identity Domains Limits을 참조하십시오.

OCI IAM 정책 튜닝은 OCI의 정책 한도를 유지하면서 안전하고 확장 가능하며 효율적인 클라우드 환경을 유지하는 데 중요한 작업입니다. 이 과정이 필수적인 이유는 다음과 같습니다.

Policy Management에서 태그 지정의 역할

태그 지정은 리소스에 대한 세분화된 제어를 가능하게 함으로써 정책 관리를 크게 향상시키는 OCI의 강력한 기능입니다. 태그는 리소스에 연결할 수 있는 키-값 쌍으로 표현되는 메타데이터 레이블입니다. 특히 여러 팀과 프로젝트를 갖춘 복잡한 클라우드 환경에서 대규모 액세스 제어를 구성, 관리 및 시행할 수 있습니다. 자세한 내용은 태그 지정 개요를 참조하십시오.

태그 지정으로 정책 관리 향상 방법

  1. 리소스 식별 단순화: 태그는 프로젝트, 환경, 소유자 또는 부서와 같은 속성을 기반으로 리소스를 분류하는 통합된 방법을 제공합니다. 이렇게 하면 특정 리소스 하위 세트에 정책을 적용하는 프로세스가 간소화됩니다.

    예: Project: ProjectX를 사용하여 리소스에 태그를 지정하면 대상 액세스 정책이 사용으로 설정됩니다.

    Allow group Developers to manage instances in tenancy where tag.Project = 'ProjectX'

  2. 동적 정책 적용 사용: 태그 기반 정책은 변화하는 리소스 속성에 맞게 조정됩니다. 예를 들어, 새 인스턴스에 Environment: Production 태그가 지정된 경우 운용 환경에 대해 정의된 정책을 자동으로 상속합니다.

    정책 예:

    Allow group QA to inspect instances in tenancy where tag.Environment = 'Test'

  3. 다중 프로젝트 및 다중 팀 거버넌스 간소화: 태그는 리소스를 특정 팀 또는 프로젝트와 연계하여 액세스를 격리하는 데 도움이 됩니다. 이렇게 하면 여러 그룹의 권한을 관리할 때 복잡성이 줄어듭니다.

  4. 자동화 활용: 태그는 리소스 생성, 모니터링, 수명 주기 관리를 위한 자동화된 워크플로를 구동할 수 있습니다. 예를 들어, 비용 추적 스크립트는 CostCenter: Marketing 태그가 지정된 모든 리소스를 검색하여 세부 비용 보고서를 생성할 수 있습니다.

  5. 비용 관리 및 보고 향상: 태그를 사용하면 특정 프로젝트, 부서 또는 환경에 대한 비용 속성을 세분화할 수 있습니다. 이를 통해 조직은 지출을 추적하고 예산을 보다 효과적으로 최적화할 수 있습니다.

태그 거버넌스: 태그 관리 제어

정책 관리에서 일관성, 신뢰성 및 보안을 유지하려면 태그 생성 및 수정을 엄격하게 제어해야 합니다. 거버넌스는 태그가 올바르게 적용되고 조직 표준에 맞춰 조정되도록 보장합니다. 태그 관리를 특정 개인 또는 그룹으로 제한하는 것은 조직의 클라우드 환경 내에서 제어, 일관성 및 보안을 유지하는 핵심 요소입니다.

실제 사용 사례에 대한 태그 기반 OCI IAM 정책

이제 위에서 배운 모든 것을 통해 실제 사용 사례에서 사용자 원칙 및 인스턴스 원칙에 대한 OCI IAM 정책을 튜닝해 보겠습니다. 그러나 이를 수행하기 전에 모든 고객이 사용 사례에 관계없이 요구하는 몇 가지 일반적인 정책이 있습니다.

사용자 주체에 대한 OCI IAM 정책 스케일 조정

OCI IAM 정책 모델: 이 정책 모델의 목표는 속성 기반 액세스 제어(Attribute Based Access Control)라고도 알려진 데이터(당사의 경우 태그)로 통보되는 보다 적은 수의 관리 가능한 정책을 작성하는 것입니다. 액세스 제어를 위해 대상 리소스 또는 대상 리소스 컴파트먼트에 지정된 태그를 권한 태그라고 합니다.

권한 태그: 테넌시의 모든 동사(작업) + 리소스 유형 조합에 대한 권한 태그를 정의합니다. 대상 리소스에 대한 사용자 그룹에 지정해야 하는 고유한 권한을 정의합니다. 목록이 한 번 설정 및 완료되지 않았습니다. 적은 수의 권한 태그로 시작합니다. 정책 모델을 통해 핸들을 가져오면 권한 태그를 더 추가할 수 있습니다. 이 자습서에서는 권한 태그 네임스페이스를 mgmt로 생성합니다. 또한 gname이라는 하나의 태그 키를 사용하여 태그 네임스페이스(이 infosec)를 만듭니다.

  1. 리소스 유형이 네 개인 다음 컴파트먼트 구조의 경우 해당 리소스에 대한 관리 및 사용 권한을 지정하기 위해 권한 태그가 생성됩니다.

    권한 설정 태그

  2. 대상에 지정해야 하는 모든 권한(대부분의 경우 구획)에 대해 그룹을 생성합니다. 컴파트먼트 기본 태그를 사용하여 리소스에 권한 태그를 지정하고 리소스 구획을 지정합니다. 태그 값은 대상 리소스에 대해 제공된 권한이 있어야 하는 그룹입니다.

    권한 태그 그룹

  3. 권한 태그가 정의되면 정책을 작성할 수 있습니다. 최종 결과는 테넌시에 정의된 권한 태그당 하나의 정책만 필요하다는 것입니다. 제공된 권한에 대해 동일한 정책이 전체 테넌시에서 작동합니다.

    권한 태그 정책

  4. 더 많은 워크로드를 온보딩할 때 관리할 리소스 유형이 더 많은 경우 해당 권한 태그에 대한 권한 태그 및 정책을 추가해야 할 수 있습니다. 그렇지 않으면 액세스 권한을 가져야 하는 사용자 그룹을 사용하여 새 작업 부하에 기존 권한 태그를 지정합니다. 새 작업 로드에 대해 새 정책을 작성할 필요가 없습니다.

이 접근 방식은 여기에 설명된 모든 예에서 일관되게 유지되며 OCI IAM 그룹 및 정책을 정의하는 기반이 됩니다.

예 1: 모든 애플리케이션에 대한 컴파트먼트

1단계: 고객의 비즈니스에 대한 포괄적인 이해

CompanyA는 고객을 위해 여러 클라우드 네이티브 애플리케이션을 개발 및 배포하는 성장하는 기술 회사입니다. 각 애플리케이션은 엄격한 보안 및 규정 준수 요구 사항을 갖춘 특정 고객 세그먼트를 대상으로 합니다. 격리, 확장성 및 효율적인 액세스 제어를 보장하기 위해 CompanyA는 구조화된 구획화 접근 방식을 사용하여 OCI 리소스를 구성합니다.

단계 2: 작업 로드에 대한 컴파트먼트 구조 설계

설명된 대로 CompanyA는 OCI IAM 정책을 확장하기 위한 OCI IAM 정책 모델을 따릅니다. 리소스 격리를 유지 관리하기 위해 애플리케이션에 대해 별도의 구획을 만들었습니다.

사용 사례 1

주: 관리자만 mgmt 및 infosec 태그 네임스페이스를 관리할 수 있어야 합니다.

3단계: Verb+Resource 조합 유형의 다음 권한 태그 설계

OCI에서 그룹을 생성합니다.

  1. 그룹 생성 권한이 있는 관리자 계정으로 OCI IAM 도메인에 로그인합니다.

    OCI 홈

  2. ID 및 보안으로 이동하고 ID 아래의 도메인을 누릅니다.

    도메인

  3. 구획을 선택하고 그룹을 생성할 도메인을 누릅니다.

    도메인 선택

  4. 그룹을 누릅니다.

    그룹

  5. 권한 태그를 기반으로 그룹을 정의합니다. (선택사항) 사용자를 해당 그룹에 추가합니다.

    그룹 생성

주: 권한과 대상의 고유한 조합에 대해 그룹을 생성해야 합니다. 동일한 기능 그룹의 사용자(NetworkAdmin)가 모든 대상에서 네트워크를 관리할 수 있는 액세스 권한을 가져야 하는 경우 모든 대상에서 액세스를 관리하려면 하나의 그룹만 필요합니다.

다음은 해당 태그에 대한 권한 태그 및 OCI IAM 그룹입니다. 위의 단계에 따라 정의된 각 권한 태그에 대해 그룹을 만듭니다.

  1. 루트 컴파트먼트: 루트 컴파트먼트는 최상위 레벨 관리 계층으로 사용됩니다. 여기서 권한 태그가 지정된 관리자 그룹이 표시됩니다. 태그는 다음과 같습니다.

    • 관리자: 전체 테넌시 관리를 위한 manageall 권한입니다.
    • UseAdministrators: 테넌시 전체에서 리소스에 액세스할 수 있는 useall 권한입니다.
    • 감사자: 테넌시 간 모니터링을 위해 리소스에 대한 읽기 전용 액세스 권한이 있는 readall 권한입니다.

  2. 애플리케이션별 구획 모델: CompanyA에는 여러 클라우드 기반 애플리케이션이 있습니다. 각 애플리케이션에 대해 별도의 상위 컴파트먼트를 생성합니다. 이 모델이 애플리케이션 1(App1) 및 애플리케이션 2(App2)에 상위 구획으로 적용되는 방법에 대해 살펴보겠습니다.

    • 애플리케이션 1(App1): OCI에서 호스팅되는 고객 대면 애플리케이션입니다.

      • 네트워크 컴파트먼트: VCN, 서브넷 등의 모든 네트워크 관련 리소스에 대한 컴파트먼트입니다. 이제 권한 태그 및 해당 OCI IAM 그룹을 생성할 수 있습니다.
        • App1NetworkAdmin: App1에 대한 네트워크 리소스를 관리하는 엔지니어를 위한 managenetwork 리소스 권한 태그입니다.
        • App1NetworkUser: App1의 네트워크 구성에 대한 제한된 액세스가 필요한 개발자를 위한 usenetwork 리소스 권한 태그입니다.
        • App1NetworkReader: App1의 네트워크 설정을 확인하는 감사자에 대한 readnetwork 리소스 권한 태그입니다.
      • 컴퓨트 컴파트먼트: 컴퓨트 인스턴스용 컴파트먼트입니다. 이제 권한 태그 및 해당 OCI IAM 그룹을 생성할 수 있습니다.
        • App1ComputeAdmin: 시스템 관리자가 App1 백엔드에 대한 컴퓨트 인스턴스를 프로비전 및 스케일링하기 위한 managecompute 리소스 권한 태그입니다.
        • App1ComputeUser: App1의 백엔드 서비스를 배치 및 테스트하는 개발자를 위한 usecompute 리소스 권한 태그입니다.
        • App1ComputeReader: App1에 대한 컴퓨트 리소스 사용을 모니터링하는 감사자에 대한 readcompute 리소스 권한 태그입니다.
      • 데이터 컴파트먼트: 데이터베이스 및 스토리지 관련 리소스에 대한 컴파트먼트입니다. 이제 권한 태그 및 해당 OCI IAM 그룹을 생성할 수 있습니다.
        • App1DataAdmin: managedb App1용 Oracle Autonomous Databases 및 OCI Object Storage를 관리하는 데이터베이스 관리자를 위한 리소스 권한 태그입니다.
        • App1DataUser: usedb App1와 관련하여 분석을 위해 데이터 세트에 액세스하는 데이터 과학자에 대한 리소스 권한 태그입니다.
        • App1DataReader: App1의 데이터베이스 구성을 검토하는 감사자에 대한 readdb 리소스 권한 태그입니다.

    • 애플리케이션 2(App2): CompanyA의 운영을 위한 내부 ERP(전사적 자원 관리) 시스템입니다.

      참고: 여기에서도 동일한 컴파트먼트 구조 접근 방식을 따르고 상위 App2 컴파트먼트 아래에 네트워크 컴파트먼트, 컴퓨트 컴파트먼트 및 데이터 컴파트먼트를 생성합니다. 중복을 방지하기 위해 App2에 대한 권한 태그 및 OCI IAM 그룹을 기록해 둡니다.

      • 네트워크 컴파트먼트:

        • App2NetworkAdmin: managenetwork 리소스 권한 태그입니다.
        • App2NetworkUser: usenetwork 리소스 권한 태그입니다.
        • App2NetworkReader: readnetwork 리소스 권한 태그입니다.

      • 컴퓨트 컴파트먼트:

        • App2ComputeAdmin: managecompute 리소스 권한 태그입니다.
        • App2ComputeUser: usecompute 리소스 권한 태그입니다.
        • App2ComputeReader: readcompute 리소스 권한 태그입니다.

      • 데이터 컴파트먼트:

        • App2DataAdmin: managedb 리소스 권한 태그입니다.
        • App2DataUser: usedb 리소스 권한 태그입니다.
        • App2DataReader: readdb 리소스 권한 태그입니다.

주: 대상에 권한 태그(대상은 리소스 또는 컴파트먼트일 수 있음)를 적용하여 App1 및 App2의 대상에 대해 특정 권한을 가질 그룹을 지정합니다.

4단계: 해당 권한 태그에 대한 OCI IAM 정책 작성

여기에 설명된 것과 동일한 접근 방식을 사용하여 CompanyA에 대한 정책을 생성할 것입니다. 더 적은 비용으로 그룹에 대한 OCI IAM 정책 확장. 이를 위해 gname이라는 하나의 태그 키로 태그 네임스페이스(이 infosec)를 만듭니다.

  1. 정책 생성 권한이 있는 관리자 계정으로 OCI IAM 도메인에 로그인합니다.

    OCI 홈

  2. ID 및 보안으로 이동하고 ID 아래의 정책을 누릅니다.

    정책

  3. 루트 컴파트먼트를 선택하고 정책 생성을 누릅니다.

    정책 생성

  4. 이름, 설명을 정책에 입력하고 정책 문도 추가합니다. Create를 누릅니다.

    • 모든 리소스 정책:

      Allow any-user to manage all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageall)
Allow any-user to use all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useall)
Allow any-user to read all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readall)

      정책 문

      주: 다음 언급된 정책을 모두 정의하고 해당 정책 문을 추가하려면 동일한 절차를 따르십시오.

    • Cloudguard 정책:

      Allow any-user to manage cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecspm)
Allow any-user to use cloud-guard-family in tenancy where
sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecspm)
Allow any-user to read cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcspm)

    • 네트워크 정책:

      Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork)
Allow any-user to use virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useetwork)
Allow any-user to read virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readnetwork)

    • 컴퓨트 정책:

      Allow any-user to manage instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecompute)
Allow any-user to use instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecompute)
Allow any-user to read instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcompute)

    • 데이터베이스 정책:

      Allow any-user to manage database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managedb)
Allow any-user to use database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usedb)
Allow any-user to read database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readdb)

예 2: 모든 고객/테넌트의 컴파트먼트

1단계: 고객의 비즈니스에 대한 포괄적인 이해

CompanyB Solutions는 클라우드 인프라, 데이터 관리 및 애널리틱스에서 테넌트 기반의 SaaS 애플리케이션을 제공하는 선도적인 ISV(Independent Software Vendor)입니다. CompanyB 다양한 업계의 고객을 대상으로 원활하고 안전하며 확장 가능한 솔루션을 제공합니다. 그들의 성공은 보안 및 규정 준수 요구 사항을 준수하면서 리소스를 효율적으로 관리하기 위해 잘 설계된 구획 구조와 함께 OCI를 사용하는 데 달려 있습니다.

단계 2: 작업 로드에 대한 컴파트먼트 구조 설계

CompanyB 고객의 워크로드를 격리하고 전용 하위 구획을 생성했습니다. 또한 네트워크 구획, 공유 스토리지 및 데이터베이스 구획이 있습니다. CompanyB도 OCI IAM 정책 확장을 위해 OCI IAM 정책 모델을 따릅니다.

사용 사례 2

3단계: Verb+Resource 조합 유형의 다음 권한 태그 설계

그룹을 만들려면 예 1 단계 3을 참조하십시오. 아래에 정의된 모든 권한 태그에 대해 그룹을 만들어야 합니다.

  1. 루트 구획 - 중앙 집중식 거버넌스: 루트 구성요소는 OCI 테넌시 전반의 모든 리소스 및 활동을 감독하기 위한 중앙 계층 역할을 합니다. 여기서 권한 태그가 지정된 관리자 그룹이 표시됩니다. 태그는 다음과 같습니다.

    • 관리자: 전체 테넌시 관리를 위한 manageall 권한입니다.
    • UseAdministrators: 테넌시 전체에서 리소스에 액세스할 수 있는 useall 권한입니다.
    • 감사자: 테넌시 간 모니터링을 위해 리소스에 대한 읽기 전용 액세스 권한이 있는 readall 권한입니다.

  2. 네트워크 컴파트먼트 - 운영 백본: 네트워크 컴파트먼트는 CompanyB의 클라우드 네트워킹 인프라를 지원하여 모든 리소스에 대한 연결을 지원합니다. 여기에는 VCN(가상 클라우드 네트워크), 서브넷, 게이트웨이 및 로드 밸런서가 포함됩니다. 권한 태그 및 해당 OCI IAM 그룹을 정의해 보겠습니다.

    • NetworkAdmin: CompanyB에 대한 네트워크 리소스를 관리하는 엔지니어를 위한 managenetwork 리소스 권한 태그입니다.
    • NetworkUser: CompanyB의 네트워크 구성에 대한 제한된 액세스가 필요한 개발자를 위한 리소스 권한 태그는 usenetwork입니다.
    • NetworkReader: CompanyB의 네트워크 설정을 확인하는 감사자에 대한 readnetwork 리소스 권한 태그입니다.

  3. 테넌트 구획 - 다양한 고객 워크로드를 위한 격리된 구획: 테넌트 구획은 각 클라이언트(테넌트)에 대한 리소스와 워크로드를 격리하기 위해 구성됩니다. 이를 통해 CompanyB는 운영 효율성을 유지하면서 안전한 개인 서비스를 제공합니다.

    • 테넌트 1 컴파트먼트: 테넌트 1은 애플리케이션 개발 및 로깅 서비스에 CompanyB를 사용하는 주요 엔터프라이즈 클라이언트를 나타냅니다. 다음은 권한 태그 및 해당 OCI IAM 그룹입니다.

      • t1devadmin: 테넌트 1의 개발 팀에 대한 manageappdev 리소스 권한은 사용자 정의 응용 프로그램을 구성, 배치할 수 있는 관리 권한을 가집니다.
      • t1devuser: 응용 프로그램 리소스를 모니터 및 조정할 수 있는 useappdev 리소스 권한입니다. 테넌트 1의 개발자는 이러한 리소스를 일상적인 개발 및 테스트에 사용합니다.
      • t1logsadmin 및 t1devuser: 역할 로깅 및 모니터링을 위한 managelogs 및 uselogs 리소스 권한은 administrators가 로깅 서비스를 구성하고 developers가 로그에 액세스하여 응용 프로그램을 디버그하고 최적화하도록 합니다.
      • t1devadmin 및 t1devuser: 테넌트 1에 대한 managecspm 및 usecspm 리소스 권한도 보안 상태에 중점을 두고 있으며 보안 위험을 모니터링하고 해결할 수 있습니다.

    • Tenant 2 and Tenant 3 Compartments: The structure for Tenant 2 and Tenant 3 mirrors that of Tenant 1, with roles like t2devadmin, t2devuser, t3devadmin, t3devuser, t2logsadmin and t3logsadmin ensuring that each tenant operates in a fully isolated environment. 이 접근 방식을 통해 CompanyB는 특정 테넌트 요구 사항을 충족하면서 일관된 거버넌스를 유지할 수 있습니다.

    • 공유 컴파트먼트 - 모든 테넌트를 위한 중앙 집중식 리소스: 공유 컴파트먼트에는 여러 테넌트가 사용하지만 개인 정보 보호 및 보안을 위해 논리적으로 분리된 상태로 유지되는 데이터베이스 및 오브젝트 스토리지와 같은 리소스가 포함됩니다.

      • 데이터베이스 컴파트먼트:
        • dbadmin: CompanyB의 데이터베이스 관리자에 대한 managedb 리소스 권한은 프로비저닝(provisioning), 확장(scaling), 패치 적용을 포함하여 모든 테넌트가 사용하는 공유 데이터베이스를 처리합니다.
        • dbuser: 테넌트별 사용자에 대한 usedb 리소스 권한은 해당 데이터베이스 스키마 또는 서비스에 액세스합니다.
        • dbreader: 데이터베이스 구성이 보안 정책을 준수하는지 확인하기 위해 감사자에 대한 readdb 리소스 권한은 읽기 전용 액세스 권한을 가집니다.
      • 스토리지 구획: OCI Object Storage는 각 테넌트에 대한 전용 버킷을 사용하여 중앙에서 관리됩니다.
        • osadmin: 공유 객체 저장소 리소스 관리를 담당하는 manageobject 리소스 권한입니다.
        • osuser: useobject 테넌트별 저장소 리소스 권한(또는 t1osur, t2osur, t3osur)은 테넌트가 해당 버킷에만 액세스하도록 합니다.
        • osreader: 규정 준수 팀에 대한 리소스 권한은 스토리지 구성 및 사용 패턴을 검토합니다. readobject

4단계: 해당 권한 태그에 대한 OCI IAM 정책 작성

정책을 만들려면 예 1 단계 4를 참조하십시오. 다음 정책을 생성해야 합니다.

예제 3: 대형 엔터프라이즈 컴파트먼트 구조

1단계: 고객의 비즈니스에 대한 포괄적인 이해

CompanyC 혁신적인 소프트웨어 솔루션을 전문으로 하는 다국적 기업인 Solutions는 미션 크리티컬 워크로드를 OCI로 마이그레이션하기로 결정했습니다. 이 회사는 보안, 규정 준수 및 확장성이 가장 중요한 재무 및 의료와 같은 규제가 엄격한 산업에서 운영하고 있습니다.

단계 2: 작업 로드에 대한 컴파트먼트 구조 설계

이제 OCI IAM 정책 확장을 위해 OCI IAM 정책 모델을 따르는 CompanyC의 컴파트먼트 구조를 살펴보겠습니다.

사용 사례 3

3단계: Verb+Resource 조합 유형의 다음 권한 태그 설계

그룹을 만들려면 예 1 단계 3을 참조하십시오. 다음 모든 권한 태그에 대해 그룹을 만들어야 합니다.

  1. 루트 구획 - 중앙 집중식 거버넌스: 루트 구성요소는 OCI 테넌시 전반의 모든 리소스 및 활동을 감독하기 위한 중앙 계층 역할을 합니다. 여기서 권한 태그가 지정된 관리자 그룹이 표시됩니다. 태그는 다음과 같습니다.

    • 관리자: 전체 테넌시 관리를 위한 manageall 권한입니다.
    • UseAdministrators: 테넌시 전체에서 리소스에 액세스할 수 있는 useall 권한입니다.
    • 감사자: 테넌시 간 모니터링을 위해 리소스에 대한 읽기 전용 액세스 권한이 있는 readall 권한입니다.

  2. PROD 구획: 비즈니스 운영 및 최종 사용자에게 직접 영향을 미치는 미션 크리티컬 운영 워크로드를 호스팅하기 위한 구획입니다. 각 애플리케이션에는 리소스 격리 및 최적화된 관리를 위한 전용 하위 구획이 있습니다. 권한 태그 및 해당 OCI IAM 그룹을 정의해 보겠습니다.

    • NetworkAdmin: CompanyC에 대한 네트워크 리소스를 관리하는 엔지니어를 위한 managenetwork 리소스 권한 태그입니다.
    • NetworkReader: CompanyC의 네트워크 설정을 확인하는 감사자에 대한 readnetwork 리소스 권한 태그입니다.
    • ComputeAdmin: 시스템 관리자가 CompanyC에 대한 컴퓨트 인스턴스를 프로비전 및 스케일링하기 위한 managecompute 리소스 권한 태그입니다.
    • ComputeReader: CompanyC에 대한 컴퓨트 리소스 사용을 모니터링하는 감사자에 대한 readcompute 리소스 권한 태그입니다.
    • StorageReader: 스토리지 관리 팀이 스토리지 구성을 관리할 수 있는 리소스 권한은 manageobject입니다.
    • StorageReader: 규정 준수 팀에 대한 리소스 권한은 스토리지 구성 및 사용 패턴을 검토합니다. readobject
    • SecurityAdmin: 보안 위험을 모니터링하고 해결할 수 있는 기능과 함께 컴파트먼트 PROD에 대한 managecspm 리소스 권한도 보안 상태에 중점을 둡니다.

    이제 애플리케이션별 하위 구획에 대한 권한 태그 및 해당 OCI IAM 그룹을 정의합니다. 현재 세 개의 서로 다른 애플리케이션 구획에 대한 권한을 병합하고 정의했습니다.

    • 애플리케이션 구획:
      • PRApp1NetAdmin, PRApp2NetAdmin 및 PRApp3NetAdmin: 각각 App1, App2 및 App3에 대한 네트워크 리소스를 관리하는 엔지니어를 위한 managenetwork 리소스 권한 태그가 있는 관리 OCI IAM 그룹.
      • PRApp1NetUser, PRApp2NetUser 및 PRApp3NetUser: App1, App2 및 App3에 대한 네트워크 리소스를 관리하는 엔지니어를 위해 각각 usenetwork 리소스 권한 태그를 사용하는 관리 OCI IAM 그룹
      • PRApp1ComputeAdmin, PRApp2ComputeAdmin 및 PRApp3ComputeAdmin: App1, App2 및 App3에 대한 OCI 컴퓨트 인스턴스를 관리하는 엔지니어를 위해 각각 managecompute 리소스 권한 태그를 사용하는 관리 OCI IAM 그룹.
      • PRApp1ComputeUser, PRApp2ComputeUser 및 PRApp3ComputeUser: App1, App2 및 App3용 OCI 컴퓨트 인스턴스를 사용하는 엔지니어를 위해 각각 usecompute 리소스 권한 태그를 사용하는 관리 OCI IAM 그룹.
      • PRApp1StorageAdmin, PRApp2StorageAdmin 및 PRApp3StorageAdmin: App1, App2 및 App3에 대한 OCI Object Storage를 관리하는 엔지니어를 위해 각각 manageobject 리소스 권한 태그를 사용하는 관리 OCI IAM 그룹.
      • PRApp1StorageUser, PRApp2StorageUser 및 PRApp3StorageUser: OCI Object Storage를 App1, App2 및 App3용으로 사용하는 엔지니어를 위해 각각 useobject 리소스 권한 태그를 사용하는 관리 OCI IAM 그룹.

  3. NPROD 컴파트먼트: 스테이지, 개발 및 품질 보증 환경 전용입니다. 이 구획은 일관성을 보장하기 위해 PROD와 유사하게 구조화됩니다. 권한 태그 및 해당 OCI IAM 그룹을 정의해 보겠습니다.

    • NetworkAdmin: CompanyC에 대한 네트워크 리소스를 관리하는 엔지니어를 위한 managenetwork 리소스 권한 태그입니다.
    • NetworkReader: CompanyC의 네트워크 설정을 확인하는 감사자에 대한 readnetwork 리소스 권한 태그입니다.
    • ComputeAdmin: managecompute CompanyC용 OCI 컴퓨트 인스턴스를 프로비전하고 스케일링하기 위한 리소스 권한 태그입니다.
    • ComputeReader: readcompute CompanyC에 대한 OCI 컴퓨트 리소스 사용을 모니터링하는 감사자에 대한 리소스 권한 태그입니다.
    • StorageReader: 스토리지 관리 팀이 스토리지 구성을 관리할 수 있는 리소스 권한은 manageobject입니다.
    • StorageReader: 규정 준수 팀에 대한 리소스 권한은 스토리지 구성 및 사용 패턴을 검토합니다. readStorage
    • SecurityAdmin: 보안 위험을 모니터링하고 해결할 수 있는 기능과 함께 Compartment NPROD에 대한 managecspm 리소스 권한도 보안 상태에 중점을 두고 있습니다.

    마찬가지로 이제 애플리케이션별 하위 구획에 대한 권한 태그 및 해당 OCI IAM 그룹을 정의합니다.

    • 애플리케이션 구획:
      • NPApp1NetAdmin, NPApp2NetAdmin 및 NPApp3NetAdmin: App1, App2 및 App3에 대한 네트워크 리소스를 관리하는 엔지니어를 위해 각각 managenetwork 리소스 권한 태그를 사용하는 관리 OCI IAM 그룹
      • NPApp1NetUser, NPApp2NetUser 및 NPApp3NetUser: App1, App2 및 App3에 대한 네트워크 리소스를 관리하는 엔지니어를 위해 각각 usenetwork 리소스 권한 태그를 사용하는 관리 OCI IAM 그룹
      • NPApp1ComputeAdmin, NPApp2ComputeAdmin 및 NPApp3ComputeAdmin: App1, App2 및 App3에 대한 OCI 컴퓨트 인스턴스를 관리하는 엔지니어를 위해 각각 managecompute 리소스 권한 태그를 사용하는 관리 OCI IAM 그룹.
      • NPApp1ComputeUser, NPApp2ComputeUser 및 NPApp3ComputeUser: App1, App2 및 App3용 OCI 컴퓨트 인스턴스를 사용하는 엔지니어를 위해 각각 usecompute 리소스 권한 태그를 사용하는 관리 OCI IAM 그룹.
      • NPApp1StorageAdmin, NPApp2StorageAdmin 및 NPApp3StorageAdmin: App1, App2 및 App3에 대한 OCI Object Storage를 관리하는 엔지니어를 위해 각각 manageobject 리소스 권한 태그를 사용하는 관리 OCI IAM 그룹.
      • NPApp1StorageUser, NPApp2StorageUser 및 NPApp3StorageUser: OCI Object Storage를 App1, App2 및 App3용으로 사용하는 엔지니어를 위해 각각 useobject 리소스 권한 태그를 사용하는 관리 OCI IAM 그룹.

  4. 공유 컴파트먼트: 공유 컴파트먼트는 로깅 및 Cloud Guard OCI 서비스와 같은 모니터링을 위한 리소스를 호스트합니다. 또한 여러 테넌트에서 활용하는 암호화 및 암호 해독을 위한 키가 있으며, 개인 정보 보호 및 보안을 유지하기 위해 논리적 분리를 보장합니다. 해당 서비스에 대한 액세스 권한이 필요한 애플리케이션의 모든 관리자가 해당 서비스에 대해 생성된 OCI IAM 그룹에 추가됩니다. 권한 태그 및 해당 OCI IAM 그룹을 정의해 보겠습니다.

    • Oracle Cloud Guard 구획:

      • cspmAdmin: PROD 및 비PROD 구획용 Oracle Cloud Guard를 관리하는 관리자에 대한 관리 OCI IAM 그룹(managecspm 리소스 권한 태그 포함)입니다.
      • cspmUser: PROD 및 비PROD 구획용 Oracle Cloud Guard를 사용/모니터링하는 엔지니어를 위한 usecspm 리소스 권한 태그가 있는 OCI IAM 그룹.
      • cspmReader: PROD 및 비PROD 구획용 Oracle Cloud Guard를 읽는 엔지니어를 위한 readcspm 리소스 권한 태그가 있는 OCI IAM 그룹

    • OCI 로깅 구획:

      • logsAdmin: PROD 및 비PROD 구획에 대한 OCI 로깅을 관리하는 관리자에 대한 managelogs 리소스 권한 태그가 있는 관리 OCI IAM 그룹
      • logsUser: OCI IAM은 PROD 및 비PROD 구획에 대한 OCI 로깅을 사용/모니터링하는 엔지니어를 위한 uselogs 리소스 권한 태그와 함께 그룹화됩니다.
      • logsReader: OCI IAM은 PROD 및 비PROD 구획에 대한 OCI 로깅을 읽는 엔지니어를 위한 readlogs 리소스 권한 태그와 함께 그룹화됩니다.

    • 키 구획:

      • kmsAdmin: PROD 및 비PROD 구획의 키 볼트를 관리하는 관리자에 대한 관리 OCI IAM 그룹(managekeys 리소스 권한 태그 포함)입니다.
      • kmsUser: PROD 및 비PROD 구획에 대해 키 볼트를 사용/모니터링하는 엔지니어를 위한 usekeys 리소스 권한 태그가 있는 OCI IAM 그룹
      • kmsReader: OCI IAM은 PROD 및 비PROD 구획의 키 볼트를 읽는 엔지니어를 위한 readkeys 리소스 권한 태그와 함께 그룹화됩니다.

  5. 플레이그라운드 구획: 실험, 개발 및 테스트를 위한 유연하고 격리된 환경입니다. 이 구획은 운영 또는 규정 준수 제약 조건과 관련이 없으므로 혁신에 이상적입니다. 여기서는 매우 하위 구획에 대해 하나의 OCI IAM 관리자 그룹만 가지며 테스트 요구사항에 필요한 모든 OCI 리소스에 대해 관리 권한을 부여합니다.

    • 개발 구획:

      • DevAdmin: Dev Compartment 내의 새로운 구현을 테스트하기 위한 개발 관리자를 위한 managenetwork, managecompute, manageobject, managekeys, managelogs 리소스 권한을 가진 관리 OCI IAM 그룹

    • 구획 테스트:

      • TestAdmin: 테스트 컴파트먼트 내에서 새로운 구현을 테스트하기 위한 개발 관리자에 대한 관리 OCI IAM 그룹(managenetwork, managecompute, manageobject, managekeys, managelogs 리소스 권한)입니다.

    • 성능 테스트 구획:

      • PerfTestAdmin: 성능 테스트 컴파트먼트 내에서 새 구현을 테스트하기 위한 개발 관리자에 대한 관리 OCI IAM 그룹(managenetwork, managecompute, manageobject, managekeys, managelogs 리소스 권한)입니다.

4단계: 해당 권한 태그에 대한 OCI IAM 정책 작성

정책을 만들려면 예 1 단계 4를 참조하십시오. 다음 정책을 생성해야 합니다.

주: 새 작업 로드를 온보딩할 때마다 해당 시나리오의 경우:

세분화된 액세스 제어를 위한 태그 기반 권한 모델

지금까지 리소스 제품군에 대한 create manage, user 또는 read 권한에 대해 설명한 모든 예제입니다. 그러나 대부분의 고객은 최소 권한 모델을 따르기 위해 세부적인 액세스 제어가 필요합니다. 이 자습서는 정책 모델을 이해하는 데 중점을 두므로 간단한 사용 사례에 대해 설명했습니다. 그러나 네 명의 네트워크 담당자의 예와 해당 네 명의 페르소나에 대한 세분화된 권한 태그 및 OCI IAM 정책을 설계하는 방법을 살펴보겠습니다.

네트워크 구획에서 networkowner, networkadmin, networkoperator 및 networkuser를 네 개의 태그로 정의합니다. 해당 태그의 경우 네트워크 컴파트먼트에 액세스할 수 있는 그룹 이름을 지정합니다.

인스턴스 Principals에 대한 OCI IAM 정책 스케일 조정

예 1: OCI의 공유 스토리지 및 암호에 대한 다중 테넌트 인스턴스 액세스 제어

1단계: 고객의 비즈니스에 대한 포괄적인 이해

XYZ Cloud Solutions는 OCI에서 호스팅되는 DMS(문서 관리 시스템)를 제공하는 SaaS 제공업체입니다. 이 플랫폼은 여러 기업 고객에게 서비스를 제공하며, 각 고객은 공유 인프라를 활용하면서 데이터를 엄격하게 격리해야 합니다.

고객 요구 사항:

단계 2: 작업 로드에 대한 컴파트먼트 구조 설계

이제 OCI IAM 정책 확장을 위해 OCI IAM 정책 모델을 따르는 XYZ Cloud Solutions의 구획 구조를 살펴 보겠습니다.

인스턴스 사용 사례 1

단계 3: OCI IAM 그룹 생성

OCI 다중 테넌트 환경에서 안전하고 격리된 액세스 관리를 보장하기 위해 다음 정책이 정의됩니다.

참고: 이러한 그룹 및 OCI IAM 정책은 공통 OCI IAM 정책 섹션에서 설명한 대로 이미 생성되었습니다.

단계 4: 정의된 그룹에 대한 OCI IAM 정책 생성

테넌트 리소스 액세스 정책: 데이터 격리를 유지하려면 테넌트 리소스가 자신의 암호 및 객체 스토리지에만 액세스할 수 있어야 합니다.

Allow any-user to use object-family in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.resource.tag.Enterprise.Tenant
Allow any-user to use secret-family in compartment Tenants where request.principal.compartment.tag.Enterprise.Tenant = target.resource.tag.Enterprise.Tenant

테넌트 인스턴스 원칙에 새 객체를 생성할 수 있는 권한도 필요한 경우 테넌트 이름과 동일한 이름으로 버킷 이름을 생성하고 테넌트 이름 태그를 사용하여 버킷 이름과 비교할 수 있습니다.

Allow any-user to manage objects in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.bucket.name

예 2: 공유 OCI 스토리지 모델의 다중 서비스 데이터 액세스를 위한 세분화된 액세스 제어

1단계: 고객의 비즈니스에 대한 포괄적인 이해

XYZ Corp는 디지털 혁신 솔루션을 전문으로 하는 빠르게 성장하는 기업입니다. XYZ Corp는 글로벌 입지를 통해 여러 지역에서 운영되며 OCI를 활용하여 중요한 애플리케이션을 호스팅하고 데이터를 관리하며 팀 간 원활한 협업을 보장합니다.

고객 요구 사항:

단계 2: 작업 로드에 대한 컴파트먼트 구조 설계

이제 OCI IAM 정책 확장을 위해 OCI IAM 정책 모델을 따르는 XYZ Corp의 컴파트먼트 구조를 살펴보겠습니다.

인스턴스 사용 사례 2

단계 3: OCI IAM 그룹 생성

OCI 다중 테넌트 환경에서 안전하고 격리된 액세스 관리를 보장하기 위해 다음 정책이 정의됩니다.

참고: 공통 OCI IAM 정책 섹션에서 설명한 대로 InfoSec 및 Terraform-Runner 그룹 및 IAM 정책이 이미 생성되었습니다.

단계 4: 정의된 그룹에 대한 OCI IAM 정책 생성

테넌트 리소스 액세스 정책: 데이터 격리를 유지하려면 테넌트 리소스가 자신의 암호 및 객체 스토리지에만 액세스할 수 있어야 합니다.

Allow dynamic-group AdminInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Admin’}

Allow dynamic-group SalesInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Sales’}

Allow dynamic-group SupplyInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Supply’}

Allow any-user to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Shared’}

Allow dynamic-group AdminInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Admin’}

Allow dynamic-group SalesInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Sales’}

Allow dynamic-group SupplyInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Supply’}

확인

추가 학습 자원

docs.oracle.com/learn에서 다른 실습을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 액세스하세요. 또한 Oracle Learning Explorer가 되려면 education.oracle.com/learning-explorer을 방문하십시오.

제품 설명서는 Oracle Help Center를 참조하십시오.