Orchestration의 자격 증명, 연결 및 별칭 소개
Orchestration의 모든 애플리케이션 통합에는 리소스에 액세스하려면 해당 애플리케이션에 대한 연결 정보, 자격 증명, 연결 및 자격 증명 별칭이 필요합니다.
Orchestration에서 애플리케이션 통합을 실행하려면 먼저 해당 연결 정보와 자격 증명을 생성하고 구성해야 합니다. 연결은 프로토콜이 있는 IP 주소 또는 엔드포인트와 같은 시스템과의 통합과 관련이 있습니다. 여기에는 데이터베이스와 통합할 때의 데이터베이스 세부 정보와 같은 특정 세부 정보가 포함됩니다. 연결된 자격 증명은 연결을 만드는 데 필요한 인증 데이터입니다.
연결 정보 및 자격 증명은 동일한 통합에 대한 QA/개발/프로덕션 환경 간에 다를 수 있습니다. 이 데이터와 애플리케이션 메타데이터(예: 워크플로 또는 작업 스케줄링) 간의 긴밀한 결합으로 인해 환경을 변경할 때 애플리케이션 메타데이터가 더 이상 사용되지 않습니다. 이 문제를 완화하기 위해 연결 및 자격 증명에 대해 별칭 개념이 도입되어 이 데이터를 응용 프로그램 메타데이터에서 분리합니다. 이러한 별칭을 통해 고객은 런타임 중에 연결 및 자격 증명 데이터로 확인되는 별칭에 결합되도록 애플리케이션 메타데이터를 설계할 수 있습니다.
자격 증명 별칭은 자격 증명 데이터만 확인합니다. 별칭 데이터 모델과 함께 런타임 중에 연결 및 자격 증명 데이터를 가져올 수 있는 스크립트 가능한 API를 사용할 수 있습니다.
Orchestration에서 연결 및 자격 증명 별칭 사용
자격 증명 또는 연결 기록에 레이블을 지정하는 별칭을 정의합니다.
- 이름
- 별칭의 이름입니다.
- ID
- 이 필드는 범위 이름 + 이름으로 고유 기록을 보장하기 위한 ID의 고유 인덱스인 "scope name.alias name" 형식을 기반으로 합니다. 범위가 전역인 경우 ID는 별칭 이름입니다.
- 유형
- "자격 증명" 또는 "연결 및 자격 증명"을 선택할 수 있습니다. 기본값은 연결 및 자격 증명입니다.
- 연결 유형
- 이 필드는 별칭 유형이 연결 및 자격 증명으로 설정된 경우에 적용할 수 있습니다. HTTP, JDBC, JMS의 세 가지 연결 유형이 있습니다. 기본값은 HTTP입니다.
- 이름에는 알파벳, 숫자 및 밑줄만 사용할 수 있습니다.
- 업그레이드하는 동안 자격 증명 기록의 태그가 연결 별칭으로 마이그레이션됩니다. 이전 릴리스의 자격 증명 기록에 있는 태그에 알파벳, 숫자, 밑줄 이외의 특수 문자가 포함되어 있으면 업그레이드 중에 태그 데이터가 보존됩니다. 사용자는 이러한 연결 별칭을 계속 사용할 수 있지만 업데이트를 수행할 때 이러한 특수 문자를 제거하지 않는 한 이러한 별칭을 업데이트할 수 없습니다.
오케스트레이션에 자격 증명 사용
오케스트레이션에서 자원에 액세스하려면 자격 증명이 필요합니다.
자격 증명 테이블
자격 증명 테이블(discovery_credential)은 통합에 사용할 수 있는 자격 증명을 정의합니다. 이전 릴리스에서 자격 증명 테이블에는 자격 증명에 레이블을 지정하는 문자열 유형 태그 필드가 포함되어 있으며 태그는 오케스트레이션 활동에 사용됩니다. Madrid 릴리스에서는 태그 이름을 자격 증명 별칭으로 바꾸고, 유형을 문자열에서 연결 별칭 테이블의 참조인 GlideList로 변경합니다.
자격 증명 유형
| 자격 증명 유형 | 설명 | 테스트 자격 증명 옵션 지원 |
|---|---|---|
| 애플리케이션 자격 증명 | 장치 또는 컴퓨터에서 애플리케이션을 탐색하기 위한 자격 증명입니다. 에서 사용하는 검색 패턴 ITOM 가시성 애플리케이션 자격 증명이 필요한 경우가 많습니다. | 아니요 |
| Amazon Web Service 자격 증명 | AWS(Amazon Web Services) 마스터 계정, 접근 키 ID 및 비밀 접근 키입니다. 주: 테스트를 통해 AWS 자격 증명을 테스트할 수 없습니다. |
아니요 |
| Azure 서비스 주체 및 기업계약 자격 증명 | Azure 구독에 필요한 Azure 서비스 주체입니다. | 아니요 |
| 기본 인증 자격 증명 | 사용자 이름 및 암호입니다. | 아니요 |
| CIM 자격 증명 | VMware ESX 서버에 대한 정보를 가져오는 CIMOM(Common Information Model Object Manager) 서버에 액세스하는 데 필요한 사용자 이름 및 암호입니다. | 아니요 |
| 클라우드 자격 증명 | Orchestration이 클라우드 자원에 액세스하는 데 사용하는 자격 증명입니다. | 아니요 |
| JDBC 자격 증명 | JDBC(Java Database Connectivity) 연결에 액세스하기 위한 사용자 이름 및 암호입니다. | 예 |
| JMS 자격 증명 | JMS(Java Message Service)에 액세스하기 위한 사용자 이름 및 암호입니다. | 예 |
| OAuth 2.0 자격 증명 | OAuth 2.0 자격 증명을 사용하면 ServiceNow에서 HTTP 서비스의 사용자 계정에 대한 접근 권한을 얻을 수 있습니다. | |
| SNMP 커뮤니티 자격 증명 | SNMP를 통해 장치에 액세스하는 커뮤니티 문자열입니다. | 예 |
| SNMPv3 자격 증명 | SNMP v3 네트워크의 장치에 액세스하는 데 필요한 사용자 이름 및 키입니다. | 예 |
| SSH 자격 증명 | Linux 및 Unix 장치에 액세스하기 위한 사용자 이름 및 암호입니다. | 예 |
| SSH 자격 증명 | Linux 및 Unix 장치에 액세스하기 위한 개인 키 자격 증명입니다. 주: 보안을 강화하려면 SSH 암호 자격 증명보다 SSH 개인 키 자격 증명을 사용하는 것이 좋습니다. |
예 |
| VMware 자격 증명 | vCenter 자원에 액세스하기 위한 자격 증명입니다. 이러한 자격 증명은 가상 머신 복제와 같이 vCenter에서 수행되는 모든 작업에 필요합니다. | 예 |
| Windows 자격 증명 | Windows 컴퓨터에 액세스하는 데 필요한 사용자 이름과 암호입니다. Windows 자격 증명을 사용하려면 여러 Windows 자격 증명을 충족해야 합니다. | 예 |
MID Server에서 자격 증명을 사용하는 방법
기본적으로 Windows MID Server는 호스트 시스템에서 MID Server 서비스의 로그인 자격 증명을 사용하여 네트워크에서 장치를 검색합니다 Windows . 도메인 또는 로컬 관리자 권한을 갖도록 Windows MID Server 서비스 자격 증명을 구성해야 합니다. UNIX 머신 및 네트워크 장치의 경우 Linux MID Server는 다음 인스턴스에서 구성된 SSH 및 SNMP 자격 증명을 사용합니다. .
를 사용하는 MID Server 오케스트레이션 는 워크플로우 활동에서 지정된 대로 네트워크의 컴퓨터에서 명령을 실행하는 데 필요한 자격 증명에 액세스할 수 있어야 합니다. Orchestration에는 와 동일한 SSH 및 SNMP 자격 증명을 검색사용할 수 있지만 특정 워크플로우 활동을 Windows 위해 설계된 두 가지 추가 자격 증명인 PowerShell용 및 VMware가 있습니다.
암호화 및 암호 해독
플랫폼은 자격 증명 [discovery_credentials] 테이블의 암호화된 필드에 자격 증명을 저장합니다. 일단 입력하면 볼 수 없습니다.
- 자격 증명은 password2 고정 키를 사용하여 인스턴스에서 해독됩니다.
- 자격 증명은 MID Server의 공개 키를 사용하여 인스턴스에서 다시 암호화됩니다.
- 자격 증명은 SSL을 사용하여 부하 분산 장치에서 암호화됩니다.
- 자격 증명은 SSL을 사용하여 MID 서버에서 해독됩니다.
- 자격 증명은 MID Server의 개인 키를 사용하여 MID Server에서 다시 해독됩니다.
자격 증명 주문
자격 증명은 자격 증명 양식 에서 순서 값을 할당할 수 있으며, 이렇게 하면 애플리케이션이 원하는 대로 모든 자격 증명을 특정 순서로 시도하게 됩니다. 순서 값을 지정하지 않으면 discovery_credential애플리케이션은 Orchestration이 SSH 서버(예: Linux 또는 UNIX 컴퓨터)에서 명령을 실행하려고 할 때 또는 Discovery가 SNMP 장치(예: 프린터, 라우터 또는 UPS).
[dscy_credentials_affinity] 테이블을 사용하여 자격 증명과 장치 간에 선호도를 만듭니다. 모든 후속 검색 또는 Orchestration 활동은 이 테이블의 자격 증명 정보를 선호도가 있는 장치와 일치시키려고 합니다. 장치에 대한 자격 증명이 변경 검색 되고 Orchestration이 새 선호도를 만들 때까지 사용 가능한 모든 자격 증명을 다시 시도하면 됩니다.
- 자격 증명 테이블에는 많은 자격 증명이 포함되어 있으며 그 중 일부는 다른 자격 증명보다 더 자주 사용됩니다. 예를 들어 테이블에 150개의 SSH 자격 증명이 포함되어 있고 그 중 5개가 디바이스의 90%에 로그인하는 데 사용되는 경우 이러한 5개를 낮은 순서 번호로 구성하여 실행 목록의 맨 위에 배치하는 것이 좋습니다. 검색 Orchestration은 이러한 공통 자격 증명을 먼저 시도하면 더 빠르게 작동합니다. 첫 번째 연결에 성공한 후 시스템은 다음에 각 디바이스에 대해 사용할 자격 증명을 알고 있습니다.
- 시스템에 적극적인 로그인 보안이 있습니다. 예를 들어, 네트워크의 Solaris 데이터베이스 서버가 MID Server를 잠그기 전에 실패한 로그인 시도를 세 번만 허용하는 경우 데이터베이스 자격 증명을 낮은 순서 값으로 구성합니다.
자격 증명 별칭
- Orchestration 워크플로우의 모든 활동에 개별 자격 증명 할당
- Flow Designer의 모든 작업에 개별 자격 증명 할당
- Orchestration 워크플로우에서 동일한 활동 유형의 각 항목에 서로 다른 자격 증명을 할당합니다.
- 디자이너 플로우에서 동일한 작업이 발생할 때마다 서로 다른 자격 증명을 할당합니다.
외부 자격 증명 스토어
인스턴스에 자격 증명이 저장되는 것을 원하지 않으면 외부 자격 증명 리포지토리를 사용할 수 있습니다. 외부 자격 증명 저장소는 인스턴스가 액세스할 수 있는 외부 사이트에 자격 증명을 저장합니다. CyberArk만 지원됩니다.
오케스트레이션과의 연결
연결 테이블을 사용하여 대상 호스트에 대한 JMS, JDBC 또는 HTTP 연결을 설정합니다.
연결 테이블
- JDBC
- JMS
- HTTP(s)
| 필드 | 설명 |
|---|---|
| 이름 | 연결의 이름입니다. 이 필드는 테이블에서 고유해야 합니다. |
| 자격 증명 | 이 연결에 사용할 자격 증명을 지정합니다. 선택 사항입니다. |
| 연결 별칭 | 연결 별칭은 런타임에 연결 및 자격 증명을 확인합니다. 연결 별칭당 한 번에 하나의 연결만 활성화됩니다. |
| 활성 | 현재 연결을 활성화하려면 선택합니다. |
| 도메인 | 연결이 속한 도메인입니다. |
자격 증명은 비어 있지 않은 경우 활성 연결에서 고유합니다.
연결 정보 업그레이드
- JDBC 서버 이름이 host로 변경되었습니다.
- 데이터베이스 포트의 이름이 port로 변경되었습니다.