액세스 모니터링 시작하기

액세스 모니터링은 사용자가 Teleport 클러스터 내의 액세스 패턴을 이해하고 분석할 수 있도록 합니다.

클러스터에서 액세스 모니터링이 활성화되면 Teleport는 배경 서비스가 실행되어 다양한 입력 소스에서 데이터를 수집하고, 클러스터 내의 사용 패턴을 강조하는 그래픽 보고서를 생성하며, 사용자가 자동 응답 작업을 생성할 수 있도록 합니다.

액세스 모니터링의 주요 데이터 소스는 Teleport 감사 로그입니다. 즉시 사용 가능하게, Teleport는 위험한 사용 패턴을 나타내는 이벤트를 감사 로그에서 검색하는 보고서를 포함하고 있습니다 (예: MFA 없이 SSH 또는 데이터베이스 세션) 및 사용자에게 권장 작업을 제공합니다.

사용자는 감사 로그를 쿼리하여 자신의 맞춤형 액세스 모니터링 쿼리를 작성할 수 있습니다.

Notice

액세스 모니터링은 현재 Teleport Enterprise(클라우드 호스팅)에서 외부 감사 저장소와 함께 지원되지 않습니다. 이 기능은 향후 Teleport 릴리스에서 활성화될 것입니다.

전제 조건

Teleport v14 이상.
자체 호스팅 Teleport의 경우, AWS Athena 백엔드가 필요합니다.

구성

Teleport 액세스 모니터링은 모든 Teleport Enterprise(클라우드 호스팅) 계정에 대해 기본적으로 활성화됩니다.

액세스 모니터링을 활성화하려면 Teleport Auth 서비스 구성을 업데이트해야 합니다:

auth_service:
  access_monitoring:
    enabled: true
    # Teleport가 Athena SQL 쿼리를 실행하기 위해 가정할 AWS 역할 ARN.
    # Teleport 역할은 신뢰 관계로 구성되어야 하며 이 역할을 가정할 수 있어야 합니다.
    role_arn: arn:aws:iam::123456789012:role/AccessMonitoringRole
    # 액세스 모니터링 보고서가 저장될 S3 버킷.
    report_results: s3://audit-long-term/report_results
    # (선택 사항) 액세스 모니터링 쿼리에서 사용하는 Athena 워크그룹
    # (설정하지 않으면 기본 기본 워크그룹이 사용됩니다).
    workgroup: access_monitoring_workgroup

액세스 모니터링은 Auth 서비스가 Athena 감사 이벤트 백엔드에 접근하기 위해 사용하는 것과 다른 AWS 역할을 사용하여 Athena SQL 쿼리를 실행합니다. 이 역할은 Teleport 역할과 신뢰 관계를 가져야 하며 아래 IAM 권한을 가져야 합니다. 액세스 모니터링에 사용되는 IAM 역할이 Athena에 대한 충분한 액세스가 구성되었는지 확인하십시오. 다음은 Auth 서비스가 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"
}

당사는 Terraform 예제를 사용하여 Athena 및 액세스 모니터링 AWS 리소스를 설정하고 Athena 백엔드 및 액세스 모니터링 Teleport 구성을 생성할 수 있습니다:

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

쿼리 편집기

Teleport 접근 모니터링의 쿼리 편집기는 사용자가 감사 로그를 상호작용적으로 쿼리하고 보고서를 생성할 수 있는 인터페이스를 제공합니다.
사용자는 이러한 뷰를 위해 사용자 정의 SQL 쿼리를 작성하여 관계형 데이터베이스를 쿼리하는 것과 유사한 사용자 정의 보고서를 작성할 수 있습니다.

쿼리 편집기 내에서 사용자는 Teleport에 의해 캡처된 감사 이벤트를 나타내는 여러 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

쿼리 편집기에 접근하려면 Teleport UI의 Access Monitoring 섹션으로 이동하여 Query Editor 탭을 클릭합니다.

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 주소에서 Teleport 클러스터와 상호작용한 사용자 선택:

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

접근 모니터링 보고서

접근 모니터링은 여러 개의 미리 구축된 보고서를 제공합니다.

권한 있는 접근 보고서

권한 있는 접근 보고$1 는 인프라 전반에 걸쳐 취약한 보안 이벤트를 식별하는 데 유용한 통찰력을 제공합니다.
이 보고서는 다음과 같은 취약한 보안 이벤트를 식별할 수 있습니다:

보안이 취약한 데이터베이스 세션

다음 쿼리는 접근 요청, 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

제안: 데이터베이스 연결을 권한이 적은 데이터베이스 사용자로 다운그레이드하십시오.

Kubernetes 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 배열로 반환됩니다. 첫 번째 배열은 열 이름을 포함하고, 후속 배열은 쿼리 결과를 포함합니다.

기본적으로 tctl audit query exec 는 지난 7일 동안 검색합니다. --days=N 플래그로 대체 시간을 지정할 수 있습니다.

Teleport 원문 보기