Identity and Access Management FAQ

개요

Oracle Cloud Infrastructure Identity and Access Management(OCI IAM)는 어떤 서비스인가요?

OCI IAM은 엔터프라이즈 애플리케이션을 위한 강력한 적응형 인증,사용자 수명 주기 관리(LCM), Single Sign On(SSO) 등의 엔터프라이즈급 ID 및 액세스 관리 기능을 제공하는 OCI의 기본 서비스입니다. OCI IAM은 OCI에서 ID 도메인으로 배포됩니다. 포함된 도메인을 통해 Oracle Cloud 서비스(Network, Compute, Storage 등) 및 Oracle SaaS 애플리케이션에 대한 접근을 관리할 수 있습니다. 또한 고객은 비 Oracle 애플리케이션에 대한 인력 액세스 관리, 고객용 애플리케이션에 대한 고객 액세스 지원, 커스텀 개발 애플리케이션에 IAM 포함 등의 추가적인 사용 사례를 위해 ID 도메인을 업그레이드하거나 추가로 생성할 수도 있습니다.

ID 도메인이란 무엇인가요?

각 OCI IAM ID 도메인은 다양한 IAM 사용 사례에 적용할 수 있는 독립적인 ID 및 액세스 관리 솔루션입니다. 예를 들면, OCI IAM ID 도메인을 통해 다수의 클라우드 및 온프레미스 애플리케이션 관련 직원 액세스를 통합 관리함으로써 보안 인증, 용이한 자격 관리, 최종 사용자용 끊김 없는 SSO 기능 등을 활용할 수 있습니다. 비즈니스 파트너에게 공급망 또는 주문 시스템용 액세스를 제공하기 위한 ID 도메인 구축도 가능합니다. 또한 ID 도메인을 통해 소비자용 애플리케이션에 IAM을 활성화하고, 소비자가 자체 등록, 소셜 로그온 및/또는 이용 약관 동의를 수행할 수 있도록 허용할 수도 있습니다. 즉, ID 도메인이란 수많은 IAM 사용 사례 및 시나리오에 대응하는 포괄적 서비스형 ID(IDaaS) 솔루션을 의미합니다.

우리 회사는 어떤 ID 도메인 유형을 선택해야 하나요?

• 무료 ID 도메인: 각 OCI 테넌시에는 OCI 리소스(Network, Compute, Storage 등) 액세스 관리를 위한 Free Tier 기본 OCI IAM ID 도메인이 포함됩니다. OCI 리소스에 대한 액세스만을 관리하는 경우, 포함된 기본 도메인을 사용할 수 있습니다. 기본 도메인은 Oracle Cloud 리소스에 대한 액세스 관리를 위한 강력한 IAM 기능들을 제공합니다. 보안 모델 및 팀에 따라 기본 도메인을 OCI Administrator용으로 배정하는 선택도 가능합니다.
• Oracle Apps ID 도메인: Oracle Apps 도메인을 통해 다수의 Oracle Cloud 애플리케이션(HCM, CRM, ERP, 산업용 앱 등)에 OCI IAM을 포함 및 사용할 수 있습니다. 이러한 도메인은 구독한 Oracle 애플리케이션과 함께 사용 가능하도록 포함되어 있으며, Oracle Cloud 및 SaaS 서비스용 액세스 관리를 위한 강력한 IAM 기능들을 제공합니다. 고객사는 특정 Oracle Cloud 애플리케이션 서비스에 대한 SSO 사용을 위해 해당 도메인에 모든 직원을 추가할 수 있고, 해당 도메인을 통해 일부 또는 모든 OCI 리소스에 대한 액세스를 관리할 수도 있습니다.
• Oracle Apps 프리미엄 ID 도메인: SaaS 방식으로 제공되지 않는 Oracle 애플리케이션(예: 온프레미스 및 OCI에 호스팅된 Oracle E-Business Suite 또는 Oracle Database)에 대한 액세스 관리를 위해 전체 엔터프라이즈 기능이 포함된 Oracle Apps 도메인으로 확장하고자 하는 경우 Oracle Apps 프리미엄 ID 도메인을 선택할 수 있습니다. 해당 도메인은 하이브리드 클라우드 환경에 배포될 수 있는 Oracle 타겟에 사용 가능한 OCI IAM의 모든 기능을 제공합니다. 이는 완전한 기능을 제공하지만 Oracle 타겟에만 사용 가능하도록 제한되는 저렴한 서비스입니다.
• 외부 ID 도메인: 외부 ID 도메인은 리테일 사이트에 액세스하는 소비자, 졍부 사이트에 액세스하는 시민, 기업 사이트에 액세스하는 비즈니스 파트너 등의 비직원을 대상으로 OCI IAM의 모든 기능을 제공합니다. 애플리케이션 타겟팅과 관련된 제한 사항은 없습니다. 그러나 일반적 비직원 시나리오에 유용하지 않은 특정 엔터프라이즈용 기능(예: App Gateway 및 Provisioning Bridge)들은 포함되지 않습니다. 외부 도메인에는 소셜 로그온, 자체 등록, 이용약관 동의, 프로파일/비밀번호 관리 등에 대한 지원이 포함됩니다.
• 프리미엄 ID 도메인: 프리미엄 ID 도메인은 애플리케이션 타겟팅 관련 제한 없이 OCI IAM의 모든 기능을 제공합니다. 프리미엄 도메인은 클라우드 및 온프레미스 애플리케이션 전반에 대한 직원 또는 인력 액세스를 관리하는 엔터프라이즈 IAM 서비스로 사용할 수 있습니다. 안전한 인증, 자격 관리 용이성, 최종 사용자를 위한 원활한 SSO 등의 기능을 제공합니다.

단일 ID 도메인에서 직원 및 비직원을 함께 관리할 수 있나요?

아니요. OCI IAM 라이선스 관리를 위해 두 집단은 별도의 사용자 집단으로 간주합니다. 그러나 동일한 OCI IAM 서비스를 사용하여 직원 및 비직원(파트너, 제휴사, 소비자 등)을 수용할 수 있는 2개 이상의 도메인을 관리할 수 있습니다. 다수의 도메인을 사용하여 동일한 애플리케이션에 액세스할 수 있지만, 일반적으로 비직원 대상 규칙 및 보안 정책은 직원 대상 규칙 및 보안 정책과 다릅니다. 각 도메인에는 해당하는 사용자 집단별로 고유한 설정, 구성, 보안 정책 세트가 적용됩니다. 이는 일반적으로 사용자 집단에 따라 달라지는 요구 사항을 수용하기 위한 설계입니다.

ID 도메인에 대한 액세스 권한은 누구에게 부여되나요?

각 OCI 테넌시에는 모든 OCI 리소스에 대한 완전한 액세스를 제공하는 Administrators 그룹이 포함되어 있습니다. OCI Administrators 그룹의 모든 멤버에게는 OCI IAM ID 도메인을 관리할 수 있는 전체 액세스 권한이 주어진다는 사실을 유념해야 합니다. Oracle은 Administrators 그룹을 주의해서 사용할 것을 권장합니다. 각 도메인 내에서 사용자 그룹 간의 업무 분리를 허용하는 Administrator Roles을 통해 관리 권한을 부여할 수 있습니다. 자세한 내용은 Understanding Administrator Roles 문서를 참조해 주세요.

OCI IAM이 고가용성 및/또는 장애 복구 기능을 제공하나요?

각 OCI 리전은 다수의 가용성 도메인(AD) 또는 (단일 AD 리전의 경우) 장애 도메인(FD)들을 갖추고 있습니다. AD와 FD는 유사한 기능을 제공하지만 FD들은 AD들보다 물리적으로 서로 더 가깝게 위치합니다. ID 도메인은 고가용성을 제공하는 각 리전에 중복 설치 방식으로 배포됩니다(AD/FD별로 두 개씩). 또한 OCI IAM ID 도메인은 고성능 데이터 복제 기능을 활용하는 능동-수동 접근 방식을 통한 리전 간 장애 복구(DR)를 제공합니다. 리전 간 장애 복구 기능을 통해 만에 하나 전체 OCI 리전을 사용할 수 없게 되는 경우가 발생하더라도 안정적인 ID 도메인 데이터 복구가 가능합니다. 해당 DR은 단일 URL을 통해 제공되어 모든 애플리케이션에 대한 투명성을 갖습니다.

