Teleport 세션 녹화
이 페이지는 Teleport가 세션을 녹화하는 방법과 세션 녹화에 적용되는 다양한 구성 옵션에 대한 개요를 제공합니다. 캡처되는 내용은 세션 유형에 따라 다릅니다. Teleport는 세션의 전체 가상 터미널(PTY) 출력을 캡처합니다.
이 페이지는 Teleport가 세션을 녹화하는 방법과 세션 녹화에 적용되는 다양한 구성 옵션에 대한 개요를 제공합니다.
세션 녹화가 캡처하는 내용#
캡처되는 내용은 세션 유형에 따라 다릅니다.
SSH 세션#
Teleport는 세션의 전체 가상 터미널(PTY) 출력을 캡처합니다. 세션 녹화의 목적은 사용자가 세션을 실행할 때 본 내용을 문서화하는 것입니다.
세션 녹화의 설계에는 몇 가지 보안 위험이 있습니다. 즉, 사용자는 터미널 명령을 인코딩(예: base64 사용)하거나, 디스크 또는 인터넷에서 스크립트를 실행하거나, 터미널 설정을 변경하여 터미널 명령을 숨길 수 있습니다. 이것이 환경에 문제가 된다면, BPF 기반의 향상된 세션 녹화를 대신 사용하는 것을 고려하십시오.
Kubernetes 세션#
Teleport는 kubectl exec 호출에 대한 전체 PTY 출력을 캡처합니다.
Kubernetes 세션 녹화는 SSH 세션 녹화와 동일한 보안 위험을 수반합니다.
데스크톱 세션#
Teleport는 데스크톱 화면의 내용과 모든 마우스 입력을 캡처합니다. Teleport는 원격 데스크톱에서 키 입력을 캡처하지 않습니다.
앱 세션#
Teleport는 애플리케이션 접근과 관련된 app.session.request 감사 이벤트 스트림을 캡처합니다. 감사 이벤트는 비공식적으로 "청크"라고 불리는 5분 간격으로 분류됩니다.
데이터베이스 세션#
Teleport는 데이터베이스 쿼리와 접근 중인 데이터베이스와 관련된 감사 이벤트 스트림을 캡처합니다.
세션 녹화 구성#
Teleport는 두 가지 다른 녹화 구성을 지원합니다: 동기 및 비동기 녹화. 또한, Teleport 관리자는 녹화가 이루어지는 위치를 구성할 수 있습니다: 노드 또는 프록시에서.
이를 통해 4가지 가능한 세션 녹화 구성이 도출됩니다:
node-sync: SSH Service 인스턴스에 의해 수행되는 동기 녹화node: SSH Service 인스턴스에 의해 수행되는 비동기 녹화proxy-sync: Proxy Service 인스턴스에서 수행되는 동기 녹화proxy: Proxy Service 인스턴스에서 수행되는 비동기 녹화
이것은 클러스터 전체 구성 옵션으로 전체 Teleport 클러스터에 적용됩니다. teleport.yaml의 auth_service 섹션에서 session_recording을 설정하거나, session_recording_config 리소스를 사용하여 동적으로 구성할 수 있습니다. 다른 리소스 집합에 다른 녹화 구성을 적용해야 하는 경우, 자체 녹화 구성을 가진 신뢰할 수 있는 클러스터를 설정할 수 있습니다.
Windows, 데이터베이스 및 Kubernetes 세션은 해당 세션 유형에 대한 Teleport 서비스를 실행하는 호스트에서 항상 녹화됩니다. "노드"(데스크톱, 데이터베이스 또는 Kubernetes 클러스터)에서 실행되는 Teleport 소프트웨어가 없기 때문입니다.
이러한 이유로, Teleport Windows, Database 및 Kubernetes Services는 node와 proxy를 동일하게(비동기 녹화 수행) 처리하고 node-sync와 proxy-sync를 동일하게(동기 녹화 수행) 처리합니다.
암호화#
Teleport는 4가지 녹화 모드 모두에 대해 세션 녹화의 저장 시 암호화를 지원합니다. teleport.yaml 구성 파일 또는 session_recording_config 리소스를 통해 동적으로 활성화할 수 있습니다.
teleport.yaml을 사용하여 암호화를 활성화하는 예시:
teleport:
auth_service:
session_recording_config:
encryption:
enabled: yes
그리고 동적 session_recording_config 리소스를 사용하는 예시:
kind: session_recording_config
spec:
encryption:
enabled: yes
모든 암호화 키는 CA에 대해 구성된 동일한 키 저장 백엔드를 사용하여 프로비저닝됩니다.
여러 Teleport Auth Service가 있는 분산 HA 환경에서는 모든 서비스가 동일한 키 저장 백엔드와 키에 접근할 수 있어야 합니다. 그렇지 않으면 세션 재생 가용성이 저하될 수 있습니다. 이는 수동 암호화 키 관리를 사용하는 경우에도 마찬가지입니다.
SSH 노드에서 녹화#
기본적으로, Teleport는 SSH 노드에서 녹화를 수행합니다. 이는 Teleport의 Proxy Server가 노드로의 SSH 트래픽을 볼 수 없기 때문입니다. 트래픽은 엔드투엔드로 암호화되어 있습니다(SSH 클라이언트에서 SSH 서버로):
Proxy Service에서 녹화#
녹화 프록시 모드에서 Proxy Service는 Auth Service에 의해 동적으로 생성되고 Teleport Host CA에 의해 서명된 신뢰할 수 있는 호스트 인증서를 클라이언트에 제시하여 SSH 연결을 종료(복호화)합니다.
그런 다음 Proxy Service는 두 가지 방법 중 하나로 인증하여 대상 서버에 자체 연결을 설정합니다:
- Teleport SSH Service 및 레거시 OpenSSH 서버의 경우, Proxy Service는 클라이언트가 SSH Agent Forwarding을 통해 자격증명을 제공하도록 요구하여 이러한 자격증명을 OpenSSH 서버에 연결하는 데 재사용할 수 있습니다.
- SSH Agent Forwarding은 이 모드에서 연결을 시도하는 모든 사용자에게 허용되어야 합니다.
- OpenSSH 서버의 경우, Proxy Service는 OpenSSH 서버에 의해 신뢰받을 Teleport OpenSSH CA에 의해 서명된 인증서를 요청합니다.
연결의 양쪽이 복호화되면, Proxy Service는 클라이언트와 대상 서버 간의 파이프 역할을 하여 RBAC 검사를 수행하고, 세션을 녹화하며, 아래와 같이 감사 이벤트를 내보냅니다:
우리는 두 가지 이유로 녹화 프록시 모드가 서버 수준에서 녹화하는 것보다 덜 안전하다고 간주합니다:
- Teleport Proxy Service에 추가 권한을 부여합니다. Teleport SSH Service에서 녹화가 이루어질 때, Proxy Service는 비밀을 저장하지 않고 복호화된 데이터를 "볼" 수 없습니다. 이는 Proxy Service 인스턴스가 전체 클러스터 보안에 덜 중요하게 만듭니다. 그러나 공격자가 녹화 프록시 모드로 실행 중인 Proxy Server에 물리적 접근을 얻으면 복호화된 트래픽과 Proxy Server의 프로세스 메모리에 저장된 클라이언트 키를 볼 수 있습니다.
- SSH Agent Forwarding(Teleport 노드 및 레거시 OpenSSH 서버 지원)의 사용이 필요합니다.
녹화 프록시 모드를 활성화하는 방법을 알아보려면 참고 문서를 참조하십시오. 녹화 모드는 Auth Service에서 구성됨을 주의하십시오.
클러스터 전체에 걸쳐 녹화 프록시 모드를 사용할 필요는 더 이상 없습니다. OpenSSH 서버를 지원하기 위해서. 녹화 프록시 모드는 이 모드의 주요 보안 우려 사항인 SSH Agent Forwarding 없이도 OpenSSH 서버에 자동으로 사용됩니다.
녹화 프록시 모드는 레거시 OpenSSH 지원 및 기타 사용 사례에 대해 계속 지원되지만, 이 모드가 도입하는 여러 기술적 제한으로 인해 많은 기존 및 새로운 기능이 이 모드에서 지원되지 않습니다.
동기 녹화#
동기 녹화가 활성화되면, 녹화를 수행하는 Teleport 구성 요소(구성에 따라 Teleport SSH Service 또는 Proxy Service 인스턴스일 수 있음)가 각 녹화 이벤트를 발생 시 Teleport Auth Service에 제출합니다. 이 모드에서 녹화 이벤트 내보내기 실패는 치명적으로 간주됩니다. 이벤트를 녹화할 수 없는 경우 세션이 종료됩니다. 이는 동기 녹화가 모든 데이터가 녹화되었다는 확신이 필요한 엄격하게 규제된 환경에 가장 적합하게 만듭니다. 또한 세션 중단이나 일시적 연결 손실로 인한 세션 종료가 없도록 세션 기간 동안 Auth Server에 신뢰할 수 있고 낮은 레이턴시의 연결이 필요합니다.
동기 녹화 모드에서 Teleport Auth Service는 녹화 이벤트 스트림을 수신하고 최종 아티팩트로 조립하여 저장 백엔드에 업로드하는 역할을 합니다. 녹화 암호화가 활성화된 경우, Teleport Auth Service는 업로드 전에 이벤트 스트림을 암호화하는 역할도 합니다. 데이터가 직접 스트리밍되므로, Teleport 관리자는 Teleport SSH Service 및 Proxy Service 인스턴스의 디스크 공간에 대해 걱정할 필요가 없습니다. 해당 디스크에 녹화 데이터가 기록되지 않기 때문입니다.
비동기 녹화#
비동기 녹화가 활성화되면, 세션 중에 녹화 이벤트가 로컬 파일 시스템에 기록됩니다. 세션이 완료되면, Teleport는 각 부분을 완전한 녹화로 조립하고 저장을 위해 전체 녹화를 Auth Service에 제출합니다.
녹화 데이터가 디스크로 플러시되므로, 관리자는 예상 Teleport 세션 수를 수용할 수 있을 만큼 시스템에 충분한 디스크 공간이 있는지 확인해야 합니다. 또한 녹화 데이터가 임시적으로 디스크에 저장되므로, 업로드가 완료되기 전에 변조, 삭제 또는 손상될 가능성이 더 높습니다. 비동기 모드에 대한 녹화 암호화를 활성화하면 이벤트가 로컬 파일 시스템에 기록되기 전에 암호화되어 변조를 방지하는 데 도움이 됩니다.
비동기 녹화의 장점은 Auth Service에 대한 지속적인 연결이 필요하지 않다는 것입니다. 예를 들어, Teleport의 Auth Service가 다운되더라도 SSH 세션은 계속 작동할 수 있습니다. 세션이 완료되면 Teleport는 Auth Service에 녹화를 업로드하려고 시도합니다. Auth Service가 여전히 사용 불가능한 경우, Teleport에는 Auth Service가 다시 온라인 상태가 될 때 아티팩트를 업로드하는 내장된 재시도 및 백오프 메커니즘이 있습니다. 또한, 비동기 녹화는 매우 활발한 세션을 녹화하거나 Auth Service에 대한 연결이 불안정하거나 높은 레이턴시 환경에 잘 적합합니다.
저장소#
세션 녹화는 teleport.yaml 구성 파일의 audit_sessions_uri 필드로 지정되는 Teleport의 감사 세션 백엔드에 저장됩니다. Teleport는 현재 다음 세션 저장소 백엔드를 지원합니다:
- File: 로컬 파일 시스템에 녹화를 저장합니다. 개발 환경, 데모, 소규모 홈 환경에 적합합니다.
- S3: AWS S3 버킷 또는 S3 호환 저장소에 녹화를 저장합니다. 프로덕션 배포에 적합합니다.
- GCS: Google Cloud Storage에 녹화를 저장합니다. 프로덕션 배포에 적합합니다.
Teleport Auth Service만이 저장소 백엔드에 직접 쓰는 구성 요소입니다.
세션 저장소 백엔드는 다른 서비스 집합(SQLite, DynamoDB, Firestore 등)을 지원하는 Teleport의 클러스터 상태 또는 감사 로그 저장소와 구별됩니다.
형식#
Teleport 세션 녹화는 세션과 관련된 구조화된 이벤트의 정렬된 시퀀스입니다. 각 이벤트는 인코딩된 Protocol Buffer이며, 완전한 세션은 저장소 백엔드에 기록되기 전에 gzip으로 압축되고 선택적으로 암호화됩니다.
이러한 녹화는 하위 호환성을 위해 .tar 확장자를 가지지만, TAR 아카이브가 아니며 tar 유틸리티를 사용하여 읽을 수 없다는 점에 주의해야 합니다.
재생#
SSH 및 Kubernetes 세션은 Teleport의 웹 UI나 tsh play 명령을 사용하여 재생할 수 있습니다. 데스크톱 세션 녹화는 웹 UI에서만 재생할 수 있습니다.
PostgreSQL 데이터베이스 세션도 tsh play와 웹 UI를 사용하여 재생할 수 있습니다. 모든 데이터베이스 프로토콜의 세션은 JSON 형식(--format json)으로 tsh play를 통해 접근할 수 있습니다.
웹 UI에서 세션 녹화 페이지는 녹화에 대한 메타데이터가 포함된 세션 종료 이벤트에 대해 Teleport의 감사 로그를 쿼리하여 채워집니다. 이는 Teleport 사용자에게 종종 놀라운 일인데, 녹화와 감사 로그가 별개의 백엔드에 저장되지만 녹화를 재생하려면 둘 다 작동 중이어야 하기 때문입니다.
다운로드#
세션 녹화는 tctl recordings download 명령을 사용하여 클러스터 저장소에서 다운로드할 수 있습니다.
$ tctl recordings download [--output-dir <output-dir>] <session_id>
세션 녹화 암호화가 활성화된 경우 다운로드된 모든 녹화는 스트리밍 프로세스 중에 복호화됩니다.
업로드 완성기#
모든 Teleport 프로세스는 주기적으로 중단된 업로드를 확인하고 녹화와 관련된 세션에 대한 활성 세션 추적기가 없는 경우 완료하는 업로드 완성기라는 서비스를 실행합니다. 기본적으로 업로드 완성기는 5분마다 실행되며, 세션 추적기는 30분 만료 기간을 가집니다. 이는 서비스가 다시 온라인 상태가 된 후 중단된 업로드가 완료되는 데 최대 ~35분이 걸릴 수 있음을 의미합니다.
비동기 녹화 모드에서 세션 중에 노드가 다운되면 부분적으로 완료된 녹화가 노드의 디스크에 남습니다. 노드의 업로드 완성기는 결국 중단된 업로드를 감지하고 Teleport Auth Service로 스트리밍하여 저장소 백엔드에 기록됩니다.
동기 녹화 모드에서 Teleport의 Auth Service는 저장소로 직접 녹화를 스트리밍합니다. 세션 중에 Auth Service가 다운되면 완료되지 않은 업로드가 일련의 부분으로(클라우드 저장소 또는 Auth Service 인스턴스의 디스크에) 남게 되고, 중단된 업로드를 감지하고 완료하는 것은 Auth Service의 업로드 완성기의 책임입니다.
녹화 요약#
Teleport Identity Security를 사용하면 세션 녹화에 대해 언어 모델을 실행하여 세션 요약을 생성할 수 있습니다. 이 기능은 SSH, Kubernetes 및 데이터베이스 세션을 지원하며 Teleport 클러스터에 Identity Security 라이선스가 있는 경우에만 사용 가능합니다.
각 녹화가 업로드된 후, Teleport Auth Service는 세션 메타데이터를 모든 inference_policy 리소스와 일치시킵니다. 일치하는 항목이 발견되면, 해당 inference_model 리소스의 구성을 사용하여 세션 녹화를 생성합니다. 추론 모델은 다른 옵션 중에서 요약을 생성하는 데 사용되는 추론 공급자 및 공급자별 모델을 지정합니다.
Auth Service당 최대 150개의 동시 요약 작업이 실행됩니다. 더 많은 세션이 도착하면 이전 세션이 요약될 때까지 auth 서버는 대기합니다.
세션 녹화 요약은 세션 녹화와 함께 저장되며 Teleport 웹 앱을 사용하여 볼 수 있습니다.
수동 암호화 키 관리#
수동 암호화 키 관리는 키 관리에 대한 모든 책임과 복잡성을 관리자에게 부여합니다. 이는 Teleport의 세션 녹화 또는 재생 기능에 영향을 미치는 잘못된 구성의 위험이 훨씬 더 큽니다. 이 때문에 Teleport Cloud는 수동 암호화 키 관리 구성을 허용하지 않습니다. 사용 사례에서 수동 키 관리가 명시적으로 필요하지 않은 한 기본 자동 키 관리를 사용하는 것을 고려하십시오.
기본적으로 Teleport는 세션 녹화 암호화 키를 자동으로 프로비저닝하고 관리합니다. 그러나 Teleport가 키를 직접 관리할 충분한 권한이 없는 환경과 같이 자동 관리가 불가능하거나 원하지 않는 경우가 있을 수 있습니다. 이 때문에 Teleport는 외부적으로 관리되는 키를 사용하도록 구성할 수 있습니다. 이는 teleport.yaml 파일이나 동적 session_recording_config 리소스의 encryption.manual_key_management 구성을 사용하여 제어됩니다.
encryption:
enabled: yes
manual_key_management:
enabled: yes
active_keys:
- type: pkcs11
label: 'session_recordings_002'
rotated_keys:
- type: pkcs11
label: 'session_recordings_001'
세션 녹화 암호화는 4096비트 RSA 키 쌍을 사용한 OAEP를 사용하는 봉투 암호화 형식에 의존합니다. 이는 RSA 4096이 manual_key_management와 함께 사용할 수 있는 유일한 키 유형임을 의미합니다. 또한 이러한 키가 복호화에 사용될 수 있도록 허용되는 것도 중요합니다. 이것이 의미하는 바는 키 저장소 백엔드마다 다르지만, 일반적으로 키가 처음 프로비저닝될 때 정의되어야 합니다.
