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