Oracle Identity and Access Management의 주요 용어 및 개념은 무엇입니까?

IAM의 주요 개념은 다음과 같습니다.

• 계정 또는 테넌시 - OCI를 신규 구독하면 Oracle은 해당 기업용 테넌시를 생성합니다. 이는 기업별 클라우드 리소스를 생성, 구성, 관리할 수 있는 OCI 내의 독립형 파티션입니다. 테넌시는 OCI 계정으로도 지칭됩니다.
• 구획 - OCI 계정 내의 Oracle Cloud 리소스용 논리 컨테이너입니다. 관리자는 각 OCI 계정 내에 구획을 하나 이상 생성하여 리소스를 구성하고 관리할 수 있습니다. 예를 들면, 구획을 사용하여 여러 유형의 관리자(네트워크, 컴퓨트, 스토리지 등) 간의 직무 분리(SoD)를 시행할 수 있습니다.
• 루트 구획 - OCI 계정 내의 최상위 구획입니다. 계정이 프로비저닝되면 루트 구획이 자동으로 생성됩니다.
• ID 도메인 - 각 ID 도메인은 OCI 내의 각 사용자 집단 및 그와 연관된 구성 및 보안 설정을 대표합니다. 각 계정에는 고객사의 OCI 리소스 액세스 관리를 위한 기본 ID 도메인이 포함됩니다. 고객사는 특정 요구 사항에 대응하는 추가 ID 도메인을 생성할 수도 있습니다. ID 도메인은 구획 내에 생성되며 도메인 관리용 액세스는 구획 권한과 연동됩니다. 특정 구획/도메인의 사용자가 다른 구획의 리소스에 액세스할 수 있도록 OCI 액세스 정책을 작성할 수 있습니다.
• 사용자 - 인증 대상인 엔티티를 의미합니다. 사용자는 개인 또는 컴퓨터 계정일 수 있습니다. 각 사용자는 계정에 고유한 이름과 전역에서 고유한 식별자를 가지고 있습니다. API를 통해 웹 콘솔 액세스용 암호 및 서비스 액세스용 키를 사용자에게 부여할 수 있습니다.
• 그룹 - 다수 사용자의 집합을 의미합니다. 그룹은 액세스 관리를 간소화하는 데 사용됩니다. 예를 들어 소프트웨어 개발자를 "개발자" 그룹의 구성원으로 함께 그룹화하면 해당 그룹의 구성원 모두가 코드를 읽고, 쓰고, 및/또는 수정할 수 있습니다. 단일 사용자는 여러 그룹의 구성원이 될 수 있습니다.
• 정책 - 특정 OCI 리소스에 액세스할 수 있는 인원 및 그들에게 부여되는 권한을 지정하는 문서입니다. 각 정책은 자연어 구문을 활용하는 정책문으로 구성됩니다.

ID 및 액세스 관리에 대한 Oracle Cloud Infrastructure(OCI)만의 고유한 접근 방식은 무엇인가요?

OCI IAM은 모든 Oracle Cloud 및 Oracle Cloud 애플리케이션 서비스에 대한 인증 및 권한 부여 작업을 수행할 수 있는 단일 모델을 제공합니다. OCI IAM은 단일 프로젝트를 수행하는 개인부터 많은 그룹이 여러 프로젝트를 동시에 수행하는 대기업에 이르기까지 모든 규모의 조직에 대한 액세스를 단일 계정 내에서 손쉽게 관리할 수 있도록 지원합니다. 리소스 관리와 권한 부여는 계정 수준 또는 구획 수준에서 이루어질 수 있으며 동시에 중앙 감사 및 청구를 계속 허용합니다. OCI IAM은 설계 단계에서부터 최소 권한의 보안 원칙을 적용할 수 있도록 구축되었으며, 신규 사용자는 기본적으로 어떤 리소스에 대한 어떤 작업도 수행할 수 없습니다. 관리자는 각 신규 사용자별로 적합한 액세스 권한만을 부여할 수 있습니다.

또한 OCI IAM은 OCI 리소스 관리 외에도 손쉽게 사용할 수 있는 엔터프라이즈급 IDaaS 솔루션을 제공합니다. 직원/인력, 파트너 또는 소비자별 사용 사례 전반에 걸친 다양한 IAM 요구 사항에 대응할 수 있는 강력한 IAM 솔루션을 관련 버튼을 클릭하는 것만으로 간단히 배포할 수 있습니다.

Oracle Cloud Infrastructure는 다단계 인증을 어떻게 지원합니까?

OCI IAM은 푸시 또는 일회용 비밀번호 옵션을 제공하는 모바일 MFA 애플리케이션, FIDO2 인증자 지원, 문자 메시지, 이메일, 전화 통화 지원 등이 포함된 광범위한 다중 인증(MFA)을 제공합니다. 또한 OCI IAM에는 최종 사용자 경험을 저하하지 않고 위험을 감소시키는 상황 인식 적응형 보안 기능이 포함되어 있습니다. 적응형 보안 기능은 사용자의 장치, 네트워크, 위치, 과거 동작 등을 분석하여 사용자 세션별 위험 점수를 책정합니다. 관리자는 특정 응용 프로그램이나 특정 사용자 그룹별로 서로 다른 MFA 정책을 구성할 수 있습니다.

사용자, 그룹, 구획 및 정책에 대한 변경 사항이 디버깅 및 감사 목적으로 기록됩니까?

네. 기업의 감사 및 규제 준수에 대한 요구 사항을 지원하기 위해 모든 변경 내역은 보존되며, 추가 비용 없이 해당 기록을 사용할 수 있습니다.

OCI IAM 사용을 시작하려면 어떻게 해야 하나요?

OCI IAM은 추가 요금 없이 사용할 수 있는 기본 서비스입니다. 계정 내 첫 번째 사용자가 기본 관리자입니다. 모든 후속 사용자는 IAM 서비스를 통해 생성되며, 여기에서 지정된 클라우드 리소스와 상호 작용할 수 있는 권한을 해당 사용자에게 명시적으로 부여합니다.

콘솔, Rest API 또는 SDK를 사용하여 Oracle IAM에 액세스할 수 있습니다.

Oracle Cloud Infrastructure 사용자가 암호를 재설정하려면 어떻게 해야 합니까?

Oracle Cloud Infrastructure 암호를 재설정하려면 먼저 이메일 주소를 계정과 연결했는지 확인해야 합니다. Oracle Cloud Infrastructure 계정의 사용자 프로필 페이지를 방문하여 본인만 액세스할 수 있는 이메일 주소를 추가하십시오. 해당 주소를 계정에 등록하려고 하는지 확인하는 이메일을 받게 됩니다. 그런 다음 테넌트 관리자가 이를 비활성화지 않은 한 이메일 계정으로 암호를 재설정할 수 있습니다.

구획

구획은 어떤 문제를 해결하기 위해 설계되었나요?

구획은 계정 내에 포함된 안전한 논리 컨테이너로, 이를 사용하여 인프라 리소스(예: 컴퓨팅, 스토리지 및 네트워크)와 이러한 리소스에 대한 액세스 관리 정책 집합을 호스팅합니다. 구획을 사용하면 클라우드 리소스를 논리적으로 구성하여 다양한 사용 사례를 지원할 수 있습니다.

다음은 구획을 사용하여 수행할 수 있는 몇 가지 일반적인 방법입니다.

• 소프트웨어 개발 환경을 분리하여 관리를 간소화하십시오. 예를 들어 개발, 테스트 및 프로덕션에 별도의 구획을 두거나 파란색/녹색 배포를 지원하기 위해 별도의 구획을 둘 수 있습니다.
• 권한 관리를 간소화하십시오. 예를 들어 네트워킹 리소스(VCN, 서브넷, 인터넷 게이트웨이 등)에 별도의 구획을 생성한 다음, 네트워크 관리자만 해당 구획에 액세스하도록 허용할 수 있습니다.
• 개별 사업부의 사용량을 별도로 측정하여 해당 사업부에 클라우드 리소스 사용 요금을 올바르게 부과하십시오.
• 특정 사용자 집합이 볼 수 있는 리소스 집합을 최소화하십시오. 예를 들어 재무 팀에 특정 직원만 볼 수 있는 별도의 구획을 두고자 할 수 있습니다.

