Oracle Exadata로 데이터베이스 액세스
Teleport v18.9Teleport는 Teleport Database Service를 통해 Oracle Exadata에 대한 보안 접근을 제공할 수 있습니다. Teleport Database Service는 상호 TLS를 사용하여 Oracle Exadata 데이터베이스에 인증합니다.
Teleport는 Teleport Database Service를 통해 Oracle Exadata에 대한 보안 접근을 제공할 수 있습니다. 이를 통해 Teleport의 RBAC를 사용한 세분화된 접근 제어가 가능합니다.
이 가이드에서는 다음을 수행합니다:
- Oracle Exadata 데이터베이스를 구성합니다 mTLS 인증으로.
- 데이터베이스를 Teleport 클러스터에 추가합니다.
- Teleport를 통해 데이터베이스에 연결합니다.
작동 방식#
Teleport Database Service는 상호 TLS를 사용하여 Oracle Exadata 데이터베이스에 인증합니다. Oracle Exadata는 데이터베이스 클라이언트에 대해 Teleport 인증 기관을 신뢰하며, Teleport 데이터베이스 CA 또는 사용자 지정 CA가 서명한 인증서를 제시합니다. 사용자가 데이터베이스 세션을 시작하면 Teleport Database Service는 Teleport가 서명한 인증서를 제시합니다. 인증된 연결은 이후 사용자의 클라이언트 트래픽을 프록시합니다.


