감사 이벤트 및 레코드
Teleport는 감사 로그에 다양한 이벤트를 기록하여 클러스터 활동을 로깅합니다. BPF를 사용한 향상된 세션 녹화를 사용하면 고급 보안 기능을 갖춘 더욱 포괄적인 감사 로그를 얻을 수 있습니다. Teleport는 감사 이벤트를 저장하기 위한 여러 스토리지 백엔드를 지원합니다.
Teleport는 감사 로그에 다양한 이벤트를 기록하여 클러스터 활동을 로깅합니다. 감사 로그는 두 가지 구성 요소로 이루어져 있습니다:
- 클러스터 이벤트: Teleport는 원격 IP 주소, 시간, 세션 ID 등의 메타데이터와 함께 성공적인 사용자 로그인과 같은 이벤트를 기록합니다.
- 녹화된 세션: 모든 SSH, 데스크톱 또는 Kubernetes 셸 세션이 녹화되며 나중에 재생할 수 있습니다. 기본적으로 녹화는 Teleport 노드에 의해 수행되지만, 프록시에서 수행하도록 구성할 수도 있습니다.
- 클러스터 이벤트: Teleport는 원격 IP 주소, 시간, 세션 ID 등의 메타데이터와 함께 성공적인 사용자 로그인과 같은 이벤트를 기록합니다.
- 녹화된 세션: 모든 SSH, 데스크톱 또는 Kubernetes 셸 세션이 녹화되며 나중에 재생할 수 있습니다. Teleport Cloud가 세션 녹화 데이터의 저장을 관리합니다.
BPF를 사용한 향상된 세션 녹화를 사용하면 고급 보안 기능을 갖춘 더욱 포괄적인 감사 로그를 얻을 수 있습니다.
이벤트#
Teleport는 감사 이벤트를 저장하기 위한 여러 스토리지 백엔드를 지원합니다. dir 백엔드는 Auth Service 호스트의 로컬 파일 시스템을 사용합니다. 이 백엔드를 사용할 경우, 이벤트는 JSON 형식으로 파일 시스템에 기록됩니다. dir 백엔드는 약 24시간마다 이벤트 파일을 순환하지만, 캡처된 이벤트는 삭제하지 않습니다.
고가용성 구성의 경우, SSH 이벤트 및 녹화된 세션을 네트워크 스토리지에 저장하는 방법에 대한 정보는 Athena, DynamoDB 또는 Firestore 챕터를 참조하세요. 이러한 백엔드를 사용하면 감사 이벤트가 결국 만료되어 로그에서 제거됩니다. 기본 보존 기간은 1년이지만, retention_period 구성 매개변수를 사용하여 재정의할 수 있습니다.
감사 로그를 여러 위치에 동시에 저장하는 것도 가능합니다. 감사 로그 구성 방법에 대한 자세한 내용은 Teleport 구성 참조의 예제 구성 파일에서 storage 섹션을 참조하세요.
dir 백엔드를 사용하여 Teleport 감사 로그를 살펴보겠습니다. Teleport Auth Service 인스턴스는 서비스의 UUID를 기반으로 이름이 지정된 Teleport의 구성된 데이터 디렉터리의 하위 디렉터리에 로그를 기록합니다.
각 날은 하나의 파일로 표현됩니다:
$ ls -l /var/lib/teleport/log/bbdfe5be-fb97-43af-bf3b-29ef2e302941
# total 104
# -rw-r----- 1 root root 31638 Jan 22 20:00 2022-01-23.00:00:00.log
# -rw-r----- 1 root root 91256 Jan 31 21:00 2022-02-01.00:00:00.log
# -rw-r----- 1 root root 15815 Feb 32 22:54 2022-02-03.00:00:00.log
Teleport Enterprise Cloud가 감사 로그 저장을 관리합니다. 다음을 클릭하여 Teleport Web UI를 통해 감사 로그에 액세스할 수 있습니다:
Audit > Audit Log
감사 로그는 JSON 형식을 사용합니다. 사람이 읽을 수 있으며 프로그래밍 방식으로 파싱할 수도 있습니다. 각 줄은 하나의 이벤트를 나타내며 다음 형식을 갖습니다:
{
// 이벤트 유형. 가능한 모든 이벤트 유형의 목록은 아래를 참조하세요.
"event": "session.start",
// 이벤트 로그의 고유 ID. 중복 제거에 유용합니다.
"uid": "59cf8d1b-7b36-4894-8e90-9d9713b6b9ef",
// Teleport 사용자 이름
"user": "ekontsevoy",
// OS 로그인
"login": "root",
// 서버 네임스페이스. 이 필드는 향후 사용을 위해 예약되어 있습니다.
"namespace": "default",
// 고유 서버 ID
"server_id": "f84f7386-5e22-45ff-8f7d-b8079742e63f",
// 서버 레이블
"server_labels": {
"datacenter": "us-east-1",
"label-b": "x"
}
// 세션 ID. 세션 재생에 사용할 수 있습니다.
"sid": "8d3895b6-e9dd-11e6-94de-40167e68e931",
// SSH 노드의 주소
"addr.local": "10.5.l.15:3022",
// 연결하는 클라이언트(사용자)의 주소
"addr.remote": "73.223.221.14:42146",
// 터미널 크기
"size": "80:25",
// 타임스탬프
"time": "2017-02-03T06:54:05Z"
}
이벤트 유형#
아래는 감사 이벤트의 가능한 유형들입니다.
이 목록은 포괄적이지 않습니다. 이벤트 페이로드를 자동으로 파싱하고 event 키로 그룹화 및 필터링하여 트렌드를 발견할 수 있는 플랫폼으로 감사 이벤트를 내보내는 것을 권장합니다. 감사 이벤트 내보내기 설정 방법은 Teleport 감사 이벤트 내보내기를 읽어보세요.
| 이벤트 유형 | 설명 |
|---|---|
| auth | 인증 시도. 다음 필드를 추가합니다: {"success": "false", "error": "access denied"} |
| session.start | 대화형 셸 세션을 시작했습니다. |
| session.end | 대화형 셸 세션이 종료되었습니다. |
| session.join | 새 사용자가 기존 대화형 셸 세션에 참가했습니다. |
| session.leave | 사용자가 세션에서 나갔습니다. |
| session.disk | 세션 중에 열린 파일 목록. 향상된 세션 녹화가 필요합니다. |
| session.network | 세션 중에 이루어진 네트워크 연결 목록. 향상된 세션 녹화가 필요합니다. |
| session.command | 세션 중에 실행된 명령 목록. 향상된 세션 녹화가 필요합니다. |
| session.recording.access | 세션 녹화에 액세스했습니다. |
| exec | tsh ssh root@node ls /와 같이 SSH를 통해 원격 명령이 실행되었습니다. 다음 필드가 기록됩니다: {"command": "ls /", "exitCode": 0, "exitError": ""} |
| scp | 원격 파일 복사가 실행되었습니다. 다음 필드가 기록됩니다: {"path": "/path/to/file.txt", "len": 32344, "action": "read" } |
| resize | 터미널 크기가 변경되었습니다. |
| user.login | 사용자가 Web UI 또는 tsh를 통해 로그인했습니다. 다음 필드가 기록됩니다: {"user": "alice@example.com", "method": "local"} . |
| app.session.start | 사용자가 애플리케이션에 액세스했습니다 |
| app.session.chunk | 앱 세션 중 활동 레코드 |
| join_token.create | 새 참가 토큰이 생성되었습니다. 다음 필드를 추가합니다: {"roles": ["Node", "Db"], "join_method": "token"} |
| mcp.session.start | MCP 서버 세션이 시작되었습니다. |
| mcp.session.end | MCP 서버 세션이 종료되었습니다. |
| mcp.session.notification | MCP 클라이언트에서 알림이 전송되었습니다. |
| mcp.session.request | MCP 클라이언트에서 요청이 전송되었습니다. |
| mcp.session.listen_sse_stream | 스트리머블 HTTP 클라이언트가 SSE 스트림을 통해 서버 알림을 수신하기 시작했습니다. |
| mcp.session.invalid_http_request | 클라이언트가 Teleport에서 처리할 수 없는 HTTP 요청을 전송했습니다. |
녹화된 세션#
Teleport는 시작 및 종료 이벤트를 기록하는 것 외에도 전체 세션을 녹화할 수 있습니다. SSH 또는 Kubernetes 세션의 경우 PTY에서의 전체 바이트 스트림을 캡처합니다. 데스크톱 세션의 경우 녹화에 화면 내용이 포함됩니다.
Teleport는 녹화된 세션을 AWS S3 버킷이나 로컬 파일 시스템(NFS 포함)에 저장할 수 있습니다.
녹화된 세션은 log 아래의 sessions 디렉터리에 원시 바이트로 저장됩니다. 각 세션은 protobuf 인코딩된 이진 데이터 스트림입니다.
tsh play 명령 또는 Web UI를 사용하여 녹화된 세션을 재생할 수 있습니다.
예를 들어, CLI를 통해 세션을 재생하려면:
$ tsh play 4c146ec8-eab6-11e6-b1b3-40167e68e931
JSON 형식으로 세션 이벤트를 표준 출력에 출력하려면:
$ tsh play 4c146ec8-eab6-11e6-b1b3-40167e68e931 --format=json
Teleport Enterprise Cloud는 자동으로 녹화된 세션을 저장합니다.
tsh play 명령 또는 Web UI를 사용하여 녹화된 세션을 재생할 수 있습니다.
예를 들어, CLI를 통해 세션을 재생하려면:
$ tsh play 4c146ec8-eab6-11e6-b1b3-40167e68e931
JSON 형식으로 세션 이벤트를 표준 출력에 출력하려면:
$ tsh play 4c146ec8-eab6-11e6-b1b3-40167e68e931 --format=json
모드#
SSH 세션에서만 사용할 수 있으며, Teleport가 auth_service.session_recording: node로 구성된 경우에만 해당됩니다.
모드는 디스크 가득 참 오류와 같은 녹화 실패 시 Teleport가 어떻게 처리하는지를 정의합니다. 가장 엄격한 값이 우선순위를 갖는 역할 수준에서 서비스별로 구성됩니다. 사용 가능한 모드는 다음과 같습니다:
| 모드 | 녹화 실패 후 |
|---|---|
최선 노력 (best_effort) |
세션을 종료하지 않고 녹화를 비활성화합니다. |
엄격 (strict) |
세션을 즉시 종료합니다. |
사용자 역할에 녹화 모드가 지정되지 않은 경우 best_effort가 사용됩니다. 다음은 SSH 세션에 엄격 모드를 사용하도록 구성된 역할의 예입니다:
kind: role
version: v5
metadata:
name: ssh-strict
spec:
options:
record_session:
ssh: strict
녹화 프록시 모드 활성화#
다음과 같이 Auth Service 구성 파일을 편집합니다:
# snippet from /etc/teleport.yaml
auth_service:
# Session Recording must be set to Proxy to work with OpenSSH
session_recording: "proxy" # can also be "off" and "node" (default)
클러스터 전반에서 프록시 녹화 모드를 사용하는 것은 더 이상 OpenSSH 서버를 지원하기 위해 필요하지 않습니다. 프록시 녹화 모드는 이 모드의 주요 보안 우려 사항인 SSH 에이전트 포워딩 없이 OpenSSH 서버에 자동으로 사용됩니다.
녹화 프록시 모드는 레거시 OpenSSH 지원 및 기타 사용 사례를 위해 계속 지원되지만, 여러 기술적 제한으로 인해 많은 기존 및 새로운 기능이 이 모드에서 지원되지 않습니다.
선택적 비보안 단계: 엄격한 호스트 확인 비활성화#
녹화 프록시 모드에서 Teleport는 사용자가 연결하는 노드의 호스트 인증서가 Teleport CA에 의해 서명되었는지 확인합니다. 기본적으로 이것은 엄격한 검사입니다. 노드가 키만 제공하거나 다른 CA에 의해 서명된 인증서를 제공하면, Teleport는 다음 오류 메시지와 함께 이 연결을 거부합니다:
ssh: handshake failed: remote host presented a public key, expected a host
certificate
아래와 같이 엄격한 호스트 검사를 비활성화할 수 있습니다. 그러나 이는 중간자 공격의 가능성을 열어두므로 권장하지 않습니다.
# snippet from /etc/teleport.yaml
auth_service:
proxy_checks_host_keys: false