여러 가용성 도메인에 있는 리소스를 구획에 포함시킬 수 있습니까?

네. 구획은 가용성 도메인의 물리적 구성과는 다른 논리적 리소스 그룹화 방식입니다. 개별 구획은 가용성 도메인 전체에서 리소스를 포함할 수 있습니다.

구획을 사용하여 어떻게 액세스를 제어합니까?

모든 정책은 루트 구획 또는 하위 구획에 연결됩니다. 각 정책은 다음 기본 구문을 따르는 하나 이상의 정책문으로 구성됩니다.

구획 내 그룹 허용(Allow group to in compartment)

정책 설명을 통해 구획을 사용하여 권한 관리를 간소화할 수 있습니다. 예를 들어 그룹 HRAdministrator가 구획 HRCompartment에서 모든 리소스를 관리할 수 있는 정책을 작성할 수 있습니다.

구획을 삭제할 수 있습니까?

예. 구획을 삭제할 수 있습니다.

전체 구획 트리와 여기에 포함된 리소스를 이동할 수 있습니까?

예. 전체 구획 트리와 여기에 포함된 리소스를 다른 상위 구획으로 이동할 수 있습니다.

컴퓨팅 인스턴스 또는 블록 볼륨과 같은 리소스를 한 구획에서 다른 구획으로 이동할 수 있습니까?

예. 리소스를 한 구획에서 다른 구획으로 이동할 수 있습니다.

구획 계층 구조를 생성할 수 있습니까?

예. 구획을 중첩하여 구획 계층 구조를 생성할 수 있습니다. 계층적 구획 또는 중첩된 구획을 사용하면 시스템 관리자가 리소스를 구성하고, 하위 수준 관리자가 동일한 작업을 수행할 수 있게 하면서도, 정책을 통해 완전한 가시성 및 제어를 계속 유지할 수 있습니다.

구획을 몇 단계나 중첩할 수 있습니까?

중첩된 구획의 최대 깊이는 6단계입니다.

상위 수준 구획에 있는 정책이 하위 구획에 적용됩니까?

예. 상위 수준 구획에 있는 정책은 하위 구획에 상속됩니다.

구획별 비용 및 사용량을 추적할 수 있습니까?

예. My Services에서 비용과 사용량을 구획별로 추적할 수 있습니다.

루트 구획이란 무엇입니까?

Oracle Cloud Infrastructure는 각 계정에 대해 루트 구획이라고도 하는 상위 수준 구획을 자동으로 생성합니다. 파일 시스템의 루트 폴더와 마찬가지로 루트 구획은 몇 가지 특징을 제외하고는 하위 구획과 똑같이 동작합니다.

• 권한은 계층적이므로 루트 구획에 설정된 그룹 권한이 모든 하위 구획에 적용됩니다. 예를 들어 NetworkAdmins 그룹에 루트 구획에서 VCN(가상 클라우드 네트워크)을 관리할 수 있는 권한이 부여된 경우 해당 그룹은 모든 구획에서 VCN을 관리할 수 있습니다.
• 현재 모든 사용자와 그룹은 루트 구획 내부에 생성됩니다. 정책을 사용하여 특정 하위 구획에만 액세스할 수 있는 권한을 부여할 수 있습니다.

알림: 현재 다른 구획이 아닌 루트 구획 내에서만 추가 구획을 생성할 수 있습니다.

루트 구획과 하위 구획에서 리소스를 언제 생성해야 합니까?

일반적으로 루트 구획이 아닌 구획에서 리소스를 생성해야 합니다. 구획 및 리소스를 생성하기 전에 구획 계층 구조를 설계하는 것이 가장 좋습니다.

사용자

Oracle Cloud Infrastructure Console 사용자에게 가능한 활동은 무엇인가요?

'사용자'란 OCI IAM에 대해 성공적으로 인증할 수 있으며 계정 내에서 클라우드 리소스를 사용하거나 관리할 수 있는 충분한 권한이 있는 인물을 의미합니다. 관리자는 계정 내에 하나 이상의 사용자를 생성한 뒤 그룹에 할당하여 특정 구획에 있는 리소스에 대한 권한을 부여할 수 있습니다.

사용자를 생성하고 관리할 수 있는 대상은 누구입니까?

각 계정은 단일 사용자(기본 관리자) 및 기본 관리자를 구성원으로 하는 단일 그룹(Administrators)으로 프로비저닝됩니다. 이 그룹(관리자)은 귀사의 계정에서 모든 권한을 가집니다. 이 특수 사용자(기본 관리자)가 추가 사용자를 생성하거나 다른 사용자에게 새 사용자를 생성할 수 있는 권한을 부여해야 합니다.

새 사용자는 생성 직후 어떤 액세스 권한을 갖습니까?

기본적으로 새 사용자는 계정 내에서 리소스 또는 서비스를 사용할 수 있는 권한이 없습니다. 모든 권한을 명시적으로 부여해야 합니다. 이러한 접근 방식을 사용하면 각 사용자에게 해당 특정 사용자에게 필요한 액세스 권한만 부여하는 최소 권한의 보안 원칙을 준수할 수 있습니다. 사용자를 기존 그룹에 명시적으로 추가하거나 새 그룹을 생성한 다음, 정책을 기반으로 해당 그룹에 적절한 권한을 할당해야 합니다.

사용자 액세스를 활성화 및 비활성화할 수 있습니까?

관리자는 사용자를 비활성화하거나 잠금으로써 해당 사용자의 액세스를 일시적으로 비활성화할 수 있습니다. 또한 사용자의 암호를 재설정하거나 키를 제거할 수도 있습니다.

암호에 만료 기간을 설정할 수 있나요? 자격 증명을 교체하려면 어떻게 해야 합니까?

예. 비밀번호 정책을 사용하여 비밀번호의 만료 기간을 설정할 수 있습니다. 또한 REST API 및 SDK를 통해 암호 재설정, 키 변경, 사용자 및 그룹 멤버십 편집 등을 자동화할 수도 있습니다.

정책

정책이란 무엇입니까?

정책은 사용자 그룹에 특정 권한을 부여하는 세부 정책 설명으로 구성된 문서입니다. 이해하기 쉬운, SQL과 유사한 구문으로 작성됩니다. 예시 정책으로 다음과 같은 적용이 가능합니다.

• 시스템 관리자는 베어 메탈 컴퓨팅 인스턴스를 "종료"하거나 "재부팅"할 수 있습니다.
• 네트워크 관리자는 모든 네트워크 관련 인프라 리소스를 완전히 관리할 수 있습니다.
• IT 관리자는 사용자를 생성하고 그룹 구성원을 편집할 수 있습니다.

정책을 사용하면 한 그룹이 특정 구획에 있는 특정 유형의 리소스를 사용하여 특정 방식으로 작업할 수 있습니다. 선택적으로, 정책에는 정책 설명을 추가로 제한하는 조건절("where ...")이 포함될 수 있습니다. 정책은 다음과 같은 구문을 준수합니다.

[where] 구획 내 그룹 허용(Allow group to in compartment [where])

예를 들어 다음은 컴퓨팅 인스턴스를 사용할 수 있는 권한을 부여하는 정책 설명입니다.

그룹 개발자가 구획 ProjectA에서 인스턴스를 사용하도록 허용

• "group_name"은 권한이 부여되는 그룹 이름입니다.
• "verb"는 특정 리소스에 대해 수행할 수 있는 작업입니다(예: 검사, 읽기, 사용 또는 관리).
• "resource-type"은 권한이 부여되는 클라우드 리소스입니다. resource-types 예제에는 인스턴스, 볼륨, 루트 테이블이 포함되어 있습니다.
• "compartment_name"은 리소스가 구성되는 구획 이름입니다.
• "conditions"는 정책 설명 범위를 좁히는 추가 사양입니다. 관련 예제에는 다음이 포함되어 있습니다. "where request.user.id=target.user.id" 또는 "where target.group_name != Administrators".

자세한 내용은 Oracle Cloud Infrastructure(OCI) 설명서의 OCI IAM 섹션을 참조해 주세요.

루트 구획에 대한 정책이 하위 구획에 상속됩니까?