사전 조건#
-
실행 중인 Teleport Enterprise 클러스터. Teleport를 시작하려면 무료 체험판에 가입하거나 데모 환경을 구성하세요.
-
tctlandtshclients.Installing `tctl` and `tsh` clients
-
Teleport 클러스터의 버전을 확인합니다.
tctlandtshclients는 Teleport 클러스터 버전보다 최대 한 개의 메이저 버전까지만 뒤처질 수 있습니다. Proxy Service의/v1/webapi/find로 GET 요청을 보내고 JSON 쿼리 도구를 사용하여 클러스터 버전을 확인합니다.teleport.example.com:443를 Teleport Proxy Service의 웹 주소로 바꿉니다:$ TELEPORT_DOMAIN=teleport.example.com:443 $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')" -
사용 중인 플랫폼에 대한 지침에 따라
tctlandtshclients를 설치합니다:
-
Mac
`tctl` and `tsh` clients가 포함된, 서명된 Teleport macOS .pkg 설치 프로그램을 다운로드합니다:
```code
$ curl -O https://cdn.teleport.dev/teleport-${TELEPORT_VERSION?}.pkg
```
Finder에서 `pkg` 파일을 더블 클릭하여 설치를 시작합니다.
Homebrew를 사용하여 Teleport를 설치하는 것은 지원되지 않습니다. Homebrew의
Teleport 패키지는 Teleport에서 유지 관리하지 않으므로 신뢰성이나 보안을
보장할 수 없습니다.
Windows - Powershell
```code
$ curl.exe -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-windows-amd64-bin.zip
# Unzip the archive and move the `tctl` and `tsh` clients to your %PATH%
# NOTE: Do not place the `tctl` and `tsh` clients in the System32 directory, as this can cause issues when using WinSCP.
# Use %SystemRoot% (C:\Windows) or %USERPROFILE% (C:\Users\<username>) instead.
```
Linux
Linux 설치판의 모든 Teleport 바이너리에는 `tctl` and `tsh` clients가 포함되어 있습니다. RPM/DEB
패키지 및 i386/ARM/ARM64용 다운로드를 포함한 더 많은 옵션은
[설치 페이지](../installation/installation.mdx)를 참조하세요.
```code
$ curl -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
$ tar -xzf teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
$ cd teleport
$ sudo ./install
# Teleport binaries have been copied to /usr/local/bin
```
- Oracle Exadata 서버 인스턴스 19c 이상.
sqlclOracle 클라이언트가 설치되어 시스템PATH환경 변수에 추가되어 있거나 JDBC Oracle thin 클라이언트를 지원하는 GUI 클라이언트.
Teleport cluster에 연결할 수 있는지 확인하려면 tsh login으로 로그인한 다음,
현재 자격 증명으로 tctl 명령을 실행할 수 있는지 확인합니다.
예를 들어, teleport.example.com에 cluster 내 Teleport Proxy Service의
도메인 이름을, email@example.com에 Teleport 사용자 이름을 지정하여
다음 명령을 실행합니다:
$ tsh login --proxy=teleport.example.com --user=email@example.com
$ tctl status
# Cluster (=teleport.url=)
# Version (=teleport.version=)
# CA pin (=presets.ca_pin=)
cluster에 연결하여 tctl status 명령을 실행할 수 있다면, 현재 자격 증명을 사용하여
워크스테이션에서 이후의 tctl 명령을 실행할 수 있습니다.
자체 Teleport cluster를 호스팅하는 경우, 전체 권한을 얻기 위해 Teleport Auth Service를
호스팅하는 컴퓨터에서 tctl 명령을 실행할 수도 있습니다.
1/6단계. Oracle Exadata 구성#
이 가이드는 Oracle Exadata 시스템의 기본 구성을 가정합니다. 특히:
- 사전 구성된 TCPS 리스너.
- 그리드 지갑의 기존 데이터베이스 인증서.
- 호스트 이름이
<code>demodb-vm</code>인 단일 Oracle Exadata VM이 SSH를 통해opc사용자로 액세스 가능. 추가 VM을 구성하려면 단계를 반복합니다. - SCAN DNS 이름은
<code>demodb-vm-scan.exadatadomain.oke.oraclevcn.com</code>입니다.
명령을 사용자 구성에 맞게 조정하세요.
데이터베이스별 구성 업데이트#
opc 사용자로 Oracle Exadata VM에 연결한 후 oracle 사용자로 전환합니다:
$ ssh opc@demodb-vm
$ sudo su - oracle
각 데이터베이스별 Oracle home에 대해 $ORACLE_HOME/network/admin/sqlnet.ora 파일을 다음 항목으로 업데이트합니다:
SSL_CLIENT_AUTHENTICATION = TRUE
SQLNET.AUTHENTICATION_SERVICES = (ALL)
예를 들어, spark라는 데이터베이스가 있는 경우 oracle 사용자는 데이터베이스별 환경 변수가 포함된 자동 생성 파일 /home/oracle/spark.env에 액세스할 수 있습니다. 이 파일을 소싱하면 $ORACLE_HOME/network/admin/sqlnet.ora 경로가 spark 데이터베이스 및 관련 Oracle home의 sqlnet.ora 파일을 가리킵니다.
# 'spark' 데이터베이스의 환경 변수 로드
$ . spark.env
# $ORACLE_HOME/network/admin/sqlnet.ora에 있는 구성 파일 편집
...
필요에 따라 각 추가 데이터베이스 또는 데이터베이스 home에 대해 이 단계를 반복합니다.
Oracle 사용자 계정 구성#
Oracle 사용자 계정은 유효한 클라이언트 인증서를 요구하도록 구성해야 합니다.
새 사용자 생성:
CREATE USER alice IDENTIFIED EXTERNALLY AS 'CN=alice';
GRANT CREATE SESSION TO alice;
기존 사용자 변경:
ALTER USER alice IDENTIFIED EXTERNALLY AS 'CN=alice';
이 작업은 비밀번호와 같은 기존 인증 방법을 무효화합니다. 인증서 기반 인증이 이 사용자의 유일한 인증 방법이 됩니다.
Teleport Database Client CA 신뢰#
Teleport는 Oracle Exadata와 상호 TLS 인증을 사용합니다. 클라이언트 인증서를 확인하려면 Teleport의 인증 기관으로 구성해야 합니다.
로컬 머신에서 Teleport Database Client CA를 내보내고 대상 Oracle Exadata VM에 복사합니다.
# Teleport의 데이터베이스 클라이언트 인증 기관 내보내기
$ tctl auth export --type=db-client > teleport-db-client-ca.crt
# CA를 Oracle Exadata VM에 복사
$ scp teleport-db-client-ca.crt opc@demodb-vm:/tmp/teleport-db-client-ca.crt
grid 사용자로 그리드 TCPS 지갑을 업데이트하여 Teleport User Database CA를 신뢰합니다.
# 지갑 비밀번호 읽기
$ mkstore -wrl /u01/app/oracle/admin/cprops/cprops_wallet -nologo -viewEntry grid_tcps_wallet_passwd
grid_tcps_wallet_passwd = <wallet password>
# 그리드 TCPS 지갑 업데이트; 프롬프트 시 비밀번호 입력
$ orapki wallet add -wallet "/var/opt/oracle/dbaas_acfs/grid/tcps_wallets" -trusted_cert -cert /tmp/teleport-db-client-ca.crt
그리드 리스너에 TLS 인증 활성화#
다음 항목을 추가하여 $ORACLE_HOME/network/admin/listener.ora에서 그리드 리스너 구성을 조정하여 TLS 인증을 활성화합니다:
SSL_CLIENT_AUTHENTICATION = TRUE
리스너 재시작#
완료되면 리스너를 재시작합니다.
$ lsnrctl stop
$ lsnrctl start
2/6단계. 데이터베이스 구성 데이터 수집#
Oracle에서 내장 데이터베이스 인증서를 내보냅니다. Teleport는 이 인증서를 사용하여 데이터베이스 연결을 확인합니다.
# 데이터베이스 인증서를 내보냅니다. "-dn" 파라미터를 실제 설정에 맞게 업데이트합니다.
$ orapki wallet export -wallet "/var/opt/oracle/dbaas_acfs/grid/tcps_wallets" -dn "CN=demodb-vm-scan.exadatadomain.oke.oraclevcn.com" -cert /tmp/oracle-server-certificate.crt
/tmp/oracle-server-certificate.crt 파일을 임시 위치에 저장합니다. 최종 위치는 Teleport 설치 방법에 따라 달라지며 다음 단계에서 자세히 설명합니다.
로컬 리스너의 TCPS 주소를 확인합니다. 이 주소는 Teleport가 연결에 사용합니다. 아래 예제에서 주소는 <code>10.20.30.40:2484</code>입니다.
$ sqlplus / as sysdba
# ...
# SQL> SHOW PARAMETER local_listener;
#
# . NAME TYPE VALUE
# . -------------- ------ ------------------------------
# . local_listener string (ADDRESS=(PROTOCOL=TCP)(HOST=10.20.30.40)(PORT=1521)),
# . (ADDRESS=(PROTOCOL=TCPS)(HOST=10.20.30.40)(PORT=2484))
3/6단계. Database Service 구성 및 시작#
Teleport 조인 토큰 생성#
Database Service가 Teleport 클러스터에 조인하려면 유효한 조인 토큰이 필요합니다.
다음 tctl 명령을 실행하고 Database Service를 실행할 서버에서
토큰 출력을 /tmp/token에 저장합니다:
$ tctl tokens add --type=db --format=text
(=presets.tokens.first=)
Teleport Database Service#
Teleport Database Service를 실행할 곳에 Teleport를 설치하고 구성합니다:
Linux 서버에 Teleport Agent를 설치하려면:
권장 설치 방법은 클러스터 설치 스크립트입니다. 이 스크립트는 클러스터에 맞는 올바른 버전, 에디션, 설치 모드를 선택합니다.
-
teleport.example.com:443에 Teleport 클러스터의 호스트명과 포트를 할당하되, 스킴(https://)은 포함하지 마십시오. -
클러스터의 설치 스크립트를 실행하십시오:
$ curl "https://teleport.example.com:443/scripts/install.sh" | sudo bash
Teleport Database Service를 실행할 호스트에서 적절한 구성으로 Teleport를 시작합니다.
단일 Teleport 프로세스는 여러 Database Service 에이전트, SSH Service 또는 Application Service 등 여러 다른 서비스를 실행할 수 있습니다. 아래 단계는 기존 구성 파일을 덮어쓰므로 여러 서비스를 실행하는 경우 --output=stdout을 추가하여 터미널에 구성을 출력하고 /etc/teleport.yaml을 수동으로 조정하세요.
Oracle Database 인증서를 복사하여 Teleport Database Service 호스트의
/var/lib/teleport/oracle-server-certificate.crt에 제공합니다.
다음 명령을 실행하여 Database Service용 구성 파일을
/etc/teleport.yaml에 생성합니다.
example.teleport.sh을 Teleport Proxy
Service의 도메인 이름으로 업데이트합니다:
$ sudo teleport db configure create \
-o file \
--token=/tmp/token \
--proxy=example.teleport.sh:443 \
--name="oracle" \
--protocol=oracle \
--uri="10.20.30.40:2484" \
--ca-cert-file="/var/lib/teleport/oracle-server-certificate.crt" \
--labels=env=dev
생성된 구성 파일을 수동으로 편집하여 tls.mode: verify-ca를 포함합니다.
<code>oracle</code> 데이터베이스의 최종 항목은 다음과 유사합니다:
db_service:
enabled: true
databases:
- name: oracle
uri: "10.20.30.40:2484"
protocol: oracle
tls:
mode: verify-ca
ca_cert_file: /var/lib/teleport/oracle-server-certificate.crt
systemd 서비스를 생성하여 호스트가 부팅될 때 the Teleport Database Service이 자동으로 시작되도록 구성합니다. 지침은 the Teleport Database Service을 어떻게 설치했는지에 따라 다릅니다.
Package Manager
the Teleport Database Service을 실행할 호스트에서 Teleport를 활성화하고 시작합니다:
$ sudo systemctl enable teleport
$ sudo systemctl start teleport
TAR Archive
the Teleport Database Service을 실행할 호스트에서 Teleport용 systemd 서비스 구성을 생성하고, Teleport 서비스를 활성화한 후 Teleport를 시작합니다:
$ sudo teleport install systemd -o /etc/systemd/system/teleport.service
$ sudo systemctl enable teleport
$ sudo systemctl start teleport
systemctl status teleport로 the Teleport Database Service의 상태를 확인하고 journalctl -fu teleport로
로그를 볼 수 있습니다.
다음 명령을 사용하여 Teleport와 같은 네임스페이스에 데이터베이스 CA 인증서가 포함된 시크릿을 생성합니다:
$ kubectl create secret generic db-ca --from-file=ca.pem=/path/to/oracle-server-certificate.crt
다음 내용으로 values.yaml 파일을 생성합니다.
JOIN_TOKEN을 앞서 tctl tokens add 명령으로 생성한 조인 토큰으로 업데이트합니다:
roles: db
proxyAddr: example.teleport.sh:443
enterprise: true
authToken: "JOIN_TOKEN"
databases:
- name: oracle
uri: "10.20.30.40:2484"
protocol: oracle
static_labels:
env: dev
tls:
mode: verify-ca
ca_cert_file: /etc/teleport-tls-db/db-ca/ca.pem
extraVolumes:
- name: db-ca
secret:
secretName: db-ca
extraVolumeMounts:
- name: db-ca
mountPath: /etc/teleport-tls-db/db-ca
readOnly: true
Teleport는 Kubernetes 클러스터에 Teleport Database Service를 설치하기 위한 Helm 차트를 제공합니다.
Teleport Helm 리포지토리에서 Teleport 차트를 가져오도록 Helm을 구성하십시오.
$ helm repo add teleport (=teleport.helm_repo_url=)
최신 차트를 가져와 로컬 Helm 캐시를 새로 고치십시오.
$ helm repo update
차트 설치:
$ helm install teleport-kube-agent teleport/teleport-kube-agent \
--create-namespace \
--namespace teleport-agent \
--version (=teleport.version=) \
-f values.yaml
Teleport Agent 파드가 실행 중인지 확인합니다. 단일 준비 컨테이너를 가진
teleport-kube-agent 파드 하나가 표시되어야 합니다:
$ kubectl -n teleport-agent get pods
NAME READY STATUS RESTARTS AGE
teleport-kube-agent-0 1/1 Running 0 32s
4/6단계. (선택 사항) Oracle Audit Trail에서 감사 로그 가져오도록 Teleport 구성#
Teleport는 Oracle Audit Trail에서 감사 로그를 가져올 수 있습니다. 이 기능을 활성화하려면 Oracle Audit Trail을 구성하고 Oracle Audit Trail에서 감사 이벤트를 가져오는 데 사용될 전용 Teleport 사용자를 생성해야 합니다.
Oracle Audit Trail에서 감사 이벤트를 가져올 내부 Oracle teleport 사용자를 생성합니다:
CREATE USER teleport IDENTIFIED EXTERNALLY AS 'CN=teleport';
GRANT CREATE SESSION TO teleport;
GRANT SELECT ON dba_audit_trail TO teleport;
GRANT SELECT ON V_$SESSION TO teleport;
Oracle Audit Trail에서 테이블을 활성화합니다:
ALTER system SET audit_trail=db,extended scope=spfile;
감사 추적 변경 사항을 전파하려면 Oracle 인스턴스를 재시작합니다.
alice 사용자에 대한 Oracle 감사를 활성화합니다:
AUDIT ALL STATEMENTS by alice BY access;
Oracle에 연결하는 데 사용될 각 Teleport 사용자에 대해 감사를 활성화해야 합니다. 또한 각 사용자에 대해 다른 감사 정책을 생성할 수 있습니다.
Oracle Audit Trail에서 감사 로그를 가져오도록 Teleport Database Service를 구성합니다:
db_service:
enabled: true
databases:
- name: oracle
protocol: "oracle"
uri: "10.20.30.40:2484"
oracle:
audit_user: "teleport"
tls:
mode: verify-ca
ca_cert_file: /var/lib/teleport/oracle-server-certificate.crt
Teleport는 Oracle Audit Trail에서 감사 추적 이벤트를 정리하지 않습니다. 디스크 공간이 부족해지는 것을 방지하려면 Oracle Audit Trail 정리 정책을 구성하세요.
5/6단계. Teleport 사용자 생성#
기존 사용자를 수정하여 Database Service 접근 권한을 부여하려면 Database Access Controls를 참조하십시오.
Teleport Community Edition
내장 access 역할을 가진 로컬 Teleport 사용자를 생성합니다:
$ tctl users add \
--roles=access \
--db-users="*" \
--db-names="*" \
alice
Teleport Enterprise/Enterprise Cloud
내장 access 및 requester 역할을 가진 로컬 Teleport 사용자를 생성합니다:
$ tctl users add \
--roles=access,requester \
--db-users="*" \
--db-names="*" \
alice
| Flag | 설명 |
|---|---|
--roles |
사용자에게 할당할 역할 목록입니다. 내장 access 역할은 Teleport에 등록된 모든 데이터베이스 서버에 연결할 수 있게 합니다. |
--db-users |
사용자가 데이터베이스에 연결할 때 사용할 수 있는 데이터베이스 사용자명 목록입니다. 와일드카드는 모든 사용자를 허용합니다. |
--db-names |
사용자가 데이터베이스 서버 내에서 연결할 수 있는 논리적 데이터베이스(즉, 스키마) 목록입니다. 와일드카드는 모든 데이터베이스를 허용합니다. |
데이터베이스 이름은 PostgreSQL, MongoDB, Cloud Spanner 데이터베이스에서만 적용됩니다.
데이터베이스 접근 제어 및 접근 제한 방법에 대한 자세한 정보는 RBAC 문서를 참조하십시오.
6/6단계. 연결#
Database Service가 클러스터에 참여하면 로그인하여 사용 가능한 데이터베이스를 확인합니다:
$ tsh login --proxy=example.teleport.sh --user=alice
$ tsh db ls
# Name Description Allowed Users Labels Connect
# ------ -------------- ------------- ------- -------
oracle [*] env=dev
"<code>oracle</code>" 데이터베이스에 연결합니다. --db-name 파라미터로 올바른 서비스 이름을 전달합니다.
Oracle Exadata VM에서 데이터베이스 구성을 검사하여 서비스 이름을 확인할 수 있습니다.
> lsnrctl services | grep paas
Service "spark_PDB1.paas.oracle.com" has 1 instance(s).
$ tsh db connect --db-user alice --db-name spark_PDB1.paas.oracle.com oracle
# SQLcl: Release 24.2 Production on Fri Aug 09 15:29:41 2024
#
# Copyright (c) 1982, 2024, Oracle. All rights reserved.
#
# Connected to:
# Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production
# Version 19.24.0.0.0
#
# SQL> select user from dual;
#
# USER
# ________
# ALICE
#
# SQL>
그래픽 데이터베이스 클라이언트와 같이 원하는 도구를 사용하여 데이터베이스에 연결하려면 로컬 터널을 생성하여 사용 중인 소프트웨어로 연결할 수 있습니다:
$ tsh proxy db oracle --tunnel --db-user alice --db-name spark_PDB1.paas.oracle.com
특정 도구에 대한 자세한 내용은 데이터베이스 GUI 클라이언트 가이드를 참조하세요.
데이터베이스에서 로그아웃하고 자격 증명을 제거하려면:
# 특정 데이터베이스 인스턴스의 자격 증명 제거.
$ tsh db logout oracle
# 모든 데이터베이스 인스턴스의 자격 증명 제거.
$ tsh db logout
(선택 사항) 추가 호스트 이름 구성#
일부 배포 환경에서는 동일한 논리적 데이터베이스가 서로 다른 특성을 가진 여러 호스트 이름을 통해 접근 가능합니다. 예를 들면 다음과 같습니다.
- 복제된 데이터베이스
- 서로 다른 네트워크 경로를 거치는 호스트 이름
이것이 여러분의 환경에 해당한다면, 연결 복원력을 높이기 위해 모든 호스트를 선호 순서대로 나열합니다.
호스트에 대해 TCP dial 오류가 발생하면, 목록의 다음 호스트가 자동으로 시도됩니다. 비네트워크 오류(예: 인증서 또는 인증 실패)는 재시도되지 않으며 다음 호스트로 넘어가지 않습니다.
기본적으로 호스트는 나열된 순서대로 시도됩니다. 재시도는 목록을 순환하며 필요에 따라 처음으로 되돌아갑니다(예: host1 → host2 → host3 → host1 → ...). 연결 시도마다 순서를 무작위화하려면 shuffle_hostnames를 설정합니다. 그러면 동일한 순환 패턴이 그 무작위화된 순서에 적용됩니다.
retry_count는 네트워크 오류 발생 시 초기 시도 이후 호스트당 재시도 횟수를 제어합니다. 기본값은 2이므로, 순서상 다음 호스트로 넘어가기 전에 호스트당 총 3회(초기 1회 + 재시도 2회) 시도합니다.
이 구성은 새 연결에 대한 페일오버와 기본적인 부하 분산을 지원합니다. shuffle_hostnames를 활성화하면 초기 연결 시도가 여러 호스트에 분산되고(부하 분산), 재시도는 현재 호스트에 연결할 수 없을 때 자동으로 다음 호스트로 이동합니다(페일오버).
- name: oracle
protocol: oracle
uri: host1:2484,host2:2484,host3:2484 # Multiple hosts; dials in sequence and wraps (host1 → host2 → host3 → host1 ...). Dialing sequence can be randomized with `shuffle_hostnames`.
static_labels:
env: dev
oracle:
# Randomize host order per connection attempt to spread load. Optional.
shuffle_hostnames: true
# Retries per host on network errors only; non-network errors stop (default: 2). Optional.
retry_count: 5
문제 해결#
연결이 멈추거나 거부됨#
Oracle 데이터베이스에 연결할 때 흔히 발생하는 문제는 연결 시간 초과 또는 거부입니다. 이는 일반적으로 Teleport Database Service가 Oracle 데이터베이스 엔드포인트에 도달할 수 없는 네트워킹 문제를 나타냅니다. 방화벽 및 VPC 보안 그룹과 같은 네트워크 라우팅 및 접근 제어가 Database Service 호스트에서 데이터베이스 엔드포인트로 트래픽이 흐르도록 허용하는지 확인하십시오.
네이티브 Oracle 클라이언트를 사용하여 연결을 검증할 수 있으며, 이는 문제가 Teleport에 있는지 아니면 기저의 네트워크 구성에 있는지 확인하는 데 도움이 됩니다. 예를 들어 Oracle SQLcl을 사용합니다:
# Example: Oracle SQLcl
sql -L myuser/mypassword@oracle-instance.example.com:2484
네트워크 연결 문제는 자동화된 상태 점검을 통해 감지되는 경우가 많습니다.
등록된 모든 데이터베이스의 상태를 확인하려면:
# All databases
tctl db ls --format=json | jq -r '.[] | [.metadata.name, .status.target_health]'
비정상 상태인 데이터베이스는 다음과 유사한 출력을 표시합니다:
...
"oracle",
{
"address": "11.22.33.44:2484",
"protocol": "TCP",
"status": "unhealthy",
"transition_timestamp": "2025-09-25T09:47:39.435973Z",
"transition_reason": "threshold_reached",
"transition_error": "dial tcp 11.22.33.44:2484: i/o timeout",
"message": "1 health check failed"
}
...
TLS 협상 실패#
Oracle 데이터베이스에서 TLS를 올바르게 구성하는 것은 까다로울 수 있습니다. 서로 다른 근본 원인이 다음과 같은 Teleport의 오류 메시지처럼 동일한 오류 메시지로 이어질 수 있습니다:
Original Error: *tls.permanentError remote error: tls: handshake failure
또는 Oracle 로그에서 다음을 볼 수도 있습니다:
ORA-00609: could not attach to incoming connection
ORA-28860: Fatal SSL error
근본 원인을 식별하려면 아래 섹션의 디버깅 단계를 따르십시오. 다음 openssl 명령의 출력은 많은 일반적인 TLS 문제를 진단하는 데 도움이 될 수 있습니다. 출력을 캡처하여 디버깅 단계를 따를 때 사용하십시오.
> openssl s_client -connect oracle.example.com:2484 -showcerts
잘못된 서버 인증서#
Teleport는 신뢰할 수 없는 서버 인증서를 가진 데이터베이스로의 연결을 거부합니다. Teleport를 사용하여 인증서를 발급하는 경우 서버 인증서가 Teleport Database CA에서 발급되었는지 확인하십시오. 유효하지 않은 서버 인증서는 Teleport가 보안 연결을 설정하지 못하게 합니다.
다음 명령으로 Teleport Database CA 인증서를 볼 수 있습니다:
tctl auth export --type=db | openssl x509 -issuer -noout
...
issuer=O=teleport.example.com, CN=teleport.example.com, serialNumber=200129862304303044762346177566738813560
서버 인증서의 issuer를 Teleport Database CA 인증서의 issuer와 비교하십시오. 이전 섹션의 openssl s_client 명령은 서버 인증서를 보여줍니다:
# openssl s_client output:
...
Server certificate
subject=CN=oracle.example.com
issuer=O=teleport.example.com, CN=teleport.example.com, serialNumber=200129862304303044762346177566738813560
...
또한 orapki 유틸리티를 사용하여 Oracle 지갑을 직접 검사해 서버 인증서를 확인할 수 있습니다.
# Prompt for wallet password
orapki wallet display -complete -wallet /path/to/wallet
출력의 "User Certificates" 섹션에는 서버의 인증서가 포함되어 있어야 합니다. 그 Issuer는 Teleport Database CA의 Subject와 일치해야 합니다.
User Certificates:
Subject: CN=oracle.example.com
Issuer: SERIALNUMBER=200129862304303044762346177566738813560,CN=teleport.example.com,O=teleport.example.com
Serial Number: ...
잘못된 클라이언트 인증서#
Oracle 서버가 Teleport Database Service가 제시한 클라이언트 인증서를 거부하는 경우 Oracle 데이터베이스가 Teleport Database User CA를 신뢰하는지 확인해야 합니다.
다음 명령으로 Teleport Database User CA를 볼 수 있습니다:
tctl auth export --type=db-client | openssl x509 -issuer -noout
issuer=O=teleport.example.com, CN=teleport.example.com, serialNumber=183359545647055551607366887578713393931
Teleport Database User CA를 Oracle 데이터베이스가 신뢰하는 CA 목록과 비교하십시오. 앞서 나온 openssl s_client 명령은 Oracle 데이터베이스가 신뢰하는 CA 목록을 보여줍니다:
# openssl s_client output:
...
---
Acceptable client certificate CA names
O=teleport.example.com, CN=teleport.example.com, serialNumber=183359545647055551607366887578713393931
Teleport Database User CA 인증서가 올바른 지갑에 추가되었고 Oracle 서버 구성이 이 지갑을 참조하는지 확인하십시오.
또한 orapki 유틸리티를 사용하여 Oracle 지갑을 직접 검사해 Teleport Database User CA가 신뢰되는지 확인할 수 있습니다.
# Prompt for wallet password
orapki wallet display -complete -wallet /path/to/wallet
출력의 "Trusted Certificates" 섹션에는 Teleport Database User CA가 포함되어 있어야 합니다. 그 Issuer는 Teleport Database User CA의 issuer와 일치해야 합니다.
Trusted Certificates:
Subject: SERIALNUMBER=183359545647055551607366887578713393931,CN=teleport.example.com,O=teleport.example.com
Issuer: SERIALNUMBER=183359545647055551607366887578713393931,CN=teleport.example.com,O=teleport.example.com
Serial Number: ...
잘못된 TLS 버전#
Teleport는 알려진 취약점으로 인해 TLS 1.0 또는 1.1을 사용하는 연결을 거부합니다. TLS 1.2 또는 그 이상 버전을 활성화하려면 Oracle 구성의 SSL_VERSION 매개변수가 1.2 이상으로 설정되어 있는지 확인하십시오.
공통 암호 스위트 없음#
Oracle 구성의 SQLNET.CIPHER_SUITE 매개변수에 구성된 TLS 버전과 일치하는 최신 TLS 암호 스위트가 포함되어 있는지 확인하십시오.
다음 암호 스위트는 안전하며 다양한 Oracle 버전에서 널리 지원됩니다.
TLS 1.2의 경우:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS 1.3의 경우:
TLS_AES_128_GCM_SHA256TLS_AES_256_GCM_SHA384
Must be logged on to the server 오류#
다음 오류는 로그인 절차가 실패했음을 나타냅니다:
ORA-17430: Must be logged on to the server.
이는 대부분 Oracle 데이터베이스가 TCPS 엔드포인트에서 네이티브 암호화 또는 데이터 무결성 체크섬을 강제하기 때문에 발생합니다. Teleport는 전송 보안을 위해 TLS를 사용하며 네이티브 Oracle 암호화를 지원하지 않습니다.
TCPS 엔드포인트에 대한 중복 암호화 요구 사항을 비활성화하려면 sqlnet.ora 파일에 다음 줄을 추가하십시오:
SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS=TRUE
최신 버전의 Oracle 데이터베이스를 사용하십시오. 이전 버전에서는 이 설정이 데이터 무결성 체크섬을 비활성화하지 않을 수 있으며, 이로 인해 계속 실패할 수 있습니다.
잘못된 사용자 이름#
잘못 지정된 사용자 이름은 다음 오류를 발생시킵니다:
ORA-01017: invalid username/password; logon denied
TLS 기반 인증을 사용할 때 Oracle은 클라이언트 인증서의 Common Name(CN)을 데이터베이스의 외부 사용자에 매핑합니다. dba_users 테이블에서 사용자의 EXTERNAL_NAME을 확인하십시오. 이는 cn=<name> 형식이어야 하며, 여기서 <name>은 tsh db login 명령에서 사용된 --db-user 플래그의 값과 일치합니다.
dba_users 테이블을 쿼리하여 사용자의 EXTERNAL_NAME을 확인할 수 있습니다:
SQL> SELECT username, authentication_type, external_name
2 FROM dba_users
3 WHERE authentication_type = 'EXTERNAL'
4 ORDER BY 1;
USERNAME AUTHENTICATION_TYPE EXTERNAL_NAME
_____________ ______________________ ________________
ALICE EXTERNAL cn=alice
다음 단계#
-
특정 사용자 및 데이터베이스에 대한 접근을 제한하는 방법을 알아보십시오.
-
고가용성 (HA) 가이드를 확인하십시오.
-
YAML 구성 레퍼런스를 살펴보십시오.
-
전체 CLI 레퍼런스를 참조하십시오.
다음 문서를 참조하세요: