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