네. 루트 구획에서 권한을 부여하는 정책은 모든 하위 구획에 대해 동일한 권한을 자동으로 부여합니다. 예를 들어 다음과 같은 정책은 그룹 "InstanceAdmins"에 있는 모든 사용자에게 루트 구획과 모든 하위 구획에서 인스턴스를 관리할 수 있는 권한을 부여합니다.

그룹 InstanceAdmins가 테넌시에서 인스턴스를 관리하도록 허용

정책을 특정 구획으로 제한할 수 있습니까?

네. 각 정책은 구획에 "연결"됩니다. 연결 위치는 정책을 수정하거나 삭제할 수 있는 대상을 제어합니다. 정책을 루트 구획에 연결하면 루트 구획에서 정책을 관리할 수 있는 액세스 권한이 있는 사용자라면 누구나 정책을 변경하거나 삭제할 수 있습니다. 대신에 정책을 구획에 연결하면 해당 구획에서 정책을 관리할 수 있는 액세스 권한이 있는 사용자라면 누구나 정책을 변경하거나 삭제할 수 있습니다. 즉, 실질적으로 계정에 있는 정책을 관리할 수 있는 광범위한 액세스 권한을 부여하지 않고도 고유한 구획 정책을 관리할 수 있는 액세스 권한을 구획 관리자(예: 구획에서 "모든 리소스 관리"에 대한 액세스 권한이 있는 그룹)에게 손쉽게 부여할 수 있습니다.

정책 설명 작성에 대한 자세한 내용은 어디에서 확인할 수 있습니까?

정책 및 정책 설명에 대한 자세한 내용은 Oracle Cloud Infrastructure 설명서의 "정책 시작하기" 및 "일반 정책"을 참조하십시오.

IAM 거부 정책

OCI ID 및 액세스 관리 거부 정책 FAQ

이 FAQ에서는 Oracle Cloud Infrastructure(OCI) Identity and Access Management 거부 정책에 대해 설명합니다. 이를 참고하여 정책 관리 권한이 있는 사용자는 작업을 명시적으로 차단하고, 보안을 강화하고, OCI 테넌시의 액세스 제어를 간소화할 수 있습니다. 자세한 내용은 OCI Identity and Access Management 설명서를 참고해 주세요.

IAM Deny 시작하기

OCI에서 IAM 거부 기능을 사용으로 설정하려면 어떻게 해야 하나요?

IAM 거부는 OCI 콘솔, 정책, 작업, 정책 설정 순으로 이동하여 테넌시 관리자가 명시적으로 사용으로 설정해야 하는 옵트인 기능입니다. 일반 사용자나 정책 작성자가 사용을 활성화할 수 없습니다. 이 기능은 한 번 활성화 되면 영구적으로 테넌시 IAM 프레임워크의 일부가 되며, UI를 통해 비활성화할 수 없습니다. 그러나 거부 정책을 쓸 수 있는 테넌시 관리자의 경우, 기본 관리자 그룹 외의 사용자는 아무도 거부 정책을 생성하거나 수정하지 못하도록 차단하는 루트 레벨 거부 정책을 작성하여 거부 정책 사용을 효과적으로 제어할 수 있습니다. 예제: Deny any-user to manage policies in tenancy where target.policy.type='DENY'

IAM 거부가 사용으로 설정된 경우

• OCI는 안전한 사용을 위해 루트 구획에서 기본 거부 정책을 자동으로 시드합니다.
• 기본 관리자 그룹 및 IAM 거부를 사용으로 설정한 테넌시 관리자만 거부 정책을 구성하고 관리할 수 있는 권한을 보유합니다.
• 그런 다음 테넌시 관리자는 승인된 사용자(예: 뱅킹, 투자 및 규제준수 구획의 관리자 그룹)가 OCI 콘솔에 거부 정책을 쓸 수 있도록 기본 거부 정책을 업데이트할 수 있습니다.

OCI Identity and Access Management 거부 명령문이란 무엇인가요?

OCI Identity and Access Management deny 문을 사용하면 OCI 테넌시에서 특정 작업을 차단하기 위한 명시적 거부 정책을 작성할 수 있으며, OCI Identity and Access Management를 보완하여 정확한 액세스 제어를 위한 명령문을 제공할 수 있습니다. 예를 들어, Deny any-user to inspect all-resources in tenancy where request.service='streaming'를 사용하면 테넌시 전체에서 OCI Streaming 서비스에 대한 모든 액세스를 방지하는 보호 한계선을 설정하는 동시에 allow 문을 통해 다른 권한을 허용할 수 있습니다.

IAM 거부 정책의 제한은 무엇인가요?

IAM 거부 정책은 허용 정책과 동일한 제한을 공유합니다. 테넌시에는 최대 100개의 IAM 정책 객체가 포함될 수 있으며, 각 객체에는 최대 50개의 정책 문(거부 또는 허용)이 포함되지만, 테넌시의 모든 객체에 대한 총 정책 문 수는 100개로 제한됩니다.

IAM 거부 정책에서 지원되는 메타 동사는 새 메타 동사인가요, 기존 메타 동사인가요?

IAM 거부 정책은 관리, 사용, 읽기 및 검사와 같은 기존 메타 동사를 사용합니다. 새로운 메타 동사는 도입되지 않습니다. 권한을 추가로 부여하는 allow 문(예: 모든 하위 권한 포함)과 달리 deny 문은 권한을 제하고 지정된 권한 및 계층의 상위 레벨만 차단합니다.

예를 들어, 컴파트먼트 운용에서 인스턴스를 관리하기 위한 Deny group DevOps 정책은 관리 권한만 차단하므로 DevOps는 사용, 읽기 및 검사 작업을 수행할 수 있습니다. 그러나 기본 레벨 권한이기 때문에, 검사를 거부하면 모든 권한이 차단됩니다.

정책 생성 및 관리

OCI 콘솔에서 거부 정책은 어디에서 작성할 수 있나요?

거부 정책은 허용 정책과 동일한 OCI 콘솔 인터페이스에 생성됩니다. ID 및 보안(Identity & Security), 정책(Policies) 순으로 이동하여 컴파트먼트를 선택하고 정책 편집기를 사용하여 거부 키워드를 허용과 함께 추가합니다. 프로세스에는 별도의 인터페이스가 필요하지 않습니다.

거부 정책에 대한 별도의 정책 객체가 있나요?

아니요. 거부 정책은 허용 정책과 동일한 정책 객체를 사용합니다. 둘 다 동일한 정책 객체 내에서 관리되므로 관리가 간편합니다.

단일 IAM 정책 객체에 거부 및 허용 명령문을 포함할 수 있나요?

예. 유연한 액세스 제어를 위해 거부 및 허용 명령문을 하나의 정책 객체에 결합할 수 있습니다.

예를 들어, 아래와 같이 단일 정책에는 allow 및 deny 문이 포함될 수 있습니다.

Deny group Interns to use instance in compartment Finance
Allow group Admins to manage all-resources in compartment Finance

이러한 정책을 통해 관리자는 재무 컴파트먼트의 모든 리소스를 관리하는 동시에 인턴이 인스턴스에 대한 쓰기 작업을 수행하지 못하도록 하여 액세스 제어를 간소화할 수 있습니다.

정책을 관리할 수 있는 사용자가 거부 정책을 작성하지 못하도록 하려면 어떻게 해야 하나요?

정책을 관리할 수 있는 정책 사용자가 거부 정책을 쓰지 못하도록 하려면 루트 레벨에서 거부 정책을 생성하여 거부 정책 생성을 차단합니다.

예제: Deny group PolicyAdmins to manage policies in tenancy where target.policy.type='DENY'

이 정책은 PolicyAdmins가 허용 정책을 관리할 수 있도록 허용하면서 거부 정책을 생성하거나 수정할 수 없도록 합니다. 기본 관리자 그룹은 면제된 상태로 유지되며 필요한 경우 거부 정책을 쓸 수 있습니다.

IAM 거부 정책을 사용하여 전체 OCI 서비스를 차단하려면 어떻게 해야 하나요?

전체 OCI 서비스를 차단하려면 request.service.name과 같은 조건을 사용하여 서비스의 리소스 또는 작업을 대상으로 하는 루트 컴파트먼트에 거부 정책을 생성합니다.

예를 들어, OCI Streaming 서비스 테넌시 전체를 차단하려면 다음과 같이 작성할 수 있습니다.

Deny any-user to inspect all-resources in tenancy where request.service.name='streaming'

이 정책은 OCI Streaming 서비스에 대한 모든 액세스를 방지하며, 이는 보건의료 같은 산업의 규제 준수에 유용합니다. 루트 컴파트먼트에 정책을 배치하여 모든 컴파트먼트에 정책을 적용하고 무분별한 정책 확산을 줄일 수 있습니다.

특정 리전의 리소스 관리를 거부하려면 어떻게 해야 하나요?

그룹이 특정 영역의 리소스를 관리하지 못하도록 하려면 request.region condition와 함께 거부 정책을 사용하면 됩니다.

예를 들어, 그룹이 특정 영역에서 읽기 전용 액세스 이외의 작업을 수행하지 못하도록 하려면 다음과 같은 거부 정책을 작성할 수 있습니다.

Deny group RegionalAdmins to use all-resources in tenancy where request.region='sa-saopaulo-1'

이 정책은 RegionalAdmins 그룹이 상파울루 지역의 리소스를 사용하지 못하도록 차단하지만 사용, 읽기 및 검사 권한을 허용합니다. 이는 금융 기관이 지역 데이터 레지던시 법률 준수를 준수할 때 유용하게 사용할 수 있습니다.

특정 구획의 컴퓨트 인스턴스에 대한 그룹 액세스를 거부하려면 어떻게 해야 하나요?

그룹이 특정 컴파트먼트의 컴퓨트 인스턴스에 액세스하지 못하도록 거부하려면 다음과 같이 작성할 수 있습니다.

Deny group DevTeam to inspect instance in compartment ProjectX

이 정책은 ProjectX 컴파트먼트의 컴퓨트 인스턴스에 대한 모든 권한(검사, 읽기, 사용, 관리)을 차단합니다. 예를 들어, 기술 회사가 이를 사용하면 DevTeam가 프로덕션 인스턴스에 액세스하지 못하도록 방지하고, 보안 강화를 위해 개발 및 프로덕션 환경을 격리할 수 있습니다.

특정 구획의 오브젝트 스토리지 관리에서 그룹을 거부하려면 어떻게 해야 하나요?

특정 컴파트먼트의 오브젝트 스토리지 리소스 관리에서 그룹을 거부하려면 다음과 같이 작성할 수 있습니다.

Deny group StorageUsers to inspect object-family in compartment DataLake

이 정책은 DataLake 컴파트먼트의 오브젝트 스토리지 리소스에 대한 모든 권한(검사, 읽기, 사용, 관리)을 차단합니다. 예를 들어, 보건의료 기업이 이를 적용하면 StorageUsers가 민감한 환자 데이터에 액세스하지 못하도록 방지하고, 개인정보 보호 규정 준수를 지원할 수 있습니다.

특정 리소스를 수정하거나 거부 정책을 쓸 수 없도록 하위 컴파트먼트의 정책을 관리할 수 있는 사용자에게 작업을 위임하려면 어떻게 해야 하나요?

하위 구획의 정책을 관리할 수 있는 사용자에게 작업을 안전하게 위임하려면 다음을 수행할 수 있습니다.

• 허용 정책을 사용하여 지정된 구획 또는 리소스에 대한 특정 권한을 부여합니다.
• 하위 컴파트먼트의 정책을 관리할 수 있는 사용자가 중단형 정책을 생성하지 못하도록 거부 정책 권한 부여를 제한합니다.
• 거부 정책을 사용하여 중요한 리소스에 대한 액세스를 차단합니다.

예를 들어, 네트워크 변경사항을 제한하고 정책 생성을 거부하면서 하위 컴파트먼트의 정책을 관리할 수 있는 사용자가 컴파트먼트의 컴퓨트 리소스를 관리할 수 있도록 허용하려면 다음 정책을 사용합니다.

Deny group ProjectAdmins to manage network-family in compartment ProjectX Deny group ProjectAdmins to manage policies in compartment ProjectXwhere target.policy.type='DENY'

Allow group ProjectAdmins to manage instance-family in compartment ProjectX

이러한 정책을 통해 ProjectAdmins는 ProjectX에서 인스턴스를 관리하고, 네트워크 수정을 차단하고, 거부 정책에 쓰지 못하도록 방지하여 보안 위임을 지원할 수 있습니다. 재무 조직이 이러한 접근 방식을 사용하면 하위 관리자가 네트워크 구성 및 정책 관리에 대한 엄격한 제어를 유지하면서 컴퓨트 리소스를 관리할 수 있도록 할 수 있습니다.

안전 및 복구 메커니즘

거부 정책은 정책을 허용하기 전에 평가되나요?

예. OCI Identiy and Access Management는 거부 첫 번째 평가 모델을 사용합니다. 여기서 거부 정책은 구획 계층 구조에서 정책을 허용하기 전에 평가됩니다. 요청이 거부 정책과 일치하면 허용 정책에 관계없이 액세스가 차단됩니다. 기본 관리자 그룹은 잠금 방지를 위해 거부 정책에서 제외됩니다.

예를 들어, 운용 컴파트먼트에 다음 정책이 존재할 수 있습니다.

Deny group Devs to manage instance-family in compartment Prod
Allow group Devs to manage all-resources in compartment Prod

거부 정책은 Devs가 인스턴스를 관리하지 못하도록 차단하지만, 기본 관리자는 여전히 인스턴스를 관리할 수 있습니다.

정책을 관리할 수 있는 사용자가 테넌시의 모든 사용자를 잠그는 거부 정책을 기록하면 어떻게 되나요?

기본 관리자 그룹은 거부 정책에서 제외되므로 기본 관리자 그룹원은 정책을 로그인, 확인 및 편집하여 Lockout을 해결할 수 있습니다. 이러한 보호 장치가 있어 테넌시 전체가 중단되는 것을 막을 수 있습니다.

예제: If Deny any-user to inspect all-resources in tenancy is applied, default admins group users can still log in and access the policy editor to remove or adjust it.

모든 사용자를 잠그는 테넌시 전체 거부 정책에서 복구하려면 어떻게 해야 하나요?

테넌시의 모든 리소스를 검사하는 Deny any-user와 같은 테넌시 전체 거부 정책은 모든 사용자 액세스를 차단하여 가동 중단을 야기할 수 있습니다. 복구하려면 다음과 같이 할 수 있습니다.

1. 기본 관리자 그룹의 멤버로 로그인합니다(거부 정책 제외).
2. OCI 콘솔에서 ID 및 보안(Identity & Security), 정책(Policies) 순으로 이동합니다.
3. 루트 컴파트먼트에서 문제가 있는 정책을 찾습니다.
4. 정책을 편집하거나 삭제합니다(예: Deny any-user to inspect all-resources in tenancy를 Deny group Interns로 변경하여 테넌시의 모든 리소스를 검사합니다).
5. 또는 다음 OCI 명령행 인터페이스를 사용합니다.: OCI iam policy update --policy-id --statements '["Deny group Interns to inspect all-resources in tenancy"]

예를 들어, 하위 컴파트먼트에서 정책을 관리할 수 있는 사용자가 실수로 Deny any-user를 적용하여 테넌시의 모든 리소스를 검사하는 경우 기본 관리자 그룹 사용자는 로그인하여 Guest 그룹만 대상으로 수정할 수 있으므로 이후 잠금이 방지됩니다. 이러한 문제를 방지하려면 정책을 철저히 테스트하고 거부 정책 저작권을 제한하는 것이 좋습니다.

권한 효과

'관리' 권한을 거부하면 어떻게 되나요?

관리를 거부하면 관리 권한만 차단되며, 사용, 읽기 및 검사 권한은 변하지 않습니다.

예제: Deny group DevOps to manage instance in compartment Production prevents DevOps from managing instances but allows them to use, read, or inspect them.

'사용' 권한을 거부하면 어떻게 되나요?

사용 권한을 거부하면, 사용 및 관리 권한은 차단되지만 읽기 및 검사는 계속 허용됩니다.

예제: Deny group Testers to use bucket in compartment QA stops Testers from using or managing buckets but permits reading or inspecting them.

'읽기' 권한을 거부하면 어떻게 되나?

읽기 권한을 거부하면 읽기, 사용, 관리 권한은 차단되지만 검사는 계속 허용됩니다.

