ID 통찰력을 활용하는 ID 거버넌스 솔루션 설계
ID 액세스 관리(IAM)는 단순히 과대 광고가 아니며 새로운 현상도 아닙니다. 액세스 제어 애플리케이션은 수십 년 동안 사용되어 왔으며 많은 조직의 인프라에 내장되어 있지만 관리가 점점 어려워지고 있습니다.
고객은 여러 애플리케이션에 액세스할 수 있는 수십만 명의 사용자를 관리하기도 합니다. 즉, 잠재적으로 수십만 명의 권한이 부여될 수 있습니다. 모두 유지 관리가 필요한 애플리케이션 내 액세스 권한 및 권한과 같은 권한 부여입니다. 이로 인해 누가 어떤 컨텍스트/조건 및 방법에 따라 어떤 정보에 액세스할 수 있는지 의문을 제기하게 됩니다.
구조
이 참조 아키텍처는 다음 서비스를 활용합니다.
- Oracle Identity Governance(OIG)
- OIRI(Oracle Identity Role Intelligence)
- Oracle Access Governance(AG)
- OAM(Oracle Access Management)
- Oracle Cloud Infrastructure Identity and Access Management(OCI IAM)
이 아키텍처는 Oracle Cloud Infrastructure(OCI), 고객 데이터 센터 또는 타사 클라우드에서 구현할 수 있습니다. 이 아키텍처를 활용하면 얻을 수 있는 이점은 다음과 같습니다.
- 중복되고 시간이 많이 걸리는 수동 프로세스를 제거하여 사용자 액세스 프로비저닝의 운영 비용을 절감합니다.
- 컨테이너 및 마이크로서비스와 같은 신기술에 투자하여 합리적인 투자수익률 달성
- 효과적인 제어를 배포하고 인적 오류를 제거하여 보안 위험 최소화
- 접근 데이터를 하나의 뷰로 통합하여 누가 어떤 영역에 접근할 수 있는지, 그리고 조직에 대한 접근이 얼마나 위험한지 파악할 수 있습니다. 이 뷰는 보안 소유자 및 관리자에게 사용자 액세스 패턴에 대한 전체 가시성을 제공합니다.
- 바로 사용할 수 있는 직관적인 대시보드를 활용하여 생산성과 최종 사용자 만족도를 높입니다.
- 규제 준수 보고를 자동화합니다.
논리적 구조
다음 다이어그램은 대상 IAM 참조 아키텍처를 보여줍니다.
Oracle 플랫폼에서 구현되는 각 구성 요소의 기능은 다음과 같습니다.
OIG(Oracle Identity Governance), OIRI(Oracle Identity Role Intelligence) 및 OIG 커넥터는 다음을 제공합니다.
- 관리
셀프 서비스 기능 및 사용자 ID 관리를 위한 관리 기능 위임(사용자 및 권한 있는 계정 포함)
- 프로비전
중앙 관리 지점에서 대상 시스템으로의 사용자 정보 외부 흐름입니다. 모든 관리 리소스에서 계정, 역할 및 자격에 대한 모든 작업(생성, 업데이트 및 삭제 등)을 추적합니다.
- 조정
신뢰할 수 있는 시스템 또는 대상 시스템에서 사용자 정보의 내부 흐름입니다. 사용자 정보에는 일반적으로 중앙 관리 플랫폼에 대한 계정, 역할 및 자격의 모든 작업(생성, 업데이트 및 삭제 등)이 포함됩니다.
- Workflow 관리
비즈니스 및 IT 프로세스를 자동화하여 리소스 액세스 요청을 관리하기 위한 승인 프로세스의 정책 기반 자동 프로비저닝 및 모델링을 지원합니다.
- 비밀번호 관리
암호 재설정 및 암호 변경을 위한 암호 정책 지원 및 셀프 서비스 관리
- 통지
플랫폼에서 최종 사용자를 향한 모든 유형의 이벤트와 관련된 정보의 라우팅 및 시스템, 보안 및 위임된 관리자의 관리.
- 커넥터
다양한 이기종 ID 인식 IT 시스템에 대한 3계층 통합 기능. 이 3계층 기능은 커스텀 개발을 최소화하고, 코드 재사용을 극대화하고, 배포 시간을 단축하기 위한 목표를 반영합니다.
- 규칙 엔진
사용자, 역할, 자격, 계정 및 조직 관리와 관련된 프로세스 실행에 대한 평가 기준을 정의합니다.
- 근무 분리
IDA(Identity Audit)를 사용하여 위반을 정의하고 감지합니다. IDA의 탐지 메커니즘은 사용자가 리소스에 대한 실제 액세스를 모니터링하고 지속적으로 위반 사항을 캡처합니다. IDA에는 두 가지 모드가 있습니다 : 탐정과 예방.
- 위임된 롤 및 액세스 관리
액세스 권한을 지정하거나, 리소스를 자동으로 프로비저닝하거나, 승인 및 액세스 인증과 같은 공통 태스크에서 사용할 수 있는 사용자의 논리적 그룹화입니다.
- 위험 분석
역할, 계정 및 자격에 고위험, 중간 및 저위험 레벨을 직접 지정할 수 있는 모든 주요 기능에 대한 포괄적인 위험 관리 기능입니다.
- OIRI(역할 인텔리전스 및 마이닝)
사용자 속성을 기반으로 역할 마이닝에 대한 하향식 접근 방식을 지원하여 피어 그룹 전체에서 자격 패턴을 검색합니다. 애플리케이션 및 자격 또는 하이브리드 하향식 상향식 접근 방식을 기반으로 데이터를 필터링하는 상향식 접근 방식입니다.
역할이 급증하지 않도록 후보자 역할을 기존 역할과 비교합니다. 사용자 선호도 및 역할 선호도를 기반으로 후보자 역할을 미세 조정하는 기능입니다. OIG에 역할을 자동으로 게시하여 역할 채택을 위한 워크플로우를 트리거합니다. OIG 데이터베이스 및 플랫 파일과 같은 다양한 소스의 데이터를 병합하고 후보 롤을 운용 환경으로 이동하기 전에 가정 분석을 제공하는 기능입니다.
액세스 거버넌스(AG) 및 AG 에이전트는 다음을 제공합니다.
- 직관적인 사용자 경험을 통해 인증 캠페인을 실행하여 적시에 적절히 검토할 수 있습니다. 지능형 워크플로는 사용자를 안내하고, 규정 준수 및 규제 목표 달성을 위한 간단한 제안을 제공합니다.
- 머신 러닝 기반 인사이트 리스크 점수 부여 및 고급 애널리틱스(위험 인식 개선, 수동 인증 작업 감소, 액세스 제어/프로비저닝 자동화)를 위한 규범적 권장사항을 제공합니다.
- 그룹 액세스 데이터를 하나의 뷰로 통합하여 액세스 권한을 가진 사용자 및 조직에 대한 액세스 위험도를 자세히 파악합니다.
- ID 데이터 통합관리를 통해 Oracle Identity Governance에서 직접 자격 데이터를 가져와 수정을 트리거합니다.
OAM(Oracle Access Manager) 및 OAM WebGate은 다음을 제공합니다.
- 솔루션 인터페이스에 대한 ID, 속성, 역할, 규칙 및 자격을 기반으로 실시간 액세스 정책 결정 및 시행을 포함하는 권한 부여입니다.
- 솔루션 인터페이스에 대해 청구된 ID의 Active Directory/Azure Active Directory 사용자 저장소에 대한 실시간 확인을 사용하는 인증입니다.
- 솔루션 인터페이스용 서비스 제공자 역할에서 ID 제공자와 OCI IAM의 역할인 통합 Single Sign On입니다.
- ID 제공자로 사용되는 OAM과 서비스 제공자로 OAM과 통합 SSO입니다.
대상 애플리케이션
구현할 통합 대상 애플리케이션에는 다음 중 일부가 포함됩니다.
- ID 조정: Peoplesoft, SAP HRMS, Oracle e-Business Suite HRMS
- 프로비전 및 대상 조정: SAP, Siebel, Salesforce, ServiceNow, Oracle e-Business Suite, Microsoft Office 365, Azure Active Directory, Amazon Web Services
물리적 토폴로지
다음 다이어그램은 여러 가용성 도메인을 포함하는 Oracle Cloud Infrastructure 지역에 있는 Kubernetes 클러스터의 참조 아키텍처를 보여줍니다. 대기 시간 및 성능 저하를 최소화하면서 여러 가용성 도메인(데이터 센터)을 활용하려면 동일한 리전 내의 재해 복구 전략을 사용하는 것이 좋습니다. 제안된 토폴로지는 3개의 가용성 도메인 중 2개를 활용합니다. 이는 모든 포드가 동일한 가용성 도메인의 작업자 노드에서 실행되어야 한다는 권장 사항 때문입니다. 재해 복구 전략에 대한 자세한 내용은 아래에 나와 있습니다.
구조에는 다음과 같은 구성 요소가 있습니다.
- VCN(가상 클라우드 네트워크) 및 서브넷
VCN은 Oracle Cloud Infrastructure 지역에서 설정한 맞춤형 소프트웨어 정의 네트워크입니다. 기존의 데이터 센터 네트워크와 마찬가지로 VCN을 통해 네트워크 환경을 제어할 수 있습니다. VCN에는 VCN 생성 후 변경할 수 있는 겹치지 않는 CIDR 블록이 여러 개 있을 수 있습니다. VCN을 서브넷으로 분할할 수 있습니다. 서브넷은 지역 또는 가용성 도메인으로 범위가 지정될 수 있습니다. 각 서브넷은 VCN의 다른 서브넷과 겹치지 않는 연속적인 주소 범위로 구성됩니다. 서브넷 생성 후 크기를 변경할 수 있습니다. 서브넷은 공용 또는 전용일 수 있습니다.
- 지역
Oracle Cloud Infrastructure 리전은 가용성 도메인이라고 하는 데이터 센터가 하나 이상 포함된 지역화된 지리적 영역입니다. 지역은 다른 지역과 독립적이며, 먼 거리가 그들을 분리 할 수 있습니다 (국가 또는 대륙에 걸쳐).
- 인터넷 게이트웨이
인터넷 게이트웨이는 VCN의 공용 서브넷과 공용 인터넷 간의 트래픽을 허용합니다.
- WAF(웹 애플리케이션 방화벽)
Oracle Cloud Infrastructure Web Application Firewall(WAF)은 로드 밸런서 또는 웹 애플리케이션 도메인 이름과 같이 강제 수행 지점에 연결된 PCI(Payment Card Industry) 호환 지역 기반 및 에지 적용 서비스입니다. WAF는 원치 않는 악의적인 인터넷 트래픽으로부터 애플리케이션을 보호합니다. WAF는 인터넷에 접속하는 모든 끝점을 보호할 수 있으며, 고객의 애플리케이션에 대해 일관된 규칙을 적용합니다.
- DRG(동적 경로 지정 게이트웨이)
DRG는 VCN과 지역 외부 네트워크(예: 다른 Oracle Cloud Infrastructure 지역의 VCN, 온프레미스 네트워크 또는 다른 클라우드 공급자의 네트워크) 간에 동일한 지역의 VCN 간 전용(private) 네트워크 트래픽에 필요한 경로를 제공하는 가상 라우터입니다.
- 서비스 게이트웨이
서비스 게이트웨이는 VCN에서 Oracle Cloud Infrastructure Object Storage와 같은 다른 서비스로의 액세스를 제공합니다. VCN에서 Oracle 서비스로의 트래픽은 Oracle 네트워크 패브릭을 통해 이동하며 인터넷을 순회하지 않습니다.
- NAT(Network Address Translation) 게이트웨이
NAT 게이트웨이를 사용하면 VCN의 전용 리소스가 수신 인터넷 연결에 이러한 리소스를 노출시키지 않고 인터넷의 호스트에 액세스할 수 있습니다.
- 서브넷이 아키텍처의 VCN은 운영 및 재해 복구 환경을 페어링하는 10개의 서브넷으로 구성됩니다. 모든 서브넷은 가용성 도메인에 따라 다르므로 대기 시간 및 성능 저하를 최소화하기 위해 하나의 데이터 센터 내에서 제한됩니다. 또한 동일한 VCN 및 지역에 배포된 재해 복구를 통해 가용성 도메인 장애로부터 보호합니다.
- 두 개의 공용 서브넷은 웹 계층용입니다.
- 프라이빗 로드 밸런서용 프라이빗 서브넷 2개
- 두 개의 전용 서브넷은 Kubernetes 클러스터 및 Kubernetes 클러스터의 노드를 관리하는 데 필요한 툴이 포함된 관리 호스트용입니다.
- 두 개의 프라이빗 서브넷은 Kubernetes 클러스터 API 끝점용입니다.
- 두 개의 프라이빗 서브넷은 Autonomous Database 프라이빗 끝점 액세스용이며, 지정된 프라이빗 네트워크(VCN)의 접속만 허용합니다.
- 로드 밸런서 노드
- 한 지역 공용 로드 밸런서 노드는 프로덕션 및 재해 복구 환경 전반에서 솔루션의 웹 계층을 실행하는 컴퓨팅 인스턴스로 트래픽을 가로채고 분산시킵니다.
- 환경당 하나의 가용성 도메인별 전용 로드 밸런서 노드가 컨테이너화된 애플리케이션 중간 계층을 실행하는 Kubernetes 노드로 트래픽을 가로채고 분산합니다.
- Kubernetes 워커 노드
Kubernetes 작업자 노드는 컨테이너화된 애플리케이션이 배포되는 컴퓨트 인스턴스입니다. 이 참조 아키텍처의 모든 워커 노드는 단일 노드 풀에 있으며 전용 서브넷에 연결됩니다. 필요한 경우 여러 노드 풀을 만들 수 있습니다.
이 참조 아키텍처의 워커 노드는 공용 인터넷에서 직접 액세스할 수 없습니다. 컨테이너화된 애플리케이션 사용자는 로드 밸런서를 통해 애플리케이션에 접근할 수 있습니다. 관리자는 배스천 서비스를 통해 워커 노드에 액세스할 수 있습니다. Kubernetes 마스터 노드는 Oracle 테넌시에서 실행되며 표시되지 않습니다.
- Kubernetes API 끝점
전용 서브넷에 호스트된 클러스터 제어판의 Kubernetes API 끝점을 통해 일반 사용자는 Kubernetes 리소스(예: Pod, 네임스페이스, 구성 맵 및 이벤트)를 질의하고 조작할 수 있습니다.
- POD/서비스 오버레이 네트워크
Kubernetes 네트워킹 모델은 Pod가 클러스터 내에서 고유한 경로 지정 가능한 IP 주소를 가지고 있다고 가정합니다. Kubernetes 네트워킹 모델에서 POD는 이러한 IP 주소를 사용하여 서로 통신합니다. 클러스터의 제어 플레인 노드와 다른 클러스터의 POD, 다른 서비스(예: 스토리지 서비스) 및 인터넷 사용.
- 프라이빗 끝점이 있는 Autonomous Database
대상 호스트에 대한 모든 송신 접속이 프라이빗 끝점의 송신 규칙에 따라 적용되고 제한되도록 데이터베이스 속성을 설정하여 향상된 보안을 제공합니다. 송신 규칙은 VCN 보안 목록 또는 Autonomous Database 인스턴스 프라이빗 끝점과 연관된 NSG(네트워크 보안 그룹)에 정의됩니다.
- 배스천 서비스
Oracle Cloud Infrastructure(OCI) Bastion은 퍼블릭 엔드포인트가 없고 베어메탈 및 가상 머신, Oracle MySQL Database Service, Autonomous Transaction Processing(ATP), Oracle Cloud Infrastructure Kubernetes Engine(OKE) 및 SSH(Secure Shell Protocol) 액세스를 허용하는 기타 리소스와 같은 엄격한 리소스 액세스 제어가 필요한 리소스에 대해 제한적이고 시간 제한적인 보안 액세스를 제공합니다. OCI Bastion 서비스를 사용하면 점프 호스트를 배포 및 유지 관리하지 않고도 개인 호스트에 대한 액세스를 활성화할 수 있습니다. 또한 ID 기반 권한과 중앙 집중식, 감사 및 시간 제한 SSH 세션을 통해 보안 상태를 개선할 수 있습니다. OCI Bastion은 배스천 액세스를 위한 공용 IP가 필요하지 않으므로 원격 액세스를 제공할 때 번거롭고 잠재적인 공격 표면을 제거합니다.
- 영구 저장소 복제
NFS에서의 Rsync는 최소한의 유지 관리 및 구성으로 도메인 구성을 복제하는 영구 저장소 복제 방법을 제공합니다.
- 자율운영 Data Guard(Data Guard 복제)
When you enable Autonomous Data Guard with a standby database in the current region, Autonomous Database monitors the primary database and if the primary database goes down, the standby instance automatically assumes the role of the primary instance. 로컬 standby database에서 Autonomous Data Guard를 활성화하면 Autonomous Database는 primary database의 상태에 따라 다음을 허용하는 동일한 standby database를 제공합니다.
기본 데이터베이스가 작동 중지되면 자율운영 Data Guard가 중단을 최소화하면서 대기 데이터베이스를 기본 데이터베이스로 변환합니다. 복구가 완료되면 자율운영 Data Guard가 새 대기 데이터베이스를 생성합니다.
기본 데이터베이스가 대기 데이터베이스가 되고 대기 데이터베이스가 기본 데이터베이스가 되는 전환 작업을 수행할 수 있습니다.
고려사항
ID 거버넌스 솔루션을 설계할 때 다음 사항을 고려하십시오.
장애 복구
OCI의 재해 복구 솔루션은 능동-수동 모델입니다.
기본 시스템은 Oracle Cloud Infrastructure Kubernetes Engine의 Oracle WebLogic 도메인(WLS), Oracle Identity and Access Management(OIG & OAM), 로드 밸런서, Oracle Autonomous Transaction Processing(ATP) 및 하나의 AD(가용성 도메인)에 두 개의 OHS(Oracle HTTP Server)로 구성됩니다.
보조 시스템은 동일한 아키텍처 구성 요소로 구성되어 있지만 다른 가용성 도메인에 있습니다. 가용성 도메인, 데이터 센터 및 사이트는 재해 발생 시 구성 요소를 보호하기 위해 기본 가용성 도메인과 물리적으로 충분히 멀리 떨어져 있습니다.