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