예제: Deny group Auditors to read logs in compartment Logging prevents Auditors from reading, using, or managing logs but allows inspection.

'검사' 권한을 거부하면 어떻게 되나요?

검사는 기본 레벨 권한이기 때문에, 검사를 거부하면 모든 권한(검사, 읽기, 사용, 관리)이 차단됩니다.

예제: Deny group Viewers to inspect instance in compartment Public completely blocks Viewers from accessing instances.

고급 사용 사례 및 문제 해결

거부 정책이 의도한 대로 작동하는지 확인하기 위한 모니터링은 어떻게 해야 하나요?

OCI 감사 로그를 검토하여 거부 정책으로 차단된 작업을 추적할 수 있습니다. 테넌시의 클라우드 셸 검사 시 any-user 거부와 같은 정책으로 인해 문제가 발생하는 경우, 테넌시의 클라우드 셸을 검사하도록 거부 그룹 인턴으로 세분화합니다. 정책 변경 사항에 대한 경보를 설정하여 사전 예방적 상태를 유지합니다.

예제: Monitor logs to adjust Deny group Drivers to manage instance-family in compartment Fleet if it blocks legitimate tasks.

거부 정책에서 흔히 하는 실수는 무엇인가요?

OCI의 첫 번째 거부 모델은 허용 정책보다 거부 정책을 우선시하기 때문에, 정책이 지나치게 광범위할 경우 가동 중단이 발생할 수 있습니다. 흔한 실수로는 테넌시 차원이나 구획 차원에 잠금을 적용하는 것, 지나치게 광범위한 태그 기반 조건을 사용하는 것 등이 있습니다.

예를 들어, Deny any-user to inspect all-resources in tenancy can block all access와 같은 정책은 모든 액세스를 차단하여 테넌시 전체를 잠가버릴 수 있습니다. 대신 다음과 같은 특정한 정책을 사용해 보세요.

Deny group Interns to inspect all-resources in compartment Public

이렇게 하면 의도치 않은 가동 중단을 방지할 수 있고, 인턴 그룹에 대한 액세스만 제한할 수 있습니다. 기술 회사가 이러한 접근 방식을 사용하여 다른 사용자의 기능은 유지하면서도 고객 액세스를 제한할 수 있습니다. 문제를 방지하려면 샌드박스 환경에서 정책을 테스트하고, 단순하게 유지하고, 정책 거부 저작을 제한해 보세요.

교차 테넌시 사용 사례에 대한 거부 명령문이 지원되나요?

예. deny 문은 교차 테넌시 시나리오를 지원합니다. 두 가지 모두 충족되어야 하는 endorse/admit 쌍과는 달리, deny endorse 또는 deny admit 문 하나만으로 교차 테넌시 요청을 차단할 수 있습니다.

다음은 소스 테넌시의 예제입니다.

Endorse group Devs to use object-family in tenancy PartnerTenancy Deny endorse group Devs to manage object-family in tenancy PartnerTenancy

이를 통해 개발자는 PartnerTenancy에서 객체 스토리지를 사용할 수 있지만 관리 작업을 차단할 수 있습니다. 파트너 조직이 이를 사용하면 리소스에 대한 제어를 유지하면서 데이터 공유를 사용으로 설정할 수 있습니다.

거부 정책은 OCI Zero Trust Packet Routing과 어떻게 상호작용을 하나요?

OCI Zero Trust Packet Routing은 Open Systems Interconnection 모델의 계층 4(네트워크 레벨)에서 작동하며, IAM 거부 정책은 계층 7(애플리케이션 레벨)에서 액세스를 강제 적용합니다. OCI Zero Trust Packet Routing에서 통신을 허용하는 경우, IAM 거부 정책은 여전히 작업을 차단할 수 있습니다.

예:

• OCI 제로 트러스트 패킷 경로 지정 정책: VCN web:vcn의 dynamic-group FrontEnd이 VCN vcn:server의 backend:server-instance에 접속하도록 허용하면 네트워크 트래픽이 허용됩니다.
• IAM 정책: OCI Zero Trust Packet Routing 허용량이 있더라도 동적 그룹 FrontEnd을 거부하여 ProjectA 컴파트먼트에서 instance-family를 관리하지 않습니다.

OCI Zero Trust Packet Routing 및 IAM 정책은 IAM을 최종 게이트키퍼로 사용하여 순차적으로 평가됩니다.

시스템 정의 정책은 거부 정책과 어떻게 상호작용을 하나요?

표준 시스템 정책은 항상 사용자 정의 거부 정책을 무효화하고, 필수 서비스 기능(예제: Allow any-user to read domains in tenancy where target.domain.id='request.domain.id')을 보장합니다.

예제: A deny policy such as Deny group Users to read domains in tenancy won’t block a standard system policy allowing domain access.

거부 정책은 허용 정책과 다르게 평가되나요?

OCI Identity and Access Management는 첫번째 거부 평가 모델을 사용합니다. 여기서 거부 정책은 컴파트먼트 계층에서 정책을 허용하기 전에 평가됩니다. 요청이 거부 정책과 일치하면 허용 정책에 관계없이 액세스가 차단됩니다. 시스템 정의 정책은 사용자 정의 거부를 무효화할 수 있습니다(질문 27 참조). 기본 관리자 그룹은 거부 정책에서 제외되므로 잠금 중 정책을 관리할 수 있습니다.

예제: If Deny group Users to manage instance-family in compartment Prod exists alongside Allow group Users to manage all-resources in compartment Prod, the deny policy blocks instance management.

IAM 거부가 Oracle ID 도메인 관리 롤(예: ID 도메인 관리자, 보안 관리자 및 사용자 관리자)을 무효화하나요?

현재 릴리스에서 IAM 거부 정책은 Oracle Identity Cloud Service 관리 롤(예: ID 도메인 관리자, 보안 관리자 및 사용자 관리자)을 무효화하지 않습니다. 이는 제한 사항입니다. 다음 번 릴리스에서는 일관된 액세스 제어를 위해 IAM 거부가 Oracle Identity Cloud Service 관리 롤보다 우선합니다.

새 OCI 프라이빗 서비스 액세스를 통해서만 서비스에 액세스할 수 있도록 IAM Deny를 사용하려면 어떻게 해야 하나요?

OCI 프라이빗 서비스 액세스를 사용하면 퍼블릭 인터넷이 아닌 프라이빗 네트워크 경로를 통해 Oracle 서비스에 액세스할 수 있습니다. OCI 프라이빗 서비스 액세스는 규정 준수, 성능 또는 보안상의 이유로 워크로드와 Oracle 서비스 간의 프라이빗 연결을 원하는 고객을 위해 설계되었습니다.

OCI Private Service Access를 사용하여 서비스(예: OCI Object Storage 또는 OCI Streaming)에 안전하게 액세스하는 경우 모든 액세스가 OCI Private Service Access를 거쳐야 하도록 강제할 수 있습니다. IAM 거부를 사용하면 허용 정책이 존재하더라도 서비스에 대한 모든 비OCI 프라이빗 서비스 액세스 트래픽을 명시적으로 차단할 수 있습니다.

예를 들어 OCI 프라이빗 서비스 액세스를 통해서만 OCI 객체 스토리지에 대한 액세스를 허용하려면 다음과 같이 작성할 수 있습니다.

Deny any-user to access object-family in tenancy where any {not request.gateway.id, request.gateway.type !='privateserviceaccess'}

이 정책은 트래픽이 OCI 프라이빗 서비스 액세스 끝점을 통해 경로 지정되지 않는 한 사용자가 OCI 오브젝트 스토리지에 액세스하지 못하도록 합니다. 중요한 데이터에 대한 OCI 프라이빗 서비스 액세스 설정을 구성하고 의도하지 않은 퍼블릭 경로를 통한 액세스 위험을 제거하려는 경우 특히 유용합니다.

OCI Identity and Access Management 거부 정책과 Oracle Security Zones의 차이점은 무엇이며, 언제 사용해야 하나요?

OCI는 안전하지 않은 작업을 방지하여 테넌시를 보호하기 위해 IAM 거부 정책 및 Oracle Security Zones을 제공합니다. 둘 다 보안을 강화하지만 작동 방식과 유연성이 다릅니다.

