접근 모니터링은 사용자가 텔레포트 클러스터 내의 접근 패턴을 이해하고 분석할 수 있도록 합니다.
클러스터에서 접근 모니터링이 활성화되면, 텔레포트는 다양한 입력 소스에서 데이터를 수집하고 클러스터 내의 사용 패턴을 강조하는 그래픽 보고서를 작성하며, 사용자가 자동화된 응답 작업을 생성할 수 있도록 하는 백그라운드 서비스를 실행합니다.
접근 모니터링의 주요 데이터 소스는 텔레포트 감사 로그입니다. 기본 제공 기능으로, 텔레포트는 감사 로그에서 위험한 사용 패턴을 나타내는 이벤트(예: MFA 없이 SSH 또는 데이터베이스 세션)를 검색하고 사용자에게 권장 작업을 제공합니다.
사용자는 감사 로그를 쿼리하여 자신만의 커스텀 접근 모니터링 쿼리를 작성할 수 있습니다.
접근 모니터링은 텔레포트 엔터프라이즈(클라우드 호스팅)에서 외부 감사 저장소와 함께 현재 지원되지 않습니다. 이 기능은 향후 텔레포트 릴리즈에서 활성화될 것입니다.
필수 조건
- 텔레포트 v14 이상.
- 자가 호스팅된 텔레포트의 경우 AWS Athena Backend가 필요합니다.
구성
텔레포트 접근 모니터링은 모든 텔레포트 엔터프라이즈(클라우드 호스팅) 계정에 대해 기본적으로 활성화되어 있습니다.
접근 모니터링을 활성화하려면 텔레포트 인증 서비스 구성 파일을 업데이트해야 합니다:
auth_service:
access_monitoring:
enabled: true
# 텔레포트가 Athena SQL 쿼리를 실행하기 위해 가정할 AWS 역할 ARN.
# 텔레포트 역할은 신뢰 관계로 구성되어야 하며 이 역할을 가정할 수 있어야 합니다.
role_arn: arn:aws:iam::123456789012:role/AccessMonitoringRole
# 접근 모니터링 보고서가 저장될 S3 버킷.
report_results: s3://audit-long-term/report_results
# (선택 사항) 접근 모니터링 쿼리에서 사용되는 Athena 작업 그룹
# (설정하지 않으면 기본 주 작업 그룹이 사용됩니다).
workgroup: access_monitoring_workgroup
접근 모니터링은 인증 서비스가 Athena 감사 이벤트 백엔드에 접근하기 위해 사용하는 역할과 다른 AWS 역할을 사용하여 Athena SQL 쿼리를 실행합니다. 이 역할은 텔레포트 역할과 신뢰 관계가 있어야 하며 다음 IAM 권한이 있어야 합니다. 접근 모니터링에서 사용하는 IAM 역할이 Athena에 대한 충분한 접근 권한으로 구성되어 있는지 확인하십시오. 아래에는 인증 서비스가 Athena 쿼리를 실행하고 결과를 S3 버킷에 저장할 수 있도록 허용하는 IAM 권한이 나와 있습니다.
플레이스홀더 값 | 교체할 값 |
---|---|
eu-central-1 | AWS 리전 |
1234567890 | AWS 계정 ID |
audit-long-term | 장기 저장에 사용되는 S3 버킷 |
audit-transient | 일시적인 저장에 사용되는 S3 버킷 |
kms_id | S3의 서버 측 암호화를 위한 KMS 키 ID |
audit_db | 감사 로그에 사용되는 Glue 데이터베이스 |
audit_table | 감사 로그에 사용되는 Glue 테이블 |
audit_workgroup | 접근 모니터링 쿼리에 사용되는 Athena 작업 그룹 |
{
"Statement": [
{
"Action": [
"s3:ListBucketVersions",
"s3:ListBucketMultipartUploads",
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::audit-transient",
"arn:aws:s3:::audit-long-term"
]
},
{
"Action": [
"s3:PutObject",
"s3:GetObjectVersion",
"s3:GetObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3::::audit-transient/results/*",
"arn:aws:s3:::audit-long-term/report_results/*"
]
},
{
"Action": [
"s3:ListMultipartUploadParts",
"s3:GetObjectVersion",
"s3:GetObject",
"s3:AbortMultipartUpload"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::audit-transient/results/*",
"arn:aws:s3:::audit-long-term/report_results/*",
"arn:aws:s3:::audit-long-term/events/*"
]
},
{
"Action": [
"glue:GetTable",
"athena:StartQueryExecution",
"athena:GetQueryResults",
"athena:GetQueryExecution"
],
"Effect": "Allow",
"Resource": [
"arn:aws:glue:eu-central-1:1234567890:table/audit_db/audit_table",
"arn:aws:glue:eu-central-1:1234567890:database/audit_db",
"arn:aws:glue:eu-central-1:1234567890:catalog",
"arn:aws:athena:eu-central-1:1234567890:workgroup/audit_workgroup"
]
},
{
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Effect": "Allow",
"Resource": "arn:aws:kms:eu-central-1:1234567890:key/kms_id"
}
],
"Version": "2012-10-17"
}
AWS 리소스를 설정하고 Athena 백엔드 및 접근 모니터링 텔레포트 구성을 생성하는 데 사용할 수 있는 Terraform 예제를 참조하십시오:
$ terraform apply
...
access_monitoring:
enabled: true
report_results: s3://long-term/report_results
role_arn: arn:aws:iam::123456789012:role/AccessMonitoringRole
workgroup: access_monitoring_workgroup
접근 모니터링 RBAC 권한
접근 모니터링 인터페이스에 접근하려면 사용자가 security_report
및 audit_query
리소스에 대한 list
, read
및 use
동사 허용하는 역할을 가지고 있어야 합니다. 미리 설정된 auditor
역할은 기본적으로 이러한 권한을 가지고 있습니다. 또는 이러한 권한으로 커스텀 역할을 생성할 수 있습니다:
kind: role
metadata:
name: my-role
spec:
allow:
rules:
- resources:
- security_report
- audit_query
verbs:
- list
- read
- use
쿼리 편집기
텔레포트 접근 모니터링의 쿼리 편집기는 사용자가 감사 로그를 상호작용적으로 쿼리하고 보고서를 생성할 수 있는 인터페이스를 제공합니다. 사용자는 관계형 데이터베이스를 쿼리하는 것과 같은 커스텀 SQL 쿼리를 작성하여 이러한 뷰에 대한 커스텀 보고서를 작성할 수 있습니다.
쿼리 편집기 내에서 사용자는 텔레포트에서 캡처한 감사 이벤트를 나타내는 여러 SQL 뷰에 접근할 수 있습니다. 아래는 가능한 SQL 뷰 목록입니다:
access_list_create
access_list_delete
access_list_member_create
access_list_member_delete
access_list_member_update
access_list_review
access_list_update
access_request_create
access_request_review
auth
bot_join
cert_create
db_session_query
db_session_query_failed
db_session_start
device_authenticate
device_enroll
exec
instance_join
join_token_create
kube_request
lock_created
lock_deleted
recovery_code_used
reset_password_token_create
saml_idp_auth
session_command
session_join
session_rejected
session_start
user_create
user_login
user_password_change
windows_desktop_session_end
windows_desktop_session_start
쿼리 편집기에 접근하려면 텔레포트 UI의 접근 모니터링
섹션으로 이동하여 쿼리 편집기
탭을 클릭하세요.
SQL 쿼리 예제
/etc/passwd
파일과 관련된 ssh 명령을 실행한 고유 사용자 쿼리:
SELECT
DISTINCT user
FROM
exec
WHERE
command LIKE '%/etc/passwd%';
- 각 사용자 인증서와 관련된 고유 IP 주소의 수를 날짜별로 선택:
SELECT
event_date,
identity_user AS user,
COUNT(DISTINCT cert_create.identity_client_ip) AS unique_ip_count
FROM
cert_create
GROUP BY
event_date,
identity_user
ORDER BY
event_date;
- 서로 다른 여러 IP 주소에서 텔레포트 클러스터와 상호작용한 사용자 선택:
SELECT * FROM (SELECT
event_date,
identity_user AS user,
COUNT(DISTINCT cert_create.identity_client_ip) AS unique_ip_count
FROM
cert_create
GROUP BY
event_date,
identity_user
ORDER BY
event_date) AS data WHERE unique_ip_count > 1;
- 사용자 'admin-annie'가 사용한 모든 고유 IP 주소 표시:
SELECT
DISTINCT identity_client_ip
FROM
cert_create
WHERE identity_user = 'admin-annie'
- 접근 요청 및 이를 검토한 정보 표시:
SELECT
*
FROM
access_request_create, access_request_review
WHERE
access_request_create.id = access_request_review.id
- 접근 요청 및 검토에 대한 자세한 정보 표시:
SELECT
request.user, request.reason, request.roles, request.resource_ids, review.reviewer, review.state
FROM
access_request_create as request, access_request_review as review
WHERE
request.id = review.id
접근 모니터링 보고서
접근 모니터링은 여러 개의 사전 구축된 보고서를 제공합니다.
권한 있는 접근 보고서
권한 있는 접근 보고서
는 인프라 전반에 걸쳐 보안 이벤트를 식별하는 데 유용한 통찰력을 제공합니다. 이 보고서는 다음의 약한 보안 이벤트를 식별할 수 있습니다:
약한 보안을 가진 데이터베이스 세션
다음 쿼리는 누락된 접근 요청, MFA, 가장 사용, 신뢰할 수 있는 장치 식별이 없는 약한 보안을 가진 데이터베이스 세션을 식별합니다.
SELECT
event_date,
count(*) as count,
user
FROM
db_session_start
WHERE
CARDINALITY(access_requests) IS NULL
AND
with_mfa IS NULL
AND
impersonator IS NULL
AND
trusted_device_device_id IS NULL
GROUP BY
event_date,
user
ORDER BY
event_date
제안: 접근 요청, 장치 신뢰 및 세션당 MFA를 설정하세요.
약한 보안을 가진 SSH 세션
다음 쿼리는 누락된 접근 요청, MFA, 가장 사용, 신뢰할 수 있는 장치 식별이 있는 약한 보안 SSH 세션을 식별합니다.
SELECT
event_date,
count(*) as count,
user
FROM
session_start
WHERE
CARDINALITY(access_requests) IS NULL
AND
proto='ssh'
AND
with_mfa IS NULL
AND
impersonator IS NULL
AND
trusted_device_device_id IS NULL
GROUP BY
event_date,
proto,
user
ORDER BY
event_date
제안: 접근 요청, 장치 신뢰 및 세션당 MFA를 설정하세요.
약한 보안을 가진 Kubernetes API 호출
다음 쿼리는 누락된 접근 요청, MFA, 가장 사용, 신뢰할 수 있는 장치 식별이 있는 약한 보안 Kubernetes 세션을 식별합니다.
SELECT
event_date,
count(*) as count,
user
FROM
kube_request
WHERE
CARDINALITY(access_requests) IS NULL
AND
with_mfa IS NULL
AND
impersonator IS NULL
AND
trusted_device_device_id IS NULL
GROUP BY
event_date,
user
ORDER BY
event_date
제안: 접근 요청, 장치 신뢰 및 세션당 MFA를 설정하세요.
권한 있는 PostgreSQL 세션
다음 쿼리는 'postgres' 사용자에 의해 시작된 권한 있는 PostgreSQL 세션을 식별합니다.
SELECT
event_date,
COUNT(*) AS count,
user
FROM
db_session_start
WHERE
db_protocol='postgres' and db_user='postgres'
GROUP BY
event_date,
user
ORDER BY
event_date
제안: 데이터베이스 연결을 덜 권한 있는 데이터베이스 사용자로 낮추세요.
Kube Execs
다음 쿼리는 Kubernetes exec 사용량을 식별합니다.
SELECT
event_date,
count(*) as count,
user
FROM
exec
WHERE
proto='kube'
GROUP BY
event_date,
proto,
user
ORDER BY
event_date
제안: kube exec의 사용을 제거하세요.
장기 수명 인증서
다음 쿼리는 유효 기간이 1일 이상인 장기 수명 인증서를 식별합니다.
SELECT DISTINCT
event_date,
COUNT(*) AS count,
identity_user AS user
FROM
cert_create
WHERE
from_iso8601_timestamp(identity_expires) - from_iso8601_timestamp(time) > INTERVAL '1' DAY
GROUP BY
event_date,
identity_user
ORDER BY
event_date
제안: 하룻동안 작업하는 짧은 수명 인증서를 사용하세요. 자동화를 위해 짧은 수명 인증서를 얻으려면 머신 ID를 확인하세요.
장기 수명 조인 토큰
다음 쿼리는 유효 기간이 1일 이상인 장기 수명 조인 토큰을 식별합니다.
SELECT
event_date,
COUNT(*) as count,
node_name,
host_id
FROM
instance_join
WHERE
FROM_ISO8601_TIMESTAMP(token_expires) - FROM_ISO8601_TIMESTAMP(time) > INTERVAL '1' DAY
GROUP BY
event_date,
node_name,
host_id
ORDER BY
event_date
제안: 가능한 경우 위험을 줄이기 위해 짧은 수명 토큰을 사용하며 위임된 조인하는 것을 고려하세요.
루트 SSH 세션
다음 쿼리는 'root' 사용자에 의해 시작된 SSH 세션을 식별합니다.
SELECT
event_date,
COUNT(*) as count,
user
FROM
session_start
WHERE
login='root'
GROUP BY
event_date,
user
ORDER BY
event_date
제안: SSH 세션에 대해 root
를 사용하지 마세요. sudo 권한이 있는 사용자에게 접근을 낮추세요.
시스템 Kubernetes API 호출
다음 쿼리는 'system:master' 그룹의 사용자에 의해 시작된 Kubernetes API 호출을 식별합니다.
SELECT
event_date,
COUNT(*) as count,
user
FROM
kube_request
WHERE
CONTAINS(kubernetes_groups, 'system:masters')
GROUP BY
event_date,
user
ORDER BY
event_date
제안: Kubernetes API 호출을 위해 system:masters 그룹을 사용하지 마세요. 대신 view
또는 edit
로 낮추세요.
CLI에서 접근 모니터링 감사 쿼리 실행
커스텀 감사 쿼리를 tctl audit query exec
명령을 사용하여 실행합니다:
tctl audit query exec 'select event_time,identity_user from cert_create order by event_date limit 1;'[ { "data": [ "event_time", "identity_user" ] }, { "data": [ "2024-03-20 12:12:03.374", "alice" ] }]
쿼리 결과는 배열의 배열 형태로 JSON으로 반환됩니다. 첫 번째 배열은 열 이름을 포함하고, 이후의 배열은 쿼리 결과를 포함합니다.