• 유사성: IAM은 정책을 거부하고 Oracle Security Zones은 리소스를 보호하고 OCI 테넌시에서 보안 모범 사례를 적용하기 위해 특정 작업을 차단합니다.
• 주요 차이점
  • IAM 거부 정책: 사용자 ID, 리소스 유형, IP 주소 또는 태그와 같은 조건에 따라 작업을 차단하는 사용자 정의 정책을 생성합니다. 이러한 정책은 보호 조치 역할을 합니다. 다음 릴리스부터는 이러한 정책이 모든 IAM 정책보다 우선합니다. 예를 들어, 리소스에 특정 태그(예: environment:production)가 있는 경우 특정 사용자 그룹이 중요한 리소스를 삭제하지 못하도록 차단할 수 있습니다.
  • Oracle Security Zones: 사전 정의된 보안 규칙을 구획 또는 전체 테넌시에 적용합니다. 사용으로 설정된 경우 Oracle Security Zones은 공용 서브넷을 방지하거나 암호화를 사용 안함으로 설정하는 등 일부 OCI 서비스 세트에 대한 제한을 자동으로 적용합니다. 정책을 작성하실 필요는 없습니다. 규칙이 내장되어 있으며 리소스 설정이 자동으로 확인되기 때문입니다.
• 활용 시기
  • 정의된 조건에 따라 특정 사용자나 작업을 차단하는 등, 사용자 정의 대상 제한에 IAM 거부 정책을 사용합니다.
  • Oracle Security Zones을 사용하면 즉시 사용 가능한 자동 보안 규칙을 통해 최소한의 설정으로 모범 사례를 적용할 수 있습니다.
  • 강력한 보호를 위해 두 가지를 결합할 수 있습니다. 광범위한 기준선 가드레일에 대해 Oracle Security Zones을 사용으로 설정하고 특정 맞춤형 제어에 대한 IAM 거부 정책을 추가합니다.

OCI Identity and Access Management 거부 정책 도움말 보기

추가 지원이 필요하면 OCI Identity and Access Management 문서를 참조하거나 OCI 계정 팀에 문의해 주세요.

그룹

그룹이란 무엇입니까?

그룹은 계정 내에서 특정 리소스를 사용하거나 관리할 수 있는 유사한 액세스 권한이 필요한 사용자 모음입니다. 사용자는 여러 그룹에 있을 수 있습니다. 권한은 부가적입니다. 예를 들어 한 그룹의 구성원 자격을 기반으로 사용자가 컴퓨팅 인스턴스를 사용할 수 있고 두 번째 그룹의 구성원 자격을 기반으로 해당 사용자가 블록 볼륨을 관리할 수 있는 경우 이 사용자는 인스턴스 및 블록 볼륨을 모두 관리할 수 있습니다.

관리자는 특정 구획이나 계정에 관계없이 필요한 액세스 권한을 보유한 그룹(개별 사용자 아님)을 지정하는 정책을 작성합니다. 그런 다음 관리자는 사용자를 적절한 그룹에 추가합니다.

관리자를 여러 명 둘 수 있습니까?

네. 귀사의 계정은 루트 구획 내 관리자 그룹에 속하는 단일 기본 관리자에게 프로비저닝됩니다. 이 그룹은 사용자, 그룹, 정책 및 구획을 포함한 계정 내 모든 Oracle Cloud Infrastructure 리소스를 비롯하여 모든 구획 내 모든 다른 클라우드 인프라 리소스를 생성하고 관리할 수 있는 모든 권한을 보유합니다. 새 사용자를 이 관리자 그룹에 추가할 수 있습니다.

특징

OCI IAM은 암호 만료 관련 요구 사항을 어떻게 해결하나요?

비밀번호 정책을 통해 비밀번호 만료 기간을 설정할 수 있습니다. 기본 암호 정책은 모든 암호를 120일 후에 만료되도록 설정합니다. 이는 변경 가능하며 하위 사용자 집합별로 다양한 정책을 적용할 수 있습니다.

컴퓨트 인스턴스에 사용자 자격 증명을 포함하지 않고 작업을 실행하려면 어떻게 해야 하나요?

동적 리소스 그룹을 사용하여 대상 그룹에 일련의 컴퓨트 리소스를 지정합니다. 이후 정책을 통해 해당 그룹 권한을 할당할 수 있습니다. 이러한 방식으로 컴퓨팅 인스턴스 스크립트에 인증서를 포함시키지 않고도 안전한 방식으로 다른 OCI 리소스에 액세스할 수 있습니다.

페더레이션

Oracle Cloud Infrastructure의 ID 페더레이션이란 무엇입니까?

ID 페더레이션은 Oracle Cloud Infrastructure 테넌시에 대한 사용자 관리를 ID 공급자 또는 IdP라고 하는 다른 엔터티에 위임하는 메커니즘입니다. 새 사용자 집합을 생성하고 유지 관리하는 대신 사용하려는 기존 ID 시스템이 있는 회사에 유용합니다. 페더레이션은 Oracle Cloud Infrastructure와 페더레이션 트러스트라고도 하는 IdP 간에 한 번의 구성을 거쳐야 합니다.

페더레이션 사용자란 무엇입니까?

페더레이션 사용자(외부 ID)는 Oracle Cloud Infrastructure 외부(예: 회사 디렉터리)에서 관리하지만 Oracle Cloud Infrastructure 계정에 대한 액세스 권한을 부여받는 사용자입니다. Oracle Cloud Infrastructure 계정에서 생성되고 유지 관리되는 Oracle Cloud Infrastructure 사용자와는 다릅니다.

페더레이션 사용자가 Oracle Cloud Infrastructure 콘솔에 액세스할 수 있습니까?

네. 페더레이션 사용자는 Oracle Cloud Infrastructure 콘솔에 액세스할 수 있습니다.

페더레이션 사용자가 Oracle Cloud Infrastructure SDK 및 CLI에 액세스할 수 있습니까?

네. 페더레이션 사용자는 Oracle Cloud Infrastructure SDK 및 CLI에 액세스할 수 있습니다.

콘솔에서 Oracle Cloud Infrastructure 사용자가 수행할 수 있는 작업 중 페더레이션 사용자가 수행할 수 없는 작업에는 무엇이 있습니까?

페더레이션 사용자는 Oracle Cloud Infrastructure 콘솔에서 암호를 변경하거나 재설정할 수 없습니다.

페더레이션 사용자가 콘솔에 로그인하여 수행할 수 있는 작업을 제어하려면 어떻게 해야 합니까?

동일한 Oracle Cloud Infrastructure 정책을 사용하여 기본 사용자를 관리하는 데 사용하는 페더레이션 사용자를 관리할 수 있습니다. ID 공급자의 역할 및 그룹을 Oracle Cloud Infrastructure에 있는 그룹에 매핑합니다. 페더레이션 사용자가 로그인하면 Oracle Cloud Infrastructure 콘솔이 기본 사용자와 마찬가지로 Oracle Cloud Infrastructure 그룹 구성원 자격을 기반으로 정책을 적용합니다. 예는 설명서를 참조하십시오.

ID 공급자의 단일 역할 또는 그룹을 여러 Oracle Cloud Infrastructure 그룹에 매핑할 수 있습니다. 또한 ID 공급자의 여러 역할 또는 그룹을 단일 Oracle Cloud Infrastructure 그룹에 매핑할 수도 있습니다.

Oracle Cloud Infrastructure 콘솔에 대한 액세스 권한을 부여할 수 있는 페더레이션 사용자 수는 몇 명입니까?

콘솔에 액세스할 수 있는 페더레이션 사용자 수에는 제한이 없습니다.

어떤 ID 공급자를 지원합니까?

OCI IAM은 SAML 2.0, Open ID Connect 또는 OAuth와 호환되는 ID 제공자를 지원합니다. Oracle Access Manager, Microsoft Active Directory Federation Services(AD FS), Okta 등의 주요 솔루션 및 기타 여러 솔루션을 지원하고 있습니다.

다중 인증

다중 인증(MFA)이란 무엇이고, 왜 중요한가요?

과거에는 사용자 아이디 및 비밀번호라는 간단한 수단을 통해 계정을 보호하였습니다. 하지만 비밀번호는 잊어버리기 쉽고, 네트워크 스니핑, 피싱, 무차별 암호 대입 공격 등의 일반적 사이버 공격 기술을 통해 비교적 간단히 유출될 수 있습니다. 또한 귀하의 인증 정보를 입수한 인물은 귀하의 모든 계정 및 리소스에 액세스할 수 있습니다.

다중 인증(MFA)은 애플리케이션 사용자가 실제로 등록된 사용자임을 확인하는 절차를 강화함으로써 계정 도용 위험 감소에 기여하는, 널리 사용되고 있는 보안 기능입니다. MFA는 사용자에게 2개 이상의 인증 요소를 요구합니다. 인증 요소는 크게 3가지 범주로 나누어집니다. 비밀번호 및 PIN 등 사용자가 '알고' 있는 요소, 보안 토큰 및 휴대폰 등 사용자가 '가지고' 있는 요소, 지문 및 얼굴 스캔 등을 통해 수집하는 생체 인식 데이터 등 사용자 '자신'과 관련된 요소 등이 그것입니다. MFA가 적용된 경우, 비밀번호를 탈취당하더라도 공격자가 MFA가 요구하는 추가 증거를 함께 제공하지 못하는 한 본인 인증은 이루어지지 않습니다. 따라서 사용자 계정에 대한 무단 액세스, 민감한 정보 유출, 부적절한 작업 수행 등을 방지할 수 있습니다. 또한 MFA는 각종 규제 관련 요구 사항, National Institute of Standards and Technology(NIST) 및 기타 유관 기관들이 제정하는 산업 표준 등을 준수하는 데에도 기여합니다.

MFA는 누가 사용해야 하나요?

Oracle은 모든 사용자가 MFA를 사용할 것을 권장합니다. 적어도 OCI 리소스의 작성 및 관리 기능 등을 갖춘 관리자 권한이 부여된 사용자 계정에는 MFA를 적용해야 합니다. 민감한 정보를 호스팅하거나 고위험 작업을 허용하는 모든 애플리케이션에 대한 액세스에도 MFA를 적용해야 합니다.

관리자가 MFA를 활성화한 이후 최종 사용자 경험은 어떻게 변화하나요?

관리자가 MFA를 처음으로 활성화하면, 사용자들의 로그인 화면에 MFA 등록을 유도하는 메시지가 표시됩니다. 초기 등록을 마친 사용자들은 이후 재방문시마다 로그인 과정에서 MFA 인증 요청에 응해야 합니다. 관리자가 신뢰하는 기기(Trusted Devices) 등록 기능을 사용하도록 설정했다면, 사용자들에게는 향후 동일한 기기로 재방문하는 경우 MFA 요청을 생략할 수 있는 '신뢰하는 기기로 등록' 옵션이 함께 표시됩니다.

보다 자세한 내용은 다음 지침을 참조해 주세요.

• OCI Identity and Access Management ID 도메인에서의 2단계 인증 관리
• Oracle Identity Cloud Service에서의 2단계 인증 관리

MFA는 모든 상황에 필수적으로 적용해야 하나요?

아니요. MFA는 모든 상황에 엄격히 적용되는 필수 사항은 아닙니다. 예를 들어 퍼블릭 웹사이트에 대한 액세스 권한의 경우 일반적으로는 인증을 요구하지 않습니다. 사용자가 제품을 구매할 때 판매자가 어느 계정에 대금을 청구하고 어디로 제품을 배송할지 파악하기 위한 사인인의 경우 사용자 이름 및 비밀번호만으로 충분할 수 있습니다. 그러나 동일한 사용자가 결제 방법 또는 배송 주소를 변경하거나, 해당하는 애플리케이션이 귀사에 영향을 미칠 수 있는 작업을 허용하는 경우에는 MFA를 적용하는 것이 좋습니다.

Oracle은 모든 클라우드 및 애플리케이션 관리자 계정에 MFA를 적용할 것을 강력하게 권장합니다. 궁극적으로는 귀사의 내부 보안 정책 및 위험 평가 내역을 기반으로 MFA 적용 여부를 판단해야 합니다. 모범 사례는 MFA를 일단 필수로 설정하고, MFA를 선택적으로 적용하고자 하는 애플리케이션의 경우에 한해 별도로 경영진의 승인을 거치도록 하는 정책입니다.

우리 회사에서 사용 가능한 MFA 요소에는 어떤 것들이 있나요? MFA 관련 비용이 발생하나요?

사용 가능한 요소 및 비용을 완전히 이해하기 위해서는 먼저 보유 중인 OCI 테넌시 유형을 파악해야 합니다. 귀사의 테넌시 내 OCI Identity and Access Management(IAM)에 ID 도메인이 포함되어 있는지 여부를 확인하고자 하시는 경우 본 설명서를 참조해 주세요.

• 귀사의 테넌시 내 OCI IAM에 ID 도메인이 포함되어 있는 경우, 모든 ID 도메인 유형은 추가 비용 없이 MFA를 지원합니다. 무료(Free) 유형의 ID 도메인의 경우 SMS를 인증 요소로 사용할 수는 없지만, 다른 인증 요소들을 사용 가능합니다. 자세한 내용은 ID 도메인이 포함된 OCI IAM 관련 설명서를 참조해 주세요.
• 귀사의 테넌시 내 OCI IAM에 ID 도메인이 포함되지 않은 경우, 두 가지 MFA 옵션을 활용할 수 있습니다.
  • OCI IAM 서비스를 통한 직접 사용자 로그인에 MFA를 사용하도록 설정합니다. 본 옵션을 통해 추가 비용 없이 제한된 인증 요인들을 사용할 수 있습니다. 자세한 내용은 ID 도메인이 포함되지 않은 OCI IAM의 MFA 적용 관련 설명서를 참조해 주세요.
  • Oracle Identity Cloud Service(IDCS)를 활용하여 OCI 사용자를 인증합니다. 본 옵션은 보다 많은 MFA 기능 및 인증 관련 선택지를 제공합니다.
• IDCS를 사용한 인증의 경우, 2가지 라이선스 유형이 사용됩니다.
  • IDCS Foundation(무료 버전)은 OCI 콘솔에 대한 액세스와 관련된 MFA만을 지원하고, 본 설명서에 나열된 제한적 인증 요소들만을 사용 가능합니다. 다른 애플리케이션들에도 MFA 보호를 적용하기 위해서는 IDCS Standard로 업그레이드해야 합니다.
  • IDCS Standard는 추가 비용 없이 모든 서비스 또는 애플리케이션에 대한 광범위한 MFA 보호 옵션을 지원합니다. 자세한 내용은 Identity Cloud Service(IDCS) MFA 설명서를 참조해 주세요.

MFA 적용 방법에 대한 자세한 내용은 어디에서 확인할 수 있나요?

구체적인 MFA 구현 지침은 현재 보유 중인 OCI 테넌시 유형에 따라 달라집니다. 귀사의 테넌시 내 OCI IAM에 ID 도메인이 포함되어 있는지 여부를 확인하고자 하시는 경우 본 설명서를 참조해 주세요.

• 귀사의 테넌시 내 OCI IAM에 ID 도메인이 포함되어 있는 경우, OCI IAM 보안 모범 사례를 참조해 주세요.
• 귀사의 테넌시 내 OCI IAM에 ID 도메인이 포함되지 않은 경우, 두 가지 MFA 옵션을 활용할 수 있습니다.
  • ID 도메인이 포함되지 않은 OCI IAM을 통한 직접 사용자 로그인에 MFA를 적용하고자 하시는 경우 ID 도메인이 포함되어 있지 않은 OCI IAM용 MFA 관리 문서를 참조해 주세요.
  • ID 도메인이 포함되지 않은 OCI IAM에 통합된 IDCS 사용자들을 대상으로 MFA를 적용하는 경우, IDCS용 MFA 구성 문서를 참조해 주세요.
• OCI 테넌시가 포함되지 않은 애플리케이션에 대한 액세스 권한 인증에 IDCS를 사용하는 경우, IDCS용 MFA 구성 문서를 참조해 주세요.

MFA를 적용하지 않는 경우 어떤 결과가 발생하나요?

MFA를 적용하지 않는 경우 타깃 계정 탈취 공격의 성공 위험이 증가합니다. 반면 MFA를 적용한 경우 설령 공격이 발생하더라도 테넌시 및/또는 기타 인증 프로세스들이 지속적으로 정상 작동합니다.